activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james (JIRA)" <>
Subject [jira] [Commented] (AMQ-5118) Race condition with embedded broker asynchronous startup
Date Mon, 24 Mar 2014 19:56:43 GMT


james commented on AMQ-5118:

Note that i've found a workaround for now.  If i call BrokerService.getBroker() before calling
BrokerService.start(), the internal broker instance is created and assigned before the rest
of startup proceeds and there is no longer a race condition with the connection factory startup.
 During a normal BrokerService (asynchronous) startup, the Broker instance is not created
until after the persistence adapters are started.  I'm not sure what the implications of my
workaround are (creating the broker instance before the persistence adapters are started)
but everything seems to be working fine with this change in place.

Assuming that creating the broker instance earlier in the startup process is legitimate, maybe
the BrokerService could be changed to do that in the start() method before breaking off for
the rest of the asynchronous startup process.

> Race condition with embedded broker asynchronous startup
> --------------------------------------------------------
>                 Key: AMQ-5118
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: james
> We run activemq as an embedded broker using the asynchronous startup option.  After the
start async call returns, we create a vm connector with the extra options "?create=false&waitForStart=60000".
 There is a timing hole where the BrokerService has been registered with the BrokerRegistry
(and is found by the connection factory), but the member variable has
not yet been assigned (in fact, there may be some memory visibility issues here).  The VMTransportFactory
eventually generates a call to BrokerService.getBroker(), which (since broker == null) attempts
to create a broker instance.  This ultimately results in a JMX exception due to multiple instances
being registered (assuming you have jmx enabled).
> {noformat}
> javax.jms.JMSException: Could not create Transport. Reason: Status
MBean could not be registe
> red in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
>   at org.apache.activemq.util.JMSExceptionSupport.create(
>   at org.apache.activemq.ActiveMQConnectionFactory.createTransport(
>   at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(
>   at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(
>   at org.apache.activemq.ActiveMQConnectionFactory.createConnection(
>   at <internal stacktrace ommitted>
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
>   at java.util.concurrent.ThreadPoolExecutor$
>   at
> Caused by: Status MBean could not be registered in JMX: org.apache.activemq:type=Broker,brokerName=internal,service=Health
>   at org.apache.activemq.util.IOExceptionSupport.create(
>   at
>   at
>   at
>   at
>   at org.apache.activemq.transport.vm.VMTransportFactory.doCompositeConnect(
>   at org.apache.activemq.transport.vm.VMTransportFactory.doConnect(
>   at org.apache.activemq.transport.TransportFactory.connect(
>   at org.apache.activemq.ActiveMQConnectionFactory.createTransport(
>   ... 37 more
> Caused by: org.apache.activemq:type=Broker,brokerName=internal,service=Health
>   at com.sun.jmx.mbeanserver.Repository.addMBean(
>   at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(
>   at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(
>   at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(
>   at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(
>   at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(
>   at
>   at
>   at
>   ... 44 more
> {noformat}

This message was sent by Atlassian JIRA

View raw message