I have exactly the same problem. I have many thousands of endpoints any number of which could be down. I need to be able to handle redelivery without blocking good messages.
Wondering if you came up with a workaround for this? Thanks, Steve. Claus Ibsen-2 wrote: > > Hi > > It depends on the situation but sometimes you could simply let it fail > and rollback to the source. > > But what you are looking for is currently not implemented in Camel. > Having its RedeliveryErrorHandler > support non blocking delays. > > This is something we will add in the future. I was hoping I got a > chance to work a bit on the internals > to make the Channel concept more flexible and to support having a > Queue which would allow you to send > the Exchange to that said queue and have the Channel poll the > Exchanges from the Queue. > Then all is needed is to use a DelayedQueue which then have a delay > value for the redelivery exchanges. > > The same concept could be implemented directly in > RedeliveryErrorHandler to get this implemented quicker. > > The caveat when doing this is that its a new thread which will > re-process the Exchange and thus you cannot do this > if you have transactions enabled. > > I will create a ticket in JIRA for this new feature. > > > On Mon, Apr 5, 2010 at 7:22 PM, Dragisa Krsmanovic <[email protected]> > wrote: >> Yes, but this only increases number of messages that are needed to >> "block" the route. What if I have thousands of messages and somewhere >> between 1 and 1000 can fail ? I don't want "good" messages to wait for >> "bad" messages to exhaust their retries. >> >> If I would set concurrentConsumers=2000 that can potentially spawn 2000 >> threads ? >> >> I tried a solution by sending bad messages to another, "waiting" route. >> But, although good messages are not blocked any more, I still have >> similar issue in the "waiting" route where I want to use delay. It can >> only delay number of messages that is equal to concurrentConsumers. So, >> "bad" messages at the end of the wait queue would wait, not delay() but >> (n/concurrentConsumers) * delay() amount of time. >> >> >> >> On Sat, 2010-04-03 at 10:10 +0800, Willem Jiang wrote: >>> Hi, >>> >>> Can you try to add this option "concurrentConsumers=5" into the seda >>> endpoint's URI? >>> By default there is only one thread to consumer the message in the >>> queue. >>> >>> Willem >>> >>> Dragisa Krsmanovic wrote: >>> > I have a route that is configured to re-deliver messages on exception. >>> > If there are messages in that queue and one of them fails, all other >>> > messages are blocked until all re-delivery attempts are exhausted. >>> > >>> > I would like other messages to go through while the ones that failed >>> are >>> > waiting for their re-delivery. Message order is not important. What is >>> a >>> > good way to do this ? >>> > >>> > >>> > The route I tested with looks like this: >>> > >>> > from("seda:start") >>> > .onException(Exception.class) >>> > .handled(true) >>> > .redeliverDelay(100) >>> > .maximumRedeliveries(1) >>> > .to("mock:error") >>> > .end() >>> > .process(new TestProcessor()) >>> > .to("mock:end"); >>> > >>> > >>> > >>> > >>> >> >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> This email is confidential to the intended recipient. If you have >> received it in error, please notify the sender and delete it from your >> system. Any unauthorized use, disclosure or copying is not permitted. The >> views or opinions presented are solely those of the sender and do >> not necessarily represent those of Public Library of Science unless >> otherwise specifically stated. Please note that neither Public Library >> of Science nor any of its agents accept any responsibility for any >> viruses that may be contained in this e-mail or its attachments and it >> is your responsibility to scan the e-mail and attachments (if any). >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > > -- View this message in context: http://old.nabble.com/Message-blocks-route-until-all-redelivery-attempts-are-exhausted-tp28123035p28667141.html Sent from the Camel - Users mailing list archive at Nabble.com.
