Tommi Mäkitalo <tommi@...> writes: > Looks like a problem with a static class. > > If healthCheck calls exit, it is really a fatal situation. A http > request must not run too long. If a request runs too long, tntnet > decides, that the processing hangs and tries to restart itself by > exiting in the child process. The parent process detects it and rerun > the child. > > So you should check, why the request runs too long.
That I should. > The other problem is, that exits starts destroying static classes like > the mutex, which is used here. It looks like a request is just finished > and tries to get that mutex and fails, since it is already destroyed. > > It looks like this is a very special situation in a fatal condition. Or > can you really reproduce it? AFAIK, that's easily reproducibe if one has slow requests. > Another problem is, that healthCheck should call _exit instead of exit. > exit really makes cleanup while _exit does not. It does not make any > sense to cleanup when tntnet tries to exit in such a fatal situation. I > will fix that. IMO, healthCheck should accept handlers/listeners, in that case one might take a stack trace from the listener and shutdown the important things (like embedded database connections which might need to be repaied if not properly closed, or some might even become corrupted). > Tommi ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Tntnet-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tntnet-general
