On Tue, Nov 6, 2018 at 4:18 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> This reply is quite late, I'm sorry for that. > > I'm not sure if this has changed since a while back, but it used to be > that an application could inadvertently kill the background thread. > One way to do that would be to trigger OOME or StackOverflowError on > the thread during some operation. An OOME that wasn't actually fatal > for the JVM because the objects were all local to the thread and > collectable once the exception was thrown. > > If the background thread died, sessions would no longer expire, which > would eventually take everything down. > > If we are going to re-organize threads, I think it would be best if > there were protections against the above scenario... basically, > another thead watching the background threads. I think you get that > already with an ExecutorService and a periodic job, so perhaps there > isn't much to talk about. > The executor will deal with auto respawning up to its core threads, of course. Otherwise, at the moment, the behavior is the same as before: if an exception remains uncaught like your OOM or ThreadDeath or whatever, it will cancel the scheduling (and I haven't added the code to add it back). I have chosen to use scheduleWithFixedDelay (subtle tweaks can be made here: some of the calls could use scheduleAtFixedRate instead, maybe like the connector async timeout), and the javadoc says: If any execution of the task encounters an exception, subsequent executions are suppressed. So you think adding back the scheduling after a problem is better ? Rémy > > I just wanted to keep that in mind. > > Thanks, > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvhsLQACgkQHPApP6U8 > pFhweRAAg3KnU+ThVhHMu+tKrXZwh7p7R4QmfokAIzLL08V1O1DW0fHtH+Z1KN0g > PsCjoKulluGUa8ByhSVFHKbACXP6aD5LpFFB9dyZZsGkI1SeRPEzm37ptIkzl7lV > /2wSydZ36XCb7+DoxUllgLu3lTT0FcoSXKWM3VcjjqeO2ChRUPJdygMpDUAfIcRo > yVfXpnfbWND0r6b9OG3UpFES6vw3NWHf7YP7IuWiB6tA+P4kBAZ2poQ0V/8stVJm > bbSu6t8sDH3jGGlMMmhpanSi9789IanyUi2hink/0MZwg25u8xqJly7Yz76nrwt6 > +9shVGehBgZIHjEp9j77vePaigXXE9hK51j23Pk+98FEQ1PJiS5ZVZB8vag2d3Yq > C7ROAzMmZGMh3ymLcwWQgBV/FL1h5YNpHqGyL7IiqnSQKynkMm/2DmDYVgPoxymC > SwzLz2bPRHKMHIkqP20izj6lBo4KMHAFAqI7EFCeeCK7l/M2rGR0qeO/DrXwW0vd > nZt+2f+5WXxsH5oH+GP19EKB1blT9T0yD5AV02dBeDcjkhO/3ZITw4+Lp8J38LVi > 4mwlhSuodJVq1Ei6Ur3+LBBkPh6mBBnFChlJf0d2NmVwdNHhjfJuK4KnPIRvNdzk > oNgpEVCC0It9csaz8O8JTFpifiyMfIjqDQDypTKUDUXkEr6Sw60= > =1fzA > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
