Backgroundrb devel - Jun 2008 - Restarting BackgrounDRb Means Restarting Mongrel?

I''ve noticed that I can never just restart BackgrounDRb by itself.  As
soon
as I do that, Mongrel can no longer pass requests off to it.  The only way
to get it working again is by restarting Mongrel.  As annoying as that may
be, I suppose I could justify it to myself, since BackgrounDRb is
essentially resetting itself and its connections.

But what seems odd is that Mongrel (or, rather, MiddleMan) doesn''t seem
to
notice that it''s requests aren''t getting through.  That is, no
errors are
ever thrown.  The requests just die silently.

Is this the expected behavior?  Shouldn''t MiddleMan notice that
it''s
connection to BackgrounDRb just got severed?  Or am I missing something?

Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080616/e131d2ab/attachment.html>

On Mon, Jun 16, 2008 at 11:58 PM, Ian Lesperance
<ian.lesperance at gmail.com> wrote:
> I''ve noticed that I can never just restart BackgrounDRb by itself.
As soon
> as I do that, Mongrel can no longer pass requests off to it.  The only way
> to get it working again is by restarting Mongrel.  As annoying as that may
> be, I suppose I could justify it to myself, since BackgrounDRb is
> essentially resetting itself and its connections.
>
> But what seems odd is that Mongrel (or, rather, MiddleMan) doesn''t
seem to
> notice that it''s requests aren''t getting through.  That
is, no errors are
> ever thrown.  The requests just die silently.
>
> Is this the expected behavior?  Shouldn''t MiddleMan notice that
it''s
> connection to BackgrounDRb just got severed?  Or am I missing something?
>
Are you running svn version of the plugin?

http://gnufied.org/2008/05/21/bleeding-edge-version-of-backgroundrb-for-better-memory-usage/

In git version essentially a new clean connection is made for each
request and hence you shouldn''t see above mentioned problem. Please
try upgrading and let me know, how it went?

I am hesitant to jump onto the edge, since this is being used in a
production application.  Also, since I believe I''ve managed to
eliminate our
reason for needing to restart BackgrounDRb, it''s more of an
inconvenience at
this point.

Do you have plans to tag a release anytime soon, be it through Subversion or
Git?

Ian

On Mon, Jun 16, 2008 at 6:34 PM, hemant <gethemant at gmail.com> wrote:
> On Mon, Jun 16, 2008 at 11:58 PM, Ian Lesperance
> <ian.lesperance at gmail.com> wrote:
> > I''ve noticed that I can never just restart BackgrounDRb by
itself.  As
> soon
> > as I do that, Mongrel can no longer pass requests off to it.  The only
> way
> > to get it working again is by restarting Mongrel.  As annoying as that
> may
> > be, I suppose I could justify it to myself, since BackgrounDRb is
> > essentially resetting itself and its connections.
> >
> > But what seems odd is that Mongrel (or, rather, MiddleMan)
doesn''t seem
> to
> > notice that it''s requests aren''t getting through. 
That is, no errors are
> > ever thrown.  The requests just die silently.
> >
> > Is this the expected behavior?  Shouldn''t MiddleMan notice
that it''s
> > connection to BackgrounDRb just got severed?  Or am I missing
something?
> >
>
> Are you running svn version of the plugin?
>
>
>
http://gnufied.org/2008/05/21/bleeding-edge-version-of-backgroundrb-for-better-memory-usage/
>
> In git version essentially a new clean connection is made for each
> request and hence you shouldn''t see above mentioned problem.
Please
> try upgrading and let me know, how it went?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080618/75c83b4f/attachment.html>

On Thu, Jun 19, 2008 at 1:39 AM, Ian Lesperance
<ian.lesperance at gmail.com> wrote:
> I am hesitant to jump onto the edge, since this is being used in a
> production application.  Also, since I believe I''ve managed to
eliminate our
> reason for needing to restart BackgrounDRb, it''s more of an
inconvenience at
> this point.
>
> Do you have plans to tag a release anytime soon, be it through Subversion
or
> Git?
I am not committing a time line, but I intend to release new version
this weekend if everything I planned goes well. Also, I hear from
folks( and in my own experience), git version is a _lot_ more stable.
If you don''t want to change in production at least try in production.

Any update on this new tagged version? I need a new stable version  
before I''ll be allowed to deploy an update, and at the moment
we''ve
got a whole set of things that are waiting for a stable version of  
backgroundrb to deploy.

I understand that it''s difficult to have a firm timeline, but
it''s
also been a couple of weeks since the last thing we''ve heard on  
tagging a new version.

On Jun 18, 2008, at 1:31 PM, hemant wrote:
> On Thu, Jun 19, 2008 at 1:39 AM, Ian Lesperance
> <ian.lesperance at gmail.com> wrote:
>> I am hesitant to jump onto the edge, since this is being used in a
>> production application.  Also, since I believe I''ve managed to
>> eliminate our
>> reason for needing to restart BackgrounDRb, it''s more of an  
>> inconvenience at
>> this point.
>>
>> Do you have plans to tag a release anytime soon, be it through  
>> Subversion or
>> Git?
>
> I am not committing a time line, but I intend to release new version
> this weekend if everything I planned goes well. Also, I hear from
> folks( and in my own experience), git version is a _lot_ more stable.
> If you don''t want to change in production at least try in
production.
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4619 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080706/93b686c4/attachment.bin>

On Sun, Jul 6, 2008 at 10:20 PM, Timothy Sanders
<tsanders at hiddenjester.com> wrote:
> Any update on this new tagged version? I need a new stable version before
> I''ll be allowed to deploy an update, and at the moment
we''ve got a whole set
> of things that are waiting for a stable version of backgroundrb to deploy.
>
> I understand that it''s difficult to have a firm timeline, but
it''s also been
> a couple of weeks since the last thing we''ve heard on tagging a
new version.
>
I can use some help in making new tagged release. Basically, master
branch of github will be merged with testcase branch. I am exclusively
working on testcase branch.

In past, I had some bad experience with hurried releases and don''t
want to repeat the same mistake, in the meanwhile, you can happily use
git master, it works pretty rock solid and whenever required i roll
out new fixes.

BUT, next release will be a major release and I don''t want to mess it
up. Here are set of things, that I am working on:

1. Get close to 100% test coverage and make tests runnable by end users.
2. Implement support for database based persistent worker queues. Done
in testcase branch.
3. Implement support for clustering of BackgrounDRb servers and load
balancing. This is again done.
4. Support for multi-machine setup and let user run tasks on specified
hosts.Done
5. make result storing thread safe and hence can be called from within threads.
6. Support memcache based result storage properly.
7. Cleanup job_key confusion.
8. Fix some memory leaks introduced by upstream stupid ruby tricks.

You can see this change sheet is huge. There have been some minor API
changes as well, but I want this release to be stable and scalable
within production environments.

If you want to accelerate this process, then checkout code from
testcase branch of github backgroundrb repo and give it a try.Thats
the future. Otherwise, use master branch, there is no problem there.

Indeed. I wasn''t trying to hurry you, I was just curious what the  
status was. Having said that, there''s big perceived difference in  
stability between saying "We''re using the 1.0.3 release" and
"We''re
using the latest from git, which appears to be stable". I''m sure
the
current version *IS* stabler, but there''s also a comfort level in  
having a tagged version, and it''s just simply a matter of the  
processes and procedures in use on my project saying that we want a  
stable released version of all libraries in the production  
environment. If you were just a few days away from a major release  
then I''d agree that waiting for the list you wrote up is a good idea,  
but if you want more hands testing the current version of the master  
branch I''d suggest packing it up as a 1.0.4 updating it both in git  
and svn.

It seems a little like a chicken and the egg scenario where you want  
users to test out the new version, but some set of users won''t be able
to check it until there''s a tagged version. While I can use any  
version I want in development, it''s going to be a bigger deal for me  
to try to sell using the current version in production. And truthfully  
it''s a little tricky for me to even go to a new version in development
if I have no idea how long it will be before that version would be  
suitable for production.

It''s possible that some of the issue here is simply that I''m
not
familiar with git - so maybe the master branch is equivalent to a  
tagged release. But if the "master branch" is basically the same thing
as the "trunk revision" would be in svn or cvs, then if it''s
the
version you want people using in production environments then I would  
encourage you to give it a new version number. If nothing else, simply  
so people can talk about what version the problem is against.  
Otherwise we''re all in a sort of limbo where the master version can  
change at any moment and it''s difficult to describe what version  
anybody is actually using.

My impression is that you feel if I was pushing a version to  
production today that I should use the git master, not 1.0.3, but  
that''s not really a good solution for everyone. If the git master is a
better version than 1.0.3, then it really deserves it''s own version  
tag, and that''s more important to me than whether said tag is 1.0.4,  
1.1, or 2.0.

On Jul 6, 2008, at 12:17 PM, hemant wrote:
> In past, I had some bad experience with hurried releases and don''t
> want to repeat the same mistake, in the meanwhile, you can happily use
> git master, it works pretty rock solid and whenever required i roll
> out new fixes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4619 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080706/9e3944c5/attachment.bin>