I''m checking out backgroundrb for a calculation process I estimate will take 2-3 minutes and be ran on-demand only via Rails. Very easy and slick. But I have a question. The connections never close, if I do a netstat they just keep piling up. Do I need to do some housekeeping somewhere? I noticed the @ connection.close statements are commented out in favor of a # FIXME type deal. Even if I store read_from_bdrb in an intermediate variable, call @ connection.close then return, they still sit in a CLOSE_WAIT status forever -- long, long after mongrel has cleaned up. I''m not a communications guy, so if I''m doing something wrong, let me know. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080125/f2beeb76/attachment.html
''ps -ef | grep worker'' on your box. If you find there are a bunch hanging around - there''s your problem. I''m running an ooold version of BDRB (0.2.1), and I have to kill the workers from rails, or call ''exit!'' at the bottom of my do_work method to get things behaving properly. You might be encountering something similar. Not sure what the latest and greatest method of achieving this is...TTL perhaps anyone? On Jan 25, 2008 8:56 PM, Meech <meechman at gmail.com> wrote:> I''m checking out backgroundrb for a calculation process I estimate will > take 2-3 minutes and be ran on-demand only via Rails. Very easy and slick. > > > But I have a question. > > The connections never close, if I do a netstat they just keep piling up. > > Do I need to do some housekeeping somewhere? I noticed the @ > connection.close statements are commented out in favor of a # FIXME type > deal. > > Even if I store read_from_bdrb in an intermediate variable, call @ > connection.close then return, they still sit in a CLOSE_WAIT status > forever -- long, long after mongrel has cleaned up. > > I''m not a communications guy, so if I''m doing something wrong, let me > know. > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- -------------------- seth at subimage interactive ----- http://sublog.subimage.com ----- Cashboard - Estimates, invoices, and time tracking software - for free! http://www.getcashboard.com ----- Substruct - Open source RoR e-commerce software. http://dev.subimage.com/projects/substruct -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080125/d8be0891/attachment.html
On Sat, Jan 26, 2008 at 10:26 AM, Meech <meechman at gmail.com> wrote:> I''m checking out backgroundrb for a calculation process I estimate will take > 2-3 minutes and be ran on-demand only via Rails. Very easy and slick. > > But I have a question. > > The connections never close, if I do a netstat they just keep piling up. > > Do I need to do some housekeeping somewhere? I noticed the > @connection.close statements are commented out in favor of a # FIXME type > deal. > > Even if I store read_from_bdrb in an intermediate variable, call > @connection.close then return, they still sit in a CLOSE_WAIT status forever > -- long, long after mongrel has cleaned up.That shouldn''t be a problem, although initially @connection.close wasn''t invoked to circumvent a bug with socket write, but I perhaps understand your concern ( running out of open file descriptor? ), file a ticket, if possible here: http://backgroundrb.devjavu.com/ I will fix this in next release. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
SI, I thought you did not _have_ to exit your workers, that they could just hang out and process requests. And most of my stale, open connections are the result of ask_status calls, not sure these hit (or need) a worker? I''ll try it though. Hemant, Thanks. I haven''t really run into any barriers yet, I''m just used to watching netstat to make sure all the various pieces and parts are awake and listening. My work rig is Windows, and I find myself checking netstat a lot because backgroundrb (under cygwin) starts successfully (or rather without any errors) but doesn''t always really start. Don''t have this problem on my home ''nix box. My application dynamically shows and hides links, actions, etc and my 1st revision polled MiddleMan directly everytime -- rather than caching it in an @instance variable. So for each request MiddleMan.ask_status could get hit 10-15 times depending on records, auth, etc. After refreshing the page a few times, I see 50+ connections just hanging around and that''s just with me. I''m just wondering what this will be like when it hits production. I''ll put in a ticket... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080126/132596b0/attachment-0001.html
On Sat, Jan 26, 2008 at 8:25 PM, Meech <meechman at gmail.com> wrote:> SI, > > I thought you did not _have_ to exit your workers, that they could just hang > out and process requests. And most of my stale, open connections are the > result of ask_status calls, not sure these hit (or need) a worker? I''ll > try it though. > > > Hemant, > > Thanks. I haven''t really run into any barriers yet, I''m just used to > watching netstat to make sure all the various pieces and parts are awake and > listening. My work rig is Windows, and I find myself checking netstat a > lot because backgroundrb (under cygwin) starts successfully (or rather > without any errors) but doesn''t always really start. Don''t have this > problem on my home ''nix box. > > My application dynamically shows and hides links, actions, etc and my 1st > revision polled MiddleMan directly everytime -- rather than caching it in an > @instance variable. So for each request MiddleMan.ask_status could get hit > 10-15 times depending on records, auth, etc. > > After refreshing the page a few times, I see 50+ connections just hanging > around and that''s just with me. I''m just wondering what this will be like > when it hits production. > > I''ll put in a ticket...Don''t worry about "what happens in production in issue?". I have rarely let any known/reproducible bug open for more than a week. So, we will this straightened.