-
Notifications
You must be signed in to change notification settings - Fork 142
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
shutdown() function for CleanerThread #27
base: main
Are you sure you want to change the base?
Conversation
try { | ||
ref = queue.remove(); | ||
try { | ||
while(!shutdownLatch.await(100, TimeUnit.MILLISECONDS)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have a reasoning as to why 100ms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not against a timeout, but 100ms looks way too small.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed it to seconds.
Not really. |
throw td; | ||
} catch (Throwable t) { | ||
t.printStackTrace(); | ||
} finally { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should release the hatch at the finally
block, before setting queue
to null
:
shutdownLatch.countDown();
@jjYBdx4IL I see that you modified the pull request after my comments, just wanted to point out that I'm not a Batik developer nor am I related to the ASF in any way. Thus, my comments do not represent any "official" statement from the Batik developers, the PMC nor the ASF. |
8ac91be
to
e0f777e
Compare
* de-initialize CleanerThread variables on thread shutdown * don't run CleanerThread as daemon
e0f777e
to
1a3a005
Compare
Up to Java 18 a workaround existed to stop the thread from outside (eg. application code). This was necessary for re-deploying the app in a JEE environment without having leaks. Now, after Java 21 LTE is mainstream, no more workaround exists (Thread.stop is unsupported). Since this is a real problem for companies and forks exists, may I kindly ask why this won't be included in the original Batik distribution? Can I help getting this integrated? |
I am not a Batik developer but instead the maintainer of one of the forks that you mention: I hope that this PR will not be merged because the patch is incorrect. A BTW my fork has had a correct fix since three years ago :-)
|
proper fix for:
https://issues.apache.org/jira/browse/BATIK-939
instead of using or suppressing interrupts, a simple CountDownLatch is used to check whether the thread should shut down or not.