I was just doing my regular snooping around our server and noticed a very disturbing stack dump (see below.) I took the dump three times over 30 minutes, so I can confirm that there does indeed appear to be a hangup. It looks like it's due to the SOAP web services call not having any sort of timeout at the client-side, as well as the server-side having trouble handling some requests.
Has anyone run in to something like this?
"TP-Processor8" daemon prio=10 tid=0x091fb000 nid=0x7e3 runnable [0xa2bc6000..0xa2bc8030]
at java.net.SocketInputStream.socketRead0(Native Method)
- locked <0xab0a8b88> (a java.io.BufferedInputStream)
- locked <0xab0a8b58> (a sun.net.www.http.KeepAliveStream)
Thanks for the message, is it possible to get some more information? If there is an exception in Java the log should contain the type of the exception and the message.
Most of the stack trace is just the vm internals handling the request. The actual error could be a few things, e.g. a bug in the Java wrapper, incorrect input, a bug in the API, a network error, or just a timeout. The server will definitely timeout even if the client side does not.
I think you are misunderstanding my concern. There was no error or exception ever thrown. That isn't a stack_trace_ that I pasted, it's a stack_dump_. As in, that thread has been sitting there for days in that state. There is something going on with the SOAP stack that you're using that is not allowing things to time out properly.
Perhaps you can get a dev env of the API service created and put in a dummy "pause" that takes 10+ minutes. I believe that the SOAP client will sit there for 10 minutes, but I think a better approach would be to put in smart default timeouts in your API wrapper (ie: 10 seconds).
Any more news on this by chance? We're still seeing it happen :(
Thanks for reporting that. It seems that there should be some changes made to handle timeouts properly, though I haven't had a chance to make these changes yet.
The reason this code is freely available on GitHub is so that people like you can contribute to it. If you have the time, feel free to fork my GitHub repo and submit a pull request with your changes.
The Campaign Monitor developers can't officially support all the different bindings/wrappers for our API (most of which are developed/maintained externally), but we do what we can in the time we have available when not working on core features of our product.
I'm hoping to be able to work on the Java wrapper again soon, but can't make any promises on when I'll get to it.
Cool, thanks I appreciate the note. I was going to go down that route soon anyway. Is SOAP the only API you support currently? I'm a SOAP n00b, but if you did JSON over HTTP or some other simple REST-like syntax I would be happy to rig up and support a Java wrapper for that.
Yes, unfortunately we only support SOAP (all methods) and XML-RPC (most methods) currently. The documentation for each method states whether each access method is supported.
We'd like to have a fully RESTful API for Campaign Monitor in the future which supported different data formats and have started putting thought into how this would work in conjunction with our current API. Although this is obviously only one of a huge number of features requested by our users.