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
-~----------~----~----~----~------~----~------~--~---
