Allow clean full restart of WorkflowRuntime
- Lingua principale
- Java
- Stelle
- 300
- Fork
- 230
- Merge medio
- 5g 1h
- PR unite (30g)
- 5
Descrizione
## Describe the proposal
When using quarkus (with quarkus-dapr), quarkus devmode does a (somewhat) full application restart when the code of the application has changed.
The way this is implemented there currently implemented causes problems, since the WorkflowRuntime instance is not correctly recycled, so we have stray instances of CDI beans still connected to a non-stopped WorkflowRuntime. While I was trying to fix this, I ran into two problems, somewhat related to #1727 and #1631.
1) When calling [WorkflowRuntime.close()](https://github.com/dapr/java-sdk/blob/master/sdk-workflows/src/main/java/io/dapr/workflows/runtime/WorkflowRuntime.java#L70), dapr-java blocks, since it seems that the order of the shutdown is wrong (even after applying #1727).
Currently `this.closeSideCarChannel();` is called before `this.worker.close();` which blocks until the close timeout hits. When i reverse the order this problem goes away. I don't know if that would break other stuff, but locally this seems to work fine
2) [WorkflowRuntimeBuilder](https://github.com/dapr/java-sdk/blob/master/sdk-workflows/src/main/java/io/dapr/workflows/runtime/WorkflowRuntimeBuilder.java) doesn't allow a full rebuild of the `WorkflowRuntime`. So when using the builder to create a new `WorkflowRuntime`, the channel it tries to use doesn't actually work at all (at least i could not make it work, it's probably some deep connection to how the quarkus restart works). If i reset `WorkflowRuntimeBuilder.instance` before calling `build()` again, everything works as expected.
I guess the easiest way to fix this would be to allow resetting the WorkflowRuntimeBuilder.instance from the outside? I
Guida per i contributori
Apri la guida per i contributori
Direzione di ricerca
Inizia da sdk-workflows/src/main/java/io/dapr/workflows/runtime/WorkflowRuntime.java, in particolare close(), e da WorkflowRuntimeBuilder.java, concentrandoti sull’ordine di arresto e sull’istanza statica durante una ricostruzione. Riproduci lo scenario di riavvio di Quarkus devmode, quindi verifica che la chiusura non si blocchi e che un WorkflowRuntime appena creato disponga di un canale funzionante.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- java
- Ambito
- backend
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Tranquilla
- Chiarezza
- Abbastanza chiara
- Idoneità per principianti
- 48/100