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

WildFly can eat exceptions.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 34.0.1.Final
    • Batch
    • None
    • Hide

      Cause org.wildfly.extension.batch.jberet.job.repository.JobRepositoryService.getAndCheckDelegate(JobRepositoryService.java:230) to throw an error (on undeploy) and try to undeploy an application that caused JobOperatorService to be created.

      Show
      Cause org.wildfly.extension.batch.jberet.job.repository.JobRepositoryService.getAndCheckDelegate(JobRepositoryService.java:230) to throw an error (on undeploy) and try to undeploy an application that caused JobOperatorService to be created.
    • ---
    • ---

      Sometimes my wildfly could not shutdown, but there where no exceptions in the logs or anywhere. So after some debugging I found out what failed and got my issue resolved, but the issue for me, from the wildfly side, is that the exception was not logged anywhere and just forgotten.

      So the stack that was not logged was:

       

      java.lang.IllegalStateException: WFLYBATCH000004: The service JobOperatorService has been stopped and cannot execute operations.
          at org.wildfly.extension.batch.jberet@34.0.1.Final//org.wildfly.extension.batch.jberet.job.repository.JobRepositoryService.getAndCheckDelegate(JobRepositoryService.java:230)
          at org.wildfly.extension.batch.jberet@34.0.1.Final//org.wildfly.extension.batch.jberet.job.repository.JobRepositoryService.getJobNames(JobRepositoryService.java:84)
          at org.wildfly.extension.batch.jberet@34.0.1.Final//org.wildfly.extension.batch.jberet.job.repository.InMemoryJobRepositoryService.getJobNames(InMemoryJobRepositoryService.java:23)
          at org.wildfly.extension.batch.jberet@34.0.1.Final//org.wildfly.extension.batch.jberet.deployment.JobOperatorService$BatchJobServerActivity.stopRunningJobs(JobOperatorService.java:469)
          at org.wildfly.extension.batch.jberet@34.0.1.Final//org.wildfly.extension.batch.jberet.deployment.JobOperatorService.lambda$stop$1(JobOperatorService.java:131)
          at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
          at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
          at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
          at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
          at java.base/java.lang.Thread.run(Thread.java:840)
          at org.jboss.threads@2.4.0.Final//org.jboss.threads.JBossThread.run(JBossThread.java:513) 

      My suggestion would be, that maybe the ExecutorService used should log down if a job gets an exception. In my case, because I got the exception, the "context.complete();" was not called, so the server could not shut down, as service was still running on it's opinion and there was nothing in the logs to find out that JobOperatorService had failed to shutdown.

       

              rh-ee-ibourdak Ilias Bourdakos
              mysticel Andres Luuk (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated: