[Twisted-Python] Need Exception that will stop ther reactor within twistd

[Nicolas D. Cesar]

my apologies for the delayed answer, i've been very busy latelly.

El Martes, 28 de Noviembre de 2006 06:07, glyph at divmod.com escribió:
> >Actually is type 1, but there are horrible (network) conditions were de
> >application should stop.
>
> No, there aren't.  What happens when I run your application in-process with
> my webserver?  Should the webserver stop simply because your protocol is
> not working?

Well, yes I agree with you: not a webserver. So, I'll shortly describe my 
application.

I have multiple LSTP (Linux Terminal Server Project) servers. All servers are 
(almost) the same, and any of them can serve any client. There are arround 
8-12 servers and 150+ clients. I'm developing a twisted application that 
balances clients requests (by filtering DHCP discover/requests packets. (I 
attached an image, my application is called multiltsp). I'm using ip_queue 
for this.

Each server has a daemon, they syncronize themselves periodically. Every 
daemon knows the connection state of the others, and based on that 
information they create it's own "valid MACs' list".

There is a LDAP somewhere that has all client MACs that are in the group (eg. 
the 150 clients) and from time to time, multiltsp re-reads this list. (I'm 
simplifying much of these details). I'll call this list "ALL-MACS"...
[continued below]

> Just don't call reactor.stop at all unless you are writing top-level
> infrastructure code.  Your application should have some other, more
> structured way of reporting fatal shut-down errors to its run container
> (e.g. runContainer.applicationEncounteredFatal(xxx)), not simply raising
> exceptions and hoping someone is listening.  Unless you give more specifics
> that indicate that your special case is special-er than any other I've seen
> before, I'll stand by this. :)

[continuing with my explanation]
... all multiltsp daemons MUST have the ALL-MACS list identical, in case there 
is a out of sync[1] problem the (incorrect) server must quit and the others 
must handle the clients. 

There are serveral  services involved in this application (the multicast UDP 
protocol, a shell, the ip_queue reader and others),  but a major problem as 
stated above MUST get the application down with some special clean up. 

Glyph, I hope you understand my rustic English in the explanation above. Any 
advice or suggestion please respond this email.

Greetings, 

[1] This process involves a unique serial and many timeouts and a 
posible "FLUX" state, I just made a simple conclusion so we can argue about 
my twistd special need.

-- 
Nicolás D. César <ncesar at lunix.com.ar>
Lunix S.R.L. -[ http://www.lunix.com.ar ]-
GnuPG Public Key: gpg --keyserver wwwkeys.pgp.net --recv-key 0x3606F3E6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Netfilter-en.png
Type: image/png
Size: 25112 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20061130/fb5e6e71/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20061130/fb5e6e71/attachment.pgp