Writing protocol buffer data in C++ and reading in Java over AMQP/JMS

Question

So I'm a bit stumped on this. I've got an AMQP class implementation on the C++ side that ultimately serializes my Porotocol buffer object to a string:

qpid::messaging::message qmesg;
std::string msgstr;
ProtoMessage.SerializeToString(&msgstr);
qmesg.setContent(msgstr);

//Proceed to send the message

The message body is set to this, and the content type is binary.

On the Java side, we're reading the bytes in from a JMSBytesMessage Object, then trying to parse the data back to a protocol buffer object:

JMSBytesMessage msg; //Assume this is in the proper context
ProtoMessage.parseFrom(msg.getData().array());

I've also tried:

byte[] bytearr = new byte[]
msg.readBytes(bytearr);

Which gives the same.

When I log the byte data, I do see byte values (Using Array.ToString(byte[]), but the code above on the java side throws an InvalidProtocolBufferException:

com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an     invalid tag (zero).

I'd assume that since it's byte data, it's anonymous to the character encoding. Am I missing something obvious? Also, please refrain from alternative implementation suggestions regardless of how awkward this looks, just assume this one must be used. Any guidance would be appreciated.

Protocol Buffer byte array values (Maybe unnecessary? Why not) EDIT: Diffed byte results, interesting.

EDIT: Top decoded in Java, bottom encoded in C++:

10 0 18 0 34 0 42 0 50 0 58 0 82 0 90 0 98 0 106 0 114 0 122 0 -126 1 6 97 99 99 101 112

10 0 18 0 34 0 42 0 50 0 58 0 82 0 90 0 98 0 106 0 114 0 122 0 130 1 6 97 99 99 101 112

These are only the first few, but the pattern continues. Most of the data is the same, but some bytes are changed to signed from unsigned. I don't work in Java too much, so what's going on here?

Answer 1

This is a total guess, but perhaps only part of that byte array is the real message, and perhaps that zero is the end of it. The initial allocation was bigger than the actual message and you need to track the number of bytes written, and then only read that many on the other side.

Answer 2

I don't know how to solve the problem, and I have a similar issue. However, I can help a bit. The difference in the traces are due to interpreting the byte as signed or unsigned. The bit pattern is the same for both. 130 = 10000010 (unsigned char), and -126 = 10000010 (signed char)