9 Replies Latest reply on Dec 20, 2016 5:28 PM by richardmoore

Long delay in getting JobOperator

richardmoore Dec 14, 2016 3:27 PM

It is taking roughly 3 minutes for the following to run. Got any ideas why? It doesn't matter if I use a jdbc connection or in memory. The following is in memory.

private void initializeOperator() {

try {

log.log(Level.INFO, "Creating job operator.");

operator = BatchRuntime.getJobOperator();

log.log(Level.INFO, "Job operator created.");

} catch(Exception e) {

log.log(Level.SEVERE, "Failed during creation of job operator.", e);

throw new RuntimeException(e);

}

Log entry -

2016-12-14 14:20:28.947 [main ] JavaBatchExecutor - [INFO ] Creating job operator.

2016-12-14 14:23:23.908 [main ] JavaBatchExecutor - [INFO ] Job operator created.

1. Re: Long delay in getting JobOperator

cfang Dec 14, 2016 3:39 PM (in response to richardmoore)

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?
Actions
2. Re: Long delay in getting JobOperator

richardmoore Dec 14, 2016 4:46 PM (in response to cfang)

Yes we do. Is there a way to use a minimal list of jars and then dynamically add them afterwards?
Actions
3. Re: Long delay in getting JobOperator

cfang Dec 14, 2016 5:34 PM (in response to richardmoore)

not in the standard use of Java SE. You can first try to eliminate non-used jars.
Actions
4. Re: Long delay in getting JobOperator

cfang Dec 14, 2016 10:03 PM (in response to cfang)

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
Actions
5. Re: Long delay in getting JobOperator

richardmoore Dec 20, 2016 5:04 PM (in response to cfang)

Sorry for the delay in getting back to you, I got pulled off this for something else. I scaled my classpath back to -

* cdi-api-1.2.jar
* javax.inject-1.jar
* jboss-batch-api_1.0_spec-1.0.0.Final.jar
* jboss-transaction-api_1.2_spec-1.0.0.Final.jar
* guava-18.0.jar
* jberet-core-1.3.0.Beta3.jar
* jboss-logging-3.3.0.Final.jar
* jboss-marshalling-1.4.10.Final.jar
* weld-core-2.3.4.Final.jar
* wildfly-security-manager-1.1.2.Final.jar

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?
Actions
6. Re: Long delay in getting JobOperator

cfang Dec 20, 2016 5:09 PM (in response to richardmoore)

jberet-se.jar should also be included, when running JBeret in Java SE environment.

and same for weld-se.jar
Actions
7. Re: Long delay in getting JobOperator

cfang Dec 20, 2016 5:11 PM (in response to cfang)

in JBeret project README.md, towards the end, lists what jars are required for Java SE environment:
Actions
8. Re: Long delay in getting JobOperator

cfang Dec 20, 2016 5:17 PM (in response to cfang)
Somewhat related info, the performance of getting job operator from BatchRuntime via service provider api was raised in this JIRA issue:

JBERET-223
BatchRuntime should cache the ServiceLoader for JobOperator
Actions
9. Re: Long delay in getting JobOperator

richardmoore Dec 20, 2016 5:28 PM (in response to cfang)

We figured it about the time you replied. These changes greatly improved our response time. It took about 18s rather than 2-3 minutes.
Actions

Go to original post

BatchRuntime should cache the ServiceLoader for JobOperator