Queue qsize = unreliable?
sbabbitt at commspeed.net
Fri Aug 6 18:41:11 CEST 2004
"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?
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
"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.
More information about the Python-list