> -----Original Message----- > From: Greg A. Woods [mailto:woods-cyrus@xxxxxxxxx] > Sent: Friday, November 20, 2009 6:06 PM > At Fri, 20 Nov 2009 11:14:19 -0500, "Dan Smith" > <rrdansmith@xxxxxxxxx> wrote: > Subject: RE: Is there a graceful shutdown of imapd process? > > > > My main goal is really to distribute newly created > subscribers across > > multiple partitions. The vendor supports multiple messaging > > solutions, so they chose to implement this partition load > balancing as > > an external script that updates the default partition and > restarts imapd. > > (do you mean "imapd" there, or do you mean the Cyrus "master" > process?) I really mean imapd. They are updating the imapd.conf file with a new default partition, and then killing off the imapd processes as a way to get it to reload the config and move to the next partition. > Either way that sounds rather hokey for the purpose... I completely agree there. > For example, what exactly does it mean to "support multiple > messaging _solutions_", and how exactly does this have > anything to do with active load balancing of IMAP/POP > services over different "partitions"? Does "partition" here > really mean what it does in /etc/imapd.conf? Why the heck > isn't this level of "load balancing" being down way down in > the storage "layer"? Does this in any way involve a MURDER > configuration? The support of multiple messaging solutions really refers to the fact that the company doesn't just use Cyrus. They support other messaging solutions that might not behave exactly the same way as Cyrus for load balancing. So their argument is that building support for the distribution of subs across multiple partitions for Cyrus into the code would break support for one of the other messaging solutions. No connection with murder...this is specifically for the creation of the accounts. > > I have a strong > > dislike for killing active connections, so I'm trying to > find a better > > solution. > > I wouldn't worry about it and you should not either. The > correct solution is to ask each active imapd to close its > connection cleanly but quickly, and to exit cleanly. > > The IMAP protocol _MUST_ be robust against such events. (I > haven't done a protocol analysis to determine this, but I do > observe that some IMAP servers have login timeouts which > disconnect idle clients, and I also observe that many other > events can adversely affect communications between a client > and the server at any time causing the connection to > terminate abruptly at any phase or state.) Understood...and I will definitely go back and completely verify my concerns with some additional tests. This Cyrus install is fronting larger than average files (~1.5M each) on a voicemail solution. As a result, the retrieval/playback would be impacted if the connection was severed and then rebuilt/restarted. That said, I need to go back and quantify the actual end user impact of a restart. My experience said it was a bad idea, and initial testing showed enough delay in presentation to worry me. > HOWEVER, this is _not_ what the patch being circulated does. > > Currently the patch only tells _waiting_ processes to timeout > and exit without accepting any new connections. _Active_ > working processes will still _ignore_ the SIGHUP. > > The patch as it sits is _extremely_ safe! > > It probably also does _exactly_ what your vendor's solution > requires in order to implement their form of partition load balancing. Thanks for the explanation of the patch, and you are right...that's exactly what we need. I will go ahead and start a full-court press to get them to adopt it. Thank you! -dan > -- > Greg A. Woods > > +1 416 218-0098 VE3TCP RoboHack > <woods@xxxxxxxxxxx> > Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird > <woods@xxxxxxxxx> > ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
