Queue qsize = unreliable?

[Tom B.]

"James R. Saker Jr." <jsaker at americanrelay.com> wrote in message
news:mailman.1284.1091808092.5135.python-list at python.org...
> Thanks Peter, Mike & Michael on qsize - had a hunch it might be
> "reliable but not advisable" in the aspect of queue data changing.
>
> Perhaps there's an easier way to accomplish what I'm attempting. I've
> got a syslogd receptor that needs to:
>
> 1. have a thread sit on port 514 and receive input via syslog protocol
> from various sources
>
> 2. receive input and put into a queue (ideally a persistent object so if
> the receptor gets rebooted while there's work in the queue, data isn't
> lost. i like the idea of ZODB's Persistence class for this - thoughts?)
>
> 3. have a thread sit and look for data in the queue. when data is found,
> parse it and fire it off using BEEP to an upstream collector.
>
> I've done an initial version of this using Postgresql for an
> intermediary (and twisted's database interface to deal with blocking
> issues), but having to load Postgresql on a syslog2beep receptor is
> overkill. A ZODB Queue implemented in a threaded app would seem the
> right way to go. Any thoughts?
>
> Jamie
>
I wrote this on another reply just awhile ago but it also applies here,

You should have a look at Pyro (Python Remote Objects) at
http://pyro.sourceforge.net/index.html

"It is an advanced and powerful Distributed Object Technology system written
entirely in Python"

Have a look at the rserve demo for a distributed object and the chat demo
for an event server.

Tom