[
https://issues.apache.org/jira/browse/MJARSIGNER-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17796105#comment-17796105
]
ASF GitHub Bot commented on MJARSIGNER-72:
------------------------------------------
schedin commented on code in PR #18:
URL:
https://github.com/apache/maven-jarsigner-plugin/pull/18#discussion_r1425095671
##########
src/main/java/org/apache/maven/plugins/jarsigner/JarsignerSignMojo.java:
##########
@@ -174,6 +197,36 @@ protected JarSignerRequest createRequest(File archive)
throws MojoExecutionExcep
return request;
}
+ /**
+ * {@inheritDoc} Processing of files may be parallelized for increased
performance.
+ */
+ @Override
+ protected void processArchives(List<File> archives) throws
MojoExecutionException {
+ ExecutorService executor = Executors.newFixedThreadPool(threadCount);
Review Comment:
Nice observation! I could, but I'm not sure I should, because it would make
the code a bit harder to read. In the documentation for
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html
there is this text:
> When a new task is submitted in method
[execute(Runnable)](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html#execute-java.lang.Runnable-),
and fewer than corePoolSize threads are running, a new thread is created to
handle the request, even if other worker threads are idle.
That is, for this specific case the number of threads will in practice be
limited to the number of jobs I submit to the thread pool (number of jar
files). Due to how Executors.newFixedThreadPool() work you might end up with a
few more than needed, if the first jobs terminate very fast before the last
has been submitted. But the number of threads will never be more than the
amount of submitted jobs.
I have tested and verified that this behavior holds! Using
`threadCount=10000` and looking at the number of threads in my IDE.
> Parallel signing for increased speed
> ------------------------------------
>
> Key: MJARSIGNER-72
> URL: https://issues.apache.org/jira/browse/MJARSIGNER-72
> Project: Maven Jar Signer Plugin
> Issue Type: New Feature
> Affects Versions: 3.0.0
> Reporter: Lennart Schedin
> Priority: Minor
> Labels: performance
>
> *Background:*
> As of June 1 2023, a new industry standard mandates the storage of private
> keys used for code signing on external hardware devices. Refer to
> [https://knowledge.digicert.com/general-information/new-private-key-storage-requirement-for-standard-code-signing-certificates-november-2022]
> for details. Various devices, from the Thales SafeNet USB eToken (about
> $30), Yubico YubiHSM 2 FIPS (about €1000) up to Thales Luna S700 Series
> (about €30000) can store these keys. Cloud-based HSM solutions (like DigiCert
> KeyLocker ($90/year)) also exist.
>
> This ticket primarily targets HSM as a service but could benefit network
> attached HSM solutions as well.
>
> *Problem:*
> Using the {{jarsigner:sign}} goal it is possible to specify
> {{{}archiveDirectory{}}}, that points to a directory with many jar files.
> This is useful for signing every dependency the project has.
>
> Using the DigiCert Keylocker HSM as a service I measured that it took 240
> seconds to sign 128 jar files. I was in Sweden and the DigiCert Keylocker
> service is in USA. The response time of server is about 500 to 700 ms
> (without any login and without any signing).
>
> I created a quick parallel hack (using the Linux command parallel) that used
> 8 threads and it took only 31 seconds. That is: for this specific HSM service
> it scales linearly with the number of threads used.
>
> *To implement:*
> I propose to implement a parallelization for maven-jarsigner-plugin that can
> be used when signing many jar files at once.
>
> The configuration for this could be a new parameter named {{threadCount}}
> (with user property {{{}jarsigner.threadCount{}}}) with default to 1 (no
> parallelization).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
