[
https://issues.apache.org/jira/browse/ARTEMIS-4476?focusedWorklogId=889737&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-889737
]
ASF GitHub Bot logged work on ARTEMIS-4476:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 09/Nov/23 14:19
Start Date: 09/Nov/23 14:19
Worklog Time Spent: 10m
Work Description: clebertsuconic commented on code in PR #4656:
URL: https://github.com/apache/activemq-artemis/pull/4656#discussion_r1388073741
##########
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/AMQPFederationConnectTest.java:
##########
@@ -219,6 +219,7 @@ public void
testFederationCreatesControlLinkAndClosesConnectionDetachIndicatesNo
.withNullTarget();
peer.remoteDetach().withErrorCondition("amqp:unauthorized-access",
"Not authroized").queue();
peer.expectDetach().optional();
+ peer.expectClose().optional();
Review Comment:
Moving to the Connection Failure to the Netty thread unveiled an issue with
Broker Connection. By the time I issue a failure, we won't wait the flush of
the connection.close to be sent to the client before we close it... we just
disconnect(). If you are writing a unit test like this.. the expect close
becomes optional. Fixing it would require some work, and it would be orthogonal
to this.
As for now, this is what I"m supposed to do with these tests.
Issue Time Tracking
-------------------
Worklog Id: (was: 889737)
Time Spent: 1h 50m (was: 1h 40m)
> Connection Failure Race Conditions in AMQP and Core
> ---------------------------------------------------
>
> Key: ARTEMIS-4476
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4476
> Project: ActiveMQ Artemis
> Issue Type: Task
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Failure Detection has a possibility to a race condition with the processing
> of the client packets (or frames in the case of AMQP).
> This is because Netty detects the failure and removes the connection objects
> while the packets are still processing things.
> I was not able to reproduce this particular issue, but I have seen a case
> from a memory dump where the consumer was created while the connection was
> already dropped, leaving the consumer isolated without any communication with
> clients.
> That particular case I could see a possibility because of these races.
> I am adding tests to exercise connection failure in stress and I was able to
> reproduce other issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
