activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrico Musuruana (JIRA)" <>
Subject [jira] [Commented] (AMQ-5198) MessageConsumer and Producer are not thread safe
Date Tue, 24 Jun 2014 09:06:25 GMT


Enrico Musuruana commented on AMQ-5198:

Hi Timothy,

As I mentioned the problem is not related to the Session, but the Connection itself not being
thread safe. We currently make use of a single Session per thread.

We both agree that an 'in frequently triggered' race condition doesnt exactly lend itself
to a simple junit, but I believe that the test case I provided you with the actual patch should
be quite straight-forward to test.

> MessageConsumer and Producer are not thread safe
> ------------------------------------------------
>                 Key: AMQ-5198
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.9.0
>            Reporter: Enrico Musuruana
>         Attachments:
> We currently have an object that acts both as a consumer and as a producer over the same
> 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(
>         at org.apache.activemq.ActiveMQMessageConsumer.rollback(
>         at org.apache.activemq.ActiveMQMessageConsumer$5.afterRollback(
>         at org.apache.activemq.TransactionContext.afterRollback(
>         ... 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.start();
>                     } catch(Exception e) {
>                         throw JMSExceptionSupport.create(e);
>                     }
> The suggested fix is to simply invoke the start within the constructor of the Scheduler

This message was sent by Atlassian JIRA

View raw message