Re: [xmlblaster-devel] Why do xml-rpc sessions w/ callbacks time out?

[Marcel Ruff <mr at marcelruff.info>]

Brad Clements wrote:
> On 18 Aug 2004 at 14:23, Marcel Ruff wrote:
>
>
> > You are right, the pings don't prevent from session timeout during client
> > inactivity.
>
>
> Do you think this is the best behaviour?
>
> At least for my use case the callback is the only listening for published information. 
> Otherwise, it never makes any client requests.
>
> It seems strange to have to pump the client to keep it from timing out.

I don't know if it is the best default behavior, these are the supported cases:

1. The session timeout times out (configured with connect QoS):
   -> The client is disconnected and resources are reclaimed
   (Client activity respans the timer)

2. The callback ping fails
   a) dispatch/callback/retries = -1
      -> The server polls for the callback client
   b) dispatch/callback/retries = 0
      -> The client is disconnected and resources are reclaimed

In your case set connect QoS to:

  ...
  <session timeout='0'.../>
  <queue relating='callback'>
     <callback type='XMLRPC' retries='0'>
     ...

now your client needs no activity and if the client ever
fails the session is destroyed and server side resources are reclaimed.
No 'pump' needed.

The features are there, it's the question what is the default
behavior, and the answer is difficult and arbitrary.
We could add a refresh on each successful callback ping but
this would lead to one more configuration parameter without
gaining new functionality.

> --
>
> Regarding pyBlaster. I'm planning to rework this when my client can afford the time. I would 
> like to re-examine the threaded tcp server/threadedxmlrpc server architecture. I note that it 
> does *not* work with python2.3 xmlrpclib.py, you have to use the supplied xmlrpclib.py which 
> appears to be from python 2.2
>
> Are there any more notes about the architectural design decisions made during pyBlaster's 
> development? I've read the source notes, which mostly describe the implementation itself, 
> not *why* it was done that way.
>
> Also, it would be nice to have several different server archictures supported, like straight 
> asyncore and twisted. I'll chip away at these over the next few months unless my project 
> gets cancelled.

pyBlaster was donated by Peter Arwanitis,
probably he can shed some light on it,

regards

Marcel

--
http://www.xmlBlaster.org