Hi!
It's probably working locally because it's a different caching
mechanism. Rails by default will use MemoryStore, whereas on Heroku it
is set to use Memcache.
So you're using Rails.cache to make sure just one instance of
Rufus::Scheduler is running? Interesting. Is it working locally? (ie
even if you boot two thins just one scheduler instance is executed?
Well, I'm not sure but I think it won't work with Memcache. You can
either run the scheduler in just one server or maybe just allow one
scheduler instance per server? Or of course you can attempt to run it
locally with memcache and try to debug/fix it.
On Fri, Sep 26, 2008 at 3:55 PM, ChasManRors <[EMAIL PROTECTED]> wrote:
>
> Thank you Pedro. Though I don't think we are on the same page.
>
> I work locally and confirm my app is working, which it is, then I push
> it up for deployment.
>
> - So I don't know why the fetch() acts differently locally then it
> does when it is deployed?
>
> Here is the algorithm: (I am open to suggestions)
>
> I am using a single instance of the scheduler so that I do not have to
> track the scheduler instances in parallel with the job_ids. Because,
> I don't think I need a new Scheduler for each job I wish to schedule.
> Here is how I am using rufus and Rails.cache:
>
> I am doing 'rufus.unschedule(job_id)' in my controller. I do
> unschedule() to stop my scheduled job(s). I get the instance of the
> rufus scheduler from the cache by doing 'rufus =
> Rails.cache.read(:rufus)'.
>
> Before I get the rufus scheduler in my controller (above) the rufus
> scheduler instance is set in my model, by doing:
> 'Rails.cache.fetch(:rufus) {Rufus::Scheduler.start_new}'
>
> Thanks,
>
> Trying ToRor.
>
> On Sep 26, 2:37 pm, Pedro Belo <[EMAIL PROTECTED]> wrote:
>> I think the problem is you're trying to put/get from the cache one
>> instance of Rufus::Scheduler, not the result of your scheduled job. If
>> you want the former, you should call Rails.cache.fetch inside your
>> Rufus job.
>>
>> Makes sense? If not please explain what you're trying to fetch from
>> the cache.
>>
>> On Sep 26, 10:26 am, ChasManRors <[EMAIL PROTECTED]> wrote:
>>
>> > No luck. Same problem
>>
>> > I tried to invoke gem before I do a fetch by putting the following in
>> > my model.
>>
>> > # Bug in cash loading workaround thanks tony, but not yet working
>> > x = Rufus::Scheduler.start_new
>> > Rails.cache.fetch(:rufus) {Rufus::Scheduler.start_new
>>
>> > I also started a console and assigned
>> > x = Rufus::Scheduler.start_new
>>
>> > I may have misunderstood your point, or perhaps it is something
>> > else.
>>
>> > thanx
>>
>> > On Sep 26, 10:09 am, "tony luo" <[EMAIL PROTECTED]> wrote:
>>
>> > > I met the same problem.
>>
>> > > It is because that you use your own data structure and Rails haven't
>> > > loaded
>> > > it yet.
>>
>> > > You can invoke this object before you read from cache to solve this
>> > > problem.
>>
>> > > On Fri, Sep 26, 2008 at 9:41 PM, ChasManRors <[EMAIL PROTECTED]> wrote:
>>
>> > > > Works locally but I get the following trace when running deployed app:
>>
>> > > > TypeError in TasksController#index
>>
>> > > > no marshal_dump is defined for class Thread
>>
>> > > > RAILS_ROOT: /mnt/home/userapps/33901
>> > > > Application Trace | Framework Trace | Full Trace
>>
>> > > > /usr/lib/ruby/gems/1.8/gems/memcache-client-1.5.0/lib/memcache.rb:
>> > > > 300:in `dump'
>> > > > /usr/lib/ruby/gems/1.8/gems/memcache-client-1.5.0/lib/memcache.rb:
>> > > > 300:in `set'
>> > > > /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/
>> > > > cache/mem_cache_store.rb:37:in `send'
>> > > > /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/
>> > > > cache/mem_cache_store.rb:37:in `write'
>> > > > /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/
>> > > > cache.rb:71:in `fetch'
>> > > > app/models/task.rb:9
>> > > > app/controllers/tasks_controller.rb:10
>> > > > /home/userapps_plugins/preload/request_timeout/lib/request_timeout.rb:
>> > > > 9
>> > > > /home/userapps_plugins/preload/request_timeout/lib/request_timeout.rb:
>> > > > 8
>> > > > /home/heroku_rack/lib/toolbar.rb:16
>> > > > /usr/bin/thin:19:in `load'
>> > > > /usr/bin/thin:19
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Heroku" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en
-~----------~----~----~----~------~----~------~--~---