Re: [Twisted-Python] Need Exception that will stop ther reactor within twistd
On 27 Nov, 06:19 pm, ncesar@lunix.com.ar wrote:
El S�bado, 25 de Noviembre de 2006 02:39, glyph@divmod.com escribi�:
I was wondering if twistd/the application class could have a "exit on Exception" for this type of operations.
In general this is a bad idea. There are basically 3 kinds of code you can write with Twisted:
1. Infrastructure code, which implements a protocol and provides APIs for parsing and dealing with events. This kind of code should never contain a reactor.stop at all.
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?
Even it's not type 3, I get your point. And thats why I didn't want to write ANY reactor.stop() call, instead just raise exceptions- And have a unnified reactor.stop() inside somewhere in twistd. But it seems I need to think another solution. Right now as a workaround, reactor.stop() will be inside my exception's __init__ function ;-)
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. :)
Don't try to always stop the *process* when your program is complete: stop the *program* by keeping a Deferred around which represents its complete run. That way the *driver* for the program is responsible for stopping it, and when you want to aggregate multiple runs of it, you can easily use a tool like DeferredList, or do something different in the callbacks at the end.
I couldn't understand much of this last parragraph (my English reading could be part of the problem). I understand algorithms mucho more when are written in python instead of English, Do you have a link to some code explaning this?
It's hard for me to think of a program which does this in a simple way. If I can think of one I will post an example.
my apologies for the delayed answer, i've been very busy latelly. El Martes, 28 de Noviembre de 2006 06:07, glyph@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@lunix.com.ar> Lunix S.R.L. -[ http://www.lunix.com.ar ]- GnuPG Public Key: gpg --keyserver wwwkeys.pgp.net --recv-key 0x3606F3E6
participants (2)
-
glyph＠divmod.com -
Nicolas D. Cesar