You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Martin Gilday <ma...@imap.cc> on 2008/09/23 11:18:31 UTC
Stopping a consumer on failure
Hi,
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
https://issues.apache.org/activemq/browse/CAMEL-868 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?
Thanks,
Martin.
RE: Stopping a consumer on failure
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
I am actually wondering if ActiveMQ could pause consumers? So you can send message to it, but it will not let any consumers get any messages?
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc]
Sent: 23. september 2008 11:19
To: camel-user@activemq.apache.org
Subject: Stopping a consumer on failure
Hi,
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
https://issues.apache.org/activemq/browse/CAMEL-868 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?
Thanks,
Martin.
RE: Stopping a consumer on failure
Posted by Claus Ibsen <ci...@silverbullet.dk>.
Hi
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
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: Martin Gilday [mailto:martin.lists@imap.cc]
Sent: 23. september 2008 11:19
To: camel-user@activemq.apache.org
Subject: Stopping a consumer on failure
Hi,
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
https://issues.apache.org/activemq/browse/CAMEL-868 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?
Thanks,
Martin.