You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/06/15 19:32:00 UTC
[jira] [Commented] (ARTEMIS-1934) the broker sends duplicate AMQP
connection data in certain conditions
[ https://issues.apache.org/jira/browse/ARTEMIS-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514257#comment-16514257 ]
ASF GitHub Bot commented on ARTEMIS-1934:
-----------------------------------------
GitHub user gemmellr opened a pull request:
https://github.com/apache/activemq-artemis/pull/2144
ARTEMIS-1934: fix handling/accounting of sent AMQP connection data
Fix for https://issues.apache.org/jira/browse/ARTEMIS-1934 with some tests, plus improvements for the existing max frame size tests.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gemmellr/activemq-artemis ARTEMIS-1934
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2144.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2144
----
commit 9a3442f0bd29d77e02eca2f57b4e3adfec5b2f75
Author: Robbie Gemmell <ro...@...>
Date: 2018-06-15T19:27:28Z
ARTEMIS-1934: fix handling/accounting of sent amqp connection data
updates max frame size tests to verify behaviour seen with standalone
brokers rather than non represenative test-only conditions, as well
as more closely validate the recieved messages
----
> the broker sends duplicate AMQP connection data in certain conditions
> ---------------------------------------------------------------------
>
> Key: ARTEMIS-1934
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1934
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
> Affects Versions: 2.6.1
> Reporter: Robbie Gemmell
> Assignee: Robbie Gemmell
> Priority: Critical
> Fix For: 2.6.2
>
>
> The broker can write out some connection data twice in certain circumstances, corrupting the connection data, due to the way it handles the proton-j transport output and sending it out to Netty. It fails to 'pop' the correct amount of data from the proton transport that was actually transmitted, underaccounting the amount, which results in some of the data being sent a second time the next time output is generated and sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)