Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid blocking in job handlers #3498

Open
sbuettner opened this issue Oct 16, 2024 · 1 comment
Open

Avoid blocking in job handlers #3498

sbuettner opened this issue Oct 16, 2024 · 1 comment
Assignees
Labels
kind:enhancement New feature or request

Comments

@sbuettner
Copy link
Contributor

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/

@sbuettner sbuettner added the kind:enhancement New feature or request label Oct 16, 2024
@sbuettner
Copy link
Contributor Author

Things to consider: Use virtual threads for the blocking parts & adhere job limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants