Hi,
I am working with c8run to check for our migration from Camunda7 to Camunda8. When running some of our BPMNs I receive a timeout.
"Expected to handle REST API request, but request timed out between gateway and broker"
I have tried several things to increase this timeout
setting the environment variable ZEEBE_GATEWAY_CLUSTER_REQUESTTIMEOUT
defining the timeout in the application.yaml file in
camunda8-run-8.6.9/c8run/camunda-zeebe-8.6.9/config
even after restarting c8run the timeout is still thrown after 15 seconds.
Is there another way to come around this timeout?
In Camunda7 our BPMNs are running up to 5 minutes.
Hi @Edmund - C8 is a fully asynchronous, eventually consistent architecture. Because of that, using the “start process with result” endpoint often runs into a timeout. If your process takes longer than a few moments, it may be best to try a different pattern. For instance, a task at the end of the process that sends data back to your application notifying it that the process is complete (similar to this pattern).
As for changing the settings … that’s a good question! That environment variable should have worked. Are you running this on Windows, Linux, or macOS?
Hi,
in my test environment I am running c8run on Linux.
Is the behaviour of the other types of environments different from c8run?
What is a useful development environment without kubernetes?
In our current development environments every developer has his own Camunda7 server running locally.
I will give your idea with this asynchronous task a try. Thanks. We are open for all ideas.
Hi @Edmund - I’ve shared the issue of the timeout not getting updated with the engineers and will see what they think.
C8 Run is a script that downloads the JAR files for each component and starts all of them with a list of arguments. Not every parameter can be customized with C8 Run. It works for most local development and testing needs, but isn’t intended to be a fully configurable deployment model.
If you want a local environment that you can fully control and behaves more closely to a deployed production environment, I recommend our docker-compose configuration, which should work out of the box for most users.
One common development workflow we’re seeing with C8 is every developer uses C8 Run or Docker locally, and you can complement that with a staging/test environment that mimics production for better testing and quality control. Ultimately, due to the async nature of C8, testing locally will give different timings than testing in a cloud environment, so having a cloud environment with similar resources to the production cluster will be helpful.