I think this is a good idea. PHP is not a language to write daemons in... and certainly not scalable daemons.
Having a daemon however is not necessary when working with a queue, just remember to spin off the queue handler that connects to the MQ servers and downloads the messages before the queue grows too much (or too much time has passed). You can also use a cronjob to do that, but i'd rather have a master process to do that in this case. I can see a problem here with XMPP. With the current setup the connection needs to be maintained, not true if you convert it to use XMPP BOSH. In that case you could activate the script each X minutes (depending on the BOSH timeout you specified), do the queued elaborations and die. All you need to do is remember sid & rid. However i do not know how complete is XMPPHP BOSH implementation. I read your wiki post and i saw you suggested using a different language to write this sort of master process. What were your thoughts on this? I'm experimenting with Scala lately and it's quite impressive... i think it could be a good candidate, especially if you want to scale up. 2009/10/23 Brion Vibber <br...@status.net> > Some of StatusNet's awesomer features like the XMPP and Twitter bridges > require running background daemons to watch event queues or keep connections > to XMPP servers open. > > Alas, this just isn't going to scale to the future StatusNet 1.0 world > where we're going to be running thousands of instances for our hosted > services. We see a lot of problems with memory leaks and instability in > those daemons with even just a few live sites now... > > > I've worked out what I think is a feasible architecture for a more scalable > queue/daemon system for big sites to use; details and some diagrams I > whipped up to help me keep my head straight are up on the wiki: > > http://status.net/wiki/Daemon_redesign > > > I'm planning to use a single lightweight master daemon which will maintain > long-running connections to the ActiveMQ queue and XMPP daemons. Actual > event handling will still be done at the PHP/StatusNet level, but now as > short-running processes which will handle a single event and exit. > > This reduces the surface area for memory leaks and other oddities we > encounter in long-running PHP scripts, and most importantly means we only > have to run as many processes are there actually are events being handled! > > Please feel free to give some feedback before I jump into implementation. > :) > > -- brion vibber (brion @ status.net) > Senior Software Architect, StatusNet > San Francisco > > _______________________________________________ > StatusNet-dev mailing list > StatusNet-dev@lists.status.net > http://lists.status.net/mailman/listinfo/statusnet-dev > -- --------------- FM Flow with whatever is happening and let your mind be free. Stay centered by accepting whatever you are doing. This is the ultimate. - 庄子 (Chuang Tzu)
_______________________________________________ StatusNet-dev mailing list StatusNet-dev@lists.status.net http://lists.status.net/mailman/listinfo/statusnet-dev
