Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of cctrieloff@redhat.com
 designates 66.187.237.31 as permitted sender)
Message-ID: <495ADF32.3090108@redhat.com>
Date: Tue, 30 Dec 2008 21:55:46 -0500
From: Carl Trieloff <cctrieloff@redhat.com>
Reply-To: cctrieloff@redhat.com
Organization: Red Hat
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Session Disconnects in Python - how to resolve
References: <alpine.LFD.2.00.0812301512490.22464@home-av-server.home-av>
In-Reply-To: <alpine.LFD.2.00.0812301512490.22464@home-av-server.home-av>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joshua Kramer wrote:
>
> Hello,
>
> If I do something 'funny' (defined below), the qpidd disconnects the 
> session.  What is the best way to handle this - is there a session 
> reconnect method, or do I create a new session?  Are the qpidd and 
> Python objects gracefully destroyed if I create a new session?


AMQP uses a disconnect to signal significant errors, this in general is 
good practice, as once you have had an error, it is better to pick back 
up from a well know point.

This can be done in two ways, create a new session, or re-attach.

Note that a session and all the related state will be destroyed when the 
session is terminated. The session gets terminated when it expires 
(time-out since last traffic) which can
be set from anything on 0 to infinity I believe.

So there are two patterns to choose from:
- set the session time-out to 0 and recreate what you need
- set the session time-out to something reasonable for your application 
and re-attach.

In both cases you need to work through through the logic to recreate the 
resources you need, if you want to deal with the case that the broker 
can be killed.


>
> Definition of 'funny':
>
> I am writing a server daemon in Python.  The daemon may be run a first 
> time, which means it needs to create a local queue on which to listen, 
> and then create a server queue to which the local queue can be 
> subscribed. The daemon may also be run again (on the same or a 
> different machine to provide additional threads servicing requests), 
> in which case it needs to create a local queue and subscribe to the 
> server queue.
>
> I am doing it in the manner:  I first create a local queue and 
> subscribe it to a server queue.  If I get a 
> qpid.session.SessionException, the server queue must not exist... so I 
> then create the server queue, create the local queue, and subscribe it 
> to the server queue.
>
> I did not account for the fact that the qpidd server disconnects the 
> session when it can't find the server queue.
>

why not just declare it regardless?

Carl.