Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-14733

[GSS](7.1.z) JBERET-417 - Incorrect jberet batch status is shown if we have multiple standalone node involved.

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.1.4.CR1, 7.1.4.GA
    • 7.1.1.GA
    • Batch
    • None
    • Hide

      1. Run locally two JBoss EAP 7.0 standalone server instances with the batch subsystem pointing to the same db. You can use standalone.xml_1 and standalone.xml_2 from attachment.
      2. Build and Deploy an batch-processing application from attachment and start batch on the 1st JBoss instance.

      [GET] http://localhost:18080/batch-processing/start

      In console you can see output like as:
      ~~~~
      15:24:16,023 ERROR [stderr] (default task-6) Seconds = 5
      15:24:16,032 ERROR [stderr] (default task-6) Execution ID = 1
      15:24:16,040 ERROR [stderr] (Batch Thread - 4) Start.
      15:24:21,041 ERROR [stderr] (Batch Thread - 4) End.
      ~~~

      3. Query job execution status on the second instance using below URL. It should report "STARTED".

      [GET] http://localhost:28080/batch-processing/status

      In the console you should be able to see logging like as:
      ~~~~
      INFO [stdout] (default task-7) Id=1
      INFO [stdout] (default task-7) BatchStatus=STARTED
      INFO [stdout] (default task-7) ExitStatus=null
      INFO [stdout] (default task-7) JobParameters.seconds=5
      ~~~~

      4. Batch execution will be completed after 5 seconds. Now check the batch status on 1st node, it will be 'COMPLETED'.

      [GET] http://localhost:18080/batch-processing/status

      5. Check batch status on 2nd node using below REST endpoint:

      [GET] http://localhost:28080/batch-processing/status

      It will still showing batch status as 'STARTED'.

      Show
      1. Run locally two JBoss EAP 7.0 standalone server instances with the batch subsystem pointing to the same db. You can use standalone.xml_1 and standalone.xml_2 from attachment. 2. Build and Deploy an batch-processing application from attachment and start batch on the 1st JBoss instance. [GET] http://localhost:18080/batch-processing/start In console you can see output like as: ~~~~ 15:24:16,023 ERROR [stderr] (default task-6) Seconds = 5 15:24:16,032 ERROR [stderr] (default task-6) Execution ID = 1 15:24:16,040 ERROR [stderr] (Batch Thread - 4) Start. 15:24:21,041 ERROR [stderr] (Batch Thread - 4) End. ~~~ 3. Query job execution status on the second instance using below URL. It should report "STARTED". [GET] http://localhost:28080/batch-processing/status In the console you should be able to see logging like as: ~~~~ INFO [stdout] (default task-7) Id=1 INFO [stdout] (default task-7) BatchStatus=STARTED INFO [stdout] (default task-7) ExitStatus=null INFO [stdout] (default task-7) JobParameters.seconds=5 ~~~~ 4. Batch execution will be completed after 5 seconds. Now check the batch status on 1st node, it will be 'COMPLETED'. [GET] http://localhost:18080/batch-processing/status 5. Check batch status on 2nd node using below REST endpoint: [GET] http://localhost:28080/batch-processing/status It will still showing batch status as 'STARTED'.

    Description

      Customer is using JEE batch (JSR 352) feature in there application, which is deployed on two standalone nodes. Multiple standalone server instances(EAP 7.0) sharing the same batch datasource. The jdbc module name used in jberet is same for both servers,standalone_1 and standalone_2,both are referring to the same datasource.

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-14859 [GSS](7.2.0) Incorrect jberet batch status is shown if we have multiple standalone node involved.

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Bug - A problem that impairs or prevents the functions of the product. JBERET-417 Incorrect jberet batch status is shown when using JDBCRepository and multiple nodes

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          is incorporated by

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. JBEAP-14952 [GSS](7.1.z) Upgrade jberet to 1.2.6.Final

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBERET-417 Incorrect jberet batch status is shown when using JDBCRepository and multiple nodes

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              rhn-support-iweiss Ingo Weiss
              rhn-support-abhumbe Abhijit Humbe
              Daniel Cihak Daniel Cihak
              Daniel Cihak Daniel Cihak
              Votes:
              7 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: