Hi, I want to use backgroundrb to set up dead-man timers on user accounts. If someone is inactive for a set period, then the system will automatically log them out and send an offline presence notification. I''ve got this working by spawning new workers with job keys and using page changes and periodic calls to refresh a countdown timer in the worker. However, this becomes hard going if more than a few dozen users log in at the same time. I''ve dug through the documentation and tried a few things to no avail. What I''m wondering is, is it possible to add and access threads on a single worker using a job key? Alternately, is there a way to pre-fork a group of workers and then assign (and reassign) them job keys? Many Thanks, Todd -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080305/7269de3c/attachment.html
On Wed, 2008-03-05 at 18:34 +0000, Todd Tyree wrote:> Hi, > > I want to use backgroundrb to set up dead-man timers on user accounts. > If someone is inactive for a set period, then the system will > automatically log them out and send an offline presence notification. > I''ve got this working by spawning new workers with job keys and using > page changes and periodic calls to refresh a countdown timer in the > worker. However, this becomes hard going if more than a few dozen > users log in at the same time. I''ve dug through the documentation and > tried a few things to no avail. What I''m wondering is, is it possible > to add and access threads on a single worker using a job key? > Alternately, is there a way to pre-fork a group of workers and then > assign (and reassign) them job keys? > usIf you lots of users coming in and spawning a worker for each them is bad idea. You should probably be off using inbuilt thread pool. However, it seems you want unique handle for each user. The best way to achieve this is to use register_status with user_id or something inside worker, so as when you invoke ask_status from your controller, you can grab status based on user ids. What I am trying to say is, perhaps you don''t need a job_key for each thread invoked.
On Thu, 2008-03-06 at 09:37 +0000, Todd Tyree wrote:> > > If you lots of users coming in and spawning a worker for each > them is > bad idea. You should probably be off using inbuilt thread > pool. > > However, it seems you want unique handle for each user. The > best way to > achieve this is to use register_status with user_id or > something inside > worker, so as when you invoke ask_status from your controller, > you can > grab status based on user ids. What I am trying to say is, > perhaps you > don''t need a job_key for each thread invoked. > > > > Hi Hemant, > > Thanks for that. I think I understand where you''re coming from with > that suggestion and I''ll give it a try. In the meantime, could you > just tell me if something like what I''ve outlined below is possible? > I''ve tried a few variations and can''t get it to work and just want to > know if I''m going down a dead-end. > > def create(user) > return Thread.new do > @shutdown = add_timer(60) { done(user, thread) } > end > end > > def keepalive(user, thread) > thread do > cancel_timer(@shutdown) > @shutdown = add_timer(60) { done(user. thread) } > end > end > > def done(user,thread) > user.destroy > thread.destroy > end >I do not understand what you are trying to do? For one fact, you can never pass threads across workers and rails. Also, are you having one worker per user? If yes, then why you need threads? If no, then you can easily have each thread in thread pool mapped to individual user. Can you specify more clearly what this worker does? If possible, can you send us, entire worker code so as I can see more sense of purpose that I can scantly see now.