I don''t know if anyone is using this but I just fixed a bunch of bugs,
some
big ones, and moved this project to RubyForge SVN servers.
So you can get it here now:
script/plugin install
http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/
This is working great for me on a couple of projects.
Here is the README
Updated: 3/14/2008
Purpose:
The purpose of FacebookerMQ is to provide an async method for performing
time consuming
Facebook API requests. The Facebook platform is very sensitive to long
running requests,
and as such it becomes important to offload some of these requests to a
background process.
As the name suggests this plugin relies on the facebooker api ( gem install
facebooker ).
Overview:
FacebookerMQ intercepts Facebooker calls into session.publish(method,
params) and saves all the relevant data
to the database. This is inspired by the ar_mailer project which does the
same for ActionMailer. In order
to process the queue you can setup a cron job to run script/runner
FacebookerMqRunner.work().
What you need:
1) script/plugin install
http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/
2) You will need a migration to create the table that holds the messages.
You can think if this table as the queue
class CreateFacebookMessages < ActiveRecord::Migration
def self.up
create_table :facebook_messages do |t|
t.column(:session_key, :string, :null => false)
t.column(:expires, :string, :null => false, :default =>
"0")
t.column(:uid, :integer, :null => false)
t.column(:api_method, :string, :null => false)
t.column(:params, :text, :null => false ) # Always a hash.
t.column(:state, :string, :null => false, :default =>
''new'' )
t.column(:send_after, :datetime, :null => false, :default =>
Time.at(0)) # Optional date time to wait until you send
t.column( :last_send_attempt, :datetime )
t.column( :send_attempts, :integer, :default => 0 , :null =>
false
)
t.column( :facebook_errors, :text, :default => "")
t.column( :response_xml, :text, :default => "")
t.timestamps
end
end
def self.down
drop_table :facebook_messages
end
end
3) Cronjob or some other way to fire off FacebookerMqRunner.work()
Misc:
Look in facebooker_session_override.rb and you will see all the api methods
that are currently offloaded to the queue.
This can be added to or removed from by calling Facebooker::
Session.async_method or Facebooker::Session.sync_method
I am kinda hoping to get this pushed into the Facebooker source so that it
can be a config option. If not I will setup
a rubyforge project and change the URL
This is a work in progress and any comments or code is totally welcome. It
has been developed from a couple of projects
that I am currently working on.
TODO:
1) I think some of the options such as the max number of failure, which
methods to intercept and table name should be configurable.
2) I think that it would be good to work out some admin view of the queue.
3) Make sure that it works well with multiple runner instances.
4) Remove the need to run this within the RAILS_ENV
5) Create a gem like ar_mailer has.
6) Implement saving response and using a callback to do something with the
response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/9af0d852/attachment.html
Nice work. But would you run into issues with publishing feeds? Since they have to be publish while the user is actively logged in now? Shane On Fri, Mar 14, 2008 at 2:38 PM, David Clements <digidigo at gmail.com> wrote:> I don''t know if anyone is using this but I just fixed a bunch of bugs, some > big ones, and moved this project to RubyForge SVN servers. > > So you can get it here now: > > script/plugin install > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > This is working great for me on a couple of projects. > > Here is the README > > Updated: 3/14/2008 > > Purpose: > The purpose of FacebookerMQ is to provide an async method for performing > time consuming > Facebook API requests. The Facebook platform is very sensitive to long > running requests, > and as such it becomes important to offload some of these requests to a > background process. > As the name suggests this plugin relies on the facebooker api ( gem install > facebooker ). > > Overview: > > FacebookerMQ intercepts Facebooker calls into session.publish(method, > params) and saves all the relevant data > to the database. This is inspired by the ar_mailer project which does the > same for ActionMailer. In order > to process the queue you can setup a cron job to run script/runner > FacebookerMqRunner.work(). > > What you need: > > 1) script/plugin install > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > 2) You will need a migration to create the table that holds the messages. > You can think if this table as the queue > > class CreateFacebookMessages < ActiveRecord::Migration > def self.up > create_table :facebook_messages do |t| > t.column(:session_key, :string, :null => false) > t.column(:expires, :string, :null => false, :default => "0") > t.column(:uid, :integer, :null => false) > t.column(:api_method, :string, :null => false) > t.column(:params, :text, :null => false ) # Always a hash. > t.column(:state, :string, :null => false, :default => ''new'' ) > t.column(:send_after, :datetime, :null => false, :default => > Time.at(0)) # Optional date time to wait until you send > t.column( :last_send_attempt, :datetime ) > t.column( :send_attempts, :integer, :default => 0 , :null => false > ) > t.column( :facebook_errors, :text, :default => "") > t.column( :response_xml, :text, :default => "") > t.timestamps > end > end > > def self.down > drop_table :facebook_messages > end > end > > 3) Cronjob or some other way to fire off FacebookerMqRunner.work() > > > Misc: > > Look in facebooker_session_override.rb and you will see all the api methods > that are currently offloaded to the queue. > This can be added to or removed from by calling > Facebooker::Session.async_method or Facebooker::Session.sync_method > > I am kinda hoping to get this pushed into the Facebooker source so that it > can be a config option. If not I will setup > a rubyforge project and change the URL > > This is a work in progress and any comments or code is totally welcome. It > has been developed from a couple of projects > that I am currently working on. > > > TODO: > > 1) I think some of the options such as the max number of failure, which > methods to intercept and table name should be configurable. > 2) I think that it would be good to work out some admin view of the queue. > 3) Make sure that it works well with multiple runner instances. > 4) Remove the need to run this within the RAILS_ENV > 5) Create a gem like ar_mailer has. > 6) Implement saving response and using a callback to do something with the > response. > > > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > >-- http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com
That is interesting. I haven''t run into that. But for me feeds get updated within a minute or so , as I run the cron job every minute. Do you know how they detect that the user is logged in? Dave On Fri, Mar 14, 2008 at 1:45 PM, Shane Vitarana <shanev at gmail.com> wrote:> Nice work. But would you run into issues with publishing feeds? Since > they have to be publish while the user is actively logged in now? > > Shane > > On Fri, Mar 14, 2008 at 2:38 PM, David Clements <digidigo at gmail.com> > wrote: > > I don''t know if anyone is using this but I just fixed a bunch of bugs, > some > > big ones, and moved this project to RubyForge SVN servers. > > > > So you can get it here now: > > > > script/plugin install > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > This is working great for me on a couple of projects. > > > > Here is the README > > > > Updated: 3/14/2008 > > > > Purpose: > > The purpose of FacebookerMQ is to provide an async method for performing > > time consuming > > Facebook API requests. The Facebook platform is very sensitive to long > > running requests, > > and as such it becomes important to offload some of these requests to a > > background process. > > As the name suggests this plugin relies on the facebooker api ( gem > install > > facebooker ). > > > > Overview: > > > > FacebookerMQ intercepts Facebooker calls into session.publish(method, > > params) and saves all the relevant data > > to the database. This is inspired by the ar_mailer project which does > the > > same for ActionMailer. In order > > to process the queue you can setup a cron job to run script/runner > > FacebookerMqRunner.work(). > > > > What you need: > > > > 1) script/plugin install > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > 2) You will need a migration to create the table that holds the > messages. > > You can think if this table as the queue > > > > class CreateFacebookMessages < ActiveRecord::Migration > > def self.up > > create_table :facebook_messages do |t| > > t.column(:session_key, :string, :null => false) > > t.column(:expires, :string, :null => false, :default => "0") > > t.column(:uid, :integer, :null => false) > > t.column(:api_method, :string, :null => false) > > t.column(:params, :text, :null => false ) # Always a hash. > > t.column(:state, :string, :null => false, :default => ''new'' ) > > t.column(:send_after, :datetime, :null => false, :default => > > Time.at(0)) # Optional date time to wait until you send > > t.column( :last_send_attempt, :datetime ) > > t.column( :send_attempts, :integer, :default => 0 , :null => > false > > ) > > t.column( :facebook_errors, :text, :default => "") > > t.column( :response_xml, :text, :default => "") > > t.timestamps > > end > > end > > > > def self.down > > drop_table :facebook_messages > > end > > end > > > > 3) Cronjob or some other way to fire off FacebookerMqRunner.work() > > > > > > Misc: > > > > Look in facebooker_session_override.rb and you will see all the api > methods > > that are currently offloaded to the queue. > > This can be added to or removed from by calling > > Facebooker::Session.async_method or Facebooker::Session.sync_method > > > > I am kinda hoping to get this pushed into the Facebooker source so that > it > > can be a config option. If not I will setup > > a rubyforge project and change the URL > > > > This is a work in progress and any comments or code is totally welcome. > It > > has been developed from a couple of projects > > that I am currently working on. > > > > > > TODO: > > > > 1) I think some of the options such as the max number of failure, which > > methods to intercept and table name should be configurable. > > 2) I think that it would be good to work out some admin view of the > queue. > > 3) Make sure that it works well with multiple runner instances. > > 4) Remove the need to run this within the RAILS_ENV > > 5) Create a gem like ar_mailer has. > > 6) Implement saving response and using a callback to do something with > the > > response. > > > > > > > > > > > > _______________________________________________ > > Facebooker-talk mailing list > > Facebooker-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > > -- > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/96274280/attachment.html
Not sure how they do it. I think it should be fine if it is run every minute though. On Fri, Mar 14, 2008 at 2:47 PM, David Clements <digidigo at gmail.com> wrote:> That is interesting. I haven''t run into that. But for me feeds get > updated within a minute or so , as I run the cron job every minute. > Do you know how they detect that the user is logged in? > > > Dave > > > > On Fri, Mar 14, 2008 at 1:45 PM, Shane Vitarana <shanev at gmail.com> wrote: > > Nice work. But would you run into issues with publishing feeds? Since > > they have to be publish while the user is actively logged in now? > > > > Shane > > > > > > > > > > On Fri, Mar 14, 2008 at 2:38 PM, David Clements <digidigo at gmail.com> > wrote: > > > I don''t know if anyone is using this but I just fixed a bunch of bugs, > some > > > big ones, and moved this project to RubyForge SVN servers. > > > > > > So you can get it here now: > > > > > > script/plugin install > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > This is working great for me on a couple of projects. > > > > > > Here is the README > > > > > > Updated: 3/14/2008 > > > > > > Purpose: > > > The purpose of FacebookerMQ is to provide an async method for performing > > > time consuming > > > Facebook API requests. The Facebook platform is very sensitive to long > > > running requests, > > > and as such it becomes important to offload some of these requests to a > > > background process. > > > As the name suggests this plugin relies on the facebooker api ( gem > install > > > facebooker ). > > > > > > Overview: > > > > > > FacebookerMQ intercepts Facebooker calls into session.publish(method, > > > params) and saves all the relevant data > > > to the database. This is inspired by the ar_mailer project which does > the > > > same for ActionMailer. In order > > > to process the queue you can setup a cron job to run script/runner > > > FacebookerMqRunner.work(). > > > > > > What you need: > > > > > > 1) script/plugin install > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > > > 2) You will need a migration to create the table that holds the > messages. > > > You can think if this table as the queue > > > > > > class CreateFacebookMessages < ActiveRecord::Migration > > > def self.up > > > create_table :facebook_messages do |t| > > > t.column(:session_key, :string, :null => false) > > > t.column(:expires, :string, :null => false, :default => "0") > > > t.column(:uid, :integer, :null => false) > > > t.column(:api_method, :string, :null => false) > > > t.column(:params, :text, :null => false ) # Always a hash. > > > t.column(:state, :string, :null => false, :default => ''new'' ) > > > t.column(:send_after, :datetime, :null => false, :default => > > > Time.at(0)) # Optional date time to wait until you send > > > t.column( :last_send_attempt, :datetime ) > > > t.column( :send_attempts, :integer, :default => 0 , :null => > false > > > ) > > > t.column( :facebook_errors, :text, :default => "") > > > t.column( :response_xml, :text, :default => "") > > > t.timestamps > > > end > > > end > > > > > > def self.down > > > drop_table :facebook_messages > > > end > > > end > > > > > > 3) Cronjob or some other way to fire off FacebookerMqRunner.work() > > > > > > > > > Misc: > > > > > > Look in facebooker_session_override.rb and you will see all the api > methods > > > that are currently offloaded to the queue. > > > This can be added to or removed from by calling > > > Facebooker::Session.async_method or Facebooker::Session.sync_method > > > > > > I am kinda hoping to get this pushed into the Facebooker source so that > it > > > can be a config option. If not I will setup > > > a rubyforge project and change the URL > > > > > > This is a work in progress and any comments or code is totally welcome. > It > > > has been developed from a couple of projects > > > that I am currently working on. > > > > > > > > > TODO: > > > > > > 1) I think some of the options such as the max number of failure, which > > > methods to intercept and table name should be configurable. > > > 2) I think that it would be good to work out some admin view of the > queue. > > > 3) Make sure that it works well with multiple runner instances. > > > 4) Remove the need to run this within the RAILS_ENV > > > 5) Create a gem like ar_mailer has. > > > 6) Implement saving response and using a callback to do something with > the > > > response. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Facebooker-talk mailing list > > > Facebooker-talk at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > > > > > > > > -- > > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com > > > >-- http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com
Yeah, main reason is to not get hung up during the request cycle talking to facebook api. I need to better detect errors though so that I can see if Facebook is denying my request. Dave On Fri, Mar 14, 2008 at 1:57 PM, Shane Vitarana <shanev at gmail.com> wrote:> Not sure how they do it. I think it should be fine if it is run every > minute though. > > On Fri, Mar 14, 2008 at 2:47 PM, David Clements <digidigo at gmail.com> > wrote: > > That is interesting. I haven''t run into that. But for me feeds get > > updated within a minute or so , as I run the cron job every minute. > > Do you know how they detect that the user is logged in? > > > > > > Dave > > > > > > > > On Fri, Mar 14, 2008 at 1:45 PM, Shane Vitarana <shanev at gmail.com> > wrote: > > > Nice work. But would you run into issues with publishing feeds? Since > > > they have to be publish while the user is actively logged in now? > > > > > > Shane > > > > > > > > > > > > > > > On Fri, Mar 14, 2008 at 2:38 PM, David Clements <digidigo at gmail.com> > > wrote: > > > > I don''t know if anyone is using this but I just fixed a bunch of > bugs, > > some > > > > big ones, and moved this project to RubyForge SVN servers. > > > > > > > > So you can get it here now: > > > > > > > > script/plugin install > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > This is working great for me on a couple of projects. > > > > > > > > Here is the README > > > > > > > > Updated: 3/14/2008 > > > > > > > > Purpose: > > > > The purpose of FacebookerMQ is to provide an async method for > performing > > > > time consuming > > > > Facebook API requests. The Facebook platform is very sensitive to > long > > > > running requests, > > > > and as such it becomes important to offload some of these requests > to a > > > > background process. > > > > As the name suggests this plugin relies on the facebooker api ( gem > > install > > > > facebooker ). > > > > > > > > Overview: > > > > > > > > FacebookerMQ intercepts Facebooker calls into session.publish > (method, > > > > params) and saves all the relevant data > > > > to the database. This is inspired by the ar_mailer project which > does > > the > > > > same for ActionMailer. In order > > > > to process the queue you can setup a cron job to run script/runner > > > > FacebookerMqRunner.work(). > > > > > > > > What you need: > > > > > > > > 1) script/plugin install > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > > > > > > > 2) You will need a migration to create the table that holds the > > messages. > > > > You can think if this table as the queue > > > > > > > > class CreateFacebookMessages < ActiveRecord::Migration > > > > def self.up > > > > create_table :facebook_messages do |t| > > > > t.column(:session_key, :string, :null => false) > > > > t.column(:expires, :string, :null => false, :default => > "0") > > > > t.column(:uid, :integer, :null => false) > > > > t.column(:api_method, :string, :null => false) > > > > t.column(:params, :text, :null => false ) # Always a > hash. > > > > t.column(:state, :string, :null => false, :default => ''new'' > ) > > > > t.column(:send_after, :datetime, :null => false, :default > => > > > > Time.at(0)) # Optional date time to wait until you send > > > > t.column( :last_send_attempt, :datetime ) > > > > t.column( :send_attempts, :integer, :default => 0 , :null > => > > false > > > > ) > > > > t.column( :facebook_errors, :text, :default => "") > > > > t.column( :response_xml, :text, :default => "") > > > > t.timestamps > > > > end > > > > end > > > > > > > > def self.down > > > > drop_table :facebook_messages > > > > end > > > > end > > > > > > > > 3) Cronjob or some other way to fire off FacebookerMqRunner.work() > > > > > > > > > > > > Misc: > > > > > > > > Look in facebooker_session_override.rb and you will see all the api > > methods > > > > that are currently offloaded to the queue. > > > > This can be added to or removed from by calling > > > > Facebooker::Session.async_method or Facebooker::Session.sync_method > > > > > > > > I am kinda hoping to get this pushed into the Facebooker source so > that > > it > > > > can be a config option. If not I will setup > > > > a rubyforge project and change the URL > > > > > > > > This is a work in progress and any comments or code is totally > welcome. > > It > > > > has been developed from a couple of projects > > > > that I am currently working on. > > > > > > > > > > > > TODO: > > > > > > > > 1) I think some of the options such as the max number of failure, > which > > > > methods to intercept and table name should be configurable. > > > > 2) I think that it would be good to work out some admin view of the > > queue. > > > > 3) Make sure that it works well with multiple runner instances. > > > > 4) Remove the need to run this within the RAILS_ENV > > > > 5) Create a gem like ar_mailer has. > > > > 6) Implement saving response and using a callback to do something > with > > the > > > > response. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Facebooker-talk mailing list > > > > Facebooker-talk at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > > > > > > > > > > > > > > -- > > > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com > > > > > > > > > > > -- > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/33cbbf24/attachment-0001.html
David, this seems like a great idea. I''ve been using Spawn to kick off various things like this in my code. It has worked well so far, and alleviates the need for a cron job. As for the publishing thing, I wonder about that. Does the user truly have to be interactively logged in, or can you simply use their infinite session key? On 3/14/08, David Clements <digidigo at gmail.com> wrote:> > Yeah, main reason is to not get hung up during the request cycle talking > to facebook api. I need to better detect errors though so that I can see if > Facebook is denying my request. > > > Dave > > > On Fri, Mar 14, 2008 at 1:57 PM, Shane Vitarana <shanev at gmail.com> wrote: > > > Not sure how they do it. I think it should be fine if it is run every > > minute though. > > > > On Fri, Mar 14, 2008 at 2:47 PM, David Clements <digidigo at gmail.com> > > wrote: > > > That is interesting. I haven''t run into that. But for me feeds get > > > updated within a minute or so , as I run the cron job every minute. > > > Do you know how they detect that the user is logged in? > > > > > > > > > Dave > > > > > > > > > > > > On Fri, Mar 14, 2008 at 1:45 PM, Shane Vitarana <shanev at gmail.com> > > wrote: > > > > Nice work. But would you run into issues with publishing feeds? > > Since > > > > they have to be publish while the user is actively logged in now? > > > > > > > > Shane > > > > > > > > > > > > > > > > > > > > On Fri, Mar 14, 2008 at 2:38 PM, David Clements <digidigo at gmail.com> > > > wrote: > > > > > I don''t know if anyone is using this but I just fixed a bunch of > > bugs, > > > some > > > > > big ones, and moved this project to RubyForge SVN servers. > > > > > > > > > > So you can get it here now: > > > > > > > > > > script/plugin install > > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > This is working great for me on a couple of projects. > > > > > > > > > > Here is the README > > > > > > > > > > Updated: 3/14/2008 > > > > > > > > > > Purpose: > > > > > The purpose of FacebookerMQ is to provide an async method for > > performing > > > > > time consuming > > > > > Facebook API requests. The Facebook platform is very sensitive to > > long > > > > > running requests, > > > > > and as such it becomes important to offload some of these requests > > to a > > > > > background process. > > > > > As the name suggests this plugin relies on the facebooker api ( > > gem > > > install > > > > > facebooker ). > > > > > > > > > > Overview: > > > > > > > > > > FacebookerMQ intercepts Facebooker calls into session.publish > > (method, > > > > > params) and saves all the relevant data > > > > > to the database. This is inspired by the ar_mailer project which > > does > > > the > > > > > same for ActionMailer. In order > > > > > to process the queue you can setup a cron job to run > > script/runner > > > > > FacebookerMqRunner.work(). > > > > > > > > > > What you need: > > > > > > > > > > 1) script/plugin install > > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > > > > > > > > > > > 2) You will need a migration to create the table that holds the > > > messages. > > > > > You can think if this table as the queue > > > > > > > > > > class CreateFacebookMessages < ActiveRecord::Migration > > > > > def self.up > > > > > create_table :facebook_messages do |t| > > > > > t.column(:session_key, :string, :null => false) > > > > > t.column(:expires, :string, :null => false, :default => > > "0") > > > > > t.column(:uid, :integer, :null => false) > > > > > t.column(:api_method, :string, :null => false) > > > > > t.column(:params, :text, :null => false ) # Always a > > hash. > > > > > t.column(:state, :string, :null => false, :default => > > ''new'' ) > > > > > t.column(:send_after, :datetime, :null => false, > > :default => > > > > > Time.at(0)) # Optional date time to wait until you send > > > > > t.column( :last_send_attempt, :datetime ) > > > > > t.column( :send_attempts, :integer, :default => 0 , :null > > => > > > false > > > > > ) > > > > > t.column( :facebook_errors, :text, :default => "") > > > > > t.column( :response_xml, :text, :default => "") > > > > > t.timestamps > > > > > end > > > > > end > > > > > > > > > > def self.down > > > > > drop_table :facebook_messages > > > > > end > > > > > end > > > > > > > > > > 3) Cronjob or some other way to fire off FacebookerMqRunner.work > > () > > > > > > > > > > > > > > > Misc: > > > > > > > > > > Look in facebooker_session_override.rb and you will see all the > > api > > > methods > > > > > that are currently offloaded to the queue. > > > > > This can be added to or removed from by calling > > > > > Facebooker::Session.async_method or Facebooker:: > > Session.sync_method > > > > > > > > > > I am kinda hoping to get this pushed into the Facebooker source so > > that > > > it > > > > > can be a config option. If not I will setup > > > > > a rubyforge project and change the URL > > > > > > > > > > This is a work in progress and any comments or code is totally > > welcome. > > > It > > > > > has been developed from a couple of projects > > > > > that I am currently working on. > > > > > > > > > > > > > > > TODO: > > > > > > > > > > 1) I think some of the options such as the max number of failure, > > which > > > > > methods to intercept and table name should be configurable. > > > > > 2) I think that it would be good to work out some admin view of > > the > > > queue. > > > > > 3) Make sure that it works well with multiple runner instances. > > > > > 4) Remove the need to run this within the RAILS_ENV > > > > > 5) Create a gem like ar_mailer has. > > > > > 6) Implement saving response and using a callback to do something > > with > > > the > > > > > response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Facebooker-talk mailing list > > > > > Facebooker-talk at rubyforge.org > > > > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > http://shanesbrain.net | http://crimsonjet.com | > > http://myfitbuddy.com > > > > > > > > > > > > > > > > > > -- > > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com > > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > >-- Christopher Bailey Cobalt Edge LLC http://cobaltedge.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/3570408a/attachment.html
On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey <chris at cobaltedge.com> wrote:> David, this seems like a great idea. I''ve been using Spawn to kick off > various things like this in my code. It has worked well so far, and > alleviates the need for a cron job. > > As for the publishing thing, I wonder about that. Does the user truly > have to be interactively logged in, or can you simply use their infinite > session key? >Yeah, I was using spawn for awhile, it worked great. I have an unfounded aversion to forking lots of processes. And since my apps are going to go viral and I am going to have 10 million users by the end of the day, I figured I should build something more robust. ;)> > > On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > > > Yeah, main reason is to not get hung up during the request cycle > > talking to facebook api. I need to better detect errors though so that I > > can see if Facebook is denying my request. > > > > > > Dave > > > > > > On Fri, Mar 14, 2008 at 1:57 PM, Shane Vitarana <shanev at gmail.com> > > wrote: > > > > > Not sure how they do it. I think it should be fine if it is run every > > > minute though. > > > > > > On Fri, Mar 14, 2008 at 2:47 PM, David Clements <digidigo at gmail.com> > > > wrote: > > > > That is interesting. I haven''t run into that. But for me feeds > > > get > > > > updated within a minute or so , as I run the cron job every minute. > > > > Do you know how they detect that the user is logged in? > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > On Fri, Mar 14, 2008 at 1:45 PM, Shane Vitarana <shanev at gmail.com> > > > wrote: > > > > > Nice work. But would you run into issues with publishing feeds? > > > Since > > > > > they have to be publish while the user is actively logged in now? > > > > > > > > > > Shane > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 14, 2008 at 2:38 PM, David Clements < > > > digidigo at gmail.com> > > > > wrote: > > > > > > I don''t know if anyone is using this but I just fixed a bunch of > > > bugs, > > > > some > > > > > > big ones, and moved this project to RubyForge SVN servers. > > > > > > > > > > > > So you can get it here now: > > > > > > > > > > > > script/plugin install > > > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > > > This is working great for me on a couple of projects. > > > > > > > > > > > > Here is the README > > > > > > > > > > > > Updated: 3/14/2008 > > > > > > > > > > > > Purpose: > > > > > > The purpose of FacebookerMQ is to provide an async method for > > > performing > > > > > > time consuming > > > > > > Facebook API requests. The Facebook platform is very sensitive > > > to long > > > > > > running requests, > > > > > > and as such it becomes important to offload some of these > > > requests to a > > > > > > background process. > > > > > > As the name suggests this plugin relies on the facebooker api ( > > > gem > > > > install > > > > > > facebooker ). > > > > > > > > > > > > Overview: > > > > > > > > > > > > FacebookerMQ intercepts Facebooker calls into session.publish > > > (method, > > > > > > params) and saves all the relevant data > > > > > > to the database. This is inspired by the ar_mailer project > > > which does > > > > the > > > > > > same for ActionMailer. In order > > > > > > to process the queue you can setup a cron job to run > > > script/runner > > > > > > FacebookerMqRunner.work(). > > > > > > > > > > > > What you need: > > > > > > > > > > > > 1) script/plugin install > > > > > > http://facebooker-mq.rubyforge.org/svn/trunk/facebooker-mq/ > > > > > > > > > > > > > > > > > > > > > > > > 2) You will need a migration to create the table that holds the > > > > messages. > > > > > > You can think if this table as the queue > > > > > > > > > > > > class CreateFacebookMessages < ActiveRecord::Migration > > > > > > def self.up > > > > > > create_table :facebook_messages do |t| > > > > > > t.column(:session_key, :string, :null => false) > > > > > > t.column(:expires, :string, :null => false, :default => > > > "0") > > > > > > t.column(:uid, :integer, :null => false) > > > > > > t.column(:api_method, :string, :null => false) > > > > > > t.column(:params, :text, :null => false ) # Always > > > a hash. > > > > > > t.column(:state, :string, :null => false, :default => > > > ''new'' ) > > > > > > t.column(:send_after, :datetime, :null => false, > > > :default => > > > > > > Time.at(0)) # Optional date time to wait until you send > > > > > > t.column( :last_send_attempt, :datetime ) > > > > > > t.column( :send_attempts, :integer, :default => 0 , > > > :null => > > > > false > > > > > > ) > > > > > > t.column( :facebook_errors, :text, :default => "") > > > > > > t.column( :response_xml, :text, :default => "") > > > > > > t.timestamps > > > > > > end > > > > > > end > > > > > > > > > > > > def self.down > > > > > > drop_table :facebook_messages > > > > > > end > > > > > > end > > > > > > > > > > > > 3) Cronjob or some other way to fire off > > > FacebookerMqRunner.work() > > > > > > > > > > > > > > > > > > Misc: > > > > > > > > > > > > Look in facebooker_session_override.rb and you will see all the > > > api > > > > methods > > > > > > that are currently offloaded to the queue. > > > > > > This can be added to or removed from by calling > > > > > > Facebooker::Session.async_method or Facebooker:: > > > Session.sync_method > > > > > > > > > > > > I am kinda hoping to get this pushed into the Facebooker source > > > so that > > > > it > > > > > > can be a config option. If not I will setup > > > > > > a rubyforge project and change the URL > > > > > > > > > > > > This is a work in progress and any comments or code is totally > > > welcome. > > > > It > > > > > > has been developed from a couple of projects > > > > > > that I am currently working on. > > > > > > > > > > > > > > > > > > TODO: > > > > > > > > > > > > 1) I think some of the options such as the max number of > > > failure, which > > > > > > methods to intercept and table name should be configurable. > > > > > > 2) I think that it would be good to work out some admin view of > > > the > > > > queue. > > > > > > 3) Make sure that it works well with multiple runner instances. > > > > > > 4) Remove the need to run this within the RAILS_ENV > > > > > > 5) Create a gem like ar_mailer has. > > > > > > 6) Implement saving response and using a callback to do > > > something with > > > > the > > > > > > response. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Facebooker-talk mailing list > > > > > > Facebooker-talk at rubyforge.org > > > > > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://shanesbrain.net | http://crimsonjet.com | > > > http://myfitbuddy.com > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > http://shanesbrain.net | http://crimsonjet.com | http://myfitbuddy.com > > > > > > > > > _______________________________________________ > > Facebooker-talk mailing list > > Facebooker-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > > -- > Christopher Bailey > Cobalt Edge LLC > http://cobaltedge.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/aadf6f9d/attachment.html
On 3/14/08, David Clements <digidigo at gmail.com> wrote: On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey <chris at cobaltedge.com>> wrote: > > > David, this seems like a great idea. I''ve been using Spawn to kick off > > various things like this in my code. It has worked well so far, and > > alleviates the need for a cron job. > > > > As for the publishing thing, I wonder about that. Does the user truly > > have to be interactively logged in, or can you simply use their infinite > > session key? > > > > Yeah, I was using spawn for awhile, it worked great. I have an unfounded > aversion to forking lots of processes. And since my apps are going to go > viral and I am going to have 10 million users by the end of the day, I > figured I should build something more robust. ;) >No doubt! :) Ya, my take was actually that I''ll use Workling, so as to transition to something like Starling once load requires it. But for now, Spawn was the simplest and lightest solution to put in. Do note that Spawn can fork or it can use threads, although the threads variant is a bit more sketchy due to ActiveRecord and so on (apparently - I haven''t tried using the threads version yet, as I figured once I got to high enough loads where that mattered, I''d switch to Starling). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/cb68fa13/attachment.html
On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com> wrote:> On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey <chris at cobaltedge.com> > > wrote: > > > > > David, this seems like a great idea. I''ve been using Spawn to kick > > > off various things like this in my code. It has worked well so far, and > > > alleviates the need for a cron job. > > > > > > As for the publishing thing, I wonder about that. Does the user truly > > > have to be interactively logged in, or can you simply use their infinite > > > session key? > > > > > > > Yeah, I was using spawn for awhile, it worked great. I have an > > unfounded aversion to forking lots of processes. And since my apps are > > going to go viral and I am going to have 10 million users by the end of the > > day, I figured I should build something more robust. ;) > > > > > No doubt! :) Ya, my take was actually that I''ll use Workling, so as to > transition to something like Starling once load requires it. But for now, > Spawn was the simplest and lightest solution to put in. Do note that Spawn > can fork or it can use threads, although the threads variant is a bit more > sketchy due to ActiveRecord and so on (apparently - I haven''t tried using > the threads version yet, as I figured once I got to high enough loads where > that mattered, I''d switch to Starling). >I am a short and simple kind of guy and like to understand as much code as I can that I have in production. I like spawn for sure and probably should get over my fear of lots of processes. The thread thing scared me as well, as I would have to dive too far into the rails code to know how that works. I haven''t looked at starling yet, and haven''t even heard of workling. Dave> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/c64b6ab4/attachment-0001.html
Actually, I think you are right to look beyond Spawn for something that you will release publicly, or that is a standard part of Facebooker, given the ease with which a Facebook application''s traffic can go through the roof. If people do an even mildly popular Facebook app, they are going to want something other than forking, or they are going to have to beef up the machines they run on, etc. As for Workling, it is a wrapper around things like Starling, Spawn, etc., so that you can swap out different async processing libraries. Check it out from this blog post about it: http://playtype.net/past/2008/2/6/starling_and_asynchrous_tasks_in_ruby_on_rails/ On 3/14/08, David Clements <digidigo at gmail.com> wrote:> > > > On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com> > wrote: > > > On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > > > On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey < > > > chris at cobaltedge.com> wrote: > > > > > > > David, this seems like a great idea. I''ve been using Spawn to kick > > > > off various things like this in my code. It has worked well so far, and > > > > alleviates the need for a cron job. > > > > > > > > As for the publishing thing, I wonder about that. Does the user > > > > truly have to be interactively logged in, or can you simply use their > > > > infinite session key? > > > > > > > > > > Yeah, I was using spawn for awhile, it worked great. I have an > > > unfounded aversion to forking lots of processes. And since my apps are > > > going to go viral and I am going to have 10 million users by the end of the > > > day, I figured I should build something more robust. ;) > > > > > > > > > No doubt! :) Ya, my take was actually that I''ll use Workling, so as to > > transition to something like Starling once load requires it. But for now, > > Spawn was the simplest and lightest solution to put in. Do note that Spawn > > can fork or it can use threads, although the threads variant is a bit more > > sketchy due to ActiveRecord and so on (apparently - I haven''t tried using > > the threads version yet, as I figured once I got to high enough loads where > > that mattered, I''d switch to Starling). > > > > I am a short and simple kind of guy and like to understand as much code as > I can that I have in production. I like spawn for sure and probably should > get over my fear of lots of processes. The thread thing scared me as well, > as I would have to dive too far into the rails code to know how that works. > > I haven''t looked at starling yet, and haven''t even heard of workling. > > Dave > > > > > > > > >-- Christopher Bailey Cobalt Edge LLC http://cobaltedge.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/d40cf865/attachment.html
Starling is pretty nice. It is just over 1000 lines including comments. Michael On Mar 14, 2008, at 4:02 PM, David Clements wrote:> > > On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com > > wrote: > On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey <chris at cobaltedge.com > > wrote: > David, this seems like a great idea. I''ve been using Spawn to kick > off various things like this in my code. It has worked well so far, > and alleviates the need for a cron job. > > > As for the publishing thing, I wonder about that. Does the user > truly have to be interactively logged in, or can you simply use > their infinite session key? > > Yeah, I was using spawn for awhile, it worked great. I have an > unfounded aversion to forking lots of processes. And since my apps > are going to go viral and I am going to have 10 million users by the > end of the day, I figured I should build something more robust. ;) > > > No doubt! :) Ya, my take was actually that I''ll use Workling, so > as to transition to something like Starling once load requires it. > But for now, Spawn was the simplest and lightest solution to put > in. Do note that Spawn can fork or it can use threads, although the > threads variant is a bit more sketchy due to ActiveRecord and so on > (apparently - I haven''t tried using the threads version yet, as I > figured once I got to high enough loads where that mattered, I''d > switch to Starling). > > I am a short and simple kind of guy and like to understand as much > code as I can that I have in production. I like spawn for sure and > probably should get over my fear of lots of processes. The thread > thing scared me as well, as I would have to dive too far into the > rails code to know how that works. > > I haven''t looked at starling yet, and haven''t even heard of workling. > > Dave > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/8f1debc1/attachment.html
On Fri, Mar 14, 2008 at 3:07 PM, Michael Niessner < mniessner at elevatedrails.com> wrote:> Starling is pretty nice. It is just over 1000 lines including comments. >That is cool. I''ll take a look. Then I won''t feel like I am at its mercy, like I felt in the backgroundrb days. Those were painful days, although I understand it has been rewritten as well. Dave> > Michael > > On Mar 14, 2008, at 4:02 PM, David Clements wrote: > > > > On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com> > wrote: > > > On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > > > On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey < > > > chris at cobaltedge.com> wrote: > > > > > > > David, this seems like a great idea. I''ve been using Spawn to kick > > > > off various things like this in my code. It has worked well so far, and > > > > alleviates the need for a cron job. > > > > > > > > As for the publishing thing, I wonder about that. Does the user > > > > truly have to be interactively logged in, or can you simply use their > > > > infinite session key? > > > > > > > > > > Yeah, I was using spawn for awhile, it worked great. I have an > > > unfounded aversion to forking lots of processes. And since my apps are > > > going to go viral and I am going to have 10 million users by the end of the > > > day, I figured I should build something more robust. ;) > > > > > > > > > No doubt! :) Ya, my take was actually that I''ll use Workling, so as to > > transition to something like Starling once load requires it. But for now, > > Spawn was the simplest and lightest solution to put in. Do note that Spawn > > can fork or it can use threads, although the threads variant is a bit more > > sketchy due to ActiveRecord and so on (apparently - I haven''t tried using > > the threads version yet, as I figured once I got to high enough loads where > > that mattered, I''d switch to Starling). > > > > I am a short and simple kind of guy and like to understand as much code as > I can that I have in production. I like spawn for sure and probably should > get over my fear of lots of processes. The thread thing scared me as well, > as I would have to dive too far into the rails code to know how that works. > > I haven''t looked at starling yet, and haven''t even heard of workling. > > Dave > > > > > > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/d1fbcecd/attachment.html
And it speaks memcache :D On Fri, Mar 14, 2008 at 4:07 PM, Michael Niessner < mniessner at elevatedrails.com> wrote:> Starling is pretty nice. It is just over 1000 lines including comments. > Michael > > On Mar 14, 2008, at 4:02 PM, David Clements wrote: > > > > On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com> > wrote: > > > On 3/14/08, David Clements <digidigo at gmail.com> wrote: > > > > On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey < > > > chris at cobaltedge.com> wrote: > > > > > > > David, this seems like a great idea. I''ve been using Spawn to kick > > > > off various things like this in my code. It has worked well so far, and > > > > alleviates the need for a cron job. > > > > > > > > As for the publishing thing, I wonder about that. Does the user > > > > truly have to be interactively logged in, or can you simply use their > > > > infinite session key? > > > > > > > > > > Yeah, I was using spawn for awhile, it worked great. I have an > > > unfounded aversion to forking lots of processes. And since my apps are > > > going to go viral and I am going to have 10 million users by the end of the > > > day, I figured I should build something more robust. ;) > > > > > > > > > No doubt! :) Ya, my take was actually that I''ll use Workling, so as to > > transition to something like Starling once load requires it. But for now, > > Spawn was the simplest and lightest solution to put in. Do note that Spawn > > can fork or it can use threads, although the threads variant is a bit more > > sketchy due to ActiveRecord and so on (apparently - I haven''t tried using > > the threads version yet, as I figured once I got to high enough loads where > > that mattered, I''d switch to Starling). > > > > I am a short and simple kind of guy and like to understand as much code as > I can that I have in production. I like spawn for sure and probably should > get over my fear of lots of processes. The thread thing scared me as well, > as I would have to dive too far into the rails code to know how that works. > > I haven''t looked at starling yet, and haven''t even heard of workling. > > Dave > > > > > > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/4839c2cb/attachment-0001.html
And we use it on apps with more than 10 million users with no problems. It''s not unusual to process several million messages in a single day. I highly recommend it. In fact, I''m writing about it right now :) Mike On Mar 14, 2008, at 4:23 PM, Brian Smith wrote:> And it speaks memcache :D > > On Fri, Mar 14, 2008 at 4:07 PM, Michael Niessner <mniessner at elevatedrails.com > > wrote: > Starling is pretty nice. It is just over 1000 lines including > comments. > > Michael > > On Mar 14, 2008, at 4:02 PM, David Clements wrote: > >> >> >> On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey <chris at cobaltedge.com >> > wrote: >> On 3/14/08, David Clements <digidigo at gmail.com> wrote: >> >> On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey <chris at cobaltedge.com >> > wrote: >> David, this seems like a great idea. I''ve been using Spawn to kick >> off various things like this in my code. It has worked well so >> far, and alleviates the need for a cron job. >> >> >> As for the publishing thing, I wonder about that. Does the user >> truly have to be interactively logged in, or can you simply use >> their infinite session key? >> >> Yeah, I was using spawn for awhile, it worked great. I have an >> unfounded aversion to forking lots of processes. And since my apps >> are going to go viral and I am going to have 10 million users by >> the end of the day, I figured I should build something more >> robust. ;) >> >> >> No doubt! :) Ya, my take was actually that I''ll use Workling, so >> as to transition to something like Starling once load requires it. >> But for now, Spawn was the simplest and lightest solution to put >> in. Do note that Spawn can fork or it can use threads, although >> the threads variant is a bit more sketchy due to ActiveRecord and >> so on (apparently - I haven''t tried using the threads version yet, >> as I figured once I got to high enough loads where that mattered, >> I''d switch to Starling). >> >> I am a short and simple kind of guy and like to understand as much >> code as I can that I have in production. I like spawn for sure and >> probably should get over my fear of lots of processes. The thread >> thing scared me as well, as I would have to dive too far into the >> rails code to know how that works. >> >> I haven''t looked at starling yet, and haven''t even heard of workling. >> >> Dave >> >> >> >> _______________________________________________ >> Facebooker-talk mailing list >> Facebooker-talk at rubyforge.org >> http://rubyforge.org/mailman/listinfo/facebooker-talk > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk-- Mike Mangino http://www.elevatedrails.com
Cool, I wait for the PDF to be updated then!! Dave On Fri, Mar 14, 2008 at 3:47 PM, Mike Mangino <mmangino at elevatedrails.com> wrote:> And we use it on apps with more than 10 million users with no > problems. It''s not unusual to process several million messages in a > single day. I highly recommend it. In fact, I''m writing about it right > now :) > > Mike > > On Mar 14, 2008, at 4:23 PM, Brian Smith wrote: > > > And it speaks memcache :D > > > > On Fri, Mar 14, 2008 at 4:07 PM, Michael Niessner < > mniessner at elevatedrails.com > > > wrote: > > Starling is pretty nice. It is just over 1000 lines including > > comments. > > > > Michael > > > > On Mar 14, 2008, at 4:02 PM, David Clements wrote: > > > >> > >> > >> On Fri, Mar 14, 2008 at 2:53 PM, Christopher Bailey < > chris at cobaltedge.com > >> > wrote: > >> On 3/14/08, David Clements <digidigo at gmail.com> wrote: > >> > >> On Fri, Mar 14, 2008 at 2:22 PM, Christopher Bailey < > chris at cobaltedge.com > >> > wrote: > >> David, this seems like a great idea. I''ve been using Spawn to kick > >> off various things like this in my code. It has worked well so > >> far, and alleviates the need for a cron job. > >> > >> > >> As for the publishing thing, I wonder about that. Does the user > >> truly have to be interactively logged in, or can you simply use > >> their infinite session key? > >> > >> Yeah, I was using spawn for awhile, it worked great. I have an > >> unfounded aversion to forking lots of processes. And since my apps > >> are going to go viral and I am going to have 10 million users by > >> the end of the day, I figured I should build something more > >> robust. ;) > >> > >> > >> No doubt! :) Ya, my take was actually that I''ll use Workling, so > >> as to transition to something like Starling once load requires it. > >> But for now, Spawn was the simplest and lightest solution to put > >> in. Do note that Spawn can fork or it can use threads, although > >> the threads variant is a bit more sketchy due to ActiveRecord and > >> so on (apparently - I haven''t tried using the threads version yet, > >> as I figured once I got to high enough loads where that mattered, > >> I''d switch to Starling). > >> > >> I am a short and simple kind of guy and like to understand as much > >> code as I can that I have in production. I like spawn for sure and > >> probably should get over my fear of lots of processes. The thread > >> thing scared me as well, as I would have to dive too far into the > >> rails code to know how that works. > >> > >> I haven''t looked at starling yet, and haven''t even heard of workling. > >> > >> Dave > >> > >> > >> > >> _______________________________________________ > >> Facebooker-talk mailing list > >> Facebooker-talk at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > _______________________________________________ > > Facebooker-talk mailing list > > Facebooker-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > > > > > _______________________________________________ > > Facebooker-talk mailing list > > Facebooker-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/facebooker-talk > > -- > Mike Mangino > http://www.elevatedrails.com > > > > _______________________________________________ > Facebooker-talk mailing list > Facebooker-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/facebooker-talk >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/facebooker-talk/attachments/20080314/abf08ed5/attachment.html