From: "ara.t.howard" Date: 2007-12-14T05:07:29+09:00 Subject: Re: [ANN] bj-0.0.2 On Dec 13, 2007, at 10:33 AM, hemant kumar wrote: > > I am maintaining backgruondrb in these younger days. And things have > changed. Its written on top of event driven networking lib ( packet ) > that i wrote. > > There are no threads anywhere. Everything is even driven, it still has > real processes, but those have reactor loop of their own. I wrote a > custom protocol for internal communication between workers and it > works > reasonably well. > > I agree that, bj , spawn they all have different purpose. If you find > time, please look into code base and suggest any problems that you > find. hey hemant - didn't know you'd taken that over. so it seems everyone is in agreement here and to be entirely clear, i'm not suggesting there is anything wrong with either spawn or backgrounddrb. i thought i'd take a quick stab at use cases for each and hopefully you can clarify so people can understand 1) spawn this just forks your rails app and, as such, is the simplest way to get a background process that has context, etc. it's not going to easily allow say, 1000 incoming requests because you are duping your entire rails process on the fork so you have to be careful with this and about collecting the children so as not to create zombies. 2) backgrounddrb this is going to be good where you have a medium number of background processes, esp if you want to interact with with them. for example, a task, spawn with an ajax request, like a video conversion, cold then be polled using periodically_call_remote to display progress to the user. these processes are going to be living in memory and, unless you code it, there is no concept of queueing. 3) bj this is for fire and forget standalone processes that may or may not load the rails_env. examples would include adding users based on an uploaded csv file and emailing each one or updating 100 rss feeds in the background. the queueing effect is going to save your butt if many requests come in at once and tasks are going to durable across application restart and even reboot (since they live in the db). bj is good where you want to be able track which jobs succeeded or failed, possibly by an external sweeper process, taking appropriate actions as needed. bj tasks are going to be slower to start if you require the rails_env, since you'll need to load the rails app for each process but the memory if going to be freed on each transient task to leaks are of no concern. maybe others can add to this stab a summary... cheers. a @ http://codeforpeople.com/ -- share your knowledge. it's a way to achieve immortality. h.h. the 14th dalai lama