From gethemant at gmail.com  Sat Mar  1 22:36:53 2008
From: gethemant at gmail.com (hemant)
Date: Sun, 2 Mar 2008 09:06:53 +0530
Subject: [Backgroundrb-devel] [ANN] BackgrounDRb 1.0.3 release ( Requiem for
	a dream )
Message-ID: <fb283d5e0803011936h13c5e6fas8a3709f11820eb66@mail.gmail.com>

Hi Folks,

BackgrounDRb 1.0.3 is available now. This release contains several bug
fixes, cleanups, test case coverage and brand new documentation.

A brief ChangeLog:

2008-02-28  hemant kumar  <hemant at shire>

	* fixed some meory leaks.

	* Implemented cleaner API for invoking tasks in workers

	* Updated the documentation

2008-02-25  hemant kumar  <hemant at shire>

	* Commited Patch by Alex which lets BackgrounDRb to have command line
arguments and loading of specific environments
	through command line argument.

2008-02-14  hemant kumar  <hemant at shire>

	* Added TestCases for Cron Triggers, Meta Workers and stuff. We are
heading towards proper code coverage with test/spec.

	* Added preliminary support for starting a worker on demand through
scheduler. What it means is, when you have a worker which is getting
	scheduled very less frequently and you don't want the worker to
persist, you can ask BackgrounDRb to restart the worker on each
schedule.

	* Fixed some unreported issues with writing data to socket between
workers and stuff.

	* Fixed issues with too many open connections, because connections
were not getting closed. BackgrounDRb now opens only one connection,
which is
	reused throughout the lifecycle of rails application.

	* Fixed all outstanding issues with Cron triggers, BackgrounDRb now
explicitly depends on "chronic" gem.

	* Removed Framework directory and BackgrounDRb now explicitly depends
on packet gem.
	

We also did lot of work on documentation and new docs are available at:

http://backgroundrb.rubyforge.org

Credits:
* Dale cook for helping out with documentation.
* Alex for awesome patches.
* Ezra and Skaar for taking BackgrounDRb so far.
* Francis Cianfrocca for EventMachine and inspiration.



-- 
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 gethemant at gmail.com  Sat Mar  1 22:40:08 2008
From: gethemant at gmail.com (hemant)
Date: Sun, 2 Mar 2008 09:10:08 +0530
Subject: [Backgroundrb-devel] [ANN] BackgrounDRb 1.0.3 release ( Requiem
	for a dream )
In-Reply-To: <fb283d5e0803011936h13c5e6fas8a3709f11820eb66@mail.gmail.com>
References: <fb283d5e0803011936h13c5e6fas8a3709f11820eb66@mail.gmail.com>
Message-ID: <fb283d5e0803011940x6f9d457fg7d2bf2c4b086c1ec@mail.gmail.com>

On Sun, Mar 2, 2008 at 9:06 AM, hemant <gethemant at gmail.com> wrote:
> Hi Folks,
>
>  BackgrounDRb 1.0.3 is available now. This release contains several bug
>  fixes, cleanups, test case coverage and brand new documentation.
>
>  A brief ChangeLog:
>
>  2008-02-28  hemant kumar  <hemant at shire>
>
>         * fixed some meory leaks.
>
>         * Implemented cleaner API for invoking tasks in workers
>
>         * Updated the documentation
>
>  2008-02-25  hemant kumar  <hemant at shire>
>
>         * Commited Patch by Alex which lets BackgrounDRb to have command line
>  arguments and loading of specific environments
>         through command line argument.
>
>  2008-02-14  hemant kumar  <hemant at shire>
>
>         * Added TestCases for Cron Triggers, Meta Workers and stuff. We are
>  heading towards proper code coverage with test/spec.
>
>         * Added preliminary support for starting a worker on demand through
>  scheduler. What it means is, when you have a worker which is getting
>         scheduled very less frequently and you don't want the worker to
>  persist, you can ask BackgrounDRb to restart the worker on each
>  schedule.
>
>         * Fixed some unreported issues with writing data to socket between
>  workers and stuff.
>
>         * Fixed issues with too many open connections, because connections
>  were not getting closed. BackgrounDRb now opens only one connection,
>  which is
>         reused throughout the lifecycle of rails application.
>
>         * Fixed all outstanding issues with Cron triggers, BackgrounDRb now
>  explicitly depends on "chronic" gem.
>
>         * Removed Framework directory and BackgrounDRb now explicitly depends
>  on packet gem.
>
>
>  We also did lot of work on documentation and new docs are available at:
>
>  http://backgroundrb.rubyforge.org
>
>  Credits:
>  * Dale cook for helping out with documentation.
>  * Alex for awesome patches.
>  * Ezra and Skaar for taking BackgrounDRb so far.
>  * Francis Cianfrocca for EventMachine and inspiration.

Also, although development has moved to gitorious, SVN mirrors are
updated with latest code. User

./script/backgroundrb --version

to find out which version, you are running.

From iambenbryant at gmail.com  Sat Mar  1 23:31:14 2008
From: iambenbryant at gmail.com (Benjamin H. Bryant)
Date: Sat, 1 Mar 2008 23:31:14 -0500
Subject: [Backgroundrb-devel] BackgrounDRB Ver. 1.0.3 install troubles.
Message-ID: <50817CAF-0AE8-4491-B806-277E76F8C2F2@gmail.com>

So, after deleting the old version, I have tried getting the files  
from both gitorious and SVN using Piston.  Both locations left me with  
this error on startup:

/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in  
`gem_original_require': no such file to load -- meta_worker  
(MissingSourceFile)
	from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 
27:in `require'
	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
active_support/dependencies.rb:496:in `require'
	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
active_support/dependencies.rb:342:in `new_constants_in'
	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
active_support/dependencies.rb:496:in `require'
	from script/backgroundrb:17


Ideas?

Thanks,
Benjamin Bryant

From gethemant at gmail.com  Sun Mar  2 00:55:31 2008
From: gethemant at gmail.com (hemant kumar)
Date: Sun, 02 Mar 2008 11:25:31 +0530
Subject: [Backgroundrb-devel] BackgrounDRB Ver. 1.0.3 install troubles.
In-Reply-To: <50817CAF-0AE8-4491-B806-277E76F8C2F2@gmail.com>
References: <50817CAF-0AE8-4491-B806-277E76F8C2F2@gmail.com>
Message-ID: <1204437331.12541.1.camel@shire>


On Sat, 2008-03-01 at 23:31 -0500, Benjamin H. Bryant wrote:
> So, after deleting the old version, I have tried getting the files  
> from both gitorious and SVN using Piston.  Both locations left me with  
> this error on startup:
> 
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in  
> `gem_original_require': no such file to load -- meta_worker  
> (MissingSourceFile)
> 	from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 
> 27:in `require'
> 	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
> active_support/dependencies.rb:496:in `require'
> 	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
> active_support/dependencies.rb:342:in `new_constants_in'
> 	from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/ 
> active_support/dependencies.rb:496:in `require'
> 	from script/backgroundrb:17
> 
> 
> Ideas?

Did you delete your old "backgroundrb" script from script folder of your
rails directory? If not please do so, and run rake backgroundrb:setup.

Also, make sure you have packet-0.1.5 installed.



From lists at sourceillustrated.com  Mon Mar  3 00:09:35 2008
From: lists at sourceillustrated.com (John Wells)
Date: Mon, 3 Mar 2008 00:09:35 -0500
Subject: [Backgroundrb-devel] BackgrounDRB Ver. 1.0.3 install troubles.
In-Reply-To: <1204437331.12541.1.camel@shire>
References: <50817CAF-0AE8-4491-B806-277E76F8C2F2@gmail.com>
	<1204437331.12541.1.camel@shire>
Message-ID: <44dddf400803022109u2b235239xa772fb08fe0d6939@mail.gmail.com>

On Sun, Mar 2, 2008 at 12:55 AM, hemant kumar <gethemant at gmail.com> wrote:
>
>  On Sat, 2008-03-01 at 23:31 -0500, Benjamin H. Bryant wrote:
>  > So, after deleting the old version, I have tried getting the files
>  > from both gitorious and SVN using Piston.  Both locations left me with
>  > this error on startup:
>  >
>  > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
>  > `gem_original_require': no such file to load -- meta_worker
>  > (MissingSourceFile)
>  >       from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:
>  > 27:in `require'
>  >       from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/
>  > active_support/dependencies.rb:496:in `require'
>  >       from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/
>  > active_support/dependencies.rb:342:in `new_constants_in'
>  >       from /usr/local/lib/ruby/gems/1.8/gems/activesupport-2.0.2/lib/
>  > active_support/dependencies.rb:496:in `require'
>  >       from script/backgroundrb:17
>  >
>  >
>  > Ideas?
>
>  Did you delete your old "backgroundrb" script from script folder of your
>  rails directory? If not please do so, and run rake backgroundrb:setup.
>
>  Also, make sure you have packet-0.1.5 installed.

I found I also had to:

1. Install chronic gem.
2. Add 'require "rubygems"' to new script/backgroundrb

This seemed to fix my issues.

Hope this helps,

John

From todd at snappl.co.uk  Mon Mar  3 05:03:02 2008
From: todd at snappl.co.uk (Todd Tyree)
Date: Mon, 3 Mar 2008 10:03:02 +0000
Subject: [Backgroundrb-devel] require 'rubygems'
Message-ID: <44f20a950803030203u3d6e8f33t242efdf3f0b749f1@mail.gmail.com>

Not sure if its something funny in my environment or not, but I had to
require rubygems in the new version script/backgroundrb to get it to find
packet.  Otherwise, it would quit complaining that it couldn't find it.  My
setup is OSX 10.5.1 with rails 2.0.2 running against the most current
version of darwinports ruby.

Cheers,
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080303/f9f52daf/attachment.html 

From lists at sourceillustrated.com  Mon Mar  3 09:20:18 2008
From: lists at sourceillustrated.com (John Wells)
Date: Mon, 3 Mar 2008 09:20:18 -0500
Subject: [Backgroundrb-devel] require 'rubygems'
In-Reply-To: <44f20a950803030203u3d6e8f33t242efdf3f0b749f1@mail.gmail.com>
References: <44f20a950803030203u3d6e8f33t242efdf3f0b749f1@mail.gmail.com>
Message-ID: <44dddf400803030620p74ca98a7wa6a606ec77867e50@mail.gmail.com>

On Mon, Mar 3, 2008 at 5:03 AM, Todd Tyree <todd at snappl.co.uk> wrote:
> Not sure if its something funny in my environment or not, but I had to
> require rubygems in the new version script/backgroundrb to get it to find
> packet.  Otherwise, it would quit complaining that it couldn't find it.  My
> setup is OSX 10.5.1 with rails 2.0.2 running against the most current
> version of darwinports ruby.

FYI, I had to do the same on Debian Etch...

John

From gethemant at gmail.com  Mon Mar  3 09:39:57 2008
From: gethemant at gmail.com (hemant)
Date: Mon, 3 Mar 2008 20:09:57 +0530
Subject: [Backgroundrb-devel] require 'rubygems'
In-Reply-To: <44dddf400803030620p74ca98a7wa6a606ec77867e50@mail.gmail.com>
References: <44f20a950803030203u3d6e8f33t242efdf3f0b749f1@mail.gmail.com>
	<44dddf400803030620p74ca98a7wa6a606ec77867e50@mail.gmail.com>
Message-ID: <fb283d5e0803030639n16ac3c79m168bebada2dd149c@mail.gmail.com>

On Mon, Mar 3, 2008 at 7:50 PM, John Wells <lists at sourceillustrated.com> wrote:
>
> On Mon, Mar 3, 2008 at 5:03 AM, Todd Tyree <todd at snappl.co.uk> wrote:
>  > Not sure if its something funny in my environment or not, but I had to
>  > require rubygems in the new version script/backgroundrb to get it to find
>  > packet.  Otherwise, it would quit complaining that it couldn't find it.  My
>  > setup is OSX 10.5.1 with rails 2.0.2 running against the most current
>  > version of darwinports ruby.
>
>  FYI, I had to do the same on Debian Etch...
>

I am really sorry about this. I updated git repository will update svn repo too.

From clint at ctro.net  Mon Mar  3 12:08:50 2008
From: clint at ctro.net (Clint Troxel)
Date: Mon, 3 Mar 2008 10:08:50 -0700
Subject: [Backgroundrb-devel] 1.0.3 problems with script/start
Message-ID: <c9b2ca370803030908l18cc0237kce0e5d054076a497@mail.gmail.com>

Hi.  just updated to 1.0.3, and am having problems starting bdrb.  It
seems to be confused about my backgroundrb.yml file.

I'm trying to schedule recurring tasks from the yml file, it looks like this:

--------------------------------------------------------------------------------------------------
:backgroundrb:
  :ip: localhost
  :port: 11006
  :environment: development
  :log: foreground
:schedules:
  :app_task_worker:
    :clean_sessions:
      :trigger_args:
        :start: <%= Time.now + 5.seconds %>
        :end: <%= Time.now + 2.years %>
        :repeat_interval: <%= 1.day %>
--------------------------------------------------------------------------------------------------

here is some cmdline output:

ctro$ script/backgroundrb --version
1.0.3
ctro$ script/backgroundrb start
(erb):11: undefined method `seconds' for 5:Fixnum (NoMethodError)

---------------------------------------------------------------------------------------------------

Is this not the correct way to schedule the worker?

Also, a slightly related question:  how does the add_periodic_timer
method work?  Is it started up "automatically" like workers used to be
in the example above?

Thanks again!
-clint

From leavengood at gmail.com  Mon Mar  3 12:28:55 2008
From: leavengood at gmail.com (Ryan Leavengood)
Date: Mon, 3 Mar 2008 12:28:55 -0500
Subject: [Backgroundrb-devel] 1.0.3 problems with script/start
In-Reply-To: <c9b2ca370803030908l18cc0237kce0e5d054076a497@mail.gmail.com>
References: <c9b2ca370803030908l18cc0237kce0e5d054076a497@mail.gmail.com>
Message-ID: <a4855ac50803030928wf278115hec4991ad78dfd349@mail.gmail.com>

On Mon, Mar 3, 2008 at 12:08 PM, Clint Troxel <clint at ctro.net> wrote:
>  ctro$ script/backgroundrb start
>  (erb):11: undefined method `seconds' for 5:Fixnum (NoMethodError)
>
>  ---------------------------------------------------------------------------------------------------
>
>  Is this not the correct way to schedule the worker?

You are getting that error because the 5.seconds and 2.years methods
are not by default in Ruby, they are added by classes in Rails. It
seems the Rails code and environment is not loaded at the time the
backgroundrb.yml file is loaded.

Since the above syntax is shown on the BackgrounDRb documentation, I
can only assume this is a bug.

The simple solution for the time being is to just "expand" those
values using the Rails console:

Loading development environment.
>> 5.seconds
=> 5
>> 2.years
=> 63115200
>> 1.day
=> 86400

Then use those expanded values in the backgroundrb.yml file.

>  Also, a slightly related question:  how does the add_periodic_timer
>  method work?  Is it started up "automatically" like workers used to be
>  in the example above?

If you put a call to add_periodic_timer in your create method for
workers loaded automatically (which is all workers by default), then
yes the periodic timer will be set up automatically.

Regards,
Ryan

From rubyonrails-ug at peuchert.de  Mon Mar  3 17:42:45 2008
From: rubyonrails-ug at peuchert.de (Alex Peuchert)
Date: Mon, 03 Mar 2008 23:42:45 +0100
Subject: [Backgroundrb-devel] 1.0.3 problems with script/start
In-Reply-To: <a4855ac50803030928wf278115hec4991ad78dfd349@mail.gmail.com>
References: <c9b2ca370803030908l18cc0237kce0e5d054076a497@mail.gmail.com>
	<a4855ac50803030928wf278115hec4991ad78dfd349@mail.gmail.com>
Message-ID: <47CC7EE5.5010908@peuchert.de>

Ryan Leavengood wrote:
> On Mon, Mar 3, 2008 at 12:08 PM, Clint Troxel <clint at ctro.net> wrote:
>   
>>  ctro$ script/backgroundrb start
>>  (erb):11: undefined method `seconds' for 5:Fixnum (NoMethodError)
>>
>>  ---------------------------------------------------------------------------------------------------
>>
>>  Is this not the correct way to schedule the worker?
>>     
>
> You are getting that error because the 5.seconds and 2.years methods
> are not by default in Ruby, they are added by classes in Rails. It
> seems the Rails code and environment is not loaded at the time the
> backgroundrb.yml file is loaded.
>
> Since the above syntax is shown on the BackgrounDRb documentation, I
> can only assume this is a bug.
>
> The simple solution for the time being is to just "expand" those
> values using the Rails console:
>
> Loading development environment.
>   
>>> 5.seconds
>>>       
> => 5
>   
>>> 2.years
>>>       
> => 63115200
>   
>>> 1.day
>>>       
> => 86400
>
> Then use those expanded values in the backgroundrb.yml file.
>
>   
>>  Also, a slightly related question:  how does the add_periodic_timer
>>  method work?  Is it started up "automatically" like workers used to be
>>  in the example above?
>>     
>
> If you put a call to add_periodic_timer in your create method for
> workers loaded automatically (which is all workers by default), then
> yes the periodic timer will be set up automatically.
>
> Regards,
> Ryan
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
>   
Hi!
Thanks for the pointing this out. I changed the loading of the RoR 
framewok in script/backgroundrb:

- parse CLI parameters
- load RoR
- load config/backgroundrb.yml

submitted that to Gitorious repo as commit 78b956b

-Alex

From rue at thinlayer.co.uk  Tue Mar  4 05:32:49 2008
From: rue at thinlayer.co.uk (Rue Turner)
Date: Tue, 04 Mar 2008 10:32:49 +0000
Subject: [Backgroundrb-devel] failing on start (Errno::EADDRINUSE)
Message-ID: <1204626769.22348.20.camel@boudicca>

(first post - be gentle with me)


Just when I thought it was going well ;)

I'm getting the following on `ruby script/backgroundrb start`. The box
is fairly freshly built and has a pretty small gem list (also below)
It's also freshly booted and there aren't any spurious dead/zombie
processes running.

here's the output:

/.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
`initialize': Address already in use - bind(2) (Errno::EADDRINUSE)

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
`new'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
`start_server'

from /.../vendor/plugins/backgroundrb/server/master_worker.rb:166:in
`initialize'

from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'

from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
`initialize'
        from script/backgroundrb:41:in `new'
        from script/backgroundrb:41
/.../vendor/plugins/backgroundrb/lib/../framework/packet/nbio.rb:23:in
`read_data': Packet::DisconnectError (Packet::DisconnectError)

from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:47:in
`handle_internal_messages'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:158:in
`start_reactor'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
`each'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
`start_reactor'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
`loop'

from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
`start_reactor'

from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:21:in
`start_worker'

from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:139:in `fork_and_load'

from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:116:in `start_worker'

from /.../vendor/plugins/backgroundrb/server/master_worker.rb:165:in
`initialize'

from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'

from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
`initialize'
        from script/backgroundrb:41:in `new'
        from script/backgroundrb:41

and the config:

--- 
:backgroundrb: 
  :port: 11007
  :ip: 127.0.0.1
  :environment: development
  :log: foreground

The same error occurs even on a brand new rails app so I'm thinking it
could be a clashing gem issue?

*** LOCAL GEMS ***
actionmailer (2.0.2)
actionpack (2.0.2)
activerecord (2.0.2)
activeresource (2.0.2)
activesupport (2.0.2)
chronic (0.2.3)
gemsonrails (0.7.2)
graticule (0.2.6)
hoe (1.5.0)
mini_exiftool (0.5.0)
packet (0.1.5)
piston (1.4.0)
railroad (0.4.0)
rails (2.0.2)
rake (0.8.1)
ruby-openid (2.0.4)
rubyforge (0.4.4)
rubygems-update (1.0.1)
slave (1.2.1)


any help appreciated.


#rubyonrails / montyw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080304/d753815a/attachment-0001.html 

From gapeldoorn at wehkamp.nl  Tue Mar  4 05:46:41 2008
From: gapeldoorn at wehkamp.nl (Ger Apeldoorn)
Date: Tue, 04 Mar 2008 11:46:41 +0100
Subject: [Backgroundrb-devel] failing on start (Errno::EADDRINUSE)
In-Reply-To: <1204626769.22348.20.camel@boudicca>
References: <1204626769.22348.20.camel@boudicca>
Message-ID: <1204627601.26361.5.camel@gerdesktop.wehkamp.nl>

Hi,

Seems like it is:
- already running in the background (use "ps -ef | grep ruby" to see if
that's true)
- some other process is using that exact port.. (Unlikely)

Good luck,
Ger Apeldoorn

On Tue, 2008-03-04 at 10:32 +0000, Rue Turner wrote:
> (first post - be gentle with me)
> 
> 
> Just when I thought it was going well ;)
> 
> I'm getting the following on `ruby script/backgroundrb start`. The box
> is fairly freshly built and has a pretty small gem list (also below)
> It's also freshly booted and there aren't any spurious dead/zombie
> processes running.
> 
> here's the output:
> 
> /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> `new'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> `start_server'
> 
> from /.../vendor/plugins/backgroundrb/server/master_worker.rb:166:in
> `initialize'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'
> 
> from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
> `initialize'
>         from script/backgroundrb:41:in `new'
>         from script/backgroundrb:41
> /.../vendor/plugins/backgroundrb/lib/../framework/packet/nbio.rb:23:in
> `read_data': Packet::DisconnectError (Packet::DisconnectError)
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:47:in
> `handle_internal_messages'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:158:in
> `start_reactor'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
> `each'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
> `start_reactor'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
> `loop'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
> `start_reactor'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:21:in
> `start_worker'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:139:in `fork_and_load'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:116:in `start_worker'
> 
> from /.../vendor/plugins/backgroundrb/server/master_worker.rb:165:in
> `initialize'
> 
> from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'
> 
> from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
> `initialize'
>         from script/backgroundrb:41:in `new'
>         from script/backgroundrb:41
> 
> and the config:
> 
> --- 
> :backgroundrb: 
>   :port: 11007
>   :ip: 127.0.0.1
>   :environment: development
>   :log: foreground
> 
> The same error occurs even on a brand new rails app so I'm thinking it
> could be a clashing gem issue?
> 
> *** LOCAL GEMS ***
> actionmailer (2.0.2)
> actionpack (2.0.2)
> activerecord (2.0.2)
> activeresource (2.0.2)
> activesupport (2.0.2)
> chronic (0.2.3)
> gemsonrails (0.7.2)
> graticule (0.2.6)
> hoe (1.5.0)
> mini_exiftool (0.5.0)
> packet (0.1.5)
> piston (1.4.0)
> railroad (0.4.0)
> rails (2.0.2)
> rake (0.8.1)
> ruby-openid (2.0.4)
> rubyforge (0.4.4)
> rubygems-update (1.0.1)
> slave (1.2.1)
> 
> 
> any help appreciated.
> 
> 
> #rubyonrails / montyw 
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

From gethemant at gmail.com  Tue Mar  4 06:54:53 2008
From: gethemant at gmail.com (hemant kumar)
Date: Tue, 04 Mar 2008 17:24:53 +0530
Subject: [Backgroundrb-devel] failing on start (Errno::EADDRINUSE)
In-Reply-To: <1204627601.26361.5.camel@gerdesktop.wehkamp.nl>
References: <1204626769.22348.20.camel@boudicca>
	<1204627601.26361.5.camel@gerdesktop.wehkamp.nl>
Message-ID: <1204631693.26482.0.camel@shire>


On Tue, 2008-03-04 at 11:46 +0100, Ger Apeldoorn wrote:
> Hi,
> 
> Seems like it is:
> - already running in the background (use "ps -ef | grep ruby" to see if
> that's true)
> - some other process is using that exact port.. (Unlikely)
> 

Yes, thats right. Some application is already running on that port ( if
not backgroundrb).

You can try changing the port. 


From rue at thinlayer.co.uk  Tue Mar  4 07:34:12 2008
From: rue at thinlayer.co.uk (Rue Turner)
Date: Tue, 04 Mar 2008 12:34:12 +0000
Subject: [Backgroundrb-devel] failing on start (Errno::EADDRINUSE)
In-Reply-To: <1204627601.26361.5.camel@gerdesktop.wehkamp.nl>
References: <1204626769.22348.20.camel@boudicca>
	<1204627601.26361.5.camel@gerdesktop.wehkamp.nl>
Message-ID: <1204634052.25399.2.camel@boudicca>

*shamed*

thanks Ger, you were right with the first one. Not sure how it was still
happening after reboot - kubuntu does seem to start processes that you
last had running in their last state which is useful for general play
but worth taking care when you need a 'fresh' environment.


On Tue, 2008-03-04 at 11:46 +0100, Ger Apeldoorn wrote:

> Hi,
> 
> Seems like it is:
> - already running in the background (use "ps -ef | grep ruby" to see if
> that's true)
> - some other process is using that exact port.. (Unlikely)
> 
> Good luck,
> Ger Apeldoorn
> 
> On Tue, 2008-03-04 at 10:32 +0000, Rue Turner wrote:
> > (first post - be gentle with me)
> > 
> > 
> > Just when I thought it was going well ;)
> > 
> > I'm getting the following on `ruby script/backgroundrb start`. The box
> > is fairly freshly built and has a pretty small gem list (also below)
> > It's also freshly booted and there aren't any spurious dead/zombie
> > processes running.
> > 
> > here's the output:
> > 
> > /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> > `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> > `new'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:137:in
> > `start_server'
> > 
> > from /.../vendor/plugins/backgroundrb/server/master_worker.rb:166:in
> > `initialize'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'
> > 
> > from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
> > `initialize'
> >         from script/backgroundrb:41:in `new'
> >         from script/backgroundrb:41
> > /.../vendor/plugins/backgroundrb/lib/../framework/packet/nbio.rb:23:in
> > `read_data': Packet::DisconnectError (Packet::DisconnectError)
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:47:in
> > `handle_internal_messages'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:158:in
> > `start_reactor'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
> > `each'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
> > `start_reactor'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
> > `loop'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
> > `start_reactor'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/worker.rb:21:in
> > `start_worker'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:139:in `fork_and_load'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:116:in `start_worker'
> > 
> > from /.../vendor/plugins/backgroundrb/server/master_worker.rb:165:in
> > `initialize'
> > 
> > from /.../vendor/plugins/backgroundrb/framework/packet/packet_master.rb:18:in `run'
> > 
> > from /.../vendor/plugins/backgroundrb/server/master_worker.rb:163:in
> > `initialize'
> >         from script/backgroundrb:41:in `new'
> >         from script/backgroundrb:41
> > 
> > and the config:
> > 
> > --- 
> > :backgroundrb: 
> >   :port: 11007
> >   :ip: 127.0.0.1
> >   :environment: development
> >   :log: foreground
> > 
> > The same error occurs even on a brand new rails app so I'm thinking it
> > could be a clashing gem issue?
> > 
> > *** LOCAL GEMS ***
> > actionmailer (2.0.2)
> > actionpack (2.0.2)
> > activerecord (2.0.2)
> > activeresource (2.0.2)
> > activesupport (2.0.2)
> > chronic (0.2.3)
> > gemsonrails (0.7.2)
> > graticule (0.2.6)
> > hoe (1.5.0)
> > mini_exiftool (0.5.0)
> > packet (0.1.5)
> > piston (1.4.0)
> > railroad (0.4.0)
> > rails (2.0.2)
> > rake (0.8.1)
> > ruby-openid (2.0.4)
> > rubyforge (0.4.4)
> > rubygems-update (1.0.1)
> > slave (1.2.1)
> > 
> > 
> > any help appreciated.
> > 
> > 
> > #rubyonrails / montyw 
> > _______________________________________________
> > 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/20080304/d8d50ab5/attachment.html 

From tiffani2k3 at gmail.com  Tue Mar  4 08:45:38 2008
From: tiffani2k3 at gmail.com (Tiffani Ashley Bell)
Date: Tue, 4 Mar 2008 08:45:38 -0500
Subject: [Backgroundrb-devel] Quirks and such within bdrb ...
Message-ID: <ae27e1e40803040545p717b2c98s2c27619ff4cff399@mail.gmail.com>

Heyy everybody,

So far, in reading about bdrb, I've found it to be just what I'm looking for
much like other developers.  But, there are a few things I'm rather unclear
on and I figure folks on this last can clear things up.

So, I have the XMPP4R library that I'm tinkering around with and I've
created the following worker:

http://pastie.caboo.se/161129

I originally had problems with getting this code to run properly, but I
finally resolved those thanks to some previous posts on the list.  But, I'm
still running into a few issues here.  First, why does it seem as if you
can't access the arguments that are passed into the worker via the create
method when it's indeed loaded for the first time?  I either get that I'm
trying to access a nil or something else that prevents me from accessing the
arguments I passed to new_worker.  Or am I correlating the two wrongly
(create and new_worker)?

Secondly, in my connect_to_jabber method, I attempt to do things like create
a connection to Jabber and such.  Everything works fine outside of bdrb.  In
this case, I'm only wondering what the tasks you call on workers are
actually supposed to return and is the code I'm writing somehow preventing
these from working properly even though it works outside of bdrb?  Here's
just one line of what I was attempting to do earlier:

def connect_to_jabber(login_info=args)
   jid = JID.new(login_info)
   return "All done!"
end

When I run this code, *without* the first line, it does just fine.
Otherwise, bdrb just kinda sits there.  What am I doing wrong?

Here's what I'm doing in the controller, too, btw:

http://pastie.caboo.se/161138

TIA for any help/pointers,
Tiffani A.B.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080304/2a5bdb4c/attachment.html 

From rue at thinlayer.co.uk  Tue Mar  4 08:48:05 2008
From: rue at thinlayer.co.uk (Rue Turner)
Date: Tue, 04 Mar 2008 13:48:05 +0000
Subject: [Backgroundrb-devel] crashes on ask_status ?
Message-ID: <1204638485.25399.14.camel@boudicca>

IT all seems fine till I ask it to query the worker for anything
directly. Is packet broken? should we be using a specific version with
backgroundrb?

Console:

>> MiddleMan.query_all_workers
{:type=>:all_worker_status}
=> {:street_worker=>"foo", :log_worker=>nil}

that seems fine, then:

>> MiddleMan.ask_status(:worker_name => :street_worker)
{:type=>:get_status, :worker_name=>:street_worker}
=> nil

and the server barfs. The project is brand new and has nothing other
than this worker in it. The worker itself _only_ registers a status -
nothing else, no methods.

Here's the log:

/.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:119:in
`process_status': You have a nil object when you didn't expect it!
(NoMethodError)
The error occurred while evaluating nil.to_sym
from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:36:in
`receive_data'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:29:in `call'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:29:in `extract'

from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:31:in
`receive_data'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:212:in `read_external_socket'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:204:in `handle_external_messages'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:178:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:21:in `run'

from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in
`initialize'
        from script/backgroundrb:56:in `new'
        from script/backgroundrb:56
/usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in
`read_data': Packet::DisconnectError (Packet::DisconnectError)

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in `handle_internal_messages'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in `start_worker'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in `fork_and_load'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:96:in `load_workers'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in `each'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in `load_workers'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:20:in `run'

from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in
`initialize'
        from script/backgroundrb:56:in `new'
        from script/backgroundrb:56
/usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in
`read_data': Packet::DisconnectError (Packet::DisconnectError)

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in `handle_internal_messages'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in `start_worker'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in `fork_and_load'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:108:in `start_worker'

from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:169:in
`initialize'

from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:19:in `run'

from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in
`initialize'
        from script/backgroundrb:56:in `new'
        from script/backgroundrb:56


thanks guys
*sigh*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080304/72e91d10/attachment-0001.html 

From gethemant at gmail.com  Tue Mar  4 09:49:10 2008
From: gethemant at gmail.com (hemant kumar)
Date: Tue, 04 Mar 2008 20:19:10 +0530
Subject: [Backgroundrb-devel] crashes on ask_status ?
In-Reply-To: <1204638485.25399.14.camel@boudicca>
References: <1204638485.25399.14.camel@boudicca>
Message-ID: <1204642150.26482.3.camel@shire>


On Tue, 2008-03-04 at 13:48 +0000, Rue Turner wrote:
> IT all seems fine till I ask it to query the worker for anything
> directly. Is packet broken? should we be using a specific version with
> backgroundrb?
> 
> Console:
> 
> >> MiddleMan.query_all_workers
> {:type=>:all_worker_status}
> => {:street_worker=>"foo", :log_worker=>nil}
> 
> that seems fine, then:
> 
> >> MiddleMan.ask_status(:worker_name => :street_worker)
> {:type=>:get_status, :worker_name=>:street_worker}
> => nil
> 
> and the server barfs. The project is brand new and has nothing other
> than this worker in it. The worker itself _only_ registers a status -
> nothing else, no methods.
> 
> Here's the log:
> 
> /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:119:in
> `process_status': You have a nil object when you didn't expect it!
> (NoMethodError)
> The error occurred while evaluating nil.to_sym
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:36:in `receive_data'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:29:in `call'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:29:in `extract'
> 
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:212:in `read_external_socket'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:204:in `handle_external_messages'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:178:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:21:in `run'
> 
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
>         from script/backgroundrb:56:in `new'
>         from script/backgroundrb:56
> /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in `read_data': Packet::DisconnectError (Packet::DisconnectError)
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in `handle_internal_messages'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in `start_worker'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in `fork_and_load'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:96:in `load_workers'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in `each'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:91:in `load_workers'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:20:in `run'
> 
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
>         from script/backgroundrb:56:in `new'
>         from script/backgroundrb:56
> /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in `read_data': Packet::DisconnectError (Packet::DisconnectError)
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in `handle_internal_messages'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in `start_worker'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in `fork_and_load'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:108:in `start_worker'
> 
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:169:in `initialize'
> 
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:19:in `run'
> 
> from /.../vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
>         from script/backgroundrb:56:in `new'
>         from script/backgroundrb:56
> 
> 

>From where did you get: MiddleMan.ask_status(:worker_name
=> :street_worker) ?

It should be:

MiddleMan.ask_status(:worker => :street_worker) or
MiddleMan.worker(:street_worker).ask_status

Also, file a bug report nonetheless, since server shouldn't crash
anyways.



From gethemant at gmail.com  Tue Mar  4 11:03:29 2008
From: gethemant at gmail.com (hemant)
Date: Tue, 4 Mar 2008 21:33:29 +0530
Subject: [Backgroundrb-devel] Quirks and such within bdrb ...
In-Reply-To: <ae27e1e40803040545p717b2c98s2c27619ff4cff399@mail.gmail.com>
References: <ae27e1e40803040545p717b2c98s2c27619ff4cff399@mail.gmail.com>
Message-ID: <fb283d5e0803040803m64176978wbf11ab8431458744@mail.gmail.com>

On Tue, Mar 4, 2008 at 7:15 PM, Tiffani Ashley Bell
<tiffani2k3 at gmail.com> wrote:
> Heyy everybody,
>
> So far, in reading about bdrb, I've found it to be just what I'm looking for
> much like other developers.  But, there are a few things I'm rather unclear
> on and I figure folks on this last can clear things up.
>
> So, I have the XMPP4R library that I'm tinkering around with and I've
> created the following worker:
>
> http://pastie.caboo.se/161129
>
> I originally had problems with getting this code to run properly, but I
> finally resolved those thanks to some previous posts on the list.  But, I'm
> still running into a few issues here.  First, why does it seem as if you
> can't access the arguments that are passed into the worker via the create
> method when it's indeed loaded for the first time?  I either get that I'm
> trying to access a nil or something else that prevents me from accessing the
> arguments I passed to new_worker.  Or am I correlating the two wrongly
> (create and new_worker)?
>
> Secondly, in my connect_to_jabber method, I attempt to do things like create
> a connection to Jabber and such.  Everything works fine outside of bdrb.  In
> this case, I'm only wondering what the tasks you call on workers are
> actually supposed to return and is the code I'm writing somehow preventing
> these from working properly even though it works outside of bdrb?  Here's
> just one line of what I was attempting to do earlier:
>
> def connect_to_jabber(login_info=args)
>    jid = JID.new(login_info)
>    return "All done!"
> end
>
> When I run this code, *without* the first line, it does just fine.
> Otherwise, bdrb just kinda sits there.  What am I doing wrong?
>
> Here's what I'm doing in the controller, too, btw:
>
> http://pastie.caboo.se/161138
>
> TIA for any help/pointers,

Okay, did you read the docs at:

http://backgroundrb.rubyforge.org

thouroughly? Also send_request geenrally blocks until backgroundrb
server returns some data back to rails.

From mbukhin at gmail.com  Tue Mar  4 16:27:56 2008
From: mbukhin at gmail.com (mike bukhin)
Date: Tue, 4 Mar 2008 16:27:56 -0500
Subject: [Backgroundrb-devel] Cleaing up after workers in backgroundrb
Message-ID: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>

Hi there--

I just updated to the latest build of Backgroundrb and am hitting up
against a memory leak because my workers aren't cleaning up.  My code
concurrently pulls a large number of images using RMagick.  I thought
the problem was with RMagick but after putting in some garbage
collection code when pulling an image, my code runs well from irb.
When wrapped with backgroundrb, it eventually hangs.

In the old backgroundrb I had a self.delete at the end of do_work to
clean up.  Now my setup is a little different:

MiddleMan.worker(:context_worker).process_context(id)

and then

class ContextWorker < BackgrounDRb::MetaWorker

  set_worker_name :context_worker
  pool_size 1


  def create(args = nil)

  end

  def process_context(id)

     do_stuff()

  end

end

How do I clean up after process_context().

thanks


-- 
Mike Bukhin
Interactive Telecommunications Program - '07

From epugh at opensourceconnections.com  Tue Mar  4 20:35:10 2008
From: epugh at opensourceconnections.com (Eric Pugh)
Date: Tue, 4 Mar 2008 20:35:10 -0500
Subject: [Backgroundrb-devel] Vlad the Deployer??
Message-ID: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>

I've been playing around with Vlad the deployer, and quite like it.   
However, has anyone used it to stop/start background rb processes via  
the ./script/backgroundrb script?

Eric

-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com




From rubyonrails-ug at peuchert.de  Wed Mar  5 01:53:53 2008
From: rubyonrails-ug at peuchert.de (Alex Peuchert)
Date: Wed, 05 Mar 2008 07:53:53 +0100
Subject: [Backgroundrb-devel] Vlad the Deployer??
In-Reply-To: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>
References: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>
Message-ID: <47CE4381.5000402@peuchert.de>

Eric Pugh wrote:
> I've been playing around with Vlad the deployer, and quite like it.   
> However, has anyone used it to stop/start background rb processes via  
> the ./script/backgroundrb script?
>
> Eric
>
> -----------------------------------------------------
> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
>   
Hi Eric, I use vlad and have the following in my deploy.rb file:

namespace :vlad do
  desc "Restart the backgroundrb server"
  remote_task :start_app, :roles => :app do
    run "cd #{current_path}; ./script/backgroundrb start -e #{RAILS_ENV}"
  end

  desc "Stop the backgroundrb server"
  remote_task :stop_app, :roles => :app do
    run "cd #{current_path}; ./script/backgroundrb stop"
  end
end


-Alex


From email2ants at gmail.com  Wed Mar  5 08:42:36 2008
From: email2ants at gmail.com (Anthony Underwood)
Date: Wed, 5 Mar 2008 13:42:36 +0000
Subject: [Backgroundrb-devel] 1.03 and new API
Message-ID: <7CD38CAF-C41F-4006-95FE-E94A64E987A4@gmail.com>

Hi All

I've been getting all kinds of problems since upgrading to 1.03

Loads of crashes of the backgroundrb main script. script/backgroundrb  
stop fails to stop process so that script/background start fails due  
to the port already being bound
example crash
/home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:32:in `load':  
undefined class/module Job (ArgumentError)
	from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:32:in `receive_data'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:37:in `call'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:37:in `extract'
	from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:212:in `read_external_socket'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:204:in `handle_external_messages'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:178:in `handle_read_event'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `each'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `handle_read_event'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:130:in `start_reactor'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `loop'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `start_reactor'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:21:in `run'
	from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
	from script/backgroundrb:42:in `new'
	from script/backgroundrb:42
/usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb: 
25:in `read_data': Packet::DisconnectError (Packet::DisconnectError)
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_worker.rb:46:in `handle_internal_messages'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:176:in `handle_read_event'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `each'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `handle_read_event'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:130:in `start_reactor'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `loop'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `start_reactor'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_worker.rb:20:in `start_worker'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:133:in `fork_and_load'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:108:in `start_worker'
	from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:169:in `initialize'
	from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:19:in `run'
	from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/ 
plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
	from script/backgroundrb:42:in `new'
	from script/backgroundrb:42

The new api seems to be broken also

MiddleMan.new_worker(:long_job_worker, :job_key => @job.job_key, :data  
=> {:job => @job}) doesn't work reporting wrong number of arguments.

Like the new web page but it seems that the documentation is not quite  
ready. For the moment I'll have to rollback to the old version which  
was working well.


Please keep up the great development. Thanks

Anthony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080305/b9960437/attachment-0001.html 

From email2ants at gmail.com  Wed Mar  5 09:12:25 2008
From: email2ants at gmail.com (Anthony Underwood)
Date: Wed, 5 Mar 2008 14:12:25 +0000
Subject: [Backgroundrb-devel] Problems when starting worker in 1.03
Message-ID: <2B209BE4-3F30-4E7F-A0BC-ACFE089CE2D9@gmail.com>

Here's part of my worker class. When starting this worker without any  
args the server complains that it is trying to evaluate nil.[] in line  
6 despite the fact that a default is defined in the create method.  
This worked fine before 1.03


class LongJobWorker < BackgrounDRb::MetaWorker
   set_worker_name :long_job_worker
   set_no_auto_load(true)
   def create(args={})
     # this method is called, when worker is loaded for the first time
     @job = args[:job]
     register_status("started")
   end
  ........
end
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080305/c44170a6/attachment.html 

From todd at snappl.co.uk  Wed Mar  5 13:34:20 2008
From: todd at snappl.co.uk (Todd Tyree)
Date: Wed, 5 Mar 2008 18:34:20 +0000
Subject: [Backgroundrb-devel] Recalling threads
Message-ID: <44f20a950803051034s70c58209ja44eb2f74f5ec4a9@mail.gmail.com>

Hi,

I want to use backgroundrb to set up dead-man timers on user accounts.  If
someone is inactive for a set period, then the system will automatically log
them out and send an offline presence notification.  I've got this working
by spawning new workers with job keys and using page changes and periodic
calls to refresh a countdown timer in the worker.  However, this becomes
hard going if more than a few dozen users log in at the same time.  I've dug
through the documentation and tried a few things to no avail.  What I'm
wondering is, is it possible to add and access threads on a single worker
using a job key?   Alternately, is there a way to pre-fork a group of
workers and then assign (and reassign) them job keys?

Many Thanks,
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080305/7269de3c/attachment.html 

From jason at shotgunsoftware.com  Wed Mar  5 19:56:14 2008
From: jason at shotgunsoftware.com (Jason Ang)
Date: Wed, 5 Mar 2008 19:56:14 -0500
Subject: [Backgroundrb-devel] New output in 1.0.3
Message-ID: <F9D3B871-6D3D-49F2-BB19-8BE5D1153F2F@shotgunsoftware.com>

I see a whole bunch of new output in the shell I run "mongrel_rails  
start" locally, like:

{:type 
= 
 > 
:get_result 
, :data=>"joe", :worker=>:compute_worker, :worker_method=>:compute}

Setting debug_log to false doesn't disable this.  The previous version  
didn't have anything printed here--most of it went to the logs.  How  
do I disable this?

From jason at shotgunsoftware.com  Wed Mar  5 20:17:05 2008
From: jason at shotgunsoftware.com (Jason Ang)
Date: Wed, 5 Mar 2008 20:17:05 -0500
Subject: [Backgroundrb-devel] New output in 1.0.3
In-Reply-To: <F9D3B871-6D3D-49F2-BB19-8BE5D1153F2F@shotgunsoftware.com>
References: <F9D3B871-6D3D-49F2-BB19-8BE5D1153F2F@shotgunsoftware.com>
Message-ID: <2F1CACDC-4F47-4CBE-9A1A-1D998DEBFD27@shotgunsoftware.com>

Okay, I found out why:

lib/backgroundrb.rb#dump_object

has a "p data" which is printing the data.  I've removed it locally.

On 5-Mar-08, at 7:56 PM, Jason Ang wrote:

> I see a whole bunch of new output in the shell I run "mongrel_rails  
> start" locally, like:
>
> {:type 
> = 
> > 
> :get_result 
> , :data=>"joe", :worker=>:compute_worker, :worker_method=>:compute}
>
> Setting debug_log to false doesn't disable this.  The previous  
> version didn't have anything printed here--most of it went to the  
> logs.  How do I disable this?


From epugh at opensourceconnections.com  Wed Mar  5 20:52:44 2008
From: epugh at opensourceconnections.com (Eric Pugh)
Date: Wed, 5 Mar 2008 20:52:44 -0500
Subject: [Backgroundrb-devel] Vlad the Deployer??
In-Reply-To: <47CE4381.5000402@peuchert.de>
References: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>
	<47CE4381.5000402@peuchert.de>
Message-ID: <6D84BDD4-11C5-4B30-B1CA-045212E65E5F@opensourceconnections.com>

Wow...  That seems too easy...

I'll have to check, but I don't think when I start things that I pass  
a -e #{RAILS_ENV} with the 1.0.3 version of backgroundrb!

Eric
On Mar 5, 2008, at 1:53 AM, Alex Peuchert wrote:

> Eric Pugh wrote:
>> I've been playing around with Vlad the deployer, and quite like  
>> it.   However, has anyone used it to stop/start background rb  
>> processes via  the ./script/backgroundrb script?
>>
>> Eric
>>
>> -----------------------------------------------------
>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467  
>> | http://www.opensourceconnections.com
>>
>>
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>
>>
> Hi Eric, I use vlad and have the following in my deploy.rb file:
>
> namespace :vlad do
> desc "Restart the backgroundrb server"
> remote_task :start_app, :roles => :app do
>   run "cd #{current_path}; ./script/backgroundrb start -e  
> #{RAILS_ENV}"
> end
>
> desc "Stop the backgroundrb server"
> remote_task :stop_app, :roles => :app do
>   run "cd #{current_path}; ./script/backgroundrb stop"
> end
> end
>
>
> -Alex
>

-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com




From gethemant at gmail.com  Thu Mar  6 02:30:52 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:00:52 +0530
Subject: [Backgroundrb-devel] Cleaing up after workers in backgroundrb
In-Reply-To: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>
References: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>
Message-ID: <1204788653.8822.1.camel@shire>


On Tue, 2008-03-04 at 16:27 -0500, mike bukhin wrote:
> Hi there--
> 
> I just updated to the latest build of Backgroundrb and am hitting up
> against a memory leak because my workers aren't cleaning up.  My code
> concurrently pulls a large number of images using RMagick.  I thought
> the problem was with RMagick but after putting in some garbage
> collection code when pulling an image, my code runs well from irb.
> When wrapped with backgroundrb, it eventually hangs.
> 
> In the old backgroundrb I had a self.delete at the end of do_work to
> clean up.  Now my setup is a little different:
> 
> MiddleMan.worker(:context_worker).process_context(id)
> 
> and then
> 
> class ContextWorker < BackgrounDRb::MetaWorker
> 
>   set_worker_name :context_worker
>   pool_size 1
> 
> 
>   def create(args = nil)
> 
>   end
> 
>   def process_context(id)
> 
>      do_stuff()
> 
>   end
> 
> end
> 
> How do I clean up after process_context().
> 

You can still call, 'exit' at the end of worker to finish up execution
of task.

And what you mean by 'cleanup' actually? RMagick is one heck of a
library to work with, but if it works at irb prompt, should work in
BackgrounDRb worker too. Send us the worker code, and we will see whats
going wrong.



From gethemant at gmail.com  Thu Mar  6 02:33:04 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:03:04 +0530
Subject: [Backgroundrb-devel] 1.03 and new API
In-Reply-To: <7CD38CAF-C41F-4006-95FE-E94A64E987A4@gmail.com>
References: <7CD38CAF-C41F-4006-95FE-E94A64E987A4@gmail.com>
Message-ID: <1204788784.8822.4.camel@shire>


On Wed, 2008-03-05 at 13:42 +0000, Anthony Underwood wrote:
> Hi All
> 
> 
> I've been getting all kinds of problems since upgrading to 1.03
> 
> 
> Loads of crashes of the backgroundrb main script. script/backgroundrb
> stop fails to stop process so that script/background start fails due
> to the port already being bound
> example crash
> /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:32:in `load': undefined class/module Job (ArgumentError)
> from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:32:in `receive_data'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:37:in `call'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_parser.rb:37:in `extract'
> from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:212:in `read_external_socket'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:204:in `handle_external_messages'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:178:in `handle_read_event'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:21:in `run'
> from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
> from script/backgroundrb:42:in `new'
> from script/backgroundrb:42
> /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_nbio.rb:25:in `read_data': Packet::DisconnectError (Packet::DisconnectError)
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:46:in `handle_internal_messages'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:176:in `handle_read_event'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_worker.rb:20:in `start_worker'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:133:in `fork_and_load'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:108:in `start_worker'
> from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:169:in `initialize'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:19:in `run'
> from /home/f0/anthony/projects/minimum_snps/rails/minimum_snps/vendor/plugins/backgroundrb/server/lib/master_worker.rb:166:in `initialize'
> from script/backgroundrb:42:in `new'
> from script/backgroundrb:42
> 
> 
> The new api seems to be broken also
> 
> 
> MiddleMan.new_worker(:long_job_worker, :job_key => @job.job_key, :data
> => {:job => @job}) doesn't work reporting wrong number of arguments.
> 
> 
> Like the new web page but it seems that the documentation is not quite
> ready. For the moment I'll have to rollback to the old version which
> was working well.
> 

However, 1.0.3 is fully backward compatible with old API, since new APIs
are nothing but syntatic sugar around older ones.


> 


From gethemant at gmail.com  Thu Mar  6 02:33:58 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:03:58 +0530
Subject: [Backgroundrb-devel] Problems when starting worker in 1.03
In-Reply-To: <2B209BE4-3F30-4E7F-A0BC-ACFE089CE2D9@gmail.com>
References: <2B209BE4-3F30-4E7F-A0BC-ACFE089CE2D9@gmail.com>
Message-ID: <1204788838.8822.6.camel@shire>


On Wed, 2008-03-05 at 14:12 +0000, Anthony Underwood wrote:
> Here's part of my worker class. When starting this worker without any
> args the server complains that it is trying to evaluate nil.[] in line
> 6 despite the fact that a default is defined in the create method.
> This worked fine before 1.03
> 
> 
> 
> 
> class LongJobWorker < BackgrounDRb::MetaWorker
>   set_worker_name :long_job_worker
>   set_no_auto_load(true)
>   def create(args={})
>     # this method is called, when worker is loaded for the first time
>     @job = args[:job]
>     register_status("started")
>   end
>  ........
> end


Many, thanks. If possible, Also file a bug report so that it doesn't get
lost in mailing list junk.



From gethemant at gmail.com  Thu Mar  6 02:37:36 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:07:36 +0530
Subject: [Backgroundrb-devel] Recalling threads
In-Reply-To: <44f20a950803051034s70c58209ja44eb2f74f5ec4a9@mail.gmail.com>
References: <44f20a950803051034s70c58209ja44eb2f74f5ec4a9@mail.gmail.com>
Message-ID: <1204789056.8822.10.camel@shire>


On Wed, 2008-03-05 at 18:34 +0000, Todd Tyree wrote:
> Hi,
> 
> I want to use backgroundrb to set up dead-man timers on user accounts.
> If someone is inactive for a set period, then the system will
> automatically log them out and send an offline presence notification.
> I've got this working by spawning new workers with job keys and using
> page changes and periodic calls to refresh a countdown timer in the
> worker.  However, this becomes hard going if more than a few dozen
> users log in at the same time.  I've dug through the documentation and
> tried a few things to no avail.  What I'm wondering is, is it possible
> to add and access threads on a single worker using a job key?
> Alternately, is there a way to pre-fork a group of workers and then
> assign (and reassign) them job keys?
> us

If you lots of users coming in and spawning a worker for each them is
bad idea. You should probably be off using inbuilt thread pool.

However, it seems you want unique handle for each user. The best way to
achieve this is to use register_status with user_id or something inside
worker, so as when you invoke ask_status from your controller, you can
grab status based on user ids. What I am trying to say is, perhaps you
don't need a job_key for each thread invoked.



From gethemant at gmail.com  Thu Mar  6 02:38:53 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:08:53 +0530
Subject: [Backgroundrb-devel] New output in 1.0.3
In-Reply-To: <2F1CACDC-4F47-4CBE-9A1A-1D998DEBFD27@shotgunsoftware.com>
References: <F9D3B871-6D3D-49F2-BB19-8BE5D1153F2F@shotgunsoftware.com>
	<2F1CACDC-4F47-4CBE-9A1A-1D998DEBFD27@shotgunsoftware.com>
Message-ID: <1204789133.8822.12.camel@shire>


On Wed, 2008-03-05 at 20:17 -0500, Jason Ang wrote:
> Okay, I found out why:
> 
> lib/backgroundrb.rb#dump_object
> 
> has a "p data" which is printing the data.  I've removed it locally.

Good catch, we will remove it as well.



From rue at thinlayer.co.uk  Thu Mar  6 02:40:51 2008
From: rue at thinlayer.co.uk (Rue Turner)
Date: Thu, 06 Mar 2008 07:40:51 +0000
Subject: [Backgroundrb-devel] Cleaing up after workers in backgroundrb
In-Reply-To: <1204788653.8822.1.camel@shire>
References: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>
	<1204788653.8822.1.camel@shire>
Message-ID: <1204789251.16821.5.camel@boudicca>


On Thu, 2008-03-06 at 13:00 +0530, hemant kumar wrote:

> On Tue, 2008-03-04 at 16:27 -0500, mike bukhin wrote:
> > Hi there--
> > 
> > I just updated to the latest build of Backgroundrb and am hitting up
> > against a memory leak because my workers aren't cleaning up.  My code
> > concurrently pulls a large number of images using RMagick.  I thought
> > the problem was with RMagick but after putting in some garbage
> > collection code when pulling an image, my code runs well from irb.
> > When wrapped with backgroundrb, it eventually hangs.
> > 
> > In the old backgroundrb I had a self.delete at the end of do_work to
> > clean up.  Now my setup is a little different:
> > 
> > MiddleMan.worker(:context_worker).process_context(id)
> > 
> > and then
> > 
> > class ContextWorker < BackgrounDRb::MetaWorker
> > 
> >   set_worker_name :context_worker
> >   pool_size 1
> > 
> > 
> >   def create(args = nil)
> > 
> >   end
> > 
> >   def process_context(id)
> > 
> >      do_stuff()
> > 
> >   end
> > 
> > end
> > 
> > How do I clean up after process_context().
> > 
> 
> You can still call, 'exit' at the end of worker to finish up execution
> of task.
> 
> And what you mean by 'cleanup' actually? RMagick is one heck of a
> library to work with, but if it works at irb prompt, should work in
> BackgrounDRb worker too. Send us the worker code, and we will see whats
> going wrong.
> 
> 
> _______________________________________________
> 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/20080306/95941546/attachment.html 

From gethemant at gmail.com  Thu Mar  6 02:51:52 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 13:21:52 +0530
Subject: [Backgroundrb-devel] Vlad the Deployer??
In-Reply-To: <47CE4381.5000402@peuchert.de>
References: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>
	<47CE4381.5000402@peuchert.de>
Message-ID: <1204789912.8822.25.camel@shire>


On Wed, 2008-03-05 at 07:53 +0100, Alex Peuchert wrote:
> Eric Pugh wrote:
> > I've been playing around with Vlad the deployer, and quite like it.   
> > However, has anyone used it to stop/start background rb processes via  
> > the ./script/backgroundrb script?
> >
> > Eric
> >
> > -----------------------------------------------------
> > Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
> >
> >
> >
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
> >   
> Hi Eric, I use vlad and have the following in my deploy.rb file:
> 
> namespace :vlad do
>   desc "Restart the backgroundrb server"
>   remote_task :start_app, :roles => :app do
>     run "cd #{current_path}; ./script/backgroundrb start -e #{RAILS_ENV}"
>   end
> 
>   desc "Stop the backgroundrb server"
>   remote_task :stop_app, :roles => :app do
>     run "cd #{current_path}; ./script/backgroundrb stop"
>   end
> end
> 

Neat,

I use capistrano. But alex, can you update documentation with this bit
of information?



From gethemant at gmail.com  Thu Mar  6 04:45:47 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 15:15:47 +0530
Subject: [Backgroundrb-devel] Recalling threads
In-Reply-To: <44f20a950803060137h591285f9x40f6e5c3673cdebd@mail.gmail.com>
References: <44f20a950803051034s70c58209ja44eb2f74f5ec4a9@mail.gmail.com>
	<1204789056.8822.10.camel@shire>
	<44f20a950803060137h591285f9x40f6e5c3673cdebd@mail.gmail.com>
Message-ID: <1204796747.8822.33.camel@shire>


On Thu, 2008-03-06 at 09:37 +0000, Todd Tyree wrote:
> 
> 
>         If you lots of users coming in and spawning a worker for each
>         them is
>         bad idea. You should probably be off using inbuilt thread
>         pool.
>         
>         However, it seems you want unique handle for each user. The
>         best way to
>         achieve this is to use register_status with user_id or
>         something inside
>         worker, so as when you invoke ask_status from your controller,
>         you can
>         grab status based on user ids. What I am trying to say is,
>         perhaps you
>         don't need a job_key for each thread invoked.
>         
>         
> 
> Hi Hemant,
> 
> Thanks for that.  I think I understand where you're coming from with
> that suggestion and I'll give it a try.  In the meantime, could you
> just tell me if something like what I've outlined below is possible?
> I've tried a few variations and can't get it to work and just want to
> know if I'm going down a dead-end.
> 
> def create(user)
>    return Thread.new do
>        @shutdown = add_timer(60) { done(user, thread) }
>    end
> end
> 
> def keepalive(user, thread)
>   thread do
>     cancel_timer(@shutdown)
>     @shutdown = add_timer(60) { done(user. thread) }
>   end
> end 
> 
> def done(user,thread)
>   user.destroy
>   thread.destroy
> end
> 

I do not understand what you are trying to do? For one fact, you can
never pass threads across workers and rails.

Also, are you having one worker per user? If yes, then why you need
threads? If no, then you can easily have each thread in thread pool
mapped to individual user. Can you specify more clearly what this worker
does? If possible, can you send us, entire worker code so as I can see
more sense of purpose that I can scantly see now.




From mbukhin at gmail.com  Thu Mar  6 08:43:48 2008
From: mbukhin at gmail.com (mike bukhin)
Date: Thu, 6 Mar 2008 08:43:48 -0500
Subject: [Backgroundrb-devel] Cleaing up after workers in backgroundrb
In-Reply-To: <1204788653.8822.1.camel@shire>
References: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>
	<1204788653.8822.1.camel@shire>
Message-ID: <ebb840330803060543n231d49edo1d96495e8ee95bf8@mail.gmail.com>

I just remember that in the older version of backgroundrb I was having
memory/performance issues until I added self.delete to do_work.  Then
those problems went away.  My worker is very simple:

class ContextWorker < BackgrounDRb::MetaWorker

  set_worker_name :context_worker
  pool_size 5


  def create(args = nil)

  end

  def process_context(context_id)
    require 'context_update'
    @r_update = ContextUpdate.new(Time.now)
    @r_update.load_public_context(context_id)
  end

end


The bulk of the code is in libraries.  So you're saying I self.delete
is the same as putting exit after
@r_update.load_public_context(context_id)?

thanks!

On Thu, Mar 6, 2008 at 2:30 AM, hemant kumar <gethemant at gmail.com> wrote:
>
>
>  On Tue, 2008-03-04 at 16:27 -0500, mike bukhin wrote:
>  > Hi there--
>  >
>  > I just updated to the latest build of Backgroundrb and am hitting up
>  > against a memory leak because my workers aren't cleaning up.  My code
>  > concurrently pulls a large number of images using RMagick.  I thought
>  > the problem was with RMagick but after putting in some garbage
>  > collection code when pulling an image, my code runs well from irb.
>  > When wrapped with backgroundrb, it eventually hangs.
>  >
>  > In the old backgroundrb I had a self.delete at the end of do_work to
>  > clean up.  Now my setup is a little different:
>  >
>  > MiddleMan.worker(:context_worker).process_context(id)
>  >
>  > and then
>  >
>  > class ContextWorker < BackgrounDRb::MetaWorker
>  >
>  >   set_worker_name :context_worker
>  >   pool_size 1
>  >
>  >
>  >   def create(args = nil)
>  >
>  >   end
>  >
>  >   def process_context(id)
>  >
>  >      do_stuff()
>  >
>  >   end
>  >
>  > end
>  >
>  > How do I clean up after process_context().
>  >
>
>  You can still call, 'exit' at the end of worker to finish up execution
>  of task.
>
>  And what you mean by 'cleanup' actually? RMagick is one heck of a
>  library to work with, but if it works at irb prompt, should work in
>  BackgrounDRb worker too. Send us the worker code, and we will see whats
>  going wrong.
>
>
>



-- 
Mike Bukhin
Interactive Telecommunications Program - '07

From gethemant at gmail.com  Thu Mar  6 09:27:19 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 06 Mar 2008 19:57:19 +0530
Subject: [Backgroundrb-devel] Cleaing up after workers in backgroundrb
In-Reply-To: <ebb840330803060543n231d49edo1d96495e8ee95bf8@mail.gmail.com>
References: <ebb840330803041327x22876539i4ba2983751fb8cb8@mail.gmail.com>
	<1204788653.8822.1.camel@shire>
	<ebb840330803060543n231d49edo1d96495e8ee95bf8@mail.gmail.com>
Message-ID: <1204813639.8822.38.camel@shire>


On Thu, 2008-03-06 at 08:43 -0500, mike bukhin wrote:
> I just remember that in the older version of backgroundrb I was having
> memory/performance issues until I added self.delete to do_work.  Then
> those problems went away.  My worker is very simple:
> 
> class ContextWorker < BackgrounDRb::MetaWorker
> 
>   set_worker_name :context_worker
>   pool_size 5
> 
> 
>   def create(args = nil)
> 
>   end
> 
>   def process_context(context_id)
>     require 'context_update'
>     @r_update = ContextUpdate.new(Time.now)
>     @r_update.load_public_context(context_id)
>   end
> 
> end
> 
> 
> The bulk of the code is in libraries.  So you're saying I self.delete
> is the same as putting exit after
> @r_update.load_public_context(context_id)?
> 

As far as I remember self.delete used to delete/exit the current worker.
"exit" does the same thing in newer version.




From heisters at greenriver.org  Thu Mar  6 15:30:51 2008
From: heisters at greenriver.org (Ian Smith-Heisters)
Date: Thu, 6 Mar 2008 12:30:51 -0800
Subject: [Backgroundrb-devel] email on error
Message-ID: <de819a5b0803061230n6068865td665e9aebaec5fdd@mail.gmail.com>

Hi all,

I'm trying to figure out how to use exception_notification to alert me
of any error in bdrb. I'm not quite sure how bdrb handles errors,
though. It seems like implementing ExceptionNotifiable in my worker
class would catch any worker errors (maybe). But what if bdrb fails
before it loads the worker, or there some other internal bdrb error?
It seems to catch everything and put it in backgroundrb_debug.log, is
it possible to exploit whatever hook that uses?

I'll play around with it and RTFS, but I was just hoping someone might
have some prior experience with this.

Thanks,
Ian

From leavengood at gmail.com  Thu Mar  6 16:51:57 2008
From: leavengood at gmail.com (Ryan Leavengood)
Date: Thu, 6 Mar 2008 16:51:57 -0500
Subject: [Backgroundrb-devel] email on error
In-Reply-To: <de819a5b0803061230n6068865td665e9aebaec5fdd@mail.gmail.com>
References: <de819a5b0803061230n6068865td665e9aebaec5fdd@mail.gmail.com>
Message-ID: <a4855ac50803061351h5e0f2103l5033e9b909af1420@mail.gmail.com>

On Thu, Mar 6, 2008 at 3:30 PM, Ian Smith-Heisters
<heisters at greenriver.org> wrote:
>
>  I'm trying to figure out how to use exception_notification to alert me
>  of any error in bdrb. I'm not quite sure how bdrb handles errors,
>  though. It seems like implementing ExceptionNotifiable in my worker
>  class would catch any worker errors (maybe). But what if bdrb fails
>  before it loads the worker, or there some other internal bdrb error?
>  It seems to catch everything and put it in backgroundrb_debug.log, is
>  it possible to exploit whatever hook that uses?
>
>  I'll play around with it and RTFS, but I was just hoping someone might
>  have some prior experience with this.

I wanted something like this too and what I did was add some methods
to BackgrounDRb::MetaWorker like so:

class BackgrounDRb::MetaWorker
  def handle_exceptions
    result = nil

    if block_given?
      begin
        result = yield
      rescue Exception => e
        log_error(e)
      end
    end

    result
  end

  def log_error(error)
    case error
    when Exception
      class_name = self.class.name
      logger.info("Had exception #{error.class} in #{class_name},
sending email.")
      NotifyMailer.deliver_error_notification(error, class_name)
    else
      logger.info(error.to_s)
    end
  end
end

I put the above in a file in lib. I require it in my workers and then
call handle_exceptions with a block inside my worker methods. This
definitely works, though I don't know if it is the ideal way to do it.
For one thing it won't catch errors at the level of BackgrounDRb
itself. But at least for worker errors it is fine. Also as you can see
I defined my own error mailer that is very similar to the one from the
ExceptionNotifier plug-in.

It might be nice for BackgrounDRb to support something like this
itself. Maybe one of us could put together a patch.

Also I use the above with the last released version of BackgrounDRb, I
haven't yet upgraded. Though it will probably also work with the new
version.

Ryan

From epugh at opensourceconnections.com  Fri Mar  7 14:50:04 2008
From: epugh at opensourceconnections.com (Eric Pugh)
Date: Fri, 7 Mar 2008 14:50:04 -0500
Subject: [Backgroundrb-devel] Vlad the Deployer??
In-Reply-To: <1204789912.8822.25.camel@shire>
References: <CEFCDD69-0A2E-423B-9622-86F08E6B59F9@opensourceconnections.com>
	<47CE4381.5000402@peuchert.de> <1204789912.8822.25.camel@shire>
Message-ID: <F15F2C93-6D66-41E5-84ED-D97D036259BD@opensourceconnections.com>

I discovered when I dropped from my production environment my "dev"  
database that background rb keeps starting using Development!

This is what my Vlad rake task looks like:

   remote_task :start_app, :roles => :app do
     run "cd #{current_path}; ./script/backgroundrb start -e production"
   end

I noticed also I kept having a development.log file created, so I  
hacked around a bit and discovered that I can never get backgroundrb  
to start with in anything but "development" mode.

I added some debugging to bdrb_config.rb and can confirm that  
"production" is what is being passed in...  And my main Mongrel  
processes are all running in "production" mode as well..  Just not  
sure how the backgroundrb isn't getting the production setting!




On Mar 6, 2008, at 2:51 AM, hemant kumar wrote:

>
> On Wed, 2008-03-05 at 07:53 +0100, Alex Peuchert wrote:
>> Eric Pugh wrote:
>>> I've been playing around with Vlad the deployer, and quite like it.
>>> However, has anyone used it to stop/start background rb processes  
>>> via
>>> the ./script/backgroundrb script?
>>>
>>> Eric
>>>
>>> -----------------------------------------------------
>>> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467  
>>> | http://www.opensourceconnections.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Backgroundrb-devel mailing list
>>> Backgroundrb-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>>
>>>
>> Hi Eric, I use vlad and have the following in my deploy.rb file:
>>
>> namespace :vlad do
>>  desc "Restart the backgroundrb server"
>>  remote_task :start_app, :roles => :app do
>>    run "cd #{current_path}; ./script/backgroundrb start -e  
>> #{RAILS_ENV}"
>>  end
>>
>>  desc "Stop the backgroundrb server"
>>  remote_task :stop_app, :roles => :app do
>>    run "cd #{current_path}; ./script/backgroundrb stop"
>>  end
>> end
>>
>
> Neat,
>
> I use capistrano. But alex, can you update documentation with this bit
> of information?
>
>

-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com




From diegofcam at gmail.com  Sun Mar  9 11:59:32 2008
From: diegofcam at gmail.com (Diego Camacho)
Date: Sun, 9 Mar 2008 10:59:32 -0500
Subject: [Backgroundrb-devel] Multiple deployments of same application using
	backgroundrb
Message-ID: <c52c27c20803090859x7ba5c981rc5daf0178b1319f4@mail.gmail.com>

Thanks for this great app. I am having some problems configuring it in my
server. I have a single app deployed three times, one is for testing, one is
for demoing and the other one is for production.
I read that it was unnecesary and it will not work to have multiple
instances of backgroundrb for each of my deployments. I read that it was
enough to instantiate backgroundrb only once from one of the deployments and
the other deployments should use the workers on the deployment where
backgroundrb was started. I have been not been able to do this. If I request
a worker from a deployment that is not hosting the workers, I get errors in
the worker. I am just able to use the workers by restarting the mongrel
cluster that handles the deployment and by restarting backgroundrb in the
deployment I want to use the worker.

As a note, the worker is receiving a ActiveRecord object as a parameter and
the error seem to be coming from there. I am getting undefined methods in
the activerecord inside the worker.

What I am doing wrong ?.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080309/c093a1bf/attachment.html 

From noah at rapouts.com  Sun Mar  9 18:31:27 2008
From: noah at rapouts.com (Noah Horton)
Date: Sun, 9 Mar 2008 15:31:27 -0700
Subject: [Backgroundrb-devel] Using the ip flag
Message-ID: <C3F9B34F.2B2A%noah@rapouts.com>

Hey All,
  I am looking for an example of the proper config settings for background rb to run my rails app and my backgroundrb instance on separate machines (or more precisely, to have a rails cluster with one backgroundrb machine).  Does anyone have such examples?

Thanks!
-Noah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080309/dee389bd/attachment.html 

From todd at snappl.co.uk  Tue Mar 11 10:27:24 2008
From: todd at snappl.co.uk (Todd Tyree)
Date: Tue, 11 Mar 2008 14:27:24 +0000
Subject: [Backgroundrb-devel] Worker logging in test output.
Message-ID: <44f20a950803110727n78789d17ub005c4d818160587@mail.gmail.com>

Hi,

I'm trying to silence the information that backgroundrb is putting in to my
test runs.  I'm seeing several hundred lines of this during the test runs
(both unit and functional):

{:type=>:all_worker_info}
{:type=>:do_work, :worker=>:xmlrpc_xmpp_worker,
:worker_method=>:register_user,
:data=>{:xmpp_password=>"04ced0eda236a8690ec8ed30af63b3f2d886109c",
:userid=>1151}}

but can't find where it seems to be coming from.  How do I shut it off?  I'm
using 1.0.3 on 2.0.2 with the standard testing setup (i.e. no rspec).

Cheers,
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080311/4ba432c4/attachment.html 

From gethemant at gmail.com  Tue Mar 11 21:16:02 2008
From: gethemant at gmail.com (hemant kumar)
Date: Wed, 12 Mar 2008 06:46:02 +0530
Subject: [Backgroundrb-devel] Multiple deployments of same
	application	using backgroundrb
In-Reply-To: <c52c27c20803090859x7ba5c981rc5daf0178b1319f4@mail.gmail.com>
References: <c52c27c20803090859x7ba5c981rc5daf0178b1319f4@mail.gmail.com>
Message-ID: <1205284562.5707.9.camel@shire>

Hi,

First of all really sorry for late reply.

On Sun, 2008-03-09 at 10:59 -0500, Diego Camacho wrote:
> Thanks for this great app. I am having some problems configuring it in
> my server. I have a single app deployed three times, one is for
> testing, one is for demoing and the other one is for production.
> 
> 
> I read that it was unnecesary and it will not work to have multiple
> instances of backgroundrb for each of my deployments. I read that it
> was enough to instantiate backgroundrb only once from one of the
> deployments and the other deployments should use the workers on the
> deployment where backgroundrb was started. I have been not been able
> to do this. If I request a worker from a deployment that is not
> hosting the workers, I get errors in the worker. I am just able to use
> the workers by restarting the mongrel cluster that handles the
> deployment and by restarting backgroundrb in the deployment I want to
> use the worker.

You can do this if you are using same backgroundrb.yml file across all
deployments and assuming BackgrounDRb server is accessible from all
deployed machines. Are you using same config file?

> 
> 
> As a note, the worker is receiving a ActiveRecord object as a
> parameter and the error seem to be coming from there. I am getting
> undefined methods in the activerecord inside the worker.
> 

By default, You can't pass AR objects as arguments, however if you put following in your backgroundrb.yml file you can do that:

---
:backgroundrb:
  :port: 11006
  :ip: localhost
  :environment: production
  :lazy_load: false

Putting lazy_load as false will make sure that your models are loaded even in master process.






> 


From gethemant at gmail.com  Tue Mar 11 21:21:37 2008
From: gethemant at gmail.com (hemant kumar)
Date: Wed, 12 Mar 2008 06:51:37 +0530
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <C3F9B34F.2B2A%noah@rapouts.com>
References: <C3F9B34F.2B2A%noah@rapouts.com>
Message-ID: <1205284897.5707.16.camel@shire>

Hi Noah,

Sorry for late reply, I have been terribly busy with my day job and now
catching up on mails.

On Sun, 2008-03-09 at 15:31 -0700, Noah Horton wrote:
> Hey All,
>   I am looking for an example of the proper config settings for
> background rb to run my rails app and my backgroundrb instance on
> separate machines (or more precisely, to have a rails cluster with one
> backgroundrb machine).  Does anyone have such examples?
> 

Okay, so you need one BackgrounDRb server for each machine so as mongrel
clusters running on that machine has access to BackgrounDRb server
running on that machine?

If yes, you can simply use "0.0.0.0" as ip, and your mongrels running on
that machine will only use BackgrounDRb server running on that machine.

Also, I will advise you to use MemCache cluster for storing
status/result objects so as even if next request goes to mongrels
running on another machine, you will have access to result objects from
another BackgrounDRb server. I dunno, if I am answering your questions,
but if you have doubt shoot back.



From gethemant at gmail.com  Tue Mar 11 21:23:10 2008
From: gethemant at gmail.com (hemant kumar)
Date: Wed, 12 Mar 2008 06:53:10 +0530
Subject: [Backgroundrb-devel] Worker logging in test output.
In-Reply-To: <44f20a950803110727n78789d17ub005c4d818160587@mail.gmail.com>
References: <44f20a950803110727n78789d17ub005c4d818160587@mail.gmail.com>
Message-ID: <1205284990.5707.18.camel@shire>


On Tue, 2008-03-11 at 14:27 +0000, Todd Tyree wrote:
> Hi,
> 
> I'm trying to silence the information that backgroundrb is putting in
> to my test runs.  I'm seeing several hundred lines of this during the
> test runs (both unit and functional):
> 
> {:type=>:all_worker_info}
> {:type=>:do_work, :worker=>:xmlrpc_xmpp_worker, :worker_method=>:register_user, :data=>{:xmpp_password=>"04ced0eda236a8690ec8ed30af63b3f2d886109c", :userid=>1151}}
> 
> but can't find where it seems to be coming from.  How do I shut it
> off?  I'm using 1.0.3 on 2.0.2 with the standard testing setup (i.e.
> no rspec). 
> 

Just put debug_log: false for the time being to silence those log
messages. Example is available on http://backgroundrb.rubyforge.org





From noah at rapouts.com  Wed Mar 12 16:04:39 2008
From: noah at rapouts.com (Noah Horton)
Date: Wed, 12 Mar 2008 13:04:39 -0700
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <1205284897.5707.16.camel@shire>
Message-ID: <C3FD8567.2D50%noah@rapouts.com>

Actually, my requirements are a bit different.  Sorry for being unclear.  Thanks for your help on this!

My setup is that I have a cluster of machines (lets call them A, B and C) that are all running clusters of mongrels (lets say 3 per machine, labeled A1, A2, A3, B1, B2, B3, C1, C2, C3).

I want to setup another machine, D, such that it runs nothing but BackgroundRB.  All of the mongrels on all the machines (A, B and C) would call into the single instance of BackgroundRB on D.  Is this possible?



On 3/11/08 6:21 PM, "hemant kumar" <gethemant at gmail.com> wrote:

Hi Noah,

Sorry for late reply, I have been terribly busy with my day job and now
catching up on mails.

On Sun, 2008-03-09 at 15:31 -0700, Noah Horton wrote:
> Hey All,
>   I am looking for an example of the proper config settings for
> background rb to run my rails app and my backgroundrb instance on
> separate machines (or more precisely, to have a rails cluster with one
> backgroundrb machine).  Does anyone have such examples?
>

Okay, so you need one BackgrounDRb server for each machine so as mongrel
clusters running on that machine has access to BackgrounDRb server
running on that machine?

If yes, you can simply use "0.0.0.0" as ip, and your mongrels running on
that machine will only use BackgrounDRb server running on that machine.

Also, I will advise you to use MemCache cluster for storing
status/result objects so as even if next request goes to mongrels
running on another machine, you will have access to result objects from
another BackgrounDRb server. I dunno, if I am answering your questions,
but if you have doubt shoot back.



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

From leavengood at gmail.com  Wed Mar 12 16:39:06 2008
From: leavengood at gmail.com (Ryan Leavengood)
Date: Wed, 12 Mar 2008 16:39:06 -0400
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <C3FD8567.2D50%noah@rapouts.com>
References: <1205284897.5707.16.camel@shire> <C3FD8567.2D50%noah@rapouts.com>
Message-ID: <a4855ac50803121339t54599efif5620d977c79ed82@mail.gmail.com>

On Wed, Mar 12, 2008 at 4:04 PM, Noah Horton <noah at rapouts.com> wrote:
>
>  I want to setup another machine, D, such that it runs nothing but
> BackgroundRB.  All of the mongrels on all the machines (A, B and C) would
> call into the single instance of BackgroundRB on D.  Is this possible?

Yes that is possible and in fact as far as I know it is the preferred
approach. All you need is to have the IP address or server name for
the common BackgrounDRb server in a single backroundrb.yml file, which
all the other machines will use. If they are all the same application
code (which I assume they are), then you can just change the
backgroundrb.yml file in your source control tool and then update all
your servers.

Regards,
Ryan

From noah at rapouts.com  Wed Mar 12 16:47:42 2008
From: noah at rapouts.com (Noah Horton)
Date: Wed, 12 Mar 2008 13:47:42 -0700
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <a4855ac50803121339t54599efif5620d977c79ed82@mail.gmail.com>
Message-ID: <C3FD8F7E.2D5E%noah@rapouts.com>

Is there any config to get the backgroundrb instances to listen to requests from any machine besides localhost?


On 3/12/08 1:39 PM, "Ryan Leavengood" <leavengood at gmail.com> wrote:

On Wed, Mar 12, 2008 at 4:04 PM, Noah Horton <noah at rapouts.com> wrote:
>
>  I want to setup another machine, D, such that it runs nothing but
> BackgroundRB.  All of the mongrels on all the machines (A, B and C) would
> call into the single instance of BackgroundRB on D.  Is this possible?

Yes that is possible and in fact as far as I know it is the preferred
approach. All you need is to have the IP address or server name for
the common BackgrounDRb server in a single backroundrb.yml file, which
all the other machines will use. If they are all the same application
code (which I assume they are), then you can just change the
backgroundrb.yml file in your source control tool and then update all
your servers.

Regards,
Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080312/2c82e9a3/attachment-0001.html 

From leavengood at gmail.com  Wed Mar 12 17:02:10 2008
From: leavengood at gmail.com (Ryan Leavengood)
Date: Wed, 12 Mar 2008 17:02:10 -0400
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <C3FD8F7E.2D5E%noah@rapouts.com>
References: <a4855ac50803121339t54599efif5620d977c79ed82@mail.gmail.com>
	<C3FD8F7E.2D5E%noah@rapouts.com>
Message-ID: <a4855ac50803121402x67f1b47bv931435cf234d8624@mail.gmail.com>

On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton <noah at rapouts.com> wrote:
>
> Is there any config to get the backgroundrb instances to listen to requests
> from any machine besides localhost?

If you use the same backgroundrb.yml used for your Mongrel machines on
the BackgrounDRb machine (which you should), then it should listen on
the machine's IP which you have configured in that file. If you want
it to listen to all interfaces then use 0.0.0.0 like hemant said in
his previous post.

Regards,
Ryan

From noah at rapouts.com  Wed Mar 12 17:43:04 2008
From: noah at rapouts.com (Noah Horton)
Date: Wed, 12 Mar 2008 14:43:04 -0700
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <a4855ac50803121402x67f1b47bv931435cf234d8624@mail.gmail.com>
Message-ID: <C3FD9C78.2D70%noah@rapouts.com>

Wait - the default config used in all the examples has the backgroundrb workers listening to connections from all public interfaces?  That seems like a really risky thing.  Perhaps the examples should all get updated to 'localhost'.


On 3/12/08 2:02 PM, "Ryan Leavengood" <leavengood at gmail.com> wrote:

On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton <noah at rapouts.com> wrote:
>
> Is there any config to get the backgroundrb instances to listen to requests
> from any machine besides localhost?

If you use the same backgroundrb.yml used for your Mongrel machines on
the BackgrounDRb machine (which you should), then it should listen on
the machine's IP which you have configured in that file. If you want
it to listen to all interfaces then use 0.0.0.0 like hemant said in
his previous post.

Regards,
Ryan

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

From gethemant at gmail.com  Wed Mar 12 18:52:59 2008
From: gethemant at gmail.com (hemant kumar)
Date: Thu, 13 Mar 2008 04:22:59 +0530
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <C3FD9C78.2D70%noah@rapouts.com>
References: <C3FD9C78.2D70%noah@rapouts.com>
Message-ID: <1205362379.9326.31.camel@shire>


On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
> Wait ? the default config used in all the examples has the
> backgroundrb workers listening to connections from all public
> interfaces?  That seems like a really risky thing.  Perhaps the
> examples should all get updated to ?localhost?.
> 

Except 'localhost' doesn't work on Mac OSX from my experience.

> 
> On 3/12/08 2:02 PM, "Ryan Leavengood" <leavengood at gmail.com> wrote:
> 
>         On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
>         <noah at rapouts.com> wrote:
>         >
>         > Is there any config to get the backgroundrb instances to
>         listen to requests
>         > from any machine besides localhost?
>         
>         If you use the same backgroundrb.yml used for your Mongrel
>         machines on
>         the BackgrounDRb machine (which you should), then it should
>         listen on
>         the machine's IP which you have configured in that file. If
>         you want
>         it to listen to all interfaces then use 0.0.0.0 like hemant
>         said in
>         his previous post.
>         
>         Regards,
>         Ryan
>         
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From noah at rapouts.com  Wed Mar 12 19:29:45 2008
From: noah at rapouts.com (Noah Horton)
Date: Wed, 12 Mar 2008 16:29:45 -0700
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <1205362379.9326.31.camel@shire>
Message-ID: <C3FDB579.2D82%noah@rapouts.com>

Then I would make the default yml file have a comment above the default saying "This doesn't work on MacOS, you can use 0.0.0.0 but it will allow open network connections too".

I would wager that 80%+ of BackgroundRB deployments have not secured this since the security implications are not noted at all.  This seems really dangerous.


On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:



On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
> Wait - the default config used in all the examples has the
> backgroundrb workers listening to connections from all public
> interfaces?  That seems like a really risky thing.  Perhaps the
> examples should all get updated to 'localhost'.
>

Except 'localhost' doesn't work on Mac OSX from my experience.

>
> On 3/12/08 2:02 PM, "Ryan Leavengood" <leavengood at gmail.com> wrote:
>
>         On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
>         <noah at rapouts.com> wrote:
>         >
>         > Is there any config to get the backgroundrb instances to
>         listen to requests
>         > from any machine besides localhost?
>
>         If you use the same backgroundrb.yml used for your Mongrel
>         machines on
>         the BackgrounDRb machine (which you should), then it should
>         listen on
>         the machine's IP which you have configured in that file. If
>         you want
>         it to listen to all interfaces then use 0.0.0.0 like hemant
>         said in
>         his previous post.
>
>         Regards,
>         Ryan
>
> _______________________________________________
> 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/20080312/1092b52c/attachment.html 

From vansonsamuel at gmail.com  Thu Mar 13 11:48:41 2008
From: vansonsamuel at gmail.com (Vanson Samuel)
Date: Thu, 13 Mar 2008 11:48:41 -0400
Subject: [Backgroundrb-devel] Loading an array of MiddleMen
Message-ID: <b7ae96dd0803130848w46912467q6ad1cb9e577fc9e8@mail.gmail.com>

Hi,
I am currently working on a project that requires multiple rails
applications (lets call them consumers, since they will consume
requests) to exposes long running services that will be executed from
a management rails application (the producer of the requests).  To do
this BackgrounDrb was installed on all the consumers and the producer.
 BackgrounDrb was configured to on each of the consumers and the
configuration files were copied over to the producer.  This is where I
run into a problem, there can only be one MiddleMan on the producer.
In version .99 of BackgrounDrb I got over this hurdle by passing in
the configuration file path to BackgrounDrb.initialize.  I would then
instantiate and array of MiddleMen using the modified class.  I want
to do the same thing again for the new version.  Only this time I am
hoping that my changes will be merged into the trunk.  Please see the
attached patch and let me know if this is possible.

- Vanson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backgroundrb.rb.patch
Type: application/octet-stream
Size: 1088 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080313/4c0e5ddb/attachment.obj 

From email2ants at gmail.com  Thu Mar 13 12:26:57 2008
From: email2ants at gmail.com (Anthony Underwood)
Date: Thu, 13 Mar 2008 16:26:57 +0000
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <C3FDB579.2D82%noah@rapouts.com>
References: <C3FDB579.2D82%noah@rapouts.com>
Message-ID: <1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>

I am also interested in doing the same (2 servers running mongrels  
(IPs 158.119.147.x and 158.119.147.y) with another server (IP  
158.119.147.z) running background jobs).
To clarify I would have the rails apps on both x and y with the  
backgroundrb.yml file specifying 158.119.147.z).

What would I need on the backgroundrb server- just the backgroundrb  
script?
Would I also need a backgroundrb.yml file on this machine and does the  
IP here specify which machines to accept backgroundrb jobs from -  
would I set this to 158.119.147.0?
How would I start the backgroundrb script on the background job server?


Thanks for all your help


Anthony
On 12 Mar 2008, at 23:29, Noah Horton wrote:

> Then I would make the default yml file have a comment above the  
> default saying ?This doesn?t work on MacOS, you can use 0.0.0.0 but  
> it will allow open network connections too?.
>
> I would wager that 80%+ of BackgroundRB deployments have not secured  
> this since the security implications are not noted at all.  This  
> seems really dangerous.
>
>
> On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:
>
>
>
> On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
> > Wait ? the default config used in all the examples has the
> > backgroundrb workers listening to connections from all public
> > interfaces?  That seems like a really risky thing.  Perhaps the
> > examples should all get updated to ?localhost?.
> >
>
> Except 'localhost' doesn't work on Mac OSX from my experience.
>
> >
> > On 3/12/08 2:02 PM, "Ryan Leavengood" <leavengood at gmail.com> wrote:
> >
> >         On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
> >         <noah at rapouts.com> wrote:
> >         >
> >         > Is there any config to get the backgroundrb instances to
> >         listen to requests
> >         > from any machine besides localhost?
> >
> >         If you use the same backgroundrb.yml used for your Mongrel
> >         machines on
> >         the BackgrounDRb machine (which you should), then it should
> >         listen on
> >         the machine's IP which you have configured in that file. If
> >         you want
> >         it to listen to all interfaces then use 0.0.0.0 like hemant
> >         said in
> >         his previous post.
> >
> >         Regards,
> >         Ryan
> >
> > _______________________________________________
> > 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/20080313/0a15c86c/attachment-0001.html 

From gethemant at gmail.com  Fri Mar 14 00:50:03 2008
From: gethemant at gmail.com (hemant kumar)
Date: Fri, 14 Mar 2008 10:20:03 +0530
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>
References: <C3FDB579.2D82%noah@rapouts.com>
	<1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>
Message-ID: <1205470203.7620.4.camel@shire>


On Thu, 2008-03-13 at 16:26 +0000, Anthony Underwood wrote:
> I am also interested in doing the same (2 servers running mongrels
> (IPs 158.119.147.x and 158.119.147.y) with another server (IP
> 158.119.147.z) running background jobs). 
> To clarify I would have the rails apps on both x and y with the
> backgroundrb.yml file specifying 158.119.147.z). 

Yes that would certainly work!

> 
> 
> What would I need on the backgroundrb server- just the backgroundrb
> script?
> Would I also need a backgroundrb.yml file on this machine and does the
> IP here specify which machines to accept backgroundrb jobs from -
> would I set this to 158.119.147.0?
> How would I start the backgroundrb script on the background job
> server?

What you will need on BackgrounDRb server is the backgroundrb.yml file
and your rails application ( because you want access to your rails
environment in BackgrounDRB workers ). You won't need to run any
mongrels on that machine and on machines running mongrels you can just
point ip of BackgrounDRB server in backgroundrb.yml file and it should
suffice. Let us know, how it goes for you!


> 
> 
> 
> 
> Thanks for all your help
> 
> 
> 
> 
> Anthony
> On 12 Mar 2008, at 23:29, Noah Horton wrote:
> 
> > Then I would make the default yml file have a comment above the
> > default saying ?This doesn?t work on MacOS, you can use 0.0.0.0 but
> > it will allow open network connections too?.
> > 
> > I would wager that 80%+ of BackgroundRB deployments have not secured
> > this since the security implications are not noted at all.  This
> > seems really dangerous.
> > 
> > 
> > On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:
> > 
> >         
> >         
> >         On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
> >         > Wait ? the default config used in all the examples has the
> >         > backgroundrb workers listening to connections from all
> >         public
> >         > interfaces?  That seems like a really risky thing.
> >          Perhaps the
> >         > examples should all get updated to ?localhost?.
> >         >
> >         
> >         Except 'localhost' doesn't work on Mac OSX from my
> >         experience.
> >         
> >         >
> >         > On 3/12/08 2:02 PM, "Ryan Leavengood"
> >         <leavengood at gmail.com> wrote:
> >         >
> >         >         On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
> >         >         <noah at rapouts.com> wrote:
> >         >         >
> >         >         > Is there any config to get the backgroundrb
> >         instances to
> >         >         listen to requests
> >         >         > from any machine besides localhost?
> >         >
> >         >         If you use the same backgroundrb.yml used for your
> >         Mongrel
> >         >         machines on
> >         >         the BackgrounDRb machine (which you should), then
> >         it should
> >         >         listen on
> >         >         the machine's IP which you have configured in that
> >         file. If
> >         >         you want
> >         >         it to listen to all interfaces then use 0.0.0.0
> >         like hemant
> >         >         said in
> >         >         his previous post.
> >         >
> >         >         Regards,
> >         >         Ryan
> >         >
> >         > _______________________________________________
> >         > 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
> 
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From gethemant at gmail.com  Fri Mar 14 00:53:41 2008
From: gethemant at gmail.com (hemant kumar)
Date: Fri, 14 Mar 2008 10:23:41 +0530
Subject: [Backgroundrb-devel] Loading an array of MiddleMen
In-Reply-To: <b7ae96dd0803130848w46912467q6ad1cb9e577fc9e8@mail.gmail.com>
References: <b7ae96dd0803130848w46912467q6ad1cb9e577fc9e8@mail.gmail.com>
Message-ID: <1205470421.7620.8.camel@shire>


On Thu, 2008-03-13 at 11:48 -0400, Vanson Samuel wrote:
> Hi,
> I am currently working on a project that requires multiple rails
> applications (lets call them consumers, since they will consume
> requests) to exposes long running services that will be executed from
> a management rails application (the producer of the requests).  To do
> this BackgrounDrb was installed on all the consumers and the producer.
>  BackgrounDrb was configured to on each of the consumers and the
> configuration files were copied over to the producer.  This is where I
> run into a problem, there can only be one MiddleMan on the producer.
> In version .99 of BackgrounDrb I got over this hurdle by passing in
> the configuration file path to BackgrounDrb.initialize.  I would then
> instantiate and array of MiddleMen using the modified class.  I want
> to do the same thing again for the new version.  Only this time I am
> hoping that my changes will be merged into the trunk.  Please see the
> attached patch and let me know if this is possible.
> 

Yes, that should work. Can you submit your patch with git-format-patch
so as I can commit it. You also need to submit some test cases, if you
want the patch to in. Also, you are not mentioning whats there in
backgroundrb_environment.rb file.

Just to clarify further, if inside your rails application you need an
array of middleman all you need to do is, creating custom middlemen by
requiring backgroundrb.rb file and changing ip and port to which it
connects. I think, details are pretty bare and should be easily
hackable.



From email2ants at gmail.com  Fri Mar 14 04:49:11 2008
From: email2ants at gmail.com (Anthony Underwood)
Date: Fri, 14 Mar 2008 08:49:11 +0000
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <1205470203.7620.4.camel@shire>
References: <C3FDB579.2D82%noah@rapouts.com>
	<1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>
	<1205470203.7620.4.camel@shire>
Message-ID: <6A8BC794-86DE-4C6F-B44F-8CA573A8854F@gmail.com>

Hi Hemant,

Thanks for your help. How would it work if I have more than one rails  
application accessing the backgroundrb server. Would I have both rails  
apps on the background server and start the backgroundrb script in  
both applications?

Thanks

Anthony

On 14 Mar 2008, at 04:50, hemant kumar wrote:

>
> On Thu, 2008-03-13 at 16:26 +0000, Anthony Underwood wrote:
>> I am also interested in doing the same (2 servers running mongrels
>> (IPs 158.119.147.x and 158.119.147.y) with another server (IP
>> 158.119.147.z) running background jobs).
>> To clarify I would have the rails apps on both x and y with the
>> backgroundrb.yml file specifying 158.119.147.z).
>
> Yes that would certainly work!
>
>>
>>
>> What would I need on the backgroundrb server- just the backgroundrb
>> script?
>> Would I also need a backgroundrb.yml file on this machine and does  
>> the
>> IP here specify which machines to accept backgroundrb jobs from -
>> would I set this to 158.119.147.0?
>> How would I start the backgroundrb script on the background job
>> server?
>
> What you will need on BackgrounDRb server is the backgroundrb.yml file
> and your rails application ( because you want access to your rails
> environment in BackgrounDRB workers ). You won't need to run any
> mongrels on that machine and on machines running mongrels you can just
> point ip of BackgrounDRB server in backgroundrb.yml file and it should
> suffice. Let us know, how it goes for you!
>
>
>>
>>
>>
>>
>> Thanks for all your help
>>
>>
>>
>>
>> Anthony
>> On 12 Mar 2008, at 23:29, Noah Horton wrote:
>>
>>> Then I would make the default yml file have a comment above the
>>> default saying ?This doesn?t work on MacOS, you can use 0.0.0.0 but
>>> it will allow open network connections too?.
>>>
>>> I would wager that 80%+ of BackgroundRB deployments have not secured
>>> this since the security implications are not noted at all.  This
>>> seems really dangerous.
>>>
>>>
>>> On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:
>>>
>>>
>>>
>>>        On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
>>>> Wait ? the default config used in all the examples has the
>>>> backgroundrb workers listening to connections from all
>>>        public
>>>> interfaces?  That seems like a really risky thing.
>>>         Perhaps the
>>>> examples should all get updated to ?localhost?.
>>>>
>>>
>>>        Except 'localhost' doesn't work on Mac OSX from my
>>>        experience.
>>>
>>>>
>>>> On 3/12/08 2:02 PM, "Ryan Leavengood"
>>>        <leavengood at gmail.com> wrote:
>>>>
>>>>        On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
>>>>        <noah at rapouts.com> wrote:
>>>>>
>>>>> Is there any config to get the backgroundrb
>>>        instances to
>>>>        listen to requests
>>>>> from any machine besides localhost?
>>>>
>>>>        If you use the same backgroundrb.yml used for your
>>>        Mongrel
>>>>        machines on
>>>>        the BackgrounDRb machine (which you should), then
>>>        it should
>>>>        listen on
>>>>        the machine's IP which you have configured in that
>>>        file. If
>>>>        you want
>>>>        it to listen to all interfaces then use 0.0.0.0
>>>        like hemant
>>>>        said in
>>>>        his previous post.
>>>>
>>>>        Regards,
>>>>        Ryan
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>


From gethemant at gmail.com  Fri Mar 14 05:18:04 2008
From: gethemant at gmail.com (hemant kumar)
Date: Fri, 14 Mar 2008 14:48:04 +0530
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <6A8BC794-86DE-4C6F-B44F-8CA573A8854F@gmail.com>
References: <C3FDB579.2D82%noah@rapouts.com>
	<1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>
	<1205470203.7620.4.camel@shire>
	<6A8BC794-86DE-4C6F-B44F-8CA573A8854F@gmail.com>
Message-ID: <1205486284.9579.14.camel@shire>


On Fri, 2008-03-14 at 08:49 +0000, Anthony Underwood wrote:
> Hi Hemant,
> 
> Thanks for your help. How would it work if I have more than one rails  
> application accessing the backgroundrb server. Would I have both rails  
> apps on the background server and start the backgroundrb script in  
> both applications?
> 

Out of box, you can't/shouldn't access same backgroundrb server from two
different rails application( i.e entirely different rails application,
you can very well access backgroundrb server from any instances of same
rails applications). 

So, If you want to have more than one rails application (that's to say
with different code base) using same bdrb server, you will have to setup
rails environment of bdrb server so as models/libs/plugins used in both
applications are present in bdrb server's rails instance.This is tricky
and I won't advise you to go with this.

However, you can have two instances of bdrb servers, running on same
machine, but different ports, being used from different rails
applications.




> Thanks
> 
> Anthony
> 
> On 14 Mar 2008, at 04:50, hemant kumar wrote:
> 
> >
> > On Thu, 2008-03-13 at 16:26 +0000, Anthony Underwood wrote:
> >> I am also interested in doing the same (2 servers running mongrels
> >> (IPs 158.119.147.x and 158.119.147.y) with another server (IP
> >> 158.119.147.z) running background jobs).
> >> To clarify I would have the rails apps on both x and y with the
> >> backgroundrb.yml file specifying 158.119.147.z).
> >
> > Yes that would certainly work!
> >
> >>
> >>
> >> What would I need on the backgroundrb server- just the backgroundrb
> >> script?
> >> Would I also need a backgroundrb.yml file on this machine and does  
> >> the
> >> IP here specify which machines to accept backgroundrb jobs from -
> >> would I set this to 158.119.147.0?
> >> How would I start the backgroundrb script on the background job
> >> server?
> >
> > What you will need on BackgrounDRb server is the backgroundrb.yml file
> > and your rails application ( because you want access to your rails
> > environment in BackgrounDRB workers ). You won't need to run any
> > mongrels on that machine and on machines running mongrels you can just
> > point ip of BackgrounDRB server in backgroundrb.yml file and it should
> > suffice. Let us know, how it goes for you!
> >
> >
> >>
> >>
> >>
> >>
> >> Thanks for all your help
> >>
> >>
> >>
> >>
> >> Anthony
> >> On 12 Mar 2008, at 23:29, Noah Horton wrote:
> >>
> >>> Then I would make the default yml file have a comment above the
> >>> default saying ?This doesn?t work on MacOS, you can use 0.0.0.0 but
> >>> it will allow open network connections too?.
> >>>
> >>> I would wager that 80%+ of BackgroundRB deployments have not secured
> >>> this since the security implications are not noted at all.  This
> >>> seems really dangerous.
> >>>
> >>>
> >>> On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>        On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
> >>>> Wait ? the default config used in all the examples has the
> >>>> backgroundrb workers listening to connections from all
> >>>        public
> >>>> interfaces?  That seems like a really risky thing.
> >>>         Perhaps the
> >>>> examples should all get updated to ?localhost?.
> >>>>
> >>>
> >>>        Except 'localhost' doesn't work on Mac OSX from my
> >>>        experience.
> >>>
> >>>>
> >>>> On 3/12/08 2:02 PM, "Ryan Leavengood"
> >>>        <leavengood at gmail.com> wrote:
> >>>>
> >>>>        On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
> >>>>        <noah at rapouts.com> wrote:
> >>>>>
> >>>>> Is there any config to get the backgroundrb
> >>>        instances to
> >>>>        listen to requests
> >>>>> from any machine besides localhost?
> >>>>
> >>>>        If you use the same backgroundrb.yml used for your
> >>>        Mongrel
> >>>>        machines on
> >>>>        the BackgrounDRb machine (which you should), then
> >>>        it should
> >>>>        listen on
> >>>>        the machine's IP which you have configured in that
> >>>        file. If
> >>>>        you want
> >>>>        it to listen to all interfaces then use 0.0.0.0
> >>>        like hemant
> >>>>        said in
> >>>>        his previous post.
> >>>>
> >>>>        Regards,
> >>>>        Ryan
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> Backgroundrb-devel mailing list
> >> Backgroundrb-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
> 


From email2ants at gmail.com  Fri Mar 14 05:41:54 2008
From: email2ants at gmail.com (Anthony Underwood)
Date: Fri, 14 Mar 2008 09:41:54 +0000
Subject: [Backgroundrb-devel] Using the ip flag
In-Reply-To: <1205486284.9579.14.camel@shire>
References: <C3FDB579.2D82%noah@rapouts.com>
	<1C303BC7-8411-48A7-A031-34AED813125D@gmail.com>
	<1205470203.7620.4.camel@shire>
	<6A8BC794-86DE-4C6F-B44F-8CA573A8854F@gmail.com>
	<1205486284.9579.14.camel@shire>
Message-ID: <49F0DC46-3980-4984-A1C7-D9A4DF2496F2@gmail.com>

Thanks,

Sorry to be a bit slow. So to clarify I would have copies of each  
rails app on the backgroundrb machine where the port in the  
backgroundrb.yml has been set to different values. I would then start  
several backgroundrb instances (one for each app) by running script/ 
backgroundrb start within app.


Thanks


Anthony
On 14 Mar 2008, at 09:18, hemant kumar wrote:

>
> On Fri, 2008-03-14 at 08:49 +0000, Anthony Underwood wrote:
>> Hi Hemant,
>>
>> Thanks for your help. How would it work if I have more than one rails
>> application accessing the backgroundrb server. Would I have both  
>> rails
>> apps on the background server and start the backgroundrb script in
>> both applications?
>>
>
> Out of box, you can't/shouldn't access same backgroundrb server from  
> two
> different rails application( i.e entirely different rails application,
> you can very well access backgroundrb server from any instances of  
> same
> rails applications).
>
> So, If you want to have more than one rails application (that's to say
> with different code base) using same bdrb server, you will have to  
> setup
> rails environment of bdrb server so as models/libs/plugins used in  
> both
> applications are present in bdrb server's rails instance.This is  
> tricky
> and I won't advise you to go with this.
>
> However, you can have two instances of bdrb servers, running on same
> machine, but different ports, being used from different rails
> applications.
>
>
>
>
>> Thanks
>>
>> Anthony
>>
>> On 14 Mar 2008, at 04:50, hemant kumar wrote:
>>
>>>
>>> On Thu, 2008-03-13 at 16:26 +0000, Anthony Underwood wrote:
>>>> I am also interested in doing the same (2 servers running mongrels
>>>> (IPs 158.119.147.x and 158.119.147.y) with another server (IP
>>>> 158.119.147.z) running background jobs).
>>>> To clarify I would have the rails apps on both x and y with the
>>>> backgroundrb.yml file specifying 158.119.147.z).
>>>
>>> Yes that would certainly work!
>>>
>>>>
>>>>
>>>> What would I need on the backgroundrb server- just the backgroundrb
>>>> script?
>>>> Would I also need a backgroundrb.yml file on this machine and does
>>>> the
>>>> IP here specify which machines to accept backgroundrb jobs from -
>>>> would I set this to 158.119.147.0?
>>>> How would I start the backgroundrb script on the background job
>>>> server?
>>>
>>> What you will need on BackgrounDRb server is the backgroundrb.yml  
>>> file
>>> and your rails application ( because you want access to your rails
>>> environment in BackgrounDRB workers ). You won't need to run any
>>> mongrels on that machine and on machines running mongrels you can  
>>> just
>>> point ip of BackgrounDRB server in backgroundrb.yml file and it  
>>> should
>>> suffice. Let us know, how it goes for you!
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks for all your help
>>>>
>>>>
>>>>
>>>>
>>>> Anthony
>>>> On 12 Mar 2008, at 23:29, Noah Horton wrote:
>>>>
>>>>> Then I would make the default yml file have a comment above the
>>>>> default saying ?This doesn?t work on MacOS, you can use 0.0.0.0  
>>>>> but
>>>>> it will allow open network connections too?.
>>>>>
>>>>> I would wager that 80%+ of BackgroundRB deployments have not  
>>>>> secured
>>>>> this since the security implications are not noted at all.  This
>>>>> seems really dangerous.
>>>>>
>>>>>
>>>>> On 3/12/08 3:52 PM, "hemant kumar" <gethemant at gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>       On Wed, 2008-03-12 at 14:43 -0700, Noah Horton wrote:
>>>>>> Wait ? the default config used in all the examples has the
>>>>>> backgroundrb workers listening to connections from all
>>>>>       public
>>>>>> interfaces?  That seems like a really risky thing.
>>>>>        Perhaps the
>>>>>> examples should all get updated to ?localhost?.
>>>>>>
>>>>>
>>>>>       Except 'localhost' doesn't work on Mac OSX from my
>>>>>       experience.
>>>>>
>>>>>>
>>>>>> On 3/12/08 2:02 PM, "Ryan Leavengood"
>>>>>       <leavengood at gmail.com> wrote:
>>>>>>
>>>>>>       On Wed, Mar 12, 2008 at 4:47 PM, Noah Horton
>>>>>>       <noah at rapouts.com> wrote:
>>>>>>>
>>>>>>> Is there any config to get the backgroundrb
>>>>>       instances to
>>>>>>       listen to requests
>>>>>>> from any machine besides localhost?
>>>>>>
>>>>>>       If you use the same backgroundrb.yml used for your
>>>>>       Mongrel
>>>>>>       machines on
>>>>>>       the BackgrounDRb machine (which you should), then
>>>>>       it should
>>>>>>       listen on
>>>>>>       the machine's IP which you have configured in that
>>>>>       file. If
>>>>>>       you want
>>>>>>       it to listen to all interfaces then use 0.0.0.0
>>>>>       like hemant
>>>>>>       said in
>>>>>>       his previous post.
>>>>>>
>>>>>>       Regards,
>>>>>>       Ryan
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> Backgroundrb-devel mailing list
>>>> Backgroundrb-devel at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>>
>>
>


From vansonsamuel at gmail.com  Fri Mar 14 13:22:21 2008
From: vansonsamuel at gmail.com (Vanson Samuel)
Date: Fri, 14 Mar 2008 13:22:21 -0400
Subject: [Backgroundrb-devel] Loading an array of MiddleMen
In-Reply-To: <1205470421.7620.8.camel@shire>
References: <b7ae96dd0803130848w46912467q6ad1cb9e577fc9e8@mail.gmail.com>
	<1205470421.7620.8.camel@shire>
Message-ID: <b7ae96dd0803141022w102ec25ev79cff9277d87b792@mail.gmail.com>

Hi Hemant,
Thanks for the quick reply.  I will create a git-patch and tests for
you today.  Attached is my own version of backgroundrb_environment.rb,
however I suspect that those who need this feature will want to
implement it in their own way. That is why I put it in
config/backgroundrb_environment.rb outside of the the backgroundrb
source tree.

Once this patch has been commit people will be able to create a
backgroundrb_environment.rb file where they can implement code that
will create a their own MiddleMan or MiddleMen array.  If this file
has not been created then a MiddleMan will be loaded based on the
default configuration file..

- Vanson

On Fri, Mar 14, 2008 at 12:53 AM, hemant kumar <gethemant at gmail.com> wrote:
>
>
>  On Thu, 2008-03-13 at 11:48 -0400, Vanson Samuel wrote:
>  > Hi,
>  > I am currently working on a project that requires multiple rails
>  > applications (lets call them consumers, since they will consume
>  > requests) to exposes long running services that will be executed from
>  > a management rails application (the producer of the requests).  To do
>  > this BackgrounDrb was installed on all the consumers and the producer.
>  >  BackgrounDrb was configured to on each of the consumers and the
>  > configuration files were copied over to the producer.  This is where I
>  > run into a problem, there can only be one MiddleMan on the producer.
>  > In version .99 of BackgrounDrb I got over this hurdle by passing in
>  > the configuration file path to BackgrounDrb.initialize.  I would then
>  > instantiate and array of MiddleMen using the modified class.  I want
>  > to do the same thing again for the new version.  Only this time I am
>  > hoping that my changes will be merged into the trunk.  Please see the
>  > attached patch and let me know if this is possible.
>  >
>
>  Yes, that should work. Can you submit your patch with git-format-patch
>  so as I can commit it. You also need to submit some test cases, if you
>  want the patch to in. Also, you are not mentioning whats there in
>  backgroundrb_environment.rb file.
>
>  Just to clarify further, if inside your rails application you need an
>  array of middleman all you need to do is, creating custom middlemen by
>  requiring backgroundrb.rb file and changing ip and port to which it
>  connects. I think, details are pretty bare and should be easily
>  hackable.
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backgroundrb_environment.rb
Type: application/octet-stream
Size: 390 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080314/e635dde2/attachment-0001.obj 

From list at lylo.co.uk  Mon Mar 17 20:05:33 2008
From: list at lylo.co.uk (Olly Lylo)
Date: Tue, 18 Mar 2008 00:05:33 +0000
Subject: [Backgroundrb-devel] Major issues with ActiveRecord callbacks in
	BackgroundRb r324
Message-ID: <f317a9f40803171705h4d2af46dgbb0cb10efb790c2f@mail.gmail.com>

Hi there

I've been running BackgroundRb in production for a few months now.  Recently
we added encryption onto some of our ActiveRecord fields by hooking in the
before_save and after_save callbacks, like:

  class MyCallback
    def initialize(attr_names)
      @attr_names = attr_names
    end

    def before_save(model)
      @attr_names.each do |attr_name|
        next if model.send("#{attr_name}").blank?
        model.send("#{attr_name}=",
Encrypter.encrypt(model.send("#{attr_name}")))

      end
    end

    def after_save(model)
      @attr_names.each do |attr_name|
        next if model.send("#{attr_name}").blank?
        model.send("#{attr_name}=", Encrypter.decrypt(model.send
("#{attr_name}")))
      end
    end
  end

There's a little more to it but that should give you the idea.  Anyway,
whilst this works a treat in our Rails app and when using script/console,
BackgroundRb returns strange results when we try and load a model object
which has an encrypted field.  After some debugging it seems like the
before_save filter is called twice for these objects.  When we access it
using the console, it's only called once as expected.

Is there an obvious reason why adding bespoke callbacks like this might
cause a problem in a BackgroundRb worker?   Failing this, would someone be
able to explain (or point me in the right direction of the class files) how
exactly BackgroundRb hooks into Rails?   This way I can dig into the code to
investigate.

Thanks in advance
Olly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080318/e04b7c5e/attachment.html 

From gobigdave at gmail.com  Tue Mar 18 00:08:13 2008
From: gobigdave at gmail.com (Dave Dupre)
Date: Tue, 18 Mar 2008 00:08:13 -0400
Subject: [Backgroundrb-devel] Polling is REALLY slow
Message-ID: <258cc3f50803172108t3a131527yb3fba53f244f1c5b@mail.gmail.com>

I'm having some trouble with using brb for polling for work. Basically, what
I want to do is update the state of a record and have brb notice and start a
process. I do not want to call ask_work for each process because there may
be several places where the object's state is changed, and I only want to
process once.  Plus, I can schedule things better this way.  My first
thought was to create a worker that polled for records with the correct
state, but it doesn't work as expected.  Here is what I have with error
checking, etc. removed:

class RequestQueuePollerWorker < BackgrounDRb::MetaWorker
  set_worker_name :request_queue_poller_worker

  QUEUE_SLEEP_TIME = 30   # seconds

  def create(args = nil)
    @running = true
    self.poll_queue
  end

  def build_all_matches(args = nil)
    thread_pool.defer(args) do |args|
       requests = Request.find_active(:all)
       requests.each { |request| request.queue! }  # using
acts_as_state_machine
    end
  end

  protected

  # Was hoping to get multiple threads processing
  def build_matches(args = nil)
    thread_pool.defer(args) do |args|
       request = Request.find(args.to_i)
       request.build_matches
    end
  end

  def poll_queue
    Thread.new do
      while @running do
        sleep_time = QUEUE_SLEEP_TIME
        request = nil
        Request.transaction do
          request = Request.find_in_state(:first, :queued, :order => '
requests.updated_at ASC', :lock => true)
          request.search! unless request.nil?  # make sure I don't hit again
        end
        if request
          self.build_matches(request.id)
          sleep_time = 0
          request = nil
        end
        sleep(sleep_time)
      end
    end
  end

  def stop_polling
    @running = false
  end

end

In my test case, there are 20 Request items. Normally, it would take about 5
seconds to call Request.build_matches on 20 Request items.  However, asking
for work like so:

MiddleMan.ask_work(:worker => :request_queue_poller_worker, :worker_method
=> :build_all_matches)

It takes 20 minutes(!) to process the same 20 Request items.  Processing
basically c r a w l s along.  I expected to immediately see all the states
change to :queued, and then very quickly changed to :searching. However, it
doesn't happen that way. Things go to queued pretty quickly, by searching
takes FOREVER. It's like poll_queue and build_matches don't get any CPU
cycles.

Is there a recommended way to do something like this?

Please note, I do not want to use a periodic timer because I don't know how
long handling a message will take. Plus, if there are more items in the
queue, I don't want to wait around to get them. My thought is to generalize
this as a db queue eventually.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080318/67d1a32f/attachment.html 

From Bishnuprasaditpradipta_Das at mindtree.com  Tue Mar 18 10:18:56 2008
From: Bishnuprasaditpradipta_Das at mindtree.com (Bishnuprasaditpradipta Narayan Das)
Date: Tue, 18 Mar 2008 19:48:56 +0530
Subject: [Backgroundrb-devel] regarding problem backgroundrb setup(new to
	ruby on rails)
Message-ID: <260D35C84DA03043BE637BF29AFFC09D01387736@mtw01ex03.mindtree.com>

Hi all
                My problem is that:
                                                   With reference to
http://backgroundrb.rubyforge.org/
  1---I have download backgroundrb from
http://opensvn.csie.org/ezra/rails/backgroundrb 
      to my vendor/plugin in my application folder.
 2--  after that I used the command to run   :-rake  backgroundrb:setup  --
trace 
        From my application folder 
 3:- it shows the error as follows 

    


A:-It shows rake aborted;

B-It do not know how to build task  'backgroundrb:setup'

4: actually I have gem version  1.1.2 .i do not know whether it supports or
not. I am using radrails.and webrick server and for database heidisql.
    I  have rake 0.7.1 & 0.7.1.

Can any body suggest me what should I do ,so that I can deploy scheduler in
my application in a well manner.




DISCLAIMER:
This message (including attachment if any) is confidential and may be privileged. If you have received this message by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorized use or dissemination of this message in whole or in part is strictly prohibited.
E-mail may contain viruses. Before opening attachments please check them for viruses and defects. While MindTree Consulting Limited (MindTree) has put in place checks to minimize the risks, MindTree will not be responsible for any viruses or defects or any forwarded attachments emanating either from within MindTree or outside.
Please note that e-mails are susceptible to change and MindTree shall not be liable for any improper, untimely or incomplete transmission.
MindTree reserves the right to monitor and review the content of all messages sent to or from MindTree e-mail address. Messages sent to or from this e-mail address may be stored on the MindTree e-mail system or else where.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080318/204c647e/attachment.html 

From heisters at greenriver.org  Tue Mar 18 10:50:19 2008
From: heisters at greenriver.org (Ian Smith-Heisters)
Date: Tue, 18 Mar 2008 07:50:19 -0700
Subject: [Backgroundrb-devel] regarding problem backgroundrb setup(new
	to ruby on rails)
In-Reply-To: <260D35C84DA03043BE637BF29AFFC09D01387736@mtw01ex03.mindtree.com>
References: <260D35C84DA03043BE637BF29AFFC09D01387736@mtw01ex03.mindtree.com>
Message-ID: <de819a5b0803180750v73ed04d7va2e72978326b730@mail.gmail.com>

On Tue, Mar 18, 2008 at 7:18 AM, Bishnuprasaditpradipta Narayan Das
<Bishnuprasaditpradipta_Das at mindtree.com> wrote:

<snip>

> B-It do not know how to build task  'backgroundrb:setup'

ok, so it's not installed correctly. Looking at the backgroundrb site,
http://backgroundrb.rubyforge.org, the correct url for svn is
http://svn.devjavu.com/backgroundrb/trunk, so that's probably the
first thing you should fix. It sounds like you're using an older
version, which will be harder for anyone to support since it's
deprecated.

> 4: actually I have gem version  1.1.2 .i do not know whether it supports or
> not. I am using radrails.and webrick server and for database heidisql.

It looks like HeidiSQL is just a frontend to MySQL. I'd recommend
using MySQL directly, since all the tutorials assume you're doing
that, and it'll be easier to get people to help you if you're using
the standard stuff. That being said, use whatever gets the job done,
just don't expect anyone to be able to help with HeidiSQL-specific
problems.

HTH
-ISH

>
>     I  have rake 0.7.1 & 0.7.1.
>
> Can any body suggest me what should I do ,so that I can deploy scheduler in
> my application in a well manner.
>
>
>
>
>
>
>
> DISCLAIMER:
>
> This message (including attachment if any) is confidential and may be
> privileged. If you have received this message by mistake please notify the
> sender by return e-mail and delete this message from your system. Any
> unauthorized use or dissemination of this message in whole or in part is
> strictly prohibited.
>
> E-mail may contain viruses. Before opening attachments please check them for
> viruses and defects. While MindTree Consulting Limited (MindTree) has put in
> place checks to minimize the risks, MindTree will not be responsible for any
> viruses or defects or any forwarded attachments emanating either from within
> MindTree or outside.
>
> Please note that e-mails are susceptible to change and MindTree shall not be
> liable for any improper, untimely or incomplete transmission.
>
> MindTree reserves the right to monitor and review the content of all
> messages sent to or from MindTree e-mail address. Messages sent to or from
> this e-mail address may be stored on the MindTree e-mail system or else
> where.
> _______________________________________________
>  Backgroundrb-devel mailing list
>  Backgroundrb-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

From f.schwach at uea.ac.uk  Wed Mar 19 09:57:03 2008
From: f.schwach at uea.ac.uk (Frank Schwach)
Date: Wed, 19 Mar 2008 13:57:03 +0000
Subject: [Backgroundrb-devel] problem with worker status
Message-ID: <1205935023.17162.85.camel@fschwachbiopc.bio.uea.ac.uk>

Hi,

I have a page were users can start jobs that may take several hours to
run. BackgrounDrb is perfect for me and seems to be working well most of
the time but some times I have the following problem:

My worker is set up like this:

class UploadWorker < BackgrounDRb::MetaWorker
  set_worker_name :upload_worker
  set_no_auto_load(true)

  def create(args = nil )
    file = args[:file]
    sample_id = args[:sample_id]
    @user_id = args[:user_id]
    @submission_time = Time.now
       
    percent_complete = 0
    total_count = get_total_count(file)
    register_status(:percent_complete => percent_complete, :total =>
total_count)

<<< some long running task >>>
    exit
  end
end

Now when I fire up the backroundrb server and a rails console
and ask for a new worker like this:

>> jk = MiddleMan.new_worker(:worker => :upload_worker, :job_key =>
"123", :data => data)

(where data = {:file => some_file} )

most of the time I get the jobkey returned and the job works and I can
ask the status with
>> MiddleMan.ask_status(:worker => :upload_worker, :job_key => "123")

But sometimes I get the jobkey returned from the initial request but the
worker seems to fail to register its status. In some cases the job is
actually running though but not always. I don't understand what could be
causing this. Has anybody else experienced something like that?
The failures seem to be completely random to me.


From Ivan.Manida at Sun.COM  Wed Mar 19 11:37:12 2008
From: Ivan.Manida at Sun.COM (Ivan S. Manida)
Date: Wed, 19 Mar 2008 18:37:12 +0300
Subject: [Backgroundrb-devel] problem with worker status
In-Reply-To: <1205935023.17162.85.camel@fschwachbiopc.bio.uea.ac.uk>
References: <1205935023.17162.85.camel@fschwachbiopc.bio.uea.ac.uk>
Message-ID: <47E13328.4050004@Sun.COM>

Have you tried checking logs? Could be that your worker just hangs 
at some code in some cases? Sounds like it. I have similar setup, 
same calls, 10-30 minute running workers, no problems.

While debugging I did insert logger.info at various critical places 
inside the worker to track what it's doing, this helps understand if 
it fails prematurely.

Frank Schwach wrote:
> Hi,
> 
> I have a page were users can start jobs that may take several hours to
> run. BackgrounDrb is perfect for me and seems to be working well most of
> the time but some times I have the following problem:
> 
> My worker is set up like this:
> 
> class UploadWorker < BackgrounDRb::MetaWorker
>   set_worker_name :upload_worker
>   set_no_auto_load(true)
> 
>   def create(args = nil )
>     file = args[:file]
>     sample_id = args[:sample_id]
>     @user_id = args[:user_id]
>     @submission_time = Time.now
>        
>     percent_complete = 0
>     total_count = get_total_count(file)
>     register_status(:percent_complete => percent_complete, :total =>
> total_count)
> 
> <<< some long running task >>>
>     exit
>   end
> end
> 
> Now when I fire up the backroundrb server and a rails console
> and ask for a new worker like this:
> 
>>> jk = MiddleMan.new_worker(:worker => :upload_worker, :job_key =>
> "123", :data => data)
> 
> (where data = {:file => some_file} )
> 
> most of the time I get the jobkey returned and the job works and I can
> ask the status with
>>> MiddleMan.ask_status(:worker => :upload_worker, :job_key => "123")
> 
> But sometimes I get the jobkey returned from the initial request but the
> worker seems to fail to register its status. In some cases the job is
> actually running though but not always. I don't understand what could be
> causing this. Has anybody else experienced something like that?
> The failures seem to be completely random to me.
> 
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

From heisters at greenriver.org  Wed Mar 19 19:02:51 2008
From: heisters at greenriver.org (Ian Smith-Heisters)
Date: Wed, 19 Mar 2008 16:02:51 -0700
Subject: [Backgroundrb-devel] nil-error
Message-ID: <de819a5b0803191602p2764d544j5aa0719556dcacad@mail.gmail.com>

Hi all,

I've got the error below in my backgroundrb_debug.log. I've tried to
reproduce the error in the development environment, but the only way I
can get the same thing is by calling ask_work with a bogus worker
name. Calling it with the production code causes no error.

Here's an example of what the code calls:

MiddleMan.ask_work(:worker => :agronomy_worker, :worker_method =>
:transmit, :data => 414)

I also tried playing with adding a job_key, but that didn't seem to
change anything. Should I be providing a job_key and ensuring that
it's unique? I've no need to reference the job in progress, so I'm
fine with the default key, unless of course it's likely to be
non-unique and cause a bug.

Anyone have an idea on what could be causing this? I'm running svn revision 314.

Thanks,
Ian

--- backgroundrb_debug.log ---
Client disconected
000000079^D^H{  :       type:^Ldo_work:^Kworker:^Tagronomy_worker:
 datai^B<9E>^A:^Rworker_method:^Mtransmit
typedo_workdata414workeragronomy_workerworker_methodtransmit
undefined method `send_request' for nil:NilClass
/vendor/plugins/backgroundrb/framework/packet/packet_master.rb:43:in
`ask_worker'
/vendor/plugins/backgroundrb/server/master_worker.rb:105:in `process_work'
/vendor/plugins/backgroundrb/server/master_worker.rb:37:in `receive_data'
/vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in `call'
/vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in
`extract'
/vendor/plugins/backgroundrb/server/master_worker.rb:33:in `receive_data'
/vendor/plugins/backgroundrb/framework/packet/core.rb:199:in
`read_external_socket'
/vendor/plugins/backgroundrb/framework/packet/core.rb:191:in
`handle_external_messages'
/vendor/plugins/backgroundrb/framework/packet/core.rb:160:in `start_reactor'
/vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `each'
/vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `start_reactor'
/vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `loop'
/vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `start_reactor'
/vendor/plugins/backgroundrb/framework/packet/packet_master.rb:20:in `run'
/vendor/plugins/backgroundrb/server/master_worker.rb:163:in `initialize'
/script/backgroundrb:42:in `new'
/script/backgroundrb:42

From heisters at greenriver.org  Wed Mar 19 19:03:54 2008
From: heisters at greenriver.org (Ian Smith-Heisters)
Date: Wed, 19 Mar 2008 16:03:54 -0700
Subject: [Backgroundrb-devel] email on error
In-Reply-To: <a4855ac50803061351h5e0f2103l5033e9b909af1420@mail.gmail.com>
References: <de819a5b0803061230n6068865td665e9aebaec5fdd@mail.gmail.com>
	<a4855ac50803061351h5e0f2103l5033e9b909af1420@mail.gmail.com>
Message-ID: <de819a5b0803191603ndf67860yacf05c07515715c8@mail.gmail.com>

On Thu, Mar 6, 2008 at 2:51 PM, Ryan Leavengood <leavengood at gmail.com> wrote:
>
> On Thu, Mar 6, 2008 at 3:30 PM, Ian Smith-Heisters
>  <heisters at greenriver.org> wrote:
>  >
>  >  I'm trying to figure out how to use exception_notification to alert me
>  >  of any error in bdrb. I'm not quite sure how bdrb handles errors,
>  >  though. It seems like implementing ExceptionNotifiable in my worker
>  >  class would catch any worker errors (maybe). But what if bdrb fails
>  >  before it loads the worker, or there some other internal bdrb error?
>  >  It seems to catch everything and put it in backgroundrb_debug.log, is
>  >  it possible to exploit whatever hook that uses?
>  >
>  >  I'll play around with it and RTFS, but I was just hoping someone might
>  >  have some prior experience with this.
>
>  I wanted something like this too and what I did was add some methods
>  to BackgrounDRb::MetaWorker like so:
>
>  class BackgrounDRb::MetaWorker
>   def handle_exceptions
>     result = nil
>
>     if block_given?
>       begin
>         result = yield
>       rescue Exception => e
>         log_error(e)
>       end
>     end
>
>     result
>   end
>
>   def log_error(error)
>     case error
>     when Exception
>       class_name = self.class.name
>       logger.info("Had exception #{error.class} in #{class_name},
>  sending email.")
>       NotifyMailer.deliver_error_notification(error, class_name)
>     else
>       logger.info(error.to_s)
>     end
>   end
>  end
>
>  I put the above in a file in lib. I require it in my workers and then
>  call handle_exceptions with a block inside my worker methods. This
>  definitely works, though I don't know if it is the ideal way to do it.
>  For one thing it won't catch errors at the level of BackgrounDRb
>  itself. But at least for worker errors it is fine. Also as you can see
>  I defined my own error mailer that is very similar to the one from the
>  ExceptionNotifier plug-in.
>
>  It might be nice for BackgrounDRb to support something like this
>  itself. Maybe one of us could put together a patch.
>
>  Also I use the above with the last released version of BackgrounDRb, I
>  haven't yet upgraded. Though it will probably also work with the new
>  version.
>
>  Ryan
>

Cool, thanks, this is really helpful. I'll post back with my finding
if I can ever get around to implementing something like this in my own
app.

From gethemant at gmail.com  Thu Mar 20 04:41:44 2008
From: gethemant at gmail.com (hemant)
Date: Thu, 20 Mar 2008 14:11:44 +0530
Subject: [Backgroundrb-devel] Polling is REALLY slow
In-Reply-To: <258cc3f50803172108t3a131527yb3fba53f244f1c5b@mail.gmail.com>
References: <258cc3f50803172108t3a131527yb3fba53f244f1c5b@mail.gmail.com>
Message-ID: <fb283d5e0803200141h6064d57fq90ec3df433a0a780@mail.gmail.com>

On Tue, Mar 18, 2008 at 9:38 AM, Dave Dupre <gobigdave at gmail.com> wrote:
> I'm having some trouble with using brb for polling for work. Basically, what
> I want to do is update the state of a record and have brb notice and start a
> process. I do not want to call ask_work for each process because there may
> be several places where the object's state is changed, and I only want to
> process once.  Plus, I can schedule things better this way.  My first
> thought was to create a worker that polled for records with the correct
> state, but it doesn't work as expected.  Here is what I have with error
> checking, etc. removed:
>
> class RequestQueuePollerWorker < BackgrounDRb::MetaWorker
>   set_worker_name :request_queue_poller_worker
>
>   QUEUE_SLEEP_TIME = 30   # seconds
>
>   def create(args = nil)
>     @running = true
>     self.poll_queue
>    end
>
>   def build_all_matches(args = nil)
>     thread_pool.defer(args) do |args|
>        requests = Request.find_active(:all)
>        requests.each { |request| request.queue! }  # using
> acts_as_state_machine
>      end
>   end
>
>   protected
>
>   # Was hoping to get multiple threads processing
>   def build_matches(args = nil)
>     thread_pool.defer(args) do |args|
>        request = Request.find(args.to_i)
>        request.build_matches
>      end
>   end
>
>   def poll_queue
>     Thread.new do
>       while @running do
>         sleep_time = QUEUE_SLEEP_TIME
>         request = nil
>         Request.transaction do
>           request = Request.find_in_state(:first, :queued, :order =>
> 'requests.updated_at ASC', :lock => true)
>            request.search! unless request.nil?  # make sure I don't hit
> again
>         end
>         if request
>           self.build_matches(request.id)
>           sleep_time = 0
>            request = nil
>         end
>         sleep(sleep_time)
>       end
>     end
>   end
>
>   def stop_polling
>     @running = false
>   end
>
> end
>
> In my test case, there are 20 Request items. Normally, it would take about 5
> seconds to call Request.build_matches on 20 Request items.  However, asking
> for work like so:
>
> MiddleMan.ask_work(:worker => :request_queue_poller_worker, :worker_method
> => :build_all_matches)
>
> It takes 20 minutes(!) to process the same 20 Request items.  Processing
> basically c r a w l s along.  I expected to immediately see all the states
> change to :queued, and then very quickly changed to :searching. However, it
> doesn't happen that way. Things go to queued pretty quickly, by searching
> takes FOREVER. It's like poll_queue and build_matches don't get any CPU
> cycles.
>
> Is there a recommended way to do something like this?
>
> Please note, I do not want to use a periodic timer because I don't know how
> long handling a message will take. Plus, if there are more items in the
> queue, I don't want to wait around to get them. My thought is to generalize
> this as a db queue eventually.
>

You should never put sleep anywhere in your worker code. Mainly
because all the workers are reactive in nature and putting sleep
anywhere may block main reactor loop. If you want certain action to be
executed like a polling method, you should investigate next_turn
method, which will invoke specified block on each turn of reactor loop
inside worker.

Remove the sleep and look into next_turn and see how are your results.
Also, sorry for my late reply, since I am stuck in a village almost
without internet and electricity.




-- 
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 gethemant at gmail.com  Thu Mar 20 04:45:09 2008
From: gethemant at gmail.com (hemant)
Date: Thu, 20 Mar 2008 14:15:09 +0530
Subject: [Backgroundrb-devel] problem with worker status
In-Reply-To: <47E13328.4050004@Sun.COM>
References: <1205935023.17162.85.camel@fschwachbiopc.bio.uea.ac.uk>
	<47E13328.4050004@Sun.COM>
Message-ID: <fb283d5e0803200145o4b8e91bx20a466e2ba74d3a6@mail.gmail.com>

Also, ensure that you are running latest code from git ( i am not
sure, if svn trunk has the fix). This bug was reported on the list and
I have it fixed on git trunk repository.


On Wed, Mar 19, 2008 at 9:07 PM, Ivan S. Manida <Ivan.Manida at sun.com> wrote:
> Have you tried checking logs? Could be that your worker just hangs
>  at some code in some cases? Sounds like it. I have similar setup,
>  same calls, 10-30 minute running workers, no problems.
>
>  While debugging I did insert logger.info at various critical places
>  inside the worker to track what it's doing, this helps understand if
>  it fails prematurely.
>
>
>
>  Frank Schwach wrote:
>  > Hi,
>  >
>  > I have a page were users can start jobs that may take several hours to
>  > run. BackgrounDrb is perfect for me and seems to be working well most of
>  > the time but some times I have the following problem:
>  >
>  > My worker is set up like this:
>  >
>  > class UploadWorker < BackgrounDRb::MetaWorker
>  >   set_worker_name :upload_worker
>  >   set_no_auto_load(true)
>  >
>  >   def create(args = nil )
>  >     file = args[:file]
>  >     sample_id = args[:sample_id]
>  >     @user_id = args[:user_id]
>  >     @submission_time = Time.now
>  >
>  >     percent_complete = 0
>  >     total_count = get_total_count(file)
>  >     register_status(:percent_complete => percent_complete, :total =>
>  > total_count)
>  >
>  > <<< some long running task >>>
>  >     exit
>  >   end
>  > end
>  >
>  > Now when I fire up the backroundrb server and a rails console
>  > and ask for a new worker like this:
>  >
>  >>> jk = MiddleMan.new_worker(:worker => :upload_worker, :job_key =>
>  > "123", :data => data)
>  >
>  > (where data = {:file => some_file} )
>  >
>  > most of the time I get the jobkey returned and the job works and I can
>  > ask the status with
>  >>> MiddleMan.ask_status(:worker => :upload_worker, :job_key => "123")
>  >
>  > But sometimes I get the jobkey returned from the initial request but the
>  > worker seems to fail to register its status. In some cases the job is
>  > actually running though but not always. I don't understand what could be
>  > causing this. Has anybody else experienced something like that?
>  > The failures seem to be completely random to me.
>  >
>  > _______________________________________________
>  > 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
>



-- 
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 gethemant at gmail.com  Thu Mar 20 04:49:21 2008
From: gethemant at gmail.com (hemant)
Date: Thu, 20 Mar 2008 14:19:21 +0530
Subject: [Backgroundrb-devel] nil-error
In-Reply-To: <de819a5b0803191602p2764d544j5aa0719556dcacad@mail.gmail.com>
References: <de819a5b0803191602p2764d544j5aa0719556dcacad@mail.gmail.com>
Message-ID: <fb283d5e0803200149m3bd959d8v7217b1cffce6868f@mail.gmail.com>

You need a job_key only when you have started your worker with a
job_key using new_worker method. Otherwise, you don't need any
job_keys at all.

Also, upgrade to latest svn trunk and see if your problem goes away.
There will be an error if you invoke ask_work on a bogus worker and I
thought that behavior is correct.

On Thu, Mar 20, 2008 at 4:32 AM, Ian Smith-Heisters
<heisters at greenriver.org> wrote:
> Hi all,
>
>  I've got the error below in my backgroundrb_debug.log. I've tried to
>  reproduce the error in the development environment, but the only way I
>  can get the same thing is by calling ask_work with a bogus worker
>  name. Calling it with the production code causes no error.
>
>  Here's an example of what the code calls:
>
>  MiddleMan.ask_work(:worker => :agronomy_worker, :worker_method =>
>  :transmit, :data => 414)
>
>  I also tried playing with adding a job_key, but that didn't seem to
>  change anything. Should I be providing a job_key and ensuring that
>  it's unique? I've no need to reference the job in progress, so I'm
>  fine with the default key, unless of course it's likely to be
>  non-unique and cause a bug.
>
>  Anyone have an idea on what could be causing this? I'm running svn revision 314.
>
>  Thanks,
>  Ian
>
>  --- backgroundrb_debug.log ---
>  Client disconected
>  000000079^D^H{  :       type:^Ldo_work:^Kworker:^Tagronomy_worker:
>   datai^B<9E>^A:^Rworker_method:^Mtransmit
>  typedo_workdata414workeragronomy_workerworker_methodtransmit
>  undefined method `send_request' for nil:NilClass
>  /vendor/plugins/backgroundrb/framework/packet/packet_master.rb:43:in
>  `ask_worker'
>  /vendor/plugins/backgroundrb/server/master_worker.rb:105:in `process_work'
>  /vendor/plugins/backgroundrb/server/master_worker.rb:37:in `receive_data'
>  /vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in `call'
>  /vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in
>  `extract'
>  /vendor/plugins/backgroundrb/server/master_worker.rb:33:in `receive_data'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:199:in
>  `read_external_socket'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:191:in
>  `handle_external_messages'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:160:in `start_reactor'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `each'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `start_reactor'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `loop'
>  /vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `start_reactor'
>  /vendor/plugins/backgroundrb/framework/packet/packet_master.rb:20:in `run'
>  /vendor/plugins/backgroundrb/server/master_worker.rb:163:in `initialize'
>  /script/backgroundrb:42:in `new'
>  /script/backgroundrb:42
>  _______________________________________________
>  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 heisters at greenriver.org  Thu Mar 20 17:02:54 2008
From: heisters at greenriver.org (Ian Smith-Heisters)
Date: Thu, 20 Mar 2008 14:02:54 -0700
Subject: [Backgroundrb-devel] nil-error
In-Reply-To: <fb283d5e0803200149m3bd959d8v7217b1cffce6868f@mail.gmail.com>
References: <de819a5b0803191602p2764d544j5aa0719556dcacad@mail.gmail.com>
	<fb283d5e0803200149m3bd959d8v7217b1cffce6868f@mail.gmail.com>
Message-ID: <de819a5b0803201402r2043d165j1e7905e0e367051a@mail.gmail.com>

Thanks hemant. Unfortunately upgrading to HEAD doesn't seem to have
changed any of the behaviors I observed. I'm still getting this error
when I fire off a work request. Any ideas what else I can look at?

==> backgroundrb_debug.log <==
000000079{      :       type:
                             do_work:   dataiO
:

worker:agronomy_worker:workertransmit
typedo_workworkeragronomy_workerdata335worker_methodtransmit
undefined method `send_request' for nil:NilClass
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/packet_master.rb:43:in
`ask_worker'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/server/master_worker.rb:105:in
`process_work'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/server/master_worker.rb:37:in
`receive_data'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in
`call'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in
`extract'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/server/master_worker.rb:33:in
`receive_data'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:199:in
`read_external_socket'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:191:in
`handle_external_messages'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:160:in
`start_reactor'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
`each'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:156:in
`start_reactor'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
`loop'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/core.rb:147:in
`start_reactor'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/framework/packet/packet_master.rb:20:in
`run'
/var/www/star-cafe-production/releases/20080318150454/vendor/plugins/backgroundrb/server/master_worker.rb:163:in
`initialize'
/var/www/star-cafe-production/releases/20080318150454/script/backgroundrb:42:in
`new'
/var/www/star-cafe-production/releases/20080318150454/script/backgroundrb:42



On Thu, Mar 20, 2008 at 1:49 AM, hemant <gethemant at gmail.com> wrote:
> You need a job_key only when you have started your worker with a
>  job_key using new_worker method. Otherwise, you don't need any
>  job_keys at all.
>
>  Also, upgrade to latest svn trunk and see if your problem goes away.
>  There will be an error if you invoke ask_work on a bogus worker and I
>  thought that behavior is correct.
>
>
>
>  On Thu, Mar 20, 2008 at 4:32 AM, Ian Smith-Heisters
>  <heisters at greenriver.org> wrote:
>  > Hi all,
>  >
>  >  I've got the error below in my backgroundrb_debug.log. I've tried to
>  >  reproduce the error in the development environment, but the only way I
>  >  can get the same thing is by calling ask_work with a bogus worker
>  >  name. Calling it with the production code causes no error.
>  >
>  >  Here's an example of what the code calls:
>  >
>  >  MiddleMan.ask_work(:worker => :agronomy_worker, :worker_method =>
>  >  :transmit, :data => 414)
>  >
>  >  I also tried playing with adding a job_key, but that didn't seem to
>  >  change anything. Should I be providing a job_key and ensuring that
>  >  it's unique? I've no need to reference the job in progress, so I'm
>  >  fine with the default key, unless of course it's likely to be
>  >  non-unique and cause a bug.
>  >
>  >  Anyone have an idea on what could be causing this? I'm running svn revision 314.
>  >
>  >  Thanks,
>  >  Ian
>  >
>  >  --- backgroundrb_debug.log ---
>  >  Client disconected
>  >  000000079^D^H{  :       type:^Ldo_work:^Kworker:^Tagronomy_worker:
>  >   datai^B<9E>^A:^Rworker_method:^Mtransmit
>  >  typedo_workdata414workeragronomy_workerworker_methodtransmit
>  >  undefined method `send_request' for nil:NilClass
>  >  /vendor/plugins/backgroundrb/framework/packet/packet_master.rb:43:in
>  >  `ask_worker'
>  >  /vendor/plugins/backgroundrb/server/master_worker.rb:105:in `process_work'
>  >  /vendor/plugins/backgroundrb/server/master_worker.rb:37:in `receive_data'
>  >  /vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in `call'
>  >  /vendor/plugins/backgroundrb/lib/../framework/packet/bin_parser.rb:29:in
>  >  `extract'
>  >  /vendor/plugins/backgroundrb/server/master_worker.rb:33:in `receive_data'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:199:in
>  >  `read_external_socket'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:191:in
>  >  `handle_external_messages'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:160:in `start_reactor'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `each'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:156:in `start_reactor'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `loop'
>  >  /vendor/plugins/backgroundrb/framework/packet/core.rb:147:in `start_reactor'
>  >  /vendor/plugins/backgroundrb/framework/packet/packet_master.rb:20:in `run'
>  >  /vendor/plugins/backgroundrb/server/master_worker.rb:163:in `initialize'
>  >  /script/backgroundrb:42:in `new'
>  >  /script/backgroundrb:42
>  >  _______________________________________________
>  >  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 sweiss at stylesight.com  Thu Mar 20 21:07:39 2008
From: sweiss at stylesight.com (Stephen Weiss)
Date: Thu, 20 Mar 2008 21:07:39 -0400
Subject: [Backgroundrb-devel] can't call any methods on workers
Message-ID: <DEF7B732-7849-40F4-A9C5-B7DBA6F7AF79@stylesight.com>

[ sorry if this went out twice, sent once but it didn't seem to go  
through ]

Hi,

I'm a long time backgroundrb user, still stuck using the very ancient  
original version from Ezra (not even Ezra's 2.0 version, I'm using the  
one that didn't really have a version number).  The 2.0 version did  
very little but crash for me.  Anyway I finally got some time set  
aside to try out this new version you all have been developing.  I'm  
very excited about the new all_worker_info method on MiddleMan!  It  
should drastically improve the way my users can manage their  
background processes.

Unfortunately, I can't seem to get even the most basic worker to do  
anything.  I followed all the instructions for installation, and  
installed from SVN (I'm on OS X Tiger, it doesn't appear that there's  
a very good port for git out there without installing a package  
manager, which tend to screw up the rest of my computer).  I deleted  
my script/backgroundrb directory, and the old backgroundrb out of  
vendor plugins.  I checked out the SVN source and moved it into / 
vendor/plugins.  I installed all the appropriate gems (and my packet  
version is 0.1.5).

The server starts fine with this config:

:backgroundrb:
  :port: 11006 # port to start listen
  :ip: 0.0.0.0 # host to listen
  :environment: development # rails environment to load
  :log: foreground # foreground mode,print log messages on console

And I can start my test worker.  However, whenever I call any method  
on my test_worker, I get this error in backgroundrb_11006_debug.log:
00000004{:worker_method:process_batch:	type:
                                                                             do_work
worker_methodprocess_batchtypedo_work
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.send_request
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:44:in `ask_worker'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:104:in `process_work'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:35:in `receive_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:29:in `call'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:29:in `extract'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:212:in `read_external_socket'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:204:in `handle_external_messages'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:178:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `each'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:130:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `loop'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:21:in `run'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:166:in `initialize'
script/backgroundrb:42:in `new'
script/backgroundrb:42

It doesn't matter what's in the method, it could be empty and it still  
doesn't run (I am restarting backgroundrb after each modification - is  
this still necessary?).

Here's my test worker:

class BatchMakerWorker < BackgrounDRb::MetaWorker
  set_worker_name :batch_maker_worker
  def create(args = nil)
    # this method is called, when worker is loaded for the first time
  end

  def process_batch

  end
end


The rails code I'm using to test the worker looks like this:

    job_key = MiddleMan.new_worker(:class => :batch_maker_worker)
    worker = MiddleMan.worker(job_key)
    worker.process_batch

Anyway, the only thing I could find on the error out there was this (http://pastie.caboo.se/pastes/167509 
), which someone posted yesterday.  This leads me to believe some bug  
got put on the SVN very recently, and at least one other person's in  
the same boat.

If anyone has a version that does work, or if anyone knows what wrong  
gem I'm using or what I'm doing wrong in general, I'd really  
appreciate it.  I only have a week or so I can devote to this before  
my boss puts me onto something else, and I'd *really* like to upgrade  
to something that's not twice-deprecated.

Machine runs OS X (client) 10.4.11, ruby 1.8.5

Thanks everyone!   Sorry about the super long e-mail...

--
Steve

From sweiss at stylesight.com  Thu Mar 20 15:06:12 2008
From: sweiss at stylesight.com (Stephen Weiss)
Date: Thu, 20 Mar 2008 15:06:12 -0400
Subject: [Backgroundrb-devel] can't call any methods on workers
Message-ID: <E7DA747F-78CE-49AD-94A7-AA9E5837A760@stylesight.com>

Hi,

I'm a long time backgroundrb user, still stuck using the very ancient  
original version from Ezra (not even Ezra's 2.0 version, I'm using the  
one that didn't really have a version number).  The 2.0 version did  
very little but crash for me.  Anyway I finally got some time set  
aside to try out this new version you all have been developing.  I'm  
very excited about the new all_worker_info method on MiddleMan!  It  
should drastically improve the way my users can manage their  
background processes.

Unfortunately, I can't seem to get even the most basic worker to do  
anything.  I followed all the instructions for installation, and  
installed from SVN (I'm on OS X Tiger, it doesn't appear that there's  
a very good port for git out there without installing a package  
manager, which tend to screw up the rest of my computer).  I deleted  
my script/backgroundrb directory, and the old backgroundrb out of  
vendor plugins.  I checked out the SVN source and moved it into / 
vendor/plugins.  I installed all the appropriate gems (and my packet  
version is 0.1.5).

The server starts fine with this config:

:backgroundrb:
   :port: 11006 # port to start listen
   :ip: 0.0.0.0 # host to listen
   :environment: development # rails environment to load
   :log: foreground # foreground mode,print log messages on console

And I can start my test worker.  However, whenever I call any method  
on my test_worker, I get this error in backgroundrb_11006_debug.log:
00000004{:worker_method:process_batch:	type:
                                                                              do_work
worker_methodprocess_batchtypedo_work
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.send_request
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:44:in `ask_worker'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:104:in `process_work'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:35:in `receive_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:29:in `call'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_parser.rb:29:in `extract'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:212:in `read_external_socket'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:204:in `handle_external_messages'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:178:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `each'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:174:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:130:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `loop'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_core.rb:124:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/ 
packet_master.rb:21:in `run'
/Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/ 
backgroundrb/server/lib/master_worker.rb:166:in `initialize'
script/backgroundrb:42:in `new'
script/backgroundrb:42

It doesn't matter what's in the method, it could be empty and it still  
doesn't run (I am restarting backgroundrb after each modification - is  
this still necessary?).

Here's my test worker:

class BatchMakerWorker < BackgrounDRb::MetaWorker
   set_worker_name :batch_maker_worker
   def create(args = nil)
     # this method is called, when worker is loaded for the first time
   end

   def process_batch

   end
end


The rails code I'm using to test the worker looks like this:

     job_key = MiddleMan.new_worker(:class => :batch_maker_worker)
     worker = MiddleMan.worker(job_key)
     worker.process_batch

Anyway, the only thing I could find on the error out there was this (http://pastie.caboo.se/pastes/167509 
), which someone posted yesterday.  This leads me to believe some bug  
got put on the SVN very recently, and at least one other person's in  
the same boat.

If anyone has a version that does work, or if anyone knows what wrong  
gem I'm using or what I'm doing wrong in general, I'd really  
appreciate it.  I only have a week or so I can devote to this before  
my boss puts me onto something else, and I'd *really* like to upgrade  
to something that's not twice-deprecated.

Machine runs OS X (client) 10.4.11, ruby 1.8.5

Thanks everyone!   Sorry about the super long e-mail...

--
Steve

From gethemant at gmail.com  Fri Mar 21 07:33:20 2008
From: gethemant at gmail.com (hemant)
Date: Fri, 21 Mar 2008 17:03:20 +0530
Subject: [Backgroundrb-devel] can't call any methods on workers
In-Reply-To: <E7DA747F-78CE-49AD-94A7-AA9E5837A760@stylesight.com>
References: <E7DA747F-78CE-49AD-94A7-AA9E5837A760@stylesight.com>
Message-ID: <fb283d5e0803210433i5eafe1fdx3315860cae52fac2@mail.gmail.com>

On Fri, Mar 21, 2008 at 12:36 AM, Stephen Weiss <sweiss at stylesight.com> wrote:
>
> Hi,
>
>  I'm a long time backgroundrb user, still stuck using the very ancient
>  original version from Ezra (not even Ezra's 2.0 version, I'm using the
>  one that didn't really have a version number).  The 2.0 version did
>  very little but crash for me.  Anyway I finally got some time set
>  aside to try out this new version you all have been developing.  I'm
>  very excited about the new all_worker_info method on MiddleMan!  It
>  should drastically improve the way my users can manage their
>  background processes.
>
>  Unfortunately, I can't seem to get even the most basic worker to do
>  anything.  I followed all the instructions for installation, and
>  installed from SVN (I'm on OS X Tiger, it doesn't appear that there's
>  a very good port for git out there without installing a package
>  manager, which tend to screw up the rest of my computer).  I deleted
>  my script/backgroundrb directory, and the old backgroundrb out of
>  vendor plugins.  I checked out the SVN source and moved it into /
>  vendor/plugins.  I installed all the appropriate gems (and my packet
>  version is 0.1.5).
>
>  The server starts fine with this config:
>
>  :backgroundrb:
>    :port: 11006 # port to start listen
>    :ip: 0.0.0.0 # host to listen
>    :environment: development # rails environment to load
>    :log: foreground # foreground mode,print log messages on console
>
>  And I can start my test worker.  However, whenever I call any method
>  on my test_worker, I get this error in backgroundrb_11006_debug.log:
>  00000004{:worker_method:process_batch:  type:
>                                                                               do_work
>  worker_methodprocess_batchtypedo_work
>  You have a nil object when you didn't expect it!
>  The error occurred while evaluating nil.send_request
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_master.rb:44:in `ask_worker'
>  /Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/
>  backgroundrb/server/lib/master_worker.rb:104:in `process_work'
>  /Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/
>  backgroundrb/server/lib/master_worker.rb:35:in `receive_data'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_parser.rb:29:in `call'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_parser.rb:29:in `extract'
>  /Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/
>  backgroundrb/server/lib/master_worker.rb:31:in `receive_data'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:212:in `read_external_socket'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:204:in `handle_external_messages'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:178:in `handle_read_event'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:174:in `each'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:174:in `handle_read_event'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:130:in `start_reactor'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:124:in `loop'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_core.rb:124:in `start_reactor'
>  /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/
>  packet_master.rb:21:in `run'
>  /Users/sweiss/Documents/workspace/RACE-local/vendor/plugins/
>  backgroundrb/server/lib/master_worker.rb:166:in `initialize'
>  script/backgroundrb:42:in `new'
>  script/backgroundrb:42
>
>  It doesn't matter what's in the method, it could be empty and it still
>  doesn't run (I am restarting backgroundrb after each modification - is
>  this still necessary?).
>
>  Here's my test worker:
>
>  class BatchMakerWorker < BackgrounDRb::MetaWorker
>    set_worker_name :batch_maker_worker
>    def create(args = nil)
>      # this method is called, when worker is loaded for the first time
>    end
>
>    def process_batch
>
>    end
>  end

Worker code is ok.

>
>
>  The rails code I'm using to test the worker looks like this:
>
>      job_key = MiddleMan.new_worker(:class => :batch_maker_worker)
>      worker = MiddleMan.worker(job_key)
>      worker.process_batch
>
>  Anyway, the only thing I could find on the error out there was this (http://pastie.caboo.se/pastes/167509
>  ), which someone posted yesterday.  This leads me to believe some bug
>  got put on the SVN very recently, and at least one other person's in
>  the same boat.

Okay, above way of interacting with workers is totally wrong. Correct code is:

job_key = MiddleMan.new_worker(:worker => :batch_maker_worker,:job_key
=> "some_unique")
worker  = MiddleMan.worker(:batch_maker_worker,job_key)
worker.process_batch

Couple of things have changed since old version of bdrb, and new docs
can be found here:

http://backgroundrb.rubyforge.org/rails/index.html


>
>  If anyone has a version that does work, or if anyone knows what wrong
>  gem I'm using or what I'm doing wrong in general, I'd really
>  appreciate it.  I only have a week or so I can devote to this before
>  my boss puts me onto something else, and I'd *really* like to upgrade
>  to something that's not twice-deprecated.
>
>  Machine runs OS X (client) 10.4.11, ruby 1.8.5
>
>  Thanks everyone!   Sorry about the super long e-mail...
>
>  --
>  Steve
>  _______________________________________________
>  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 primdahl at mac.com  Fri Mar 21 14:04:50 2008
From: primdahl at mac.com (Morten Primdahl)
Date: Fri, 21 Mar 2008 19:04:50 +0100
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
Message-ID: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>


Hi, pardon if this is a duplicate mail, I forgot to click the  
subscription link the first time around.

I've been using backgroundrb for a while now (older version) and I've  
had so many headaches because of it that I began looking for a  
replacement technology. And then I saw the new and shiny backgroundrb  
website, looking good!

Initially I used the version maintained by skaar, but had some long  
forgotten issues. On Ezras recommendation, I changed to the latest  
version he did (a downgrade so to speak), and this has been okay, but  
we see some connectivity issues with that once it's been running for a  
while, eg. druby://10.1.65.87:22222 - #<Errno::ECONNREFUSED:  
Connection refused - connect(2)>

So, I'm here to ask, what's the state of backgroundrb 1.0.3? How much  
has changed since Herman took over? Is it ready for production and  
rock solid? Or should I go look for something else?

Thanks,

Morten



From epugh at opensourceconnections.com  Fri Mar 21 16:10:40 2008
From: epugh at opensourceconnections.com (Eric Pugh)
Date: Fri, 21 Mar 2008 16:10:40 -0400
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
In-Reply-To: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>
References: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>
Message-ID: <4857C0DF-4E68-454F-957D-EA764D065DC8@opensourceconnections.com>

In my experience, I have found the 1.0.3 version more stable then the  
older one..  Admittedly I am not running lots of workloads through it,  
but it has been easier to setup and to code against...

Eric

On Mar 21, 2008, at 2:04 PM, Morten Primdahl wrote:

>
> Hi, pardon if this is a duplicate mail, I forgot to click the
> subscription link the first time around.
>
> I've been using backgroundrb for a while now (older version) and I've
> had so many headaches because of it that I began looking for a
> replacement technology. And then I saw the new and shiny backgroundrb
> website, looking good!
>
> Initially I used the version maintained by skaar, but had some long
> forgotten issues. On Ezras recommendation, I changed to the latest
> version he did (a downgrade so to speak), and this has been okay, but
> we see some connectivity issues with that once it's been running for a
> while, eg. druby://10.1.65.87:22222 - #<Errno::ECONNREFUSED:
> Connection refused - connect(2)>
>
> So, I'm here to ask, what's the state of backgroundrb 1.0.3? How much
> has changed since Herman took over? Is it ready for production and
> rock solid? Or should I go look for something else?
>
> Thanks,
>
> Morten
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

-----------------------------------------------------
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com




From kitplummer at gmail.com  Fri Mar 21 16:28:05 2008
From: kitplummer at gmail.com (Kit Plummer)
Date: Fri, 21 Mar 2008 13:28:05 -0700
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
In-Reply-To: <4857C0DF-4E68-454F-957D-EA764D065DC8@opensourceconnections.com>
References: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>
	<4857C0DF-4E68-454F-957D-EA764D065DC8@opensourceconnections.com>
Message-ID: <B2588A10-ECC1-4491-9017-A965B8823BF2@gmail.com>

I too have been fine with the 1.0.3 stuff.  New dependencies...but, no  
big deal.

I'm curious though...what else is there?  If you were to go looking  
what would you find?

On Mar 21, 2008, at 1:10 PM, Eric Pugh wrote:
> In my experience, I have found the 1.0.3 version more stable then the
> older one..  Admittedly I am not running lots of workloads through it,
> but it has been easier to setup and to code against...
>
> Eric
>
> On Mar 21, 2008, at 2:04 PM, Morten Primdahl wrote:
>
>>
>> Hi, pardon if this is a duplicate mail, I forgot to click the
>> subscription link the first time around.
>>
>> I've been using backgroundrb for a while now (older version) and I've
>> had so many headaches because of it that I began looking for a
>> replacement technology. And then I saw the new and shiny backgroundrb
>> website, looking good!
>>
>> Initially I used the version maintained by skaar, but had some long
>> forgotten issues. On Ezras recommendation, I changed to the latest
>> version he did (a downgrade so to speak), and this has been okay, but
>> we see some connectivity issues with that once it's been running  
>> for a
>> while, eg. druby://10.1.65.87:22222 - #<Errno::ECONNREFUSED:
>> Connection refused - connect(2)>
>>
>> So, I'm here to ask, what's the state of backgroundrb 1.0.3? How much
>> has changed since Herman took over? Is it ready for production and
>> rock solid? Or should I go look for something else?
>>
>> Thanks,
>>
>> Morten
>>
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> -----------------------------------------------------
> Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From primdahl at mac.com  Fri Mar 21 16:49:30 2008
From: primdahl at mac.com (Morten Primdahl)
Date: Fri, 21 Mar 2008 21:49:30 +0100
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
In-Reply-To: <B2588A10-ECC1-4491-9017-A965B8823BF2@gmail.com>
References: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>
	<4857C0DF-4E68-454F-957D-EA764D065DC8@opensourceconnections.com>
	<B2588A10-ECC1-4491-9017-A965B8823BF2@gmail.com>
Message-ID: <7980F6F4-8974-414A-B03A-35826B210E75@mac.com>


On Mar 21, 2008, at 9:28 PM, Kit Plummer wrote:
> I too have been fine with the 1.0.3 stuff.  New dependencies...but, no
> big deal.
>
> I'm curious though...what else is there?  If you were to go looking
> what would you find?

Then I'd be looking for a queuing mechanism of sorts, inspiration here:
http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue

And a question, the API has changed some since the version I use, and  
I have a little problems getting my most basic example to work in the  
console - when I attempt to read the result, I get nil. Can anyone  
spot what may be wrong:

class ReverseWorker < BackgrounDRb::MetaWorker
   set_worker_name :reverse_worker
   def create(args = nil)
     # this method is called, when worker is loaded for the first time
   end

   def reverse(arg = 'missing')
     @result = arg.reverse
   end

   def result
     @result
   end
end

flake:zendesk morten$ script/console
Loading development environment (Rails 2.0.2)
 >> key = MiddleMan.new_worker(:worker => :reverse_worker, :job_key =>  
'123')
{:type=>:start_worker, :worker=>:reverse_worker, :job_key=>"123"}

=> "123"
 >> MiddleMan.worker(:reverse_worker, key).reverse('Hello')
{:type 
= 
 > 
:do_work 
, :data 
= 
 > 
"Hello 
", :worker=>:reverse_worker, :worker_method=>:reverse, :job_key=>"123"}

=> nil
 >> MiddleMan.worker(:reverse_worker, key).result
{:type 
= 
 > 
:do_work 
, :worker=>:reverse_worker, :worker_method=>:result, :job_key=>"123"}

=> nil

Odd isn't it? The debug log:

00000006:	type:start_worker:
                                   worker:reverse_worker:
                                                         job_key123
{:type=>:start_worker, :job_key=>"123", :worker=>:reverse_worker}
00000009{
:	type:
              do_work:	data"
Hello:
       worker:reverse_worker:worker_method:
                                           reverse:
                                                   job_key123
{:type 
= 
 > 
:do_work 
, :job_key 
= 
 > 
"123 
", :worker_method=>:reverse, :worker=>:reverse_worker, :data=>"Hello"}
00000008{	:	type:
                              do_work:
                                       
worker:reverse_worker:worker_method:
                                                                          result 
:
                                                                                 job_key123
{:type 
= 
 > 
:do_work 
, :job_key=>"123", :worker_method=>:result, :worker=>:reverse_worker}

Br,

Morten







From primdahl at mac.com  Sat Mar 22 11:28:10 2008
From: primdahl at mac.com (Morten Primdahl)
Date: Sat, 22 Mar 2008 16:28:10 +0100
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
In-Reply-To: <7980F6F4-8974-414A-B03A-35826B210E75@mac.com>
References: <AB23F873-18AB-4C83-96B0-9FDCBAF9FC33@mac.com>
	<4857C0DF-4E68-454F-957D-EA764D065DC8@opensourceconnections.com>
	<B2588A10-ECC1-4491-9017-A965B8823BF2@gmail.com>
	<7980F6F4-8974-414A-B03A-35826B210E75@mac.com>
Message-ID: <AE6FCD75-50D5-42FC-9CBB-37B5FE0C5B84@mac.com>


Hi,

I found that instead of using a custom "result" method, I can get the  
result data from the worker by using register_status and ask_status -  
but is this how it's meant to work? The status methods are not  
"reserved" (semantically) for progress notifications? It's not  
possible to retrieve data from a worker by a custom method, or is my  
approach incorrect?

Thanks.

Morten


On Mar 21, 2008, at 9:49 PM, Morten Primdahl wrote:
>
> On Mar 21, 2008, at 9:28 PM, Kit Plummer wrote:
>> I too have been fine with the 1.0.3 stuff.  New dependencies...but,  
>> no
>> big deal.
>>
>> I'm curious though...what else is there?  If you were to go looking
>> what would you find?
>
> Then I'd be looking for a queuing mechanism of sorts, inspiration  
> here:
> http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue
>
> And a question, the API has changed some since the version I use, and
> I have a little problems getting my most basic example to work in the
> console - when I attempt to read the result, I get nil. Can anyone
> spot what may be wrong:
>
> class ReverseWorker < BackgrounDRb::MetaWorker
>   set_worker_name :reverse_worker
>   def create(args = nil)
>     # this method is called, when worker is loaded for the first time
>   end
>
>   def reverse(arg = 'missing')
>     @result = arg.reverse
>   end
>
>   def result
>     @result
>   end
> end
>
> flake:zendesk morten$ script/console
> Loading development environment (Rails 2.0.2)
>>> key = MiddleMan.new_worker(:worker => :reverse_worker, :job_key =>
> '123')
> {:type=>:start_worker, :worker=>:reverse_worker, :job_key=>"123"}
>
> => "123"
>>> MiddleMan.worker(:reverse_worker, key).reverse('Hello')
> {:type
> =
>>
> :do_work
> , :data
> =
>>
> "Hello
> ", :worker 
> =>:reverse_worker, :worker_method=>:reverse, :job_key=>"123"}
>
> => nil
>>> MiddleMan.worker(:reverse_worker, key).result
> {:type
> =
>>
> :do_work
> , :worker=>:reverse_worker, :worker_method=>:result, :job_key=>"123"}
>
> => nil
>
> Odd isn't it? The debug log:
>
> 00000006:	type:start_worker:
>                                   worker:reverse_worker:
>                                                         job_key123
> {:type=>:start_worker, :job_key=>"123", :worker=>:reverse_worker}
> 00000009{
> :	type:
>              do_work:	data"
> Hello:
>       worker:reverse_worker:worker_method:
>                                           reverse:
>                                                   job_key123
> {:type
> =
>>
> :do_work
> , :job_key
> =
>>
> "123
> ", :worker_method=>:reverse, :worker=>:reverse_worker, :data=>"Hello"}
> 00000008{	:	type:
>                              do_work:
>
> worker:reverse_worker:worker_method:
>                                                                          result
> :
>                                                                                 job_key123
> {:type
> =
>>
> :do_work
> , :job_key=>"123", :worker_method=>:result, :worker=>:reverse_worker}
>
> Br,
>
> Morten
>
>
>
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From subimage at gmail.com  Mon Mar 24 04:54:20 2008
From: subimage at gmail.com (subimage interactive)
Date: Mon, 24 Mar 2008 01:54:20 -0700
Subject: [Backgroundrb-devel] monit config?
In-Reply-To: <33841ac70704301002u5d42ebbehd4160834c8890e98@mail.gmail.com>
References: <33841ac70704301002u5d42ebbehd4160834c8890e98@mail.gmail.com>
Message-ID: <7aff9b4c0803240154o1817d7a8wc2fbefd68a3ad00@mail.gmail.com>

Did you ever figure this out?

On Mon, Apr 30, 2007 at 10:02 AM, Zack Chandler <zackchandler at gmail.com> wrote:
> Anyone have a a good monit config section for bgrb?
>
>  I'm thinking something like this:
>
>  check process backgroundrb with pidfile
>  /var/www/apps/foo/current/log/backgroundrb.pid
>    start program = "/var/www/apps/foo/current/script/backgroundrb start"
>    stop program = "/var/www/apps/foo/current/script/backgroundrb stop"
>    if failed host 127.0.0.1 port 2000 then restart
>    if 5 restarts within 5 cycles then timeout
>
>  Problem is the port test fails - I thought 2000 is the default...
>
>  Thanks,
>  Zack
>  _______________________________________________
>  Backgroundrb-devel mailing list
>  Backgroundrb-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>



-- 
--------------------
seth at subimage interactive
-----
http://sublog.subimage.com
-----
Cashboard - Estimates, invoices, and time tracking software - for free!
http://www.getcashboard.com
-----
Substruct - Open source RoR e-commerce software.
http://code.google.com/p/substruct/

From sweiss at stylesight.com  Tue Mar 25 12:10:28 2008
From: sweiss at stylesight.com (Stephen Weiss)
Date: Tue, 25 Mar 2008 12:10:28 -0400
Subject: [Backgroundrb-devel] State of backgroundrb (dupe?)
Message-ID: <4E989AAB-8201-4798-A4B2-4EADC9ED07D9@stylesight.com>

In my searches, most of what I've come across would be some kind of  
messaging solution, like ActiveMQ or JMS.  Actually tried to get this  
working once but it was unnecessarily complicated (and high in  
overhead) compared to even a really old backgroundrb.

New backgroundrb is great, once you adjust to the new API.  After one  
small misunderstanding I had things up and running on the new one in a  
day.  Not one crash yet, and so many more options for how you model  
your workers...  Great job, guys!

--
Steve



> From: Kit Plummer <kitplummer at gmail.com>
> Date: March 21, 2008 4:28:05 PM EDT
> To: backgroundrb-devel at rubyforge.org
> Subject: Re: [Backgroundrb-devel] State of backgroundrb (dupe?)
>
>
> I too have been fine with the 1.0.3 stuff.  New dependencies...but,  
> no big deal.
>
> I'm curious though...what else is there?  If you were to go looking  
> what would you find?

From sweiss at stylesight.com  Tue Mar 25 13:17:56 2008
From: sweiss at stylesight.com (Stephen Weiss)
Date: Tue, 25 Mar 2008 13:17:56 -0400
Subject: [Backgroundrb-devel] extending bdrb / running multiple servers
Message-ID: <F1BD6E96-DC4F-4146-B632-E5C5F91A5143@stylesight.com>

Hi,

Thanks for the help getting the new backgroundrb working, things are  
working fabulously now.

I have two questions:

1)  I have a few basic methods I need available on all my workers in  
order to communicate properly with my application... it seems to make  
the most sense right now to subclass BackgrounDRb::MetaWorker, or make  
a mixin module, because I'm actually extending some of the base  
methods as well (like the exit method, which I have extended to update  
status information in a central queue monitor).  Is there a proper  
place to put in custom code that extends BackgrounDrb, so that it is  
automatically loaded by the server before the workers are instantiated  
(sort of like an environment.rb)?

2)  I have one application server that runs Rails and does all the  
user interface, but several (10+) servers running backgroundrb to do  
all the heavy lifting (we do a lot of hi-res image processing,  
requires many CPU's).  I have a central monitor that monitors what  
servers are available to run which tasks, and load balances the tasks  
across all the available backgroundrb servers, instantiating a  
MiddleMan for the correct server and then sending the job request to  
that server.  Needless to say, this process is going a lot easier with  
the new version, except for one catch.  With the old backgroundrb, I  
was able to connect to an arbitrary server like this:

thisMiddleMan = DRbObject.new(nil, "druby://#{server_name}:22223");

Now this doesn't work.  So, I took a look at  
BackgrounDRb::WorkerProxy, and it seems like it can only connect to  
the server listed in the config file.  Is there supposed to be a way  
to manage multiple backgroundrb servers?  I've read the manual, it's  
not in there.  My solution so far is to subclass WorkerProxy, with a  
new init method that takes the host and port as parameters:

class BackgrounDRb::CustomProxy < BackgrounDRb::WorkerProxy
   def self.init(ip, port)
     @@config = BackgrounDRb::Config.read_config("#{BACKGROUNDRB_ROOT}/ 
config/backgroundrb.yml")
     @@server_ip = ip
     @@server_port = port
     new
   end
end

But this doesn't seem very elegant to me, I worry about future  
software updates...  Is there a clean method for doing this or is this  
just not supported (yet)?

Thanks for any insight, really appreciate it!

--
Steve

From gethemant at gmail.com  Tue Mar 25 17:17:20 2008
From: gethemant at gmail.com (hemant)
Date: Wed, 26 Mar 2008 02:47:20 +0530
Subject: [Backgroundrb-devel] Questions about backgroundrb
In-Reply-To: <efc1839e0803250725s5c50bda1u27f2d9507da0e926@mail.gmail.com>
References: <efc1839e0803250725s5c50bda1u27f2d9507da0e926@mail.gmail.com>
Message-ID: <fb283d5e0803251417n46fcc1c3ma5308a6993b11f16@mail.gmail.com>

Cc'ing to the list for archival purposes:

On Tue, Mar 25, 2008 at 7:55 PM, Brian Noguchi <brian.noguchi at gmail.com> wrote:
> Hi Hemant,
>
> I'm Brian Noguchi, a developer in the Bay Area.  I have some questions about
> backgroundrb, and I found your contact info on a forum.  I figured its
> probably best to get answers straight from the source.
>
> First of all, thanks for your work on backgroundrb!  I've heard nothing but
> great things about the newest version.  I'm looking forward to incorporating
> it into my site.
>
> I had several questions regarding implementing some features on my site
> using backgroundrb.  If you could help guide me in any way with any of
> these, that would be great!
>
> Background:  I'm trying to write a series of web crawler tasks.  This is my
> first time writing a robust web crawler.
>
> A new web crawler task is initiated whenever a user decides to track
> information from a new site.  Upon initialization by the user, that web
> crawler is supposed to run using backgroundrb and then (1) save the
> information to the db and (2) periodically provide data back to the view
> either with xml or json that displays the contents of its crawl thus far.

Great!

>
> After the web crawler runs once, it is then scheduled to run periodically on
> a daily basis, saving information to the db but not generating any xml or
> json to send back to the view.
> The questions I have:
>
> Is the following the best/most scalable way to implement?...Each site I am
> crawling gets its own worker -- e.g., MyspaceWorker.  Within each worker, I
> have a crawl method that uses concurrency to avoid latency when crawling one
> set of several web pages within one website.  If 2 users decides to track
> two different sets of pages from a given website, then I declare two new
> instances of MyspaceWorker.  And so on and so forth.

Having one worker for each website is ok. But "If 2 users decides to track
two different sets of pages from a given website, then I declare two new
 instances of MyspaceWorker." is BAD. Because if you have 100 users
tracking same website, then you will have 100 instances of workers
running. Thats where thread_pool comes in to the picture. Read below
for more details.

>
> How do I provide json or xml back to the view if I'm using workers?  It's
> important for the UI to show crawled content periodically to show a more
> detailed progress "indicator" in the view.

Just generate xml/json and save as status/result objects for the
worker and then query the data back using ask_status method of a
worker.

>
> In one of your posts, you mention:
> " When you are processing too many tasks from rails, you should use inbuilt
> thread pool, rather than firing new workers"
> ...We are planning to have 100s of web crawlers being initiated and thus
> periodically scheduled to run.  I'm assuming I should use the inbuilt thread
> pool.  But does this mean that the workers are running in parallel as
> threads no matter the worker type?  Or that the instances of each worker are
> run in parallel for one given worker type?  What exactly is being threaded?
> I'm not very familiar with the event model of network programming that you
> mention; I looked into it, but am a little confused when it comes to
> figuring out exactly how the workers and everything works from a network
> programming theory point of view.  Any clarification with regards
 to this
> issue or direction to some resources would be greatly appreciated. I hope
> you'll have time to address some or all of these questions.  Hopefully, they
> will not take too long to answer.  Sorry for the inconvenience.  Thanks for
> the plugin and the help.  I hope I can get my ruby-fu to the point where I
> can contribute back to the community in a similar fashion in the future.

As I said earlier in this mail, having one worker for each user
tracking same website is bad. What you need is, when 2 users are
tracking same website, but different pages, you can have 2 threads
within same worker. Let me explain:

Say user x, wants to track /social_revolution page of myspace and user
y wants to track /facebook_suks page of myspace.  As you mentioned
earlier, tracking itself will be invoked from rails hence, assuming
our myspace worker is already started, we will send following data to
the worker:

MiddleMan.worker(:myspace_worker).crawl_page(:page_name =>
"social_revolution",:user_id => x)

Where crawl_page is a method inside MyspaceWorker.

class MyspaceWorker<BackgrounDRb::MetaWorker
  def create
     @crawled_data = {}
     @data_mutex = Mutex.new
  end
  def crawl_page options = {}
     thread_pool.defer(options) { start_crawling(options)}
  end

  def start_crawling options
    # do your page crawling here
    result = magical_crawl(options[:page_name])
    # since multiple threads may write to the same hash, lets protect
it with a mutex
    @data_mutex.sycncronize do
       @crawled_data[options[:user_id]] = result
    end
    # save as status hash, so as it can be accessed later from rails
    register_status(@crawled_data)
  end
end

Similarly for other user. So whats being threaded here is, your
crawling task and now our worker can do concurrent crawling for many
users. You can get the generated xml/json using:

result = (MiddleMan.worker(:myspace_worker).ask_status)[:whatever_user_id]

You mentioned, you also need to schedule crawling for periodic
execution. For that case, you should probably separate actual crawling
function in a separate method and set it to periodically execute.
There are couple of finer points that needs to be kept in mind:

1. Crawled xml/json can be huge and hence consider using Memcache for
result storage. BackgrounDRb supports clustered memcache based result
storage.
2. If you are using same instance of MyspaceWorker for crawling pages
on demand as well as for scheduling crawling. Usually scheduled tasks
are not threaded, as in say you have scheduled crawling of pages
preferred by users x,y and z, then while worker is processing (thats ,
while its doing actual crawling, not sitting idle for schedule to
reach) task, it won't be able to respond to requests from rails
immediately. You can mitigate this easily by adding scheduled tasks to
thread pool as well. What I mean is, say method "scheduled_crawling"
initiates scheduled crawling of pages preferred by all users on
current website. You can schedule "scheduled_crawling" through cron
scheduler or normal add_periodic_timer method. Now, since you do not
want scheduled processing to block rest of the request/response cycle,
you can do:

def scheduled_crawling
  x = find_pages_to_crawl
  thread_pool.defer {|x| crawl_without_xml_jxon(x)}
end

All in all, its a bit tricky and hence all the best.

From gethemant at gmail.com  Tue Mar 25 18:27:42 2008
From: gethemant at gmail.com (hemant)
Date: Wed, 26 Mar 2008 03:57:42 +0530
Subject: [Backgroundrb-devel] extending bdrb / running multiple servers
In-Reply-To: <F1BD6E96-DC4F-4146-B632-E5C5F91A5143@stylesight.com>
References: <F1BD6E96-DC4F-4146-B632-E5C5F91A5143@stylesight.com>
Message-ID: <fb283d5e0803251527p11c0083cye2b8a9fcf9c79ed4@mail.gmail.com>

On Tue, Mar 25, 2008 at 10:47 PM, Stephen Weiss <sweiss at stylesight.com> wrote:
> Hi,
>
>  Thanks for the help getting the new backgroundrb working, things are
>  working fabulously now.
>
>  I have two questions:
>
>  1)  I have a few basic methods I need available on all my workers in
>  order to communicate properly with my application... it seems to make
>  the most sense right now to subclass BackgrounDRb::MetaWorker, or make
>  a mixin module, because I'm actually extending some of the base
>  methods as well (like the exit method, which I have extended to update
>  status information in a central queue monitor).  Is there a proper
>  place to put in custom code that extends BackgrounDrb, so that it is
>  automatically loaded by the server before the workers are instantiated
>  (sort of like an environment.rb)?

For the time being, you can put that file in lib folder of your rails
application and require that file in environment.rb.

>
>  2)  I have one application server that runs Rails and does all the
>  user interface, but several (10+) servers running backgroundrb to do
>  all the heavy lifting (we do a lot of hi-res image processing,
>  requires many CPU's).  I have a central monitor that monitors what
>  servers are available to run which tasks, and load balances the tasks
>  across all the available backgroundrb servers, instantiating a
>  MiddleMan for the correct server and then sending the job request to
>  that server.  Needless to say, this process is going a lot easier with
>  the new version, except for one catch.  With the old backgroundrb, I
>  was able to connect to an arbitrary server like this:
>
>  thisMiddleMan = DRbObject.new(nil, "druby://#{server_name}:22223");
>
>  Now this doesn't work.  So, I took a look at
>  BackgrounDRb::WorkerProxy, and it seems like it can only connect to
>  the server listed in the config file.  Is there supposed to be a way
>  to manage multiple backgroundrb servers?  I've read the manual, it's
>  not in there.  My solution so far is to subclass WorkerProxy, with a
>  new init method that takes the host and port as parameters:
>
>  class BackgrounDRb::CustomProxy < BackgrounDRb::WorkerProxy
>    def self.init(ip, port)
>      @@config = BackgrounDRb::Config.read_config("#{BACKGROUNDRB_ROOT}/
>  config/backgroundrb.yml")
>      @@server_ip = ip
>      @@server_port = port
>      new
>    end
>  end
>
>  But this doesn't seem very elegant to me, I worry about future
>  software updates...  Is there a clean method for doing this or is this
>  just not supported (yet)?
>

Since, each connection to BackgrounDRb server is nothing but a plain
tcp socket connection. Now, before composing a reply to your message,
I actually committed a little code change, which allows you do do:

Loading development environment (Rails 2.0.2)
server ip: 0.0.0.0 11006
>> foo = BackgrounDRb::WorkerProxy.custom_connection("localhost",11006)
server ip: localhost 11006
=> #<BackgrounDRb::WorkerProxy:0xb7477e14 @mutex=#<Mutex:0xb7477dec>,
@connection_status=true, @connection=#<TCPSocket:0xb7477ce8>>
>> foo
=> #<BackgrounDRb::WorkerProxy:0xb7477e14 @mutex=#<Mutex:0xb7477dec>,
@connection_status=true, @connection=#<TCPSocket:0xb7477ce8>>
>> foo.all_worker_info
=> [{:job_key=>"", :status=>:running, :worker=>:log_worker}]
>> foo.query_all_worker_info
NoMethodError: undefined method `query_all_worker_info' for
#<BackgrounDRb::WorkerProxy:0xb7477e14>
        from (irb):4
>> foo.query_all_workers
=> {:log_worker=>nil}

So, update the code from git and use it.
I hope this helps.

From chrisangileri at yahoo.com  Wed Mar 26 19:06:52 2008
From: chrisangileri at yahoo.com (Eire Angel)
Date: Wed, 26 Mar 2008 16:06:52 -0700 (PDT)
Subject: [Backgroundrb-devel] bgrb won't start
Message-ID: <907973.42036.qm@web53405.mail.re2.yahoo.com>

I get the error when trying to start backgroundRb 1.0.3 running on Rails 1.2.6

 ./backgroundrb start
./backgroundrb:11:in `require': no such file to load -- /var/www/test/vendor/plugins/backgroundrb/config/boot.rb (LoadError)
        from ./backgroundrb:11


is 1.0.3 able to run on rails 1.26 ?
this was my thought as to why it wasn't working
unfortunately i cannot upgrade rails just yet.
any other thoughts ?

Chris

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

From gethemant at gmail.com  Thu Mar 27 03:31:57 2008
From: gethemant at gmail.com (hemant)
Date: Thu, 27 Mar 2008 13:01:57 +0530
Subject: [Backgroundrb-devel] bgrb won't start
In-Reply-To: <907973.42036.qm@web53405.mail.re2.yahoo.com>
References: <907973.42036.qm@web53405.mail.re2.yahoo.com>
Message-ID: <fb283d5e0803270031p25f2bd2an9082f23ba8600694@mail.gmail.com>

On Thu, Mar 27, 2008 at 4:36 AM, Eire Angel <chrisangileri at yahoo.com> wrote:
> I get the error when trying to start backgroundRb 1.0.3 running on Rails
> 1.2.6
>
>  ./backgroundrb start
> ./backgroundrb:11:in `require': no such file to load --
> /var/www/test/vendor/plugins/backgroundrb/config/boot.rb (LoadError)
>         from ./backgroundrb:11
>
>
> is 1.0.3 able to run on rails 1.26 ?
> this was my thought as to why it wasn't working
> unfortunately i cannot upgrade rails just yet.
> any other thoughts ?
>


Please go to RAILS root directory and run:

./script/backgroundrb start

Else, I think, you should be able to start bdrb from script directory
too. You can file a ticket, if you like.

From emarceta at gmail.com  Thu Mar 27 17:30:52 2008
From: emarceta at gmail.com (Emil Marceta)
Date: Thu, 27 Mar 2008 22:30:52 +0100
Subject: [Backgroundrb-devel] lazy_load config bug
Message-ID: <74b000990803271430i11c82f7aw5af0950d1d7bfd4c@mail.gmail.com>

Hi there,

This is in master_worker.rb at 266 - it looks to me that there is a bug
in reading the lazy_loading property.

The line below doesn't work if lazy_load: true is specified in the yml.

 lazy_load = CONFIG_FILE[:backgroundrb][:lazy_load].nil? ? true :
CONFIG_FILE[:backgroundrb][:lazy_load].nil?

should say something like this:

lazy_load = CONFIG_FILE[:backgroundrb][:lazy_load] || true

Also,  there is  print statement on the next line that should probably go away.


thanks,
emil

From emarceta at gmail.com  Fri Mar 28 14:13:15 2008
From: emarceta at gmail.com (Emil Marceta)
Date: Fri, 28 Mar 2008 19:13:15 +0100
Subject: [Backgroundrb-devel] Upgrading from older version - how?
Message-ID: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>

Hi there,

We've been using previous version of bdrb (drb based one) for a while
and it was running relatively OK. We recently attempted to upgrade to
the new version to keep up / use supported version but we ended up
reverting to the older version.


Here are the things that moved us to revert :

1) With the workers we never manage to pass this error:
''
You have a nil object when you didn't expect it!
The error occurred while evaluating nil.send_request
/opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:44:in
`ask_worker'
''

2) It is not clear the difference between Middleman.worker(:my_worker,
key).ask_status and using the nonexistent method
Middleman.worker(:my_worker, key).mumbo_jumbo - they both return nil.
I understand that is related to one way invocation (asynch) but this
just too loose and easy to mixup things.

3) Unit testing - we used backgroundrb_mock.rb that mocks new_worker
and other framework api that manage the creation of workers, so
testing was simple as testing any other Rails classes. This is
actually pretty big one for us.

4) No RDoc  - older version has RDoc.

5) ./script/background start | stop are unreliable. Stop throws if the
pid file is not found. Invoking start multiple times start multiple
processes - not sure what that means. Invoking stop afterwards stops
only the one process obviously.

6) Finally it would be great to have some sort of migration cookbook -
how to change the older workers and migrate to the new version. The
number of changes are pretty big and we were never sure whether we
completed the migration.

Hope this does not sound too negative - those are our 'wishes' for new
bdrdb to have.

thanks,
emil

From jonathan.wallace at gmail.com  Fri Mar 28 14:44:06 2008
From: jonathan.wallace at gmail.com (Jonathan Wallace)
Date: Fri, 28 Mar 2008 14:44:06 -0400
Subject: [Backgroundrb-devel] Upgrading from older version - how?
In-Reply-To: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
References: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
Message-ID: <fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>

On Fri, Mar 28, 2008 at 2:13 PM, Emil Marceta <emarceta at gmail.com> wrote:
[snip]
>  5) ./script/background start | stop are unreliable. Stop throws if the
>  pid file is not found. Invoking start multiple times start multiple
>  processes - not sure what that means. Invoking stop afterwards stops
>  only the one process obviously.

I'm unable to reproduce the your issue of multiple processes when
invoking start multiple times.  Did you delete your
script/backgroundrb file and run rake backgroundrb:setup?

username at host ~/current_app_name $ ps aux | grep ruby &&
./script/backgroundrb start && ps aux | grep ruby
username  30073  0.0  2.0  48452 35288 ?        Sl   17:39   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3000 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3000.pid -l
/var/www/rails/app_name/current/log/mongrel.3000.log
username  30076  0.0  2.0  47808 34952 ?        Sl   17:39   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3001 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3001.pid -l
/var/www/rails/app_name/current/log/mongrel.3001.log
username  30079  0.0  2.1  51284 38292 ?        Sl   17:39   0:03
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3002 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3002.pid -l
/var/www/rails/app_name/current/log/mongrel.3002.log
username  30082  0.0  1.9  46684 33820 ?        Sl   17:40   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3003 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3003.pid -l
/var/www/rails/app_name/current/log/mongrel.3003.log
username  30402  0.0  1.7  43000 30396 ?        S    18:28   0:00 ruby
/var/www/rails/app_name/current/script/backgroundrb start
username  30403  0.0  1.7  42864 29860 ?        S    18:28   0:00 ruby
log_worker
username  30409  0.1  1.9  44972 33576 ?        S    18:28   0:01 ruby
queue_processing_worker
username  30484  0.0  0.0   1700   504 pts/0    R+   18:37   0:00 grep
--colour=auto ruby
username  30073  0.0  2.0  48452 35288 ?        Sl   17:39   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3000 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3000.pid -l
/var/www/rails/app_name/current/log/mongrel.3000.log
username  30076  0.0  2.0  47808 34952 ?        Sl   17:39   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3001 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3001.pid -l
/var/www/rails/app_name/current/log/mongrel.3001.log
username  30079  0.0  2.1  51284 38292 ?        Sl   17:39   0:03
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3002 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3002.pid -l
/var/www/rails/app_name/current/log/mongrel.3002.log
username  30082  0.0  1.9  46684 33820 ?        Sl   17:40   0:02
/usr/bin/ruby18 /usr/bin/mongrel_rails start -d -e production -a
10.252.63.80 -c /var/www/rails/app_name/current -p 3003 -P
/var/www/rails/app_
name/current/tmp/pids/mongrel.3003.pid -l
/var/www/rails/app_name/current/log/mongrel.3003.log
username  30402  0.0  1.7  43008 30404 ?        S    18:28   0:00 ruby
/var/www/rails/app_name/current/script/backgroundrb start
username  30403  0.0  1.7  42864 29868 ?        S    18:28   0:00 ruby
log_worker
username  30409  0.1  1.9  44972 33576 ?        S    18:28   0:01 ruby
queue_processing_worker
username  30488  0.0  1.6  41724 29224 pts/0    R    18:37   0:00 ruby
log_worker
username  30490  0.0  0.0   1700   504 pts/0    R+   18:37   0:00 grep
--colour=auto ruby


I use capistrano and have added the following tasks to my
config/deploy.rb for handling the thrown error where a pid file
doesn't exist.

 task :restart do
    run "mongrel_rails cluster::restart -C #{mongrel_conf}"
    restart_backgroundrb
  end

  task :restart_backgroundrb do
    begin stop_backgroundrb; rescue; end #this catches the bdrb error
where a PID file doesn't exist
    start_backgroundrb
  end

  task :stop_backgroundrb do
    run "#{deploy_to}/current/script/backgroundrb stop"
  end

  task :start_backgroundrb do
    run "#{deploy_to}/current/script/backgroundrb start"
  end

Good luck!
  Jonathan

From emarceta at gmail.com  Fri Mar 28 15:01:17 2008
From: emarceta at gmail.com (Emil Marceta)
Date: Fri, 28 Mar 2008 20:01:17 +0100
Subject: [Backgroundrb-devel] Upgrading from older version - how?
In-Reply-To: <fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
References: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
	<fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
Message-ID: <74b000990803281201m53449cd9g6d5087621507501c@mail.gmail.com>

On Fri, Mar 28, 2008 at 7:44 PM, Jonathan Wallace
<jonathan.wallace at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 2:13 PM, Emil Marceta <emarceta at gmail.com> wrote:
>  [snip]
>
> >  5) ./script/background start | stop are unreliable. Stop throws if the
>  >  pid file is not found. Invoking start multiple times start multiple
>  >  processes - not sure what that means. Invoking stop afterwards stops
>  >  only the one process obviously.
>
>  I'm unable to reproduce the your issue of multiple processes when
>  invoking start multiple times.  Did you delete your
>  script/backgroundrb file and run rake backgroundrb:setup?

Yes. Here is on vanilla Rails project created from scratch with plugin
installed at the same time.


wahoo:bdrb_test emil$ ./script/backgroundrb start
wahoo:bdrb_test emil$ ps ax | grep ruby
 3075 s003  S      0:00.08 ruby ./script/backgroundrb start
 3076 s003  S      0:00.05 ruby log_worker
TERM_PROGRAM=iTerm.app
 3078 s003  R+     0:00.00 grep ruby
wahoo:bdrb_test emil$ ./script/backgroundrb start
wahoo:bdrb_test emil$ ps ax | grep ruby
 3075 s003  S      0:00.21 ruby ./script/backgroundrb start
 3076 s003  S      0:00.14 ruby log_worker
TERM_PROGRAM=iTerm.app
 3083 s003  R+     0:00.00 grep ruby
wahoo:bdrb_test emil$ ./script/backgroundrb stop
Deleting pid file
wahoo:bdrb_test emil$ ps ax | grep ruby
 3075 s003  S      0:00.37 ruby ./script/backgroundrb start
 3076 s003  S      0:00.25 ruby log_worker
TERM_PROGRAM=iTerm.app
 3086 s003  R+     0:00.00 grep ruby
wahoo:bdrb_test emil$ ./script/backgroundrb stop
./script/backgroundrb:46:in `initialize': No such file or directory -
/Users/emil/tmp/bdrb_test/tmp/pids/backgroundrb_11006.pid
(Errno::ENOENT)
        from ./script/backgroundrb:46:in `open'
        from ./script/backgroundrb:46
wahoo:bdrb_test emil$ ps ax | grep ruby
 3075 s003  S      0:00.95 ruby ./script/backgroundrb start
 3076 s003  S      0:00.61 ruby log_worker
TERM_PROGRAM=iTerm.app
 3089 s003  R+     0:00.00 grep ruby
wahoo:bdrb_test emil$

Maybe is OS X specific. I added a guard in script/backgroundrb that
tests for the pid file existence and that fixes double stop but he
double start is still there. Could it be that the 2nd start is
rewriting the pid file?

The start/stop issue is a less important one though. Migration process
/ tasks from old version to this version is our major issue. We were
unsuccessful to convert workers and framework to this version.

emil

From emarceta at gmail.com  Fri Mar 28 16:00:42 2008
From: emarceta at gmail.com (Emil Marceta)
Date: Fri, 28 Mar 2008 21:00:42 +0100
Subject: [Backgroundrb-devel] Upgrading from older version - how?
In-Reply-To: <fd0631d50803281225y7b0c351h734ccbabe48a402b@mail.gmail.com>
References: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
	<fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
	<74b000990803281201m53449cd9g6d5087621507501c@mail.gmail.com>
	<fd0631d50803281225y7b0c351h734ccbabe48a402b@mail.gmail.com>
Message-ID: <74b000990803281300g13246e50p6fdbeb63de48c13b@mail.gmail.com>

On Fri, Mar 28, 2008 at 8:25 PM, Jonathan Wallace
<jonathan.wallace at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 3:01 PM, Emil Marceta <emarceta at gmail.com> wrote:

<snip/>

>  All of my workers are basically just calls into my models.  I'm not
>  using the dynamic worker creation.  This keeps all testing in
>  Test::Unit.  I'm using bdrb to run jobs that are queued to the
>  database by controllers.


Yes. however to do integration or functional testing - where
controller starts the worker  - fully mocked framework is needed.
backroundrb_mock.rb in the older version is perfect, it does not
require backgroundrb server and runs the worker class synchronously.

However I'm still stuck at the step 1 - to invoke the worker. I get
this exception :
''
The error occurred while evaluating nil.send_request
/opt/local/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:44:in
`ask_worker'
''

emil

From emarceta at gmail.com  Fri Mar 28 17:25:32 2008
From: emarceta at gmail.com (Emil Marceta)
Date: Fri, 28 Mar 2008 22:25:32 +0100
Subject: [Backgroundrb-devel] Upgrading from older version - how?
In-Reply-To: <74b000990803281201m53449cd9g6d5087621507501c@mail.gmail.com>
References: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
	<fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
	<74b000990803281201m53449cd9g6d5087621507501c@mail.gmail.com>
Message-ID: <74b000990803281425y25176dc7qe0cb21824801d82b@mail.gmail.com>

On Fri, Mar 28, 2008 at 8:01 PM, Emil Marceta <emarceta at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 7:44 PM, Jonathan Wallace
>  <jonathan.wallace at gmail.com> wrote:
>  > On Fri, Mar 28, 2008 at 2:13 PM, Emil Marceta <emarceta at gmail.com> wrote:
[snip]
>  Maybe is OS X specific.

just for a reference here is the old version on OS X.

wahoo:steam emil$ ./script/backgroundrb start
wahoo:steam emil$ ./script/backgroundrb start
ERROR: there is already one or more instance(s) of the program running

emil

From zach at plugthegap.co.uk  Sun Mar 30 23:21:10 2008
From: zach at plugthegap.co.uk (Zachary Powell)
Date: Sun, 30 Mar 2008 23:21:10 -0400
Subject: [Backgroundrb-devel] UK Daylight Savings
Message-ID: <ac243e420803302021u56ae2f0bj2252bb4223687a3a@mail.gmail.com>

A quick fix for anyone running into this problem:

load_schedule was crashing cron_trigger.rb#160, and I found that for
triggers like "0 20 5 * * * *" it was putting in 32 for the date (even
though its Mon Mar 31 04:16:21 BST 2008). Something to do with switching to
day light savings I think, which concludes after 2am. I patched it by adding

day = 31 if day == 32

on the line before. Not sure if there are any ramifications to this, but it
seems to be running now.

Zach

(I'm running r303 right now. possibly this has been fixed)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080330/8221c491/attachment-0001.html 

From zach at plugthegap.co.uk  Mon Mar 31 05:49:45 2008
From: zach at plugthegap.co.uk (Zachary Powell)
Date: Mon, 31 Mar 2008 05:49:45 -0400
Subject: [Backgroundrb-devel] UK Daylight Savings
In-Reply-To: <ac243e420803302021u56ae2f0bj2252bb4223687a3a@mail.gmail.com>
References: <ac243e420803302021u56ae2f0bj2252bb4223687a3a@mail.gmail.com>
Message-ID: <ac243e420803310249t6f435c15t2336be25ed9e4203@mail.gmail.com>

Apparently this hasn't fixed it -the scheduler has been firing off workers
repeatedly ("0 50 2 * * * *" firing off every few seconds etc). Will post
any findings later.
Zach

On Sun, Mar 30, 2008 at 11:21 PM, Zachary Powell <zach at plugthegap.co.uk>
wrote:

> A quick fix for anyone running into this problem:
>
> load_schedule was crashing cron_trigger.rb#160, and I found that for
> triggers like "0 20 5 * * * *" it was putting in 32 for the date (even
> though its Mon Mar 31 04:16:21 BST 2008). Something to do with switching to
> day light savings I think, which concludes after 2am. I patched it by adding
>
> day = 31 if day == 32
>
> on the line before. Not sure if there are any ramifications to this, but
> it seems to be running now.
>
> Zach
>
> (I'm running r303 right now. possibly this has been fixed)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080331/1c07f12e/attachment.html 

From zach at plugthegap.co.uk  Mon Mar 31 08:56:51 2008
From: zach at plugthegap.co.uk (Zachary Powell)
Date: Mon, 31 Mar 2008 08:56:51 -0400
Subject: [Backgroundrb-devel] UK Daylight Savings
In-Reply-To: <1EE76CDD-2AF9-41E0-A240-C1EC52644E42@gmx.de>
References: <ac243e420803302021u56ae2f0bj2252bb4223687a3a@mail.gmail.com>
	<1EE76CDD-2AF9-41E0-A240-C1EC52644E42@gmx.de>
Message-ID: <ac243e420803310556y9a0559djb95e69bd63c0228f@mail.gmail.com>

thanks Thomas,

Mm, I think my first patch was making it fire repeatedly because the time it
created was in the past. I've improved it (move forwards not back), but
obviously its still a hack around the issue. not even sure if they're firing
at the right time (but as they're early morning maintenance scripts 1 hour
off is no big deal):
    server/cron_trigger.rb#160:

      begin
        s = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
#{yday}, #{isdst}, #{zone}"
        if(day == 32)
          day = 1
          month += 1
          if(month == 13)
            month = 1
            year +=1
          end
        end
        s2 = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
#{yday}, #{isdst}, #{zone}"
        puts "changed\n#{s}\n#{s2}" unless s == s2
        Time.local sec, min, hour, day, month, year, wday, yday, isdst, zone
      rescue => e
        raise "failed\n#{s}\n\#{s2}"
      end

which produced this in the log:

changed
0, 0, 0, 32, 3, 2008, 1, 91, true, BST
0, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
30, 0, 0, 32, 3, 2008, 1, 91, true, BST
30, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 10, 5, 32, 3, 2008, 1, 91, true, BST
0, 10, 5, 1, 4, 2008, 1, 91, true, BST
changed
0, 20, 5, 32, 3, 2008, 1, 91, true, BST
0, 20, 5, 1, 4, 2008, 1, 91, true, BST
changed
30, 20, 0, 32, 3, 2008, 1, 91, true, BST
30, 20, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 0, 0, 32, 3, 2008, 1, 91, true, BST
0, 0, 0, 1, 4, 2008, 1, 91, true, BST
changed
0, 50, 2, 32, 3, 2008, 1, 91, true, BST
0, 50, 2, 1, 4, 2008, 1, 91, true, BST


unfortunately i've got too much going on to look into a proper fix, but i'll
post one in a few weeks once the busy period has blown over (hopefully this
will hold out, seems logical..)


On Mon, Mar 31, 2008 at 5:56 AM, Thomas R. Koll <tomk32 at gmx.de> wrote:

>
> Am 31.03.2008 um 05:21 schrieb Zachary Powell:
> > A quick fix for anyone running into this problem:
> >
> > load_schedule was crashing cron_trigger.rb#160, and I found that
> > for triggers like "0 20 5 * * * *" it was putting in 32 for the
> > date (even though its Mon Mar 31 04:16:21 BST 2008). Something to
> > do with switching to day light savings I think, which concludes
> > after 2am. I patched it by adding
> >
> > day = 31 if day == 32
>
> I guess this version would be better for now (until some madman
> changes the whole world, uhh don't read my sig)
>
> day = 31 if day > 31
>
> ciao, tom
>
> --
> Thomas R. "TomK32" Koll || http://tomk32.de || http://ananasblau.com
> (NEW)
> just a geek trying to change the world
> Skype: TomK32 || Mail: tomk32 at gmx.de
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080331/51a19874/attachment.html 

From jonathan.wallace at gmail.com  Mon Mar 31 10:49:42 2008
From: jonathan.wallace at gmail.com (Jonathan Wallace)
Date: Mon, 31 Mar 2008 10:49:42 -0400
Subject: [Backgroundrb-devel] Upgrading from older version - how?
In-Reply-To: <fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
References: <74b000990803281113i1e6da888t83a20efdad70b179@mail.gmail.com>
	<fd0631d50803281144i148c5a89p738cd1c32ffdf4f1@mail.gmail.com>
Message-ID: <fd0631d50803310749j2ba2d8d8nd77104b8e954fc2d@mail.gmail.com>

Hello,

I'd just like to update that my capistrano deploy tasks for
backgroundrb were incorrect for my situation.  In my case, the current
working directory for backgroundrb on deploy was the home directory of
the deploy user.  This caused some issues in my app.  Here are the
updated tasks which correct the issue.

  task :restart do
    run "mongrel_rails cluster::restart -C #{mongrel_conf}"
    restart_backgroundrb
  end

  task :restart_backgroundrb do
    begin stop_backgroundrb; rescue; end #this catches the bdrb error
where a PID file doesn't exist
    start_backgroundrb
  end

  task :stop_backgroundrb do
    run "cd #{deploy_to}/current &&
#{deploy_to}/current/script/backgroundrb stop"
  end

  task :start_backgroundrb do
    run "cd #{deploy_to}/current &&
#{deploy_to}/current/script/backgroundrb start"
  end

Jonathan

On Fri, Mar 28, 2008 at 2:44 PM, Jonathan Wallace
<jonathan.wallace at gmail.com> wrote:
>  I use capistrano and have added the following tasks to my
>  config/deploy.rb for handling the thrown error where a pid file
>  doesn't exist.
>
>   task :restart do
>     run "mongrel_rails cluster::restart -C #{mongrel_conf}"
>     restart_backgroundrb
>   end
>
>   task :restart_backgroundrb do
>     begin stop_backgroundrb; rescue; end #this catches the bdrb error
>  where a PID file doesn't exist
>     start_backgroundrb
>   end
>
>   task :stop_backgroundrb do
>     run "#{deploy_to}/current/script/backgroundrb stop"
>   end
>
>   task :start_backgroundrb do
>     run "#{deploy_to}/current/script/backgroundrb start"
>   end
>
>  Good luck!
>   Jonathan
>

From sweiss at stylesight.com  Mon Mar 31 11:16:28 2008
From: sweiss at stylesight.com (Stephen Weiss)
Date: Mon, 31 Mar 2008 11:16:28 -0400
Subject: [Backgroundrb-devel] Patch - Multiple servers support
Message-ID: <90B4877B-1E5E-4F6F-BDDE-C357CA57901C@stylesight.com>

Hi,

This is a patch that allows you to work with multiple backgroundrb  
servers from within Rails.  It modifies the rails worker proxy to use  
a middleman supplied in its constructor, instead of using the  
MiddleMan constant.  Basically a fix to make  
BackgrounDRb::WorkerProxy.custom_connection usable (without patch,  
you can establish a custom connection but all calls to worker objects  
still go to the main MiddleMan connection regardless).

If I didn't submit this correctly please let me know, I don't submit  
patches all that often. Thanks.

--
Stephen Weiss
stevemw at mac.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdrb-multiple-connections-fix.patch
Type: application/octet-stream
Size: 1900 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080331/7bfd121a/attachment.obj 

From gethemant at gmail.com  Mon Mar 31 13:08:22 2008
From: gethemant at gmail.com (hemant)
Date: Mon, 31 Mar 2008 22:38:22 +0530
Subject: [Backgroundrb-devel] UK Daylight Savings
In-Reply-To: <ac243e420803310556y9a0559djb95e69bd63c0228f@mail.gmail.com>
References: <ac243e420803302021u56ae2f0bj2252bb4223687a3a@mail.gmail.com>
	<1EE76CDD-2AF9-41E0-A240-C1EC52644E42@gmx.de>
	<ac243e420803310556y9a0559djb95e69bd63c0228f@mail.gmail.com>
Message-ID: <fb283d5e0803311008o4de8377q1b80b785f80aebd5@mail.gmail.com>

On Mon, Mar 31, 2008 at 6:26 PM, Zachary Powell <zach at plugthegap.co.uk> wrote:
> thanks Thomas,
>
> Mm, I think my first patch was making it fire repeatedly because the time it
> created was in the past. I've improved it (move forwards not back), but
> obviously its still a hack around the issue. not even sure if they're firing
> at the right time (but as they're early morning maintenance scripts 1 hour
> off is no big deal):
>
>     server/cron_trigger.rb#160:
>
>
>       begin
>         s = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
> #{yday}, #{isdst}, #{zone}"
>         if(day == 32)
>           day = 1
>           month += 1
>           if(month == 13)
>             month = 1
>             year +=1
>           end
>         end
>         s2 = "#{sec}, #{min}, #{hour}, #{day}, #{month}, #{year}, #{wday},
> #{yday}, #{isdst}, #{zone}"
>         puts "changed\n#{s}\n#{s2}" unless s == s2
>         Time.local sec, min, hour, day, month, year, wday, yday, isdst, zone
>       rescue => e
>         raise "failed\n#{s}\n\#{s2}"
>       end
>
> which produced this in the log:
>
>
> changed
> 0, 0, 0, 32, 3, 2008, 1, 91, true, BST
> 0, 0, 0, 1, 4, 2008, 1, 91, true, BST
> changed
> 30, 0, 0, 32, 3, 2008, 1, 91, true, BST
> 30, 0, 0, 1, 4, 2008, 1, 91, true, BST
> changed
> 0, 10, 5, 32, 3, 2008, 1, 91, true, BST
> 0, 10, 5, 1, 4, 2008, 1, 91, true, BST
>  changed
> 0, 20, 5, 32, 3, 2008, 1, 91, true, BST
> 0, 20, 5, 1, 4, 2008, 1, 91, true, BST
> changed
> 30, 20, 0, 32, 3, 2008, 1, 91, true, BST
> 30, 20, 0, 1, 4, 2008, 1, 91, true, BST
> changed
> 0, 0, 0, 32, 3, 2008, 1, 91, true, BST
> 0, 0, 0, 1, 4, 2008, 1, 91, true, BST
> changed
> 0, 50, 2, 32, 3, 2008, 1, 91, true, BST
> 0, 50, 2, 1, 4, 2008, 1, 91, true, BST
>
>
> unfortunately i've got too much going on to look into a proper fix, but i'll
> post one in a few weeks once the busy period has blown over (hopefully this
> will hold out, seems logical..)
>

No problems. I will try to look into this, during weekend and see what
can be done about this.