Rails - Sep 2006 - Could a BackgrounDrb worker do this?

When a user explicitly logs out of my app (by clicking a button that invokes the
''logout'' action), all the DB records and files
they''ve created during their session get deleted.  I''m trying
to figure out how to do that same thing when users just abandon the site (either
by closing the browser or entering a new URL.).

One thought is to use BackgroundDrb for my session store (currently using the
default PStore) and have the worker process somehow invoke the logout action
(it''s done explicitly via a form_remote_tag submission) on behalf of /
masquerading as the user.  Could this work?

Thanks,
Bill

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sep 10, 2006, at 11:10 AM, Bill Walton wrote:
> When a user explicitly logs out of my app (by clicking a button  
> that invokes the ''logout'' action), all the DB records and
files
> they''ve created during their session get deleted.  I''m
trying to
> figure out how to do that same thing when users just abandon the  
> site (either by closing the browser or entering a new URL.).
>
> One thought is to use BackgroundDrb for my session store (currently  
> using the default PStore) and have the worker process somehow  
> invoke the logout action (it''s done explicitly via a  
> form_remote_tag submission) on behalf of / masquerading as the  
> user.  Could this work?
>
> Thanks,
> Bill
>

Hey Bill-

	I don''t think backgroundrb is the right tool or this job.  
Backgroundrb is not a session container so it won''t work like you  
want. The best way to do what you want would be to use the  
ActiveRecord session store to store your sessions in the db. Then  
make a cron job that wakes up ever 10 minutes or so and deletes the  
session and objects that folks abandoned. You would need some sort of  
heuristic to decide how long to wait before you call a session  
''abandoned'' and delete it.


-Ezra

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Ezra,

Ezra Zygmuntowicz wrote:
> Backgroundrb is not a session container
> so it won''t work like you want.
I don''t understand what you mean by ''not a session
container,''  It''s listed
as an alternative to PStore and ActiveRecord session stores.  I really
don''t
know much of anything about session management mechanisms and I have a 
feeling you''re telling me something I need to understand.  Could you
say
more about this please?
> The best way to do what you want would be
> to use the ActiveRecord session store to store
> your sessions in the db. Then make a cron job
> that wakes up ever 10 minutes or so and deletes
> the session and objects that folks abandoned.
The documentation on the wiki (I think) says that cron jobs are very high 
cost compared to Backgroundrb and gives the impression that Backgroundrb is 
a lightweight alternative that combines the session store mechanism with 
cron-like worker processes.  I misunderstood?

The main issue I''m trying to get my arms around is how to get at the
data
the user entered during their session so it can be deleted.  Is it possible 
for the cron job to access the application data?  Do you know of any online 
examples of how that would be done?  The following happens when the user 
explicitly logs out of the app.

def cleanup
    emrec = find_emrec    # get the parent record; its id is stored in a 
session variable
    files = Tempfilerec.find(:all, :conditions => ["emrec_id = ?", 
emrec.id])    # get the names of all the files the visitor has created
    files.each {|file|  FileUtils.rm "public/#{file.filename}" } #
delete
the files
    emrec.destroy # delete all the db records the visitor has created
    reset_session
  end

I need to do the same processing when the user abandons a session.  Can I do 
this from a script run as a cron job?

Thanks very much for any help understanding how to go about this.

Best regards,
Bill 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi~

On Sep 11, 2006, at 5:24 AM, Bill Walton wrote:
>
> Hi Ezra,
>
> Ezra Zygmuntowicz wrote:
>
>> Backgroundrb is not a session container
>> so it won''t work like you want.
>
> I don''t understand what you mean by ''not a session
container,''
> It''s listed
> as an alternative to PStore and ActiveRecord session stores.  I  
> really don''t
> know much of anything about session management mechanisms and I have a
> feeling you''re telling me something I need to understand.  Could  
> you say
> more about this please?
	I think there is some confusion n the wiki. There is a DRb session  
container that you can use that comes with rails. BackgrounDRb is a  
rails plugin that I wrote for running long background tasks with hook  
for ajax progress bars or status updates in the browser. BackgrounDRb  
has nothing to do with sessions and will not work as a session  
container. For session containers here are your main options:

Pstore: filesystm storage, slowest of all the session containers.

ActiveRecord session store: stores sessions in a database table. Fast

DRb session store:  similar speed to ActiveRecord store but not as  
robust and has less features. I have never used this one for  
production and i dont think that many people use this one.

Memcached: fastest session container but requires running extra  
daemons. Use this if you need to scale to the moon.

Stefan Kaeys Mysql session store:  Faster then AR session store  
because its direct sql access. worth lookin at.


Out of all these the one I usualy use most is ActiveRecord store. Its  
very easy to set up and is pretty fast. This is the one I recommend.  
You can always change it later if it becomes necessary but it will  
handle all but the hugest sites fast.

>
>> The best way to do what you want would be
>> to use the ActiveRecord session store to store
>> your sessions in the db. Then make a cron job
>> that wakes up ever 10 minutes or so and deletes
>> the session and objects that folks abandoned.
>
> The documentation on the wiki (I think) says that cron jobs are  
> very high
> cost compared to Backgroundrb and gives the impression that  
> Backgroundrb is
> a lightweight alternative that combines the session store mechanism  
> with
> cron-like worker processes.  I misunderstood?
	Backgroundrb does have cron like workers. And you can manage them  
from your rails app. But it is not a session container. So I think it  
can work for what you want to do.
>
> The main issue I''m trying to get my arms around is how to get at  
> the data
> the user entered during their session so it can be deleted.  Is it  
> possible
> for the cron job to access the application data?  Do you know of  
> any online
> examples of how that would be done?  The following happens when the  
> user
> explicitly logs out of the app.
	Are you marking your records with some kind of identifier so you can  
delete everything someone created? Or how will you know which objects  
to delete when you clean up after them?
>
> def cleanup
>     emrec = find_emrec    # get the parent record; its id is stored  
> in a
> session variable
>     files = Tempfilerec.find(:all, :conditions => ["emrec_id =
?",
> emrec.id])    # get the names of all the files the visitor has created
>     files.each {|file|  FileUtils.rm "public/#{file.filename}" }
#
> delete
> the files
>     emrec.destroy # delete all the db records the visitor has created
>     reset_session
>   end
>
> I need to do the same processing when the user abandons a session.   
> Can I do
> this from a script run as a cron job?
>
> Thanks very much for any help understanding how to go about this.
>
> Best regards,
> Bill
	If you store your sessions in the ActiveRecord session container you  
can query it like any other db table. So you can do a query for all  
the sessions that have no activity for 15 minutes or however long you  
want. Then use that info to delete the correct records.

	BackgrounDRb can be used to do what you want. But you may want to  
keep it simple and use script/runner and cron.


-Ezra







--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Ezra,

Thanks for responding.

Ezra Zygmuntowicz wrote:
> I think there is some confusion n the wiki. There is a DRb session
> container that you can use that comes with rails. BackgrounDRb is a
> rails plugin that I wrote for running long background tasks with hook
> for ajax progress bars or status updates in the browser.
The confusion may just be me.  I am looking for a way to run a background 
task that will ''run'' for a specified amount of time and then
invoke a
specified action in a specified controller in my Rails app.  The invoked 
action would be the same one that''s invoked when a visitor clicks the 
''logout'' button.
> BackgrounDRb has nothing to do with sessions and will not work
> as a session container.
Cool.
> Backgroundrb does have cron like workers. And you
> can manage them from your rails app.
I think that''s all I need.
> Are you marking your records with some kind of
> identifier so you can delete everything someone
> created? Or how will you know which objects
> to delete when you clean up after them?
The id of the session''s parent record is stored in the session.  Each
child
record is marked in the sense of having a foreign-key field.  Is that what 
you mean?
> If you store your sessions in the ActiveRecord session container you
> can query it like any other db table. So you can do a query for all
> the sessions that have no activity for 15 minutes or however long you
> want. Then use that info to delete the correct records.
Do you know of any resources available (online or print) that could help get 
me started here?
> BackgrounDRb can be used to do what you want.
I was just reading (and rereading) the DRb section in AWD, the archives at 
http://rubyforge.org/pipermail/backgroundrb-devel, and the documentation at 
http://backgroundrb.rubyforge.org/.  I''m hoping I''m not just
confusing
myself, but could it work like....

1) from the rails app, start a worker for a session with a timeout setting 
and a controller/action argument
2) every time the visitor interacts with the rails app, reset the
worker''s
timeout
3) when the timeout occurs, the worker invokes the controller/action in the 
rails app that was passed in at startup.
> But you may want to keep it simple and use
> script/runner and cron.
Right now it feels simpler, at least conceptually, to just start an external 
process that''s specific to that session and have it
''logout'' for the visitor
if the visitor doesn''t do it themselves. What do you think?  Is what I
want
to do possible?

Thank much for your advice!
Bill 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sep 11, 2006, at 1:44 PM, Bill Walton wrote:
>
> Hi Ezra,
>
> Thanks for responding.
>
> Ezra Zygmuntowicz wrote:
>
>> I think there is some confusion n the wiki. There is a DRb session
>> container that you can use that comes with rails. BackgrounDRb is a
>> rails plugin that I wrote for running long background tasks with hook
>> for ajax progress bars or status updates in the browser.
>
> The confusion may just be me.  I am looking for a way to run a  
> background
> task that will ''run'' for a specified amount of time and
then invoke a
> specified action in a specified controller in my Rails app.  The  
> invoked
> action would be the same one that''s invoked when a visitor clicks
the
> ''logout'' button.
Gotcha
>
>> BackgrounDRb has nothing to do with sessions and will not work
>> as a session container.
>
> Cool.
>
>> Backgroundrb does have cron like workers. And you
>> can manage them from your rails app.
>
> I think that''s all I need.
Could be for sure.
>
>> Are you marking your records with some kind of
>> identifier so you can delete everything someone
>> created? Or how will you know which objects
>> to delete when you clean up after them?
>
> The id of the session''s parent record is stored in the session.   
> Each child
> record is marked in the sense of having a foreign-key field.  Is  
> that what
> you mean?
Yup this is what I meant. Good.
>
>> If you store your sessions in the ActiveRecord session container you
>> can query it like any other db table. So you can do a query for all
>> the sessions that have no activity for 15 minutes or however long you
>> want. Then use that info to delete the correct records.
>
> Do you know of any resources available (online or print) that could  
> help get
> me started here?
http://wiki.rubyonrails.org/rails/pages/HowtoChangeSessionStore
>
>> BackgrounDRb can be used to do what you want.
>
> I was just reading (and rereading) the DRb section in AWD, the  
> archives at
> http://rubyforge.org/pipermail/backgroundrb-devel, and the  
> documentation at
> http://backgroundrb.rubyforge.org/.  I''m hoping I''m not
just confusing
> myself, but could it work like....
>
> 1) from the rails app, start a worker for a session with a timeout  
> setting
> and a controller/action argument
> 2) every time the visitor interacts with the rails app, reset the  
> worker''s
> timeout
> 3) when the timeout occurs, the worker invokes the controller/ 
> action in the
> rails app that was passed in at startup.
Something like this could work. The main issue is that backgroundrb  
doesn''t use http so it can''t really call a controller method
in your
app for you. You could just put a similar action in your worker class  
and call it there. But I think the best way for what you want to do  
would be to just stick with script/runner and a cron job. Lets assume  
that you want to log someone out if they haven''t had any activity on  
their session in 15 minutes or more.

1. Setup a method in your User model that will do a find on the  
updated_at column in the session table and return all sessions that  
were last updated more then 15 minutes ago. Then iterate over these  
records and delete them from the sessions table. Lets call this  
method ''session_sweep''

2. You setup a cron job that runs every 15.

3. Use this as the command for cron to run:

4. /usr/local/bin/ruby /full/path/to/yourapp/script/runner  
''User.session_sweep''

>
>> But you may want to keep it simple and use
>> script/runner and cron.
>
> Right now it feels simpler, at least conceptually, to just start an  
> external
> process that''s specific to that session and have it
''logout'' for
> the visitor
> if the visitor doesn''t do it themselves. What do you think?  Is  
> what I want
> to do possible?
>
> Thank much for your advice!
> Bill
	Ok all that being said, BackgrounDRb can do the same thing for you.  
But it does add another daemon you have to run all the time. So for a  
simple wake up every 15 minutes and call script/runner then quite,  
you will save cpu and memory. Also cron has been in use for many many  
years and has much more precise control over how you can specify  
timing rules. If you decide to go the BackgrounDRb route then please  
join the mailing list for it and I''ll do my best to help you along.


*Mailing list: http://rubyforge.org/mailman/listinfo/backgroundrb-devel


Cheers-
-Ezra




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Ezra,

Continuing our conversation from the Rails list.

Ezra Zygmuntowicz wrote:
<snip some very encouraging stuff>
> Bill Walton wrote:
> > ... but could it work like....
> >
> > 1) from the rails app, start a worker for a session
> >  with a timeout setting and a controller/action argument
> > 2) every time the visitor interacts with the rails app,
> > reset the worker''s timeout
> > 3) when the timeout occurs, the worker invokes the
> > controller/action in the rails app that was passed in at
> > startup.
> Something like this could work. The main issue is that
> backgroundrb doesn''t use http so it can''t really call a
> controller method in your app for you. You could just
> put a similar action in your worker class and call it there.
I''m not sure I''m understanding you here.  Are you saying put
the ''cleanup''
action that deletes the user-entered records and files in the worker?  If 
so, doesn''t that go against the DRY principle?  Or are you saying to
move it
from where it is now (in one of the app''s controllers) into a worker?

I''m definitely confused by your statement that "backgroundrb
doesn''t use
http so it can''t really call a controller method in your app".  I
understood
that workers could respond to Ajax requests.  Did I misunderstand?

To my limited understanding, if a worker''s job is to respond to Ajax 
requests, that means I can think of a backgroundrb worker as just another of 
the app''s controllers, albeit a ''special'' one because
it''s running in
parallel.  Am I ''courting danger'' with this simplistic view?

Now that we''ve talked about it a little, I guess if it *is* ok to think
about a worker as one of the app''s controllers, then the worker really
is
where I want to put the cleanup code.  I''m also assuming that a worker 
''knows'' what session it''s part of.  Is that right?

Does any of the way I''m thinking about this tell you I''m
heading off ''into
the weeds''?

<snip>
> Ok all that being said, BackgrounDRb can do the same
> thing for you. [...]  If you decide to go the BackgrounDRb
> route then please join the mailing list for it and I''ll do my
> best to help you along.
Well.... here I am! ;-)  And thank you.  You may yet convince me that the 
script/cron route is the way to go.  But first, I need to better understand 
what you''re telling me.  In the interest of full disclosure, until
finding
RoR around the first of this year, I''ve not done any serious
development in
a dozen years.  I''ve been managing it, but not doing it.  A lot has
changed
and I''m finding there are lots of details I need to learn.

Best regards,
Bill




*Mailing list: http://rubyforge.org/mailman/listinfo/backgroundrb-devel




Cheers-
-Ezra





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk at googlegroups.com
To unsubscribe from this group, send email to 
rubyonrails-talk-unsubscribe at googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Ezra,

Ezra Zygmuntowicz wrote:
> Ok all that being said, BackgrounDRb can do
> the same thing for you. [...] If you decide to go
> the BackgrounDRb route then please join the
> mailing list for it and I''ll do my best to help you along.
I''ve joined the BackgrounDRb mailing list and have responded there. 
Thanks!

Bill 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

Hi Bill~

On Sep 12, 2006, at 7:45 AM, Bill Walton wrote:
> Hi Ezra,
>
> Continuing our conversation from the Rails list.

Welcome ;)
>
> Ezra Zygmuntowicz wrote:
> <snip some very encouraging stuff>
>
> I''m not sure I''m understanding you here.  Are you saying
put the
> ''cleanup''
> action that deletes the user-entered records and files in the  
> worker?  If
> so, doesn''t that go against the DRY principle?  Or are you saying
> to move it
> from where it is now (in one of the app''s controllers) into a
worker?
>
> I''m definitely confused by your statement that "backgroundrb
> doesn''t use
> http so it can''t really call a controller method in your
app".  I
> understood
> that workers could respond to Ajax requests.  Did I misunderstand?
>
> To my limited understanding, if a worker''s job is to respond to
Ajax
> requests, that means I can think of a backgroundrb worker as just  
> another of
> the app''s controllers, albeit a ''special'' one
because it''s running in
> parallel.  Am I ''courting danger'' with this simplistic
view?
>
> Now that we''ve talked about it a little, I guess if it *is* ok to
> think
> about a worker as one of the app''s controllers, then the worker  
> really is
> where I want to put the cleanup code.  I''m also assuming that a
worker
> ''knows'' what session it''s part of.  Is that
right?
>
> Does any of the way I''m thinking about this tell you I''m
heading
> off ''into
> the weeds''?
	Yes you have a few incorrect notions, let''s see if I can clear  
things up for you a bit. Your backgroundrb worker are not rails  
controllers at all and they do not directly respond to ajax calls. In  
your rails app you have access to the MiddleMan object that you can  
use to start workers in the drb server and ping them for results  
later during the ajax requests. But the http requests have to come  
into a normal rails controller, the in a controller action you can  
use MiddleMan to grab a handle on your remote worker object and call  
methods or get vars from it.

	So yes if you are going to be using backgroundrb to do this cleanup  
project I would move the cleanup code into a worker class and remove  
it from your main app. Then in your rails app when you need to call  
the cleanup worker, you use the MiddleMan to do so. And then in the  
cleanup worker you could have a timer that wakes up every X minutes  
and does the cleanup for users who left their session dangling.

	So a worker class might look like this:

class CleanupWorker < BackgrounDRb::Rails

   repeat_every 15.minutes
   first_run Time.now

   def do_work(args)
      # pull the id out of args and do the cleanup
      # or if there is no args then just look for session older then  
X minutes and clean them up.
   end

end

	Then you would want to autostart this worker so it runs on boot up.  
So you would add this to your backgroundrb.yml config  file:

autostart:
   1:
     job_key: cleanup
     class: cleanup_worker


	And then to access this from your rails app when someone logs out  
explicitely

# in a controller or model method

def cleanup(user_id)
   MiddleMan.new_worker :class => :cleanup_worker,
                                                :args => user_id,
                                                :ttl => 120
end

	So now when you call that action, the drb server will create a new  
cleaup worker and pass in the user_id so you can cleanup after that  
user.
>
> <snip>
>
>> Ok all that being said, BackgrounDRb can do the same
>> thing for you. [...]  If you decide to go the BackgrounDRb
>> route then please join the mailing list for it and I''ll do my
>> best to help you along.
>
> Well.... here I am! ;-)  And thank you.  You may yet convince me  
> that the
> script/cron route is the way to go.  But first, I need to better  
> understand
> what you''re telling me.  In the interest of full disclosure, until
> finding
> RoR around the first of this year, I''ve not done any serious  
> development in
> a dozen years.  I''ve been managing it, but not doing it.  A lot
has
> changed
> and I''m finding there are lots of details I need to learn.
>
> Best regards,
> Bill
	So IU hope that explains it a bit better. You could go either way  
with this. BackgrounDRb will certainly work for what you need to do.  
But since this is more like a fire and forget type of job, it is less  
moving parts to just use a cron job and a script/runner  script that  
fires the cleanup code. Its up to you which direction to take. I''ll  
try to help as much as I can.

Cheers-
-Ezra

Hi Ezra,

Ezra Zygmuntowicz wrote:
>> Continuing our conversation from the Rails list.
>
> Welcome ;)
Thanks!
>> Does any of the way I''m thinking about this tell you
I''m heading off
>> ''into the weeds''?
>
> Yes you have a few incorrect notions,
I was afraid of that ;-)
> let''s see if I can clear things up for you a bit.
I really appreciate it.  I should warn you though.  Sometimes even *I* am 
surprised by my density ;-)
> Your backgroundrb worker are not rails controllers at all and they do not 
> directly respond to ajax calls. In your rails app you have access to the 
> MiddleMan object that you can  use to start workers in the drb server and 
> ping them for results  later during the ajax requests.
If I can ping the worker from the controller and they can respond and my 
controller can receive and process their response, and they''re sitting
out
there running and waiting to respond, I''m not getting why they
couldn''t
*initiate* a ''conversation''.  Is this a ''we
don''t have a tool built to do
that'' situation?  Or is it ''the Rails architecture
doesn''t allow for that
kind of interprocess communication'' situation?

<snip>
> So IU hope that explains it a bit better.
I have a much better understanding of how to use BackgrounDRb.  Thank you. 
But I''m still confused ;-(

I think, maybe, my confusion comes from associating (in my mind) 
BackgrounDRb and dRuby (drb) as discussed in "Programming Ruby".  The
DRb
class description (p.670) says "Although expressed in terms of clients and 
servers, once the initial connection is established, the protocol is 
effectively symmetrical: either side can invoke methods in objects on the 
other side."  Could you shed some light on this for me?

Thanks!
Bill

On Sep 13, 2006, at 7:38 AM, Bill Walton wrote:
> Hi Ezra,
>
> Ezra Zygmuntowicz wrote:
>
>>> Continuing our conversation from the Rails list.
>>
>> Welcome ;)
>
> Thanks!
>
>>> Does any of the way I''m thinking about this tell you
I''m heading
>>> off ''into the weeds''?
>>
>> Yes you have a few incorrect notions,
>
> I was afraid of that ;-)
>
>> let''s see if I can clear things up for you a bit.
>
> I really appreciate it.  I should warn you though.  Sometimes even  
> *I* am surprised by my density ;-)
>
>> Your backgroundrb worker are not rails controllers at all and they  
>> do not directly respond to ajax calls. In your rails app you have  
>> access to the MiddleMan object that you can  use to start workers  
>> in the drb server and ping them for results  later during the ajax  
>> requests.
>
> If I can ping the worker from the controller and they can respond  
> and my controller can receive and process their response, and  
> they''re sitting out there running and waiting to respond,
I''m not
> getting why they couldn''t *initiate* a
''conversation''.  Is this a
> ''we don''t have a tool built to do that''
situation?  Or is it ''the
> Rails architecture doesn''t allow for that kind of interprocess  
> communication'' situation?
	I''m just not sure what you are trying to accomplish with this. I  
think you are making it way more difficult ;) The way backgroundrb  
works is mainly a one way thing. You kick off the workers from your  
controller and then you can ping the worker later from your  
controller to get status or results from it. If you really feel you  
need to call back to your controller from the bgdrb server, you could  
use net/http in ruby''s standard library top make a http request back  
to the rails app.

	The problem with trying to talk back to rails from the drb server is  
that rails is not persistent. Each request instantiates a new  
controller object. So if you try to callback to rails from bdrb, you  
aren''t garanteed to get the same controller object to work with. So  
bdrb works by letting rails control it. You kick off your worker  
classes with a command in your controller and then you store a job  
key in your sessions. Then on later requests in rails you can use  
this job key to grab a handle on your worker object and call methods  
on it for results.
>
> <snip>
>
>> So IU hope that explains it a bit better.
>
> I have a much better understanding of how to use BackgrounDRb.   
> Thank you. But I''m still confused ;-(
>
> I think, maybe, my confusion comes from associating (in my mind)  
> BackgrounDRb and dRuby (drb) as discussed in "Programming Ruby".
> The DRb class description (p.670) says "Although expressed in terms  
> of clients and servers, once the initial connection is established,  
> the protocol is effectively symmetrical: either side can invoke  
> methods in objects on the other side."  Could you shed some light  
> on this for me?
	Yes BackgrounDRb uses drb to do its work. But the way it is designed  
is for use with the way rails works. Its a persistent daemon that  
runs your jobs. Your rails controllers and models are all  
instantiated on each request so they don''t persist and thats why you  
need a session.

	So yes its true that the way drb works is that both ends effectively  
become servers and clients. But because rails is a web app, and the  
way request/response and object instantiation in rails works, you  
can''t really call back to rails from backgroundrb. Because the place  
you would be trying to call back to won''t exist after its request is  
served.


Cheers-
-Ezra

Hi Ezra,

Ezra Zygmuntowicz wrote:
>
> I''m just not sure what you are trying to accomplish with this.
My bad.

In ''normal'' session management the goal is to shut off visitor
access after
a set period of time.  Data removal is a secondary concern.

I''m working to a requirement that says "shutting off visitor
access and
removing the data they''ve entered from the system need to happen at the
same
time, and both need to happen when we say they''re going to
happen."

Sweeping the system with a cron job doesn''t accomplish that.  If, for 
example, the timeout is set for 5 minutes, and the cron job runs every five 
minutes, some visitors will time out in 5 minutes and some will time out in 
9:59 minutes.
> I  think you are making it way more difficult ;)
What do you think now?  If there''s an easier way, I''m dying to
be educated!
;-)
> If you really feel you need to call back to your controller from the bgdrb 
> server, you could use net/http in ruby''s standard library top make
a http
> request back  to the rails app.
Now we''re talkin''!!!  I''ll dig into it.
> The problem with trying to talk back to rails from the drb server is that 
> rails is not persistent. Each request instantiates a new controller 
> object.
I understand.  I was hoping that if I started a DRb server from within the 
controller to listen for a call from a remote client, that Rails would 
somehow keep the controller ''alive'' at some level.  I guess
not.

You''ve given me some hope though by pointing me to the net/http
library.  My
understanding is that Rails knows what objects to use based on a session id 
that gets passed as part of the message header.  Is that right?  If it is, 
then it seems like if I send a logout message with the ''right''
header, Rails
won''t know whether or not the request actually came from the visitor 
clicking the logout button.  I guess, in the end, what I''m trying to do
is
an ''authorized'' session hijacking by an surrogate whose only
job is to make
sure everything gets cleaned up as required.

If I''ve said anything else that doesn''t make sense, please
feel free to
''slap me around'' a little ;-)

I''ll be back, with more questions I''m sure ;-), after
I''ve studied the
net/http library.

Thanks!
Bill

Hi Michael,

Michael Siebert  wrote:
> 2006/9/14, Bill Walton <bill.walton at charter.net>:
> > I''m working to a requirement that says "shutting off
visitor
> > access and removing the data they''ve entered from the
> > system need to happen at the same time, and both need
> > to happen when we say they''re going to happen."
> unfortunately this aproach doesnt delete the data if the user
> just leaves the site and doesnt come back.
Exactly.
> here you could use a cronjob of some sort.
Which, as I noted earlier, would not satisfy the last portion of the 
requirement above.
> <snip> every other thing would by a hackery of some type
Precisely what this requirement is about protecting against.
> think your problem is that you absolutely wanted to use
> bgdrb and did not see other obvious solutions like what
> i said...
I understand that interpretation ...
> but possibly thats just crap too :)
I wouldn''t call it crap.  I would say that this is a very unusual 
requirement that seems to require that I take a different approach than I 
would under normal circumstances.

<snip>
> the session id is stored in a cookie and that is transfered
> in the header. slight difference :
In Ruby (as opposed to Rails), is there an easy way for an application to 
explicitly set the cookie to a specific value?  I can''t seem to zero in
on
how to do that.

Thanks!
Bill

Hi Michael,

Michael Siebert wrote:
> erm... i have an idea...
> use activerecord session store and when the
> user logs in, create a bgdrb worker. this worker
> is responsible for deleting the users session and
> data after a certain amount of time (the timeout).
That''s pretty much Ezra suggested earlier.
> now, in a before_filter, get your worker (hope
> you saved the worker id) and update the timeout
> somehow.
Yep.
> would that aproach satisfy all of your requirements?
I''m still getting my arms around how it would work, exactly, but I
think
this is the track I''m going to take.  The worker will be responsible
for
deleting the session whether the visitor explicitly logs out, times out with 
their browser still open, or abandons the session by closing/redirecting the 
browser.

I''ve not done much with processing in the model and that''s
probably a
material part of why I''m having trouble with getting my arms around how
this
would work.  As long as I can delete the files referenced in the DB before 
the DB record that identifies them gets deleted it should work.

Thanks for your help!
Bill

> But I think the best way for what you want to do
> would be to just stick with script/runner and a cron job. Lets assume
> that you want to log someone out if they haven''t had any activity
on
> their session in 15 minutes or more.
> 
> 1. Setup a method in your User model that will do a find on the
> updated_at column in the session table and return all sessions that
> were last updated more then 15 minutes ago. Then iterate over these
> records and delete them from the sessions table. Lets call this
> method ''session_sweep''
> 
> 2. You setup a cron job that runs every 15.
> 
> 3. Use this as the command for cron to run:
> 
> 4. /usr/local/bin/ruby /full/path/to/yourapp/script/runner
> ''User.session_sweep''
I''m thinking about using BackgrounDRb too.  I would probably need it to
run once every 5 minutes (to send out email and to check for records 
older than 5 minutes).

Do you think it''d be better to use a cron job for this, or would 
backgrounDRb be good for this?  The background tasks I want to run are 
not long-running tasks, so would it be better to just use a cron job?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hey Joe -

On 5-Jul-07, at 10:07 AM, Joe Peck wrote:
>
>> But I think the best way for what you want to do
>> would be to just stick with script/runner and a cron job. Lets assume
>> that you want to log someone out if they haven''t had any
activity on
>> their session in 15 minutes or more.
>>
>> 1. Setup a method in your User model that will do a find on the
>> updated_at column in the session table and return all sessions that
>> were last updated more then 15 minutes ago. Then iterate over these
>> records and delete them from the sessions table. Lets call this
>> method ''session_sweep''
>>
>> 2. You setup a cron job that runs every 15.
>>
>> 3. Use this as the command for cron to run:
>>
>> 4. /usr/local/bin/ruby /full/path/to/yourapp/script/runner
>> ''User.session_sweep''
> I''m thinking about using BackgrounDRb too.  I would probably need
> it to
> run once every 5 minutes (to send out email and to check for records
> older than 5 minutes).
>
> Do you think it''d be better to use a cron job for this, or would
> backgrounDRb be good for this?  The background tasks I want to run are
> not long-running tasks, so would it be better to just use a cron job?
>
>
First I want to say that I''m a big fan of Ezra & brb, but of late
it
isn''t getting much attention - so if you run into problems/bugs you  
may not get much support.

Additionally I''ve had a terrible time getting a brb deploy stable -  
be that application of brb issues I''m not sure - but my test coverage  
is quite good and brb is reporting that it can''t find worker tasks  
and will die. Monit has been deployed to keep brb up, but there also  
seems to be a bug where the ppid written isn''t always the actual  
running brb process id - so monit launches another instance (and  
well, eventually I''ll have a few running...)

Having said the above, many people are running brb it quite nicely...

Myself I may be turning to cron as I don''t need the app_server to  
deliver or communicate with workers.

hopefully the above arms you with more info for your decision making.

I would suggest you read over the traffic on the brb mailing list[1].

cheers,
Jodi

[1] http://rubyforge.org/pipermail/backgroundrb-devel/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---