Backgroundrb devel - Feb 2007 - Backgroundrb-devel Digest, Vol 9, Issue 1

Hi Bill,

I have "version 1" backgroundrb running on my development server with
rails 1.2.1, with no issues (other than the left over DB connections  
blocking up my MySQL server, which isn''t exactly a new problem).   
Going to move production servers to rails 1.2.1 very soon, I''ll post  
back if there''s any trouble.

Still would *really* like to get version 2 running though!  Having a  
production system where I have to restart a process every couple  
hours is definitely *not* ideal but backgroundrb 2 is still  
completely unworkable for me.  It still seg-faults every time I try  
to start a worker for the 2nd time (malloc error in drb.rb).  Still  
can''t get anything queue-based working because any call to  
worker_thread fails (nil:NilClass errors, totally following the docs  
and nothing...).  This all on top of the fact that results worker  
doesn''t really seem to hold any results.  I''ve rewritten my
software
8 different ways and no luck.

I read that some people actually managed to get version 2 to work in  
production, I''d really love to know how.  Has anyone gotten it to  
work successfully on Mac OS X 10.4, server or client, or anything  
close?  I feel like it''s gotta be something with gcc 4.x or the 64- 
bit-ness or ruby 1.8.5 or something, there are scattered clues all  
over google, but everything else on the system runs so well I''m  
really nervous to spend days recompiling everything down to 1.8.2/gcc  
3.3 just to find out that everything else is broken but backgroundrb  
works fine.

What really confuses me is I see very little chatter about these  
problems on the list or when searching the web, but I seriously can  
install a completely new 10.4 system, fresh ruby/rails/everything  
compiled from scratch, make a totally new Rails program, and plug in  
a worker straight from the examples that come with bgrb-2, and so  
help me when you run that worker the second time, it always seg- 
faults!  Intel or PPC, server or client version, no difference!  Just  
how does anyone with OS X get this running?

Really, any advice at all...  if someone with Mac OS X 10.4 has  
gotten version 2 to work, and you could just post all the version  
numbers on the gcc, ruby, etc that you use with it, my database, my  
users and I would be so very grateful.

--
Steve


On Feb 3, 2007, at 1:33 PM, backgroundrb-devel-request at rubyforge.org  
wrote:
>
> Greetings!
>
> Has anybody tried running the ''old'' version of
BackgrouDRb (the
> repository on rubyforge.org) on Rails 1.2.1?  Any reason to think  
> it won''t work?
>
> Thanks!
> Bill
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/ 
> 20070130/93d4cd89/attachment-0001.html
>
> ------------------------------
>

I have no such problems on OS X 10.4.8 and Rails 1.1.6

Here is my configuration:

erik$ ruby -v
ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1]

erik$ gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~20/src/configure -- 
disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- 
enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] 
[^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 -- 
build=powerpc-apple-darwin8 --with-arch=pentium-m --with- 
tune=prescott --program-prefix= --host=i686-apple-darwin8 -- 
target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)

erik$ uname -a
Darwin erik.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25  
19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386

erik$ gem list|grep slave
slave (1.2.0)

erik$ gem list|grep daemons
daemons (1.0.3)

On Feb 3, 2007, at 5:51 PM, Stephen Weiss wrote:
> Hi Bill,
>
> I have "version 1" backgroundrb running on my development server
with
> rails 1.2.1, with no issues (other than the left over DB connections
> blocking up my MySQL server, which isn''t exactly a new problem).
> Going to move production servers to rails 1.2.1 very soon, I''ll
post
> back if there''s any trouble.
>
> Still would *really* like to get version 2 running though!  Having a
> production system where I have to restart a process every couple
> hours is definitely *not* ideal but backgroundrb 2 is still
> completely unworkable for me.  It still seg-faults every time I try
> to start a worker for the 2nd time (malloc error in drb.rb).  Still
> can''t get anything queue-based working because any call to
> worker_thread fails (nil:NilClass errors, totally following the docs
> and nothing...).  This all on top of the fact that results worker
> doesn''t really seem to hold any results.  I''ve rewritten
my software
> 8 different ways and no luck.
>
> I read that some people actually managed to get version 2 to work in
> production, I''d really love to know how.  Has anyone gotten it to
> work successfully on Mac OS X 10.4, server or client, or anything
> close?  I feel like it''s gotta be something with gcc 4.x or the
64-
> bit-ness or ruby 1.8.5 or something, there are scattered clues all
> over google, but everything else on the system runs so well I''m
> really nervous to spend days recompiling everything down to 1.8.2/gcc
> 3.3 just to find out that everything else is broken but backgroundrb
> works fine.
>
> What really confuses me is I see very little chatter about these
> problems on the list or when searching the web, but I seriously can
> install a completely new 10.4 system, fresh ruby/rails/everything
> compiled from scratch, make a totally new Rails program, and plug in
> a worker straight from the examples that come with bgrb-2, and so
> help me when you run that worker the second time, it always seg-
> faults!  Intel or PPC, server or client version, no difference!  Just
> how does anyone with OS X get this running?
>
> Really, any advice at all...  if someone with Mac OS X 10.4 has
> gotten version 2 to work, and you could just post all the version
> numbers on the gcc, ruby, etc that you use with it, my database, my
> users and I would be so very grateful.
>
> --
> Steve
>
>
> On Feb 3, 2007, at 1:33 PM, backgroundrb-devel-request at rubyforge.org
> wrote:
>>
>> Greetings!
>>
>> Has anybody tried running the ''old'' version of
BackgrouDRb (the
>> repository on rubyforge.org) on Rails 1.2.1?  Any reason to think
>> it won''t work?
>>
>> Thanks!
>> Bill
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/
>> 20070130/93d4cd89/attachment-0001.html
>>
>> ------------------------------
>>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Hey~

On Feb 3, 2007, at 2:51 PM, Stephen Weiss wrote:
> Hi Bill,
>
> I have "version 1" backgroundrb running on my development server
with
> rails 1.2.1, with no issues (other than the left over DB connections
> blocking up my MySQL server, which isn''t exactly a new problem).
> Going to move production servers to rails 1.2.1 very soon, I''ll
post
> back if there''s any trouble.

In version 1 of the plugin you need to call  
ActiveRecord::Base.connection.disconnect!  as the last thing your  
worker does or when it''s done with the database. This will not affect  
the other db handles as it only disconnects the db handle for the  
thread your worker is running in.
>
> Really, any advice at all...  if someone with Mac OS X 10.4 has
> gotten version 2 to work, and you could just post all the version
> numbers on the gcc, ruby, etc that you use with it, my database, my
> users and I would be so very grateful.
>
> --
> Steve
ez ez $ ruby -v
ruby 1.8.5 (2006-08-25) [i686-darwin8.7.1]
ez ez $ gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure -- 
disable-checking -enable-werror --prefix=/usr --mandir=/share/man -- 
enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg] 
[^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with- 
slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=nocona -- 
with-tune=generic --program-prefix= --host=i686-apple-darwin8 -- 
target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
ez ez $ uname -a
Darwin ezra-zygmuntowiczs-computer.local 8.8.1 Darwin Kernel Version  
8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/ 
RELEASE_I386 i386 i386
ez ez $ gem list slave

*** LOCAL GEMS ***

slave (1.2.0, 1.0.0)
     slave
ez ez $ gem list daemons

*** LOCAL GEMS ***

daemons (1.0.3, 1.0.2, 0.4.2)
     A toolkit to create and control daemons in different ways


Sorry you are having trouble Steve. Admitedly Backgroundrb0.2.x  
branch does still have some problems but it does work very well once  
you tame it. That being said I have had zero time to work on bdrb in  
the last few months./ skaar did a ton of great work on this new  
architecture. But he and I have always said that 0.3.x will be the  
stable release of the new architecture.

I hope to have some time soon to go over the 0.2.x branch and fix any  
issues people are having. I also think that the old way of doing jobs  
has its place. So I may release a trimmed down refactored version of  
the original plugin. The thrteaded approach is fast to spawn jobs and  
if you are doing small tasks like cleaning sessions and working with  
rss of csv files then the old way is faster to spawn workers. The new  
slave architecture is for higher volume processing with long lived  
workers.

All that being said, if anyone wants to step up and help fix problems  
with either version of the plugin then I welcome you and I love  
patches ;)

Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Hi Ezra,

Ezra Zygmuntowicz wrote:
> I also think that the old way of doing jobs has
> its place. So I may release a trimmed down
> refactored version of  the original plugin. The
> thrteaded approach is fast to spawn jobs and
> if you are doing small tasks like cleaning sessions
I''m really glad to hear you take this position.
> All that being said, if anyone wants to step up
> and help fix problems with either version of the
> plugin then I welcome you and I love patches ;)
Count me in.  I''m not sure just how helpful I''ll be, but
I''m definitely
going to have to figure out what''s going wrong in my situation and get
it
fixed.  More on my situation in the other thread.

Thanks,
Bill