You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by pwanner <pw...@pwanner.com> on 2008/10/23 15:29:28 UTC
JMS transaction and delayed retry
Hi everyone,
I have an oportunity to introduce ServiceMix in my company, through this
simple use case:
1. Read a message in a MQSeries queue
2. Call a websevice and pass it the message
3. Get back the message from the ws and post it in an other MQSeries queue
But there are some constraints:
- This has to be done under the same JMS transaction, so that if there is
any problem calling the WS, the get from the first queue is rolled back and
the message is not lost.
- JMS transaction and NOT XA transaction.
- If there is a problem calling the WS the retry has to be delayed (let say
30 sec) to ensure that we are not falling in a "mad" loop of retries.
This is very easy with standard Java code I don't know if this is possible
with ServiceMix.
I know that the jms:consumer has a transacted="jms" attribute but it seems
to me that it's a transaction spanning just the get from the queue and the
send to the NMR.
I have already done the binding of the jms:consumer and the jms:provider
with the MQSeries queue, bridged the call to the http:provider through an
eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
jms:provider), but for the JMS transaction and the delayed retry I didn't
find anything.
Does anyone has any advise?
Thank you and best regards
Philippe
--
View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JMS transaction and delayed retry
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, that's something to check with MQ then. The transaction should
be rolled back, but I'm not sure under which conditions are messages
redelivered in MQ or how to configure the redelivery delay.
On Thu, Oct 23, 2008 at 5:45 PM, pwanner <pw...@pwanner.com> wrote:
>
> The point here is that we use IBM MQSeries and not ActiveMQ.
> Or would you say internally to ServiceMix?
> Anyway I tried with the cacheLevel attribute but it didn't change anything.
>
>
> gnodet wrote:
>>
>> Yes, there is. The problem with the redelivery is not really in
>> ServiceMix, but in ActiveMQ. The redelivery mechanism works on the
>> client side for a given consumer. So the key for the redelivery to
>> work as expected is to always use the same consumer and not close it.
>> It should work if you use the <jms:consumer /> endpoint with a
>> cacheLevel="3" which should ensure the consumer is reused and not
>> closed each time. It will also enhance the overall throughput on the
>> JMS side.
>>
>> On Thu, Oct 23, 2008 at 5:17 PM, pwanner <pw...@pwanner.com> wrote:
>>>
>>> I tried with the xa tm and it works fine for now.
>>> To manage a fault on the JBI exchange would you use a robust MEP?
>>> I insist on this point as I can't afford to loose any message!
>>> You said "the JMS message will be redelivered later" but in fact it's
>>> immediately, I mean with no delay, isn't it? Is it a way to set a
>>> redelivery
>>> interval to avoid the WS to be called 10 times per second with the same
>>> message whereas the service is not available for a while?
>>>
>>>
>>> gnodet wrote:
>>>>
>>>> In your case, XA is fine because there will be no two-phase commits
>>>> and no tx logs.
>>>> We're using the transaction manager from jenks (which delegates to the
>>>> geronimo tx mgr).
>>>> You can find the code at:
>>>>
>>>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/
>>>>
>>>> For the redelivery stuff, if the JBI exchange is in an ERROR state
>>>> (for example because the web service was not available and the
>>>> connection failed), the transaction will be rolled back and the JMS
>>>> message will be redelivered later. A fault on the JBI exchange won't
>>>> cause a rollback because faults are considered in a different way.
>>>>
>>>> On Thu, Oct 23, 2008 at 4:27 PM, pwanner <pw...@pwanner.com> wrote:
>>>>>
>>>>> The point about not using an XA transaction was to avoid the slow
>>>>> two-phase
>>>>> commit, as the throughput is a real concern.
>>>>> But also to avoid to have an other transaction manager with tx logs to
>>>>> configure and monitor. By the way, witch transaction manager are you
>>>>> talking
>>>>> about in the scenario you described? The jenks one?
>>>>> Anything about the recovery delay if the WS is down or generate a fault
>>>>> and
>>>>> the message is rolledback?
>>>>>
>>>>> Regards
>>>>> Philippe Wanner
>>>>>
>>>>>
>>>>> gnodet wrote:
>>>>>>
>>>>>> Why not using XA transactions ? The transaction manager is optimized
>>>>>> so that if there is only a single transacted resource (which would be
>>>>>> the case, as only the JMS connection factory would be used), it will
>>>>>> bypass the two-phase commit and simply commit the underlying JMS
>>>>>> transaction. In such a case, nothing is written to disk or whatever,
>>>>>> so there is no overhead.
>>>>>> This use case using XA works fine in servicemix. It may be possible
>>>>>> to do the same with JMS transactions only, but this is not really
>>>>>> supported.
>>>>>>
>>>>>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I have an oportunity to introduce ServiceMix in my company, through
>>>>>>> this
>>>>>>> simple use case:
>>>>>>>
>>>>>>> 1. Read a message in a MQSeries queue
>>>>>>> 2. Call a websevice and pass it the message
>>>>>>> 3. Get back the message from the ws and post it in an other MQSeries
>>>>>>> queue
>>>>>>>
>>>>>>> But there are some constraints:
>>>>>>> - This has to be done under the same JMS transaction, so that if
>>>>>>> there
>>>>>>> is
>>>>>>> any problem calling the WS, the get from the first queue is rolled
>>>>>>> back
>>>>>>> and
>>>>>>> the message is not lost.
>>>>>>> - JMS transaction and NOT XA transaction.
>>>>>>> - If there is a problem calling the WS the retry has to be delayed
>>>>>>> (let
>>>>>>> say
>>>>>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>>>>>>
>>>>>>> This is very easy with standard Java code I don't know if this is
>>>>>>> possible
>>>>>>> with ServiceMix.
>>>>>>>
>>>>>>> I know that the jms:consumer has a transacted="jms" attribute but it
>>>>>>> seems
>>>>>>> to me that it's a transaction spanning just the get from the queue
>>>>>>> and
>>>>>>> the
>>>>>>> send to the NMR.
>>>>>>>
>>>>>>> I have already done the binding of the jms:consumer and the
>>>>>>> jms:provider
>>>>>>> with the MQSeries queue, bridged the call to the http:provider
>>>>>>> through
>>>>>>> an
>>>>>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>>>>>>> jms:provider), but for the JMS transaction and the delayed retry I
>>>>>>> didn't
>>>>>>> find anything.
>>>>>>>
>>>>>>> Does anyone has any advise?
>>>>>>>
>>>>>>> Thank you and best regards
>>>>>>> Philippe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133175.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133710.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JMS transaction and delayed retry
Posted by pwanner <pw...@pwanner.com>.
The point here is that we use IBM MQSeries and not ActiveMQ.
Or would you say internally to ServiceMix?
Anyway I tried with the cacheLevel attribute but it didn't change anything.
gnodet wrote:
>
> Yes, there is. The problem with the redelivery is not really in
> ServiceMix, but in ActiveMQ. The redelivery mechanism works on the
> client side for a given consumer. So the key for the redelivery to
> work as expected is to always use the same consumer and not close it.
> It should work if you use the <jms:consumer /> endpoint with a
> cacheLevel="3" which should ensure the consumer is reused and not
> closed each time. It will also enhance the overall throughput on the
> JMS side.
>
> On Thu, Oct 23, 2008 at 5:17 PM, pwanner <pw...@pwanner.com> wrote:
>>
>> I tried with the xa tm and it works fine for now.
>> To manage a fault on the JBI exchange would you use a robust MEP?
>> I insist on this point as I can't afford to loose any message!
>> You said "the JMS message will be redelivered later" but in fact it's
>> immediately, I mean with no delay, isn't it? Is it a way to set a
>> redelivery
>> interval to avoid the WS to be called 10 times per second with the same
>> message whereas the service is not available for a while?
>>
>>
>> gnodet wrote:
>>>
>>> In your case, XA is fine because there will be no two-phase commits
>>> and no tx logs.
>>> We're using the transaction manager from jenks (which delegates to the
>>> geronimo tx mgr).
>>> You can find the code at:
>>>
>>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/
>>>
>>> For the redelivery stuff, if the JBI exchange is in an ERROR state
>>> (for example because the web service was not available and the
>>> connection failed), the transaction will be rolled back and the JMS
>>> message will be redelivered later. A fault on the JBI exchange won't
>>> cause a rollback because faults are considered in a different way.
>>>
>>> On Thu, Oct 23, 2008 at 4:27 PM, pwanner <pw...@pwanner.com> wrote:
>>>>
>>>> The point about not using an XA transaction was to avoid the slow
>>>> two-phase
>>>> commit, as the throughput is a real concern.
>>>> But also to avoid to have an other transaction manager with tx logs to
>>>> configure and monitor. By the way, witch transaction manager are you
>>>> talking
>>>> about in the scenario you described? The jenks one?
>>>> Anything about the recovery delay if the WS is down or generate a fault
>>>> and
>>>> the message is rolledback?
>>>>
>>>> Regards
>>>> Philippe Wanner
>>>>
>>>>
>>>> gnodet wrote:
>>>>>
>>>>> Why not using XA transactions ? The transaction manager is optimized
>>>>> so that if there is only a single transacted resource (which would be
>>>>> the case, as only the JMS connection factory would be used), it will
>>>>> bypass the two-phase commit and simply commit the underlying JMS
>>>>> transaction. In such a case, nothing is written to disk or whatever,
>>>>> so there is no overhead.
>>>>> This use case using XA works fine in servicemix. It may be possible
>>>>> to do the same with JMS transactions only, but this is not really
>>>>> supported.
>>>>>
>>>>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I have an oportunity to introduce ServiceMix in my company, through
>>>>>> this
>>>>>> simple use case:
>>>>>>
>>>>>> 1. Read a message in a MQSeries queue
>>>>>> 2. Call a websevice and pass it the message
>>>>>> 3. Get back the message from the ws and post it in an other MQSeries
>>>>>> queue
>>>>>>
>>>>>> But there are some constraints:
>>>>>> - This has to be done under the same JMS transaction, so that if
>>>>>> there
>>>>>> is
>>>>>> any problem calling the WS, the get from the first queue is rolled
>>>>>> back
>>>>>> and
>>>>>> the message is not lost.
>>>>>> - JMS transaction and NOT XA transaction.
>>>>>> - If there is a problem calling the WS the retry has to be delayed
>>>>>> (let
>>>>>> say
>>>>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>>>>>
>>>>>> This is very easy with standard Java code I don't know if this is
>>>>>> possible
>>>>>> with ServiceMix.
>>>>>>
>>>>>> I know that the jms:consumer has a transacted="jms" attribute but it
>>>>>> seems
>>>>>> to me that it's a transaction spanning just the get from the queue
>>>>>> and
>>>>>> the
>>>>>> send to the NMR.
>>>>>>
>>>>>> I have already done the binding of the jms:consumer and the
>>>>>> jms:provider
>>>>>> with the MQSeries queue, bridged the call to the http:provider
>>>>>> through
>>>>>> an
>>>>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>>>>>> jms:provider), but for the JMS transaction and the delayed retry I
>>>>>> didn't
>>>>>> find anything.
>>>>>>
>>>>>> Does anyone has any advise?
>>>>>>
>>>>>> Thank you and best regards
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133175.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133710.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JMS transaction and delayed retry
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, there is. The problem with the redelivery is not really in
ServiceMix, but in ActiveMQ. The redelivery mechanism works on the
client side for a given consumer. So the key for the redelivery to
work as expected is to always use the same consumer and not close it.
It should work if you use the <jms:consumer /> endpoint with a
cacheLevel="3" which should ensure the consumer is reused and not
closed each time. It will also enhance the overall throughput on the
JMS side.
On Thu, Oct 23, 2008 at 5:17 PM, pwanner <pw...@pwanner.com> wrote:
>
> I tried with the xa tm and it works fine for now.
> To manage a fault on the JBI exchange would you use a robust MEP?
> I insist on this point as I can't afford to loose any message!
> You said "the JMS message will be redelivered later" but in fact it's
> immediately, I mean with no delay, isn't it? Is it a way to set a redelivery
> interval to avoid the WS to be called 10 times per second with the same
> message whereas the service is not available for a while?
>
>
> gnodet wrote:
>>
>> In your case, XA is fine because there will be no two-phase commits
>> and no tx logs.
>> We're using the transaction manager from jenks (which delegates to the
>> geronimo tx mgr).
>> You can find the code at:
>>
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/
>>
>> For the redelivery stuff, if the JBI exchange is in an ERROR state
>> (for example because the web service was not available and the
>> connection failed), the transaction will be rolled back and the JMS
>> message will be redelivered later. A fault on the JBI exchange won't
>> cause a rollback because faults are considered in a different way.
>>
>> On Thu, Oct 23, 2008 at 4:27 PM, pwanner <pw...@pwanner.com> wrote:
>>>
>>> The point about not using an XA transaction was to avoid the slow
>>> two-phase
>>> commit, as the throughput is a real concern.
>>> But also to avoid to have an other transaction manager with tx logs to
>>> configure and monitor. By the way, witch transaction manager are you
>>> talking
>>> about in the scenario you described? The jenks one?
>>> Anything about the recovery delay if the WS is down or generate a fault
>>> and
>>> the message is rolledback?
>>>
>>> Regards
>>> Philippe Wanner
>>>
>>>
>>> gnodet wrote:
>>>>
>>>> Why not using XA transactions ? The transaction manager is optimized
>>>> so that if there is only a single transacted resource (which would be
>>>> the case, as only the JMS connection factory would be used), it will
>>>> bypass the two-phase commit and simply commit the underlying JMS
>>>> transaction. In such a case, nothing is written to disk or whatever,
>>>> so there is no overhead.
>>>> This use case using XA works fine in servicemix. It may be possible
>>>> to do the same with JMS transactions only, but this is not really
>>>> supported.
>>>>
>>>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I have an oportunity to introduce ServiceMix in my company, through
>>>>> this
>>>>> simple use case:
>>>>>
>>>>> 1. Read a message in a MQSeries queue
>>>>> 2. Call a websevice and pass it the message
>>>>> 3. Get back the message from the ws and post it in an other MQSeries
>>>>> queue
>>>>>
>>>>> But there are some constraints:
>>>>> - This has to be done under the same JMS transaction, so that if there
>>>>> is
>>>>> any problem calling the WS, the get from the first queue is rolled back
>>>>> and
>>>>> the message is not lost.
>>>>> - JMS transaction and NOT XA transaction.
>>>>> - If there is a problem calling the WS the retry has to be delayed (let
>>>>> say
>>>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>>>>
>>>>> This is very easy with standard Java code I don't know if this is
>>>>> possible
>>>>> with ServiceMix.
>>>>>
>>>>> I know that the jms:consumer has a transacted="jms" attribute but it
>>>>> seems
>>>>> to me that it's a transaction spanning just the get from the queue and
>>>>> the
>>>>> send to the NMR.
>>>>>
>>>>> I have already done the binding of the jms:consumer and the
>>>>> jms:provider
>>>>> with the MQSeries queue, bridged the call to the http:provider through
>>>>> an
>>>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>>>>> jms:provider), but for the JMS transaction and the delayed retry I
>>>>> didn't
>>>>> find anything.
>>>>>
>>>>> Does anyone has any advise?
>>>>>
>>>>> Thank you and best regards
>>>>> Philippe
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133175.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JMS transaction and delayed retry
Posted by pwanner <pw...@pwanner.com>.
I tried with the xa tm and it works fine for now.
To manage a fault on the JBI exchange would you use a robust MEP?
I insist on this point as I can't afford to loose any message!
You said "the JMS message will be redelivered later" but in fact it's
immediately, I mean with no delay, isn't it? Is it a way to set a redelivery
interval to avoid the WS to be called 10 times per second with the same
message whereas the service is not available for a while?
gnodet wrote:
>
> In your case, XA is fine because there will be no two-phase commits
> and no tx logs.
> We're using the transaction manager from jenks (which delegates to the
> geronimo tx mgr).
> You can find the code at:
>
> https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/
>
> For the redelivery stuff, if the JBI exchange is in an ERROR state
> (for example because the web service was not available and the
> connection failed), the transaction will be rolled back and the JMS
> message will be redelivered later. A fault on the JBI exchange won't
> cause a rollback because faults are considered in a different way.
>
> On Thu, Oct 23, 2008 at 4:27 PM, pwanner <pw...@pwanner.com> wrote:
>>
>> The point about not using an XA transaction was to avoid the slow
>> two-phase
>> commit, as the throughput is a real concern.
>> But also to avoid to have an other transaction manager with tx logs to
>> configure and monitor. By the way, witch transaction manager are you
>> talking
>> about in the scenario you described? The jenks one?
>> Anything about the recovery delay if the WS is down or generate a fault
>> and
>> the message is rolledback?
>>
>> Regards
>> Philippe Wanner
>>
>>
>> gnodet wrote:
>>>
>>> Why not using XA transactions ? The transaction manager is optimized
>>> so that if there is only a single transacted resource (which would be
>>> the case, as only the JMS connection factory would be used), it will
>>> bypass the two-phase commit and simply commit the underlying JMS
>>> transaction. In such a case, nothing is written to disk or whatever,
>>> so there is no overhead.
>>> This use case using XA works fine in servicemix. It may be possible
>>> to do the same with JMS transactions only, but this is not really
>>> supported.
>>>
>>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> I have an oportunity to introduce ServiceMix in my company, through
>>>> this
>>>> simple use case:
>>>>
>>>> 1. Read a message in a MQSeries queue
>>>> 2. Call a websevice and pass it the message
>>>> 3. Get back the message from the ws and post it in an other MQSeries
>>>> queue
>>>>
>>>> But there are some constraints:
>>>> - This has to be done under the same JMS transaction, so that if there
>>>> is
>>>> any problem calling the WS, the get from the first queue is rolled back
>>>> and
>>>> the message is not lost.
>>>> - JMS transaction and NOT XA transaction.
>>>> - If there is a problem calling the WS the retry has to be delayed (let
>>>> say
>>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>>>
>>>> This is very easy with standard Java code I don't know if this is
>>>> possible
>>>> with ServiceMix.
>>>>
>>>> I know that the jms:consumer has a transacted="jms" attribute but it
>>>> seems
>>>> to me that it's a transaction spanning just the get from the queue and
>>>> the
>>>> send to the NMR.
>>>>
>>>> I have already done the binding of the jms:consumer and the
>>>> jms:provider
>>>> with the MQSeries queue, bridged the call to the http:provider through
>>>> an
>>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>>>> jms:provider), but for the JMS transaction and the delayed retry I
>>>> didn't
>>>> find anything.
>>>>
>>>> Does anyone has any advise?
>>>>
>>>> Thank you and best regards
>>>> Philippe
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20133175.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JMS transaction and delayed retry
Posted by Guillaume Nodet <gn...@gmail.com>.
In your case, XA is fine because there will be no two-phase commits
and no tx logs.
We're using the transaction manager from jenks (which delegates to the
geronimo tx mgr).
You can find the code at:
https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/geronimo-transaction/
For the redelivery stuff, if the JBI exchange is in an ERROR state
(for example because the web service was not available and the
connection failed), the transaction will be rolled back and the JMS
message will be redelivered later. A fault on the JBI exchange won't
cause a rollback because faults are considered in a different way.
On Thu, Oct 23, 2008 at 4:27 PM, pwanner <pw...@pwanner.com> wrote:
>
> The point about not using an XA transaction was to avoid the slow two-phase
> commit, as the throughput is a real concern.
> But also to avoid to have an other transaction manager with tx logs to
> configure and monitor. By the way, witch transaction manager are you talking
> about in the scenario you described? The jenks one?
> Anything about the recovery delay if the WS is down or generate a fault and
> the message is rolledback?
>
> Regards
> Philippe Wanner
>
>
> gnodet wrote:
>>
>> Why not using XA transactions ? The transaction manager is optimized
>> so that if there is only a single transacted resource (which would be
>> the case, as only the JMS connection factory would be used), it will
>> bypass the two-phase commit and simply commit the underlying JMS
>> transaction. In such a case, nothing is written to disk or whatever,
>> so there is no overhead.
>> This use case using XA works fine in servicemix. It may be possible
>> to do the same with JMS transactions only, but this is not really
>> supported.
>>
>> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>>
>>> Hi everyone,
>>>
>>> I have an oportunity to introduce ServiceMix in my company, through this
>>> simple use case:
>>>
>>> 1. Read a message in a MQSeries queue
>>> 2. Call a websevice and pass it the message
>>> 3. Get back the message from the ws and post it in an other MQSeries
>>> queue
>>>
>>> But there are some constraints:
>>> - This has to be done under the same JMS transaction, so that if there is
>>> any problem calling the WS, the get from the first queue is rolled back
>>> and
>>> the message is not lost.
>>> - JMS transaction and NOT XA transaction.
>>> - If there is a problem calling the WS the retry has to be delayed (let
>>> say
>>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>>
>>> This is very easy with standard Java code I don't know if this is
>>> possible
>>> with ServiceMix.
>>>
>>> I know that the jms:consumer has a transacted="jms" attribute but it
>>> seems
>>> to me that it's a transaction spanning just the get from the queue and
>>> the
>>> send to the NMR.
>>>
>>> I have already done the binding of the jms:consumer and the jms:provider
>>> with the MQSeries queue, bridged the call to the http:provider through an
>>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>>> jms:provider), but for the JMS transaction and the delayed retry I didn't
>>> find anything.
>>>
>>> Does anyone has any advise?
>>>
>>> Thank you and best regards
>>> Philippe
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JMS transaction and delayed retry
Posted by pwanner <pw...@pwanner.com>.
The point about not using an XA transaction was to avoid the slow two-phase
commit, as the throughput is a real concern.
But also to avoid to have an other transaction manager with tx logs to
configure and monitor. By the way, witch transaction manager are you talking
about in the scenario you described? The jenks one?
Anything about the recovery delay if the WS is down or generate a fault and
the message is rolledback?
Regards
Philippe Wanner
gnodet wrote:
>
> Why not using XA transactions ? The transaction manager is optimized
> so that if there is only a single transacted resource (which would be
> the case, as only the JMS connection factory would be used), it will
> bypass the two-phase commit and simply commit the underlying JMS
> transaction. In such a case, nothing is written to disk or whatever,
> so there is no overhead.
> This use case using XA works fine in servicemix. It may be possible
> to do the same with JMS transactions only, but this is not really
> supported.
>
> On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>>
>> Hi everyone,
>>
>> I have an oportunity to introduce ServiceMix in my company, through this
>> simple use case:
>>
>> 1. Read a message in a MQSeries queue
>> 2. Call a websevice and pass it the message
>> 3. Get back the message from the ws and post it in an other MQSeries
>> queue
>>
>> But there are some constraints:
>> - This has to be done under the same JMS transaction, so that if there is
>> any problem calling the WS, the get from the first queue is rolled back
>> and
>> the message is not lost.
>> - JMS transaction and NOT XA transaction.
>> - If there is a problem calling the WS the retry has to be delayed (let
>> say
>> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>>
>> This is very easy with standard Java code I don't know if this is
>> possible
>> with ServiceMix.
>>
>> I know that the jms:consumer has a transacted="jms" attribute but it
>> seems
>> to me that it's a transaction spanning just the get from the queue and
>> the
>> send to the NMR.
>>
>> I have already done the binding of the jms:consumer and the jms:provider
>> with the MQSeries queue, bridged the call to the http:provider through an
>> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
>> jms:provider), but for the JMS transaction and the delayed retry I didn't
>> find anything.
>>
>> Does anyone has any advise?
>>
>> Thank you and best regards
>> Philippe
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
--
View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20132153.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: JMS transaction and delayed retry
Posted by Guillaume Nodet <gn...@gmail.com>.
Why not using XA transactions ? The transaction manager is optimized
so that if there is only a single transacted resource (which would be
the case, as only the JMS connection factory would be used), it will
bypass the two-phase commit and simply commit the underlying JMS
transaction. In such a case, nothing is written to disk or whatever,
so there is no overhead.
This use case using XA works fine in servicemix. It may be possible
to do the same with JMS transactions only, but this is not really
supported.
On Thu, Oct 23, 2008 at 3:29 PM, pwanner <pw...@pwanner.com> wrote:
>
> Hi everyone,
>
> I have an oportunity to introduce ServiceMix in my company, through this
> simple use case:
>
> 1. Read a message in a MQSeries queue
> 2. Call a websevice and pass it the message
> 3. Get back the message from the ws and post it in an other MQSeries queue
>
> But there are some constraints:
> - This has to be done under the same JMS transaction, so that if there is
> any problem calling the WS, the get from the first queue is rolled back and
> the message is not lost.
> - JMS transaction and NOT XA transaction.
> - If there is a problem calling the WS the retry has to be delayed (let say
> 30 sec) to ensure that we are not falling in a "mad" loop of retries.
>
> This is very easy with standard Java code I don't know if this is possible
> with ServiceMix.
>
> I know that the jms:consumer has a transacted="jms" attribute but it seems
> to me that it's a transaction spanning just the get from the queue and the
> send to the NMR.
>
> I have already done the binding of the jms:consumer and the jms:provider
> with the MQSeries queue, bridged the call to the http:provider through an
> eip:pipeline (jms:consumer -> eip:pipeline -> http:provider ->
> jms:provider), but for the JMS transaction and the delayed retry I didn't
> find anything.
>
> Does anyone has any advise?
>
> Thank you and best regards
> Philippe
>
>
>
>
> --
> View this message in context: http://www.nabble.com/JMS-transaction-and-delayed-retry-tp20130976p20130976.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com