From charlesmbowman at gmail.com  Mon Jun  4 15:57:05 2007
From: charlesmbowman at gmail.com (Charlie Bowman)
Date: Mon, 4 Jun 2007 15:57:05 -0400
Subject: [Backgroundrb-devel] backgroundrb scheduler
Message-ID: <298c4d2a0706041257m44a2c8d3j2de785ae0c7dafe5@mail.gmail.com>

I've been having a terrible time with the backgroundrb scheduler.  The
issues I'm having is that the scheduled actions aren't ran at all and if
they do, the process stays around forever.  I'm using the backgroundrb as a
nightly cron to run some accounting operations.

questions:
1. How can I have the process destroyed after the worker completes?
2.  Any idea on what would keep the prcesses from being started.  The
backgroundrb.log is empty.  I'll post the backgroundrb_server.log
3.  Is backgroundrb even the right choice for nightly rails crons?

Thanks for any help, and of course for backgroundrb!

Charlie

This is the backgroundrb_server.log for last night.  It called and ran this
worker but none of the rest (about 7 others).  Again, nothing was written to
the backgroundrb.log.   all the workers run fine when manually called, and
even run fine some of the time through cron.

20070604-06:00:00 (29111) Schedule triggered: #<struct #<Class:0xb7a2a5ac>
job=#<Proc:0xb7982dac@/var/www/companyapp/releases/20070531073057/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:355>,
trigger=#<BackgrounDRb::CronTrigger:0xb7366cc0 @sec=[0], @wday=0..6,
@min=[0], @month=1..12, @hour=[6], @year=nil, @day=1..31, @cron_expr="0 0 6
* * * *">, earliest=Mon Jun 04 06:00:00 EDT 2007, last=Mon Jun 04 06:00:00
EDT 2007>
20070604-10:00:03 (29111) Starting worker: collect_worker collect
(collect_worker_collect) ()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070604/ab998b4c/attachment.html 

From ezmobius at gmail.com  Mon Jun  4 16:03:38 2007
From: ezmobius at gmail.com (Ezra Zygmuntowicz)
Date: Mon, 4 Jun 2007 13:03:38 -0700
Subject: [Backgroundrb-devel] backgroundrb scheduler
In-Reply-To: <298c4d2a0706041257m44a2c8d3j2de785ae0c7dafe5@mail.gmail.com>
References: <298c4d2a0706041257m44a2c8d3j2de785ae0c7dafe5@mail.gmail.com>
Message-ID: <6C4AF6DB-E094-4FA9-961A-E8C0F83EC8E2@brainspl.at>

CHarlie-

	If all you need is nightly type jobs then bdrb is not the right  
choice,. I would just use cron and script/runner.

Cheers-
-Ezra

On Jun 4, 2007, at 12:57 PM, Charlie Bowman wrote:

> I've been having a terrible time with the backgroundrb scheduler.   
> The issues I'm having is that the scheduled actions aren't ran at  
> all and if they do, the process stays around forever.  I'm using  
> the backgroundrb as a nightly cron to run some accounting operations.
>
> questions:
> 1. How can I have the process destroyed after the worker completes?
> 2.  Any idea on what would keep the prcesses from being started.   
> The backgroundrb.log is empty.  I'll post the backgroundrb_server.log
> 3.  Is backgroundrb even the right choice for nightly rails crons?
>
> Thanks for any help, and of course for backgroundrb!
>
> Charlie
>
> This is the backgroundrb_server.log for last night.  It called and  
> ran this worker but none of the rest (about 7 others).  Again,  
> nothing was written to the backgroundrb.log.   all the workers run  
> fine when manually called, and even run fine some of the time  
> through cron.
>
> 20070604-06:00:00 (29111) Schedule triggered: #<struct #<Class: 
> 0xb7a2a5ac> job=#<Proc:0xb7982dac@/var/www/companyapp/releases/ 
> 20070531073057/vendor/plugins/backgroundrb/server/lib/backgroundrb/ 
> middleman.rb:355>, trigger=#<BackgrounDRb::CronTrigger:0xb7366cc0  
> @sec=[0], @wday=0..6, @min=[0], @month=1..12, @hour=[6], @year=nil,  
> @day=1..31, @cron_expr="0 0 6 * * * *">, earliest=Mon Jun 04  
> 06:00:00 EDT 2007, last=Mon Jun 04 06:00:00 EDT 2007>
> 20070604-10:00:03 (29111) Starting worker: collect_worker collect  
> (collect_worker_collect) ()
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

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



From charlesmbowman at gmail.com  Mon Jun  4 16:13:35 2007
From: charlesmbowman at gmail.com (Charlie Bowman)
Date: Mon, 4 Jun 2007 16:13:35 -0400
Subject: [Backgroundrb-devel] backgroundrb scheduler
In-Reply-To: <6C4AF6DB-E094-4FA9-961A-E8C0F83EC8E2@brainspl.at>
References: <298c4d2a0706041257m44a2c8d3j2de785ae0c7dafe5@mail.gmail.com>
	<6C4AF6DB-E094-4FA9-961A-E8C0F83EC8E2@brainspl.at>
Message-ID: <298c4d2a0706041313p2743f586x11147ff1b1dfb393@mail.gmail.com>

Thanks for the quick reply!  I'll definitely take your advice on this.

On 6/4/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>
> CHarlie-
>
>         If all you need is nightly type jobs then bdrb is not the right
> choice,. I would just use cron and script/runner.
>
> Cheers-
> -Ezra
>
> On Jun 4, 2007, at 12:57 PM, Charlie Bowman wrote:
>
> > I've been having a terrible time with the backgroundrb scheduler.
> > The issues I'm having is that the scheduled actions aren't ran at
> > all and if they do, the process stays around forever.  I'm using
> > the backgroundrb as a nightly cron to run some accounting operations.
> >
> > questions:
> > 1. How can I have the process destroyed after the worker completes?
> > 2.  Any idea on what would keep the prcesses from being started.
> > The backgroundrb.log is empty.  I'll post the backgroundrb_server.log
> > 3.  Is backgroundrb even the right choice for nightly rails crons?
> >
> > Thanks for any help, and of course for backgroundrb!
> >
> > Charlie
> >
> > This is the backgroundrb_server.log for last night.  It called and
> > ran this worker but none of the rest (about 7 others).  Again,
> > nothing was written to the backgroundrb.log.   all the workers run
> > fine when manually called, and even run fine some of the time
> > through cron.
> >
> > 20070604-06:00:00 (29111) Schedule triggered: #<struct #<Class:
> > 0xb7a2a5ac> job=#<Proc:0xb7982dac@/var/www/companyapp/releases/
> > 20070531073057/vendor/plugins/backgroundrb/server/lib/backgroundrb/
> > middleman.rb:355>, trigger=#<BackgrounDRb::CronTrigger:0xb7366cc0
> > @sec=[0], @wday=0..6, @min=[0], @month=1..12, @hour=[6], @year=nil,
> > @day=1..31, @cron_expr="0 0 6 * * * *">, earliest=Mon Jun 04
> > 06:00:00 EDT 2007, last=Mon Jun 04 06:00:00 EDT 2007>
> > 20070604-10:00:03 (29111) Starting worker: collect_worker collect
> > (collect_worker_collect) ()
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> -- Ezra Zygmuntowicz
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070604/e8b7bb50/attachment.html 

From wil at 3cglabs.com  Tue Jun  5 12:41:15 2007
From: wil at 3cglabs.com (Wil Chung)
Date: Tue, 5 Jun 2007 11:41:15 -0500
Subject: [Backgroundrb-devel] typo in the README?
Message-ID: <4cdd0d160706050941gf7bd3fcw7c0297cdb0bc0954@mail.gmail.com>

In the section under "Trigger" it says:


The plain trigger takes three arguments:
>
>   | :start => time, :end => time, :interval => seconds
>
> If the end argument is omitted, the event will trigger at the interval as
> long as the server is running.
>

Shouldn't it be :repeat_interval?

Everything below it in both the backgroundrb_schedules.yml and the MiddleMan
section seems to indicate this.  If so, how can I go about changing it?
download the trunk and submit a patch?  I wouldn't mind helping out with
documentation, especially parts I found confusing when I first started using
backgroundrb.  Thanks.

Wil

-- 
http://www.3cglabs.com
http://thoughtl.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070605/e0cc93b0/attachment.html 

From jodi at nnovation.ca  Tue Jun  5 21:00:56 2007
From: jodi at nnovation.ca (Jodi Showers)
Date: Tue, 5 Jun 2007 21:00:56 -0400
Subject: [Backgroundrb-devel] struggling with stability
Message-ID: <2E2B05AE-C48C-4E1B-B4E7-B93ED98F9172@nNovation.ca>

Greetings all,

Unit tests are passing, but I'm having mucho problems getting brb to  
run without exceptions for more than 6 hours.

I'm seeing a mixture of the following 2 exceptions:

20070605-11:26:56 (21497) failed to find slave socket - (RuntimeError)
20070605-11:26:56 (21497) /usr/local/lib/ruby/gems/1.8/gems/ 
slave-1.2.1/lib/slave.rb:435:in `initialize'
20070605-11:26:56 (21497) /var/www/html/the-soup/vendor/plugins/ 
backgroundrb/server/lib/backgroundrb/middleman.rb:210:in `new_worker'

and

20070605-11:26:56 (21497) ~~~~~~~~~ Can't find job! 'job_key_1' -  
(Exception)
20070605-11:26:56 (21497) undefined method `initial_do_work' for  
[]:Array - (NoMethodError)
20070605-11:26:56 (21497) /var/www/html/the-soup/vendor/plugins/ 
backgroundrb/server/lib/backgroundrb/middleman.rb:342:in  
`schedule_worker'
(the above is a check I added when a job key lookup fails)

environment:
- RHEL 4
- ruby 1.8.4 (2005-12-24) [x86_64-linux]
- rails  1.2.3
- slave (1.2.1)
- daemons (1.0.5)
- not using middleman - only the scheduler
- mysql 5

The tasks are scheduled to run every hour, and don't run for more  
than a few minutes.

Talking with Ezra at railsconf he indicated that a new team member  
was joining - can I provide any info to help debug this?

Jodi

From cschlaefcke at wms-network.de  Thu Jun  7 03:51:56 2007
From: cschlaefcke at wms-network.de (Christian Schlaefcke)
Date: Thu, 7 Jun 2007 09:51:56 +0200 (CEST)
Subject: [Backgroundrb-devel] Problem with workers starting workers
Message-ID: <46219.159.103.208.26.1181202716.squirrel@www.wms-network.de>

Hi,

I have something like a control worker that gets started from a webservice
on request. The control worker should prepare other execution workers and
start them.

It seems that the execution workers stop working as soon as the control
worker has done it?s work and gets released.

Is there a way to start workers from other workers without blocking them
as soon as the father worker gets released?

Thanks & Regards,

Christian


From charlesmbowman at gmail.com  Mon Jun 11 15:04:31 2007
From: charlesmbowman at gmail.com (Charlie Bowman)
Date: Mon, 11 Jun 2007 15:04:31 -0400
Subject: [Backgroundrb-devel] render_to_string from within the worker?
Message-ID: <298c4d2a0706111204jca50acfm99f6b4d821e8bf99@mail.gmail.com>

Is it possible to call render_to_string from with in a brb worker?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070611/21c1821a/attachment.html 

From jgarten at postful-inc.com  Mon Jun 11 17:55:40 2007
From: jgarten at postful-inc.com (Justin Garten)
Date: Mon, 11 Jun 2007 14:55:40 -0700
Subject: [Backgroundrb-devel] smtp timeout failures
Message-ID: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>

Hi.

I'm using backgroundrb to, in part, wrap smtp transactions made through
actionmailer.  The problem is that when smtp fails with a timeout error, the
worker simply stops at that point.

No exception is returned. I've tried wrapping this call in a begin...rescue
block but no exception seems to be making it back to the worker (other
methods are correctly passing exceptions to the worker).

I've tested to see if this is an issue of the delay prior to the exception
being thrown by creating a method that sleeps prior to throwing an exception
but this is passed through and caught without issue.

When I generate smtp timeout errors in console, I receive the exception
normally.  I'm trying to figure out what could be different about the
combination of backgroundrb and actionmailer.

If anyone has suggestions for what else I can try in testing this or has
experience with this, I'd very much appreciate the help.

Thanks in advance!

-Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070611/a10f04ef/attachment.html 

From dtown22 at gmail.com  Tue Jun 12 12:42:11 2007
From: dtown22 at gmail.com (dtown)
Date: Tue, 12 Jun 2007 09:42:11 -0700
Subject: [Backgroundrb-devel] smtp timeout failures
In-Reply-To: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
References: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
Message-ID: <778fbc270706120942q41a49f78w38adc997d649673e@mail.gmail.com>

Hi Justin,

I am experiencing a similar problem. I am performing some screen scraping,
and then sending out emails. My worker basically starts once, has a sleep
call, to ensure it runs every hour...but eventually, after a while it just
stops running.

I believe this problem is related to the mailer (sendmail) in my case, but i
cant seem to track it down, and no exception is thrown.

On 6/11/07, Justin Garten <jgarten at postful-inc.com> wrote:
>
> Hi.
>
> I'm using backgroundrb to, in part, wrap smtp transactions made through
> actionmailer.  The problem is that when smtp fails with a timeout error, the
> worker simply stops at that point.
>
> No exception is returned. I've tried wrapping this call in a
> begin...rescue block but no exception seems to be making it back to the
> worker (other methods are correctly passing exceptions to the worker).
>
> I've tested to see if this is an issue of the delay prior to the exception
> being thrown by creating a method that sleeps prior to throwing an exception
> but this is passed through and caught without issue.
>
> When I generate smtp timeout errors in console, I receive the exception
> normally.  I'm trying to figure out what could be different about the
> combination of backgroundrb and actionmailer.
>
> If anyone has suggestions for what else I can try in testing this or has
> experience with this, I'd very much appreciate the help.
>
> Thanks in advance!
>
> -Justin
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070612/117cc944/attachment.html 

From ruby at geoffgarside.co.uk  Tue Jun 12 15:13:56 2007
From: ruby at geoffgarside.co.uk (Geoff Garside)
Date: Tue, 12 Jun 2007 20:13:56 +0100
Subject: [Backgroundrb-devel] smtp timeout failures
In-Reply-To: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
References: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
Message-ID: <151AF2C5-1E6E-40F7-9D57-4F8CF467038F@geoffgarside.co.uk>

Have you tried wrapping the delivery in a Timeout block? Something  
along the lines of

	begin
		Timeout::timeout(15) do
			ActionMailer.stuff(weeeee)
		end
	rescue Timeout::Error
		# ActionMailer took too long
	end

It might work, but I have admittely not tested this in the least.

Geoff


On 11 Jun 2007, at 22:55, Justin Garten wrote:

> Hi.
>
> I'm using backgroundrb to, in part, wrap smtp transactions made  
> through actionmailer.  The problem is that when smtp fails with a  
> timeout error, the worker simply stops at that point.
>
> No exception is returned. I've tried wrapping this call in a  
> begin...rescue block but no exception seems to be making it back to  
> the worker (other methods are correctly passing exceptions to the  
> worker).
>
> I've tested to see if this is an issue of the delay prior to the  
> exception being thrown by creating a method that sleeps prior to  
> throwing an exception but this is passed through and caught without  
> issue.
>
> When I generate smtp timeout errors in console, I receive the  
> exception normally.  I'm trying to figure out what could be  
> different about the combination of backgroundrb and actionmailer.
>
> If anyone has suggestions for what else I can try in testing this  
> or has experience with this, I'd very much appreciate the help.
>
> Thanks in advance!
>
> -Justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070612/0a287c93/attachment.html 

From jgarten at postful-inc.com  Tue Jun 12 15:32:27 2007
From: jgarten at postful-inc.com (Justin Garten)
Date: Tue, 12 Jun 2007 12:32:27 -0700
Subject: [Backgroundrb-devel] smtp timeout failures
In-Reply-To: <4cdd0d160706111714h4964f89v87b02a7fc7b582c5@mail.gmail.com>
References: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
	<4cdd0d160706111714h4964f89v87b02a7fc7b582c5@mail.gmail.com>
Message-ID: <ace9af700706121232q79fa4e42k234473914eb0dd46@mail.gmail.com>

Wil,
Thank you for the pointer.  I changed the line, but unfortunately that
doesn't seem to be the problem.  I added some statements around it just to
make sure, but that doesn't seem to be where things are catching in this
case (although it's great to have one bug out of the way _before_ I hit it).


-Justin

On 6/11/07, Wil Chung <iamwil at gmail.com> wrote:
>
> I've had similar problems too, but Mathias Meyer pointed out that the
> problem is probably
>
> line 48 of server/lib/backgroundrb/scheduler.rb.
>
> http://rubyforge.org/pipermail/backgroundrb-devel/2007-April/<http://rubyforge.org/pipermail/backgroundrb-devel/2007-April/000875.html>
> 000875.html<http://rubyforge.org/pipermail/backgroundrb-devel/2007-April/000875.html>
>
> I tried it and it seems to spit back exceptions now, in the
> background_server.log.
>
> It was suggested about a month or two ago, but it hasn't made it into a
> new release.  So you can try monkey patching it yourself, or try to find a
> way to submit a patch.
>
> Wil
>
> On 6/11/07, Justin Garten <jgarten at postful-inc.com> wrote:
>
> > Hi.
> >
> > I'm using backgroundrb to, in part, wrap smtp transactions made through
> > actionmailer.  The problem is that when smtp fails with a timeout error, the
> > worker simply stops at that point.
> >
> > No exception is returned. I've tried wrapping this call in a
> > begin...rescue block but no exception seems to be making it back to the
> > worker (other methods are correctly passing exceptions to the worker).
> >
> > I've tested to see if this is an issue of the delay prior to the
> > exception being thrown by creating a method that sleeps prior to throwing an
> > exception but this is passed through and caught without issue.
> >
> > When I generate smtp timeout errors in console, I receive the exception
> > normally.  I'm trying to figure out what could be different about the
> > combination of backgroundrb and actionmailer.
> >
> > If anyone has suggestions for what else I can try in testing this or has
> > experience with this, I'd very much appreciate the help.
> >
> > Thanks in advance!
> >
> > -Justin
> >
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
>
>
>
> --
> http://www.3cglabs.com
> http://thoughtl.us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070612/2605d060/attachment.html 

From jgarten at postful-inc.com  Tue Jun 12 15:32:56 2007
From: jgarten at postful-inc.com (Justin Garten)
Date: Tue, 12 Jun 2007 12:32:56 -0700
Subject: [Backgroundrb-devel] smtp timeout failures
In-Reply-To: <151AF2C5-1E6E-40F7-9D57-4F8CF467038F@geoffgarside.co.uk>
References: <ace9af700706111455j4e631c3brfd953091b50790b2@mail.gmail.com>
	<151AF2C5-1E6E-40F7-9D57-4F8CF467038F@geoffgarside.co.uk>
Message-ID: <ace9af700706121232wda0c3adh3ee6562f38a8a34@mail.gmail.com>

Geoff,

I tried this previously, thinking that it would at least catch and repackage
the exception in a way that might make it through to backgroundrb, but it
didn't help.  Since I have no problem with other exceptions being passed
through, I was surprised that this didn't work.

I must admit, I'm quite stumped at this point.

-Justin

On 6/12/07, Geoff Garside <ruby at geoffgarside.co.uk> wrote:
>
> Have you tried wrapping the delivery in a Timeout block? Something along
> the lines of
> begin
> Timeout::timeout(15) do
> ActionMailer.stuff(weeeee)
> end
> rescue Timeout::Error
> # ActionMailer took too long
> end
>
> It might work, but I have admittely not tested this in the least.
>
> Geoff
>
>
> On 11 Jun 2007, at 22:55, Justin Garten wrote:
>
> Hi.
>
> I'm using backgroundrb to, in part, wrap smtp transactions made through
> actionmailer.  The problem is that when smtp fails with a timeout error, the
> worker simply stops at that point.
>
> No exception is returned. I've tried wrapping this call in a
> begin...rescue block but no exception seems to be making it back to the
> worker (other methods are correctly passing exceptions to the worker).
>
> I've tested to see if this is an issue of the delay prior to the exception
> being thrown by creating a method that sleeps prior to throwing an exception
> but this is passed through and caught without issue.
>
> When I generate smtp timeout errors in console, I receive the exception
> normally.  I'm trying to figure out what could be different about the
> combination of backgroundrb and actionmailer.
>
> If anyone has suggestions for what else I can try in testing this or has
> experience with this, I'd very much appreciate the help.
>
> Thanks in advance!
>
> -Justin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070612/6aa0e6e3/attachment-0001.html 

From charlesmbowman at gmail.com  Tue Jun 19 10:39:09 2007
From: charlesmbowman at gmail.com (Charlie Bowman)
Date: Tue, 19 Jun 2007 10:39:09 -0400
Subject: [Backgroundrb-devel] recycled objects and gc problem
Message-ID: <298c4d2a0706190739q448f430av532d3dfa6f474f14@mail.gmail.com>

I've been digging around all morning through google trying to understand the
problem of recycled objects.  I'm only getting the error sometimes, so its
very had to track down.  I dont think I'm using any variables in my worker
that come from the app so I'm not sure what is being gc'd that is causing
the errors.  You can see that the real work isn't being done in the drb but
in my models.  I do this to help ease testing of these methods.  Is my woker
causing the recycled object errors?


class GrabFeedWorker < BackgrounDRb::Worker::RailsBase
  require 'net/http'
  require 'simple-rss'
  def do_work(args)
    Space.find(args[:space]).update_all_syndications if args[:space]
    Feed.find(args[:feed]).update_feed if args[:feed]
    self.delete
  end

end
GrabFeedWorker.register
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070619/7722678a/attachment.html 

From fredix at gmail.com  Wed Jun 20 19:41:04 2007
From: fredix at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Logier?=)
Date: Thu, 21 Jun 2007 01:41:04 +0200
Subject: [Backgroundrb-devel] send objet between 2 workers
Message-ID: <d7ca1a4b0706201641v326178d9ieda8dae95b1ee3df@mail.gmail.com>

Hi,

I'm using backgroundrb but I have 2 problems with it.

First is when I launch a thread Toto from the do_work method. Toto can't
access to a class variable defined before... (undefined method `+' for
nil:NilClass)
I suspect that thread is launched when backgroundrb start but the worker not
..

My code is :

class MonWorker < BackgrounDRb::Worker::RailsBase
  attr_reader :mavar_send, :mavar_receive

  @@mavar_send, @@mavar_receive = 0

def do_work(args)
   trace = Thread.new{t_trace}
   trace.join
end


def t_trace
  while true
    @@mavar_send += 1
    sleep 1
  end
end


Second is I'm trying to call a worker from another to send it an object, is
it possible ?
job =MiddleMan.worker(:second_worker) doesn't work in my first worker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070621/9ef42cbe/attachment.html 

From fredix at gmail.com  Thu Jun 21 09:52:31 2007
From: fredix at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Logier?=)
Date: Thu, 21 Jun 2007 15:52:31 +0200
Subject: [Backgroundrb-devel] send objet between 2 workers
In-Reply-To: <d7ca1a4b0706201641v326178d9ieda8dae95b1ee3df@mail.gmail.com>
References: <d7ca1a4b0706201641v326178d9ieda8dae95b1ee3df@mail.gmail.com>
Message-ID: <d7ca1a4b0706210652m1e8b3947y98156d86e308ff9a@mail.gmail.com>

2007/6/21, Fr?d?ric Logier :
>
>
> Second is I'm trying to call a worker from another to send it an object,
> is it possible ?
> job =MiddleMan.worker(:second_worker) doesn't work in my first worker.


I see this bug report :
http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/55
but I don't understand this : "I can pass the actual worker reference into
the other workers in args and that works"

I tried this but it doesn't work better, second worker crash :


s_worker = MiddleMan.new_worker(:class => :FIRSTWorker,
                                    :job_key => :first_worker,
                                    :args => "")

 MiddleMan.new_worker(:class => :SECONDWorker,
                                   :job_key => :second_worker,
                                    :args => {:sms_job_key => s_worker})


def do_work(args)
   @sms_worker = args[:sms_job_key]
end


def test
  @sms_worker.test("hello")
end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070621/767d6bc5/attachment.html 

From fredix at gmail.com  Thu Jun 21 10:30:03 2007
From: fredix at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Logier?=)
Date: Thu, 21 Jun 2007 16:30:03 +0200
Subject: [Backgroundrb-devel] send objet between 2 workers
In-Reply-To: <d7ca1a4b0706210652m1e8b3947y98156d86e308ff9a@mail.gmail.com>
References: <d7ca1a4b0706201641v326178d9ieda8dae95b1ee3df@mail.gmail.com>
	<d7ca1a4b0706210652m1e8b3947y98156d86e308ff9a@mail.gmail.com>
Message-ID: <d7ca1a4b0706210730g771ad8b1xadc603dbc336322f@mail.gmail.com>

2007/6/21, Fr?d?ric Logier :
>
>
> I tried this but it doesn't work better, second worker crash :
>
>
> s_worker = MiddleMan.new_worker(:class => :FIRSTWorker,
>                                     :job_key => :first_worker,
>                                     :args => "")
>
>  MiddleMan.new_worker(:class => :SECONDWorker,
>                                    :job_key => :second_worker,
>                                     :args => {:sms_job_key => s_worker})
>



works better with     s_worker = MiddleMan.worker(:sms_worker) before !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070621/0bfcda0e/attachment.html 

From charlesmbowman at gmail.com  Thu Jun 21 15:20:06 2007
From: charlesmbowman at gmail.com (Charlie Bowman)
Date: Thu, 21 Jun 2007 15:20:06 -0400
Subject: [Backgroundrb-devel] config file questions
Message-ID: <298c4d2a0706211220mdecfa88ydae99dea838bf197@mail.gmail.com>

example:

:host: 192.168.1.101
:protocol: druby
:worker_dir: lib/workers
:rails_env: production
:pool_size: 15
:load_rails: true
:timer_sleep: 60
:acl:
  :deny: all
  :allow: localhost 192.168.1.*
  :order: deny allow

I have this config file on 2 app servers running rails.  The 2 servers are
running behind a load balancer.  I'm starting the backgroundrb server on the
one server with the ip of 192.168.1.101.  Each time I try to call an action
that uses backgroundrb I get the followng error.  If I'm using druby, why do
I get the following error message?

drbunix:///tmp/backgroundrbunix_localhost_2000 - #

Doesn't the error tell me that I'm using drbunix?  I'll also post my
backgroundrb_sever.log.  I'm stumped and very confused on what to do next.
Thank you for any possible help!

20070621-14:59:39 (10124) Starting BackgrounDRb Server
20070621-14:59:39 (10124) config: config/backgroundrb/production.yml
20070621-14:59:39 (10124) rails_env: production
20070621-14:59:39 (10124) socket_dir: /tmp/backgroundrb.10124
20070621-14:59:39 (10124) pool_size: 15
20070621-14:59:39 (10124) host: 192.168.1.101
20070621-14:59:39 (10124) acl: orderdeny allowdenyallallowlocalhost
192.168.1.*
20070621-14:59:39 (10124) temp_dir: /tmp
20070621-14:59:39 (10124) port: 2000
20070621-14:59:39 (10124) load_rails: true
20070621-14:59:39 (10124) worker_dir: /var/www/near-
time.net/releases/20070621035836/lib/workers
20070621-14:59:39 (10124) protocol: druby
20070621-14:59:39 (10124) uri: druby://192.168.1.101:2000
20070621-14:59:39 (10124) timer_sleep: 60
20070621-14:59:39 (10124) Installed DRb ACL
20070621-14:59:41 (10127) Starting worker:
BackgrounDRb::Worker::WorkerLogger backgroundrb_logger (backgroundrb_logger)
()
20070621-14:59:41 (10127) Starting worker:
BackgrounDRb::Worker::WorkerResults backgroundrb_results
(backgroundrb_results) ()
20070621-14:59:41 (10127) Loading Worker Class File: /var/www/near-
time.net/releases/20070621035836/lib/workers/grab_feed_worker.rb
20070621-14:59:41 (10127) Loading Worker Class File: /var/www/near-
time.net/releases/20070621035836/lib/workers/unzip_worker.rb

3809,1        Bot


Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070621/d298f25c/attachment.html 

From kenneth.kalmer at gmail.com  Sun Jun 24 16:46:01 2007
From: kenneth.kalmer at gmail.com (Kenneth Kalmer)
Date: Sun, 24 Jun 2007 22:46:01 +0200
Subject: [Backgroundrb-devel] Two quick questions (future & windows)
Message-ID: <fad9d4840706241346m543a0cd3pd13c84812211c7f7@mail.gmail.com>

Howdy all

First off, thanks to Ezra & skaar (and all the other contributors) for
the plugin. It's been a great help the last couple of days.

1. I explored the trac site, and saw that commits recently have been
few and far between. Is the project on the way down or is it a lack of
time and resources? (Between the lines, is the next release gonna
happen and will patches still be excepted?)

2. The Windows issue is a contentious one, not that it bothers me
since our entire dev team in on Linux. On an existing project we are
working with some designers that use Windows, and since the
BackgrounDrb integration into trunk today we've had some issues. Wait
before you throw me with the "it is deprecated"...

2 (cont) I made a mock MiddleMan that doesn't background, but calls
the worker in a blocking fashion. Admittedly this is not the best
move, but a step towards some limited (and I'll keep it at limited)
Windows "compatibility mode". See
http://backgroundrb.devjavu.com/projects/backgroundrb/ticket/42#comment:1
for the patch.

2 (actual question) Will Windows support ever return or are we sending
them packing?

I hope this helps somebody else who has non-core team members that
can't work because their on Windows...

Best

-- 

Kenneth Kalmer
kenneth.kalmer at gmail.com

Folding at home stats
http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

From tiberiu_motoc at yahoo.ca  Sun Jun 24 20:28:05 2007
From: tiberiu_motoc at yahoo.ca (Tiberiu Motoc)
Date: Sun, 24 Jun 2007 20:28:05 -0400 (EDT)
Subject: [Backgroundrb-devel] one more "uninitialized constant" problem
Message-ID: <103405.12797.qm@web30513.mail.mud.yahoo.com>

Hi everyone,
   
  I'm new to backgroundrb, and I'm trying to get started with a simple example, yet with no success.
   
  This is the code that I have in RAILS_ROOT/lib/workers/testing_worker.rb
  class TestingWorker < BackgrounDRb::Worker::RailsBase
    def do_work(args)
    # This method is called in it's own new thread when you
    # call new worker. args is set to :args
      logger.info('TestingWorker do work')
    results[:do_work_time] = Time.now_to_s
    results[:done_with_do_work] || = true
  end
  end
   
  And this is the code that I have in RAILS_ROOT/app/controllers/mytest2_controller.rb
  class Mytest2Controller < ApplicationController
  def new
    key = MiddleMan.new_worker(:class => :testing_worker)
    worker = MiddleMan.worker(key)
    #worker.other_method
    #worker.delete
  end
end
   
  And this is what I get when I access: http://host:3000/mytest2/new
   NameError in Mytest2Controller#new
   uninitialized constant TestingWorker
 RAILS_ROOT: script/../config/..
 Application Trace | Framework Trace | Full Trace
   
  I don't understand why I'm getting the "uninitialized constant" error. I've read other postings with the same issue, and I understand that you must restart the server after adding/making modifications to your workers. The server is restarted with the following commands: ./script/backgroundrb stop and ./script/bacgroundrb start, right? (I don't even think this applies to me, since first I created all necessary files for the example and then I started the server; I did restart the server several times just to make sure this is not a problem)
  I also tried to use the console and I get a similar message.
  Btw, I have changed nothing in the default setup, except in /server/lib/backgroundrb/console.rb, where I commented out the line "require 'irb/completion'" due to a strange error that I was getting.
   
  Thanks,
  Tiberiu
   
  PS. I want to make sure that the way I downloaded backgroundrb is not faulty. Instead of getting it via subversion (trying to save time by not involving my admin), I just downloaded file by file from http://svn.devjavu.com/backgroundrb/tags/release-0.2.1.

       
---------------------------------
Ask a question on any topic and get answers from real people. Go to Yahoo! Answers. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070624/05ee1b56/attachment-0001.html 

From ruby at geoffgarside.co.uk  Mon Jun 25 03:42:15 2007
From: ruby at geoffgarside.co.uk (Geoff Garside)
Date: Mon, 25 Jun 2007 08:42:15 +0100
Subject: [Backgroundrb-devel] one more "uninitialized constant" problem
In-Reply-To: <103405.12797.qm@web30513.mail.mud.yahoo.com>
References: <103405.12797.qm@web30513.mail.mud.yahoo.com>
Message-ID: <754A2696-F603-4EAA-9A22-1C8D611A7A37@geoffgarside.co.uk>

On 25 Jun 2007, at 01:28, Tiberiu Motoc wrote:

> Hi everyone,
>
> I'm new to backgroundrb, and I'm trying to get started with a  
> simple example, yet with no success.
>
> This is the code that I have in RAILS_ROOT/lib/workers/ 
> testing_worker.rb
> class TestingWorker < BackgrounDRb::Worker::RailsBase
>   def do_work(args)
>     # This method is called in it's own new thread when you
>     # call new worker. args is set to :args
>     logger.info('TestingWorker do work')
>     results[:do_work_time] = Time.now_to_s
>     results[:done_with_do_work] || = true
>   end
> end

Do you have

	TestingWorker.register

at the end of the testing_worker.rb file?

>
> And this is the code that I have in RAILS_ROOT/app/controllers/ 
> mytest2_controller.rb
> class Mytest2Controller < ApplicationController
>   def new
>     key = MiddleMan.new_worker(:class => :testing_worker)
>     worker = MiddleMan.worker(key)
>     #worker.other_method
>     #worker.delete
>   end
> end
>
> And this is what I get when I access: http://host:3000/mytest2/new
>  NameError in Mytest2Controller#new
>  uninitialized constant TestingWorker
>  RAILS_ROOT: script/../config/..
>  Application Trace | Framework Trace | Full Trace
>
> I don't understand why I'm getting the "uninitialized constant"  
> error. I've read other postings with the same issue, and I  
> understand that you must restart the server after adding/making  
> modifications to your workers. The server is restarted with the  
> following commands: ./script/backgroundrb stop and ./script/ 
> bacgroundrb start, right? (I don't even think this applies to me,  
> since first I created all necessary files for the example and then  
> I started the server; I did restart the server several times just  
> to make sure this is not a problem)
> I also tried to use the console and I get a similar message.
> Btw, I have changed nothing in the default setup, except in /server/ 
> lib/backgroundrb/console.rb, where I commented out the line  
> "require 'irb/completion'" due to a strange error that I was getting.
>
> Thanks,
> Tiberiu
>
> PS. I want to make sure that the way I downloaded backgroundrb is  
> not faulty. Instead of getting it via subversion (trying to save  
> time by not involving my admin), I just downloaded file by file  
> from http://svn.devjavu.com/backgroundrb/tags/release-0.2.1.
>
> Ask a question on any topic and get answers from real people. Go to  
> Yahoo! Answers.
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Regards,
Geoff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070625/2398907d/attachment.html 

From tiberiu_motoc at yahoo.ca  Mon Jun 25 13:52:32 2007
From: tiberiu_motoc at yahoo.ca (Tiberiu Motoc)
Date: Mon, 25 Jun 2007 13:52:32 -0400 (EDT)
Subject: [Backgroundrb-devel] one more "uninitialized constant" problem
In-Reply-To: <754A2696-F603-4EAA-9A22-1C8D611A7A37@geoffgarside.co.uk>
Message-ID: <20070625175232.51814.qmail@web30504.mail.mud.yahoo.com>

Hi Geoff,
   
  Yes, I do have it at the end of the script. I just forgot to copy it in the message.
   
  Tiberiu

Geoff Garside <ruby at geoffgarside.co.uk> wrote:
      On 25 Jun 2007, at 01:28, Tiberiu Motoc wrote:

    Hi everyone,
   
  I'm new to backgroundrb, and I'm trying to get started with a simple example, yet with no success.
   
  This is the code that I have in RAILS_ROOT/lib/workers/testing_worker.rb
  class TestingWorker < BackgrounDRb::Worker::RailsBase
    def do_work(args)
    # This method is called in it's own new thread when you
    # call new worker. args is set to :args
      logger.info('TestingWorker do work')
    results[:do_work_time] = Time.now_to_s
    results[:done_with_do_work] || = true
  end
  end
  

  Do you have
  

  TestingWorker.register

  

  at the end of the testing_worker.rb file?

     
  And this is the code that I have in RAILS_ROOT/app/controllers/mytest2_controller.rb
  class Mytest2Controller < ApplicationController
  def new
    key = MiddleMan.new_worker(:class => :testing_worker)
    worker = MiddleMan.worker(key)
    #worker.other_method
    #worker.delete
  end
end
     
  And this is what I get when I access: http://host:3000/mytest2/new
   NameError in Mytest2Controller#new
   uninitialized constant TestingWorker
 RAILS_ROOT: script/../config/..
 Application Trace | Framework Trace | Full Trace
   
  I don't understand why I'm getting the "uninitialized constant" error. I've read other postings with the same issue, and I understand that you must restart the server after adding/making modifications to your workers. The server is restarted with the following commands: ./script/backgroundrb stop and ./script/bacgroundrb start, right? (I don't even think this applies to me, since first I created all necessary files for the example and then I started the server; I did restart the server several times just to make sure this is not a problem)
  I also tried to use the console and I get a similar message.
  Btw, I have changed nothing in the default setup, except in /server/lib/backgroundrb/console.rb, where I commented out the line "require 'irb/completion'" due to a strange error that I was getting.
   
  Thanks,
  Tiberiu
   
  PS. I want to make sure that the way I downloaded backgroundrb is not faulty. Instead of getting it via subversion (trying to save time by not involving my admin), I just downloaded file by file from http://svn.devjavu.com/backgroundrb/tags/release-0.2.1.
  

  
---------------------------------
  Ask a question on any topic and get answers from real people. Go to Yahoo! Answers.  _______________________________________________
  Backgroundrb-devel mailing list
  Backgroundrb-devel at rubyforge.org
  http://rubyforge.org/mailman/listinfo/backgroundrb-devel


  Regards,
  Geoff



       
---------------------------------
All new Yahoo! Mail  
---------------------------------
Get news delivered. Enjoy RSS feeds right on your Mail page.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070625/064ea1a8/attachment.html 

From ruby at geoffgarside.co.uk  Mon Jun 25 15:31:37 2007
From: ruby at geoffgarside.co.uk (Geoff Garside)
Date: Mon, 25 Jun 2007 20:31:37 +0100
Subject: [Backgroundrb-devel] one more "uninitialized constant" problem
In-Reply-To: <20070625175232.51814.qmail@web30504.mail.mud.yahoo.com>
References: <20070625175232.51814.qmail@web30504.mail.mud.yahoo.com>
Message-ID: <48F86888-C8A3-4B71-84FF-6657C5BE44F3@geoffgarside.co.uk>

Ah, think I see it now.

Try changing your TestingWorker to use Time.now.to_s not  
Time.now_to_s. If you check the backgroundrb log files you will  
probably see a no method error somewhere.

Geoff


On 25 Jun 2007, at 18:52, Tiberiu Motoc wrote:

> Hi Geoff,
>
> Yes, I do have it at the end of the script. I just forgot to copy  
> it in the message.
>
> Tiberiu
>
> Geoff Garside <ruby at geoffgarside.co.uk> wrote:
> On 25 Jun 2007, at 01:28, Tiberiu Motoc wrote:
>
>> Hi everyone,
>>
>> I'm new to backgroundrb, and I'm trying to get started with a  
>> simple example, yet with no success.
>>
>> This is the code that I have in RAILS_ROOT/lib/workers/ 
>> testing_worker.rb
>> class TestingWorker < BackgrounDRb::Worker::RailsBase
>>   def do_work(args)
>>     # This method is called in it's own new thread when you
>>     # call new worker. args is set to :args
>>     logger.info('TestingWorker do work')
>>     results[:do_work_time] = Time.now_to_s
>>     results[:done_with_do_work] || = true
>>   end
>> end
>
> Do you have
>
> TestingWorker.register
>
> at the end of the testing_worker.rb file?
>
>>
>> And this is the code that I have in RAILS_ROOT/app/controllers/ 
>> mytest2_controller.rb
>> class Mytest2Controller < ApplicationController
>>   def new
>>     key = MiddleMan.new_worker(:class => :testing_worker)
>>     worker = MiddleMan.worker(key)
>>     #worker.other_method
>>     #worker.delete
>>   end
>> end
>>
>> And this is what I get when I access: http://host:3000/mytest2/new
>>  NameError in Mytest2Controller#new
>>  uninitialized constant TestingWorker
>>  RAILS_ROOT: script/../config/..
>>  Application Trace | Framework Trace | Full Trace
>>
>> I don't understand why I'm getting the "uninitialized constant"  
>> error. I've read other postings with the same issue, and I  
>> understand that you must restart the server after adding/making  
>> modifications to your workers. The server is restarted with the  
>> following commands: ./script/backgroundrb stop and ./script/ 
>> bacgroundrb start, right? (I don't even think this applies to me,  
>> since first I created all necessary files for the example and then  
>> I started the server; I did restart the server several times just  
>> to make sure this is not a problem)
>> I also tried to use the console and I get a similar message.
>> Btw, I have changed nothing in the default setup, except in / 
>> server/lib/backgroundrb/console.rb, where I commented out the line  
>> "require 'irb/completion'" due to a strange error that I was getting.
>>
>> Thanks,
>> Tiberiu
>>
>> PS. I want to make sure that the way I downloaded backgroundrb is  
>> not faulty. Instead of getting it via subversion (trying to save  
>> time by not involving my admin), I just downloaded file by file  
>> from http://svn.devjavu.com/backgroundrb/tags/release-0.2.1.
>>
>> Ask a question on any topic and get answers from real people. Go  
>> to Yahoo! Answers.
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> Regards,
> Geoff
>
>
>
> All new Yahoo! Mail
> Get news delivered. Enjoy RSS feeds right on your Mail page.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070625/db007678/attachment.html 

From fredix at gmail.com  Tue Jun 26 17:56:55 2007
From: fredix at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Logier?=)
Date: Tue, 26 Jun 2007 23:56:55 +0200
Subject: [Backgroundrb-devel] 0.2.x new architecture ?
Message-ID: <d7ca1a4b0706261456k4bda042bi2dae124a084c2aa5@mail.gmail.com>

Hi,

I'm using the latest stable version (0.2.1 (Released November 28, 2006 -
r162)) and according to the web site :
"the new system uses multi process with IPC to manage workers.So each of
your workers will run in their own ruby interpreter."

I supposed that each worker run in is own process. That isn't true. I
defined the same instance variable (@toto) in the do_work methods of each
worker, and @toto is shared between of them. Is it normal ?
In fact, it seems that each worker run in a thread of the backgroundrb
process.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070626/8df745fe/attachment-0001.html 

From raasdnil at gmail.com  Tue Jun 26 22:25:35 2007
From: raasdnil at gmail.com (Mikel Lindsaar)
Date: Wed, 27 Jun 2007 12:25:35 +1000
Subject: [Backgroundrb-devel] Debugging Workers
Message-ID: <57a815bf0706261925n6ad89490v21feec97fca659fa@mail.gmail.com>

Hello all,

I just looked through the list and didn't find a good answer to this..
so posting away.

I have some backgorunDRB workers that are all working nicely.  In
fact, I have no problem right now.

But when i was doing the coding, I found a need occasionally to fire
up the debugger and have a look at what was going on inside, but found
no way to do this directly.

Is there a way to run the debugger interactively on a BackgrounDRB task?

My work around was to take the code out of a worker and put it in a
standard class in my lib dir... this works to some extent.

On the other hand, my final implementation has the backgrounDRB worker
not doing a lot of code, as I consider it a bit of a controller in the
MVC view in Rails and instead, all it is doing is directing several
classes and modules to do the hard work.  It just co-ordinates and
runs it all.  So in this case, having a debugger is something that
when you need it, you need it :)

The other option is sprinkling the code with @logger calls... but this
is a hack.  Ideas anyone?

Regards

Mikel

From tieg.zaharia at gmail.com  Wed Jun 27 11:48:29 2007
From: tieg.zaharia at gmail.com (Tieg Zaharia)
Date: Wed, 27 Jun 2007 11:48:29 -0400
Subject: [Backgroundrb-devel] struggling with stability
Message-ID: <156c5bc40706270848p5c2eb834kfb1c68baa4adf43f@mail.gmail.com>

Re: Jodi's post,

I'm having the same problem just today (don't think I've had this before),
and only when I feed it a custom background.yml file. Here's the error:

20070627-11:36:28 (1804) Starting BackgrounDRb Server
20070627-11:36:28 (1804) config: RAILS_ROOT/config/backgroundrb.yml
20070627-11:36:28 (1804) rails_env: development
20070627-11:36:28 (1804) socket_dir: RAILS_ROOT/tmp/backgroundrb.1804
20070627-11:36:28 (1804) pool_size: 5
20070627-11:36:28 (1804) host: localhost
20070627-11:36:28 (1804) acl: orderdenyallowdenyallallowlocalhost 127.0.0.1
20070627-11:36:28 (1804) temp_dir: RAILS_ROOT/tmp
20070627-11:36:28 (1804) port: 2000
20070627-11:36:28 (1804) worker_dir: RAILS_ROOT/lib/workers
20070627-11:36:28 (1804) protocol: drbunix
20070627-11:36:28 (1804) uri:
drbunix:///RAILS_ROOT/tmp/backgroundrbunix_localhost_2000
20070627-11:36:29 (1806) Starting worker: BackgrounDRb::Worker::WorkerLogger
backgroundrb_logger (backgroundrb_logger) ()
20070627-11:36:29 (1806) failed to find slave socket - (RuntimeError)
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/slave-1.2.1/lib/slave.rb:435:in
`initialize'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
`new'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:210:in
`new_worker'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:36:in
`dispatch'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`initialize'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`new'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/thread_pool.rb:22:in
`dispatch'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:199:in
`new_worker'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb/middleman.rb:103:in
`setup'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:306:in
`run'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in
`call'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:193:in
`start_proc'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/daemonize.rb:192:in
`call'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/daemonize.rb:192:in
`call_as_daemon'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:197:in
`start_proc'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/application.rb:233:in
`start'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/controller.rb:69:in
`run'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:185:in
`run_proc'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in
`call'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons/cmdline.rb:105:in
`catch_exceptions'
20070627-11:36:29 (1806)
/usr/local/lib/ruby/gems/1.8/gems/daemons-1.0.6/lib/daemons.rb:184:in
`run_proc'
20070627-11:36:29 (1806)
RAILS_ROOT/vendor/plugins/backgroundrb/server/lib/backgroundrb_server.rb:301:in
`run'
20070627-11:36:29 (1806) script/backgroundrb:29
20070627-11:36:29 (1806) Loading Worker Class File:
RAILS_ROOT/lib/workers/my_worker.rb

And I only used a minimal config file to change the tmp directory:
---
:temp_dir: "RAILS_ROOT/tmp"

(the RAILS_ROOT in all of this is just a replacement for the paths to my
app)
I just noticed this problem and haven't even started to dig into it yet, but
it looks like feeding it a custom temp dir messes up the slave somehow? I
tried replacing the temp_dir via the command line args and it still happens.

environment:
- OSX 10.4.10
- ruby 1.8.4 (2005-12-24) [x86_64-linux]
- ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-darwin8.8.5]
- rails EDGE
- slave (1.2.1)
- daemons (1.0.6)
- mysql 5.0.27


-tieg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070627/aff60354/attachment.html 

From jordan at digitalignition.com  Sat Jun 30 12:48:32 2007
From: jordan at digitalignition.com (Jordan Glasner)
Date: Sat, 30 Jun 2007 12:48:32 -0400
Subject: [Backgroundrb-devel] Worker that launches workers?
Message-ID: <CB4DF16E-1416-4CC7-A726-F9695F29415E@digitalignition.com>

I'm just getting started with backgroundRb and have run into a bit of  
problem...

I want to have my controller launch one worker which in turn launches  
multiple child workers. When trying to use MiddleMan.new_worker in  
the parent worker I get a "recycled object" error.

Is it not possible to launch workers from within another worker?

TIA, for any help.

- Jordan Glasner

From jodi at nnovation.ca  Sat Jun 30 13:03:56 2007
From: jodi at nnovation.ca (Jodi Showers)
Date: Sat, 30 Jun 2007 13:03:56 -0400
Subject: [Backgroundrb-devel] struggling with stability
In-Reply-To: <156c5bc40706270848p5c2eb834kfb1c68baa4adf43f@mail.gmail.com>
References: <156c5bc40706270848p5c2eb834kfb1c68baa4adf43f@mail.gmail.com>
Message-ID: <A89FC2B3-C057-47BA-B724-C1288B3D1D68@nNovation.ca>

Greetings Tieg,

On 27-Jun-07, at 11:48 AM, Tieg Zaharia wrote:

> Re: Jodi's post,
>
> I'm having the same problem just today (don't think I've had this  
> before), and only when I feed it a custom background.yml file.  
> Here's the error:
>
> 20070627-11:36:28 (1804) Starting BackgrounDRb Server
> 20070627-11:36:28 (1804) config: RAILS_ROOT/config/backgroundrb.yml
> 20070627-11:36:28 (1804) rails_env: development
> 20070627-11:36:28 (1804) socket_dir: RAILS_ROOT/tmp/backgroundrb.1804
> 20070627-11:36:28 (1804) pool_size: 5
> 20070627-11:36:28 (1804) host: localhost
> 20070627-11:36:28 (1804) acl: orderdenyallowdenyallallowlocalhost  
> 127.0.0.1
> 20070627-11:36:28 (1804) temp_dir: RAILS_ROOT/tmp
> 20070627-11:36:28 (1804) port: 2000
> 20070627-11:36:28 (1804) worker_dir: RAILS_ROOT/lib/workers
> 20070627-11:36:28 (1804) protocol: drbunix
> 20070627-11:36:28 (1804) uri: drbunix:///RAILS_ROOT/tmp/ 
> backgroundrbunix_localhost_2000
> 20070627-11:36:29 (1806) Starting worker:  
> BackgrounDRb::Worker::WorkerLogger backgroundrb_logger  
> (backgroundrb_logger) ()
> 20070627-11:36:29 (1806) failed to find slave socket - (RuntimeError)
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> slave-1.2.1/lib/slave.rb:435:in `initialize'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/middleman.rb:210:in `new'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/middleman.rb:210:in `new_worker'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/thread_pool.rb:36:in `dispatch'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/thread_pool.rb:22:in `initialize'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/thread_pool.rb:22:in `new'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/thread_pool.rb:22:in `dispatch'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/middleman.rb:199:in `new_worker'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb/middleman.rb:103:in `setup'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb_server.rb:306:in `run'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/application.rb:193:in `call'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/application.rb:193:in `start_proc'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/daemonize.rb:192:in `call'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/daemonize.rb:192:in `call_as_daemon'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/application.rb:197:in `start_proc'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/application.rb:233:in `start'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/controller.rb:69:in `run'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons.rb:185:in `run_proc'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/cmdline.rb:105:in `call'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons/cmdline.rb:105:in `catch_exceptions'
> 20070627-11:36:29 (1806) /usr/local/lib/ruby/gems/1.8/gems/ 
> daemons-1.0.6/lib/daemons.rb:184:in `run_proc'
> 20070627-11:36:29 (1806) RAILS_ROOT/vendor/plugins/backgroundrb/ 
> server/lib/backgroundrb_server.rb:301:in `run'
> 20070627-11:36:29 (1806) script/backgroundrb:29
> 20070627-11:36:29 (1806) Loading Worker Class File: RAILS_ROOT/lib/ 
> workers/my_worker.rb
>
> And I only used a minimal config file to change the tmp directory:
> ---
> :temp_dir: "RAILS_ROOT/tmp"
>
> (the RAILS_ROOT in all of this is just a replacement for the paths  
> to my app)
> I just noticed this problem and haven't even started to dig into it  
> yet, but it looks like feeding it a custom temp dir messes up the  
> slave somehow? I tried replacing the temp_dir via the command line  
> args and it still happens.
>
> environment:
> - OSX 10.4.10
> - ruby 1.8.4 (2005-12-24) [x86_64-linux]
> - ruby 1.8.5 (2006-12-25 patchlevel 12) [i686-darwin8.8.5]
> - rails EDGE
> - slave (1.2.1)
> - daemons (1.0.6)
> - mysql 5.0.27
>

I have resorted to using Monit to keep backgroundrb up. Last week the  
app went 4 days without downtime - woop!

I'm quite convinced it's not an app specific problem - my tests are  
quite complete. And dev, staging and production show the same  
symptoms - unpredictable failures.

The only guess I have so far is that it maybe a resource contention  
issue - as long as I keep. My brb tasks ratchet up the ram usage to  
+80%.

Funny (not so actually) just checked my prod box and cp was at +95%,  
and 3 separate backgroundrb tasks were running (the dangers of using  
monit to heal processes!)

good luck
Jodi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070630/6d791709/attachment.html