-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QueuedThreadPool should support ThreadFactory behaviors #4121
Comments
ThreadFactory semantic Signed-off-by: Greg Wilkins <[email protected]>
Several QTP fixes: * #4105 Threads without jobs now check if they should idle die before waiting rather than before, this allows idling under steady load. 3ad6780 * #4121 ThreadFactory behaviour supported by doing thread config within newThread call. 7b306d7 * #4122 Always clear the interrupted status. c37a4ff task = queue.poll(timeout); Signed-off-by: Greg Wilkins <[email protected]>
The fix in PR #4146 is only a half fix. |
Signed-off-by: Joakim Erdfelt <[email protected]>
Opened PR #4149 (currently in draft status as I work on unit tests) |
Signed-off-by: Joakim Erdfelt <[email protected]>
Issue #4121 - ThreadFactory support in QTP
FYI, by making the protected |
The change was intended. |
@josephlbarnett to be precise... the change to use the ThreadFactory API was intended.... that fact that this change breaks backwards compatibility was an unintended consequence. In retrospect we should not have broken that in a point release, but it is a good change and it is out now... we'd cause more disruption I think by reverting. |
@gregw Currently this causes a bug for anyone using the spring-boot-dependencies bom as a baseline for dependency management. See spring-projects/spring-boot#19769. |
We already have large projects using this new feature (as it was requested by them). |
I understand. As highlighted in the spring-boot ticket linked above, spring-boot clearly also wanted this and other new features, but maybe you have some way to cut a special version of the 9.4.24 release, which rolls back this breaking api change only. The impact is rather big, as any project using spring boot version 2.2.1+ to drive their dependency management (default behaviour when using their maven or gradle plugin) will automatically get their versions managed to this broken combination of jetty and jersey. |
We are about to release 9.4.26 to address issues discovered in 9.4.24 and 9.4.25 Jersey is the reason for the 9.4.26 release due to issue #4461, they will be upgrading to 9.4.26. |
@NielsDoucet other large projects that use Jersey have been able to use Jetty 9.4.24 and 9.4.25 without a similar issue to spring-boot. |
I don't believe it is unique to Spring Boot. As I understand it, it's a problem for anyone trying to use Jersey 2.29.x with Jetty 9.4.22 and later when Jersey's responsible for creating the Jetty instance. As shown in the Boot issue referenced above (spring-projects/spring-boot#19769), one way to do that is by using Jersey's test framework. Spring Boot users who aren't using Jersey's test framework may not be affected at all as Boot will create the Jetty instance and configure Jersey to run on top of it. My understanding is that will take Jersey's |
The JVM class
java.util.concurrent.ThreadFactory
was introduced in Java 1.5 and the default Executors in Java support it as well.@sbordet proposes that we have
QueuedThreadPool
implementjava.util.concurrent.ThreadFactory
, but also allow the constructor ofQueuedThreadPool
have an optionalThreadFactory
that can be passed in (similar to how the Executors themselves operate)We should also move the configuration of the new thread ....
https://github.com/eclipse/jetty.project/blob/ba728eee5d9e8cfd3b7449b1246546ca2306bb25/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L633-L638
... into the QTP.newThread(Runnable) ...
https://github.com/eclipse/jetty.project/blob/ba728eee5d9e8cfd3b7449b1246546ca2306bb25/jetty-util/src/main/java/org/eclipse/jetty/util/thread/QueuedThreadPool.java#L666-L669
The text was updated successfully, but these errors were encountered: