From cbillen at warmlyyours.com  Wed Feb  4 12:26:51 2009
From: cbillen at warmlyyours.com (Christian Billen)
Date: Wed, 4 Feb 2009 11:26:51 -0600
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
Message-ID: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>

Good morning list,
We are a new user of BackgroundDrb and we use it to run specific cron-like
jobs at certain times of the day

What we've been noticing is that even when no jobs are running,
backgrounddrb will be running and 'humming' .  This happen as soon as
background drb is started. Notice the CPU usage for it and packet worker
will be between 4% to 7%

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND


22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby


22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68 packet_worker_r



My packet gem is at this release:
packet (0.1.14)

My backgrounddrb is at this release:
1.1

Running on ubuntu 8.10 x86 on slicehost

Here's our backgrounddrb.xml, i've tried with or without debug, as you can
see the script are only running once a day.

:backgroundrb:
  :ip: 0.0.0.0
  :port: 11006
  :debug_log: true

:schedules:
  :order_shipped_worker:
    :complete_orders:
      :trigger_args: 0 30 21 * * * *
    :reconcile_committed_items:
      :trigger_args: 0 0 22 * * * *
    :check_for_receipts:
      :trigger_args: 0 30 22 * * * *
  :exchange_rates_worker:
    :get_exchange_rates_for_today:
      :trigger_args: 0 0 6 * * * *
    :get_all_exchange_rates:
      :trigger_args: 0 30 6 1 * * *


Can anyone shed some light on how to debug or is this cpu usage normal?

Thank you


Christian Billen
Director of IT
Warmlyyours.com, inc.

Phone: (800) 875-5285 ext.800
Fax:      (847) 550-2600
Email:   cbillen at warmlyyours.com

WarmlyYours
Honeywell authorized licensee
2 Corporate Dr., Suite 100
Long Grove, Illinois 60047

Visit the WarmlyYours website at: www.warmlyyours.com

24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
Service
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090204/17ca9f6a/attachment.html>

From gethemant at gmail.com  Thu Feb  5 05:26:58 2009
From: gethemant at gmail.com (hemant)
Date: Thu, 5 Feb 2009 15:56:58 +0530
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
In-Reply-To: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
References: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
Message-ID: <fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>

I doubt there would be a problem with bdrb. However I would suggest
you to run your program with ruby-prof or use one of the memory
profiles (bleakhouse).

Try to reduce the case and paste your worker code.


On Wed, Feb 4, 2009 at 10:56 PM, Christian Billen
<cbillen at warmlyyours.com> wrote:
> Good morning list,
> We are a new user of BackgroundDrb and we use it to run specific cron-like
> jobs at certain times of the day
> What we've been noticing is that even when no jobs are running,
> backgrounddrb will be running and 'humming' .  This happen as soon as
> background drb is started. Notice the CPU usage for it and packet worker
> will be between 4% to 7%
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>
>
> 22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby
>
>
> 22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68 packet_worker_r
>
>
> My packet gem is at this release:
> packet (0.1.14)
>
> My backgrounddrb is at this release:
> 1.1
>
> Running on ubuntu 8.10 x86 on slicehost
> Here's our backgrounddrb.xml, i've tried with or without debug, as you can
> see the script are only running once a day.
> :backgroundrb:
>   :ip: 0.0.0.0
>   :port: 11006
>   :debug_log: true
> :schedules:
>   :order_shipped_worker:
>     :complete_orders:
>       :trigger_args: 0 30 21 * * * *
>     :reconcile_committed_items:
>       :trigger_args: 0 0 22 * * * *
>     :check_for_receipts:
>       :trigger_args: 0 30 22 * * * *
>   :exchange_rates_worker:
>     :get_exchange_rates_for_today:
>       :trigger_args: 0 0 6 * * * *
>     :get_all_exchange_rates:
>       :trigger_args: 0 30 6 1 * * *
>
> Can anyone shed some light on how to debug or is this cpu usage normal?
> Thank you
>
> Christian Billen
> Director of IT
> Warmlyyours.com, inc.
>
> Phone: (800) 875-5285 ext.800
> Fax:      (847) 550-2600
> Email:   cbillen at warmlyyours.com
>
> WarmlyYours
> Honeywell authorized licensee
> 2 Corporate Dr., Suite 100
> Long Grove, Illinois 60047
>
> Visit the WarmlyYours website at: www.warmlyyours.com
>
> 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
> Service
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the company.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>



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

From jmillr at umich.edu  Thu Feb  5 13:07:53 2009
From: jmillr at umich.edu (John Miller)
Date: Thu, 5 Feb 2009 13:07:53 -0500
Subject: [Backgroundrb-devel] newbie how to install
Message-ID: <E2782198-A3A2-4C7A-9F83-F10381D98FDE@umich.edu>

I'm following the directions at http://backgroundrb.rubyforge.org/

I've installed chronic and packet gems.

Then it says: you can install the plugin from git:

git clone git://github.com/gnufied/backgroundrb.git

BUT WHERE???

I did this at the root level of my rails app.

$ git clone git://github.com/gnufied/backgroundrb.git
Initialized empty Git repository in /Users/xxxxx/rails/xxxxx/ 
backgroundrb/.git/
remote: Counting objects: 1862, done.
remote: Compressing objects: 100% (732/732), done.
remote: Total 1862 (delta 1078), reused 1852 (delta 1073)
Receiving objects: 100% (1862/1862), 1.73 MiB | 885 KiB/s, done.
Resolving deltas: 100% (1078/1078), done.

So the git repository of backgroundrb is at the root level of my rails  
app. Now I'm supposed to run the rake task:

$ rake backgroundrb:setup
(in /Users/xxxxx/rails/xxxxx)
rake aborted!
Don't know how to build task 'backgroundrb:setup'

(See full trace by running task with --trace)

Now I'm stuck. Any suggestions? Thanks!

John


From enzodm at gmail.com  Thu Feb  5 14:29:53 2009
From: enzodm at gmail.com (Samer Masry)
Date: Thu, 5 Feb 2009 11:29:53 -0800
Subject: [Backgroundrb-devel] newbie how to install
In-Reply-To: <E2782198-A3A2-4C7A-9F83-F10381D98FDE@umich.edu>
References: <E2782198-A3A2-4C7A-9F83-F10381D98FDE@umich.edu>
Message-ID: <c9517bd80902051129r69fc1081ta7cdd9a46f5234db@mail.gmail.com>

It's a plugin that you need to install

do the git clone in vendor/plugins

or

./script/plugin install git://github.com/gnufied/backgroundrb.git

On Thu, Feb 5, 2009 at 10:07 AM, John Miller <jmillr at umich.edu> wrote:

> I'm following the directions at http://backgroundrb.rubyforge.org/
>
> I've installed chronic and packet gems.
>
> Then it says: you can install the plugin from git:
>
> git clone git://github.com/gnufied/backgroundrb.git
>
> BUT WHERE???
>
> I did this at the root level of my rails app.
>
> $ git clone git://github.com/gnufied/backgroundrb.git
> Initialized empty Git repository in
> /Users/xxxxx/rails/xxxxx/backgroundrb/.git/
> remote: Counting objects: 1862, done.
> remote: Compressing objects: 100% (732/732), done.
> remote: Total 1862 (delta 1078), reused 1852 (delta 1073)
> Receiving objects: 100% (1862/1862), 1.73 MiB | 885 KiB/s, done.
> Resolving deltas: 100% (1078/1078), done.
>
> So the git repository of backgroundrb is at the root level of my rails app.
> Now I'm supposed to run the rake task:
>
> $ rake backgroundrb:setup
> (in /Users/xxxxx/rails/xxxxx)
> rake aborted!
> Don't know how to build task 'backgroundrb:setup'
>
> (See full trace by running task with --trace)
>
> Now I'm stuck. Any suggestions? Thanks!
>
> John
>
> _______________________________________________
> 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/20090205/9d7b2fd5/attachment.html>

From cbillen at warmlyyours.com  Thu Feb  5 15:43:08 2009
From: cbillen at warmlyyours.com (Christian Billen)
Date: Thu, 5 Feb 2009 14:43:08 -0600
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
In-Reply-To: <fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>
References: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
	<fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>
Message-ID: <a5a491740902051243y31b2b7dfo8d3b70e0c5b90f9@mail.gmail.com>

Hi there,

Well I disabled the schedule for all the workers, so all i have left in
backgrounddrb.yml is


When I start backgrounddrb on Ubuntu 8.10 I get the 4-5% cpu humming on
packetworker and backgrounddrb.  I get this issue also on my rails app
running on Mac OS X 10.5

This is all I have in my backgrounddrb.yml:

:backgroundrb:
  :ip: 0.0.0.0
  :port: 11006

gem versions:

rails (2.2.2)
packet (0.1.14)
chronic (0.2.3)

Background drb installed from

sudo ./script/plugin install git://github.com/gnufied/backgroundrb.git

Since no background drb workers are running at all I do not know how to
profile this as you suggest.

Where else could look to determine where this is coming from?

Thank you

Christian Billen
Director of IT
Warmlyyours.com, inc.

Phone: (800) 875-5285 ext.800
Fax:      (847) 550-2600
Email:   cbillen at warmlyyours.com

WarmlyYours
Honeywell authorized licensee
2 Corporate Dr., Suite 100
Long Grove, Illinois 60047

Visit the WarmlyYours website at: www.warmlyyours.com

24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
Service
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the company.


On Thu, Feb 5, 2009 at 4:26 AM, hemant <gethemant at gmail.com> wrote:

> I doubt there would be a problem with bdrb. However I would suggest
> you to run your program with ruby-prof or use one of the memory
> profiles (bleakhouse).
>
> Try to reduce the case and paste your worker code.
>
>
> On Wed, Feb 4, 2009 at 10:56 PM, Christian Billen
> <cbillen at warmlyyours.com> wrote:
> > Good morning list,
> > We are a new user of BackgroundDrb and we use it to run specific
> cron-like
> > jobs at certain times of the day
> > What we've been noticing is that even when no jobs are running,
> > backgrounddrb will be running and 'humming' .  This happen as soon as
> > background drb is started. Notice the CPU usage for it and packet worker
> > will be between 4% to 7%
> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> >
> >
> > 22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby
> >
> >
> > 22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68
> packet_worker_r
> >
> >
> > My packet gem is at this release:
> > packet (0.1.14)
> >
> > My backgrounddrb is at this release:
> > 1.1
> >
> > Running on ubuntu 8.10 x86 on slicehost
> > Here's our backgrounddrb.xml, i've tried with or without debug, as you
> can
> > see the script are only running once a day.
> > :backgroundrb:
> >   :ip: 0.0.0.0
> >   :port: 11006
> >   :debug_log: true
> > :schedules:
> >   :order_shipped_worker:
> >     :complete_orders:
> >       :trigger_args: 0 30 21 * * * *
> >     :reconcile_committed_items:
> >       :trigger_args: 0 0 22 * * * *
> >     :check_for_receipts:
> >       :trigger_args: 0 30 22 * * * *
> >   :exchange_rates_worker:
> >     :get_exchange_rates_for_today:
> >       :trigger_args: 0 0 6 * * * *
> >     :get_all_exchange_rates:
> >       :trigger_args: 0 30 6 1 * * *
> >
> > Can anyone shed some light on how to debug or is this cpu usage normal?
> > Thank you
> >
> > Christian Billen
> > Director of IT
> > Warmlyyours.com, inc.
> >
> > Phone: (800) 875-5285 ext.800
> > Fax:      (847) 550-2600
> > Email:   cbillen at warmlyyours.com
> >
> > WarmlyYours
> > Honeywell authorized licensee
> > 2 Corporate Dr., Suite 100
> > Long Grove, Illinois 60047
> >
> > Visit the WarmlyYours website at: www.warmlyyours.com
> >
> > 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
> > Service
> > This email and any files transmitted with it are confidential and
> intended
> > solely for the use of the individual or entity to whom they are
> addressed.
> > If you have received this email in error please notify the system
> manager.
> > Please note that any views or opinions presented in this email are solely
> > those of the author and do not necessarily represent those of the
> company.
> >
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
>
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090205/99e25493/attachment-0001.html>

From cbillen at warmlyyours.com  Thu Feb  5 16:48:02 2009
From: cbillen at warmlyyours.com (Christian Billen)
Date: Thu, 5 Feb 2009 15:48:02 -0600
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
In-Reply-To: <c9517bd80902051345t2d3317d7r95f693c4ad82c8bd@mail.gmail.com>
References: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
	<fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>
	<a5a491740902051243y31b2b7dfo8d3b70e0c5b90f9@mail.gmail.com>
	<c9517bd80902051345t2d3317d7r95f693c4ad82c8bd@mail.gmail.com>
Message-ID: <a5a491740902051348t6656dd79udf297833694bb4f0@mail.gmail.com>

Hi,
I have tried with persistent off and debug log on, I tailed the debug log
file but see no activity, yet I still see cpu activity for the process.

Christian Billen
Director of IT
Warmlyyours.com, inc.

Phone: (800) 875-5285 ext.800
Fax:      (847) 550-2600
Email:   cbillen at warmlyyours.com

WarmlyYours
Honeywell authorized licensee
2 Corporate Dr., Suite 100
Long Grove, Illinois 60047

Visit the WarmlyYours website at: www.warmlyyours.com

24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
Service
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
Please note that any views or opinions presented in this email are solely
those of the author and do not necessarily represent those of the company.


On Thu, Feb 5, 2009 at 3:45 PM, Samer Masry <enzodm at gmail.com> wrote:

> I would turn on debug for active record and see if you can correlated the
> spikes of the cpu with the backgroundrb call to the db queue since you are
> using a persistant queue.
>
> Have a tail of your log file open and another window with top.
>
> -Samer Masry
> dryBlis
>
>
> On Thu, Feb 5, 2009 at 12:43 PM, Christian Billen <cbillen at warmlyyours.com
> > wrote:
>
>> Hi there,
>>
>> Well I disabled the schedule for all the workers, so all i have left in
>> backgrounddrb.yml is
>>
>>
>> When I start backgrounddrb on Ubuntu 8.10 I get the 4-5% cpu humming on
>> packetworker and backgrounddrb.  I get this issue also on my rails app
>> running on Mac OS X 10.5
>>
>> This is all I have in my backgrounddrb.yml:
>>
>> :backgroundrb:
>>   :ip: 0.0.0.0
>>   :port: 11006
>>
>> gem versions:
>>
>> rails (2.2.2)
>> packet (0.1.14)
>> chronic (0.2.3)
>>
>> Background drb installed from
>>
>> sudo ./script/plugin install git://github.com/gnufied/backgroundrb.git
>>
>> Since no background drb workers are running at all I do not know how to
>> profile this as you suggest.
>>
>> Where else could look to determine where this is coming from?
>>
>> Thank you
>>
>> Christian Billen
>> Director of IT
>> Warmlyyours.com, inc.
>>
>> Phone: (800) 875-5285 ext.800
>> Fax:      (847) 550-2600
>> Email:   cbillen at warmlyyours.com
>>
>> WarmlyYours
>> Honeywell authorized licensee
>> 2 Corporate Dr., Suite 100
>> Long Grove, Illinois 60047
>>
>> Visit the WarmlyYours website at: www.warmlyyours.com
>>
>> 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
>> Service
>> This email and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed.
>> If you have received this email in error please notify the system manager.
>> Please note that any views or opinions presented in this email are solely
>> those of the author and do not necessarily represent those of the company.
>>
>>
>> On Thu, Feb 5, 2009 at 4:26 AM, hemant <gethemant at gmail.com> wrote:
>>
>>> I doubt there would be a problem with bdrb. However I would suggest
>>> you to run your program with ruby-prof or use one of the memory
>>> profiles (bleakhouse).
>>>
>>> Try to reduce the case and paste your worker code.
>>>
>>>
>>> On Wed, Feb 4, 2009 at 10:56 PM, Christian Billen
>>> <cbillen at warmlyyours.com> wrote:
>>> > Good morning list,
>>> > We are a new user of BackgroundDrb and we use it to run specific
>>> cron-like
>>> > jobs at certain times of the day
>>> > What we've been noticing is that even when no jobs are running,
>>> > backgrounddrb will be running and 'humming' .  This happen as soon as
>>> > background drb is started. Notice the CPU usage for it and packet
>>> worker
>>> > will be between 4% to 7%
>>> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>> >
>>> >
>>> > 22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby
>>> >
>>> >
>>> > 22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68
>>> packet_worker_r
>>> >
>>> >
>>> > My packet gem is at this release:
>>> > packet (0.1.14)
>>> >
>>> > My backgrounddrb is at this release:
>>> > 1.1
>>> >
>>> > Running on ubuntu 8.10 x86 on slicehost
>>> > Here's our backgrounddrb.xml, i've tried with or without debug, as you
>>> can
>>> > see the script are only running once a day.
>>> > :backgroundrb:
>>> >   :ip: 0.0.0.0
>>> >   :port: 11006
>>> >   :debug_log: true
>>> > :schedules:
>>> >   :order_shipped_worker:
>>> >     :complete_orders:
>>> >       :trigger_args: 0 30 21 * * * *
>>> >     :reconcile_committed_items:
>>> >       :trigger_args: 0 0 22 * * * *
>>> >     :check_for_receipts:
>>> >       :trigger_args: 0 30 22 * * * *
>>> >   :exchange_rates_worker:
>>> >     :get_exchange_rates_for_today:
>>> >       :trigger_args: 0 0 6 * * * *
>>> >     :get_all_exchange_rates:
>>> >       :trigger_args: 0 30 6 1 * * *
>>> >
>>> > Can anyone shed some light on how to debug or is this cpu usage normal?
>>> > Thank you
>>> >
>>> > Christian Billen
>>> > Director of IT
>>> > Warmlyyours.com, inc.
>>> >
>>> > Phone: (800) 875-5285 ext.800
>>> > Fax:      (847) 550-2600
>>> > Email:   cbillen at warmlyyours.com
>>> >
>>> > WarmlyYours
>>> > Honeywell authorized licensee
>>> > 2 Corporate Dr., Suite 100
>>> > Long Grove, Illinois 60047
>>> >
>>> > Visit the WarmlyYours website at: www.warmlyyours.com
>>> >
>>> > 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
>>> > Service
>>> > This email and any files transmitted with it are confidential and
>>> intended
>>> > solely for the use of the individual or entity to whom they are
>>> addressed.
>>> > If you have received this email in error please notify the system
>>> manager.
>>> > Please note that any views or opinions presented in this email are
>>> solely
>>> > those of the author and do not necessarily represent those of the
>>> company.
>>> >
>>> > _______________________________________________
>>> > Backgroundrb-devel mailing list
>>> > Backgroundrb-devel at rubyforge.org
>>> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>> >
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/20090205/25d66114/attachment.html>

From enzodm at gmail.com  Thu Feb  5 16:45:36 2009
From: enzodm at gmail.com (Samer Masry)
Date: Thu, 5 Feb 2009 13:45:36 -0800
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
In-Reply-To: <a5a491740902051243y31b2b7dfo8d3b70e0c5b90f9@mail.gmail.com>
References: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
	<fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>
	<a5a491740902051243y31b2b7dfo8d3b70e0c5b90f9@mail.gmail.com>
Message-ID: <c9517bd80902051345t2d3317d7r95f693c4ad82c8bd@mail.gmail.com>

I would turn on debug for active record and see if you can correlated the
spikes of the cpu with the backgroundrb call to the db queue since you are
using a persistant queue.

Have a tail of your log file open and another window with top.

-Samer Masry
dryBlis

On Thu, Feb 5, 2009 at 12:43 PM, Christian Billen
<cbillen at warmlyyours.com>wrote:

> Hi there,
>
> Well I disabled the schedule for all the workers, so all i have left in
> backgrounddrb.yml is
>
>
> When I start backgrounddrb on Ubuntu 8.10 I get the 4-5% cpu humming on
> packetworker and backgrounddrb.  I get this issue also on my rails app
> running on Mac OS X 10.5
>
> This is all I have in my backgrounddrb.yml:
>
> :backgroundrb:
>   :ip: 0.0.0.0
>   :port: 11006
>
> gem versions:
>
> rails (2.2.2)
> packet (0.1.14)
> chronic (0.2.3)
>
> Background drb installed from
>
> sudo ./script/plugin install git://github.com/gnufied/backgroundrb.git
>
> Since no background drb workers are running at all I do not know how to
> profile this as you suggest.
>
> Where else could look to determine where this is coming from?
>
> Thank you
>
> Christian Billen
> Director of IT
> Warmlyyours.com, inc.
>
> Phone: (800) 875-5285 ext.800
> Fax:      (847) 550-2600
> Email:   cbillen at warmlyyours.com
>
> WarmlyYours
> Honeywell authorized licensee
> 2 Corporate Dr., Suite 100
> Long Grove, Illinois 60047
>
> Visit the WarmlyYours website at: www.warmlyyours.com
>
> 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
> Service
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the company.
>
>
> On Thu, Feb 5, 2009 at 4:26 AM, hemant <gethemant at gmail.com> wrote:
>
>> I doubt there would be a problem with bdrb. However I would suggest
>> you to run your program with ruby-prof or use one of the memory
>> profiles (bleakhouse).
>>
>> Try to reduce the case and paste your worker code.
>>
>>
>> On Wed, Feb 4, 2009 at 10:56 PM, Christian Billen
>> <cbillen at warmlyyours.com> wrote:
>> > Good morning list,
>> > We are a new user of BackgroundDrb and we use it to run specific
>> cron-like
>> > jobs at certain times of the day
>> > What we've been noticing is that even when no jobs are running,
>> > backgrounddrb will be running and 'humming' .  This happen as soon as
>> > background drb is started. Notice the CPU usage for it and packet worker
>> > will be between 4% to 7%
>> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>> >
>> >
>> > 22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby
>> >
>> >
>> > 22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68
>> packet_worker_r
>> >
>> >
>> > My packet gem is at this release:
>> > packet (0.1.14)
>> >
>> > My backgrounddrb is at this release:
>> > 1.1
>> >
>> > Running on ubuntu 8.10 x86 on slicehost
>> > Here's our backgrounddrb.xml, i've tried with or without debug, as you
>> can
>> > see the script are only running once a day.
>> > :backgroundrb:
>> >   :ip: 0.0.0.0
>> >   :port: 11006
>> >   :debug_log: true
>> > :schedules:
>> >   :order_shipped_worker:
>> >     :complete_orders:
>> >       :trigger_args: 0 30 21 * * * *
>> >     :reconcile_committed_items:
>> >       :trigger_args: 0 0 22 * * * *
>> >     :check_for_receipts:
>> >       :trigger_args: 0 30 22 * * * *
>> >   :exchange_rates_worker:
>> >     :get_exchange_rates_for_today:
>> >       :trigger_args: 0 0 6 * * * *
>> >     :get_all_exchange_rates:
>> >       :trigger_args: 0 30 6 1 * * *
>> >
>> > Can anyone shed some light on how to debug or is this cpu usage normal?
>> > Thank you
>> >
>> > Christian Billen
>> > Director of IT
>> > Warmlyyours.com, inc.
>> >
>> > Phone: (800) 875-5285 ext.800
>> > Fax:      (847) 550-2600
>> > Email:   cbillen at warmlyyours.com
>> >
>> > WarmlyYours
>> > Honeywell authorized licensee
>> > 2 Corporate Dr., Suite 100
>> > Long Grove, Illinois 60047
>> >
>> > Visit the WarmlyYours website at: www.warmlyyours.com
>> >
>> > 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
>> > Service
>> > This email and any files transmitted with it are confidential and
>> intended
>> > solely for the use of the individual or entity to whom they are
>> addressed.
>> > If you have received this email in error please notify the system
>> manager.
>> > Please note that any views or opinions presented in this email are
>> solely
>> > those of the author and do not necessarily represent those of the
>> company.
>> >
>> > _______________________________________________
>> > Backgroundrb-devel mailing list
>> > Backgroundrb-devel at rubyforge.org
>> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>> >
>>
>>
>>
>> --
>> 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
>>
>
>
> _______________________________________________
> 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/20090205/fff02e0d/attachment-0001.html>

From jmillr at umich.edu  Thu Feb  5 18:15:12 2009
From: jmillr at umich.edu (John Miller)
Date: Thu, 5 Feb 2009 18:15:12 -0500
Subject: [Backgroundrb-devel] newbie how to install
In-Reply-To: <FEE1418D-AF84-4124-ABEE-A23E4F961F99@crystalcommerce.com>
References: <E2782198-A3A2-4C7A-9F83-F10381D98FDE@umich.edu>
	<FEE1418D-AF84-4124-ABEE-A23E4F961F99@crystalcommerce.com>
Message-ID: <0D0726F5-82B6-4E89-B8A8-15EA3ECFD0EC@umich.edu>

Thanks to all who replied. I strongly suggest that the documentation  
read

script/plugin install git://github.com/gnufied/backgroundrb.git

instead of

git clone git://github.com/gnufied/backgroundrb.git

Even if it is obvious to many, it wasn't obvious to me where the  
download was supposed to go...

Thanks again!

On Feb 5, 2009, at 2:45 PM, Woody Peterson wrote:

> try
>
> script/plugin install git://github.com/gnufied/backgroundrb.git
>
> instead
>
> On Feb 5, 2009, at 10:07 AM, John Miller wrote:
>
>> I'm following the directions at http://backgroundrb.rubyforge.org/
>>
>> I've installed chronic and packet gems.
>>
>> Then it says: you can install the plugin from git:
>>
>> git clone git://github.com/gnufied/backgroundrb.git
>>
>> BUT WHERE???
>>
>> I did this at the root level of my rails app.
>>
>> $ git clone git://github.com/gnufied/backgroundrb.git
>> Initialized empty Git repository in /Users/xxxxx/rails/xxxxx/ 
>> backgroundrb/.git/
>> remote: Counting objects: 1862, done.
>> remote: Compressing objects: 100% (732/732), done.
>> remote: Total 1862 (delta 1078), reused 1852 (delta 1073)
>> Receiving objects: 100% (1862/1862), 1.73 MiB | 885 KiB/s, done.
>> Resolving deltas: 100% (1078/1078), done.
>>
>> So the git repository of backgroundrb is at the root level of my  
>> rails app. Now I'm supposed to run the rake task:
>>
>> $ rake backgroundrb:setup
>> (in /Users/xxxxx/rails/xxxxx)
>> rake aborted!
>> Don't know how to build task 'backgroundrb:setup'
>>
>> (See full trace by running task with --trace)
>>
>> Now I'm stuck. Any suggestions? Thanks!
>>
>> John
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
>
>


From gethemant at gmail.com  Thu Feb  5 19:36:34 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 6 Feb 2009 06:06:34 +0530
Subject: [Backgroundrb-devel] CPU/Memory usage of BackgroundDrb
In-Reply-To: <a5a491740902051348t6656dd79udf297833694bb4f0@mail.gmail.com>
References: <a5a491740902040926p32bfc27h18d2aad68c83fc7a@mail.gmail.com>
	<fb283d5e0902050226r3316fec0s89c855b018c8748c@mail.gmail.com>
	<a5a491740902051243y31b2b7dfo8d3b70e0c5b90f9@mail.gmail.com>
	<c9517bd80902051345t2d3317d7r95f693c4ad82c8bd@mail.gmail.com>
	<a5a491740902051348t6656dd79udf297833694bb4f0@mail.gmail.com>
Message-ID: <fb283d5e0902051636o3a76c584n93820ceb22c346fe@mail.gmail.com>

Okay, for running a profiler on your application. You will have to
explicitly require "ruby-prof" in your worker code. Ruby-Prof has
options for where to write the profiling data and stuff.

I wouldn't worry about 1-5% CPU usage btw because essentially its
polling sockets (and database too). But sometimes the way different
gems interfact can throw a boner.

On Fri, Feb 6, 2009 at 3:18 AM, Christian Billen
<cbillen at warmlyyours.com> wrote:
> Hi,
> I have tried with persistent off and debug log on, I tailed the debug log
> file but see no activity, yet I still see cpu activity for the process.
>
> Christian Billen
> Director of IT
> Warmlyyours.com, inc.
>
> Phone: (800) 875-5285 ext.800
> Fax:      (847) 550-2600
> Email:   cbillen at warmlyyours.com
>
> WarmlyYours
> Honeywell authorized licensee
> 2 Corporate Dr., Suite 100
> Long Grove, Illinois 60047
>
> Visit the WarmlyYours website at: www.warmlyyours.com
>
> 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
> Service
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the company.
>
>
> On Thu, Feb 5, 2009 at 3:45 PM, Samer Masry <enzodm at gmail.com> wrote:
>>
>> I would turn on debug for active record and see if you can correlated the
>> spikes of the cpu with the backgroundrb call to the db queue since you are
>> using a persistant queue.
>>
>> Have a tail of your log file open and another window with top.
>>
>> -Samer Masry
>> dryBlis
>>
>> On Thu, Feb 5, 2009 at 12:43 PM, Christian Billen
>> <cbillen at warmlyyours.com> wrote:
>>>
>>> Hi there,
>>>
>>> Well I disabled the schedule for all the workers, so all i have left in
>>> backgrounddrb.yml is
>>>
>>> When I start backgrounddrb on Ubuntu 8.10 I get the 4-5% cpu humming on
>>> packetworker and backgrounddrb.  I get this issue also on my rails app
>>> running on Mac OS X 10.5
>>> This is all I have in my backgrounddrb.yml:
>>> :backgroundrb:
>>>   :ip: 0.0.0.0
>>>   :port: 11006
>>>
>>> gem versions:
>>> rails (2.2.2)
>>> packet (0.1.14)
>>> chronic (0.2.3)
>>>
>>> Background drb installed from
>>> sudo ./script/plugin install git://github.com/gnufied/backgroundrb.git
>>>
>>> Since no background drb workers are running at all I do not know how to
>>> profile this as you suggest.
>>> Where else could look to determine where this is coming from?
>>>
>>> Thank you
>>> Christian Billen
>>> Director of IT
>>> Warmlyyours.com, inc.
>>>
>>> Phone: (800) 875-5285 ext.800
>>> Fax:      (847) 550-2600
>>> Email:   cbillen at warmlyyours.com
>>>
>>> WarmlyYours
>>> Honeywell authorized licensee
>>> 2 Corporate Dr., Suite 100
>>> Long Grove, Illinois 60047
>>>
>>> Visit the WarmlyYours website at: www.warmlyyours.com
>>>
>>> 24/7 Installation Support ? Lifetime Technical Assistance ? Free Design
>>> Service
>>> This email and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom they are
>>> addressed. If you have received this email in error please notify the system
>>> manager. Please note that any views or opinions presented in this email are
>>> solely those of the author and do not necessarily represent those of the
>>> company.
>>>
>>>
>>> On Thu, Feb 5, 2009 at 4:26 AM, hemant <gethemant at gmail.com> wrote:
>>>>
>>>> I doubt there would be a problem with bdrb. However I would suggest
>>>> you to run your program with ruby-prof or use one of the memory
>>>> profiles (bleakhouse).
>>>>
>>>> Try to reduce the case and paste your worker code.
>>>>
>>>>
>>>> On Wed, Feb 4, 2009 at 10:56 PM, Christian Billen
>>>> <cbillen at warmlyyours.com> wrote:
>>>> > Good morning list,
>>>> > We are a new user of BackgroundDrb and we use it to run specific
>>>> > cron-like
>>>> > jobs at certain times of the day
>>>> > What we've been noticing is that even when no jobs are running,
>>>> > backgrounddrb will be running and 'humming' .  This happen as soon as
>>>> > background drb is started. Notice the CPU usage for it and packet
>>>> > worker
>>>> > will be between 4% to 7%
>>>> >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>>>> >
>>>> >
>>>> > 22523 heatwave  20   0  284m 134m 1292 S    3  6.6   0:01.94 ruby
>>>> >
>>>> >
>>>> > 22524 heatwave  20   0 99.7m  41m 3200 S    1  2.0   0:01.68
>>>> > packet_worker_r
>>>> >
>>>> >
>>>> > My packet gem is at this release:
>>>> > packet (0.1.14)
>>>> >
>>>> > My backgrounddrb is at this release:
>>>> > 1.1
>>>> >
>>>> > Running on ubuntu 8.10 x86 on slicehost
>>>> > Here's our backgrounddrb.xml, i've tried with or without debug, as you
>>>> > can
>>>> > see the script are only running once a day.
>>>> > :backgroundrb:
>>>> >   :ip: 0.0.0.0
>>>> >   :port: 11006
>>>> >   :debug_log: true
>>>> > :schedules:
>>>> >   :order_shipped_worker:
>>>> >     :complete_orders:
>>>> >       :trigger_args: 0 30 21 * * * *
>>>> >     :reconcile_committed_items:
>>>> >       :trigger_args: 0 0 22 * * * *
>>>> >     :check_for_receipts:
>>>> >       :trigger_args: 0 30 22 * * * *
>>>> >   :exchange_rates_worker:
>>>> >     :get_exchange_rates_for_today:
>>>> >       :trigger_args: 0 0 6 * * * *
>>>> >     :get_all_exchange_rates:
>>>> >       :trigger_args: 0 30 6 1 * * *
>>>> >
>>>> > Can anyone shed some light on how to debug or is this cpu usage
>>>> > normal?
>>>> > Thank you
>>>> >
>>>> > Christian Billen
>>>> > Director of IT
>>>> > Warmlyyours.com, inc.
>>>> >
>>>> > Phone: (800) 875-5285 ext.800
>>>> > Fax:      (847) 550-2600
>>>> > Email:   cbillen at warmlyyours.com
>>>> >
>>>> > WarmlyYours
>>>> > Honeywell authorized licensee
>>>> > 2 Corporate Dr., Suite 100
>>>> > Long Grove, Illinois 60047
>>>> >
>>>> > Visit the WarmlyYours website at: www.warmlyyours.com
>>>> >
>>>> > 24/7 Installation Support ? Lifetime Technical Assistance ? Free
>>>> > Design
>>>> > Service
>>>> > This email and any files transmitted with it are confidential and
>>>> > intended
>>>> > solely for the use of the individual or entity to whom they are
>>>> > addressed.
>>>> > If you have received this email in error please notify the system
>>>> > manager.
>>>> > Please note that any views or opinions presented in this email are
>>>> > solely
>>>> > those of the author and do not necessarily represent those of the
>>>> > company.
>>>> >
>>>> > _______________________________________________
>>>> > Backgroundrb-devel mailing list
>>>> > Backgroundrb-devel at rubyforge.org
>>>> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> Backgroundrb-devel mailing list
>>> Backgroundrb-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>
>
>



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

From phil at ideeli.com  Fri Feb  6 11:58:23 2009
From: phil at ideeli.com (Phil Smy)
Date: Fri, 6 Feb 2009 17:58:23 +0100
Subject: [Backgroundrb-devel] backgroundrb worker and soap?
Message-ID: <1A614371-9005-44EC-A245-029B77E9DB8F@ideeli.com>

I am having a problem calling a soap driver from within a backgroundrb  
worker.
Here is basically what I am doing:

class MyWorker < BackgrounDRb::MetaWorker
   def create(args = nil)
     # this method is called, when worker is loaded for the first time
   end
   def process args
     inv_items = NSHelper::NSPort.instance.find_things(args)
   end
end

The Helper create a PortType and so on that has been generated by  
wsdl2ruby.

I am getting an error inside of httptimeout:

2009-02-06 17:56:40 (46574) I: #<NoMethodError: You have a nil object  
when you didn't expect it!
The error occurred while evaluating nil.cancel>
2009-02-06 17:56:40 (46574) I: /Library/Ruby/Gems/1.8/gems/ 
httpclient-2.1.3.1/lib/httpclient/timeout.rb:76:in `cancel'
/Library/Ruby/Gems/1.8/gems/httpclient-2.1.3.1/lib/httpclient/ 
timeout.rb:116:in `timeout'
and so on.
It immediately is going to a timeout - so I think that is the crux of  
the issue.

I can use my helper / soap calls fine from within a controller or the  
console - it is just from the worker I am having problems.

Any help would be greatly appreciated!

Phil

From andrew at workingtechnology.co.uk  Sat Feb  7 03:02:38 2009
From: andrew at workingtechnology.co.uk (andrew at workingtechnology.co.uk)
Date: Sat, 7 Feb 2009 08:02:38 +0000
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
Message-ID: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>

Hi,

I have a production environment setup on CentOS 5.2. Latest versions  
of backgroundrb and associated gems.

When I run script/backgroundrb start directly from the command line on  
the server is starts fine.

"RAILS_ENV=production script/backgroundrb start"

However the following capistrano task doesn't seem to work correctly.  
It creates the pid file containing what looks like a valid id but when  
looking for the running process with "ps -aux | grep background"  
nothing is found (whereas a process is listed if started via command  
prompt).

If I start the backgroundrb script manually at the command prompt and  
then run the cap task to restart it doesn't give any errors, it stops  
normally (no errors regarding missing process) and appears to restart  
normally. However on inspection you can see there is no process  
running after starting via cap.

No obvious errors are generated in any logs. Has anyone experienced  
anything similar or have any pointers on where to start looking?

Thanks, Andrew.

==backgroundrb.yml==

:backgroundrb:
   :port: 11006
   :ip: 0.0.0.0
   :environment: production
   :persistent_delay: 10

==deploy.rb==

ssh_options[:paranoid] = false
default_run_options[:pty] = true

set :user, 'deploy'
set :runner, 'deploy'
set :use_sudo, false

role :app, "192.168.10.60"
role :web, "192.168.10.60"
role :db,  "192.168.10.60", :primary => true

...

desc "Restart Backgroundrb"
task :restart_backgroundrb, :roles => [:app] do
   run "cd #{current_path} && RAILS_ENV=production script/backgroundrb  
stop"
   run "cd #{current_path} && RAILS_ENV=production script/backgroundrb  
start"
end

==output==

$ cap restart_backgroundrb
   * executing `restart_backgroundrb'
   * executing "cd /var/webapps/optics/current && RAILS_ENV=production  
script/backgroundrb stop"
     servers: ["192.168.10.60"]
Password:
     [192.168.10.60] executing command
  ** [out :: 192.168.10.60] /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:6:in `getpgid'
  ** [out :: 192.168.10.60] :
  ** [out :: 192.168.10.60] No such process
  ** [out :: 192.168.10.60] (
  ** [out :: 192.168.10.60] Errno::ESRCH
  ** [out :: 192.168.10.60] )
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:6:in `kill_process'
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `stop'
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `each'
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `stop'
  ** [out :: 192.168.10.60] from script/backgroundrb:36
     command finished
failed: "sh -c \"cd /var/webapps/optics/current &&  
RAILS_ENV=production script/backgroundrb stop\"" on 192.168.10.60




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From enzodm at gmail.com  Sat Feb  7 10:26:46 2009
From: enzodm at gmail.com (Samer Masry)
Date: Sat, 7 Feb 2009 07:26:46 -0800
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
Message-ID: <3D1CCBF0-FB07-40DD-AF85-CD3B31EF5D4C@gmail.com>

For my production environment is use

run "#{deploy_to}/current/script/backgroundrb start -- 
environment=#{environment}\""

Try passing it as a parameter
-Samer Masry
dryBlis


On Feb 7, 2009, at 12:02 AM, andrew at workingtechnology.co.uk wrote:

> Hi,
>
> I have a production environment setup on CentOS 5.2. Latest versions  
> of backgroundrb and associated gems.
>
> When I run script/backgroundrb start directly from the command line  
> on the server is starts fine.
>
> "RAILS_ENV=production script/backgroundrb start"
>
> However the following capistrano task doesn't seem to work  
> correctly. It creates the pid file containing what looks like a  
> valid id but when looking for the running process with "ps -aux |  
> grep background" nothing is found (whereas a process is listed if  
> started via command prompt).
>
> If I start the backgroundrb script manually at the command prompt  
> and then run the cap task to restart it doesn't give any errors, it  
> stops normally (no errors regarding missing process) and appears to  
> restart normally. However on inspection you can see there is no  
> process running after starting via cap.
>
> No obvious errors are generated in any logs. Has anyone experienced  
> anything similar or have any pointers on where to start looking?
>
> Thanks, Andrew.
>
> ==backgroundrb.yml==
>
> :backgroundrb:
>  :port: 11006
>  :ip: 0.0.0.0
>  :environment: production
>  :persistent_delay: 10
>
> ==deploy.rb==
>
> ssh_options[:paranoid] = false
> default_run_options[:pty] = true
>
> set :user, 'deploy'
> set :runner, 'deploy'
> set :use_sudo, false
>
> role :app, "192.168.10.60"
> role :web, "192.168.10.60"
> role :db,  "192.168.10.60", :primary => true
>
> ...
>
> desc "Restart Backgroundrb"
> task :restart_backgroundrb, :roles => [:app] do
>  run "cd #{current_path} && RAILS_ENV=production script/backgroundrb  
> stop"
>  run "cd #{current_path} && RAILS_ENV=production script/backgroundrb  
> start"
> end
>
> ==output==
>
> $ cap restart_backgroundrb
>  * executing `restart_backgroundrb'
>  * executing "cd /var/webapps/optics/current && RAILS_ENV=production  
> script/backgroundrb stop"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:6:in `getpgid'
> ** [out :: 192.168.10.60] :
> ** [out :: 192.168.10.60] No such process
> ** [out :: 192.168.10.60] (
> ** [out :: 192.168.10.60] Errno::ESRCH
> ** [out :: 192.168.10.60] )
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:6:in `kill_process'
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `stop'
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `each'
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `stop'
> ** [out :: 192.168.10.60] from script/backgroundrb:36
>    command finished
> failed: "sh -c \"cd /var/webapps/optics/current &&  
> RAILS_ENV=production script/backgroundrb stop\"" on 192.168.10.60
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From root at erikj.info  Sat Feb  7 11:49:55 2009
From: root at erikj.info (E. Johnson)
Date: Sat, 7 Feb 2009 11:49:55 -0500
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
Message-ID: <871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>

It looks like the restart of backgroundrb failed to start backgroundrb
because restart's stop-backgroundrb failed (nothing running, nothing
to stop), and quit the task.

If that's the case, perhaps a start_backgroundrb task is in order? I'm
controlling backgroundrb via god, and calling them from capistrano w/
the following task set:

$ cap -T |grep backgroundrb
cap restart_backgroundrb       # restart backgroundrb servers
cap start_backgroundrb         # start backgroundrb servers
cap stop_backgroundrb          # stop backgroundrb servers

# Backgroundrb Server TASKS
%w(start stop restart).each do |cmd|
  desc "#{cmd} backgroundrb servers"
  task "#{cmd}_backgroundrb".to_sym, :roles => :app do
    run "sudo #{god} #{cmd} backgroundrb"
  end
end

hope that helps,
Erik


On 2/7/09, andrew at workingtechnology.co.uk
<andrew at workingtechnology.co.uk> wrote:
> Hi,
>
>  I have a production environment setup on CentOS 5.2. Latest versions of
> backgroundrb and associated gems.
>
>  When I run script/backgroundrb start directly from the command line on the
> server is starts fine.
>
>  "RAILS_ENV=production script/backgroundrb start"
>
>  However the following capistrano task doesn't seem to work correctly. It
> creates the pid file containing what looks like a valid id but when looking
> for the running process with "ps -aux | grep background" nothing is found
> (whereas a process is listed if started via command prompt).
>
>  If I start the backgroundrb script manually at the command prompt and then
> run the cap task to restart it doesn't give any errors, it stops normally
> (no errors regarding missing process) and appears to restart normally.
> However on inspection you can see there is no process running after starting
> via cap.
>
>  No obvious errors are generated in any logs. Has anyone experienced
> anything similar or have any pointers on where to start looking?
>
>  Thanks, Andrew.
>
>  ==backgroundrb.yml==
>
>  :backgroundrb:
>   :port: 11006
>   :ip: 0.0.0.0
>   :environment: production
>   :persistent_delay: 10
>
>  ==deploy.rb==
>
>  ssh_options[:paranoid] = false
>  default_run_options[:pty] = true
>
>  set :user, 'deploy'
>  set :runner, 'deploy'
>  set :use_sudo, false
>
>  role :app, "192.168.10.60"
>  role :web, "192.168.10.60"
>  role :db,  "192.168.10.60", :primary => true
>
>  ...
>
>  desc "Restart Backgroundrb"
>  task :restart_backgroundrb, :roles => [:app] do
>   run "cd #{current_path} && RAILS_ENV=production script/backgroundrb stop"
>   run "cd #{current_path} && RAILS_ENV=production script/backgroundrb start"
>  end
>
>  ==output==
>
>  $ cap restart_backgroundrb
>   * executing `restart_backgroundrb'
>   * executing "cd /var/webapps/optics/current && RAILS_ENV=production
> script/backgroundrb stop"
>     servers: ["192.168.10.60"]
>  Password:
>     [192.168.10.60] executing command
>   ** [out :: 192.168.10.60]
> /var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:6:in
> `getpgid'
>   ** [out :: 192.168.10.60] :
>   ** [out :: 192.168.10.60] No such process
>   ** [out :: 192.168.10.60] (
>   ** [out :: 192.168.10.60] Errno::ESRCH
>   ** [out :: 192.168.10.60] )
>   ** [out :: 192.168.10.60] from
> /var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:6:in
> `kill_process'
>   ** [out :: 192.168.10.60] from
> /var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `stop'
>   ** [out :: 192.168.10.60] from
> /var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `each'
>   ** [out :: 192.168.10.60] from
> /var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `stop'
>   ** [out :: 192.168.10.60] from script/backgroundrb:36
>     command finished
>  failed: "sh -c \"cd /var/webapps/optics/current && RAILS_ENV=production
> script/backgroundrb stop\"" on 192.168.10.60
>
>
>
>
>  --
>  This message has been scanned for viruses and
>  dangerous content by MailScanner, and is
>  believed to be clean.
>
>  _______________________________________________
>  Backgroundrb-devel mailing list
>  Backgroundrb-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

From andrew at workingtechnology.co.uk  Sun Feb  8 05:56:12 2009
From: andrew at workingtechnology.co.uk (andrew at workingtechnology.co.uk)
Date: Sun, 8 Feb 2009 10:56:12 +0000
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
	<871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>
Message-ID: <15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>

Thanks guys,

I think it might be something to do with the capistrano login session.

If I use essentially the same code as Samer for my cap task:

desc "Start Backgroundrb"
task :start_backgroundrb, :roles => [:app] do
   run "#{deploy_to}/current/script/backgroundrb start -- 
environment=production"
end

I get the following output:

  cap restart_backgroundrb
   * executing `restart_backgroundrb'
   * executing "/var/webapps/optics/current/script/backgroundrb start  
--environment=production"
     servers: ["192.168.10.60"]
Password:
     [192.168.10.60] executing command
  ** [out :: 192.168.10.60] Starting BackgrounDRb ....
     command finished

This updates the pid file with 4488. However look up the pid and  
nothing:

$ ps aux | grep 4488
deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00 grep  
4488

If however I run the cap task's run command by hand on the server via  
a normal ssh session (same user, "deploy") the pid generated actually  
refers
to a running process:

$script/backgroundrb start --environment=production

$ps aux | grep 5080
deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00 ruby  
script/backgroundrb start --environment=production
deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00 grep  
background

I guess there is something specific about the cap session that is  
different to a regular ssh. If I can't find a solution, as suggested I  
suppose I could use god/monit to restart the process locally and just  
use the cap task to stop the backgroundrb process, which it doesn't  
seem to have a problem with unlike starting.

Thanks for your help, Andrew.

On 7 Feb 2009, at 16:49, E. Johnson wrote:

> It looks like the restart of backgroundrb failed to start backgroundrb
> because restart's stop-backgroundrb failed (nothing running, nothing
> to stop), and quit the task.
>
> If that's the case, perhaps a start_backgroundrb task is in order? I'm
> controlling backgroundrb via god, and calling them from capistrano w/
> the following task set:
>
> $ cap -T |grep backgroundrb
> cap restart_backgroundrb       # restart backgroundrb servers
> cap start_backgroundrb         # start backgroundrb servers
> cap stop_backgroundrb          # stop backgroundrb servers
>
> # Backgroundrb Server TASKS
> %w(start stop restart).each do |cmd|
>  desc "#{cmd} backgroundrb servers"
>  task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>    run "sudo #{god} #{cmd} backgroundrb"
>  end
> end
>
> hope that helps,
> Erik
>




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From walter at katipo.co.nz  Sun Feb  8 12:47:50 2009
From: walter at katipo.co.nz (Walter McGinnis)
Date: Mon, 9 Feb 2009 06:47:50 +1300
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
	<871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>
	<15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>
Message-ID: <A473DBDE-F9CF-43A4-B8BD-E3F826D04BCD@katipo.co.nz>

Hi,

You are correct.  This topic's instructions might help:

http://kete.net.nz/documentation/topics/show/240-configuring-sudo-path-in-capistrano-deployments

We use backgroundrb as a part of Kete, an open source Rails app and  
were running into issues with starting/stopping and gem installs.

Cheers,
Walter

On Feb 8, 2009, at 11:56 PM, andrew at workingtechnology.co.uk wrote:

> Thanks guys,
>
> I think it might be something to do with the capistrano login session.
>
> If I use essentially the same code as Samer for my cap task:
>
> desc "Start Backgroundrb"
> task :start_backgroundrb, :roles => [:app] do
>  run "#{deploy_to}/current/script/backgroundrb start -- 
> environment=production"
> end
>
> I get the following output:
>
> cap restart_backgroundrb
>  * executing `restart_backgroundrb'
>  * executing "/var/webapps/optics/current/script/backgroundrb start  
> --environment=production"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>    command finished
>
> This updates the pid file with 4488. However look up the pid and  
> nothing:
>
> $ ps aux | grep 4488
> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
> grep 4488
>
> If however I run the cap task's run command by hand on the server  
> via a normal ssh session (same user, "deploy") the pid generated  
> actually refers
> to a running process:
>
> $script/backgroundrb start --environment=production
>
> $ps aux | grep 5080
> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
> ruby script/backgroundrb start --environment=production
> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
> grep background
>
> I guess there is something specific about the cap session that is  
> different to a regular ssh. If I can't find a solution, as suggested  
> I suppose I could use god/monit to restart the process locally and  
> just use the cap task to stop the backgroundrb process, which it  
> doesn't seem to have a problem with unlike starting.
>
> Thanks for your help, Andrew.
>
> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>
>> It looks like the restart of backgroundrb failed to start  
>> backgroundrb
>> because restart's stop-backgroundrb failed (nothing running, nothing
>> to stop), and quit the task.
>>
>> If that's the case, perhaps a start_backgroundrb task is in order?  
>> I'm
>> controlling backgroundrb via god, and calling them from capistrano w/
>> the following task set:
>>
>> $ cap -T |grep backgroundrb
>> cap restart_backgroundrb       # restart backgroundrb servers
>> cap start_backgroundrb         # start backgroundrb servers
>> cap stop_backgroundrb          # stop backgroundrb servers
>>
>> # Backgroundrb Server TASKS
>> %w(start stop restart).each do |cmd|
>> desc "#{cmd} backgroundrb servers"
>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>   run "sudo #{god} #{cmd} backgroundrb"
>> end
>> end
>>
>> hope that helps,
>> Erik
>>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From enzodm at gmail.com  Sun Feb  8 13:21:22 2009
From: enzodm at gmail.com (Samer Masry)
Date: Sun, 8 Feb 2009 10:21:22 -0800
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
	<871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>
	<15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>
Message-ID: <4158A4E6-C401-482C-AC23-C743BAD4375E@gmail.com>

Is there anything set in your profile that you are specifying.

There are a few things to capistrano.  First off it uses ssh and ssh  
when it's compiled has  a PATH variable that is hard coded.  If you  
are using a version of ruby that is not in ssh's default path it wont'  
work.  If there is anything that is specified in you .profile  
or .bash_profile you may want to source your profile before you  
execute your command

run ". ~/.bash_profile; #{command}"


-Samer
dryBlis

On Feb 8, 2009, at 2:56 AM, andrew at workingtechnology.co.uk wrote:

> Thanks guys,
>
> I think it might be something to do with the capistrano login session.
>
> If I use essentially the same code as Samer for my cap task:
>
> desc "Start Backgroundrb"
> task :start_backgroundrb, :roles => [:app] do
>  run "#{deploy_to}/current/script/backgroundrb start -- 
> environment=production"
> end
>
> I get the following output:
>
> cap restart_backgroundrb
>  * executing `restart_backgroundrb'
>  * executing "/var/webapps/optics/current/script/backgroundrb start  
> --environment=production"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>    command finished
>
> This updates the pid file with 4488. However look up the pid and  
> nothing:
>
> $ ps aux | grep 4488
> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
> grep 4488
>
> If however I run the cap task's run command by hand on the server  
> via a normal ssh session (same user, "deploy") the pid generated  
> actually refers
> to a running process:
>
> $script/backgroundrb start --environment=production
>
> $ps aux | grep 5080
> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
> ruby script/backgroundrb start --environment=production
> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
> grep background
>
> I guess there is something specific about the cap session that is  
> different to a regular ssh. If I can't find a solution, as suggested  
> I suppose I could use god/monit to restart the process locally and  
> just use the cap task to stop the backgroundrb process, which it  
> doesn't seem to have a problem with unlike starting.
>
> Thanks for your help, Andrew.
>
> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>
>> It looks like the restart of backgroundrb failed to start  
>> backgroundrb
>> because restart's stop-backgroundrb failed (nothing running, nothing
>> to stop), and quit the task.
>>
>> If that's the case, perhaps a start_backgroundrb task is in order?  
>> I'm
>> controlling backgroundrb via god, and calling them from capistrano w/
>> the following task set:
>>
>> $ cap -T |grep backgroundrb
>> cap restart_backgroundrb       # restart backgroundrb servers
>> cap start_backgroundrb         # start backgroundrb servers
>> cap stop_backgroundrb          # stop backgroundrb servers
>>
>> # Backgroundrb Server TASKS
>> %w(start stop restart).each do |cmd|
>> desc "#{cmd} backgroundrb servers"
>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>   run "sudo #{god} #{cmd} backgroundrb"
>> end
>> end
>>
>> hope that helps,
>> Erik
>>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From andrew at workingtechnology.co.uk  Mon Feb  9 04:37:46 2009
From: andrew at workingtechnology.co.uk (andrew at workingtechnology.co.uk)
Date: Mon, 9 Feb 2009 09:37:46 +0000
Subject: [Backgroundrb-devel] Fails to start via Capistrano?
In-Reply-To: <A473DBDE-F9CF-43A4-B8BD-E3F826D04BCD@katipo.co.nz>
References: <82BB7E56-E14E-4C3F-A13C-F2D2C2BEB8A7@workingtechnology.co.uk>
	<871896e40902070849p64d9834i4e73d295c5246b9b@mail.gmail.com>
	<15BEC2AC-781E-4607-8C6A-BFC0174F6473@workingtechnology.co.uk>
	<A473DBDE-F9CF-43A4-B8BD-E3F826D04BCD@katipo.co.nz>
Message-ID: <09C5189B-026D-447B-8F20-DE96C9865711@workingtechnology.co.uk>

Thanks, really appreciate taking the time to help me out.

I think I've worked it out though with a little help from https://gist.github.com/raw/21559/4a8d70c1c3f7874cd435be59a5ed89a6003284a4/deploy.rb

As my deploy.rb file includes "default_run_options[:pty] = true" the  
run commands are executed via a pseudo-tty. It seems that you can't  
start a daemon process in this without it stopping on hangup  
(disconnect), at least not on CentOS - can't say for certain on others  
although I would imagine so.

If however you prepend the run command with nohup everything works  
correctly and the process stays running after the cap session ends. I  
now have:

run "nohup #{deploy_to}/current/script/backgroundrb start -- 
environment=production"

Incidentally, if you take "default_run_options[:pty] = true" out of  
deploy.rb the backgroundrb start command doesn't return and locks the  
session. Jamis Buck briefly covers this here: http://weblog.jamisbuck.org/2007/10/14/capistrano-2-1

Thanks again, Andrew.

On 8 Feb 2009, at 17:47, Walter McGinnis wrote:

> Hi,
>
> You are correct.  This topic's instructions might help:
>
> http://kete.net.nz/documentation/topics/show/240-configuring-sudo-path-in-capistrano-deployments
>
> We use backgroundrb as a part of Kete, an open source Rails app and  
> were running into issues with starting/stopping and gem installs.
>
> Cheers,
> Walter
>
> On Feb 8, 2009, at 11:56 PM, andrew at workingtechnology.co.uk wrote:
>
>> Thanks guys,
>>
>> I think it might be something to do with the capistrano login  
>> session.
>>
>> If I use essentially the same code as Samer for my cap task:
>>
>> desc "Start Backgroundrb"
>> task :start_backgroundrb, :roles => [:app] do
>> run "#{deploy_to}/current/script/backgroundrb start -- 
>> environment=production"
>> end
>>
>> I get the following output:
>>
>> cap restart_backgroundrb
>> * executing `restart_backgroundrb'
>> * executing "/var/webapps/optics/current/script/backgroundrb start  
>> --environment=production"
>>   servers: ["192.168.10.60"]
>> Password:
>>   [192.168.10.60] executing command
>> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>>   command finished
>>
>> This updates the pid file with 4488. However look up the pid and  
>> nothing:
>>
>> $ ps aux | grep 4488
>> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
>> grep 4488
>>
>> If however I run the cap task's run command by hand on the server  
>> via a normal ssh session (same user, "deploy") the pid generated  
>> actually refers
>> to a running process:
>>
>> $script/backgroundrb start --environment=production
>>
>> $ps aux | grep 5080
>> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
>> ruby script/backgroundrb start --environment=production
>> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
>> grep background
>>
>> I guess there is something specific about the cap session that is  
>> different to a regular ssh. If I can't find a solution, as  
>> suggested I suppose I could use god/monit to restart the process  
>> locally and just use the cap task to stop the backgroundrb process,  
>> which it doesn't seem to have a problem with unlike starting.
>>
>> Thanks for your help, Andrew.
>>
>> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>>
>>> It looks like the restart of backgroundrb failed to start  
>>> backgroundrb
>>> because restart's stop-backgroundrb failed (nothing running, nothing
>>> to stop), and quit the task.
>>>
>>> If that's the case, perhaps a start_backgroundrb task is in order?  
>>> I'm
>>> controlling backgroundrb via god, and calling them from capistrano  
>>> w/
>>> the following task set:
>>>
>>> $ cap -T |grep backgroundrb
>>> cap restart_backgroundrb       # restart backgroundrb servers
>>> cap start_backgroundrb         # start backgroundrb servers
>>> cap stop_backgroundrb          # stop backgroundrb servers
>>>
>>> # Backgroundrb Server TASKS
>>> %w(start stop restart).each do |cmd|
>>> desc "#{cmd} backgroundrb servers"
>>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>>  run "sudo #{god} #{cmd} backgroundrb"
>>> end
>>> end
>>>
>>> hope that helps,
>>> Erik
>>>
>>
>>
>>
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From akyrho at gmail.com  Mon Feb  9 04:38:13 2009
From: akyrho at gmail.com (=?ISO-8859-1?Q?Bousmanne_C=E9dric?=)
Date: Mon, 9 Feb 2009 10:38:13 +0100
Subject: [Backgroundrb-devel] Problem with scheduled tasks (backgroundrb.yml)
Message-ID: <30904B47-8CEF-4483-AAC9-9E53BEE2223C@gmail.com>

Hi everyone,

I got into trouble with backgroundrb scheduled tasks. I've got 3  
workers with number of methods. Somes are running, but others aren't.  
Here's my backgroundrb.yml file :

:backgroundrb:
   :port: 11006
   :ip: localhost
   :environment: production
   :user: www-data
   :group: www-data
   :result_storage: memcache
:memcache: "0.0.0.0:11211"
:schedules:
   :maintenance_worker:
     :info:
       :trigger_args: 0 0 10 * * * *
     :check_vd_hourly:
       :trigger_args: 0 0 * * * * *
     :check_vm_hourly:
       :trigger_args: 0 0 * * * * *
     :check_vd_daily:
       :trigger_args: 0 0 3 * * * *
     :check_vm_daily:
       :trigger_args: 0 0 3 * * * *
     :pooler:
       :trigger_args: 0 0 5 * * * *
     :update_count:
       :trigger_args: 0 * * * * * *
     :database_cleaning:
       :trigger_args: 0 25 10 * * * *
   :urls_worker:
     :check:
       :trigger_args: 0 */3 * * * * *
   :wc_worker:
     :check:
       :trigger_args: 0 */6 * * * * *

I wonder if there was any limit to number of processes scheduled?

urls_worker and wc_worker are running correctly, but everything in  
maintenance_worker seems to fail to load without any output in my logs.


From lists at wildgooses.com  Mon Feb  9 10:13:00 2009
From: lists at wildgooses.com (Ed W)
Date: Mon, 09 Feb 2009 15:13:00 +0000
Subject: [Backgroundrb-devel] Doing max of N tasks per given time
In-Reply-To: <fd0631d50901300652t1e1cdb12r8204744320703501@mail.gmail.com>
References: <f25d5ad20901270114x9451088ne322eefdcd77a2de@mail.gmail.com>	<f84841020901300450r53178290sbc0021d319fee417@mail.gmail.com>
	<fd0631d50901300652t1e1cdb12r8204744320703501@mail.gmail.com>
Message-ID: <499047FC.8070606@wildgooses.com>

Jonathan Wallace wrote:
> Jack,
>
> That's a great point.  In a 5 minute google search, I couldn't find 
> anything about qmail or postfix being able to rate limit out of the 
> box but I did find that exim could.  
> http://www.exim.org/exim-html-4.63/doc/html/spec_html/ch39.html#SECTratelimiting
>

A bit late, but Postfix has rate limiting

See the transport settings.  Basically you can setup a specific 
transport for a certain destination and then throttle it to X messages 
per whatever.  The only thing is that if the mails are literally being 
thrown away silently then you might prefer to go the custom code 
solution so that there can't be any mishaps due to say mailserver being 
restarted and stats being reset leading to mail loss, etc

Good luck

Ed W

From ramon.tayag at gmail.com  Wed Feb 11 12:51:52 2009
From: ramon.tayag at gmail.com (Ramon Tayag)
Date: Thu, 12 Feb 2009 01:51:52 +0800
Subject: [Backgroundrb-devel] Doing max of N tasks per given time
In-Reply-To: <499047FC.8070606@wildgooses.com>
References: <f25d5ad20901270114x9451088ne322eefdcd77a2de@mail.gmail.com>
	<f84841020901300450r53178290sbc0021d319fee417@mail.gmail.com>
	<fd0631d50901300652t1e1cdb12r8204744320703501@mail.gmail.com>
	<499047FC.8070606@wildgooses.com>
Message-ID: <641CA481-D12D-4F76-B37C-D97ADBBB7A6C@gmail.com>

Thank you everyone for you input ? based on what I've read, it seems  
putting up a postfix server would be the solution.

Ramon Tayag

On 02 9, 09, at 23:13, Ed W <lists at wildgooses.com> wrote:

> Jonathan Wallace wrote:
>> Jack,
>>
>> That's a great point.  In a 5 minute google search, I couldn't find  
>> anything about qmail or postfix being able to rate limit out of the  
>> box but I did find that exim could.  http://www.exim.org/exim-html-4.63/doc/html/spec_html/ch39.html#SECTratelimiting
>>
>
> A bit late, but Postfix has rate limiting
>
> See the transport settings.  Basically you can setup a specific  
> transport for a certain destination and then throttle it to X  
> messages per whatever.  The only thing is that if the mails are  
> literally being thrown away silently then you might prefer to go the  
> custom code solution so that there can't be any mishaps due to say  
> mailserver being restarted and stats being reset leading to mail  
> loss, etc
>
> Good luck
>
> Ed W
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

From ian.sheridan at gmail.com  Fri Feb 13 10:17:29 2009
From: ian.sheridan at gmail.com (Ian Sheridan)
Date: Fri, 13 Feb 2009 10:17:29 -0500
Subject: [Backgroundrb-devel] Running on Merb
Message-ID: <f0b43f530902130717p6d21d3c6iddb91e8249fc7fd8@mail.gmail.com>

Is there a port of BackgrounDRb to Merb? I could not find one but I
was wondering if there was a hack to make it work or BDRB can right
out of the box.

- Ian

-- 
----------------------
Ian Sheridan
http://iansheridan.dyndns.org
----------------------

From felix.holmgren at gmail.com  Mon Feb 16 15:54:19 2009
From: felix.holmgren at gmail.com (Felix Holmgren)
Date: Mon, 16 Feb 2009 21:54:19 +0100
Subject: [Backgroundrb-devel] MiddleMan.new_worker => nil
Message-ID: <35d9943f0902161254o4f33a0ffs6273811ec76deac1@mail.gmail.com>

I've been checking out all the async gems and plugins for Rails, and
decided to give BackgroundRb a shot. Unfortunately, I've not even been
able to get past the initial stages.

Whenever I call MiddleMan.new_worker, it invariably returns nil. The
log file remains empty.

I've only tried this from the console so far. If I can't even do this
successfully, I'm in no mood to try to start to write code,

I've followed the example instructions to the letter, and confirmed
that the BGRB server is running, as well as my Mongrel. I'm running on
Leopard.

Rails 2.2.2
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]

I'd really appreciate it if someone could give me some feedback on
this fast. Otherwise I'll have to drop BackgroundRb and go with a
hand-made, simpler scheme for now, as the deadline for my project is
very close (basically, like NOW).

Many thanks!

From jonathan.wallace at gmail.com  Mon Feb 16 18:59:10 2009
From: jonathan.wallace at gmail.com (Jonathan Wallace)
Date: Mon, 16 Feb 2009 18:59:10 -0500
Subject: [Backgroundrb-devel] MiddleMan.new_worker => nil
In-Reply-To: <35d9943f0902161254o4f33a0ffs6273811ec76deac1@mail.gmail.com>
References: <35d9943f0902161254o4f33a0ffs6273811ec76deac1@mail.gmail.com>
Message-ID: <fd0631d50902161559w315dc894r3940adeeb67ddacf@mail.gmail.com>

Hi Felix,

MiddleMan.new_worker returns the worker's key.  For example, if you use

w = MiddleMan.new_worker(:worker => :my_worker, :worker_key => '1')
#the value of w is 1

To access the worker, you use
MiddleMan.worker(:my_worker, '1').some_method_call_here.

If you don't pass in a worker_key, then you receive nil.

That's my understanding.
 Jonathan

On Mon, Feb 16, 2009 at 3:54 PM, Felix Holmgren <felix.holmgren at gmail.com>wrote:

> I've been checking out all the async gems and plugins for Rails, and
> decided to give BackgroundRb a shot. Unfortunately, I've not even been
> able to get past the initial stages.
>
> Whenever I call MiddleMan.new_worker, it invariably returns nil. The
> log file remains empty.
>
> I've only tried this from the console so far. If I can't even do this
> successfully, I'm in no mood to try to start to write code,
>
> I've followed the example instructions to the letter, and confirmed
> that the BGRB server is running, as well as my Mongrel. I'm running on
> Leopard.
>
> Rails 2.2.2
> ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
>
> I'd really appreciate it if someone could give me some feedback on
> this fast. Otherwise I'll have to drop BackgroundRb and go with a
> hand-made, simpler scheme for now, as the deadline for my project is
> very close (basically, like NOW).
>
> Many thanks!
> _______________________________________________
> 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/20090216/33e3e5dd/attachment.html>

From diogo.silva at w20.pt  Fri Feb 20 05:23:01 2009
From: diogo.silva at w20.pt (Diogo Silva)
Date: Fri, 20 Feb 2009 10:23:01 +0000
Subject: [Backgroundrb-devel] backgroundrb worker and soap?
In-Reply-To: <1A614371-9005-44EC-A245-029B77E9DB8F@ideeli.com>
References: <1A614371-9005-44EC-A245-029B77E9DB8F@ideeli.com>
Message-ID: <efcf12380902200223qd1eabdcl7b29bcdadbae91d9@mail.gmail.com>

Hi,

I'm having some problems too with soap driver within a worker. Sometimes it
works, sometimes not (raising a timeout error too).
Someone found a solution to this problem?

Thanks

2009/2/6 Phil Smy <phil at ideeli.com>

> I am having a problem calling a soap driver from within a backgroundrb
> worker.
> Here is basically what I am doing:
>
> class MyWorker < BackgrounDRb::MetaWorker
>  def create(args = nil)
>    # this method is called, when worker is loaded for the first time
>  end
>  def process args
>    inv_items = NSHelper::NSPort.instance.find_things(args)
>  end
> end
>
> The Helper create a PortType and so on that has been generated by
> wsdl2ruby.
>
> I am getting an error inside of httptimeout:
>
> 2009-02-06 17:56:40 (46574) I: #<NoMethodError: You have a nil object when
> you didn't expect it!
> The error occurred while evaluating nil.cancel>
> 2009-02-06 17:56:40 (46574) I:
> /Library/Ruby/Gems/1.8/gems/httpclient-2.1.3.1/lib/httpclient/timeout.rb:76:in
> `cancel'
> /Library/Ruby/Gems/1.8/gems/httpclient-2.1.3.1/lib/httpclient/timeout.rb:116:in
> `timeout'
> and so on.
> It immediately is going to a timeout - so I think that is the crux of the
> issue.
>
> I can use my helper / soap calls fine from within a controller or the
> console - it is just from the worker I am having problems.
>
> Any help would be greatly appreciated!
>
> Phil
> _______________________________________________
> 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/20090220/6797986d/attachment.html>

From adam at thewilliams.ws  Thu Feb 26 15:03:06 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Thu, 26 Feb 2009 15:03:06 -0500
Subject: [Backgroundrb-devel] Logging Configuration
Message-ID: <9D59863A-8278-447B-A509-D83F12A36D4C@thewilliams.ws>

I'd like to stop seeing the output of ActiveRecord initialization and  
queries in the default log file. This I found in the code:

   log_flag = BDRB_CONFIG[:backgroundrb][:debug_log].nil? ? true :  
BDRB_CONFIG[:backgroundrb][:debug_load_rails_env]

I confess I'm a bit confused as to how to achieve the correct  
configuration. Is this what is needed to stop logging:

   :backgroundrb:
     :port: 11006
     :ip: 0.0.0.0
     :debug_log: false
     :debug_load_rails_env: false

It seems that the value of :debug_log is treated the same whether it  
is true or false - the value of :debug_load_rails_env will be  
returned. If :debug_log is nil, you cannot control anything  
with :debug_load_rails_env.

Thanks for any clarification.

   adam


From adam at thewilliams.ws  Thu Feb 26 16:10:40 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Thu, 26 Feb 2009 16:10:40 -0500
Subject: [Backgroundrb-devel] Logging Configuration
In-Reply-To: <9D59863A-8278-447B-A509-D83F12A36D4C@thewilliams.ws>
References: <9D59863A-8278-447B-A509-D83F12A36D4C@thewilliams.ws>
Message-ID: <28B9705B-A73B-4C08-9163-432310A837CC@thewilliams.ws>

Turns out we can only ActiveRecord::Base.silence {} our own queries,  
and getting rid of the ActiveRecord initialization noise will require  
changes to MetaWorker#load_rails_env, where it enables concurrency.

On Feb 26, 2009, at 3:03 PM, Adam Williams wrote:

> I'd like to stop seeing the output of ActiveRecord initialization  
> and queries in the default log file. This I found in the code:
>
>  log_flag = BDRB_CONFIG[:backgroundrb][:debug_log].nil? ? true :  
> BDRB_CONFIG[:backgroundrb][:debug_load_rails_env]
>
> I confess I'm a bit confused as to how to achieve the correct  
> configuration. Is this what is needed to stop logging:
>
>  :backgroundrb:
>    :port: 11006
>    :ip: 0.0.0.0
>    :debug_log: false
>    :debug_load_rails_env: false
>
> It seems that the value of :debug_log is treated the same whether it  
> is true or false - the value of :debug_load_rails_env will be  
> returned. If :debug_log is nil, you cannot control anything  
> with :debug_load_rails_env.
>
> Thanks for any clarification.
>
>  adam
>


From Tuong.Le at Emulex.Com  Thu Feb 26 17:55:26 2009
From: Tuong.Le at Emulex.Com (Tuong.Le at Emulex.Com)
Date: Thu, 26 Feb 2009 14:55:26 -0800
Subject: [Backgroundrb-devel] When does a worker terminate
Message-ID: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>

Hi,



In Rails, it seems I can create a new worker with:

      worker_abc = Middleman.worker(:foo_worker)



And later on uses it like:

      worker_abc.async_some_task(:arg => data)



My question is when does this "worker_abc" go away and its resources freed up?  How does Ruby/Rails/backgroundrb know that I am done using "worker_abc"?



Thanks.



Tuong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090226/7bf620c4/attachment-0001.html>

From gethemant at gmail.com  Fri Feb 27 01:19:52 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 27 Feb 2009 11:49:52 +0530
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
Message-ID: <fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>

On Fri, Feb 27, 2009 at 4:25 AM,  <Tuong.Le at emulex.com> wrote:
> Hi,
>
>
>
> In Rails, it seems I can create a new worker with:
>
> ????? worker_abc = Middleman.worker(:foo_worker)
>
>

You don't create a new worker like that. It just gives you a handle
for already running worker.You use MiddleMan.new_worker for creating
new workers. More details:

http://backgroundrb.rubyforge.org/rails/#new_worker


>
> And later on uses it like:
>
> ????? worker_abc.async_some_task(:arg => data)
>
>
>
> My question is when does this "worker_abc" go away and its resources freed
> up?? How does Ruby/Rails/backgroundrb know that I am done using
> "worker_abc"?
>

It doesn't. You need to explicitly close/exit your workers.

From raghu.srinivasan at gmail.com  Fri Feb 27 01:48:44 2009
From: raghu.srinivasan at gmail.com (Raghu Srinivasan)
Date: Thu, 26 Feb 2009 22:48:44 -0800
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
	<fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
Message-ID: <6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>

Hemant  - I thought that script/background start starts all workers
and script/background
stop stops all workers.
How does one explicitly close/exit a  particular worker from within Rails?

On Thu, Feb 26, 2009 at 10:19 PM, hemant <gethemant at gmail.com> wrote:

> On Fri, Feb 27, 2009 at 4:25 AM,  <Tuong.Le at emulex.com> wrote:
> > Hi,
> >
> >
> >
> > In Rails, it seems I can create a new worker with:
> >
> >       worker_abc = Middleman.worker(:foo_worker)
> >
> >
>
> You don't create a new worker like that. It just gives you a handle
> for already running worker.You use MiddleMan.new_worker for creating
> new workers. More details:
>
> http://backgroundrb.rubyforge.org/rails/#new_worker
>
>
> >
> > And later on uses it like:
> >
> >       worker_abc.async_some_task(:arg => data)
> >
> >
> >
> > My question is when does this "worker_abc" go away and its resources
> freed
> > up?  How does Ruby/Rails/backgroundrb know that I am done using
> > "worker_abc"?
> >
>
> It doesn't. You need to explicitly close/exit your workers.
> _______________________________________________
> 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/20090226/5dedf73d/attachment.html>

From enzodm at gmail.com  Fri Feb 27 02:19:34 2009
From: enzodm at gmail.com (Samer Masry)
Date: Thu, 26 Feb 2009 23:19:34 -0800
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
	<fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
	<6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
Message-ID: <88E538C1-E0A9-4531-BD64-EECC9AEEA572@gmail.com>

script/background actually starts/stop the backgroundrb process.  If  
your worker is set to autoload it will load up on start up.  You can  
create workers using
MiddleMan.new_worker( :worker => :foobar_worker ) or
MiddleMan.new_worker( :worker => :foobar_worker, :worker_key=>  
'some_key' )
and use the delete method on the worker if you want to remove them.

MiddleMan.all_worker_info will give you a list of current workers.


Samer Masry
http://www.dryblis.com

On Feb 26, 2009, at 10:48 PM, Raghu Srinivasan wrote:

> Hemant  - I thought that script/background start starts all workers  
> and script/background stop stops all workers.
>
> How does one explicitly close/exit a  particular worker from within  
> Rails?
>
> On Thu, Feb 26, 2009 at 10:19 PM, hemant <gethemant at gmail.com> wrote:
> On Fri, Feb 27, 2009 at 4:25 AM,  <Tuong.Le at emulex.com> wrote:
> > Hi,
> >
> >
> >
> > In Rails, it seems I can create a new worker with:
> >
> >       worker_abc = Middleman.worker(:foo_worker)
> >
> >
>
> You don't create a new worker like that. It just gives you a handle
> for already running worker.You use MiddleMan.new_worker for creating
> new workers. More details:
>
> http://backgroundrb.rubyforge.org/rails/#new_worker
>
>
> >
> > And later on uses it like:
> >
> >       worker_abc.async_some_task(:arg => data)
> >
> >
> >
> > My question is when does this "worker_abc" go away and its  
> resources freed
> > up?  How does Ruby/Rails/backgroundrb know that I am done using
> > "worker_abc"?
> >
>
> It doesn't. You need to explicitly close/exit your workers.
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> _______________________________________________
> 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/20090226/279c693e/attachment.html>

From gethemant at gmail.com  Fri Feb 27 03:17:44 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 27 Feb 2009 13:47:44 +0530
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
	<fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
	<6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
Message-ID: <fb283d5e0902270017v435f3c2alb7e15c59132a212d@mail.gmail.com>

On Fri, Feb 27, 2009 at 12:18 PM, Raghu Srinivasan
<raghu.srinivasan at gmail.com> wrote:
> Hemant ?- I thought that script/background start starts all workers
> and?script/background stop stops all workers.
> How does one explicitly close/exit a ?particular worker from within Rails?
>

You can call #delete on worker. For example:

MiddleMan.worker("worker_name",<optional_worker_key>).delete

Or you can call #exit from within the worker.

From Tuong.Le at Emulex.Com  Fri Feb 27 12:37:18 2009
From: Tuong.Le at Emulex.Com (Tuong.Le at Emulex.Com)
Date: Fri, 27 Feb 2009 09:37:18 -0800
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <fb283d5e0902270017v435f3c2alb7e15c59132a212d@mail.gmail.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
	<fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
	<6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
	<fb283d5e0902270017v435f3c2alb7e15c59132a212d@mail.gmail.com>
Message-ID: <02B16CD25461354295D12236BDA8C0E17065836DC2@EXMAIL.ad.emulex.com>

I think #exit is what I was looking for but all your feedback got me questioning whether I am using backgroundrb the right way, or the most optimized way.  Please advise.

I was thinking of having my Rails app creating a new worker (Middleman.NEW_worker ...) EVERYTIME a time-consuming task is requested.  As a result, I could have thousands of workers running at the same time.  In my case, my Rails don't need to monitor the worker status, so I can just use #exit when a worker is done with its task.

Questions:

1. Should I create a new worker everytime like that?  Or just having 1 worker, and call async_some_method() when I need to do some long running task?  Is this where thread_pool come into place?

2. If I should create a new worker everytime, is there any reason why I shouldn't put the time-consuming task inside the worker's create() method?

3. At the Linux prompt, is there a way I can monitor how many workers are currently active?

Thank you everyone for your help.

Tuong

-----Original Message-----
From: hemant [mailto:gethemant at gmail.com] 
Sent: Friday, February 27, 2009 12:18 AM
To: Raghu Srinivasan
Cc: Le, Tuong; backgroundrb-devel at rubyforge.org
Subject: Re: [Backgroundrb-devel] When does a worker terminate

On Fri, Feb 27, 2009 at 12:18 PM, Raghu Srinivasan
<raghu.srinivasan at gmail.com> wrote:
> Hemant ?- I thought that script/background start starts all workers
> and?script/background stop stops all workers.
> How does one explicitly close/exit a ?particular worker from within Rails?
>

You can call #delete on worker. For example:

MiddleMan.worker("worker_name",<optional_worker_key>).delete

Or you can call #exit from within the worker.

From gethemant at gmail.com  Fri Feb 27 13:05:12 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 27 Feb 2009 23:35:12 +0530
Subject: [Backgroundrb-devel] When does a worker terminate
In-Reply-To: <02B16CD25461354295D12236BDA8C0E17065836DC2@EXMAIL.ad.emulex.com>
References: <02B16CD25461354295D12236BDA8C0E17065836DC1@EXMAIL.ad.emulex.com>
	<fb283d5e0902262219q2dc105c4t496c73f789eec7ca@mail.gmail.com>
	<6482c06a0902262248l31e6e299y5a9787d7bb193904@mail.gmail.com>
	<fb283d5e0902270017v435f3c2alb7e15c59132a212d@mail.gmail.com>
	<02B16CD25461354295D12236BDA8C0E17065836DC2@EXMAIL.ad.emulex.com>
Message-ID: <fb283d5e0902271005x8c277e0pa18bca5004429d7d@mail.gmail.com>

On Fri, Feb 27, 2009 at 11:07 PM,  <Tuong.Le at emulex.com> wrote:
> I think #exit is what I was looking for but all your feedback got me questioning whether I am using backgroundrb the right way, or the most optimized way. ?Please advise.
>
> I was thinking of having my Rails app creating a new worker (Middleman.NEW_worker ...) EVERYTIME a time-consuming task is requested. ?As a result, I could have thousands of workers running at the same time. ?In my case, my Rails don't need to monitor the worker status, so I can just use #exit when a worker is done with its task.
>
> Questions:
>
> 1. Should I create a new worker everytime like that? ?Or just having 1 worker, and call async_some_method() when I need to do some long running task? ?Is this where thread_pool come into place?

It really depends on nature of work you are doing within worker. If
task is IO bound and can run concurrently within thread pool without
stepping on each other's toe you can use that. However if your task is
CPU bound, ruby threads will be of no use and tasks will wait in queue
for execution within thread pool.

> 2. If I should create a new worker everytime, is there any reason why I shouldn't put the time-consuming task inside the worker's create() method?

By all means, yes you can!

>
> 3. At the Linux prompt, is there a way I can monitor how many workers are currently active?
>

Not at Linux prompt, but at ./script/console you can use
MiddleMan.all_worker_info which will give you a list of all currently
active workers.


> -----Original Message-----
> From: hemant [mailto:gethemant at gmail.com]
> Sent: Friday, February 27, 2009 12:18 AM
> To: Raghu Srinivasan
> Cc: Le, Tuong; backgroundrb-devel at rubyforge.org
> Subject: Re: [Backgroundrb-devel] When does a worker terminate
>
> On Fri, Feb 27, 2009 at 12:18 PM, Raghu Srinivasan
> <raghu.srinivasan at gmail.com> wrote:
>> Hemant ?- I thought that script/background start starts all workers
>> and?script/background stop stops all workers.
>> How does one explicitly close/exit a ?particular worker from within Rails?
>>
>
> You can call #delete on worker. For example:
>
> MiddleMan.worker("worker_name",<optional_worker_key>).delete
>
> Or you can call #exit from within the worker.
>



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