the main work here is trying to find the job operator via service discovery. Do you happen to have a long classpath with large jar files?
I've never seen such long delay in getting job operator. I can usually complete the whole batch tck (over 160 tests and even many more calls to getJobOperator) under 1 minute if using in-memory job repository. Can you adjust the jvm memory setting and see if it makes any difference?
Yes we do. Is there a way to use a minimal list of jars and then dynamically add them afterwards?
not in the standard use of Java SE. You can first try to eliminate non-used jars.
Besides removing unused jars from classpath, some other things you can try:
* put jberet-core.jar, and jboss-batch-api_1.0_spec-1.0.0.Final.jar first in classpath entries. If you're using wildcard in classpath, you'll need to change classpath to list all jar files.
* use more recent version of java, if possible
* allocate more memory to the jvm
Sorry for the delay in getting back to you, I got pulled off this for something else. I scaled my classpath back to -
But now I am getting -
JBERET000640: A BatchEnvironment implementation could not be found. Please ensure the SPI has been implemented and is on the class path.
What am I missing?
jberet-se.jar should also be included, when running JBeret in Java SE environment.
and same for weld-se.jar
Somewhat related info, the performance of getting job operator from BatchRuntime via service provider api was raised in this JIRA issue:
BatchRuntime should cache the ServiceLoader for JobOperator
We figured it about the time you replied. These changes greatly improved our response time. It took about 18s rather than 2-3 minutes.