Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <17098761.19841284828246131.JavaMail.jira@thor>
Date: Sat, 18 Sep 2010 12:44:06 -0400 (EDT)
From: "Bruce Snyder (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-2775) Race condition in
 org.apache.activemq.util.osgi.Activator
In-Reply-To: <27162793.13481276280212398.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/activemq/browse/AMQ-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Snyder updated AMQ-2775:
------------------------------

    Fix Version/s: 5.5.0
                       (was: 5.4.1)

> Race condition in org.apache.activemq.util.osgi.Activator
> ---------------------------------------------------------
>
>                 Key: AMQ-2775
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2775
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.3.2
>            Reporter: Michael Pilquist
>             Fix For: 5.5.0
>
>
> There's a race condition between start and create methods of Activator.  If a bundle that was started before activemq-core does something that causes a call to Activator.create, and Activator.start is still scanning bundles for contributed service files, an IOException results.
> In practice, this occurred after upgrading from 5.3.0 to 5.3.2 because another bundle at the same start level as activemq-core programmatically instantiated a broker from a different thread.  The activemq-core activator was still scanning the installed bundles and hadn't gotten to itself yet, so the result was a failure to instantiate the tcp handler.
> Making start/create/stop synchronized would fix this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.