5 Replies Latest reply on Aug 29, 2017 7:41 PM by Cheng Fang

    Job operator

    Richard Moore Master
      1. When we have several jobs start up they can take up to 3 seconds to get started. We are running stand-alone. Got any ideas on where to start troubleshooting?
      2. If we were to go to running in JBoss can our outside scheduler kick off jobs via a REST call?
        • 1. Re: Job operator
          Cheng Fang Master

          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 · GitHub

           

          The 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
            Richard Moore Master

            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
              Cheng Fang Master

              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
                Richard Moore Master

                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
                  Cheng Fang Master

                  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