Hi John, I regret to say that the Passenger solution is not holding. We continue to experience the disconnects. It just takes alot longer. Once ruote (or ruote sequel) encounters one disconnect, this appears to be the behavior: Ruote continues to accept incoming requests, but process_def/participants are in limbo. They are added to the database, and issued an id. However, they are unknown if we attempt to find them with engine.process(the-id).
When then restart our webservice built around Ruote, and, of course, a new engine is created, connecting to the database. Now, the engine starts doing its work, and engine.process(the-id) finds the process. Does this sound familiar? Any advice? Chad On Thursday, July 26, 2012 5:17:31 PM UTC+9, John Mettraux wrote: > > > On Thu, Jul 26, 2012 at 01:12:28AM -0700, Chad wrote: > > > > It appears that PhusionPassenger forking technique seems to prevent the > SQL > > disconnects. It's sort of scary, but we are going to test it against > it. > > Hello Chad, > > it's not scary, it's something to be aware of when using those forking > servers. It's painful to learn. > > > Ruote's SQL behaviors seems to be this. On start up, make a massive > about > > of SQL requests. Then it settles down. I start creating jobs, and the > SQL > > requests seem to consistently stop with the job stops. > > As should be. > > That's great. Please keep me posted. Cheers, > > -- > John Mettraux - http://lambda.io/jmettraux > -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
