From: David Collier on 28 Mar 2010 01:29 hi - sure this is becoming a more common issue for many people - from within a web-app how to interact with other systems in a non-blocking way. ie i dont need to wait for a response from the other system in the cycle of the same user request/response. i need to send some logging information off to another system, via rest/http. in a rails app we're currently using delayedJob, which stores the events to the DB, and another process sends them. this is a pretty heavy process. a simplistic way would be just using system "curl &" but that will spawn a system process. not sure about the risks involved with that - this means one NgInx/rails instance will have to wait for that to complete, and maybe run into memory issues. Are there any ways to use the net/http library to "fire and forget" a call? or perhaps a simple implementation using threads, that will be less resource intensive than "curl &" thanks... /dc -- Posted via http://www.ruby-forum.com/.
From: Josh Cheek on 28 Mar 2010 02:54 [Note: parts of this message were removed to make it a legal post.] On Sat, Mar 27, 2010 at 11:29 PM, David Collier <lister(a)pikkle.com> wrote: > hi - > > sure this is becoming a more common issue for many people - from within > a web-app how to interact with other systems in a non-blocking way. ie i > dont need to wait for a response from the other system in the cycle of > the same user request/response. > > i need to send some logging information off to another system, via > rest/http. > in a rails app we're currently using delayedJob, which stores the events > to the DB, and another process sends them. this is a pretty heavy > process. > > a simplistic way would be just using system "curl &" but that will > spawn a system process. not sure about the risks involved with that - > this means one NgInx/rails instance will have to wait for that to > complete, and maybe run into memory issues. > > Are there any ways to use the net/http library to "fire and forget" a > call? > or perhaps a simple implementation using threads, that will be less > resource intensive than "curl &" > > thanks... > > /dc > -- > Posted via http://www.ruby-forum.com/. > > Event Machine sounds like it fits your needs. This presentation says it can handle 5-10k concurrent connections in a single ruby process http://timetobleed.com/eventmachine-scalable-non-blocking-io-in-ruby/ Here is the rubygems page http://rubygems.org/gems/eventmachine
From: Robert Klemme on 28 Mar 2010 03:44 On 03/28/2010 07:29 AM, David Collier wrote: > i need to send some logging information off to another system, via > rest/http. > in a rails app we're currently using delayedJob, which stores the events > to the DB, and another process sends them. this is a pretty heavy > process. > Are there any ways to use the net/http library to "fire and forget" a > call? > or perhaps a simple implementation using threads, that will be less > resource intensive than "curl &" The simplest that comes to mind: stuff your operations in a queue and have one or more threads process them. Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Robert Gleeson on 28 Mar 2010 04:31 David Collier wrote: > hi - > > sure this is becoming a more common issue for many people - from within > a web-app how to interact with other systems in a non-blocking way. ie i > dont need to wait for a response from the other system in the cycle of > the same user request/response. > > i need to send some logging information off to another system, via > rest/http. > in a rails app we're currently using delayedJob, which stores the events > to the DB, and another process sends them. this is a pretty heavy > process. > > a simplistic way would be just using system "curl &" but that will > spawn a system process. not sure about the risks involved with that - > this means one NgInx/rails instance will have to wait for that to > complete, and maybe run into memory issues. > > Are there any ways to use the net/http library to "fire and forget" a > call? > or perhaps a simple implementation using threads, that will be less > resource intensive than "curl &" > > thanks... > > /dc All the other suggestions are great, and you should give 'em some consideration. I'd mention fork() as well, though, since most UNIX-like distributions(if not all? I'm just not 100%) implement a copy-on-write fork(), reducing the overhead people sometimes associate with fork(). I'd add as a note that sharing data between two processes isn't straight forward, you might need to look at IO.pipe but if you don't need to send data back or have data available in your subprocess after a call to fork() you should be fine. Don't forget Process.wait and/or Process.detach to avoid collectin' zombies. Thanks, Rob -- Posted via http://www.ruby-forum.com/.
From: Brian Candler on 28 Mar 2010 07:44 David Collier wrote: > Are there any ways to use the net/http library to "fire and forget" a > call? Thread.new do Net::HTTP.whatever... end -- Posted via http://www.ruby-forum.com/.
|
Next
|
Last
Pages: 1 2 Prev: Watir issue with AutoIt on Vista 64 bit Next: divide BMP to YUV channels |