ClassCastException for AVRO generated sources when running in dev mode #18776
Comments
|
@michalszynkiewicz @ozangunalp @cescoffier could one of you investigate this one? There's a good chance we might need Stuart here but let's at least investigate a bit what's going on and if it's still an issue with current main. |
|
I can reproduce this with the current main on Java 11. |
|
I'm a bit surprised the SSE endpoint stays alive (and stuck) on reload... |
|
I see the SSE endpoint, after restart, still uses the old classloader. I think that's the issue. I will try to dig into it a bit further. |
|
I see this behavior (keeping the old/pre-reload classloaders on SSE endpoints if the call is in progress when the app is reloaded) also without kafka. I don't know enough about the server part of RestEasy Reactive to fix it quickly, I think. |
|
A workaround could be to turn off the hot reload using instrumentation. But during the hot reload, it should cut the SSE connection. It's up to the client side to reconnect. |
|
I think it is off by default, and when I activate it using |
Yes, that's what we do with gRPC streams. @geoand @FroMage @stuartwdouglas can one of you give some pointers on implementing this or take a look at it himself? |
|
Pointers for which part exactly? |
|
good question :D It seems we miss closing an SSE connection on the app reload. |
|
That's one for @FroMage |
|
So we have to keep track of all the open connections when in DEV mode? This sort of thing doesn't appear to be limited to SSE though: it can happen with any REST call that is streaming. What is the producer of the SSE feed? Is it Reactive Messaging? Shouldn't it be responsible for cutting the emission? Or is it the case that it can keep the @michalszynkiewicz can you point me to where you keep track of gRPC streams in DEV mode for that, please? |
|
In gRPC the calls that are made with our stubs (we don't close streams for grpc-java stubs yet) are handled thorugh https://github.com/quarkusio/quarkus/blob/master/extensions/grpc/stubs/src/main/java/io/quarkus/grpc/runtime/ServerCalls.java Then, on restart, This logic is invoked from a |
This will prevent old persistent connections hanging onto the old shutdown application. Fixes quarkusio#18776
This will prevent old persistent connections hanging onto the old shutdown application. Fixes quarkusio#18776
This will prevent old persistent connections hanging onto the old shutdown application. Fixes quarkusio#18776
|
The linked PR should fix both issues |
This will prevent old persistent connections hanging onto the old shutdown application. Fixes quarkusio#18776
This will prevent old persistent connections hanging onto the old shutdown application. Fixes quarkusio#18776 (cherry picked from commit 8394756)
Fixes quarkusio#18776 (cherry picked from commit e5ac1e2)
Describe the bug
I am trying out Quarkus and following the guide Quarkus - Using Apache Kafka with Schema Registry and Avro .
When the application is first started in dev mode everything works as expected. The created Movie resources are sent to Kafka and consequently available via the consumer. However, when a change is made and the livereload kicks in, the class are no longer available in the QuarkusClassLoader and the following stack trace is observed:
Observing the issue when runnning from the command line with
mvn quarkus:devas well as running from IntelliJ 2021.1.3.Expected behavior
AVRO generated classes are available after livereload.
Actual behavior
Not sure, but my initial thoughts are that AVRO generated classes are no longer available on the classpath due to ClassLoader switching?
How to Reproduce?
Reproduce:
curl -N http://localhost:8080/consumed-moviesOutput of
uname -aorverDarwin Macbook 20.5.0 Darwin Kernel Version 20.5.0: Sat May 8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
Output of
java -versionTried Java 11, 15 and 16
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Additional information
No response
The text was updated successfully, but these errors were encountered: