Zeebe does not execute Spring worker

I’m using camunda spring-boot-starter-camunda dependency version 8.5.0. Parallelly, I am running camunda platform with the same version 8.5.0.

When I declare service tasks and corresponding workers, I do not see that Zeebe passed job to my workers. I am using Camunda self managed.

Yes, everything is configured correctly because I can see processes are deployed from my spring boot application when I run it. Can someone tell me do I need some additional configuration to make this work? I can see token in Operate, but it just “sticks” to the service task and doesn’t get executed at all.

This is example of my worker, where, of course I have service task with the same job type value:

@Component
@Slf4j
@SuppressWarnings(“unused”)
public class DeliverPreliminaryDecisionWorker {

@JobWorker(type = “deliver-preliminary-decision”)
public void deliverPreliminaryDecision() {
log.info(“Delivering preliminary decision…”);
}
}

Hi @stefan-mne.

Actually Zeebe is not pushing the job to the job worker, but the worker is polling for jobs and should then execute jobs it’s configured for.
Still if all is configured correctly the job worker should automatically poll for jobs with the topic/type “deliver-preliminary-decision”.
I think there should be some log message on startup telling you about the registration of the worker:
“Configuring {} Zeebe worker(s) of bean ‘{}’: {}”
Can you check whether you see a log message like that on startup.

Yes, you are correct. I get that log, of course. Yet, I do not get job passed to my worker. Here’s log example I get at startup:

INFO 10112 --- [ main] i.c.z.s.c.jobhandling.JobWorkerManager : . Starting Zeebe worker: ZeebeWorkerValue{type='deliver-preliminary-decision', name='deliverPreliminaryDecisionWorker#deliverPreliminaryDecision', timeout=PT-0.001S, maxJobsActive=-1, requestTimeout=PT-1S, pollInterval=PT-0.001S, autoComplete=true, fetchVariables=[], enabled=true, methodInfo=io.camunda.zeebe.spring.client.bean.MethodInfo@32def41f, tenantIds=[], forceFetchAllVariables=false, streamEnabled=true, streamTimeout=PT-0.001S}

Could you also post a sample BPMN that you would expect this worker to collect tasks from?

Of course, in fact it’s nothing special. Here’s the file.
DummyProcess.bpmn (3.7 KB)

It’s just missing customerApplication (.form file), which has dummy input and that’s it. After I complete it with Tasklist, token “gets stuck” at this service task.

And you see no log, that indicates that your worker is executing somehow? And also there are no error messages in the log?
It seems a little bit strange, if as you say the connection is correctly configured and working for deployments.

My team just found the error. It needed these dependencies to work.

        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-stub</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-core</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-api</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-netty</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-util</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-protobuf</artifactId>
            <version>${grpc.version}</version>
        </dependency>

Hope this might help someone. Our grpc verion is set to 1.65.0. Also, we are using spring-boot-starter-camunda with version 8.5.7. Only this works with current camunda platform.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.