You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2014/07/18 16:13:04 UTC
[jira] [Resolved] (AMQ-5198) MessageConsumer and Producer are not
thread safe
[ https://issues.apache.org/jira/browse/AMQ-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQ-5198.
-------------------------------
Resolution: Fixed
Fix Version/s: 5.11.0
Fixed the assignment of the member variable to occur after the created scheduler is initialized so that the initialization doesn't allow the instance to escape the synchronized block.
> 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
> Fix For: 5.11.0
>
> 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)