Christian, When you get some time, can you look at what I've done in the JMS transport to make sure it's all OK and doesn't introduce some massive scalability issue?
Basically, I now call the message observer directly from the onMessage(JMSMessage) call. This means its called on the thread that the JMS queue provides instead of from the CXF calling thread. Right now, if it's a synchronous invoke, I left the "wait()" in place on the main thread, but that's really not needed. It could return immediately as the ClientImpl will then wait if it's supposed to be synchronous. I mostly left it there due to the jmsTemplate.getReceiveTimeout() thing. If we return, the timeout would need to be configured on the client itself, which might not be a bad thing. Not really sure. Maybe the default could be RECEIVE_TIMEOUT_NO_WAIT and only wait on that main thread if it's set otherwise? I don't really know, not my area of expertise. I guess my main concern is if it's OK to process the response on the JMS provided thread. Is that part of a thread pool or similar? If not, we'll need to throw it on a workqueue. That's easy enough to do, but I wanted to hear from you first. Thanks! -- Daniel Kulp [EMAIL PROTECTED] http://dankulp.com/blog
