[Zope] fcgi, exceptions, random stuff

[Phillip J. Eby]

At 12:44 AM 2/8/99 -0800, Quinn Dunkan wrote:
>
>> One more general purpose way of handling shutting down is to include a
>> published method which shuts down python, for example:
>> 
>> def shutdown():
>>   "should require authorization to call this"
>>   raise SystemExit
>
>Yeah, but fcgi runs a seperate python for each cgi, so I'd need to somehow
>communicate with that python.  My ideal solution would be to have
>publish_module() reload its module every time (which is no time loss if the
>module hasn't changed).  How can I tell publish_module() to do this?  Ick,
>this doesn't deal with submodules properly, what I want is to have
>publish_module() re-import everything every time.  Maybe if I take them
out of
>sys.modules...
>
>I'm also having trouble with ZP exceptions, threads, sockets, and a few other
>things.
>
>Phillip was mentioning his fcgi efforts, so perhaps I needn't worry.  My
>current approach is to use the fcgiapp module and an fcgi-module-publisher
>that's similar to cgi-module-publisher with fcgi.Accept() and fcgi.Finish()
>around it.  Phillip, as soon you've gotten your fcgi working I'd love to see
>what you come up with.

If you check back in the list archives, looking for "Launcher.py" you
should be able to find the first fcgi support code I did.  It supports
specifying MAX_REQUESTS, IDLE_TIMEOUT, and MAX_LIFETIME settings so the
server will die after a set period.  During development, it can be useful
to set these all low, so that in the amount of time it takes you to make a
code change, the server will have died off due to inactivity.  :)  And if
it didn't die due to idleness, you can always hit reload a few times and
max out MAX_REQUESTS.  :)  In practice, I hardly ever do this, as I use
ZPublisher as the front-end to a Zope-like application server that runs off
the filesystem instead of a ZBase.  The app server notices when timestamps
change and automatically reloads the files, so I don't have to kill off the
server to see changes unless I'm changing the engine itself.

My newer FastCGI code is more a matter of changing to use Robin Dunn's
"fcgi" module in place of DC's "fcgiapp" so that it can be run
multithreaded, and creating a class framework for standalone publishers
that takes care of most of the messy plumbing overhead.  I'm factoring the
code into (proposed) ZPublisher.Config and ZPublisher.Plumbing.  I hope to
have some working code to present today.  ZPublisher.Config is working
quite spiffily, and most of the base Plumbing class is ready to go.  I'm
going to make test CGI(Plumbing) and FastCGI(Plumbing) classes next.



>You get the idea.  I can just wrap my published objects in a try except but
>that gets tedious after a while.  Zope also still uses string exceptions.
>Unless there is significant need for python 1.4 compatibility, it
shouldn't be
>too hard to come up with some sort of simple hierarchy, is that in the works?

You should be aware that there is a significant performance penalty for
using class exceptions, if your code throws them a lot.  This is
particularly noticeable with Acquisition, which does deep searches a fair
bit faster with the -X flag on.