Re: Organizing a Quixote/Durus multiprocess application

Actually it's not as bad as I thought.  The Durus servers don't need
full-fledged daemons with PID files, just an ordinary fork.  Then
they'll automatically be killed when the main application exits.
(Which is a good thing, because if I restart the application it means
I want to reinitialize everything.)  Plus the main app has the
servers' PIDs in memory if it wants them for anything.

The second part is initializing the client connections.
create_publisher is called inside each SCGI child process so it can do
that there.  This is the normal place to initialize the session
manager anyway, so I don't have to change anything.

(create_publisher is called indirectly by
scgi.scgi_server.SCGIServer.spawn_child.  It calls
self.handler_class(), which is a wrapper around create_publisher
defined in quixote.server.scgi_server.run().)

I'd forgotten that multiple readonly connections can use FileStorage
directly, so that eliminates one database server.

I'm getting a "connection refused" using ClientStorage on a socket,
even though netstat and lsof say the socket is listening.  I'm not
sure if it's my fault or not.  I know it's ECONNREFUSED because I
changed durus.storage_server.UnixDomainSocketAddress.get_connected_socket
to re-raise the exception rather than returning None.

On 8/29/06, Damjan <[email protected]> wrote:
> Note that I don't use double-fork in daemonize... I don't think it's
> needed on Linux.

Where is it needed?  I only used it because the Python powers that be
said this is the way to daemonize and it should probably be added to
os.system.

-- 
Mike Orr <[email protected]>