Skip to content
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

enable to preload common pool #199

Closed

Conversation

rmannibucau
Copy link
Contributor

@rmannibucau rmannibucau commented Mar 22, 2021

related to #198

Long story short, since exec:java tries to stop new threads, commonPool ones are identified as such if not already created, issue is that if the exec:java uses commonPool, potentially not in the code (thinking to HttpClient which always uses commonPool for part of its tasks), then exec:java will not stop properly until you skip the shutdown cleanup/daemon flags which is not desired. So idea is to enable to preload the common pool and skip these JVM threads.

Comment on lines +361 to +401
private void preloadCommonPool()
{
try
{
// ensure common pool exists in the jvm
final Class<?> fjp = Thread.currentThread().getContextClassLoader()
.loadClass("java.util.concurrent.ForkJoinPool");
final ExecutorService es = ExecutorService.class.cast(
fjp
.getMethod( "commonPool" )
.invoke( null ) );
final int max = preloadCommonPool > 0
? preloadCommonPool :
Integer.class.cast( fjp.getMethod( "getCommonPoolParallelism" ).invoke( null ) );
final CountDownLatch preLoad = new CountDownLatch( 1 );
for ( int i = 0;
i < max;
i++ )
{
es.submit(new Runnable() {
@Override
public void run() {
try
{
preLoad.await();
}
catch ( InterruptedException e )
{
Thread.currentThread().interrupt();
}
}
});
}
preLoad.countDown();
}
catch (final Exception e)
{
getLog().debug(e.getMessage() + ", skipping commonpool earger init");
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After our chat, I think I understood what is going on here. I am not sure, however, why reflection would be needed.
Anyway. Most of us might not be that familiar with what is going on here. A few words on the 'why' would help a lot:
why using reflection, why initializing it (maybe in conjunction with the ThreadGroup).
From my understanding, no reflection would be needed because the created JFP would not be part of the thread group.

Code comments on the "why" would be great for our maintainers! :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved to java 8 since plugin does not use java 7 anymore which drops the reflection need.
Code by itself does not use thread groups but they are inherited from the calling thread so if commonpool is created lazily in the context of the main (isolatedclassloader) then it would use this threadgroup in some JVM which would let the JVM hang.
This is what https://github.com/mojohaus/exec-maven-plugin/pull/199/files#diff-dd2fe98649dca0e18d01909e1fc59b14c562cf349cb49a2cf19957147dca5551R76 means, happy to get a better wording if you find one, also not sure of the default we should use but at least we have a clean way to solve that issue now.

@bmarwell
Copy link
Contributor

bmarwell commented Apr 8, 2022

Superseeded by #279

@bmarwell bmarwell closed this Apr 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants