[
https://issues.apache.org/jira/browse/AMQ-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417003#comment-13417003
]
Ron Koerner edited comment on AMQ-3887 at 7/18/12 11:37 AM:
------------------------------------------------------------
I tried, but it seems the problem only manifests in a live system.
Anyway, I think it is a race condition introduced by the following facts
* {{DemandForwardingBridgeSupport.start}}
** synchronously connects the {{local/remoteBroker}} Transports to
{{serviceLocal/RemoteCommand}}
** asynchronously runs {{startRemoteBride}}
* someone sends a messageDispatch command to {{localBroker}} (whenever, maybe
even before DFBS.start)
* [BrokerService[smcufs02] Task-147] delivers the message after
{{DemandForwardingBridgeSupport.start}}
** to {{DemandForwardingBridgeSupport.serviceLocalCommand}}
** which calls {{configureMessage}} which uses {{producerInfo}} which is not
yet set
** and {{startLocalBridge}} may not even be started yet
* {{startRemoteBridge}}
** eventually creates {{producerInfo}}
I don't think {{serviceLocalCommand}} should handle message dispatches before
the bridge is completely started. Therefore a {{waitStarted()}} after {{if
(command.isMessageDispatch())}} in {{serviceLocalCommand}} should solve the
problem.
It is to note that {{serviceRemoteCommand}} already includes a
{{waitStarted()}} for message dispatches.
Maybe both methods should make a checked for {{disposed}} after waiting. They
do check at the beginning, but if {{waitStarted}} really blocks, that may
change in the meantime.
was (Author: ron.koerner):
I tried, but it seems the problem only manifests in a live system.
Anyway, I think it is a race condition introduced by the following facts
* {{DemandForwardingBridgeSupport.start}}
** synchronously connects the {{local/remoteBroker}} Transports to
{{serviceLocal/RemoteCommand}}
** asynchronously runs {{startRemoteBride}}
* someone sends a messageDispatch command to {{localBroker}} (whenever, maybe
even before DFBS.start)
* {{\[BrokerService[smcufs02] Task-147\] }} delivers the message after
{{DemandForwardingBridgeSupport.start}}
** to {{DemandForwardingBridgeSupport.serviceLocalCommand}}
** which calls {{configureMessage}} which uses {{producerInfo}} which is not
yet set
** and {{startLocalBridge}} may not even be started yet
* {{startRemoteBridge}}
** eventually creates {{producerInfo}}
I don't think {{serviceLocalCommand}} should handle message dispatches before
the bridge is completely started. Therefore a {{waitStarted()}} after {{if
(command.isMessageDispatch())}} in {{serviceLocalCommand}} should solve the
problem.
It is to note that {{serviceRemoteCommand}} already includes a
{{waitStarted()}} for message dispatches.
Maybe both methods should make a checked for {{disposed}} after waiting. They
do check at the beginning, but if {{waitStarted}} really blocks, that may
change in the meantime.
> 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: Timothy Bish
> 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
