[Backgroundrb-devel] [PATCH] x 2 - Fix for "null pointer exception" when ask_status is called before worker is run, and docfixes

hemant gethemant at gmail.com
Wed Jan 9 14:12:57 EST 2008


Hi,

On Jan 9, 2008 12:46 PM, Cheah Chu Yeow <chuyeow at gmail.com> wrote:
> Thanks!
>
> Hope this will help debug what's going on with Devjavu: when I login (it's
> the right password, since if I try an incorrect password it spews an error
> message), it redirects back to wherever I came from, but the 'Login |
> Register' links are still showing and I can't create a new ticket.

Well the issue with result hash is fixed and I have updated 1.0.1
release tag as well as trunk.

I am starting work on Test Cases now. I saw your comment about lack of
test cases and I am working to amend the situation.
Between my office work, other projects, often things go wary. I have
created the infrastructure for testing the plugin and stuff, I will be
glad if you or anyone is willing to help.

I have been a user of BackgrounDRb since Ezra released first version
and followed the development closely. 0.2.1 release although a major
step forward had nasty unresolved bugs because of DRb and Slave
library. You can browse mailing list archives of ruby-talk and
backgroundrb and find that Slave is a glorious hack, but a hack
nonetheless ( Ara himself admits code is quite difficult to follow ).

So Ezra got busy and moved to better and bigger things, he asked if
anyone is willing to work on it and I volunteered. I think, Ezra
handed over the project not because he was overly impressed with my
contribution, but because NO ONE else stepped forward.

After taking up project, I was getting lots of bug reports ( again
mailing list archives is a proof). Now sad thing is, I was not able to
fix them. Why? Because fork(), threads and DRb was just a disaster. I
tried fixing existing stuff, but honestly it was a mess. I had lots of
workers running under heavy load and they would disappear. Whats more,
changes to slave library screwed up the plugin big time.


So, I did what I could do, I wrote an entire network programming
framework, removed threads, removed slave and drb and made a new
release. I am sure, its not been a smooth ride since then and I am
thankful to early adopters. I also perhaps hurried towards 1.0
release, I should kept versioning incremental. But anyways, we had a
programming model, which was totally transparent and simple ( for me
anyways ). I believe simple stuff should be kept simple ( again thanks
to Zed for the tip), so if you or anyone has time to look into
internals of BackgrounDRb, you will find it pretty easy to understand.
On the other hand,

Abstracting network IO in automated testing is hard and that explains
lack of test cases. But I am not defending it, I have been guilty of
it. I can only amend the situation I hope.


More information about the Backgroundrb-devel mailing list