Uploaded image for project: 'Red Hat Process Automation Manager'
  1. Red Hat Process Automation Manager
  2. RHPAM-3635

Business Central browser keeps polling after server is stopped

    XMLWordPrintable

Details

    • Bug
    • Status: New (View Workflow)
    • Major
    • Resolution: Unresolved
    • 7.11.0.GA
    • None
    • Business Central
    • None
    • Business Central deployed on EAP.

      Browser window with Business Central opened.

      EAP server stopped.

      Kogito service running in dev mode.

    • Release Notes

    Description

      Business Central web application, once kept open in browser window after server is stopped, it seems it keeps polling the endpoint of previously running server. (Possibly waiting for it to come back up.)

      This might lead to unexpected collisions in environment -  like in case of Kogito Decision Management service running in Dev Mode.

      In that case the symptom was observable upon changing resource within Kogito app. (When in dev mode a reload should happen upon next endpoint invocation, not immediately).

      The Kogito app reloaded seemingly on its own and presented following error. It is coming from Kogito context, but it's due to the polling by BC. Seems like this happens just in the initial phase of Kogito app load when things are not yet initialized, that's why Dev Mode gives a better chance for the symptoms to appear.

      2021-04-29 15:01:27,047 ERROR [io.und.request] (executor-thread-198) UT005071: Undertow request failed HttpServerExchange{ POST /business-central/out.79796-3716.erraiBus delegate io.undertow.vertx.VertxHttpExchange@27bbc722}: java.lang.IllegalStateException: Container not running: ArcContainerImpl [id=3, running=false, beans=0, observers=0, scopes=[]]
      	at io.quarkus.arc.impl.ArcContainerImpl.requireRunning(ArcContainerImpl.java:789)
      	at io.quarkus.arc.impl.ArcContainerImpl.requestContext(ArcContainerImpl.java:319)
      	at io.quarkus.arc.runtime.BeanContainerImpl.requestContext(BeanContainerImpl.java:53)
      	at io.quarkus.undertow.runtime.UndertowDeploymentRecorder$9$1.call(UndertowDeploymentRecorder.java:544)
      	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
      	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:152)
      	at io.quarkus.undertow.runtime.UndertowDeploymentRecorder$1.handleRequest(UndertowDeploymentRecorder.java:117)
      	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:290)
      	at io.undertow.server.DefaultExchangeHandler.handle(DefaultExchangeHandler.java:18)
      	at io.quarkus.undertow.runtime.UndertowDeploymentRecorder$5$1.run(UndertowDeploymentRecorder.java:400)
      	at io.quarkus.runtime.CleanableExecutor$CleaningRunnable.run(CleanableExecutor.java:231)
      	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
      	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2415)
      	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1452)
      	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
      	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
      	at java.base/java.lang.Thread.run(Thread.java:834)
      	at org.jboss.threads.JBossThread.run(JBossThread.java:501)
      

      Attachments

        Activity

          People

            r_anand Rishiraj Anand
            jstastny@redhat.com Jan Stastny
            Jan Stastny Jan Stastny
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: