Return-Path: X-Original-To: apmail-activemq-issues-archive@minotaur.apache.org Delivered-To: apmail-activemq-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C21B119F1A for ; Mon, 11 Apr 2016 13:33:25 +0000 (UTC) Received: (qmail 92120 invoked by uid 500); 11 Apr 2016 13:33:25 -0000 Delivered-To: apmail-activemq-issues-archive@activemq.apache.org Received: (qmail 92087 invoked by uid 500); 11 Apr 2016 13:33:25 -0000 Mailing-List: contact issues-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list issues@activemq.apache.org Received: (qmail 92059 invoked by uid 99); 11 Apr 2016 13:33:25 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Apr 2016 13:33:25 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 88C912C14F7 for ; Mon, 11 Apr 2016 13:33:25 +0000 (UTC) Date: Mon, 11 Apr 2016 13:33:25 +0000 (UTC) From: "Gary Tully (JIRA)" To: issues@activemq.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (AMQ-6240) Producer cannot be terminated when slow consumer is detected MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/AMQ-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15235093#comment-15235093 ] Gary Tully commented on AMQ-6240: --------------------------------- I am not sure. It is a bit of an anti pattern, the whole send timeout. Really the connection should close, because the sync send state is unknown. In this case the transaction blocks the close so it may make sense to use rollback(timeout) in the close case, because the socket will close and the broker side transaction will rollback. Note the transaction rollback used to be async before: https://issues.apache.org/jira/browse/AMQ-2364 having a timeout would be similar, but I guess so long as we always close it would be ok. I see an interesting angle in https://issues.apache.org/jira/browse/AMQ-1517 where the broker side blocking is limited by the message time to live. That would make a deterministic failure scenario. Message expired while pending space for send. That would leave the broker side active to respond to a close. Do you use messageExpiry or would it be a valid alternative? > Producer cannot be terminated when slow consumer is detected > ------------------------------------------------------------ > > Key: AMQ-6240 > URL: https://issues.apache.org/jira/browse/AMQ-6240 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Affects Versions: 5.13.2 > Environment: The test was run using an out of the box install of ActiveMQ 5.13.2 on Windows 7 Professional (64 bit). > The java version used was jdk1.8.0_60 > Reporter: Ken Hall > Attachments: brokertd.zip > > > There is a discussion relating to the bug here - http://activemq.2283324.n4.nabble.com/Force-Producer-to-fail-when-blocked-by-slow-consumer-td4710264.html. Test code to reproduce the problem has also been uploaded to this discussion. > We have a situation where we have a producer which is feeding a slow consumer. > The consumer belongs to a third party so we do not have control over the broker configuration. > We would like to terminate our producer but we find that we cannot do so. We can set the timeout on the connection and we then trap the timeout exception. The problem is that when we try to close the session it attempts to rollback but cannot do so as the rollback blocks. > We have created a small test that is included in the zip (mentioned above) of an Eclipse project.The zip includes three classes. Call the main method of RunTest to run the test. The activemq.xml used is in the root directory of the project. > The program will timeout after 51 messages and attempt to close the session. > It eventually locks in this line: > this.connection.syncSendPacket(info); > in the rollback method of the TransactionContext class. > We believe that the most sensible solution to this is that the rollback should respond to the same timeout as the connection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)