You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by vlasmarias <vl...@hotmail.com> on 2012/10/08 20:21:18 UTC

After rollback, JMSConsumer is not freed up to process other messages?

I seem to be seeing something entirely unexpected - when my JmsConsumer
thread throw a SchedulerException, that JmsConsumer thread will not process
any new message until it has finished processing the original ActiveMQ
message. I was expecting that having a delay would mean that that
JmsConsumer thread will now be free to process another ActiveMQ message.

Here's my setup:

1) I have a whole slew of ActiveMQ messages in my queue.

2) I have the following camel configuration:

	<camel:camelContext>
		<camel:errorHandler id="defaultErrorHandler" type="DefaultErrorHandler">
			<camel:redeliveryPolicy maximumRedeliveries="90" redeliveryDelay="10000"
logStackTrace="false"/>
		</camel:errorHandler>
		
		<camel:route errorHandlerRef="defaultErrorHandler">
			<camel:from
uri="activemq:queue:actionRequestQueue?concurrentConsumers=15" />
			<camel:bean ref="actionRequestService" method="processActionRequest" />
		</camel:route>

3) In my processActionRequest code, I print the id's which uniquely identify
the ActiveMQ message and then throw a SchedulerException to force a
rollback:

        log.debug("finding QuartzNextfire by senId:" + senId);
	String errorMsg = "Not yet my turn. beacon_id=" + beaconId + " sen_id=" +
senId + " command=" + command;
	throw new SchedulerException(errorMsg);

4) What I see is that even though there are a lot of other ActiveMQ messes
to process, thread #1 keeps processing senId=13623 and thread # 2 keeps
processing senId=13622 until the maximumRedeliveries is reached:

$ grep "finding QuartzNextfire" scenario.log.2012-10-07-15 | more
2012-10-07 15:00:02,914 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:02,916 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:12,924 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:12,927 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:22,936 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:22,937 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:32,947 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue 
2012-10-07 15:00:32,948 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue 
(...)

How can I free up those JmsConsumer threads to process the other ActiveMQ
messages in the queue during the deliveryTimeout?

Thanks in advance.



--
View this message in context: http://activemq.2283324.n4.nabble.com/After-rollback-JMSConsumer-is-not-freed-up-to-process-other-messages-tp4657621.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: After rollback, JMSConsumer is not freed up to process other messages?

Posted by vlasmarias <vl...@hotmail.com>.
Thanks for the response. While that explains a lot, I'm confused as to why it
was implemented that way - i.e., trying to preserve the message order.
Firstly, if I have 10 JMS consumer threads and only 5 messages, there's a
great chance that the order will not get preserved anyways. Secondly, if
code is not written properly and exceptions are sometimes thrown, then
having JMS consumer threads get stuck reprocessing messages until
maxRedelivery is reached would seriously compromise scalability. Imho, it's
much better that the default behaviour is to just free up that JMS consumer
to process the next message.



--
View this message in context: http://activemq.2283324.n4.nabble.com/After-rollback-JMSConsumer-is-not-freed-up-to-process-other-messages-tp4657621p4657680.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: After rollback, JMSConsumer is not freed up to process other messages?

Posted by Gary Tully <ga...@gmail.com>.
that is expected. The intent is to preserver message order.

have a peek at the discussion and solutions (that allow order to be ignored) in:

https://issues.apache.org/jira/browse/AMQ-1853
https://issues.apache.org/jira/browse/AMQ-3894

Doco  at: http://activemq.apache.org/message-redelivery-and-dlq-handling.html

On 8 October 2012 19:21, vlasmarias <vl...@hotmail.com> wrote:
> I seem to be seeing something entirely unexpected - when my JmsConsumer
> thread throw a SchedulerException, that JmsConsumer thread will not process
> any new message until it has finished processing the original ActiveMQ
> message. I was expecting that having a delay would mean that that
> JmsConsumer thread will now be free to process another ActiveMQ message.
>
> Here's my setup:
>
> 1) I have a whole slew of ActiveMQ messages in my queue.
>
> 2) I have the following camel configuration:
>
>         <camel:camelContext>
>                 <camel:errorHandler id="defaultErrorHandler" type="DefaultErrorHandler">
>                         <camel:redeliveryPolicy maximumRedeliveries="90" redeliveryDelay="10000"
> logStackTrace="false"/>
>                 </camel:errorHandler>
>
>                 <camel:route errorHandlerRef="defaultErrorHandler">
>                         <camel:from
> uri="activemq:queue:actionRequestQueue?concurrentConsumers=15" />
>                         <camel:bean ref="actionRequestService" method="processActionRequest" />
>                 </camel:route>
>
> 3) In my processActionRequest code, I print the id's which uniquely identify
> the ActiveMQ message and then throw a SchedulerException to force a
> rollback:
>
>         log.debug("finding QuartzNextfire by senId:" + senId);
>         String errorMsg = "Not yet my turn. beacon_id=" + beaconId + " sen_id=" +
> senId + " command=" + command;
>         throw new SchedulerException(errorMsg);
>
> 4) What I see is that even though there are a lot of other ActiveMQ messes
> to process, thread #1 keeps processing senId=13623 and thread # 2 keeps
> processing senId=13622 until the maximumRedeliveries is reached:
>
> $ grep "finding QuartzNextfire" scenario.log.2012-10-07-15 | more
> 2012-10-07 15:00:02,914 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:02,916 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:12,924 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:12,927 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:22,936 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:22,937 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:32,947 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13623 Camel (camel-1) thread #1 - JmsConsumer[actionRequestQueue
> 2012-10-07 15:00:32,948 DEBUG [QuartzNextfireHome] finding QuartzNextfire by
> senId:13622 Camel (camel-1) thread #0 - JmsConsumer[actionRequestQueue
> (...)
>
> How can I free up those JmsConsumer threads to process the other ActiveMQ
> messages in the queue during the deliveryTimeout?
>
> Thanks in advance.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/After-rollback-JMSConsumer-is-not-freed-up-to-process-other-messages-tp4657621.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



-- 
http://redhat.com
http://blog.garytully.com