camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen">
Subject RE: Stopping a consumer on failure
Date Tue, 23 Sep 2008 09:36:05 GMT

Otherwise you could also use scheduled polling instead of event driven when consuming messages
of the queue.

In the scheduled poller you could determine if you should try to consume messages from the
queue or NOT and then sleep until next poll.

Med venlig hilsen
Claus Ibsen
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576

-----Original Message-----
From: Martin Gilday [] 
Sent: 23. september 2008 11:19
Subject: Stopping a consumer on failure


I am in the process of writing a consumer from an ActiveMQ queue which
is consumed from using the Bean component (a Spring @Service).  This
bean then interacts with a 3rd party's API over HTTP.  In the current
legacy system the items to send are stored in a database table and a
Quartz job runs every x minutes, if an error occurs such as the endpoint
being down (as it frequently is) then the row in the database is updated
with a failed flag for each one that fails.  Then an email is sent to a
support agent.  When the system is known to be back up then we update
all the items in the database with failed=1 and they get processed.  Now
we are moving to JMS I am starting to think about what we should do when
the 3rd party is down.  I'd like it so that after x number of failures
the Bean component is paused so that the queue simply builds up.  Then
when we know that it is back up we can just unpause the consumer again. 
While looking for a way to do this I found and the related
nabble link. This states that at that time there was no easy programatic
way of pausing a route.  Is this still true? Are there any alternative
strategies to deal with this situation?  As I am not using the HTTP
component (I think I probably could but I'm still determining if it can
cope with the 3rd party's API) then I would have to forward my messages
to a dead letter channel myself.  I'd still much prefer to stop the
consuming of messages when a possible long term fault is identified,
rather than send hundreds/thousands of messages around a pointless loop.
Any ideas?


View raw message