-
1. Re: Job operator
during the startup, the only heavy piece is searching the appropriate JobOperator provider and creating it. This all happens in the standard class BatchRuntime.
You can try creating JBeret's JobOperator impl class directly, just for comparison purpose. See examples here:
jsr352/AbstractIT.java at master · jberet/jsr352 · GitHubThe above works with 1.2.2.Final or later in 1.2.x line, and 1.3.0.Beta4 or later in 1.3.x line of releases. For older releases, instantiate JBeret's JobOperatorImpl class directly.
Did you notice the slowness starting any particular release?
For REST calls, there is jberet-rest-api sub-module in JBeret project to support all the essential batch job operations. jberet-rest-api jar can be packaged inside your web app WAR file.
jsr352/jberet-rest-api at master · jberet/jsr352 · GitHub
jberet-rest-api is a community project and its support is not included in JBoss EAP subscription. Instead it is backed by the community support here or other community venues.
-
2. Re: Job operator
Did not notice when it started, someone noticed the time lag in the log and then ran a grep to see if it was an anomaly but it appears to be happening often and varies in the length of time getting started. Is there a way to troubleshoot the process to see where the time is being used? Is it just pulling down the source and putting in log messages?
So we can use our third party scheduler to issue rest calls to start jobs?
-
3. Re: Job operator
I assume this "up to 3 seconds" does not include JVM start time. The job start involves getting JobOperator (which involves search classpath for the JobOperator impl service provider, so we should keep the classpath as short as possible), connecting to job repository, so if it's jdbc job repository, it invovles connecting to the db. If the database server is running in another host, there is extra network overhead. There may be performance tools out there but I'm not knowledgable.
Yes, any external client can make rest calls to your batch application when jberet-rest-api is packaged inside the app war file.
Another option for REST calls in JBoss EAP, is to use EAP's management api, which is part of EAP so no need include jberet-rest-api in your app. Some batch processing related operations are included in EAP's management api, so if you just need these limited types of rest operations, this may be a viable option. This is similar to issue batch processing commands in EAP CLI, or web console.
The HTTP management API - Latest WildFly Documentation - Project Documentation Editor
jberet-rest-api support the full batch processing operations as you would see in JobOperator interface, and additional features. jberet-rest-api docs:
http://docs.jboss.org/jberet/latest/rest-doc/ -
4. Re: Job operator
You are correct, the JVM has already started. It is just the time to get the JobOperator. What is the best order for the jars to make this as fast as possible?
-
5. Re: Job operator
if you have control over the order of the jars in classpath, try to put batch api jar, jberet-core.jar and its direct deps jars in the front part of the classpath. For example, the following is the classpath I used in one of my test apps:
../bin:jboss-batch-api_1.0_spec-1.0.0.Final.jar:jberet-core-1.3.0.Beta6-SNAPSHOT.jar:jberet-se-1.3.0.Beta6-SNAPSHOT.jar:jboss-transaction-api_1.2_spec-1.0.0.Final.jar:wildfly-security-manager-1.1.2.Final.jar:jboss-logging-3.3.0.Final.jar:jboss-marshalling-1.4.10.Final.jar:cdi-api-1.2.jar:weld-core-2.3.4.Final.jar:weld-se-2.3.4.Final.jar:weld-spi-2.3.SP2.jar:jberet-support-1.3.0.Beta6-SNAPSHOT.jar:validation-api-1.1.0.Final.jar