[
https://issues.apache.org/jira/browse/ARTEMIS-4476?focusedWorklogId=889759&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-889759
]
ASF GitHub Bot logged work on ARTEMIS-4476:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 09/Nov/23 16:12
Start Date: 09/Nov/23 16:12
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4656:
URL: https://github.com/apache/activemq-artemis/pull/4656#discussion_r1388233588
##########
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:
ah, I've totally misread it somehow...I was replying thinking it was just
making it optional, but it [clearly?!] wasnt there before. Ok, fair enough, it
was busted originally and is now intermittently less busted.
##########
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/connect/AMQPFederationQueuePolicyTest.java:
##########
@@ -937,6 +937,7 @@ public void
testUnhandledRemoteReceiverCloseConditionCausesConnectionRebuild() t
peer.waitForScriptToComplete(5, TimeUnit.SECONDS);
peer.expectDetach().optional(); // Broker is not consistent on
sending the detach
+ peer.expectClose().optional();
Review Comment:
Ditto
Issue Time Tracking
-------------------
Worklog Id: (was: 889759)
Time Spent: 3h 10m (was: 3h)
> 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 10m
> 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)
