[
https://issues.apache.org/jira/browse/AMQ-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438598#comment-13438598
]
Ron Koerner commented on AMQ-3887:
----------------------------------
That seems to help.
Anyway, I think there is another lurking bug. When safeWaitUntilStarted()
returns because of disposed.get() is true it is the same as when it returns
because of the latch was unblocked.
Wherever safeWaitUntilStarted() is used should be a check afterwards whether
disposed.get() is true and act accordingly.
Otherwise, thanks for your help.
> Occasional Null Pointer Exception during NetworkConnector connection
> --------------------------------------------------------------------
>
> Key: AMQ-3887
> URL: https://issues.apache.org/jira/browse/AMQ-3887
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.6.0
> Environment: SLES 10
> Reporter: Ron Koerner
> Assignee: Gary Tully
> Fix For: 5.7.0
>
>
> While starting a duplex NetworkConnector an NPE can be observed on the
> receiving side.
> {code}
> 2012-06-18 17:34:24,571 INFO .DemandForwardingBridgeSupport - Network
> connection between vm://proxy-cbpi001#8 and tcp:///169.254.
> 0.5:59412(cbox-56BU101117) has been established. [StartLocalBridge:
> localBroker=vm://proxy-cbpi001#8]
> 2012-06-18 17:34:24,577 WARN .DemandForwardingBridgeSupport - Caught an
> exception processing local command [BrokerService[proxy-c
> bpi001] Task-19]
> java.lang.NullPointerException: null
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport.configureMessage(DemandForwardingBridgeSupport.java:644)
> ~[ac
> tivemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceLocalCommand(DemandForwardingBridgeSupport.java:675)
> ~
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.network.DemandForwardingBridgeSupport$1.onCommand(DemandForwardingBridgeSupport.java:139)
> [activemq
> -core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.vm.VMTransport.doDispatch(VMTransport.java:135)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.vm.VMTransport.dispatch(VMTransport.java:124)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:103)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:68)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:60)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.broker.TransportConnection.dispatch(TransportConnection.java:1307)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.broker.TransportConnection.processDispatch(TransportConnection.java:837)
> [activemq-core-5.6.0.jar:5
> .6.0]
> at
> org.apache.activemq.broker.TransportConnection.iterate(TransportConnection.java:872)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> [activemq-core-5.6.0.jar:5.6.0]
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> [activemq-core-5.6.0.jar:5.6.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source) [na:1.6.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.6.0_20]
> at java.lang.Thread.run(Unknown Source) [na:1.6.0_20]
> {code}
> The other broker will eventually connect, but with about a hundred of
> connecting brokers this occurs too often to ignore.
> As this seems to be a race condition it is quite difficult to reproduce
> reliably. I assume producerInfo is accessed in configureMessage before it is
> initialized in startRemoteBridge.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
