[Backgroundrb-devel] BackgrounDRb prerelease for 1.0.3 version
gethemant at gmail.com
Thu Feb 14 12:52:36 EST 2008
On 2/14/08, hemant <gethemant at gmail.com> wrote:
> Hullo there,
> I have worker out quite some changes as promised in last mail. Here is
> a brief ChangeLog:
> * Added TestCases for Cron Triggers, Meta Workers and stuff. We are
> heading towards proper code coverage with specs.
> * Added preliminary support for starting a worker on demand through
> scheduler. What it means is, when you have a worker which is getting
> scheduled very less frequently and you don't want the worker to
> persist, you can ask BackgrounDRb to restart the worker on each
> * Fixed some unreported issues with writing data to socket between
> workers and stuff.
> * Fixed issues with too many open connections, because connections
> were not getting closed. BackgrounDRb now opens only one connection,
> which is
> reused throughout the lifecycle of rails application.
> * Fixed all outstanding issues with Cron triggers, BackgrounDRb now
> explicitly depends on "chronic" gem.
> * Removed Framework directory and BackgrounDRb now explicitly depends
> on packet gem.
> To install:
> gem install packet chronic
> Checkout code from git repository:
> git clone git at gitorious.org:backgroundrb/mainline.git backgroundrb
> As usual, remove old backgroundrb script from script directory and
> start bdrb server.
I will really appreciate some feedback on above release, because those
Socket write issues I mentioned were serious ones and both "Packet"
library and bdrb suffered from them. Let me explain what they were
and why they matter:
When reactor loop was writing data to sockets, it was not using
"writable" status on file descriptors. For small amount of data being
written to the socket this is not a problem, but for larger objects it
could be a problem. Now, write happens in an evented manner and all
the data is "buffered" in memory until socket is ready for write. Bdrb
( or packet ) will write as much data as it can and will buffer the
remaining data for writing when socket is ready next time for write.
It was a known problem and I took some pain to fix this. So, Bdrb will
be much more robust in production environments now. Also, CronTrigger
code went through major cleanup and testing.
I implemented a function called next_turn in packet, which lets you
run random tasks at next turn of event loop. This will be used for
runtime loading of workers and task queues.
More information about the Backgroundrb-devel