[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:15:50 EST 2008


On Jan 10, 2008 12:42 AM, hemant <gethemant at gmail.com> wrote:
> 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,

Try reading code of drb of slave. I am sure they offer lot more
features, but its turtles all the way down.

>
> 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.
>



-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org


More information about the Backgroundrb-devel mailing list