Christian - thanks a lot for response. I was looking into both 2.2 and 2.2.3 sources and it seems like correlation map is always populated for anything but one-way exchanges: correlationMap.put(correlationId, exchange); <<< all logic branches except one way call this
Also I see how sendExchange() calls JMSFactory.createJmsListener() that would create a brand new DefaultMessageListenerContainer per exchange. I wonder if thread settings would be effective with that approach. And while I see trunk has changed that to jmsTemplate.receiveSelected(), I realize one conceptual problem is still there: even if correlation part is solved, application still needs to send something in order to receive something. With clustered client and possible node failures in mind, I think I won't be able to use async implementation as is. So my options are * customize CXF client, like what I did. And the more I look at it the more I realize I extended part that was not designed for extension. I get ability to leverage JMS endpoint on server side though for free. * Use 2 two-way clients as you suggested. I'll look into other options first, as there are service consumers that would still want to call it synchronously. * Give up on the idea to reuse SOAP over JMS on server side and create another invocation layer (IL), like Camel-backed one you advised. It probably would be the best option, assuming that - it is possible to route all messages to original web service implementor, even though IL has changed - Exceptions/faults are somehow delivered to client too. - (Optional, but nice to have) JAXB context is borrowed from endpoint metadata. Is it something Camel could do? Thanks a lot for your help! Pavel On Sat, Oct 3, 2009 at 12:17 AM, Christian Schneider < [email protected]> wrote: > Hi Pavel, > > I am not sure about the transactional part but I can help you with the > asnyc interface. > > The easiest way to achieve asynch behaviour is to create a method with only > an in message and no out message. CXF will by default make the call > asynchronous. The new wsdl first example on the subversion head shows > this. > > The other way to use async is to use a binding file that declares > > Pavel schrieb: > >> * How do async bindings with JMS scale? >> I.e. in my mind lots of messages with response time in minutes or perhaps >> even hours leads to numerous listeners with numerous selectors. >> Also to large correlation map. >> >> > The JMS transport uses a spring DefaultMessageListenerContainer. Using the > JMSConfigFeature you can tweak it´s params. > http://cwiki.apache.org/CXF20DOC/using-the-jmsconfigfeature.html > > You can define the number of listener threads and then also the number of > threads the executor allows. So there should be no problem with overloading. > When all listeners and executors are blocked no additional messages will be > processed and wait in the JMS queue. You could even make sure that only one > message is processed at a time. > >> * How reliable async binding is for high load/slow response case? >> E.g. if client goes down, correlation map is lost, so are all responses. >> Or did I miss the way to recover after that? >> >> > I think you can turn off the correlation and use the async interface. So > any response should be processed. As you say you have the correlation > information in your > data this should work. > > If that does not work you could use two one way services. One for request > one for reply. So there would be no correlation. > > BTW. In your case of purely asynchronous communication that is only > correlated by the data it could also be an option to use simply XML over > JMS. You can serialize and deserialize with JAXB. > Apache Camel allows to do such things very easily. If you are interested I > could make a small example for this case. > >> * Does it work for static response queues? >> E.g. http://cwiki.apache.org/CXF20DOC/jms-transport.html states that >> "static reply queue can not be shared by several instances of the service >> client", but it is unclear if the issue is still relevant. >> >> > The problem was that with a static queue and an open selector the wrong > clients would retrieve the responses. But in your case this would be > desired. > >> Also if anyone already has experience with CXF/SOAP/JMS deployment and >> could >> share, that would be really great. >> >> >> > We use SOAP over JMS as the main service transport at EnBW (germany energy > company). Till now it works very well. We have not that big throughput > though. > > Greetings > > Christian > > > -- > > Christian Schneider > --- > http://www.liquid-reality.de > >
