-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
3 changed files
with
52 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4f65a94
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @CodeSmell i'm using this policy to detect availability of a web service and stop route for some time, but before onExchangeDone called error handler moves the current message to dead letter queue. I want to avoid putting messages to DLQ for specific situation which can be handled using ThrottlingExceptionRoutePolicy.
Is it possible with ThrottlingExceptionRoutePolicy not to put current message to DLQ where ThrottlingExceptionRoutePolicy needs to take action.
4f65a94
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@codecracker2014
Based on the question I assume you are consuming from a JMS queue/topic and then calling a web service. If that is the case, this policy/circuit breaker would detect failures calling the web service and then stop consuming from the endpoint once the configurable threshold was met.
Any messages that are consumed from the queue/topic will be rolled back (assuming that there is a transaction) when the exception is thrown calling the failing web service. The exception will be counted by the policy. This policy/circuit breaker, once opened, will minimize the number of messages that go on the DLQ. However, the handling of the message that is rolled back will be determined by the JMS broker. If it is configured to move messages to a DLQ on rollback there is nothing the policy can do to stop that.
Given this scenario, I recommend implementing the
ThrottingExceptionHalfOpenHandler
to check on the web service rather than rely on the default behavior of resuming the route during the half open state. Any messages consumed during this check will also go to the DLQ.PS: probably best to ask the question in one place :)
4f65a94
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CodeSmell
Ok i can configure camel to handle on going message, but in case of concurrent consumers of source queue all the on going exchanges are getting failed on stop of route as below. Can this be handled in ThrottlingExceptionRoutePolicy
Log:
EventDrivenConsumerRoute[activemq://smsqueue -> Channel[TransactionErrorHandler:PROPAGATION_REQUIRES_NEW[Pipeline[[Channel[BeanProcessor[com.nucleus.integration.ws.server.sms.route.AfterQueueProcessor(0x50c7d3e5)]], Channel[SetHeader(CamelHttpMethod, POST)], Channel[SetHeader(Content-Type, application/json)], Channel[sendTo(http://localhost:8080/camel-hello-1.0.0/newOrder?quantity=1&orderId=dd&productName=bb)]]]]]] 15:54:02.088 [Camel (neutrinoCoreIntegrationCamelContext) thread #1 - JmsConsumer[smsqueue]] WARN o.a.c.c.j.DefaultJmsMessageListenerContainer - Rejecting received message because of the listener container having been stopped in the meantime: ActiveMQBytesMessage {commandId = 53892, responseRequired = false, messageId = ID:NB1053-30288-1516615103332-1:21:17:1:2, originalDestination = null, originalTransactionId = null, producerId = ID:NB1053-30288-1516615103332-1:21:17:1, destination = queue://smsqueue, transactionId = TX:ID:NB1053-30288-1516615103332-1:21:62, expiration = 0, timestamp = 1516616473191, arrival = 0, brokerInTime = 1516616473191, brokerOutTime = 1516616642088, correlationId = null, replyTo = null, persistent = true, type = null, priority = 4, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = false, userID = null, content = org.apache.activemq.util.ByteSequence@2b248ddd, marshalledProperties = org.apache.activemq.util.ByteSequence@6ba45c21, dataStructure = null, redeliveryCounter = 0, size = 0, properties = {breadcrumbId=ID-NB1053-30286-1516615089364-0-95}, readOnlyProperties = true, readOnlyBody = true, droppable = false} ActiveMQBytesMessage{ bytesOut = null, dataOut = null, dataIn = null }
4f65a94
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that if the circuit is being opened that the web service is failing and that all in-flight messages would fail. If there is a way to handle these consumed messages in a way that does not involve a rollback you may want to consider the Camel/Hystrix circuit breaker. Here each message is processed via fallback option instead of rolled back.