Allow clean full restart of WorkflowRuntime
## 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
0 条评论