[ 
https://issues.apache.org/jira/browse/AMQ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017707#comment-14017707
 ] 

Timothy Bish commented on AMQ-5198:
-----------------------------------

Haven't had time to investigate as the test is quite large.  A simpler JUnit 
test case would be quicker to investigate otherwise this will have to wait.  In 
JMS land the Session is meant to be a single threaded resource to you can 
probably work around any issue here by giving each it's own Session instance. 

> 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)

Reply via email to