Quarkus: remote:dev plugin not working

Created on 27 Jul 2020  路  6Comments  路  Source: quarkusio/quarkus

Describe the bug
While trying to use the remote:dev plugin for development in a container I faced a NullPointerException in the remote application after trying to connect with remote:dev.

First I start an image that starts my application in dev mode quarkus:dev. After it is up and running I try to connect using the specified properties in the documentation:

./mvnw compile quarkus:remote-dev -Dquarkus.live-reload.url=http://localhost:8080 -Dquarkus.live-reload.password=123

Expected behavior
Connect successfully to the container in development mode.

Actual behavior

Remote application exception:

2020-07-26 20:07:00,124 ERROR [io.qua.ver.htt.run.dev.RemoteSyncHandler] (vert.x-eventloop-thread-6) Connect failed: java.lang.NullPointerException at io.quarkus.deployment.dev.IsolatedRemoteDevModeMain.createHashes(IsolatedRemoteDevModeMain.java:298) at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.syncState(RuntimeUpdatesProcessor.java:204) at io.quarkus.vertx.http.runtime.devmode.RemoteSyncHandler$6.handle(RemoteSyncHandler.java:182) at io.quarkus.vertx.http.runtime.devmode.RemoteSyncHandler$6.handle(RemoteSyncHandler.java:168) at io.vertx.core.http.HttpServerRequest.lambda$bodyHandler$0(HttpServerRequest.java:216) at io.vertx.core.http.impl.HttpServerRequestImpl.onEnd(HttpServerRequestImpl.java:521) at io.vertx.core.http.impl.HttpServerRequestImpl.lambda$pendingQueue$1(HttpServerRequestImpl.java:115) at io.vertx.core.streams.impl.InboundBuffer.handleEvent(InboundBuffer.java:237) at io.vertx.core.streams.impl.InboundBuffer.drain(InboundBuffer.java:224) at io.vertx.core.streams.impl.InboundBuffer.lambda$fetch$0(InboundBuffer.java:277) at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366) at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:834)

Client exception:
2020-07-27 11:48:11,261 ERROR [io.qua.ver.htt.dep.dev.HttpRemoteDevClient] (Remote dev client thread) Remote dev request failed: java.io.IOException: Server did not start a remote dev session at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient.doConnect(HttpRemoteDevClient.java:65) at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient.access$200(HttpRemoteDevClient.java:27) at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient$Session.run(HttpRemoteDevClient.java:163) at java.base/java.lang.Thread.run(Thread.java:834)

To Reproduce
Steps to reproduce the behavior:

  1. Clone this sample application.
  2. Follow the README.md instructions.
  3. Look at the container logs.

Environment:

  • Output of uname -a or ver: Darwin JDantas-Mac-01.local 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64
  • Output of java -version: java version "11.0.7" 2020-04-14 LTS
    Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
    Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)
  • Quarkus version or git rev: 1.6.1-Final
  • Build tool (ie. output of mvnw --version or gradlew --version): Maven 3.6.3_1

Additional context
I'm still a beginner in the codebase. Looking at the source code of IsolatedRemoteDevModeMain class looks like some kind of race condition since the _appRoot_ is null when it calls _setupRuntimeCompilation_ and is only set later after get the _generateApplication_ result object.

            augmentAction = new AugmentActionImpl(curatedApplication);
            **runtimeUpdatesProcessor = setupRuntimeCompilation(context, appRoot);**

            if (runtimeUpdatesProcessor != null) {
                runtimeUpdatesProcessor.checkForFileChange();
                runtimeUpdatesProcessor.checkForChangedClasses();
            }

            JarResult result = generateApplication();
            if (result != null) {
                **appRoot = result.getPath().getParent();
                currentHashes = createHashes(appRoot);**
            }
kinbug

All 6 comments

@stuartwdouglas is this maybe fixed by https://github.com/quarkusio/quarkus/pull/10977?

Forgot to mention that I also tested with the master build. This can be reproduced in the branch https://github.com/joao-dantas/remot-dev-test/tree/use-quarkus-master.

Adding this to the list of issues I track for 1.7.0.

I can take a look at this tomorrow if Stuart hasn't fixed it by then :)

Please let me know if I can be of any help

The this is combing the old approach with the new approach, which is why it is failing.

You don't run mvn quarkus:dev on the remote side, you run a 'mutable-jar' application with 'QUARKUS_LAUNCH_DEVMODE'

Was this page helpful?
0 / 5 - 0 ratings