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
>
>
