Hello,
I''m using just the scheduler with my workers like cron jobs. I have 3
different ones that poll my db for specific object states and do work
accordingly.
This all works perfectly on my development machine. However, when I
deploy to my staging server - with its own staging configuration - the
scheduler works, the worker processes, but my ActiveRecord object
never returns any data back.
I explicitly include the model in the top of the worker and when the
worker processes, I can see the query logging in the log file. I can
even cut the query, paste into a sql window and get back the expected
results. But whenever the query returns in my non-development deployed
worker, the result set is empty.
My backgroundrb.yml configuration is super simple:
---
:backgroundrb:
:ip: 0.0.0.0
:port: 11006
Again, the above is only just for scheduling and works perfectly on my
local env. I also explicitly executed brb with the env specific
setting:
script/console backgroundrb -e stage
Still no luck.
Has anyone see this weird issue with AR not returning back any
results, even tho the query has been executed in the db?
tia,
- jason
I''m not certain at all about this, but the -e thing was not working well for me. Try spitting out the RAILS_ENV value in your worker, to be sure it is the environment your expect. Or, perhaps you could use ''sudo lsof -Pni -a -c ruby'' to see what database ruby processes are connecting to. On Apr 30, 2008, at 1:16 AM, Jason Lee wrote:> Hello, > > I''m using just the scheduler with my workers like cron jobs. I have 3 > different ones that poll my db for specific object states and do work > accordingly. > > This all works perfectly on my development machine. However, when I > deploy to my staging server - with its own staging configuration - the > scheduler works, the worker processes, but my ActiveRecord object > never returns any data back. > > I explicitly include the model in the top of the worker and when the > worker processes, I can see the query logging in the log file. I can > even cut the query, paste into a sql window and get back the expected > results. But whenever the query returns in my non-development deployed > worker, the result set is empty. > > My backgroundrb.yml configuration is super simple: > > --- > :backgroundrb: > :ip: 0.0.0.0 > :port: 11006 > > Again, the above is only just for scheduling and works perfectly on my > local env. I also explicitly executed brb with the env specific > setting: > > script/console backgroundrb -e stage > > Still no luck. > > Has anyone see this weird issue with AR not returning back any > results, even tho the query has been executed in the db? > > tia, > > - jason > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
Ah, that''s it, it''s still in development env. So neither of these commands worked for me: RAILS_ENV=stage rake backgroundrb:start script/backgroundrb start -e stage both go to development. Right now I''m kicking them off manually at the command line. Maybe the rake command is not taking the environment in to account? Now that I know the cause, I guess I have to try to fix it. I saw the environment issue mentioned in previous postings on the list, but it didn''t look like there was a solution yet (I think). I''m running rev 234 of BRb. If I figure this out or someone else does, please post. Thx. - jason On Wed, Apr 30, 2008 at 4:00 AM, Adam Williams <adam at thewilliams.ws> wrote:> I''m not certain at all about this, but the -e thing was not working well for > me. Try spitting out the RAILS_ENV value in your worker, to be sure it is > the environment your expect. Or, perhaps you could use ''sudo lsof -Pni -a -c > ruby'' to see what database ruby processes are connecting to. > > > > On Apr 30, 2008, at 1:16 AM, Jason Lee wrote: > > > > > > > > > > Hello, > > > > I''m using just the scheduler with my workers like cron jobs. I have 3 > > different ones that poll my db for specific object states and do work > > accordingly. > > > > This all works perfectly on my development machine. However, when I > > deploy to my staging server - with its own staging configuration - the > > scheduler works, the worker processes, but my ActiveRecord object > > never returns any data back. > > > > I explicitly include the model in the top of the worker and when the > > worker processes, I can see the query logging in the log file. I can > > even cut the query, paste into a sql window and get back the expected > > results. But whenever the query returns in my non-development deployed > > worker, the result set is empty. > > > > My backgroundrb.yml configuration is super simple: > > > > --- > > :backgroundrb: > > :ip: 0.0.0.0 > > :port: 11006 > > > > Again, the above is only just for scheduling and works perfectly on my > > local env. I also explicitly executed brb with the env specific > > setting: > > > > script/console backgroundrb -e stage > > > > Still no luck. > > > > Has anyone see this weird issue with AR not returning back any > > results, even tho the query has been executed in the db? > > > > tia, > > > > - jason > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > >
Hey Jason, To get the environment passed in correctly, I use: RAILS_ENV=staging ./script/backgroundrb start And just to make sure, you''re aren''t actually calling your staging environment "stage" are you? Or if you are, you have an environment intentionally named that, right? Just had to ask :). stevie On Wed, Apr 30, 2008 at 10:32 AM, Jason Lee <jasonlee9 at gmail.com> wrote:> Ah, that''s it, it''s still in development env. So neither of these > commands worked for me: > > RAILS_ENV=stage rake backgroundrb:start > > script/backgroundrb start -e stage > > both go to development. Right now I''m kicking them off manually at the > command line. Maybe the rake command is not taking the environment in > to account? > > Now that I know the cause, I guess I have to try to fix it. I saw the > environment issue mentioned in previous postings on the list, but it > didn''t look like there was a solution yet (I think). I''m running rev > 234 of BRb. > > If I figure this out or someone else does, please post. Thx. > > - jason > > > > On Wed, Apr 30, 2008 at 4:00 AM, Adam Williams <adam at thewilliams.ws> wrote: > > I''m not certain at all about this, but the -e thing was not working well for > > me. Try spitting out the RAILS_ENV value in your worker, to be sure it is > > the environment your expect. Or, perhaps you could use ''sudo lsof -Pni -a -c > > ruby'' to see what database ruby processes are connecting to. > > > > > > > > On Apr 30, 2008, at 1:16 AM, Jason Lee wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > I''m using just the scheduler with my workers like cron jobs. I have 3 > > > different ones that poll my db for specific object states and do work > > > accordingly. > > > > > > This all works perfectly on my development machine. However, when I > > > deploy to my staging server - with its own staging configuration - the > > > scheduler works, the worker processes, but my ActiveRecord object > > > never returns any data back. > > > > > > I explicitly include the model in the top of the worker and when the > > > worker processes, I can see the query logging in the log file. I can > > > even cut the query, paste into a sql window and get back the expected > > > results. But whenever the query returns in my non-development deployed > > > worker, the result set is empty. > > > > > > My backgroundrb.yml configuration is super simple: > > > > > > --- > > > :backgroundrb: > > > :ip: 0.0.0.0 > > > :port: 11006 > > > > > > Again, the above is only just for scheduling and works perfectly on my > > > local env. I also explicitly executed brb with the env specific > > > setting: > > > > > > script/console backgroundrb -e stage > > > > > > Still no luck. > > > > > > Has anyone see this weird issue with AR not returning back any > > > results, even tho the query has been executed in the db? > > > > > > tia, > > > > > > - jason > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >
Ok, I''ll try that. Yes, I have an environment separately configured for ''stage'' and I explicitly set it where needed. Thanks, - jason On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at slowbicycle.com> wrote:> Hey Jason, > > To get the environment passed in correctly, I use: > RAILS_ENV=staging ./script/backgroundrb start > > And just to make sure, you''re aren''t actually calling your staging > environment "stage" are you? Or if you are, you have an environment > intentionally named that, right? Just had to ask :). > > stevie > > > > On Wed, Apr 30, 2008 at 10:32 AM, Jason Lee <jasonlee9 at gmail.com> wrote: > > Ah, that''s it, it''s still in development env. So neither of these > > commands worked for me: > > > > RAILS_ENV=stage rake backgroundrb:start > > > > script/backgroundrb start -e stage > > > > both go to development. Right now I''m kicking them off manually at the > > command line. Maybe the rake command is not taking the environment in > > to account? > > > > Now that I know the cause, I guess I have to try to fix it. I saw the > > environment issue mentioned in previous postings on the list, but it > > didn''t look like there was a solution yet (I think). I''m running rev > > 234 of BRb. > > > > If I figure this out or someone else does, please post. Thx. > > > > - jason > > > > > > > > On Wed, Apr 30, 2008 at 4:00 AM, Adam Williams <adam at thewilliams.ws> wrote: > > > I''m not certain at all about this, but the -e thing was not working well for > > > me. Try spitting out the RAILS_ENV value in your worker, to be sure it is > > > the environment your expect. Or, perhaps you could use ''sudo lsof -Pni -a -c > > > ruby'' to see what database ruby processes are connecting to. > > > > > > > > > > > > On Apr 30, 2008, at 1:16 AM, Jason Lee wrote: > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > I''m using just the scheduler with my workers like cron jobs. I have 3 > > > > different ones that poll my db for specific object states and do work > > > > accordingly. > > > > > > > > This all works perfectly on my development machine. However, when I > > > > deploy to my staging server - with its own staging configuration - the > > > > scheduler works, the worker processes, but my ActiveRecord object > > > > never returns any data back. > > > > > > > > I explicitly include the model in the top of the worker and when the > > > > worker processes, I can see the query logging in the log file. I can > > > > even cut the query, paste into a sql window and get back the expected > > > > results. But whenever the query returns in my non-development deployed > > > > worker, the result set is empty. > > > > > > > > My backgroundrb.yml configuration is super simple: > > > > > > > > --- > > > > :backgroundrb: > > > > :ip: 0.0.0.0 > > > > :port: 11006 > > > > > > > > Again, the above is only just for scheduling and works perfectly on my > > > > local env. I also explicitly executed brb with the env specific > > > > setting: > > > > > > > > script/console backgroundrb -e stage > > > > > > > > Still no luck. > > > > > > > > Has anyone see this weird issue with AR not returning back any > > > > results, even tho the query has been executed in the db? > > > > > > > > tia, > > > > > > > > - jason > > > > _______________________________________________ > > > > Backgroundrb-devel mailing list > > > > Backgroundrb-devel at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > >
So I tried this and my debug still says the env is development.. Guess I''ll have to start hacking to see why this is.. - jason On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at slowbicycle.com> wrote:> Hey Jason, > > To get the environment passed in correctly, I use: > RAILS_ENV=staging ./script/backgroundrb start > > And just to make sure, you''re aren''t actually calling your staging > environment "stage" are you? Or if you are, you have an environment > intentionally named that, right? Just had to ask :). > > stevie
So, there is some serious confusion about this in the code. I now know
of two other folks (one you, Jason) who struggled with this besides me.
I solved it by having a shared/config/backgroundrb.yml on the server,
which we link into config of the app on deploy (capistrano). It looks
like this:
:backgroundrb:
:port: 11006
:ip: 0.0.0.0
:environment: staging
:lazy_load: true
:debug_log: true
:schedules:
:notification:
:deliver_event_reminders:
:trigger_args: 0 */3 * * * * *
As you can see, we have the environment in the config. The code in
meta_worker obviously disrespects -e. Now, you ALSO need to pass -e
staging, so that when Rails boots, it has the correct environment.
Here is our init.d line:
/var/www/apps/railsapplication/current/script/backgroundrb "$1" -e
staging >> /var/log/backgroundrb
I may patch this at some point, but it''s already eaten a bit too much
time (not you, but solving it originally).
aiwilliams
On Apr 30, 2008, at 12:49 PM, Jason Lee wrote:
> So I tried this and my debug still says the env is development..
>
> Guess I''ll have to start hacking to see why this is..
>
> - jason
>
> On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at
slowbicycle.com
> > wrote:
>> Hey Jason,
>>
>> To get the environment passed in correctly, I use:
>> RAILS_ENV=staging ./script/backgroundrb start
>>
>> And just to make sure, you''re aren''t actually calling
your staging
>> environment "stage" are you? Or if you are, you have an
environment
>> intentionally named that, right? Just had to ask :).
>>
>> stevie
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
Adam, Thanks for the reply. I''ll have to see if I can play around with the yml file. I definitely cannot use the scheduler definition as it was very unreliable for the tasks I needed to launch. If I can just get the environments to come up without any of the other config, I''ll be good. I''ll post back my solution when I find it. Thanks again, - jason On Wed, Apr 30, 2008 at 10:35 AM, Adam Williams <adam at thewilliams.ws> wrote:> So, there is some serious confusion about this in the code. I now know of > two other folks (one you, Jason) who struggled with this besides me. > > I solved it by having a shared/config/backgroundrb.yml on the server, which > we link into config of the app on deploy (capistrano). It looks like this: > > :backgroundrb: > :port: 11006 > > :ip: 0.0.0.0 > :environment: staging > :lazy_load: true > :debug_log: true > > :schedules: > :notification: > :deliver_event_reminders: > :trigger_args: 0 */3 * * * * * > > As you can see, we have the environment in the config. The code in > meta_worker obviously disrespects -e. Now, you ALSO need to pass -e staging, > so that when Rails boots, it has the correct environment. Here is our init.d > line: > > /var/www/apps/railsapplication/current/script/backgroundrb "$1" -e staging > >> /var/log/backgroundrb > > I may patch this at some point, but it''s already eaten a bit too much time > (not you, but solving it originally). > > aiwilliams > > > > On Apr 30, 2008, at 12:49 PM, Jason Lee wrote: > > > > > > > > > > So I tried this and my debug still says the env is development.. > > > > Guess I''ll have to start hacking to see why this is.. > > > > - jason > > > > On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at slowbicycle.com> > wrote: > > > > > Hey Jason, > > > > > > To get the environment passed in correctly, I use: > > > RAILS_ENV=staging ./script/backgroundrb start > > > > > > And just to make sure, you''re aren''t actually calling your staging > > > environment "stage" are you? Or if you are, you have an environment > > > intentionally named that, right? Just had to ask :). > > > > > > stevie > > > > > > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > >
Solved. So I basically followed Adam''s advice and have my deploy copying a different backgroundrb.yml file out based on the deploy. One thing that was a little puzzling was the whole worker thread process and how it picked up the environment. I noticed a few things, but I''m not sure if I''m totally correct about them as I haven''t really delved into the codebase. 1. Seems each worker process/run picks up the config. At first glance I thought "hmm, why re-load the config every time?". I''ll probably be running multiple workers - maybe half a dozen - doing various things and the config reload seems like an unnecessary hit. *However*, I didn''t write BRb and I''m sure there''s obviously a reason why this is happening and I just don''t know it yet. 2. The fact that the config is picked up on each run, overrides any env I pass in from the command line or from any automated rake/execution task. I put debug in various places, kicked off the server with the rails env set and saw that the first run picked up the env. Every run after, defaulted to development. So anyway, this isn''t a critique, just observations. I''ll be putting my system into a real production env in a few weeks and I''m glad BRb exists at all - keeps me from having to write yet another component/service. :) Thanks for the replies, it''s been very helpful! - jason On Wed, Apr 30, 2008 at 2:22 PM, Jason Lee <jasonlee9 at gmail.com> wrote:> Adam, > > Thanks for the reply. I''ll have to see if I can play around with the > yml file. I definitely cannot use the scheduler definition as it was > very unreliable for the tasks I needed to launch. If I can just get > the environments to come up without any of the other config, I''ll be > good. > > I''ll post back my solution when I find it. > > Thanks again, > > - jason > > > > On Wed, Apr 30, 2008 at 10:35 AM, Adam Williams <adam at thewilliams.ws> wrote: > > So, there is some serious confusion about this in the code. I now know of > > two other folks (one you, Jason) who struggled with this besides me. > > > > I solved it by having a shared/config/backgroundrb.yml on the server, which > > we link into config of the app on deploy (capistrano). It looks like this: > > > > :backgroundrb: > > :port: 11006 > > > > :ip: 0.0.0.0 > > :environment: staging > > :lazy_load: true > > :debug_log: true > > > > :schedules: > > :notification: > > :deliver_event_reminders: > > :trigger_args: 0 */3 * * * * * > > > > As you can see, we have the environment in the config. The code in > > meta_worker obviously disrespects -e. Now, you ALSO need to pass -e staging, > > so that when Rails boots, it has the correct environment. Here is our init.d > > line: > > > > /var/www/apps/railsapplication/current/script/backgroundrb "$1" -e staging > > >> /var/log/backgroundrb > > > > I may patch this at some point, but it''s already eaten a bit too much time > > (not you, but solving it originally). > > > > aiwilliams > > > > > > > > On Apr 30, 2008, at 12:49 PM, Jason Lee wrote: > > > > > > > > > > > > > > > > So I tried this and my debug still says the env is development.. > > > > > > Guess I''ll have to start hacking to see why this is.. > > > > > > - jason > > > > > > On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <stevie at slowbicycle.com> > > wrote: > > > > > > > Hey Jason, > > > > > > > > To get the environment passed in correctly, I use: > > > > RAILS_ENV=staging ./script/backgroundrb start > > > > > > > > And just to make sure, you''re aren''t actually calling your staging > > > > environment "stage" are you? Or if you are, you have an environment > > > > intentionally named that, right? Just had to ask :). > > > > > > > > stevie > > > > > > > > > > _______________________________________________ > > > Backgroundrb-devel mailing list > > > Backgroundrb-devel at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > > > > > > >