You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Nate M (JIRA)" <ji...@apache.org> on 2014/05/16 13:23:06 UTC

[jira] [Comment Edited] (AMQ-5161) NullPointerException during async startup

    [ https://issues.apache.org/jira/browse/AMQ-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998577#comment-13998577 ] 

Nate M edited comment on AMQ-5161 at 5/15/14 8:30 AM:
------------------------------------------------------

If I'm reading it correctly (for which there is a high probability that I'm not), the current check to see if the broker has started in the VMTransportFactory's lookupBroker method are bypassed during async startup, because as Timothy mentioned, the broker is registered just as the broker startup, and before initialization of key references, begins. Consequently, the incoming VM transport will not wait for the specified period of time nor wait until the broker is started to proceed with initiating the connection. 
{code}
            broker = registry.lookup(brokerName);
            if (broker == null && waitForStart > 0) {
                final long expiry = System.currentTimeMillis() + waitForStart;
                while ((broker == null || !broker.isStarted()) && expiry > System.currentTimeMillis()) {
{code}
It appears that perhaps 1) the broker registration in the registry should somehow be postponed until the end of the async startup, 2) the required broker references should be initialized before the async startup begins a version of which is done in James' workaround, or 3) the broker.isStarted() check can always be required in the lookupBroker method, not just when the broker can't yet be found in the registry.

Incidentally, I saw a comment on an old ticket saying, "Brokers agains start synchronously by default, which is needed for vm transport embedded case"  (https://issues.apache.org/jira/browse/AMQ-3696). 


was (Author: ndmar):
If I'm reading it correctly (for which there is a high probability that I'm not), the current check to see if the broker has started in the VMTransportFactory's lookupBroker method are bypassed during async startup, because as Timothy mentioned, the broker is registered just as the broker startup, and before initialization of key references, begins. Consequently, the incoming VM transport will not wait for the specified period of time nor wait until the broker is started to proceed with initiating the connection. 
{quote}
            broker = registry.lookup(brokerName);
            if (broker == null && waitForStart > 0) {
                final long expiry = System.currentTimeMillis() + waitForStart;
                while ((broker == null || !broker.isStarted()) && expiry > System.currentTimeMillis()) {
{quote}
It appears that perhaps 1) the broker registration in the registry should somehow be postponed until the end of the async startup, 2) the required broker references should be initialized before the async startup begins a version of which is done in James' workaround, or 3) the broker.isStarted() check can always be required in the lookupBroker method, not just when the broker can't yet be found in the registry.

Incidentally, I saw a comment on an old ticket saying, "Brokers agains start synchronously by default, which is needed for vm transport embedded case"  (https://issues.apache.org/jira/browse/AMQ-3696). 

> NullPointerException during async startup
> -----------------------------------------
>
>                 Key: AMQ-5161
>                 URL: https://issues.apache.org/jira/browse/AMQ-5161
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.1
>            Reporter: james
>         Attachments: QueueService2Test.java
>
>
> I'm using an embedded broker with asynchronous startup enabled.  My setup worked using 5.9.0.  When i upgraded to 5.9.1, i started getting this exception on startup:
> {noformat}
> javax.jms.JMSException: java.lang.NullPointerException
>   at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
>   at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1408)
>   at org.apache.activemq.ActiveMQConnection.ensureConnectionInfoSent(ActiveMQConnection.java:1513)
>   at org.apache.activemq.ActiveMQConnection.setClientID(ActiveMQConnection.java:417)
>   at <...internal system startup stack trace...>
> Caused by: java.lang.NullPointerException
>   at org.apache.activemq.broker.jmx.ManagedRegionBroker.addConnection(ManagedRegionBroker.java:232)
>   at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
>   at org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:91)
>   at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
>   at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
>   at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:92)
>   at org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:97)
>   at org.apache.activemq.broker.TransportConnection.processAddConnection(TransportConnection.java:759)
>   at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:139)
>   at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:291)
>   at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:145)
>   at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
>   at org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
>   at org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:247)
>   at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
>   at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
>   at java.lang.Thread.run(Thread.java:662)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)