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 subversion and git services (Jira)" <ji...@apache.org> on 2024/05/01 17:54:00 UTC
[jira] [Commented] (ARTEMIS-4750) AMQP Large Message flow control to use runAfter
[ https://issues.apache.org/jira/browse/ARTEMIS-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842729#comment-17842729 ]
ASF subversion and git services commented on ARTEMIS-4750:
----------------------------------------------------------
Commit 14e83faa1bf5523d63755ec54f42cbc1d21affc6 in activemq-artemis's branch refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=14e83faa1b ]
ARTEMIS-4750 AMQP Large Message flow control to use runAfter
The resume delivery on AMQP Large Message Writer is using runNow.
When a flow control is paused and then resumed, the runNow will make the first read to happen inline to the thread that's resuming other deliveries.
It would be better to not run the delivery within the same call. Hence the change here is simple, being just using a connection.runLater instead of runNow.
I have seen this on a thread dump from a production server.
No semantic issues were encountered but there was a theory that the Netty thread responsible to resume would be busy with a delivery when not supposed to.
Better to be safe on this case.
> AMQP Large Message flow control to use runAfter
> -----------------------------------------------
>
> Key: ARTEMIS-4750
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4750
> Project: ActiveMQ Artemis
> Issue Type: Task
> Affects Versions: 2.33.0
> Reporter: Clebert Suconic
> Priority: Major
> Fix For: 2.34.0
>
>
> the resume delivery on AMQP Large Message Writer is using runNow.
> When a flow control is paused and then resumed, the runNow will make the first read to happen inline to the thread that's resuming other deliveries.
> It would be better to not run the delivery within the same call. Hence the change here is simple, being just using a connection.runLater instead of runNow.
> I have seen this on a thread dump from a production server.
> No semantic issues were encountered but there was a theory that the Netty thread responsible to resume would be busy with a delivery when not supposed to. Better to be safe on this case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)