From akyrho at gmail.com  Thu Mar  5 06:08:24 2009
From: akyrho at gmail.com (=?ISO-8859-1?Q?Bousmanne_C=E9dric?=)
Date: Thu, 5 Mar 2009 12:08:24 +0100
Subject: [Backgroundrb-devel] Problem with packet while running BackgroundRb
Message-ID: <4E727546-F6BC-4B04-9A64-E361B1C8CCDB@gmail.com>

Hi everyone,

I still get into trouble to run Backgroundrb. I got this error while  
running script/backgroundrb start :

no such file to load -- packet_worker_runner (LoadError)

I found a blog post [1] who suggest to rollback to packet 0.1.5 and  
retry, i did, but got this error, this time while backgroundrb runs a  
process :

/opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
activesupport-2.2.2/lib/active_support/dependencies.rb:445:in  
`load_missing_constant': uninitialized constant Packet::BinParser  
(NameError)
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
activesupport-2.2.2/lib/active_support/dependencies.rb:77:in  
`const_missing'
	from /home/antz/declix.com/production/vendor/plugins/backgroundrb/ 
server/lib/master_worker.rb:165:in `post_init'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_connection.rb:21:in `invoke_init'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:302:in `decorate_handler'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:76:in `accept_connection'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:202:in `handle_external_messages'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:178:in `handle_read_event'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:174:in `each'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:174:in `handle_read_event'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:130:in `start_reactor'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:124:in `loop'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_core.rb:124:in `start_reactor'
	from /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/ 
packet-0.1.5/lib/packet/packet_master.rb:21:in `run'
	from /home/antz/site.com/production/vendor/plugins/backgroundrb/ 
server/lib/master_proxy.rb:14:in `initialize'
	from /home/antz/site.com/production/vendor/plugins/backgroundrb/lib/ 
backgroundrb/bdrb_start_stop.rb:50:in `new'
	from /home/antz/site.com/production/vendor/plugins/backgroundrb/lib/ 
backgroundrb/bdrb_start_stop.rb:50:in `start'
	from script/backgroundrb:35

I read almost everything i could about those problems, and i tried  
many times to remove/reinstall backgroundrb, with both version 0.1.5  
and 0.1.14 of packet, without any success...

Can anyone help me?

note : I am running rails v 2.2.2 with the latest svn version of  
backgroundrb

[1] http://mayurjain.wordpress.com/2008/08/08/no-such-file-to-load-log_worker/

From gethemant at gmail.com  Fri Mar  6 05:02:31 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 6 Mar 2009 15:32:31 +0530
Subject: [Backgroundrb-devel] Problem with packet while running
	BackgroundRb
In-Reply-To: <4E727546-F6BC-4B04-9A64-E361B1C8CCDB@gmail.com>
References: <4E727546-F6BC-4B04-9A64-E361B1C8CCDB@gmail.com>
Message-ID: <fb283d5e0903060202x1f81123ft466681288da81539@mail.gmail.com>

Well packet 0.1.5 is VERY old and so is anything you try with that may
not work. Your best bet is to try packet 0.1.14 and bakcgroundrb from
git master.

Try that and let us know if it still doesn't work.


On Thu, Mar 5, 2009 at 4:38 PM, Bousmanne C?dric <akyrho at gmail.com> wrote:
> Hi everyone,
>
> I still get into trouble to run Backgroundrb. I got this error while running
> script/backgroundrb start :
>
> no such file to load -- packet_worker_runner (LoadError)
>
> I found a blog post [1] who suggest to rollback to packet 0.1.5 and retry, i
> did, but got this error, this time while backgroundrb runs a process :
>
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:445:in
> `load_missing_constant': uninitialized constant Packet::BinParser
> (NameError)
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/activesupport-2.2.2/lib/active_support/dependencies.rb:77:in
> `const_missing'
> ? ? ? ?from
> /home/antz/declix.com/production/vendor/plugins/backgroundrb/server/lib/master_worker.rb:165:in
> `post_init'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_connection.rb:21:in
> `invoke_init'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:302:in
> `decorate_handler'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:76:in
> `accept_connection'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:202:in
> `handle_external_messages'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:178:in
> `handle_read_event'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in
> `each'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:174:in
> `handle_read_event'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:130:in
> `start_reactor'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in
> `loop'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_core.rb:124:in
> `start_reactor'
> ? ? ? ?from
> /opt/ruby-enterprise-1.8.6-20090201/lib/ruby/gems/1.8/gems/packet-0.1.5/lib/packet/packet_master.rb:21:in
> `run'
> ? ? ? ?from
> /home/antz/site.com/production/vendor/plugins/backgroundrb/server/lib/master_proxy.rb:14:in
> `initialize'
> ? ? ? ?from
> /home/antz/site.com/production/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in
> `new'
> ? ? ? ?from
> /home/antz/site.com/production/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:50:in
> `start'
> ? ? ? ?from script/backgroundrb:35
>
> I read almost everything i could about those problems, and i tried many
> times to remove/reinstall backgroundrb, with both version 0.1.5 and 0.1.14
> of packet, without any success...
>
> Can anyone help me?
>
> note : I am running rails v 2.2.2 with the latest svn version of
> backgroundrb
>
> [1]
> http://mayurjain.wordpress.com/2008/08/08/no-such-file-to-load-log_worker/
> _______________________________________________
> 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 tov-backgroundrb at overkamp.org  Thu Mar 12 10:43:49 2009
From: tov-backgroundrb at overkamp.org (Tobias Overkamp)
Date: Thu, 12 Mar 2009 15:43:49 +0100
Subject: [Backgroundrb-devel] timeout resp. handling of crash situations
Message-ID: <20090312144349.GA2066@overkamp.org>

Hi,
(hope this is not a double post but I assume I have sent the first
message from the wrong email address).

I'm quite new to BackgroundRB but want to make use of it now in a
project.
One thing I currently don't get (into my mind):

What will happen if a worker (handled by the backgroundrb-Daemon) will
die, crash, halt (perhaps due to power failure or similar things) during
execution?
I want to make use of the "enq_method" call to make sure that no request
will get lost but I can not see any mechanism for a housekeeping after a
crash. Do I miss something or do I have to query the database directly?

Hope this is not an FAQ but I could not find any related queries/answers
on Google etc.

Best regards,

Tobias.



From d-mcclean at ti.com  Thu Mar 12 12:22:43 2009
From: d-mcclean at ti.com (Don McClean)
Date: Thu, 12 Mar 2009 11:22:43 -0500
Subject: [Backgroundrb-devel] Running middleman from console
Message-ID: <49B936D3.5000101@ti.com>

Hi,
I would like to run the MiddleMan code from the console to
check status. I get a cannot find MiddleMan error. What
should I run to load the Backgroundrb code into console?

Thanks in advance,
Don

From jonathan.wallace at gmail.com  Thu Mar 12 13:17:58 2009
From: jonathan.wallace at gmail.com (Jonathan Wallace)
Date: Thu, 12 Mar 2009 13:17:58 -0400
Subject: [Backgroundrb-devel] timeout resp. handling of crash situations
In-Reply-To: <20090312144349.GA2066@overkamp.org>
References: <20090312144349.GA2066@overkamp.org>
Message-ID: <fd0631d50903121017g445d6346mee4e97783db129de@mail.gmail.com>

Hi Tobias,

It sounds like you're looking for a monitoring solution for your
workers.  I know some have used monit but I'm more familiar with god.

http://blog.jonathanrwallace.com/2008/08/monitoring-backgroundrb-workers-with-god/

Good luck,
 Jonathan

On Thu, Mar 12, 2009 at 10:43 AM, Tobias Overkamp
<tov-backgroundrb at overkamp.org> wrote:
> Hi,
> (hope this is not a double post but I assume I have sent the first
> message from the wrong email address).
>
> I'm quite new to BackgroundRB but want to make use of it now in a
> project.
> One thing I currently don't get (into my mind):
>
> What will happen if a worker (handled by the backgroundrb-Daemon) will
> die, crash, halt (perhaps due to power failure or similar things) during
> execution?
> I want to make use of the "enq_method" call to make sure that no request
> will get lost but I can not see any mechanism for a housekeeping after a
> crash. Do I miss something or do I have to query the database directly?
>
> Hope this is not an FAQ but I could not find any related queries/answers
> on Google etc.
>
> Best regards,
>
> Tobias.
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

From gethemant at gmail.com  Thu Mar 12 13:55:12 2009
From: gethemant at gmail.com (hemant)
Date: Thu, 12 Mar 2009 23:25:12 +0530
Subject: [Backgroundrb-devel] Running middleman from console
In-Reply-To: <49B936D3.5000101@ti.com>
References: <49B936D3.5000101@ti.com>
Message-ID: <fb283d5e0903121055v99a7509t74044b21eb26142d@mail.gmail.com>

If you start rails console, you should have access to MiddleMan proxy
object and you can execute all usual methods from it.


On Thu, Mar 12, 2009 at 9:52 PM, Don McClean <d-mcclean at ti.com> wrote:
> Hi,
> I would like to run the MiddleMan code from the console to
> check status. I get a cannot find MiddleMan error. What
> should I run to load the Backgroundrb code into console?
>
> Thanks in advance,
> Don
> _______________________________________________
> 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 12 13:57:33 2009
From: gethemant at gmail.com (hemant)
Date: Thu, 12 Mar 2009 23:27:33 +0530
Subject: [Backgroundrb-devel] timeout resp. handling of crash situations
In-Reply-To: <20090312144349.GA2066@overkamp.org>
References: <20090312144349.GA2066@overkamp.org>
Message-ID: <fb283d5e0903121057m57dcefy9fd3e6096f4af305@mail.gmail.com>

On Thu, Mar 12, 2009 at 8:13 PM, Tobias Overkamp
<tov-backgroundrb at overkamp.org> wrote:
> Hi,
> (hope this is not a double post but I assume I have sent the first
> message from the wrong email address).
>
> I'm quite new to BackgroundRB but want to make use of it now in a
> project.
> One thing I currently don't get (into my mind):
>
> What will happen if a worker (handled by the backgroundrb-Daemon) will
> die, crash, halt (perhaps due to power failure or similar things) during
> execution?
> I want to make use of the "enq_method" call to make sure that no request
> will get lost but I can not see any mechanism for a housekeeping after a
> crash. Do I miss something or do I have to query the database directly?
>

Well if worker crashed for any reason, your unfinished tasks will
remain marked as unfinished  in bdrb_job_queue  table and hence on
restart you can decide what do do with them.

From enzodm at gmail.com  Thu Mar 12 14:07:40 2009
From: enzodm at gmail.com (Samer Masry)
Date: Thu, 12 Mar 2009 11:07:40 -0700
Subject: [Backgroundrb-devel] Running middleman from console
In-Reply-To: <fb283d5e0903121055v99a7509t74044b21eb26142d@mail.gmail.com>
References: <49B936D3.5000101@ti.com>
	<fb283d5e0903121055v99a7509t74044b21eb26142d@mail.gmail.com>
Message-ID: <c9517bd80903121107x342fd49cx1d50e434695442cc@mail.gmail.com>

Use `MiddleMan.all_worker_info`  to see all the worker info.  If you are
still receiving an error please post it.

On Thu, Mar 12, 2009 at 10:55 AM, hemant <gethemant at gmail.com> wrote:

> If you start rails console, you should have access to MiddleMan proxy
> object and you can execute all usual methods from it.
>
>
> On Thu, Mar 12, 2009 at 9:52 PM, Don McClean <d-mcclean at ti.com> wrote:
> > Hi,
> > I would like to run the MiddleMan code from the console to
> > check status. I get a cannot find MiddleMan error. What
> > should I run to load the Backgroundrb code into console?
> >
> > Thanks in advance,
> > Don
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
>
>
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090312/ab73c8c1/attachment-0001.html>

From d-mcclean at ti.com  Thu Mar 12 14:09:07 2009
From: d-mcclean at ti.com (Don McClean)
Date: Thu, 12 Mar 2009 13:09:07 -0500
Subject: [Backgroundrb-devel] Running middleman from console
In-Reply-To: <c9517bd80903121107x342fd49cx1d50e434695442cc@mail.gmail.com>
References: <49B936D3.5000101@ti.com>	
	<fb283d5e0903121055v99a7509t74044b21eb26142d@mail.gmail.com>
	<c9517bd80903121107x342fd49cx1d50e434695442cc@mail.gmail.com>
Message-ID: <49B94FC3.1060905@ti.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090312/2ab54764/attachment.html>

From tov-backgroundrb at overkamp.org  Thu Mar 12 16:11:40 2009
From: tov-backgroundrb at overkamp.org (Tobias Overkamp)
Date: Thu, 12 Mar 2009 21:11:40 +0100
Subject: [Backgroundrb-devel] timeout resp. handling of crash situations
In-Reply-To: <fb283d5e0903121057m57dcefy9fd3e6096f4af305@mail.gmail.com>
References: <20090312144349.GA2066@overkamp.org>
	<fb283d5e0903121057m57dcefy9fd3e6096f4af305@mail.gmail.com>
Message-ID: <CC60400B-74ED-4BFF-BE1B-C7E990B7D045@overkamp.org>


Am 12.03.2009 um 18:57 schrieb hemant:

> On Thu, Mar 12, 2009 at 8:13 PM, Tobias Overkamp
> <tov-backgroundrb at overkamp.org> wrote:
>> [...]
>> I want to make use of the "enq_method" call to make sure that no  
>> request
>> will get lost but I can not see any mechanism for a housekeeping  
>> after a
>> crash. Do I miss something or do I have to query the database  
>> directly?
>>
>
> Well if worker crashed for any reason, your unfinished tasks will
> remain marked as unfinished  in bdrb_job_queue  table and hence on
> restart you can decide what do do with them.

Hi,
but do you have any suggestion how to do this via backgroundrb?
If I understand it correctly, it seems that a "taken" job will remain  
into this state until I finish it (using the finished method) or I  
perform an SQL update. Of course the SQL wouldn't be that hard but I  
was just searching for an already implemented feature in backgroundrb.
Jonathan Wallace has just recommended me to use "god" as a supervising  
daemon for backgroundrb (thanks for this, btw. :-) ). This will make  
sure that the workers keep running after crashes, but will it clean up  
the taken jobs?

Don't get me wrong: I think I'll find a solution for tidying up (and  
of course I hope that my server will not crash that often) but somehow  
I have the feeling that this functionality should be part of  
backgroundrb.


Regards,
Tobias.

From d-mcclean at ti.com  Thu Mar 12 17:44:41 2009
From: d-mcclean at ti.com (Don McClean)
Date: Thu, 12 Mar 2009 16:44:41 -0500
Subject: [Backgroundrb-devel] 2nd job submitted never runs
Message-ID: <49B98249.3010602@ti.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090312/d33cdc4f/attachment.html>

From justin.wood at trifectagis.com  Fri Mar 13 00:22:56 2009
From: justin.wood at trifectagis.com (Justin Wood)
Date: Fri, 13 Mar 2009 17:22:56 +1300
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
Message-ID: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>

Hi, All

It appears that when you enque a task, backgroundrb doesn't pass the "arg"
parameter when running the enqued method.

This is my worker:

class NotificationWorker < BackgrounDRb::MetaWorker
  set_worker_name :notification_worker

 def create(args = nil)
   logger.info("Args: #{args}")
 end

  def send_warranty_notice(data)
      logger.info "Sending warranty notice id is #{data}"
  end
end

Here's how I call it from IRB

MiddleMan.worker(:notification_worker).enq_send_warranty_notice(:arg=>"asdf",:job_key=>Time.now.to_s,:scheduled_at
=> Time.now + 3.seconds)

The "send_warranty_notice" method gets called but the parameter passed
(data) is nil.


Calling async_method works fine:

MiddleMan.worker(:notification_worker).async_send_warranty_notice(:arg=>"asdf")

prints out "Sending warranty notice id is asdf" in the drb log.

Also I noticed that on the following page
http://backgroundrb.rubyforge.org/workers/ the following text

MiddleMan(:hello_worker).enq_some_task(:arg => "hello_world",:job_key => "boy")

should read

MiddleMan.worker(:hello_worker).enq_some_task(:arg =>
"hello_world",:job_key => "boy")  ... unless I am missing something?


Any suggestions on how I can fix the arg passing problem?


Regards
Justin Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090313/c0e75852/attachment.html>

From enzodm at gmail.com  Fri Mar 13 00:55:54 2009
From: enzodm at gmail.com (Samer Masry)
Date: Thu, 12 Mar 2009 21:55:54 -0700
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
Message-ID: <B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>

Here's the usage
When creating a worker the :create method gets called with args you  
pass this  in with the :data argument to new_worker

MiddleMan.new_worker( :worker => :notification_worker, :worker_key =>  
'test', :data => "some argument" )

a bit confusing on the names but it is documented.  The create method  
says args even though you pass it in as data

When sending args to your method after you worker is created use  
something like

MiddleMan.worker( :notification_worker, 'test').enq_some_task( :arg =>  
"some argument" )

Hope that helps

Samer Masry
www.dryblis.com

On Mar 12, 2009, at 9:22 PM, Justin Wood wrote:

> Hi, All
>
> It appears that when you enque a task, backgroundrb doesn't pass the  
> "arg" parameter when running the enqued method.
>
> This is my worker:
>
> class NotificationWorker < BackgrounDRb::MetaWorker
>   set_worker_name :notification_worker
>
>  def create(args = nil)
>    logger.info("Args: #{args}")
>  end
>
>   def send_warranty_notice(data)
>       logger.info "Sending warranty notice id is #{data}"
>   end
> end
>
> Here's how I call it from IRB
>
> MiddleMan 
> .worker 
> (:notification_worker 
> ).enq_send_warranty_notice 
> (:arg=>"asdf",:job_key=>Time.now.to_s,:scheduled_at => Time.now +  
> 3.seconds)
>
> The "send_warranty_notice" method gets called but the parameter  
> passed (data) is nil.
>
>
> Calling async_method works fine:
>
> MiddleMan 
> .worker(:notification_worker).async_send_warranty_notice(:arg=>"asdf")
>
> prints out "Sending warranty notice id is asdf" in the drb log.
>
> Also I noticed that on the following page  http://backgroundrb.rubyforge.org/workers/ 
>  the following text
> MiddleMan(:hello_worker).enq_some_task(:arg =>  
> "hello_world",:job_key => "boy")
>
> should read
>
> MiddleMan.worker(:hello_worker).enq_some_task(:arg =>  
> "hello_world",:job_key => "boy")  ... unless I am missing something?
>
>
>
> Any suggestions on how I can fix the arg passing problem?
>
>
> Regards
> Justin Wood
>
>
>
>
>
>
> _______________________________________________
> 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/20090312/1fd54ca0/attachment.html>

From justin.wood at trifectagis.com  Fri Mar 13 02:27:05 2009
From: justin.wood at trifectagis.com (Justin Wood)
Date: Fri, 13 Mar 2009 19:27:05 +1300
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
	<B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
Message-ID: <95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>

Hi, Samer

Thanks for the quick reply.   I changed things a bit and ran this

>>
MiddleMan.new_worker(:worker=>:notification_worker,:worker_key=>'testkey',:data=>"data
arguement")
=> "testkey"
>>
MiddleMan.worker(:notification_worker,'testkey').enq_send_warranty_notice(:job_key=>Time.now.to_s,:arg
=> "asdf",:scheduled_at => Time.now + 3.second)
=> true

... but the arg is still not being passed.

My understanding of new_worker is it explictly creates a worker for you that
you can refer to by the key, so

If I do this:

      MiddleMan.worker(:notification_worker,'testkey')

I'm getting the worker I created above but when I call this:

     MiddleMan.worker(:notification_worker)

I'm getting the default worker that was created at startup.

Regardless of how the worker is created the "arg" parameter is still not
being passed when it gets invoked to do enqued work.   Going through the
code ... I can't figure out how it gets invoked.

Thanks
Justin





On Fri, Mar 13, 2009 at 5:55 PM, Samer Masry <enzodm at gmail.com> wrote:

> Here's the usage
> When creating a worker the :create method gets called with args you pass
> this  in with the :data argument to new_worker
>
> MiddleMan.new_worker( :worker => :notification_worker, :worker_key =>
> 'test', :data => "some argument" )
>
> a bit confusing on the names but it is documented.  The create method says
> args even though you pass it in as data
>
> When sending args to your method after you worker is created use something
> like
>
> MiddleMan.worker( :notification_worker, 'test').enq_some_task( :arg =>
> "some argument" )
>
> Hope that helps
> Samer Masry
> www.dryblis.com
>
> On Mar 12, 2009, at 9:22 PM, Justin Wood wrote:
>
> Hi, All
>
> It appears that when you enque a task, backgroundrb doesn't pass the "arg"
> parameter when running the enqued method.
>
> This is my worker:
>
> class NotificationWorker < BackgrounDRb::MetaWorker
>   set_worker_name :notification_worker
>
>  def create(args = nil)
>    logger.info("Args: #{args}")
>  end
>
>   def send_warranty_notice(data)
>       logger.info "Sending warranty notice id is #{data}"
>   end
> end
>
> Here's how I call it from IRB
>
> MiddleMan.worker(:notification_worker).enq_send_warranty_notice(:arg=>"asdf",:job_key=>Time.now.to_s,:scheduled_at
> => Time.now + 3.seconds)
>
> The "send_warranty_notice" method gets called but the parameter passed
> (data) is nil.
>
>
> Calling async_method works fine:
>
>
> MiddleMan.worker(:notification_worker).async_send_warranty_notice(:arg=>"asdf")
>
> prints out "Sending warranty notice id is asdf" in the drb log.
>
> Also I noticed that on the following page
> http://backgroundrb.rubyforge.org/workers/ the following text
>
> MiddleMan(:hello_worker).enq_some_task(:arg => "hello_world",:job_key => "boy")
>
> should read
>
> MiddleMan.worker(:hello_worker).enq_some_task(:arg => "hello_world",:job_key => "boy")  ... unless I am missing something?
>
>
> Any suggestions on how I can fix the arg passing problem?
>
>
> Regards
> Justin Wood
>
>
>
>
>
>
> _______________________________________________
> 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/20090313/8659213c/attachment-0001.html>

From gethemant at gmail.com  Fri Mar 13 03:58:42 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 13 Mar 2009 13:28:42 +0530
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
	<B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
	<95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>
Message-ID: <fb283d5e0903130058h2394e362we93499c0b1874049@mail.gmail.com>

On Fri, Mar 13, 2009 at 11:57 AM, Justin Wood
<justin.wood at trifectagis.com> wrote:
> Hi, Samer
>
> Thanks for the quick reply.?? I changed things a bit and ran this
>
>>>
>>> MiddleMan.new_worker(:worker=>:notification_worker,:worker_key=>'testkey',:data=>"data
>>> arguement")
> => "testkey"
>>>
>>> MiddleMan.worker(:notification_worker,'testkey').enq_send_warranty_notice(:job_key=>Time.now.to_s,:arg
>>> => "asdf",:scheduled_at => Time.now + 3.second)
> => true
>
> ... but the arg is still not being passed.
>
> My understanding of new_worker is it explictly creates a worker for you that
> you can refer to by the key, so
>
> If I do this:
>
> ????? MiddleMan.worker(:notification_worker,'testkey')
>
> I'm getting the worker I created above but when?I call this:
>
> ???? MiddleMan.worker(:notification_worker)
>
> I'm getting the default worker that was created at startup.
>
> Regardless of how the worker is created the "arg" parameter is still not
> being passed when it gets invoked to do enqued work.?? Going through the
> code ... I can't figure out how it gets invoked.
>

Well whatever you pass to enq_xxx method gets marshalled to database
and gets unmarshalled from table when the task is scheduled inside
worker. Can you paste your worker code?

From gethemant at gmail.com  Fri Mar 13 15:34:04 2009
From: gethemant at gmail.com (hemant)
Date: Sat, 14 Mar 2009 01:04:04 +0530
Subject: [Backgroundrb-devel] 2nd job submitted never runs
In-Reply-To: <49B98249.3010602@ti.com>
References: <49B98249.3010602@ti.com>
Message-ID: <fb283d5e0903131234p68733fecwf0452bf99e1dbdf8@mail.gmail.com>

2009/3/13 Don McClean <d-mcclean at ti.com>:
> I am using backgroundrb with rails and have a problem if I submit two jobs
> to be handled and the 2nd job is submitted before the first job is complete.
> The 2nd job is never worked on, although in the database table, it is marked
> as
> taken.
>
> I have a single worker which is created at rails startup. I am enquing the
> task. I had thought the
> the 2nd job would be in a queue and would be worked on after
> the first job is done. Am I wrong? Do I need to create a pool?
>
> I am using Oracle with rails 2.1.2
>
> I set the allow_concurrency = false
> in the 3 places I found it set to true in the backgroundrb code, per
> the FAQ, but it did not seem to matter.
>

Unforunately, I never had opportunity to test job queues with Oracle
DB. Your best bet is to test your code with sqlite/mysql and see if
you are still having the problem. However if 2nd job never ran it
sounds like a problem with the code of first job that blocked the
worker forever. Can you paste your worker code?

From d-mcclean at ti.com  Fri Mar 13 15:38:37 2009
From: d-mcclean at ti.com (Don McClean)
Date: Fri, 13 Mar 2009 14:38:37 -0500
Subject: [Backgroundrb-devel] 2nd job submitted never runs
In-Reply-To: <fb283d5e0903131234p68733fecwf0452bf99e1dbdf8@mail.gmail.com>
References: <49B98249.3010602@ti.com>
	<fb283d5e0903131234p68733fecwf0452bf99e1dbdf8@mail.gmail.com>
Message-ID: <49BAB63D.2080807@ti.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090313/b00db631/attachment.html>

From justin.wood at trifectagis.com  Fri Mar 13 18:07:57 2009
From: justin.wood at trifectagis.com (Justin Wood)
Date: Sat, 14 Mar 2009 11:07:57 +1300
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <fb283d5e0903130058h2394e362we93499c0b1874049@mail.gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
	<B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
	<95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>
	<fb283d5e0903130058h2394e362we93499c0b1874049@mail.gmail.com>
Message-ID: <95a868280903131507u3461d468l4496adbe24363be6@mail.gmail.com>

Hi, Hemant

Ah ok.   Found out where it was making the call in in meta_worker and saw
the args coming back nil from load_data.   So I ran this in IRB

>> job=BdrbJobQueue.find(:first,:conditions => [" worker_name = ? AND taken
= ? AND scheduled_at <= ? ", "notification_worker", 0, Time.now.utc ])
=> #<BdrbJobQueue id: 53, args: "\\004\\010\"\\011asdf", worker_name:
"notification_worker", worker_method: "asdf", job_key: "Fri Mar 13 16:14:48
+1300 2009", taken: 0, finished: 0, timeout: nil, priority: nil,
submitted_at: "2009-03-13 03:14:48", started_at: nil, finished_at: nil,
archived_at: nil, tag: nil, submitter_info: nil, runner_info: nil,
worker_key: "", scheduled_at: "2009-03-13 03:14:51">
>> job.args
=> "\\004\\010\"\\011asdf"
>> Marshal.load(job.args)
TypeError: incompatible marshal file format (can't be read)
        format version 4.8 required; 92.48 given
        from (irb):10:in `load'
        from (irb):10

So the problem is with marshalling ... double checked that by putting a
logger statement into BdrbServerHelper's load_data like so:

...
rescue
        error_msg = $!.message
        logger.error("Error marshaling data:  #{data}  #{error_msg})
#added
        if error_msg =~ /^undefined\ .+\ ([A-Z].+)/
....

and got the same error message.   Having something going to the log in the
rescue there would be a useful addition.

I'm using Postgres 8.3.1 (database in utf8) on Ubuntu found someone else
that encountered a marshalling error here:

http://blade.nagaokaut.ac.jp/ruby/ruby-talk/116099

Looks like a ruby/Postgres issue?    I'll have a look see if I can sort this
out but any advice you could give me would be much appreciated.

Thanks
Justin


On Fri, Mar 13, 2009 at 8:58 PM, hemant <gethemant at gmail.com> wrote:

> On Fri, Mar 13, 2009 at 11:57 AM, Justin Wood
> <justin.wood at trifectagis.com> wrote:
> > Hi, Samer
> >
> > Thanks for the quick reply.   I changed things a bit and ran this
> >
> >>>
> >>>
> MiddleMan.new_worker(:worker=>:notification_worker,:worker_key=>'testkey',:data=>"data
> >>> arguement")
> > => "testkey"
> >>>
> >>>
> MiddleMan.worker(:notification_worker,'testkey').enq_send_warranty_notice(:job_key=>Time.now.to_s,:arg
> >>> => "asdf",:scheduled_at => Time.now + 3.second)
> > => true
> >
> > ... but the arg is still not being passed.
> >
> > My understanding of new_worker is it explictly creates a worker for you
> that
> > you can refer to by the key, so
> >
> > If I do this:
> >
> >       MiddleMan.worker(:notification_worker,'testkey')
> >
> > I'm getting the worker I created above but when I call this:
> >
> >      MiddleMan.worker(:notification_worker)
> >
> > I'm getting the default worker that was created at startup.
> >
> > Regardless of how the worker is created the "arg" parameter is still not
> > being passed when it gets invoked to do enqued work.   Going through the
> > code ... I can't figure out how it gets invoked.
> >
>
> Well whatever you pass to enq_xxx method gets marshalled to database
> and gets unmarshalled from table when the task is scheduled inside
> worker. Can you paste your worker code?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090314/e19cb0b8/attachment.html>

From justin.wood at trifectagis.com  Sat Mar 14 14:43:32 2009
From: justin.wood at trifectagis.com (Justin Wood)
Date: Sun, 15 Mar 2009 07:43:32 +1300
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <95a868280903131507u3461d468l4496adbe24363be6@mail.gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
	<B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
	<95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>
	<fb283d5e0903130058h2394e362we93499c0b1874049@mail.gmail.com>
	<95a868280903131507u3461d468l4496adbe24363be6@mail.gmail.com>
Message-ID: <95a868280903141143k6599f926heeafc9ec5f5ad922@mail.gmail.com>

Hi, All

Appreciate all the assistance, turns out this is a problem resulting from

Rails <= 2.1.1 and Postgres (to do with the way binary fields are escaped)

I upgraded Rails and it works.

Thanks
Justin

On Sat, Mar 14, 2009 at 11:07 AM, Justin Wood
<justin.wood at trifectagis.com>wrote:

> Hi, Hemant
>
> Ah ok.   Found out where it was making the call in in meta_worker and saw
> the args coming back nil from load_data.   So I ran this in IRB
>
> >> job=BdrbJobQueue.find(:first,:conditions => [" worker_name = ? AND taken
> = ? AND scheduled_at <= ? ", "notification_worker", 0, Time.now.utc ])
> => #<BdrbJobQueue id: 53, args: "\\004\\010\"\\011asdf", worker_name:
> "notification_worker", worker_method: "asdf", job_key: "Fri Mar 13 16:14:48
> +1300 2009", taken: 0, finished: 0, timeout: nil, priority: nil,
> submitted_at: "2009-03-13 03:14:48", started_at: nil, finished_at: nil,
> archived_at: nil, tag: nil, submitter_info: nil, runner_info: nil,
> worker_key: "", scheduled_at: "2009-03-13 03:14:51">
> >> job.args
> => "\\004\\010\"\\011asdf"
> >> Marshal.load(job.args)
> TypeError: incompatible marshal file format (can't be read)
>         format version 4.8 required; 92.48 given
>         from (irb):10:in `load'
>         from (irb):10
>
> So the problem is with marshalling ... double checked that by putting a
> logger statement into BdrbServerHelper's load_data like so:
>
> ...
> rescue
>         error_msg = $!.message
>         logger.error("Error marshaling data:  #{data}  #{error_msg})
> #added
>         if error_msg =~ /^undefined\ .+\ ([A-Z].+)/
> ....
>
> and got the same error message.   Having something going to the log in the
> rescue there would be a useful addition.
>
> I'm using Postgres 8.3.1 (database in utf8) on Ubuntu found someone else
> that encountered a marshalling error here:
>
> http://blade.nagaokaut.ac.jp/ruby/ruby-talk/116099
>
> Looks like a ruby/Postgres issue?    I'll have a look see if I can sort
> this out but any advice you could give me would be much appreciated.
>
> Thanks
> Justin
>
>
>
> On Fri, Mar 13, 2009 at 8:58 PM, hemant <gethemant at gmail.com> wrote:
>
>> On Fri, Mar 13, 2009 at 11:57 AM, Justin Wood
>> <justin.wood at trifectagis.com> wrote:
>> > Hi, Samer
>> >
>> > Thanks for the quick reply.   I changed things a bit and ran this
>> >
>> >>>
>> >>>
>> MiddleMan.new_worker(:worker=>:notification_worker,:worker_key=>'testkey',:data=>"data
>> >>> arguement")
>> > => "testkey"
>> >>>
>> >>>
>> MiddleMan.worker(:notification_worker,'testkey').enq_send_warranty_notice(:job_key=>Time.now.to_s,:arg
>> >>> => "asdf",:scheduled_at => Time.now + 3.second)
>> > => true
>> >
>> > ... but the arg is still not being passed.
>> >
>> > My understanding of new_worker is it explictly creates a worker for you
>> that
>> > you can refer to by the key, so
>> >
>> > If I do this:
>> >
>> >       MiddleMan.worker(:notification_worker,'testkey')
>> >
>> > I'm getting the worker I created above but when I call this:
>> >
>> >      MiddleMan.worker(:notification_worker)
>> >
>> > I'm getting the default worker that was created at startup.
>> >
>> > Regardless of how the worker is created the "arg" parameter is still not
>> > being passed when it gets invoked to do enqued work.   Going through the
>> > code ... I can't figure out how it gets invoked.
>> >
>>
>> Well whatever you pass to enq_xxx method gets marshalled to database
>> and gets unmarshalled from table when the task is scheduled inside
>> worker. Can you paste your worker code?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090315/cd5929cd/attachment-0001.html>

From gethemant at gmail.com  Sat Mar 14 15:03:53 2009
From: gethemant at gmail.com (hemant)
Date: Sun, 15 Mar 2009 00:33:53 +0530
Subject: [Backgroundrb-devel] enq_method doesn't pass 'arg'
In-Reply-To: <95a868280903141143k6599f926heeafc9ec5f5ad922@mail.gmail.com>
References: <95a868280903122122p514da6f8wdd50572042498019@mail.gmail.com>
	<B6B832AB-8DB6-449B-9779-C34EC87974ED@gmail.com>
	<95a868280903122327u47a1b7bsebfdcaa03c018d88@mail.gmail.com>
	<fb283d5e0903130058h2394e362we93499c0b1874049@mail.gmail.com>
	<95a868280903131507u3461d468l4496adbe24363be6@mail.gmail.com>
	<95a868280903141143k6599f926heeafc9ec5f5ad922@mail.gmail.com>
Message-ID: <fb283d5e0903141203g1a14574aq4f13ab964d4fc52c@mail.gmail.com>

Ah,

We can put this in FAQ.


2009/3/15 Justin Wood <justin.wood at trifectagis.com>:
> Hi, All
>
> Appreciate all the assistance, turns out this is a problem resulting from
>
> Rails <= 2.1.1 and Postgres (to do with the way binary fields are escaped)
>
> I upgraded Rails and it works.
>
> Thanks
> Justin
>
> On Sat, Mar 14, 2009 at 11:07 AM, Justin Wood <justin.wood at trifectagis.com>
> wrote:
>>
>> Hi, Hemant
>>
>> Ah ok.?? Found out where it was making the call in in meta_worker and saw
>> the args coming back nil from load_data.?? So I ran this in IRB
>>
>> >> job=BdrbJobQueue.find(:first,:conditions => [" worker_name = ? AND
>> >> taken = ? AND scheduled_at <= ? ", "notification_worker", 0, Time.now.utc ])
>> => #<BdrbJobQueue id: 53, args: "\\004\\010\"\\011asdf", worker_name:
>> "notification_worker", worker_method: "asdf", job_key: "Fri Mar 13 16:14:48
>> +1300 2009", taken: 0, finished: 0, timeout: nil, priority: nil,
>> submitted_at: "2009-03-13 03:14:48", started_at: nil, finished_at: nil,
>> archived_at: nil, tag: nil, submitter_info: nil, runner_info: nil,
>> worker_key: "", scheduled_at: "2009-03-13 03:14:51">
>> >> job.args
>> => "\\004\\010\"\\011asdf"
>> >> Marshal.load(job.args)
>> TypeError: incompatible marshal file format (can't be read)
>> ??????? format version 4.8 required; 92.48 given
>> ??????? from (irb):10:in `load'
>> ??????? from (irb):10
>>
>> So the problem is with marshalling ... double checked that by putting a
>> logger statement into BdrbServerHelper's load_data like so:
>>
>> ...
>> rescue
>> ??????? error_msg = $!.message
>> ??????? logger.error("Error marshaling data:? #{data}? #{error_msg})
>> #added
>> ??????? if error_msg =~ /^undefined\ .+\ ([A-Z].+)/
>> ....
>>
>> and got the same error message.?? Having something going to the log in the
>> rescue there would be a useful addition.
>>
>> I'm using Postgres 8.3.1 (database in utf8) on Ubuntu found someone else
>> that encountered a marshalling error here:
>>
>> http://blade.nagaokaut.ac.jp/ruby/ruby-talk/116099
>>
>> Looks like a ruby/Postgres issue? ?? I'll have a look see if I can sort
>> this out but any advice you could give me would be much appreciated.
>>
>> Thanks
>> Justin
>>
>>
>> On Fri, Mar 13, 2009 at 8:58 PM, hemant <gethemant at gmail.com> wrote:
>>>
>>> On Fri, Mar 13, 2009 at 11:57 AM, Justin Wood
>>> <justin.wood at trifectagis.com> wrote:
>>> > Hi, Samer
>>> >
>>> > Thanks for the quick reply.?? I changed things a bit and ran this
>>> >
>>> >>>
>>> >>>
>>> >>> MiddleMan.new_worker(:worker=>:notification_worker,:worker_key=>'testkey',:data=>"data
>>> >>> arguement")
>>> > => "testkey"
>>> >>>
>>> >>>
>>> >>> MiddleMan.worker(:notification_worker,'testkey').enq_send_warranty_notice(:job_key=>Time.now.to_s,:arg
>>> >>> => "asdf",:scheduled_at => Time.now + 3.second)
>>> > => true
>>> >
>>> > ... but the arg is still not being passed.
>>> >
>>> > My understanding of new_worker is it explictly creates a worker for you
>>> > that
>>> > you can refer to by the key, so
>>> >
>>> > If I do this:
>>> >
>>> > ????? MiddleMan.worker(:notification_worker,'testkey')
>>> >
>>> > I'm getting the worker I created above but when?I call this:
>>> >
>>> > ???? MiddleMan.worker(:notification_worker)
>>> >
>>> > I'm getting the default worker that was created at startup.
>>> >
>>> > Regardless of how the worker is created the "arg" parameter is still
>>> > not
>>> > being passed when it gets invoked to do enqued work.?? Going through
>>> > the
>>> > code ... I can't figure out how it gets invoked.
>>> >
>>>
>>> Well whatever you pass to enq_xxx method gets marshalled to database
>>> and gets unmarshalled from table when the task is scheduled inside
>>> worker. Can you paste your worker code?
>>
>
>
> _______________________________________________
> 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 adam at thewilliams.ws  Mon Mar 16 16:44:18 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Mon, 16 Mar 2009 16:44:18 -0400
Subject: [Backgroundrb-devel] Multiple Worker Classes
Message-ID: <4365E7DB-3BBB-452D-BF7E-5E838AF25060@thewilliams.ws>

Hello,

I had multiple worker classes, each set to load once. Some were adding  
periodic executions, some had scheduled work. I've discovered that  
this means there will be a worker process for each class. In an effort  
to get down to just one worker process (memory consumption was  
unaffordable), I have moved ALL work methods into one class. None of  
the methods assign any instance variables. Three of them are run  
periodically, three of them are scheduled.

   def create(args = nil)
     add_periodic_timer(1.minute)  { deliver_reminders }
     add_periodic_timer(2.minutes) { process_emails }
     add_periodic_timer(3.minutes) { deliver_invitations }

   backgroundrb.yml
     :schedules:
       :single_worker:
         :deliver_hub_member_joins:
           :trigger_args: '59 59 23 * * * *'
         :deliver_expiration_reminders:
           :trigger_args: '59 59 23 * * * *'
         :deliver_trial_ending_reminders:
           :trigger_args: '59 59 23 * * * *'

Is there anything I should be aware of with this kind of  
configuration? Anything that I should expect to fail?

On another note, I have the schedules as "59 59 23 * * * *" because  
last weekend backgroundrb began to run "0 0 0 * * * *" as 'every  
second' instead of as 'midnight'. I looked at the tests for the cron  
scheduler code, and there isn't one for "0 0 0 * * * *"; also, most of  
the other cron tests failed too. Worked great for months, then we went  
from -5GMT to -4GMT. Coincidence?

Thanks for a great tool!

   adam

From talksense101 at gmail.com  Tue Mar 17 08:59:44 2009
From: talksense101 at gmail.com (Mukund Rajamannar)
Date: Tue, 17 Mar 2009 18:29:44 +0530
Subject: [Backgroundrb-devel] how does backgroundrb allocate memory to a
	worker?
Message-ID: <41b6ce210903170559h5536ed2dqdef7835ac01a6f8e@mail.gmail.com>

In the Rails environment, does backgroundrb start a separate process (equal
to a mongrel instance) for each worker?  Is there any optimization possible?

My Rails app is rather large and starting backgroundrb consumes too much
memory for 4 workers.

Thanks,
Mukund
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090317/0c6bb17b/attachment.html>

From adam at thewilliams.ws  Tue Mar 17 09:37:45 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Tue, 17 Mar 2009 09:37:45 -0400
Subject: [Backgroundrb-devel] Cron Scheduler
Message-ID: <636B96DE-8D80-4225-923C-AA5F37A4DCD3@thewilliams.ws>

Hello,

I have the schedules as "59 59 23 * * * *" because during the weekend  
of March 9, when our clocks moved forward an hour, backgroundrb began  
to run "0 0 0 * * * *" as 'every second' instead of as 'midnight'. I  
looked at the tests for the cron scheduler code, and there isn't one  
for "0 0 0 * * * *"; also, most of the other cron tests failed too.  
Worked great for months, then we went from -5GMT to -4GMT. Coincidence?

   aiwilliams

From enzodm at gmail.com  Tue Mar 17 12:31:03 2009
From: enzodm at gmail.com (Samer Masry)
Date: Tue, 17 Mar 2009 09:31:03 -0700
Subject: [Backgroundrb-devel] how does backgroundrb allocate memory to a
	worker?
In-Reply-To: <41b6ce210903170559h5536ed2dqdef7835ac01a6f8e@mail.gmail.com>
References: <41b6ce210903170559h5536ed2dqdef7835ac01a6f8e@mail.gmail.com>
Message-ID: <c9517bd80903170931o799a8207y3ce48cfb5467cad3@mail.gmail.com>

You can use set_no_auto_load(http://backgroundrb.rubyforge.org/workers/) so
the worker does not startup automatically.

Samer Masry

2009/3/17 Mukund Rajamannar <talksense101 at gmail.com>

> In the Rails environment, does backgroundrb start a separate process (equal
> to a mongrel instance) for each worker?  Is there any optimization possible?
>
> My Rails app is rather large and starting backgroundrb consumes too much
> memory for 4 workers.
>
> Thanks,
> Mukund
>
>
> _______________________________________________
> 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/20090317/885698a3/attachment.html>

From gethemant at gmail.com  Tue Mar 17 13:09:41 2009
From: gethemant at gmail.com (hemant)
Date: Tue, 17 Mar 2009 22:39:41 +0530
Subject: [Backgroundrb-devel] Multiple Worker Classes
In-Reply-To: <4365E7DB-3BBB-452D-BF7E-5E838AF25060@thewilliams.ws>
References: <4365E7DB-3BBB-452D-BF7E-5E838AF25060@thewilliams.ws>
Message-ID: <fb283d5e0903171009j2071921cx6426402f5acacb4f@mail.gmail.com>

On Tue, Mar 17, 2009 at 2:14 AM, Adam Williams <adam at thewilliams.ws> wrote:
> Hello,
>
> I had multiple worker classes, each set to load once. Some were adding
> periodic executions, some had scheduled work. I've discovered that this
> means there will be a worker process for each class. In an effort to get
> down to just one worker process (memory consumption was unaffordable), I
> have moved ALL work methods into one class. None of the methods assign any
> instance variables. Three of them are run periodically, three of them are
> scheduled.
>
> ?def create(args = nil)
> ? ?add_periodic_timer(1.minute) ?{ deliver_reminders }
> ? ?add_periodic_timer(2.minutes) { process_emails }
> ? ?add_periodic_timer(3.minutes) { deliver_invitations }
>
> ?backgroundrb.yml
> ? ?:schedules:
> ? ? ?:single_worker:
> ? ? ? ?:deliver_hub_member_joins:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
> ? ? ? ?:deliver_expiration_reminders:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
> ? ? ? ?:deliver_trial_ending_reminders:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
>
> Is there anything I should be aware of with this kind of configuration?
> Anything that I should expect to fail?
>

Since you are scheduling all your tasks within same worker, its
possible that some scheduled job that takes more time may not let
other scheduled jobs to run immediately. If this happens, your jobs
will run delayed accordingly.
Hence its advisable to tune time window between various scheduled jobs.



> On another note, I have the schedules as "59 59 23 * * * *" because last
> weekend backgroundrb began to run "0 0 0 * * * *" as 'every second' instead
> of as 'midnight'. I looked at the tests for the cron scheduler code, and
> there isn't one for "0 0 0 * * * *"; also, most of the other cron tests
> failed too. Worked great for months, then we went from -5GMT to -4GMT.
> Coincidence?
>
> Thanks for a great tool!
>
> ?adam
> _______________________________________________
> 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  Tue Mar 17 13:10:30 2009
From: gethemant at gmail.com (hemant)
Date: Tue, 17 Mar 2009 22:40:30 +0530
Subject: [Backgroundrb-devel] Multiple Worker Classes
In-Reply-To: <4365E7DB-3BBB-452D-BF7E-5E838AF25060@thewilliams.ws>
References: <4365E7DB-3BBB-452D-BF7E-5E838AF25060@thewilliams.ws>
Message-ID: <fb283d5e0903171010u3bcae07fg61b2e212ad597c27@mail.gmail.com>

On Tue, Mar 17, 2009 at 2:14 AM, Adam Williams <adam at thewilliams.ws> wrote:
> Hello,
>
> I had multiple worker classes, each set to load once. Some were adding
> periodic executions, some had scheduled work. I've discovered that this
> means there will be a worker process for each class. In an effort to get
> down to just one worker process (memory consumption was unaffordable), I
> have moved ALL work methods into one class. None of the methods assign any
> instance variables. Three of them are run periodically, three of them are
> scheduled.
>
> ?def create(args = nil)
> ? ?add_periodic_timer(1.minute) ?{ deliver_reminders }
> ? ?add_periodic_timer(2.minutes) { process_emails }
> ? ?add_periodic_timer(3.minutes) { deliver_invitations }
>
> ?backgroundrb.yml
> ? ?:schedules:
> ? ? ?:single_worker:
> ? ? ? ?:deliver_hub_member_joins:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
> ? ? ? ?:deliver_expiration_reminders:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
> ? ? ? ?:deliver_trial_ending_reminders:
> ? ? ? ? ?:trigger_args: '59 59 23 * * * *'
>
> Is there anything I should be aware of with this kind of configuration?
> Anything that I should expect to fail?
>
> On another note, I have the schedules as "59 59 23 * * * *" because last
> weekend backgroundrb began to run "0 0 0 * * * *" as 'every second' instead
> of as 'midnight'. I looked at the tests for the cron scheduler code, and
> there isn't one for "0 0 0 * * * *"; also, most of the other cron tests
> failed too. Worked great for months, then we went from -5GMT to -4GMT.
> Coincidence?
>

You might be hitting on a bug. It would be really helpful if you can
minimize a testcase and attach here.

From nicholas.wieland at gmail.com  Wed Mar 18 18:32:09 2009
From: nicholas.wieland at gmail.com (Nicholas Wieland)
Date: Wed, 18 Mar 2009 15:32:09 -0700
Subject: [Backgroundrb-devel] BDRB and Rspec
Message-ID: <bfb46b00903181532m37204f8dgc2d1f1919cb5f13@mail.gmail.com>

Hi guys, I would like to test my worker with RSpec, but till now I'm
not able to understand how to require it and the few references I've
found around doesn't seem to work.

My Spec is more or less like that:


spec/models/contest_worker_spec.rb

describe ContestWorker do

 setup do
   @contest_worker = ContestWorker.new
 end

 it 'should put the contest in incoming state' do
   contest = Contest.create( :title => 'foobar', :start_date =>
2.weeks.from_now, :end_date => 2.months.from_now )
   @contest_worker.state_update
   contest.should be_incoming
 end

end


My worker basically loops over an AR resultset and updates some data,
nothing big.
The point is, I guess, require bdrb and the worker itself
(uninitialized constant ContestWorker), but I don't know how to do it.
Should I require something inside the spec_helper ?

 ngw

From mstone at austin.utexas.edu  Thu Mar 19 10:32:24 2009
From: mstone at austin.utexas.edu (Stone, Matthew A)
Date: Thu, 19 Mar 2009 09:32:24 -0500
Subject: [Backgroundrb-devel] Issue starting backgroundrb server (with
	Oracle)
Message-ID: <C5E7C1A8.2D9B%mstone@austin.utexas.edu>

Hello All,

I?ve recently started trying to use backgroundrb and I?m running into an
issue with starting the server.  I?m running OSX (leopard) and rails 2.0.2
with an oracle database.
When I run ./script/backgroundrb start I get the following error:
/Library/Ruby/Gems/1.8/gems/activerecord-2.0.2/lib/active_record/connection_
adapters/abstract_adapter.rb:150:in `log': OCIError: ORA-02014: cannot
select FOR UPDATE from view with DISTINCT, GROUP BY, etc.: select * from
(select raw_sql_.*, rownum raw_rnum_ from (SELECT * FROM
event_tracking.bdrb_job_queues   WHERE ( worker_name =
'upload_invitees_worker' AND taken = 0 AND scheduled_at <= '2009-03-19
13:38:04' ) ) raw_sql_ where rownum <= 1) where raw_rnum_ > 0 FOR UPDATE
(ActiveRecord::StatementInvalid)

I?ve read in a few places that when using Oracle it may be a good idea to
remove the lines that say allow_concurrency = true, and I?ve done that.

Also, I saw that there may be an issue with oracle adapter with a SELECT ...
FOR UPDATE statement locking rows here:
http://kseebaldt.blogspot.com/2007/11/synchronizing-using-active-record.html
The comment points to this occurring with backgroundrb.

I would appreciate any help that you all can provide.

Thanks,
Matt Stone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090319/20edf682/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3852 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090319/20edf682/attachment.bin>

From d-mcclean at ti.com  Thu Mar 19 11:26:18 2009
From: d-mcclean at ti.com (Don McClean)
Date: Thu, 19 Mar 2009 10:26:18 -0500
Subject: [Backgroundrb-devel] Issue starting backgroundrb server (with
 Oracle)
In-Reply-To: <C5E7C1A8.2D9B%mstone@austin.utexas.edu>
References: <C5E7C1A8.2D9B%mstone@austin.utexas.edu>
Message-ID: <49C2641A.6040102@ti.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090319/183e95c2/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: brdb_job_queue.rb
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090319/183e95c2/attachment.pl>

From elin44 at gmail.com  Thu Mar 19 15:36:24 2009
From: elin44 at gmail.com (Eric Lin)
Date: Thu, 19 Mar 2009 12:36:24 -0700
Subject: [Backgroundrb-devel] allow_concurrency deprecation warning
Message-ID: <E2E2C991-A21C-42D9-862E-EDFF5AC026C4@gmail.com>

In Rails 2.2, I get a deprecation warning when BackgroundDRb starts up:

DEPRECATION WARNING: ActiveRecord::Base.allow_concurrency= has been  
deprecated and no longer has any effect.

Should I be worried about this?

Apparently Rails 2.2 has a new thread-safety setting:  
"config.threadsafe!".  Perhaps BackgroundDRb should be updated to take  
advantage of that.

Eric

From elin44 at gmail.com  Thu Mar 19 15:53:51 2009
From: elin44 at gmail.com (Eric Lin)
Date: Thu, 19 Mar 2009 12:53:51 -0700
Subject: [Backgroundrb-devel] Reload ActiveRecord before calling worker?
Message-ID: <EE96A917-2400-4170-83F2-C8017AF097CF@gmail.com>

I recently ran into a problem where BackgroundDRb would get stuck on a  
request invoked like this:

class SomeModel < ActiveRecord::Base
   ..
   def start_work
     update_attribute(:state, 'working')

     MiddleMan.worker(:some_worker).async_do_work(:arg =>  
{ :some_model => self })
   end
   ...
end

What seems to be causing the problem is the call to update_attribute  
before worker is called.  But if I insert a "self.reload" between  
those two calls, it works.  Does this sound familiar to anyone?

Eric

From nicholas.wieland at gmail.com  Mon Mar 23 17:57:21 2009
From: nicholas.wieland at gmail.com (Nicholas Wieland)
Date: Mon, 23 Mar 2009 14:57:21 -0700
Subject: [Backgroundrb-devel] BDRB and Rspec
In-Reply-To: <bfb46b00903181532m37204f8dgc2d1f1919cb5f13@mail.gmail.com>
References: <bfb46b00903181532m37204f8dgc2d1f1919cb5f13@mail.gmail.com>
Message-ID: <bfb46b00903231457m1cb1a92aqc4fa6bbd7539d9b4@mail.gmail.com>

On 3/18/09, Nicholas Wieland <nicholas.wieland at gmail.com> wrote:
> CUT

Nobody uses rspec with backgroundrb ? How is it possible ? ...

  ngw

From maillist at steelskies.com  Mon Mar 23 18:54:33 2009
From: maillist at steelskies.com (Jonathan del Strother)
Date: Mon, 23 Mar 2009 22:54:33 +0000
Subject: [Backgroundrb-devel] BDRB and Rspec
In-Reply-To: <bfb46b00903231457m1cb1a92aqc4fa6bbd7539d9b4@mail.gmail.com>
References: <bfb46b00903181532m37204f8dgc2d1f1919cb5f13@mail.gmail.com> 
	<bfb46b00903231457m1cb1a92aqc4fa6bbd7539d9b4@mail.gmail.com>
Message-ID: <57518fd10903231554s4f33d456y4b1e38477f9278b8@mail.gmail.com>

2009/3/23 Nicholas Wieland <nicholas.wieland at gmail.com>:
> On 3/18/09, Nicholas Wieland <nicholas.wieland at gmail.com> wrote:
>> CUT
>
> Nobody uses rspec with backgroundrb ? How is it possible ? ...
>
> ?ngw

Copy script/bdrb_test_helper.rb from inside the backgroundrb plugin to
your spec directory, and require that before requiring your worker.
Your spec should then work fine.

From justin.wood at trifectagis.com  Fri Mar 27 00:24:39 2009
From: justin.wood at trifectagis.com (Justin Wood)
Date: Fri, 27 Mar 2009 17:24:39 +1300
Subject: [Backgroundrb-devel] UTF8 postgres args saving issue
Message-ID: <95a868280903262124vf933eefp969504df073c8638@mail.gmail.com>

Hi, All

I have an encountered an issue where the args field is not saved correctly
to the database.  I encounter an error like this:

ActiveRecord::StatementInvalid (RuntimeError: ERROR    C22021    M invalid
byte sequence for encoding "UTF8": 0xcb3a    H This error can also happen if
the byte sequence does not match the encoding expected by the server, which
is controlled by "client_encoding".

Here's the SQL that gets send to the database (note that the dump-ed args
are written as a string):

F.\src\backend\utils\mb\wchar.c    L1545    Rreport_invalid_encoding: INSERT
INTO "bdrb_job_queues" ("args", "job_key", "taken", "worker_key",
"worker_method", "priority", "finished_at", "tag", "worker_name", "timeout",
"submitted_at", "finished", "runner_info", "submitter_info", "archived_at",
"scheduled_at", "started_at")
VALUES(E'{:car_idi
?:inspection_report_name"First week inspection',
E'66', 0, E'', E'send_warranty_notice', NULL, NULL, NULL,
E'notification_worker', NULL, '2009-03-27 03:53:14.036000', 0, NULL, NULL,
NULL, '2009-04-03 03:53:13.917000', NULL) RETURNING "id"):

This won't happen all the time ... only when the array of bytes from the
dump (represented as a string) have combinations or bytes that can't be
interpreted as UTF8.

This could be fixed in a couple of ways I suppose the most obvious being how
the adapter saves bytea fields and encoding the dump as UTF8 ... but I
wasn't sure if it would un-encode.  So I implemented the fool proof option
of Base64 encoding the data, which means never having to worry about
encoding again (because this is not the first time I've had a character
encoding issue)

Here's the bulletproof hack that I added to my BdrbJobQueue

...
  #these accessors get around any possible character encoding issues with
the database
  def args=(args)
    write_attribute(:args, Base64.b64encode(args))
  end
  def args
    Base64.decode64(read_attribute(:args))
  end
...

Hope that helps someone.  It will help anyone who has the problem referred
to here
http://rubyforge.org/pipermail/backgroundrb-devel/2009-March/002325.html.
Note, to the best of my knowledge all my other UTF8 settings are correct.

Cheers
Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090327/3e05a7d9/attachment.html>

From gethemant at gmail.com  Fri Mar 27 14:12:01 2009
From: gethemant at gmail.com (hemant)
Date: Fri, 27 Mar 2009 23:42:01 +0530
Subject: [Backgroundrb-devel] UTF8 postgres args saving issue
In-Reply-To: <95a868280903262124vf933eefp969504df073c8638@mail.gmail.com>
References: <95a868280903262124vf933eefp969504df073c8638@mail.gmail.com>
Message-ID: <fb283d5e0903271112s7954ed1eq8cb31edbbdac88bf@mail.gmail.com>

Hey  Justin,

Thanks for the info. BTW, I will be merging following tree which
should fix these issues:

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



On Fri, Mar 27, 2009 at 9:54 AM, Justin Wood
<justin.wood at trifectagis.com> wrote:
> Hi, All
>
> I have an encountered an issue where the args field is not saved correctly
> to the database.? I encounter an error like this:
>
> ActiveRecord::StatementInvalid (RuntimeError: ERROR??? C22021??? M invalid
> byte sequence for encoding "UTF8": 0xcb3a??? H This error can also happen if
> the byte sequence does not match the encoding expected by the server, which
> is controlled by "client_encoding".
>
> Here's the SQL that gets send to the database (note that the dump-ed args
> are written as a string):
>
> F.\src\backend\utils\mb\wchar.c??? L1545??? Rreport_invalid_encoding: INSERT
> INTO "bdrb_job_queues" ("args", "job_key", "taken", "worker_key",
> "worker_method", "priority", "finished_at", "tag", "worker_name", "timeout",
> "submitted_at", "finished", "runner_info", "submitter_info", "archived_at",
> "scheduled_at", "started_at") VALUES(E' { : car_idi ?:
> inspection_report_name" First week inspection', E'66', 0, E'',
> E'send_warranty_notice', NULL, NULL, NULL, E'notification_worker', NULL,
> '2009-03-27 03:53:14.036000', 0, NULL, NULL, NULL, '2009-04-03
> 03:53:13.917000', NULL) RETURNING "id"):
>
> This won't happen all the time ... only when the array of bytes from the
> dump (represented as a string) have combinations or bytes that can't be
> interpreted as UTF8.
>
> This could be fixed in a couple of ways I suppose the most obvious being how
> the adapter saves bytea fields and encoding the dump as UTF8 ... but I
> wasn't sure if it would un-encode.? So I implemented the fool proof option
> of Base64 encoding the data, which means never having to worry about
> encoding again (because this is not the first time I've had a character
> encoding issue)
>
> Here's the bulletproof hack that I added to my BdrbJobQueue
>
> ...
> ? #these accessors get around any possible character encoding issues with
> the database
> ? def args=(args)
> ??? write_attribute(:args, Base64.b64encode(args))
> ? end
> ? def args
> ??? Base64.decode64(read_attribute(:args))
> ? end
> ...
>
> Hope that helps someone.? It will help anyone who has the problem referred
> to here
> http://rubyforge.org/pipermail/backgroundrb-devel/2009-March/002325.html.
> Note, to the best of my knowledge all my other UTF8 settings are correct.
>
> Cheers
> Justin
>
>
>
> _______________________________________________
> 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 till at mindmeister.com  Mon Mar 30 05:59:40 2009
From: till at mindmeister.com (Till Vollmer)
Date: Mon, 30 Mar 2009 11:59:40 +0200
Subject: [Backgroundrb-devel] Severe Bug with daylight saving time?
Message-ID: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>

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.

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


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

From gethemant at gmail.com  Mon Mar 30 08:31:21 2009
From: gethemant at gmail.com (hemant)
Date: Mon, 30 Mar 2009 18:01:21 +0530
Subject: [Backgroundrb-devel] Severe Bug with daylight saving time?
In-Reply-To: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>
References: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>
Message-ID: <fb283d5e0903300531n70a4178r25d29d7db133e824@mail.gmail.com>

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?

From till at mindmeister.com  Mon Mar 30 08:46:09 2009
From: till at mindmeister.com (Till Vollmer)
Date: Mon, 30 Mar 2009 14:46:09 +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: <A1CA9277-0DC6-43B0-BFC2-80B1D08D567D@mindmeister.com>

Hi,

The worker looks like that:

class NotificationWorker < BackgrounDRb::MetaWorker
   set_worker_name :notification_worker
   reload_on_schedule true

   def create(args = nil)
     # time argument is in seconds
   end

   def do_it
     logger.info('NotificationWorker do it start')
     begin
       Idea.notify_users
     rescue  Exception => e
       logger.error("Idea.notify_users Exception: #{e.to_s}  
#{e.backtrace.join('\\n')}")
     end
     logger.info('NotificationWorker do it end')
   end
end


Recover - we removed the scheduling and trigger only daily right now.

Not sure if it would work today (after the day that has only 23  
hours). but as it is a production system we did not try it.

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/20090330/ee6863a7/attachment-0001.html>

From adam at thewilliams.ws  Mon Mar 30 09:47:38 2009
From: adam at thewilliams.ws (Adam Williams)
Date: Mon, 30 Mar 2009 09:47:38 -0400
Subject: [Backgroundrb-devel] Severe Bug with daylight saving time?
In-Reply-To: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>
References: <42C4E5BA-B5B0-4B5A-9F4D-B6CDBF8A210D@mindmeister.com>
Message-ID: <585CBC76-BC99-4C56-8929-DB35DA7541F1@thewilliams.ws>

I have suffered the same way, and also believe it to be a time change  
issue. We spent a good deal of time discovering, after the time change  
a few weeks ago, that the schedule '0 0 0 * * * *' would no long work  
at all. We are now running on '23 59 59 * * * *', and that seems to be  
fine.

On Mar 30, 2009, at 5:59 AM, Till Vollmer 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.
>
> 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
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel


From timuckun at gmail.com  Tue Mar 31 21:50:26 2009
From: timuckun at gmail.com (Tim Uckun)
Date: Wed, 1 Apr 2009 14:50:26 +1300
Subject: [Backgroundrb-devel] A pre-install question.
Message-ID: <855e4dcf0903311850p4bcddf18raab0a5173ddae233@mail.gmail.com>

I was working on creating my own background/scheduled job code but it seems
like a waste given how much work you guys have put into this project.   I
would much rather use your code than to code it all up myself.

Having said that I would like to know if the following is possible.

In my current setup I put the jobs that need to get run into a table tagged
with the user is of the person who is logged in along with the ID of their
company.  This allows me to build a page a page where the user can check up
on his jobs, see if any of them errored out (I put the error code or results
in the table) and resubmit them if needed.

In my setup the scheduled jobs go into another table and the proccessor
merely pumps jobs into the jobs queue on a scheduled basis so they can see
how their scheduled jobs worked out too.

This allows me to let the users schedule their own jobs (from a dropdown of
course) and check up on them.

Is it possible to achieve something similar with backgroundrb?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20090401/86eb2a3a/attachment.html>