-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Rémy,
On 10/15/18 10:49, Rémy Maucherat wrote: > Hi, > > Looking at threads since there's a proliferation of executors and > loose threads, I notice a possible refactoring: - > start/stopExecutor is an obvious target, but by default is not > there. However, it does not delegate to the parent container if not > there. - The background thread is a loose thread, if the > start/stopExecutor or whatever it is was a > ScheduledThreadPoolExecutor, then it can probably be refactored. - > Some executors in the clustering code, they could be run by that > "start/stopExecutor" of thir parent container. - As for the > catalina.Executor(s) in the Service, it could still wrap all this > stuff, *if* our ThreadPoolExecutor used a > ScheduledThreadPoolExecutor instead (at least as an option). > > So .. Options are: a) Do nothing. b) Merge everything except > catalina.Executor into a new ScheduledThreadPoolExecutor at the > Container level (and delegate to parent), so the Engine will have > it by default. Given how the background thread delay config and how > startStopThreads work, this can remain mostly compatible, except > some internal API from the start/stop executor is going to be > gone. c) Merge everything into one executor. Hopefully NIO2 users > remember they should give their connector its own executor. > > So personally, I think b) is nice as the Excecutor is more for > connector pools configuration and we shouldn't pollute that with > side uses. Is that doable in 9, or should it be added to the "10" > todo list ? > > Comments ? 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. 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
