Missing Features Migrating from Camunda 7

Camunda 8 Topics Discussion & Questions
1

We have a couple hundred external tasks that interact with Camunda 7 using the REST API. We’re attempting to migrate them to Zeebe, but there seems to be a few features that exist in Camunda 7 that don’t have any functional alternative in Camunda 8.

First, the /external-task/fetchAndLock method accepts a list of topics, which is very convenient, and I might argue even necessary, since we can chunk the requests for, say, 50 of them together and cut down on the number of concurrent HTTP requests. However, the Zeebe method ActivateJobs takes a single ActivateJobsRequest, which itself only accepts a string of worker types. Are there any plans to allow the ActivateJobs method to accept a list of ActivateJobsRequest instead of only one? As it stands now, we’d have 200+ HTTP requests open concurrently with Zeebe as opposed to 15 or so with Camunda 7, which does not seem sustainable.

Secondly, we typically try to use short locks and extend them using monitor threads, as necessary. Zeebe does not seem to offer any functionality equivalent to Camunda 7’s /external-task/{id}/extendLock method, which means we’ll have to lock jobs with an excessively-large interval, which can cause user complaints when jobs are not processed in a timeframe they expect, in the event of a worker thread failure. Are there plans for replacing this missing functionality?

2

Hello @jsb ,

Zeebe does not use http/1.1, but GRPC which is based on http/2. A very nice feature of http/2 is that a connection can be used constantly (almost like websocket). If you track the connections opened by a client you will see that it only connects once and keeps the connection open while sending all activateJobs requests through the same connection. So, there is no additional overhead.

Currently, there is no feature that would extend the lock of a task being worked on. This feature is in the pipeline and will probably come up with a future release. A workaround would be to track job progress in a central datasource for all workers (redis for example) to prevent double-execution of jobs. I know this will mean additional implementation overhead, however this would just be an intermediate solution until Zeebe has the similar endpoint available.

I understand that this will probably block you from migrating now, so I would encourage you to keep track of new features using github or our blog and prepare migration while still running on Camunda 7.

Jonathan

3