Alan Conway wrote:
I believe C++ is encoding UUIDs correctly as 16 byte values.
I've got a fix so that the python client will as well. There are a
couple of test failures when switching over to use session_open which I
will look into then check in.
As soon as python encoding is fixed we can do a real interop test. Does
Java depend on this incorrect encoding? If so it also needs to be fixed
before C++ can switch to the preview XML.
Couple of issues on java-c++ interop:
The java method types are now based on one octet each for method and
class id, though they still seem to be encoded & decoded as 32 bits
combined.
I changed the c++ to use a single byte each. This did require me to
alter the method indexes on message.empty and message.offset and the
class index on the cluster class as the original values were too large.
(I assume we will have a wholesale reallocation of ids now we have moved
to the smaller id sizes as the ids are used rather unsparingly!)
After altering the java client to encode/decode the methods encoded type
field as a short) it could correctly read in the connection.start frame
and send out a connection.start-ok.
The broker never manages to read this however. I'm still investigating
the cause, but it looks like the frame doesn't contain a value for the
response (not even an empty long string) or else is encoding field
tables and long strings with just a 16 bit size (values for both being
empty). There also doesn't appear to be an end-of-frame marker(?).
I could be wrong on all counts and will pursue this a bit further.
Consider this an invitation to share any insights you have though!
