From users-return-6068-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Thu Mar 22 17:33:27 2012 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B5C3C92CC for ; Thu, 22 Mar 2012 17:33:27 +0000 (UTC) Received: (qmail 71804 invoked by uid 500); 22 Mar 2012 17:33:27 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 71713 invoked by uid 500); 22 Mar 2012 17:33:27 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 71705 invoked by uid 99); 22 Mar 2012 17:33:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Mar 2012 17:33:27 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Mar 2012 17:33:19 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2MHWthN019194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Mar 2012 13:32:55 -0400 Received: from [10.3.224.144] (vpn-224-144.phx2.redhat.com [10.3.224.144]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2MHWsbK029369 for ; Thu, 22 Mar 2012 13:32:55 -0400 Message-ID: <4F6B6241.40800@redhat.com> Date: Thu, 22 Mar 2012 17:32:49 +0000 From: Gordon Sim Organization: Red Hat UK Ltd, Registered in England and Wales under Company Registration No. 3798903, Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parsons (USA), Charlie Peters (USA) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b1 Thunderbird/3.0.10 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Qpid destroys session after max queue size reached References: <77F42B4A75C8E94597470241D340426DC230146D@air.MATTER.LOCAL> <4F69D605.6060407@redhat.com> <4F6B35E7.2050403@redhat.com> <4F6B36CE.2030606@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Virus-Checked: Checked by ClamAV on apache.org On 03/22/2012 04:58 PM, Virgilio Fornazin wrote: > Gordon > > If I have the Sender Capacity to 1000 Messages per example, and the queue > has a limit of 800 Messages, and after I send 801 messages, the session is > closed after the > exception while trying to delivery the message to the queue. > > But the 800 messages sent previously are guaranteed to be delivered and > stay in queue, since they couldn't be acknowledged by the broker after the > session is terminated? > > How the API deals with this situation ? Not terribly well at present is the honest answer. This is something I would like to revisit. In the messaging API we could probably shield the application from the underlying loss of AMQP session, or at least ensure that their session object can continue to be used. All messages that the broker received before hitting the limit will be on the queue. If they were durable messages, they may not all have been written to disk, but the loss of session won't interfere with that. The problem is how the application can infer this from the messaging API. Generally you would use the unsettled count on the sender to determine how many of your sent messages remained in doubt. However that is only periodically updated so it often won't be up to date when a session error occurs. Again that is something we could change, and have the broker issue a completion before sending any exception and ending the session. I do have a JIRA open for this: https://issues.apache.org/jira/browse/QPID-3179, just need to get some time to work on it. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org