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
