[
https://issues.apache.org/jira/browse/AMQ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006996#comment-14006996
]
Enrico Musuruana edited comment on AMQ-5198 at 5/23/14 9:21 AM:
----------------------------------------------------------------
Hi Timothy,
I've attached a testcase that successfully hits the NPE when the
scheduler.start() method is delayed.
The first consumer enters the block and while it still has to perform the
start() the second will find the first if condition if (result == null) false,
hence it won't have the Timer object initialised and an exception is thrown.
I hope this explanation is clear enough
was (Author: malli):
Hi Timothy,
I've attached a testcase that successfully hits the NPE when the
scheduler.start() method is delayed.
> MessageConsumer and Producer are not thread safe
> ------------------------------------------------
>
> Key: AMQ-5198
> URL: https://issues.apache.org/jira/browse/AMQ-5198
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.9.0
> Reporter: Enrico Musuruana
> Attachments: ActiveMq.zip
>
>
> We currently have an object that acts both as a consumer and as a producer
> over the same queue.
> Lazy initialization of the scheduler is not 100% thread safe when a consumer
> and a producer are created sharing the same connection.
> We encountered the following sporadic NPE when a rollback() is invoked:
> Caused by: java.lang.NullPointerException
> at
> org.apache.activemq.thread.Scheduler.executeAfterDelay(Scheduler.java:64)
> at
> org.apache.activemq.ActiveMQMessageConsumer.rollback(ActiveMQMessageConsumer.java:1278)
> at
> org.apache.activemq.ActiveMQMessageConsumer$5.afterRollback(ActiveMQMessageConsumer.java:1054)
> at
> org.apache.activemq.TransactionContext.afterRollback(TransactionContext.java:157)
> ... 11 more
> We believe that the lazy initialized getScheduler() is open for a race
> condition when a publish and rollback are happening concurrently.
> try {
> result = scheduler = new
> Scheduler("ActiveMQConnection["+info.getConnectionId().getValue()+"]
> Scheduler");
> scheduler.start();
> } catch(Exception e) {
> throw JMSExceptionSupport.create(e);
> }
> The suggested fix is to simply invoke the start within the constructor of the
> Scheduler class.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
