On Mon, May 23, 2011 at 8:56 AM, Phredward <[email protected]> wrote: > I'm wondering if anyone is working on a graceful restart solution for > paster? > > While working with pylons in a production environment, I noticed that when > we restarted after a deploy, we would see a spike in 500's. This was caused > by multiple factors, but high up in the list was the fact that the default > paster restart command kills the old process without letting active worker > threads finish. > > I did just a little bit of hacking to try to see what I could come up with, > and was wondering if I could get feedback on this, and who was the right > person to coordinate with and submit patches too? (semi-related, I hear > pyramid might be ditching paster, who's a good person to talk to about > that?)
Zope has an admin screen where you can stop or restart the server. Pylons has never had that, mainly because the functionality doesn't exist in PasteHTTPServer. It would be nice. The Paste reorganization is still theoretical. There are two levels. One is Paste itself, which is best discussed on paste-users. The other is whether Pyramid 2 might replace some Paste components with other things. That's best discussed here. Some ideas are on https://github.com/Pylons/pyramid/wiki/Pyramid-2-brainstorm ; see also the pylons-devel and pylons-discuss archives. There's no final decision or overall plan; just a vague idea that "Pyramid 2" might switch to other things for services currently provided by Paste. Paste started as a miscellaneous package with several distinct services. Then PasteDeploy and PasteScript were factored out as namespace packages. Later WebOb and WebError were spun off as separate packages. and have since been upgraded. Then PasteOb was spun off containing some of Paste's other services. WebOb, WebError, and PasteOb are maintained, while the rest of Paste is waiting for direction. One idea is to spin off PasteDeploy and PasteScript to a new package (including the equivalent of "paster create", "paster serve", and PasteHTTPServer, but maybe not extensible for other commands. "paster make-config" and "paster setup-app" are not used much and not really necessary; you can just as easily make a top-level script.) The minimum port would just implement the existing functionality and command-line options. The maximum port would make changes. But there has been no agreement what those changes would be. A couple people are writing alternatives to PasteDeploy and PasteScript. These would work with Pyramid 1 on a configure-it-yourself basis, and the ones that prove the most popular may become default in Pyramid 2. There's also Marrow, a family of packages that provides similar functionality in a different way. But we think that switching to Marrow would be too big a step at this time. So, we're mainly waiting for these alternatives to be implemented as third-party packages, and then we'll see how well they work. Python 3 also relates to this, as Paste* need to be ported to Python 3. The question is whether to just do a straight port, or whether the existing Paste code is worth porting, or whether it would be better to start from scratch with something else. Some parts of Paste can also be added to Pyramid itself, such as paste.httpexceptions. I think we're just putting it on the back burner until some other dependencies are ported to Python 3 and some of the potential alternatives are released. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
