Is your feature request related to a problem? Please describe.
The current implementation of job workers in the Connectors runtime blocks the zeebe client thread. This can lead to a scenario where we dont work on new jobs despite having resources available as the handler thread is waiting for a Connector result (and the following zeebe command)
Describe the solution you'd like
We should have a solution based on a single thread pool that is responsible for processing all outbound connector jobs that aligns with the maximum number of active jobs but should allow the zeebe client to activate new jobs if resources are available.
We dont need to implement support for non-blocking result type (like Reactors Mono) as part of this. Every Connector can still block but the overall handling of processing the result and handing it back to the zeebe client should be non-blocking.
Is your feature request related to a problem? Please describe.
The current implementation of job workers in the Connectors runtime blocks the zeebe client thread. This can lead to a scenario where we dont work on new jobs despite having resources available as the handler thread is waiting for a Connector result (and the following zeebe command)
Describe the solution you'd like
We should have a solution based on a single thread pool that is responsible for processing all outbound connector jobs that aligns with the maximum number of active jobs but should allow the zeebe client to activate new jobs if resources are available.
We dont need to implement support for non-blocking result type (like Reactors
Mono
) as part of this. Every Connector can still block but the overall handling of processing the result and handing it back to the zeebe client should be non-blocking.Additional context
https://forum.camunda.io/t/parallel-execution-of-camunda-8-outbound-connector-jobs/48741/