Hi Christian I'm happy to see that you're interested to discuss this contribution. I don't know if/when you may take some time to compare the 2 implementations, but if we can help in any way, let us know. For example, we could, from our POV, list the differences between the 2 transports, at least a first draft that you could review/enhance in order to make up your mind.
Regards --Guillaume 2011/7/8 Christian Schneider <ch...@die-schneider.net> > Yes request / response correlation is definately a place where we currently > loose message when the client goes down. > > I think this is o big issue though as you typically only use request > response when you wait for the response. So normally you will even want the > responses to be lost when the client goes down. In the one way case we > should not loose messages as we can also use transactions. > > Still your JMS transport my be interesting. When doing the refactoring to > spring jms templates and message listener I also thought about making the > transport more asynchronous but never really did it. > So I would like to compare your implementation with the current one in cxf. > > I would not like to have both though. If your transport is more suitable we > should throw the other away. In any case we should only have one JMS > transport. > > Christian > > > Am 08.07.2011 14:39, schrieb Florent BENOIT: > > Hi, >> >> One example about the "reliable" stuff is that we should include >> "recovery". >> For example the correlation map used to match JMS replies is stored in >> memory [1] >> 341 Exchange exchange = correlationMap.remove(**correlationId); >> 342 if (exchange == null) { >> 343 LOG.log(Level.WARNING, "Could not correlate message with >> correlationId " + correlationId); >> 344 return; >> 345 } >> >> >> So, if the JVM of the client is restarted, we will loose any replies as we >> won't know how to match the reply. >> Also, there is no JTA used with the current JMS transport. It means that >> we can loose data or to get some messages twice or so one. >> >> So even by using ActiveMQ with the messages being stored on the disk, this >> won't work after a restart. >> >> [1] : >> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/** >> src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?** >> view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup> >> >> Regards, >> >> Florent >> >> On 07/08/2011 02:25 PM, Benson Margulies wrote: >> >>> I'm confused. If you use AMQ configured for reliable storage on disk, >>> how do you lose things with the existing CXF transport? >>> >>> On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOIT<florent.ben...@ow2.org> >>> wrote: >>> >>>> Hi CXF guys, >>>> >>>> I would like to introduce a new CXF transport that we've developed and >>>> that >>>> could be contributed back to the CXF community. It is called "Reliable >>>> JMS >>>> transport" >>>> >>>> When this transport has been designed, the goal was to have a reliable >>>> transport that we could called "Enterprise Transport" as we wanted to >>>> use >>>> transactions and JMS by using containers like Java EE EJB or Spring MDP >>>> (we >>>> support both). We don't want to loose any requests or answers and we >>>> want to >>>> avoid waiting threads. This transport has not been designed from scratch >>>> as >>>> it is using the JMS layer and share some classes with the current CXF >>>> JMS >>>> transport but there are some differences between them. But we couldn't >>>> change the current transport as the design is not the same. >>>> >>>> First, let me give you details about this transport and why it's >>>> different >>>> from the current JMS CXF transport. >>>> >>>> The current CXF JMS transport is not reliable. For example, if you >>>> restart a >>>> client or a server you may loose some requests/answers. This is because >>>> the >>>> mechanism that is used is keeping data in memory. So after a JVM crash, >>>> all >>>> the data are lost. >>>> Also, for this new transport, we wanted to guarantee the delivery so it >>>> is >>>> using transactions. (A transaction manager is then required). >>>> As said before, we wanted to avoid the use of threads waiting for an >>>> answer. >>>> If there are 100 requests, we don't want 100 threads waiting their >>>> answer. >>>> This is because we can use either EJB MDB or Spring MDP to handle the >>>> answer. In this way, resources are allocated only if an answer is >>>> handled >>>> and not during all the waiting time. So the number of threads is >>>> dramatically reduced. Also by relying on EJB MDB or Spring MDP we're >>>> based >>>> on existing patterns. >>>> >>>> Here is a link to the documentation of this transport and pictures that >>>> are >>>> illustrating this solution : >>>> http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/** >>>> ReliableJMS_Transport_CXF<http://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF> >>>> This illustrates how the >>>> >>>> And the errors handling that is working with all kind of JVM crash : >>>> http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/** >>>> ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-** >>>> simple-failure-english.png<http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-failure-english.png> >>>> >>>> There are integration tests included in this transport that are launched >>>> through our continous integration tool on http://bamboo.ow2.org >>>> For now, they're using JOnAS as Java EE server as we need a JTA manager >>>> and >>>> we test both EJB MDB and Spring MDP providers. >>>> >>>> To sum up, is there an interest in CXF to integrate this transport ? >>>> What >>>> kind of changes need to be done, etc. >>>> Also I hope to get some feedback about this protocol. >>>> >>>> Regards, >>>> >>>> Florent >>>> >>>> >>>> >>>> >> >> > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > >