That is for the most part what I have currently, but I seem to be getting some kind of contamination of the variables, because sometimes it tries to send a response to one that it has already sent, resulting in the headers already being sent, while some requests never receive a response. I just find that trying to debug these problems makes me spin in circles for a day and then I end up right where I started.
On Wednesday, June 26, 2013 5:23:37 PM UTC+12, Jason Crawford wrote: > > I can't find the reference now, but I've read that the best approach is > actually: stop accepting *new* connections (taking the server out of the > load balancer), finish the requests that are in process, and then shut down > gracefully and restart. That seems better to me than sending an HTTP 500 to > every open request, just because one of them happened to get an error, > which would seem to increase your overall error rate by orders of magnitude. > > -Jason > > -- > Blog: http://blog.jasoncrawford.org | Twitter: @jasoncrawford > > > On Tuesday, June 25, 2013 3:22:05 PM UTC-7, Tyler Cooke wrote: >> >> In my attempts to keep 100% uptime on my application I've implemented >> automatic restarting of worker processes when one dies (cluster module), >> but one of the problems I am having is that any connections that are >> currently open on that process are just left hanging until it gets a >> ECONNRESET. I'm using a restify server. >> >> Ideally I'd like to just return a 500 response to the single request that >> has a problem and continue with everything else, but from what I understand >> it is necessary to restart the process to avoid any unexpected behaviour. >> >> I've had a look at domains (both server and request level), and the >> trycatch module both with varying results, but nothing with which I can >> consistently return a response to the remaining open connections. >> >> >> So my question is, does anybody have any examples of robust exception >> handling around servers with multiple connections open? >> >> This e-mail, and any attachments, is intended only for use by the >> addressee(s) named herein and may contain legally privileged and/or >> confidential information. It is the property of Telogis. If you are not >> the intended recipient of this e-mail, you are hereby notified that any >> dissemination, distribution or copying of this e-mail, any attachments >> thereto, and use of the information contained, is strictly prohibited. If >> you have received this e-mail in error, please notify the sender and >> permanently delete the original and any copy thereof. >> > -- This e-mail, and any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. It is the property of Telogis. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, any attachments thereto, and use of the information contained, is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the original and any copy thereof. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" 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/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
