[
https://issues.apache.org/jira/browse/AMQ-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063493#comment-13063493
]
Stirling Chow commented on AMQ-3014:
------------------------------------
The unit test is failing because Broker.addBroker(...) is no longer being
called when the bridge processing a remote BrokerInfo command. The test was
relying on addBroker(...) to verify that the broker ID had been set.
The removal occurred in TransportConnection#processBrokerInfo(...) as part of
this changeset:
Revision: 1058577
Author: gtully
Date: 6:18:14 AM, January 13, 2011
Message:
https://issues.apache.org/jira/browse/AMQ-3077 -
ArraysIndexOutOfBoundsException : -32768 in "BrokerService[xxx] Task" thread -
brokerInfo and peerBroker infro explosion problems. A peer is a oneway
relationship with networks, broker infos were being accumulated in duplicate
for each connector and for multiple connectors. The peer broker info was
maintained for each which caused the problem marshalling. re:
https://issues.apache.org/jira/browse/AMQ-2632 - the configuration is now
respected so it can be selectively enabled and rebalance only occurs if we
randomly choose an alternative. The nested peer broker info is not propagated
in a connection control
----
Modified :
/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/network/DemandForwardingBridgeSupport.java
Modified :
/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/TransportConnection.java
Modified :
/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/region/RegionBroker.java
Modified :
/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/command/BrokerInfo.java
Modified :
/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/failover/FailoverTransport.java
Modified :
/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/transport/failover/FailoverClusterTest.java
Modified :
/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/JmsMultipleBrokersTestSupport.java
Added :
/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/usecases/NetworkOfTwentyBrokersTest.java
> DemandForwardingBridgeSupport can send BrokerInfo to remote transport before
> local broker ID is known.
> ------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3014
> URL: https://issues.apache.org/jira/browse/AMQ-3014
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Transport
> Affects Versions: 5.4.1
> Reporter: Stirling Chow
> Attachments: NullBrokerIdTest.java, patch.txt
>
>
> Symptom
> ========
> We have a production system that involves a set of Brokers connected in a
> demand-forwarding Network-of-Brokers using HTTP-based bridges. Each Broker
> periodically scans its list of peer brokers by iterating over
> RegionBroker.getPeerBrokerInfos:
> public synchronized BrokerInfo[] getPeerBrokerInfos() {
> BrokerInfo[] result = new BrokerInfo[brokerInfos.size()];
> result = brokerInfos.toArray(result);
> return result;
> }
> This scanning code assumes that BrokerInfo.getBrokerId() is always non-null
> (since every broker should have an ID). However, we periodically noticed
> that BrokerInfo.getBrokerId() returned a NULL value, which was very
> unexpected.
> Cause
> ======
> We analyzed the DemandForwardingBridgeSupport and noticed that when the
> remote bridge/transport is started, it sends the local Broker's ID:
> protected void startRemoteBridge() throws Exception {
> ...
> brokerInfo.setBrokerId(this.localBrokerId);
> remoteBroker.oneway(brokerInfo);
> }
> The local Broker's ID is not initially known until it is received from the
> local transport and processed by
> DemandForwardingBridge.serviceLocalBrokerInfo(...):
> protected void serviceLocalBrokerInfo(Command command) throws
> InterruptedException {
> synchronized (brokerInfoMutex) {
> localBrokerId = ((BrokerInfo)command).getBrokerId();
> localBrokerPath[0] = localBrokerId;
> localBrokerIdKnownLatch.countDown();
> The local Broker's ID is dispatched asynchronously when the local transport
> is started, as seen in TransportConnection.start():
> public void start() throws Exception {
> starting = true;
> try {
> synchronized (this) {
> if (taskRunnerFactory != null) {
> taskRunner = taskRunnerFactory.createTaskRunner(this,
> "ActiveMQ Connection Dispatcher: "
> + getRemoteAddress());
> } else {
> taskRunner = null;
> }
> transport.start();
> active = true;
> dispatchAsync(connector.getBrokerInfo());
> Because of the asynchronous dispatch, the remote bridge may be started before
> the local Broker's ID is known. This would be particularly evident when the
> local broker is under load processing a lot of tasks.
> We've attached a unit test that demonstrates how a slow asynchronous dispatch
> on the local transport can cause the remote transport to transmit a null
> BrokerId.
> Solution
> ======
> DemandForwardingBridgeSupport already contains a localBrokerIdKnownLatch, so
> starting the remote transport should wait for this latch before accessing the
> local Broker's ID (see patch).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
