simple-monitor having fatal gRPC error when starting up

Camunda 8 Topics Discussion & Questions
1

I’m trying to run the simple-monitor 2.4.1 via intelliJ locally, and following the instruction from the GitHub page, having a zeebe broker up and running in the docker, which is built by the docker-compose yml provided in the simple-monitor repository.

When I launch the app from the docker environment everything’s okay but I can’t modify any of the code, but when I do launch the app locally (without any code adjustment yet) I have an unhealthy cluster and this error message. Here’s the stack trace:

Exception in thread "grpc-default-executor-1" Exception in thread "grpc-default-executor-0" io.grpc.StatusRuntimeException: INTERNAL: Failed to frame message
	at io.grpc.Status.asRuntimeException(Status.java:530)
	at io.grpc.internal.MessageFramer.writePayload(MessageFramer.java:154)
	at io.grpc.internal.AbstractStream.writeMessage(AbstractStream.java:65)
	at io.grpc.internal.ForwardingClientStream.writeMessage(ForwardingClientStream.java:37)
	at io.grpc.internal.DelayedStream$6.run(DelayedStream.java:283)
	at io.grpc.internal.DelayedStream.drainPendingCalls(DelayedStream.java:182)
	at io.grpc.internal.DelayedStream.access$100(DelayedStream.java:44)
	at io.grpc.internal.DelayedStream$4.run(DelayedStream.java:148)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.UnsupportedOperationException: This is supposed to be overridden by subclasses.
	at com.google.protobuf.GeneratedMessageV3.getUnknownFields(GeneratedMessageV3.java:302)
	at io.camunda.zeebe.gateway.protocol.GatewayOuterClass$TopologyRequest.getSerializedSize(GatewayOuterClass.java:34489)
	at io.grpc.protobuf.lite.ProtoInputStream.available(ProtoInputStream.java:108)
	at io.grpc.internal.MessageFramer.getKnownLength(MessageFramer.java:208)
	at io.grpc.internal.MessageFramer.writePayload(MessageFramer.java:138)
	... 9 more
io.grpc.StatusRuntimeException: INTERNAL: Failed to frame message
	at io.grpc.Status.asRuntimeException(Status.java:530)
	at io.grpc.internal.MessageFramer.writePayload(MessageFramer.java:154)
	at io.grpc.internal.AbstractStream.writeMessage(AbstractStream.java:65)
	at io.grpc.internal.ForwardingClientStream.writeMessage(ForwardingClientStream.java:37)
	at io.grpc.internal.DelayedStream$6.run(DelayedStream.java:283)
	at io.grpc.internal.DelayedStream.drainPendingCalls(DelayedStream.java:182)
	at io.grpc.internal.DelayedStream.access$100(DelayedStream.java:44)
	at io.grpc.internal.DelayedStream$4.run(DelayedStream.java:148)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: java.lang.UnsupportedOperationException: This is supposed to be overridden by subclasses.
	at com.google.protobuf.GeneratedMessageV3.getUnknownFields(GeneratedMessageV3.java:302)
	at io.camunda.zeebe.gateway.protocol.GatewayOuterClass$TopologyRequest.getSerializedSize(GatewayOuterClass.java:34489)
	at io.grpc.protobuf.lite.ProtoInputStream.available(ProtoInputStream.java:108)
	at io.grpc.internal.MessageFramer.getKnownLength(MessageFramer.java:208)
	at io.grpc.internal.MessageFramer.writePayload(MessageFramer.java:138)
	... 9 more
2

I have located the actual problem being this line, and the pom.xml that comes with the simple-monitor app actually uses protobuf 2.4.1, for anyone running into the same problem, simply add

<!-- https://mvnrepository.com/artifact/com.google.protobuf/protobuf-java -->
        <dependency>
            <groupId>com.google.protobuf</groupId>
            <artifactId>protobuf-java</artifactId>
            <version>3.23.2</version>
        </dependency>

to your pom.xml or any other version that you prefer (I believe even protobuf 2.5 works)
I don’t have any clue why specifically 2.4.1 was chosen but this problem isn’t very searchable on the internet for some reason.

1 Like