[
https://issues.apache.org/jira/browse/ARTEMIS-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17224742#comment-17224742
]
Robbie Gemmell commented on ARTEMIS-2969:
-----------------------------------------
The latest change resolves the multiple-connections issue. The broker now
notices the connection get severed immediately, and reconnects with a single
connection.
It does keep executing the idle-timeout 'tick' handling for the old connection
however, at least (should be verified) until the brokers 60sec timeout is
reached, as the protocol trace shows heatbeat frames being generated for it
even after the new connection is in place. E.g here the broker was quickly
started, the peer severed, peer restarted. You can see it generated (and sent)
a heartbeat frame at the start, before the peer was severed (discussion
continued below):
{noformat}
2020-11-02 15:26:12,605 INFO [org.apache.activemq.artemis] AMQ241004: Artemis
Console available at http://localhost:8161/console
[489279171:0] -> Empty Frame
2020-11-02 15:26:17,024 INFO [org.apache.activemq.artemis.protocol.amqp.logger]
AMQ111002:
*******************************************************************************************************************************
Retrying Server AMQP Connection my-router on localhost:6000 retry 1 of -1
*******************************************************************************************************************************
[489279171:0] -> Empty Frame
[895280327:0] -> AMQP
[895280327:0] -> Open\{ containerId='0.0.0.0', hostname='null',
maxFrameSize=131072, channelMax=65535, idleTimeOut=30000, outgoingLocales=null,
incomingLocales=null, offeredCapabilities=null, desiredCapabilities=null,
properties={product=apache-activemq-artemis, version=2.17.0-SNAPSHOT}}
[895280327:0] -> Begin\{remoteChannel=null, nextOutgoingId=1,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=65535,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[895280327:0] ->
Attach\{name='myQueueName:c328451c-1d1f-11eb-8def-000c29e9f622', handle=0,
role=SENDER, sndSettleMode=UNSETTLED, rcvSettleMode=FIRST,
source=Source{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
target=Target\{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[qd.waypoint]}, unsettled=null, incompleteUnsettled=false,
initialDeliveryCount=0, maxMessageSize=null, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[895280327:0] ->
Attach\{name='myQueueName:c328451d-1d1f-11eb-8def-000c29e9f622', handle=1,
role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
filter=null, defaultOutcome=null, outcomes=null, capabilities=[qd.waypoint]},
target=Target\{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=null,
maxMessageSize=null, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[895280327:0] -> Flow\{nextIncomingId=null, incomingWindow=2147483647,
nextOutgoingId=1, outgoingWindow=2147483647, handle=1, deliveryCount=null,
linkCredit=1000, available=null, drain=false, echo=false, properties=null}
[895280327:0] <- AMQP
[895280327:0] <- Open\{ containerId='Standalone_iIfkOLGpUNrR7At',
hostname='null', maxFrameSize=16384, channelMax=32767, idleTimeOut=8000,
outgoingLocales=null, incomingLocales=null,
offeredCapabilities=[ANONYMOUS-RELAY, qd.streaming-links],
desiredCapabilities=[ANONYMOUS-RELAY, qd.streaming-links],
properties={product=qpid-dispatch-router, version=1.14.0, qd.conn-id=1}}
[895280327:0] <- Begin\{remoteChannel=0, nextOutgoingId=0,
incomingWindow=2147483647, outgoingWindow=2147483647, handleMax=4294967295,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
[895280327:0] <-
Attach\{name='myQueueName:c328451c-1d1f-11eb-8def-000c29e9f622', handle=0,
role=RECEIVER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
filter=null, defaultOutcome=null, outcomes=null, capabilities=null},
target=Target\{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null,
capabilities=[qd.waypoint]}, unsettled=null, incompleteUnsettled=false,
initialDeliveryCount=0, maxMessageSize=0, offeredCapabilities=null,
desiredCapabilities=null, properties=null}
[895280327:0] <-
Attach\{name='myQueueName:c328451d-1d1f-11eb-8def-000c29e9f622', handle=1,
role=SENDER, sndSettleMode=MIXED, rcvSettleMode=FIRST,
source=Source{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, distributionMode=null,
filter=null, defaultOutcome=null, outcomes=null, capabilities=[qd.waypoint]},
target=Target\{address='myQueueName', durable=NONE, expiryPolicy=SESSION_END,
timeout=0, dynamic=false, dynamicNodeProperties=null, capabilities=null},
unsettled=null, incompleteUnsettled=false, initialDeliveryCount=0,
maxMessageSize=0, offeredCapabilities=null, desiredCapabilities=null,
properties=null}
[489279171:0] -> Empty Frame
[895280327:0] -> Empty Frame
...
{noformat}
At the end you can see it is generating heartbeat trace for both the old
dropped connection ('sending' into the void) and the new replacement connection
(actually reeching the peer). After 60 seconds the old one will be treated as
having not received anything and exceeded its idle-timeout and result in
generating a Close frame:
{noformat}
[489279171:0] -> Close{error=Error{condition=amqp:resource-limit-exceeded,
description='local-idle-timeout expired', info=null}}
{noformat}
I'd guess the execution of its 'tick' processing will stop at this point, but
it should be verified, and it should be updated to stop when the connection is
originally dropped.
> broker doesnt handle server-connection being severed
> ----------------------------------------------------
>
> Key: ARTEMIS-2969
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2969
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.16.0
> Reporter: Robbie Gemmell
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.16.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The broker doesnt notice or handle a server-connection being severed / timing
> out.
> Start a broker, having instructed it to connect to a router (i.e 'peer'
> configuration). Stop the router (CTRL-C). Start the router again. Broker
> doesnt seem to notice the server-connection is gone and doesnt reconnect. It
> actually sits generating heartbeat frames until its 60sec actual-timeout is
> reached...at which point proton generates a close frame indicating the
> timeout. The broker still doesnt notice the connection is gone, and still
> doesnt reconnect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
