Program hangs when calling parseFrom for java implementation of protobuf

Question

I have a message (say its called OuterMessage)

message OuterMessage {
    optional int64 id = 1;
    optional InnerMessage inner = 2;
}

and an inner message

message InnerMessage {
    optional string type = 1;
    optioanl int64 id = 2;
}

Now when I call parseFrom on OuterMessage like OuterMessage.parseFrom(buffer) the method never returns and nor does it throw any exception. But if I do InnerMessage.parseFrom(buffer) it returns an empty InnerMessage instance.

I am serializing the message using protobuf-net. Any idea what might be causing the issue?

UPDATE: I checked the debugger console and there was following exception thrown:

Caused by: java.lang.IllegalArgumentException: Invalid embedded descriptor for "KeyValuePackageResponse.proto".
        at com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java:286)
        at com.myproj.protobuf.KeyValuePackageResponseProtocol.<clinit>(KeyValuePackageResponseProtocol.java:538)
        ... 15 more
Caused by: com.google.protobuf.Descriptors$DescriptorValidationException: KeyValuePackageResponse.proto: Dependencies passed to FileDescriptor.buildFrom() don't match those listed in the FileDescriptorProto.
        at com.google.protobuf.Descriptors$FileDescriptor.buildFrom(Descriptors.java:231)
        at com.google.protobuf.Descriptors$FileDescriptor.internalBuildGeneratedFileFrom(Descriptors.java:284)

I checked the .proto file at its the same for both java and C#. This message KeyValuePackageResponseProtocol is also used in many other messages which seems to be initialized fine. Any specific thing that I should look at to resolve this issue?

Answer 1

What is buffer? Is it a stream? a byte-array? What? The reason I ask is that protobuf does not (by default) include length headers, so it reads to the end of the stream. If the stream is left open (perhaps an open network socket) then it won't know to end and will hang (which is possibly what you are seeing). There are ways to get around this while leaving the stream open, of course.

If this isn't the issue, can you indicate (perhaps in hex) the buffer contents, and the values you are serializing? I'd like to figure out whether it is a serialization issue, or a parsing issue...