On Sun, Jun 14, 2015 at 9:59 AM, Didier Kryn <[email protected]> wrote: > What happens then? Does the webprinting service crash? Or does it hang > until Cups is ready? Is it able to detect that it is hanging? The last > would probably be the most sensible way to handle the dependency :-) A > professional webprinting service should be able to do that. And this is > what Cups itself does when a printer is paused. >
A professional web application should use a task queuing service for anything that is not directly necessary to return a result to the HTTP(S) transaction. That task queuing service should in turn attempt to perform the queued tasks, and if they fail in a manner that is transient - like an API endpoint not yet responding, or a print spooler not yet ready to take jobs, they should leave the jobs on the queue. There's still a dependency, but it's a softer one that no longer requires an explicit ordering of daemons starting. A professional service of any sort should have monitoring - the administrator should be alerted within minutes if a service doesn't start when it should or goes down when it shouldn't, Getting a little off topic at this point, but opinions vary as to whether the monitoring should actually restart the service or not. I'm firmly in the camp that process supervision is evil, because service failures on a *nix system should not happen, and when they do they should be a really big inconvenient deal that wakes people up at 3am - because that's the sort of thing that gets problems noticed and fixed. Process supervision trivializes failures, and leads us down a path of *tolerating* them and fixing the symptoms instead of fixing the problem - a really dangerous path when exploitable code and malicious input are very common causes of service failure.
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
