From till at mindmeister.com  Mon Apr  6 07:59:28 2009
From: till at mindmeister.com (Till Vollmer)
Date: Mon, 6 Apr 2009 13:59:28 +0200
Subject: [Backgroundrb-devel] Severe Bug with daylight saving time?
In-Reply-To: <fb283d5e0903300531n70a4178r25d29d7db133e824@mail.gmail.com>
References: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>
	<fb283d5e0903300531n70a4178r25d29d7db133e824@mail.gmail.com>
Message-ID: <56A1511D-0154-4E6A-8CE0-220D3397D9C5@mindmeister.com>

Hi,

Did you have time to fix this? Is it mirrored to svn already?

Regards
Till
MindMeister - MeisterLabs GmbH
Till Vollmer
Managing Director
Tel: +49 (0)89 1213 5359
Mob: + 49 (0)160 718 7403
Fax: +49 (0)89 1892 1347
Yahoo ID: till_vollmer
Skype: till_vollmer
www.mindmeister.com


Am 30.03.2009 um 14:31 schrieb hemant:

> On Mon, Mar 30, 2009 at 3:29 PM, Till Vollmer <till at mindmeister.com>  
> wrote:
>> Hi,
>> we have encountered a severe bug in backgroundrb last weekend.
>> On Sunday at 20:00 (EST) backgroundrb launched infinite workers of
>> notification_worker and our server was killed because of memory  
>> consumption.
>> :backgroundrb:
>>   :port: 11006
>>   :ip: 0.0.0.0
>>   :persistent_disabled: true # turn this off if your application  
>> doesn't use
>> backgroundrb's persistent/enqueued tasks system
>>   :persistent_delay: 10 # the time (seconds) between each time  
>> backgroundrb
>> checks the database for enqueued tasks
>> :schedules:
>>   :notification_worker:
>>     :do_it:
>>       :trigger_args: 0 30 */4 * * * *
>> We think that it might be related to daylight saving time.
>> Any hints appreciated.
>
> Were you using reload_on_schedule ?? But yes, the bug do seem like
> triggered by DST, I will be pushing out an update that will contain
> the fix.
>
> BTW, were you able to recover the worker?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090406/58b4adcd/attachment.html>

From backgroundrb at jamespmcgrath.com  Fri Apr 10 03:36:05 2009
From: backgroundrb at jamespmcgrath.com (James McGrath)
Date: Fri, 10 Apr 2009 17:36:05 +1000
Subject: [Backgroundrb-devel] Error running server: Exec format error -
	packet_worker_runner
Message-ID: <88fb60bb0904100036l201f2f8fo66dfe6709014f821@mail.gmail.com>

Hi All, I've been developing a rails app using the Bitnami RailsStack (
http://bitnami.org/stack/rubystack) and it has always worked as advertised.
That is until I have tried to get BackgrounDRB up and running. I have
followed the steps given on the plugin's project page, each seems to work. I
the plugin install works, I can generate workers etc, but when I start the
backgrounDRB server I get the following errors in the backgroundrb log file:

>>/Applications/rubystack-1.4-beta-1/ruby/lib/ruby/gems/1.8/gems/packet-0.1.14/lib/packet/packet_master.rb:116:in
`exec': Exec format error - packet_worker_runner
7:6:log_worker:17:/Volumes/DATA/development/rails/sched/lib/workers:/Volumes/DATA/development/rails/sched/script/load_worker_env
(Errno::ENOEXEC)
>>    from
/Applications/rubystack-1.4-beta-1/ruby/lib/ruby/gems/1.8/gems/packet-0.1.14/lib/packet/packet_master.rb:116:in
`fork_and_load'
>>    from
/Applications/rubystack-1.4-beta-1/ruby/lib/ruby/gems/1.8/gems/packet-0.1.14/lib/packet/packet_master.rb:80:in
`start_worker'
>>    from
/Volumes/DATA/development/rails/sched/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:16:in
`initialize'
>>    from
/Applications/rubystack-1.4-beta-1/ruby/lib/ruby/gems/1.8/gems/packet-0.1.14/lib/packet/packet_master.rb:19:in
`run'
>>    from
/Volumes/DATA/development/rails/sched/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in
`initialize'
>>    from
/Volumes/DATA/development/rails/sched/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:48:in
`new'
>>    from
/Volumes/DATA/development/rails/sched/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:48:in
`start'
>>    from script/backgroundrb:35

In my frustrations I created a rails project from scratch to make sure it
wasn't something in my other code / setup, but I still get the errors.

Has anyone seen this type of error before? If you have and suggestions I
would love to hear them. I really want to get this plugin working as it is
perfect for multiple projects I am working on. BTW: I am running on MacOSX.

Thanks.

P.S: Thanks to all devs who created this plugin - although I am not up and
running yet it looks to be a most useful tool. Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090410/7f46c837/attachment.html>

From woody at crystalcommerce.com  Mon Apr 13 22:45:25 2009
From: woody at crystalcommerce.com (Woody Peterson)
Date: Mon, 13 Apr 2009 19:45:25 -0700
Subject: [Backgroundrb-devel] script/backgroundrb updates
Message-ID: <09B4711E-10C8-4CE2-982D-BEAA4AC354DF@crystalcommerce.com>

I need lsb compliant start/stop scripts so I can successfully use  
things like monit and heartbeat, so I updated backgroundrb's newer  
start/stop module to be more lsb compliant. Specifically, my version  
1) responds to status and restart 2) start cleans the old pidfile in  
case of dead/crased process, and 3) made stop exit 0 if already stopped.

Also, unrelated to lsb compliance but really handy, I moved require  
statements and the environment load to only the start method, so all  
other actions (ex. stop, status) happen immediately without loading  
all of rails.

http://github.com/woahdae/backgroundrb/tree/master

If you're looking to cherry-pick, its in two commits,  
f0b41bc444e48da37e1e1efe45582e15c1163e3d and  
2e9bde9294b020e0589ab4e696db20ef29b6f9d3

Hope this helps someone,

-Woody

From nick at bytemark.co.uk  Fri Apr 24 12:06:58 2009
From: nick at bytemark.co.uk (nick at bytemark.co.uk)
Date: Fri, 24 Apr 2009 17:06:58 +0100
Subject: [Backgroundrb-devel] Greetings
Message-ID: <200904241706.58794.nick@bytemark.co.uk>

My name's Nick, and I work for a company called Bytemark - we use backgroundrb 
in a range of internal projects (all our internal apps are Ruby on Rails, so 
it makes sense). 

Basically, and as I mentioned on IRC, I've been tasked with making 
backgroundrb "better" over the next month or so, and I'd like to push as much 
upstream as I can while I'm at it (although some stuff I can guarantee you 
won't want - I'll my making my own local branch use a login plugin with a 
different syntax, for instance).

First on the agenda is this backtrace: 
 /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb:147:in 
`log': Mysql::Error: MySQL server has gone away: SELECT * FROM 
`bdrb_job_queues`     WHERE ( worker_name = 'dhshell_export_worker' AND taken 
= 0 AND scheduled_at <= '2009-04-24 10:41:44' )  LIMIT 1 FOR UPDATE 
(ActiveRecord::StatementInvalid)
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:302:in 
`execute'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:537:in 
`select'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in 
`select_all_without_query_cache'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:61:in 
`select_all'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/base.rb:586:in 
`find_by_sql'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/base.rb:1345:in 
`find_every'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/base.rb:1307:in 
`find_initial'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/base.rb:538:in 
`find'
from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_job_queue.rb:11:in 
`find_next'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:66:in 
`transaction'
from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/activerecord/lib/active_record/transactions.rb:79:in 
`transaction'
from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_job_queue.rb:8:in 
`find_next'
from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:271:in 
`check_for_enqueued_tasks'
from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:133:in 
`worker_init'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_periodic_event.rb:23:in 
`call'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_periodic_event.rb:23:in 
`run'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:301:in 
`check_for_timer_events'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:301:in 
`each'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:301:in 
`check_for_timer_events'
from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/backgroundrb/server/lib/meta_worker.rb:296:in 
`check_for_timer_events'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:140:in 
`start_reactor'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:139:in 
`loop'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:139:in 
`start_reactor'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_worker.rb:20:in 
`start_worker'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:33:in 
`load_worker'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:26:in 
`initialize'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47:in 
`new'
from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/packet_worker_runner:47
from /usr/bin/packet_worker_runner:19:in `load'
from /usr/bin/packet_worker_runner:19

(not latest git, but definitely git - we're just updating to packet 0.1.15, 
but I doubt that'll affect this particular error) - this kills the server 
from time to time for us (we have our MySQL server set to go away after half 
a day) - it's not the full story, since for that to happen, worker requests 
must have stopped too (or something else), but fixing this is number 1 on my 
list. I've not delved much into the source yet (5pm on a Friday is *not* the 
time to start with that!); I was wondering if you guys have a preferred / 
global strategy for dealing with errors. My approach to the above would be to 
catch the error, and respond by attempting to re-establish the connection. If 
that succeeds, I'd re-do the scheduled item (so the database going away would 
be transparent to the client); if not... hmm. Do we have a method of 
reporting a failed task back to the worker? 

Another problem I was seeing that led me to stop using the backgroundrb cache 
object was that requests into a worker via the MiddleMan API would just 
freeze up from time to time, leaving the Rails controller method hanging on 
for it. That's another one for me to investigate (we weren't using memcached, 
mind, but it annoys me when the Hash - a far simpler system - is less 
reliable).

I'm also tasked with redeploying the current backgroundrb setup - right now, 
we have one server per application using it (which is about 4,5 backgroundrb 
servers in total), with the backgroundrb table stored in the application's 
database. I'm kind of moving towards a scheme where we have a pair of 
backgroundrb servers (transparently load-balanced) used by all applications. 
Each backgroundrb server would have its own separate *SQLite* database. 
Requests would go to one or another of the backgroundrb servers; if one of 
the servers died, all the requests would go to the other server, and 
vice-versa. If possible (I know this is a -devel list), I'd like to get 
comments on whether that's a good setup or not, and suggestions for 
improvement. If not, well, just consider it to be a bit of context ;)

Regards,
-- 
Nick Thomas
Bytemark Hosting Limited

From adam at thewilliams.ws  Fri Apr 24 22:18:24 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Fri, 24 Apr 2009 22:18:24 -0400
Subject: [Backgroundrb-devel] Greetings
In-Reply-To: <200904241706.58794.nick@bytemark.co.uk>
References: <200904241706.58794.nick@bytemark.co.uk>
Message-ID: <C7A605A0-0F4A-4B2C-8BAE-6199630D3487@thewilliams.ws>

Nick, the 'db gone away' thing is a real problem. I ended up with a  
RobustWorker that all our other workers subclass, providing a kind of  
max tries mechanism as well as emails to me when that try count is  
exceeded. I think it would be great to see the library handle this  
more transparently, since before I learned how to handle all this I  
was beginning to think that all the naysayers may have been right  
about backgroundrb.

Adam Williams

On Apr 24, 2009, at 12:06 PM, nick at bytemark.co.uk wrote:

> My name's Nick, and I work for a company called Bytemark - we use  
> backgroundrb
> in a range of internal projects (all our internal apps are Ruby on  
> Rails, so
> it makes sense).
>
> Basically, and as I mentioned on IRC, I've been tasked with making
> backgroundrb "better" over the next month or so, and I'd like to  
> push as much
> upstream as I can while I'm at it (although some stuff I can  
> guarantee you
> won't want - I'll my making my own local branch use a login plugin  
> with a
> different syntax, for instance).
>
> First on the agenda is this backtrace:
> /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/ 
> abstract_adapter.rb:147:in
> `log': Mysql::Error: MySQL server has gone away: SELECT * FROM
> `bdrb_job_queues`     WHERE ( worker_name = 'dhshell_export_worker'  
> AND taken
> = 0 AND scheduled_at <= '2009-04-24 10:41:44' )  LIMIT 1 FOR UPDATE
> (ActiveRecord::StatementInvalid)
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/mysql_adapter.rb: 
> 302:in
> `execute'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/mysql_adapter.rb: 
> 537:in
> `select'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/abstract/ 
> database_statements.rb:7:in
> `select_all_without_query_cache'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/abstract/ 
> query_cache.rb:61:in
> `select_all'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/base.rb:586:in
> `find_by_sql'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/base.rb:1345:in
> `find_every'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/base.rb:1307:in
> `find_initial'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/base.rb:538:in
> `find'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/ 
> backgroundrb/lib/backgroundrb/bdrb_job_queue.rb:11:in
> `find_next'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/connection_adapters/abstract/ 
> database_statements.rb:66:in
> `transaction'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/rails/ 
> activerecord/lib/active_record/transactions.rb:79:in
> `transaction'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/ 
> backgroundrb/lib/backgroundrb/bdrb_job_queue.rb:8:in
> `find_next'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/ 
> backgroundrb/server/lib/meta_worker.rb:271:in
> `check_for_enqueued_tasks'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/ 
> backgroundrb/server/lib/meta_worker.rb:133:in
> `worker_init'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_periodic_event.rb:23:in
> `call'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_periodic_event.rb:23:in
> `run'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:301:in
> `check_for_timer_events'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:301:in
> `each'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:301:in
> `check_for_timer_events'
> from /home/bmrack/bmrack/releases/20090404011130/vendor/plugins/ 
> backgroundrb/server/lib/meta_worker.rb:296:in
> `check_for_timer_events'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:140:in
> `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:139:in
> `loop'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_core.rb:139:in
> `start_reactor'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/ 
> packet_worker.rb:20:in
> `start_worker'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ 
> packet_worker_runner:33:in
> `load_worker'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ 
> packet_worker_runner:26:in
> `initialize'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ 
> packet_worker_runner:47:in
> `new'
> from /usr/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/ 
> packet_worker_runner:47
> from /usr/bin/packet_worker_runner:19:in `load'
> from /usr/bin/packet_worker_runner:19
>
> (not latest git, but definitely git - we're just updating to packet  
> 0.1.15,
> but I doubt that'll affect this particular error) - this kills the  
> server
> from time to time for us (we have our MySQL server set to go away  
> after half
> a day) - it's not the full story, since for that to happen, worker  
> requests
> must have stopped too (or something else), but fixing this is number  
> 1 on my
> list. I've not delved much into the source yet (5pm on a Friday is  
> *not* the
> time to start with that!); I was wondering if you guys have a  
> preferred /
> global strategy for dealing with errors. My approach to the above  
> would be to
> catch the error, and respond by attempting to re-establish the  
> connection. If
> that succeeds, I'd re-do the scheduled item (so the database going  
> away would
> be transparent to the client); if not... hmm. Do we have a method of
> reporting a failed task back to the worker?
>
> Another problem I was seeing that led me to stop using the  
> backgroundrb cache
> object was that requests into a worker via the MiddleMan API would  
> just
> freeze up from time to time, leaving the Rails controller method  
> hanging on
> for it. That's another one for me to investigate (we weren't using  
> memcached,
> mind, but it annoys me when the Hash - a far simpler system - is less
> reliable).
>
> I'm also tasked with redeploying the current backgroundrb setup -  
> right now,
> we have one server per application using it (which is about 4,5  
> backgroundrb
> servers in total), with the backgroundrb table stored in the  
> application's
> database. I'm kind of moving towards a scheme where we have a pair of
> backgroundrb servers (transparently load-balanced) used by all  
> applications.
> Each backgroundrb server would have its own separate *SQLite*  
> database.
> Requests would go to one or another of the backgroundrb servers; if  
> one of
> the servers died, all the requests would go to the other server, and
> vice-versa. If possible (I know this is a -devel list), I'd like to  
> get
> comments on whether that's a good setup or not, and suggestions for
> improvement. If not, well, just consider it to be a bit of context ;)
>
> Regards,
> -- 
> Nick Thomas
> Bytemark Hosting Limited
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

From diego.gaitan at gmail.com  Mon Apr 27 11:14:54 2009
From: diego.gaitan at gmail.com (=?ISO-8859-1?Q?Diego_Gait=E1n?=)
Date: Mon, 27 Apr 2009 10:14:54 -0500
Subject: [Backgroundrb-devel] Problem with backgroundrb and rails 2
Message-ID: <b61cc1a90904270814s78f221a2w8508e973f82fa97d@mail.gmail.com>

Hi,

I just moved a project from rails 1.2.6 to rails 2.2.2 and
backgroundrb started to show this error:

Mysql::Error: MySQL server has gone away:
SHOW FIELDS FROM `credit_cards`

Any idea? I am searching for a fix online but I have not found anything yet.

I am running my application on Ubuntu Hardy 8.04

Thanks,
Diego

From diego.gaitan at gmail.com  Mon Apr 27 13:16:03 2009
From: diego.gaitan at gmail.com (=?ISO-8859-1?Q?Diego_Gait=E1n?=)
Date: Mon, 27 Apr 2009 12:16:03 -0500
Subject: [Backgroundrb-devel] Problem with backgroundrb and rails 2
In-Reply-To: <fb283d5e0904270915x32d1a07sb147e2cf8eb55b19@mail.gmail.com>
References: <b61cc1a90904270814s78f221a2w8508e973f82fa97d@mail.gmail.com>
	<fb283d5e0904270915x32d1a07sb147e2cf8eb55b19@mail.gmail.com>
Message-ID: <b61cc1a90904271016q730ebef6m96765dec55c921f3@mail.gmail.com>

Thanks for your response hemant.

Is it mandatory to update the plugin? to make it work? This app is in
production and I would have to test a lot of workers I have running
now.

I am not using packet gem...

Thanks again!

On Mon, Apr 27, 2009 at 11:15 AM, hemant <gethemant at gmail.com> wrote:
> Update the plugin to git master and make sure you are running packet version
> 0.1.15. The problem with Mysql server has gone away should go away.
>
>
>
> On Mon, Apr 27, 2009 at 8:44 PM, Diego Gait?n <diego.gaitan at gmail.com>
> wrote:
>>
>> Hi,
>>
>> I just moved a project from rails 1.2.6 to rails 2.2.2 and
>> backgroundrb started to show this error:
>>
>> Mysql::Error: MySQL server has gone away:
>> SHOW FIELDS FROM `credit_cards`
>>
>> Any idea? I am searching for a fix online but I have not found anything
>> yet.
>>
>> I am running my application on Ubuntu Hardy 8.04
>>
>> Thanks,
>> Diego
>> _______________________________________________
>> 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 d.meyers at lancaster.ac.uk  Mon Apr 27 06:14:24 2009
From: d.meyers at lancaster.ac.uk (Meyers, Dan)
Date: Mon, 27 Apr 2009 11:14:24 +0100
Subject: [Backgroundrb-devel] Exiting worker from within itself
Message-ID: <9FFF610D5DF89A4CAC9CB450C7565663026CFA5D@exchange-be4.lancs.local>

We've got some backgroundrb workers that we want to start at some point
after backgroundrb has been started, and exit as soon as they've
finished their task. The starting works fine and reliably, using:

MiddleMan.new_worker(:worker => worker, :worker_key => jobkey)
MiddleMan.worker(worker, jobkey).async_wrapper(:job_key => jobkey, :arg
=> task.id)

worker and jobkey are both extracted from our database table of jobs to
be run.

When using the previous version of backgroundrb we were just calling
exit at the end of execution in those workers that we wanted to die once
they'd done their work. However this now results in:

Error calling method wrapper with 516 on worker scanner_worker
exit
/usr/data/nac_development/rails/lib/nac_worker.rb:84:in `exit'
/usr/data/nac_development/rails/lib/nac_worker.rb:84:in `wrapper'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:313:in `send'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:313:in `invoke_user_method'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:245:in `process_request'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:219:in `receive_data'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:209:in `receive_internal_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_parser.rb:44:in `extract'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_parser.rb:26:in `loop'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_parser.rb:26:in `extract'
/usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m
eta_worker.rb:207:in `receive_internal_data'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_worker.rb:55:in `handle_internal_messages'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:194:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:192:in `each'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:192:in `handle_read_event'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:146:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:139:in `loop'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_core.rb:139:in `start_reactor'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet
_worker.rb:20:in `start_worker'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner
:33:in `load_worker'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner
:26:in `initialize'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner
:47:in `new'
/usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner
:47
/usr/local/bin/packet_worker_runner:19:in `load'
/usr/local/bin/packet_worker_runner:19

After some checking online, we tried moving to using:

MiddleMan.worker(worker_name, job_key).delete

at the end of the worker after it had finished all work. This seems to
work, but only about half the time. Sometimes the worker process will
die, and can no longer be seen in the process list, but sometimes it
continues to sit there after the worker has finished doing all it's
work. If the worker is re-run using the same job key it will run fine
again using the same process and the process will sometimes then be
removed correctly, but of course the expected operation on our live
system is that a lot of these workers will never be run twice with the
same job key, as we want the ability to run many concurrently. As such
we would end up with hundreds of erroneous worker processes from
backgroundrb. We never used to get unkilled workers using the old
version of backgroundrb, so I feel safe in assuming this is some issue
with the delete method rather than our worker's code.

I am assuming that I am doing something wrong in my deletion here. What
should I be doing to reliably exit/kill a worker from within itself once
it has finied executing it's designated task?

Thanks in advance.

--
Dan Meyers
Network Specialist, Lancaster University
E-Mail: d.meyers at lancaster.ac.uk



From diego.gaitan at gmail.com  Mon Apr 27 17:38:58 2009
From: diego.gaitan at gmail.com (=?ISO-8859-1?Q?Diego_Gait=E1n?=)
Date: Mon, 27 Apr 2009 16:38:58 -0500
Subject: [Backgroundrb-devel] Problem with backgroundrb and rails 2
In-Reply-To: <fb283d5e0904271043m753fd5abp649542cd91c29e42@mail.gmail.com>
References: <b61cc1a90904270814s78f221a2w8508e973f82fa97d@mail.gmail.com>
	<fb283d5e0904270915x32d1a07sb147e2cf8eb55b19@mail.gmail.com>
	<b61cc1a90904271016q730ebef6m96765dec55c921f3@mail.gmail.com>
	<fb283d5e0904271043m753fd5abp649542cd91c29e42@mail.gmail.com>
Message-ID: <b61cc1a90904271438o70488863l2fb1e422b14fb59f@mail.gmail.com>

maybe a silly question but... how do I know which version of the
plugin I am using?

I am not using packet gem.

On Mon, Apr 27, 2009 at 12:43 PM, hemant <gethemant at gmail.com> wrote:
> You are not using packet gem? Are you using old version of plugin? If thats
> the case, newer versions of ActiveRecord has one option called "reconnect" =
> true
>
> http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/MysqlAdapter.html
>
>
>
>
> On Mon, Apr 27, 2009 at 10:46 PM, Diego Gait?n <diego.gaitan at gmail.com>
> wrote:
>>
>> Thanks for your response hemant.
>>
>> Is it mandatory to update the plugin? to make it work? This app is in
>> production and I would have to test a lot of workers I have running
>> now.
>>
>> I am not using packet gem...
>>
>> Thanks again!
>>
>> On Mon, Apr 27, 2009 at 11:15 AM, hemant <gethemant at gmail.com> wrote:
>> > Update the plugin to git master and make sure you are running packet
>> > version
>> > 0.1.15. The problem with Mysql server has gone away should go away.
>> >
>> >
>> >
>> > On Mon, Apr 27, 2009 at 8:44 PM, Diego Gait?n <diego.gaitan at gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I just moved a project from rails 1.2.6 to rails 2.2.2 and
>> >> backgroundrb started to show this error:
>> >>
>> >> Mysql::Error: MySQL server has gone away:
>> >> SHOW FIELDS FROM `credit_cards`
>> >>
>> >> Any idea? I am searching for a fix online but I have not found anything
>> >> yet.
>> >>
>> >> I am running my application on Ubuntu Hardy 8.04
>> >>
>> >> Thanks,
>> >> Diego
>> >> _______________________________________________
>> >> 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
>> >
>
>
>
> --
> 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 toastkid.williams at gmail.com  Tue Apr 28 04:32:27 2009
From: toastkid.williams at gmail.com (Max Williams)
Date: Tue, 28 Apr 2009 09:32:27 +0100
Subject: [Backgroundrb-devel] how to know when backgroundrb server die
In-Reply-To: <AF950A3A-1FC5-4A0C-82F4-B2D849D6B062@2be.ca>
References: <AF950A3A-1FC5-4A0C-82F4-B2D849D6B062@2be.ca>
Message-ID: <f1b194900904280132i72892aecya9b386aac7020b3a@mail.gmail.com>

Getting something to monitor itself and tell you when it dies is always
going to be prone to failure, for obvious reasons.  We use Monit for this
sort of thing - if a process dies it sends a notification and then restarts
it.

http://mmonit.com/monit/

2009/4/27 Pelletier Carl <carl at 2be.ca>

> Hi, I am running a backgroundrb server and would like to known, what is the
> best way of knowing when the backgroundrb dies?
> What I am doing is that my worker run in a big try catch. When the script
> failed, the catch is run. So I can clean my stuff, send my alert email and
> exit.
>
> For testing purpose, i manually kill backgroundrb to see how my script
> react. This working well, but the Exception send by backgroundrb is :exit.
>
> What should be the error message when backgroundrb is dead?
> this is the snippet of code:
>
>     rescue Exception => e
>       log.info "[ERROR] | FATAL ERROR"
>       log.info "[ERROR] | #{e.message}" *# The error I got is: exit*
>       log.info "[ERROR] | #{e.backtrace}"
>       log.info "[INFO]  | Sending failure email..."
>
>  SystemMailer.deliver_failure(summary,"FAILURE","#{File.join(LOG_PATH,name)}")
>       persistent_job.finish!
>     end
>
> this is the output in my log file:
>
> Mon Apr 27 10:59:50 -0400 2009 | [ERROR] | FATAL ERROR
> Mon Apr 27 10:59:50 -0400 2009 | [ERROR] | exit
> Mon Apr 27 10:59:50 -0400 2009 | [ERROR] |
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:210:in
> `exit'/opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:210:in
> `shutdown'/opt/local/lib/ruby/gems/1.8/gems/packet-0.1.14/bin/../lib/packet/packet_core.rb:138:in
> `start_reactor'/opt/local/lib/ruby/gems/1.8/gems/activesupport-
> etc...
>
> Thanks
>
> p.S. sorry for bad english...
>
> _______________________________________________
> 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/20090428/5086ca4a/attachment.html>