https://bz.apache.org/bugzilla/show_bug.cgi?id=49159
--- Comment #21 from Joker <fangxuesong1...@163.com> --- (In reply to Sylvain Laurent from comment #11) > Created attachment 26108 [details] > tc7 renew threads one by one in a bounded time > > New patch with further improvements : now the behavior is more > deterministic, with an upper bound to the time necessary to renew all the > threads of the pool. The upper bound is something like > N*max(threadKeepAliveTimeout, longestRequest + threadRenewalDelay). Where N > is the number of threads in the pool and longestRequest is the maximum time > a request takes to be processed (of course it depends on the application). > This is really a worst case scenario and it should be much quicker in usual > cases, something closer to max(threadKeepAliveTimeout, longestRequest). > > I still have to make the threadRenewalDelay configurable (hardcoded to 1s > for now) and to propose some cleanups in WebAppClassLoader since this patch > makes the unsafe-and-disabled-by-default ThreadLocal cleaning obsolete. > (it's still interesting to introspect the ThreadLocals to detect potential > leaks and warn the user, it will help to improve libraries and > applications...). > > Any volunteer for a review before I continue finalizing this patch ? now the behavior is more > deterministic so does the 'more' means 100%(In reply to Sylvain Laurent from > comment #11) > Created attachment 26108 [details] > tc7 renew threads one by one in a bounded time > > New patch with further improvements : now the behavior is more > deterministic, with an upper bound to the time necessary to renew all the > threads of the pool. The upper bound is something like > N*max(threadKeepAliveTimeout, longestRequest + threadRenewalDelay). Where N > is the number of threads in the pool and longestRequest is the maximum time > a request takes to be processed (of course it depends on the application). > This is really a worst case scenario and it should be much quicker in usual > cases, something closer to max(threadKeepAliveTimeout, longestRequest). > > I still have to make the threadRenewalDelay configurable (hardcoded to 1s > for now) and to propose some cleanups in WebAppClassLoader since this patch > makes the unsafe-and-disabled-by-default ThreadLocal cleaning obsolete. > (it's still interesting to introspect the ThreadLocals to detect potential > leaks and warn the user, it will help to improve libraries and > applications...). > > Any volunteer for a review before I continue finalizing this patch ? (In reply to Sylvain Laurent from comment #11) > Created attachment 26108 [details] > tc7 renew threads one by one in a bounded time > > New patch with further improvements : now the behavior is more > deterministic, with an upper bound to the time necessary to renew all the > threads of the pool. The upper bound is something like > N*max(threadKeepAliveTimeout, longestRequest + threadRenewalDelay). Where N > is the number of threads in the pool and longestRequest is the maximum time > a request takes to be processed (of course it depends on the application). > This is really a worst case scenario and it should be much quicker in usual > cases, something closer to max(threadKeepAliveTimeout, longestRequest). > > I still have to make the threadRenewalDelay configurable (hardcoded to 1s > for now) and to propose some cleanups in WebAppClassLoader since this patch > makes the unsafe-and-disabled-by-default ThreadLocal cleaning obsolete. > (it's still interesting to introspect the ThreadLocals to detect potential > leaks and warn the user, it will help to improve libraries and > applications...). > > Any volunteer for a review before I continue finalizing this patch ? 'now the behavior is more deterministic' ,does this 'more' means 100% ? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
