I see that Brion added the concept of queue groups in this commit: http://gitorious.org/statusnet/mainline/commit/0e852def6ae5aa529cca0aef1187152fb5a880be
Queue groups are pretty neat, and I'd like to see the concept extended to iomanagers, too. I suggest IoMaster gets a "connect($class, $group)" function that is used from the StartQueueDaemonIoManagers event (instead of simply appending the iomanager class to an array) in the same style as the StartInitializeQueueManager event. Then IoMaster considers active groups the same way QueueManager does. I also think QueueManager and IoMaster should be able to each handle multiple active groups, instead of one. The command line daemon that starts them should have a parameter that specifies a list of groups this daemon should handle (or a way to specify that it should handle all of them). For the simple, most common case of a small StatusNet server, the admin would simply run (for example) "startdaemon.sh --all" then, when their load increases and they need to separate out IMAP processing, then would run "startdaemon.sh --all --except imap" on one server, then "startdaemon.sh imap" on another, and they can keep separating out groups as they scale the site. This approach would also make authoring plugins easier. For example, consider the IMAP plugin. It is simply an iomanager, and it would be nice if it could be run separately of the queue manager infrastructure and other iomanagers (as depending upon the latency of the imap connection and volume of mail, the imap iomanager could be a major drain). However, to allow it to run separately, the plugin author has to create a new executable script and leverage the SpawningDaemon class, and then the plugin has to be executed using a separate command, which is annoying for sysadmins. With groups, the imap plugin could say that its iomanager is in the "imap" group, and "startdaemon.sh" could decide whether to run that group or not depending upon command line parameters. How do these ideas sound? Thanks, ~Craig _______________________________________________ StatusNet-dev mailing list [email protected] http://lists.status.net/mailman/listinfo/statusnet-dev
