Quarkus: Reload in quarkus:dev only after HTTP invocation?

[sdaschner]

Description
If I understand it correctly, quarkus:dev only applies the changes once the next HTTP request is being made.
Is it possible to change that behavior in the Maven plugin? This might be helpful if e.g. schedulers or processing applications are being developed.

Btw, what was the motivation for only making changes on new HTTP requests?

Implementation ideas
Have an optional Maven property, such as -DhotReload / -DinstantReload which changes this behavior.
Alternatively change the default behavior to immediately apply updates on file changes.

[gsmet]

The initial idea was to avoid reloading partial changes randomly and only reload when the user says "I'm done, let's reload it". But that's for sure this approach doesn't work very well for non-web applications.

/cc @stuartwdouglas

[stuartwdouglas]

We have an API for this, and there is Kafka streams support as well.

The issue with any other way of supporting it is that it is hard to know if you have actually got the new code or not. The java file watcher API on most platforms is actually just a poll with a relatively long poll interval, so if you finish coding and send a request it is quite possible you can still get a response from the old code.

It's pretty simple to do a timing based implementation as well (I think camel has already done one), but the HTTP based one means that you always get the most recent code, you don't have to sit there refreshing wondering if the changes have been picked up yet or your have just made a mistake.

[sdaschner]

Makes sense I think, but we can add some more ways to trigger a reload in the Maven phase, and (as a side note) also test execution, see my comment here. E. g. how about triggering a reload once the user presses <Enter> in the Maven execution?

I'd totally prefer an active approach, e.g. detecting some change or having the user triggering a reload via some action, rather than a timed-based approach.

[julienrenaut]

My current workaround for this is having a "noop" web resource that I call when I want to "force" a reload.

I agree the reload should be "user triggered" otherwise it's hard to know when a reload is actually due.

Reading from System.in on the Maven execution seems like the proper match for the current request-based approach on non-web applications.

[gaetancollaud]

Instead of having a "noop" web resource you can also use the health check (if you have one). I have apps that don't have any http resource (kafka processor or just grpc clients), but they all have an health check so I use this.

http://localhost:8080/health