Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-11261

CLI unable to refer jberet resources after run PurgeBatchlet

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 15.0.0.Beta1, 15.0.0.Final
    • 14.0.0.Final
    • Batch
    • None
    • Hide

      1. Deploy attachment reproduce application.
      2. Execute something jberet job. Access to http://localhost:8080/jberet-sample/batch.
      3. Execute purge job. Access to http://localhost:8080/jberet-sample/purge.
      4. Execute below command by JBoss CLI, then, ERROR message show on server.log.

      /deployment=jberet-sample.war/subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true)
{
    "outcome" => "failed",
    "rolled-back" => true
}
      Show
      1. Deploy attachment reproduce application. 2. Execute something jberet job. Access to http://localhost:8080/jberet-sample/batch . 3. Execute purge job. Access to http://localhost:8080/jberet-sample/purge . 4. Execute below command by JBoss CLI, then, ERROR message show on server.log. /deployment=jberet-sample.war/subsystem=batch-jberet:read-resource(include-runtime= true ,recursive= true ) { "outcome" => "failed" , "rolled-back" => true }

    Description

      It's not possible to refer jberet runtime resource after execute org.jberet.repository.PurgeBatchlet with batch property "purgeJobsByNames".

      jboss-cli output before execute PurgeBatchlet
      [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
{
    "outcome" => "success",
    "result" => {
        "instance-count" => 1,
        "job-xml-names" => ["dummy-job.xml"],
        "running-executions" => 0,
        "execution" => {"1" => {
            "batch-status" => "COMPLETED",
            "create-time" => "2018-10-31T14:54:27.297+0900",
            "end-time" => "2018-10-31T14:54:27.343+0900",
            "exit-status" => "COMPLETED",
            "instance-id" => 1L,
            "last-updated-time" => "2018-10-31T14:54:27.343+0900",
            "start-time" => "2018-10-31T14:54:27.306+0900"
        }}
    }
}
      jboss-cli output after PurgeBatchlet
      /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource(include-runtime=true,recursive=true)
{
    "outcome" => "failed",
    "rolled-back" => true
}

      Then output following server.log

      14:55:23,104 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("deployment" => "jberet-sample.war"),
    ("subsystem" => "batch-jberet"),
    ("job" => "dummy-job"),
    ("execution" => "1")
]): javax.batch.operations.NoSuchJobExecutionException: JBERET000604: No job execution with id 1
	at org.jberet.operations.AbstractJobOperator.getJobExecutionImpl(AbstractJobOperator.java:354)
	at org.jberet.operations.AbstractJobOperator.getJobInstance(AbstractJobOperator.java:310)
	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobInstance(JobOperatorService.java:281)
	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecution(JobOperatorService.java:308)
	at org.wildfly.extension.batch.jberet.deployment.BatchJobExecutionResourceDefinition$JobExecutionOperationStepHandler.updateModel(BatchJobExecutionResourceDefinition.java:200)
	at org.wildfly.extension.batch.jberet.deployment.JobOperationReadOnlyStepHandler.execute(JobOperationReadOnlyStepHandler.java:47)
	at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.executeRuntime(JobOperationStepHandler.java:74)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
	at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
	at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
	at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)

      Even though delete JobExecution in JobRepository, JobExecution id "1" still show by JBoss CLI.

      jboss-cli output
      [standalone@localhost:9990 /] /deployment=jberet-sample.war/subsystem=batch-jberet/job=dummy-job:read-resource
{
    "outcome" => "success",
    "result" => {"execution" => {"1" => undefined}}
}

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-15750 [GSS](7.1.z) CLI unable to refer jberet resources after run PurgeBatchlet

          • 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. WFLY-11264 The BatchJobExecutionResource.hasChild() needs to be reviewed for purged jobs

          • 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.
          • Coding In Progress

          Activity

            People

              cfang@redhat.com Cheng Fang
              rhn-support-nagetsum Norito Agetsuma
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: