[
https://issues.apache.org/activemq/browse/AMQ-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60029#action_60029
]
Michael Pilquist commented on AMQ-2775:
---------------------------------------
Note that this can be worked around by ensuring the activemq-core bundle is
started before any bundles that attempt to use ActiveMQ. In my application,
this is easily accomplished by starting AMQ at a lower start level than the
bundles that use AMQ. This isn't always possible though, so I think it should
still be fixed in AMQ.
> 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
>
> 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.
