From users-return-6064-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Thu Mar 22 14:28:03 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 85F119722 for ; Thu, 22 Mar 2012 14:28:03 +0000 (UTC) Received: (qmail 54095 invoked by uid 500); 22 Mar 2012 14:28:03 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 54043 invoked by uid 500); 22 Mar 2012 14:28:03 -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 54032 invoked by uid 99); 22 Mar 2012 14:28:03 -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 14:28:03 +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 14:27:55 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2MERW4J017576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 22 Mar 2012 10:27:32 -0400 Received: from [10.3.224.116] (vpn-224-116.phx2.redhat.com [10.3.224.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2MERVon032213 for ; Thu, 22 Mar 2012 10:27:32 -0400 Message-ID: <4F6B36CE.2030606@redhat.com> Date: Thu, 22 Mar 2012 14:27:26 +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> In-Reply-To: <4F6B35E7.2050403@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Virus-Checked: Checked by ClamAV on apache.org On 03/22/2012 02:23 PM, Alan Conway wrote: > On 03/21/2012 09:22 AM, Gordon Sim wrote: >> On 03/20/2012 09:43 PM, Jeff Armstrong wrote: >>> I have a queue with REJECT policy and a max count. If I connect a >>> sender client and fill the queue to the max size, the broker seems to >>> destroy the session. Using qpid-tool I can see that the session is >>> gone, though the connection is still there. In the sender client >>> session.isValid() still returns true. If I then connect a receiving >>> client to drain the queues, the sender still fails to send messages >>> to the broker unless I close the session and re-open it. This seems >>> like really weird behaviour to have your session deleted because you >>> hit a max count and then not being able to tell from the sender that >>> this has happened. >> >> Yes, it is annoying. The AMQP 0-10 (and earlier) specification(s) >> state that >> when an 'exception' indication is sent on a session, the session must >> then be >> terminated. What you are seeing is that fact bubbling up to the API. >> >> The qpid::client::Session::isValid() at present only tests whether the >> 'handle' >> refers to an actual session object and doesn't take into account the >> state of >> that session. Again, I can see that is not intuitive. There isn't an >> ideal way >> to workaround that either. You can call flush() on the session which >> has minimal >> effect but would act as a test that it is active (you would need to >> catch an >> exception in the event that it was not). > > There are 2 methods to check if a session was terminated by an error: > /** > * @returns true if the session has been rendered invalid by some > * exception, false if it is valid for use. > */ > QPID_MESSAGING_EXTERN bool hasError(); > /** > * If the session has been rendered invalid by some exception, > * this method will result in that exception being thrown on > * calling this method. > */ > QPID_MESSAGING_EXTERN void checkError(); Unfortunately those are only available on qpid::messaging::Session, not the older qpid::client::Session. >> I would like to revise the general lifecycle of sessions in the case of >> exceptional conditions, but any change would almost certainly be in the >> messaging API only as the session abstraction there is not tied so >> directly to >> an AMQP 0-10 session. >> >> I could modify the qpid::client::Session::isValid() method or expose an >> additional method, in order to make testing full 'validity' simpler. >> Not sure >> how much value that would be to you however. > > isValid() is inherited from class Handle so I don't think we should put > additional semantics into it. > It's actually redundant since isNull() does the same test inverted and > is IMO more clearly named. Maybe we should deprecate isValid(). Again I think that is true for the messaging API, not the older 'client' API. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org