Hi, i''ve got an RoR site, which runs on mongrel there is a task which the admin uses to fill the database with new data, the problem is that when the task runs the whole webpage stalls, the job he does from the admin panel also runs as a cron job at a time the page isn''t used but he insists for the manual run. So i don''t know if this is a rail problem or mongrel/this whatever - but would be very grateful for a help adam -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
How much data is being loaded? If you are adding a large amount of data inside a giant commit statement then the database could become inaccessible for everyone else until the load completes. -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 10 November 2010 12:12, Peter Hickman <peterhickman386-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> How much data is being loaded? If you are adding a large amount of > data inside a giant commit statement then the database could become > inaccessible for everyone else until the load completes.Worse than that, IIRC, Mongrel serves one request at a time. If your request takes a long time, *nothing* else will respond while it''s processing. Consider a Mongrel cluster (so there are other Mongrel instances to handle other requests) or better yet, switch to Passenger with Apache (or NGinx, etc) -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
well its from an xml file which usually is about ~20MB i found one solution which isnt very pretty to run the web page on two different ports using two different instances of mongrel, but I''m looking for somthing more simple for the end user, so he dosn''t have to remember to login to one webpage for the admin work. On 10 Lis, 13:12, Peter Hickman <peterhickman...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> How much data is being loaded? If you are adding a large amount of > data inside a giant commit statement then the database could become > inaccessible for everyone else until the load completes.-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Yeh i thought about mongrel cluser - I''m just imaging the discussion with the server admins ;) On 10 Lis, 13:23, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 10 November 2010 12:12, Peter Hickman <peterhickman...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > > > How much data is being loaded? If you are adding a large amount of > > data inside a giant commit statement then the database could become > > inaccessible for everyone else until the load completes. > > Worse than that, IIRC, Mongrel serves one request at a time. If your > request takes a long time, *nothing* else will respond while it''s > processing. > Consider a Mongrel cluster (so there are other Mongrel instances to > handle other requests) or better yet, switch to Passenger with Apache > (or NGinx, etc)-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Use a delayed_job task for the long running task. This will free your mongrel process for further requests as delayed job runs as a separate ruby process but loads the rails environment. You can use "send_later" for this and this requires minimal code change. - Gautam @gautamrege On Wed, Nov 10, 2010 at 6:06 PM, Adam <anlauf.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Yeh i thought about mongrel cluser - I''m just imaging the discussion > with the server admins ;) > > On 10 Lis, 13:23, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > On 10 November 2010 12:12, Peter Hickman <peterhickman...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > wrote: > > > > > How much data is being loaded? If you are adding a large amount of > > > data inside a giant commit statement then the database could become > > > inaccessible for everyone else until the load completes. > > > > Worse than that, IIRC, Mongrel serves one request at a time. If your > > request takes a long time, *nothing* else will respond while it''s > > processing. > > Consider a Mongrel cluster (so there are other Mongrel instances to > > handle other requests) or better yet, switch to Passenger with Apache > > (or NGinx, etc) > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
this sound very interesting I''ll check that out On 10 Lis, 13:49, Gautam Rege <gau...-LmeKiT3xSvsi8rCdYzckzA@public.gmane.org> wrote:> Use a delayed_job task for the long running task. > > This will free your mongrel process for further requests as delayed job runs > as a separate ruby process but loads the rails environment. You can use > "send_later" for this and this requires minimal code change. > > - Gautam > @gautamrege > > > > > > > > On Wed, Nov 10, 2010 at 6:06 PM, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Yeh i thought about mongrel cluser - I''m just imaging the discussion > > with the server admins ;) > > > On 10 Lis, 13:23, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > On 10 November 2010 12:12, Peter Hickman <peterhickman...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> > > wrote: > > > > > How much data is being loaded? If you are adding a large amount of > > > > data inside a giant commit statement then the database could become > > > > inaccessible for everyone else until the load completes. > > > > Worse than that, IIRC, Mongrel serves one request at a time. If your > > > request takes a long time, *nothing* else will respond while it''s > > > processing. > > > Consider a Mongrel cluster (so there are other Mongrel instances to > > > handle other requests) or better yet, switch to Passenger with Apache > > > (or NGinx, etc) > > > -- > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscrib e@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-talk?hl=en.-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Nov 10, 12:55 pm, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> this sound very interesting I''ll check that out >While delayed_job is handy, you will eventually run out of steam if you only have one mongrel. Others have suggested mongrel_cluster for running multiple mongrels, you might also want to consider passenger, which will fork extra rails instances as needed. Fred -- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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?hl=en.
I do agree - infact my preferred setup us Nginx+Passenger. However, given that the current problem on hand is one long running task slowing things down and not a scale issue (I.e number of requests), delayed_job may just do the trick. My 2 cents :) - Gautam Sent from my iPhone www.joshsoftware.com On Nov 10, 2010, at 8:50 PM, Frederick Cheung <frederick.cheung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > wrote:> > > On Nov 10, 12:55 pm, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> this sound very interesting I''ll check that out >> > While delayed_job is handy, you will eventually run out of steam if > you only have one mongrel. Others have suggested mongrel_cluster for > running multiple mongrels, you might also want to consider passenger, > which will fork extra rails instances as needed. > > Fred > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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 > . >-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I''m currently trying to set up the delayed job solution, running into some problems but if I get it to work I think it will do the job, the importing will be done about once a day. Since I''m on the topic I''ve tried to do the railscast setup from delayed job but both of the versions showed there dont do it for me the first one with the send_later method Download.new.send_later(:start), shows "undefined method `perform'' for #<YAML::Object: ..." I load the config in environment.rb file (raw_config File.read(RAILS_ROOT + "/config/config.yml") APP_CONFIG = YAML.load(raw_config)[RAILS_ENV]) the second option using a new class after jobs:work "Job failed to load: Unknown handler. Try to manually require the appropriate file." On 10 Lis, 17:06, Gautam Rege <gau...-LmeKiT3xSvsi8rCdYzckzA@public.gmane.org> wrote:> I do agree - infact my preferred setup us Nginx+Passenger. > > However, given that the current problem on hand is one long running > task slowing things down and not a scale issue (I.e number of > requests), delayed_job may just do the trick. > > My 2 cents :) > - Gautam > Sent from my iPhone > > www.joshsoftware.com > > On Nov 10, 2010, at 8:50 PM, Frederick Cheung <frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > > > > > wrote: > > > On Nov 10, 12:55 pm, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> this sound very interesting I''ll check that out > > > While delayed_job is handy, you will eventually run out of steam if > > you only have one mongrel. Others have suggested mongrel_cluster for > > running multiple mongrels, you might also want to consider passenger, > > which will fork extra rails instances as needed. > > > Fred > > > -- > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org > > . > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en > > .-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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?hl=en.
Adam, I presume you have run the migration that is generated by delayed_job. You also have the initializer file. Earlier would you start the long running as Download.new.start ? If so, Download.new.send_later(:start) would definitely work. If ''start'' is an instance method in the Download model, it will work. If ''start'' is a class method, you cannot (obviously) do a Download.new.start -- then you can enqueue the task. Send some more details - and I can help you sort this out. - Gautam @gautamrege On Wed, Nov 10, 2010 at 11:07 PM, Adam <anlauf.adam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''m currently trying to set up the delayed job solution, running into > some problems > but if I get it to work I think it will do the job, the importing will > be done about once a day. > > Since I''m on the topic I''ve tried to do the railscast setup from > delayed job but both of the versions showed there dont do it for me > the first one with the send_later method > Download.new.send_later(:start), shows "undefined method `perform'' for > #<YAML::Object: ..." > I load the config in environment.rb file (raw_config > File.read(RAILS_ROOT + "/config/config.yml") > APP_CONFIG = YAML.load(raw_config)[RAILS_ENV]) > > the second option using a new class after jobs:work > > "Job failed to load: Unknown handler. Try to manually require the > appropriate file." > > > On 10 Lis, 17:06, Gautam Rege <gau...-LmeKiT3xSvsi8rCdYzckzA@public.gmane.org> wrote: > > I do agree - infact my preferred setup us Nginx+Passenger. > > > > However, given that the current problem on hand is one long running > > task slowing things down and not a scale issue (I.e number of > > requests), delayed_job may just do the trick. > > > > My 2 cents :) > > - Gautam > > Sent from my iPhone > > > > www.joshsoftware.com > > > > On Nov 10, 2010, at 8:50 PM, Frederick Cheung < > frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > > > > > > > > > > > > > wrote: > > > > > On Nov 10, 12:55 pm, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > >> this sound very interesting I''ll check that out > > > > > While delayed_job is handy, you will eventually run out of steam if > > > you only have one mongrel. Others have suggested mongrel_cluster for > > > running multiple mongrels, you might also want to consider passenger, > > > which will fork extra rails instances as needed. > > > > > Fred > > > > > -- > > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > > > . > > > For more options, visit this group athttp:// > groups.google.com/group/rubyonrails-talk?hl=en > > > . > > -- > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
hmm, I''ve played around a bit and it somehow started to work well I guess thats good just wish how I''ve done that so I could setup it on the server properly ;) On 11 Lis, 07:56, Gautam Rege <gau...-LmeKiT3xSvsi8rCdYzckzA@public.gmane.org> wrote:> Adam, > I presume you have run the migration that is generated by delayed_job. You > also have the initializer file. > > Earlier would you start the long running as Download.new.start ? If so, > Download.new.send_later(:start) would definitely work. > > If ''start'' is an instance method in the Download model, it will work. If > ''start'' is a class method, you cannot (obviously) do a Download.new.start -- > then you can enqueue the task. > > Send some more details - and I can help you sort this out. > > - Gautam > @gautamrege > > > > > > > > On Wed, Nov 10, 2010 at 11:07 PM, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I''m currently trying to set up the delayed job solution, running into > > some problems > > but if I get it to work I think it will do the job, the importing will > > be done about once a day. > > > Since I''m on the topic I''ve tried to do the railscast setup from > > delayed job but both of the versions showed there dont do it for me > > the first one with the send_later method > > Download.new.send_later(:start), shows "undefined method `perform'' for > > #<YAML::Object: ..." > > I load the config in environment.rb file (raw_config > > File.read(RAILS_ROOT + "/config/config.yml") > > APP_CONFIG = YAML.load(raw_config)[RAILS_ENV]) > > > the second option using a new class after jobs:work > > > "Job failed to load: Unknown handler. Try to manually require the > > appropriate file." > > > On 10 Lis, 17:06, Gautam Rege <gau...-LmeKiT3xSvsi8rCdYzckzA@public.gmane.org> wrote: > > > I do agree - infact my preferred setup us Nginx+Passenger. > > > > However, given that the current problem on hand is one long running > > > task slowing things down and not a scale issue (I.e number of > > > requests), delayed_job may just do the trick. > > > > My 2 cents :) > > > - Gautam > > > Sent from my iPhone > > > >www.joshsoftware.com > > > > On Nov 10, 2010, at 8:50 PM, Frederick Cheung < > > frederick.che...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > > > > > wrote: > > > > > On Nov 10, 12:55 pm, Adam <anlauf.a...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > >> this sound very interesting I''ll check that out > > > > > While delayed_job is handy, you will eventually run out of steam if > > > > you only have one mongrel. Others have suggested mongrel_cluster for > > > > running multiple mongrels, you might also want to consider passenger, > > > > which will fork extra rails instances as needed. > > > > > Fred > > > > > -- > > > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscrib e@googlegroups.com> > > > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/rubyonrails-talk?hl=en > > > > . > > > -- > > 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > > To unsubscribe from this group, send email to > > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscrib e@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-talk?hl=en.-- 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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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?hl=en.