tag:blogger.com,1999:blog-7911563994423957036.post3781184450899241048..comments2014-03-30T06:51:57.132+03:00Comments on Code tricks from Andrew Skiba: DelayQueueChannel for Spring IntegrationAndrew Skibahttp://www.blogger.com/profile/04482963509700477331noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-7911563994423957036.post-34284667298556874432009-07-10T12:16:57.844+03:002009-07-10T12:16:57.844+03:00Ok, I didn't look at the xsd.
Mark Fisher'...Ok, I didn't look at the xsd.<br />Mark Fisher's solution has advantage of allowing the use of any BlockingQueue implementation with a similar configuration complexity.Vincenthttps://www.blogger.com/profile/02695354431069183946noreply@blogger.comtag:blogger.com,1999:blog-7911563994423957036.post-80192688750704562152009-07-09T18:16:20.623+03:002009-07-09T18:16:20.623+03:00I just checked the trunk, and found task executor ...I just checked the trunk, and found task executor sub element in org.springframework.integration/src/main/resources/org/springframework/integration/config/xml/spring-integration-1.0.xsd<br /><br />So you can use Mark's code to set a delay executor on channel, and I would use this solution today. In no way it's worse than the solution I documented in this blog item, but it has advantage of being more standard from now on.Andrew Skibahttps://www.blogger.com/profile/04482963509700477331noreply@blogger.comtag:blogger.com,1999:blog-7911563994423957036.post-26575284439998295342009-07-09T17:09:19.241+03:002009-07-09T17:09:19.241+03:00Sorry for the ... delay.
I find the interceptor v...Sorry for the ... delay.<br /><br />I find the interceptor variant more difficult to configure, the delayed queue seems more intuitive to me.<br /><br />For the retry count I use a message header. A service activator handles failed message that arrives in the central error channel, adds or increments a retry count header value or discards messages to a dead letter channel (if the retry count is over the limit for instance) and finally sends the message to the retry channel. A router takes messages in the retry channel and routes them to the last channel before the message failure (the last channel value is configured with a header-enricher).<br /><br />I follow your discussion with Mark Fisher. He says that, in 1.0.3, channels will have a TaskExecutor reference option but I haven't seen anything yet in the SI sources trunk. Anyway, in a retry use case for which I want to delay message processing, again, the DelayQueue solution seems definitely more natural to me.<br /><br />VincentVincenthttps://www.blogger.com/profile/02695354431069183946noreply@blogger.comtag:blogger.com,1999:blog-7911563994423957036.post-20673744081868172692009-04-23T12:12:00.000+03:002009-04-23T12:12:00.000+03:00I'm glad it is useful. What variant do you prefer,...I'm glad it is useful. What variant do you prefer, the one on this page, or the interceptor? How do you count the retries in your application?Andrew Skibahttps://www.blogger.com/profile/04482963509700477331noreply@blogger.comtag:blogger.com,1999:blog-7911563994423957036.post-36134227332350947892009-04-23T11:54:00.000+03:002009-04-23T11:54:00.000+03:00Very useful as a 'retry channel', thanks.
VincentVery useful as a 'retry channel', thanks.<br />VincentVincenthttps://www.blogger.com/profile/02695354431069183946noreply@blogger.com