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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
