[
https://issues.apache.org/jira/browse/ARTEMIS-4476?focusedWorklogId=889757&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-889757
]
ASF GitHub Bot logged work on ARTEMIS-4476:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 09/Nov/23 16:08
Start Date: 09/Nov/23 16:08
Worklog Time Spent: 10m
Work Description: tabish121 commented on code in PR #4656:
URL: https://github.com/apache/activemq-artemis/pull/4656#discussion_r1388228370
##########
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:
Just quick note to say that it wasn't sending close before, and only
occasionally sending the detach. It seems now it sometimes sends both, and
sometimes not. Would be nice if it sent them both as a well behaved peer
should, but for clarity the original test omitted this as it was never found to
have been sent.
Issue Time Tracking
-------------------
Worklog Id: (was: 889757)
Time Spent: 3h (was: 2h 50m)
> 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: 3h
> 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)
