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
