[OPEN-ILS-DEV] ***SPAM*** opensrf perl pre-forking server module (replacing net::server)

[Bill Erickson]

Hi all,

I took on a personal project recently to gut the Net::Server glue code from
the OpenSRF Perl libs and replace it with a local pre-forking server
module.  It's an itch I've been wanting to scratch for some time and I
finally got around to it.  Attached is a patch that should apply cleanly to
OpenSRF trunk (with a -p1).

What's the point (apart from fun with Perl)?

1. Net::Server is meant to provide infrastructure for servers that listen on
a socket-type thing.  OpenSRF services aren't really servers.  They are
clients on a Jabber network.  In order to take advantage of Net::Server, the
OpenSRF code had to take Jabber messages off the wire, serialize them, then
pass them off to the Net::Server socket (a UNIX domain socket in this
case).  Net::Server would then pass the data off to a child process, via
named pipe.  The new code, like the C and Python code, skips the extra
translation step and passes Jabber messages directly from parent to child
via named pipe.  It cuts out the extra step through the UNIX domain socket.

Current setup:

XMPP -> Listener -> UNIX domain socket -> Net::Server Parent -> pipe ->
child process.

New setup:

XMPP -> Listener -> pipe -> child process

2. Dropping the extra layer and applying a little more cleanup, this patch
drops 2 processes per OpenSRF service.  The controller, master, and listener
processes have been collapsed into a single listener process.

3. Fine-grained control over process management logging.  Like the C code,
the system reports in the opensrf logs when we're running out of processes.
It also drops the extraneous net::server log files (usually in
/openils/var/log/*_unix.log).  This data will go into the opensrf logs
instead.

4.  OpenSRF no longer needs Net::Server or FreezeThaw.  Note that Evergreen
SIP still uses Net::Server.

Cons?  It's new code and not battle-hardened like the existing code.  It's
built on the same principles as the C code, which has served us well, but it
still needs lots of testing.  I've been pounding it pretty hard with
Constrictor, but that's only one dimension.

I'm not dying to get this into OpenSRF today.  I'd rather let it get some
air and testing first.  I appreciate any input, concerns, and critiques.

Thanks

-b

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20100525/1ab4cdf3/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opensrf_inline_server.patch
Type: application/octet-stream
Size: 41020 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20100525/1ab4cdf3/attachment-0001.obj