Hi Dan,
I will look into the async code on the weekend. Like you said the main
problem could be how to handle the separate thread
of the message handler.
Greetings
Christian
Daniel Kulp schrieb:
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!
--
Christian Schneider
---
http://www.liquid-reality.de
