-
1. Re: Automatic retry mechanism
marklittle Jan 11, 2008 7:35 AM (in response to stlecho)I would expect the RDLVQ capability to kick-in here, but haven't checked the WS integration code. Maybe TomF can comment?
-
2. Re: Automatic retry mechanism
tfennelly Jan 11, 2008 7:57 AM (in response to stlecho)At present it just fails the pipeline (fairly sure of that) and I don't think the pipeline processor sends the failed message to the RDLVQ??
AFAIK, the RDLVQ capability we have only applies to message aware deliveries via the ServiceInvoker. Kurt? -
3. Re: Automatic retry mechanism
kconner Jan 11, 2008 8:11 AM (in response to stlecho)This is correct, the pipeline handles an error by sending a fault to the caller or by storing the message in the DeadLetterService. The caller can then choose to resend if appropriate.
Only the service invoker handles retransmission. -
4. Re: Automatic retry mechanism
sm0k3rz Nov 5, 2008 11:28 AM (in response to stlecho)Hi,
two years have passed from this post and I would like to know if the retry mechanism has been implemented.
In Our application we need a client web service that when it was posted try n times until back on the web sevices server.
Because is it important consecutio tempore in our application.
Regard.
Davide. -
5. Re: Automatic retry mechanism
beve Nov 6, 2008 12:23 AM (in response to stlecho)Hi,
not sure if you have seen the jms_transacted quickstart?
I think that this might work for you as I think it would have worked for the original post in this thread, had it been available.
Regards,
/Daniel -
6. Re: Automatic retry mechanism
sm0k3rz Nov 6, 2008 5:01 AM (in response to stlecho)Thanks for the answer.
Is there a way you can postpone infinite number of times the message, at least until the error, typically an I / O network, is resolved? -
7. Re: Automatic retry mechanism
beve Nov 6, 2008 10:23 AM (in response to stlecho)Is there a way you can postpone infinite number of times the message, at least until the error, typically an I / O network, is resolved?
I'm not sure, but you can set MaxDeliveryAttempts in jbm-queue-service.xml to a large number. Setting it to -1 will cause this value to be taken from the DefaultMaxDeliveryAttempts specified in messaging-service.xml.
It is not clear to me if you can specify a value of -1 for this. If that is possible then it should retry forever.
For more information about the configuration options for JBoss Messaging take a look at thier user guide:
http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.SP3/html/index.html
Regards,
/Daniel