-
Bug
-
Resolution: Done
-
Major
-
1.14.0.Final
-
None
-
None
-
False
-
False
-
-
2021 Week 46-48 (from Nov 15)
Running kogito-apps/dmn-tracing-quarkus highlights this issue.
Running it from main with mvn clean compile quarkus:dev shows Kafka starts successfully however attempts to POST a decision request, as detailed in the README, fails. Furthermore typing q in the Quarkus Dev Console is unresponsive and the Quarkus Dev Console process needs killing.
__ ____ __ _____ ___ __ ____ ______ --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \ --\___\_\____/_/ |_/_/|_/_/|_|\____/___/ 2021-11-15 11:41:36,247 INFO [io.sma.rea.mes.kafka] (Quarkus Main Thread) SRMSG18258: Kafka producer kafka-producer-kogito-tracing-model, connected to Kafka brokers 'PLAINTEXT://localhost:49164', is configured to write records to 'kogito-tracing-model' 2021-11-15 11:41:36,272 INFO [io.sma.rea.mes.kafka] (Quarkus Main Thread) SRMSG18258: Kafka producer kafka-producer-kogito-tracing-decision, connected to Kafka brokers 'PLAINTEXT://localhost:49164', is configured to write records to 'kogito-tracing-decision'
Increasing the log level shows Quarkus attempts a reload following creation of HotReloadSupportClass but there are no subsequent log entries.
2021-11-12 14:47:54,669 DEBUG [io.sma.rea.mes.kafka] (Quarkus Main Thread) SRMSG18209: Sending message org.eclipse.microprofile.reactive.messaging.Message$$Lambda$2092/0x00000008018d1840@616039ec to Kafka topic 'kogito-tracing-model' 2021-11-12 14:47:54,686 INFO [io.qua.dep.dev.RuntimeUpdatesProcessor] (pool-1-thread-1) Restarting quarkus due to changes in HotReloadSupportClass.class. 2021-11-12 14:47:54,773 DEBUG [com.git.doc.zer.sha.org.apa.hc.cli.htt.wire] (docker-java-stream-980055441) http-outgoing-2 << "80[\r][\n]" java.lang.InterruptedException at java.base/java.util.concurrent.locks.ReentrantLock$Sync.lockInterruptibly(ReentrantLock.java:159) at java.base/java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:372) at java.base/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:432) at io.quarkus.vertx.http.runtime.logstream.WebSocketLogHandler.recordHistory(WebSocketLogHandler.java:66) at io.quarkus.vertx.http.runtime.logstream.WebSocketLogHandler.doPublish(WebSocketLogHandler.java:39) at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:66) at org.jboss.logmanager.ExtHandler.publishToNestedHandlers(ExtHandler.java:97) at io.quarkus.bootstrap.logging.QuarkusDelayedHandler.doPublish(QuarkusDelayedHandler.java:73) ...
Pressing <ctrl>+ in the Quarkus Dev Console shows a thread dump that points at a dead-lock.
"pool-1-thread-1" #128 prio=5 os_prio=0 cpu=4.09ms elapsed=3.24s tid=0x00007f90d4585800 nid=0x1f063 waiting for monitor entry [0x00007f91192cd000] java.lang.Thread.State: BLOCKED (on object monitor) at io.quarkus.deployment.dev.IsolatedDevModeMain.restartApp(IsolatedDevModeMain.java:213) - waiting to lock <0x0000000615ec3020> (a io.quarkus.deployment.dev.IsolatedDevModeMain) at io.quarkus.deployment.dev.IsolatedDevModeMain.restartCallback(IsolatedDevModeMain.java:208) at io.quarkus.deployment.dev.IsolatedDevModeMain$$Lambda$62/0x0000000800baa840.accept(Unknown Source) at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.doScan(RuntimeUpdatesProcessor.java:497) at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.doScan(RuntimeUpdatesProcessor.java:401) at io.quarkus.smallrye.reactivemessaging.runtime.devmode.ReactiveMessagingHotReplacementSetup$OnMessage$1.run(ReactiveMessagingHotReplacementSetup.java:39) at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@14/ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@14/ThreadPoolExecutor.java:630) at java.lang.Thread.run(java.base@14/Thread.java:832)
Removing the code in org.kie.kogito.quarkus.common.deployment.KogitoQuarkusResourceUtils that writes HotReloadSupportClass after a model has been deployed fixes the issue completely. The example runs successfully and Quarkus Dev Console is responsive to pressing q to exit.