On 06/10/2015 04:01 PM, aconway wrote:
On Tue, 2015-06-09 at 19:54 +0100, Gordon Sim wrote:
On 06/09/2015 06:40 PM, logty wrote:
When I run the client I get:
[0x5351db0]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery
-tag=b"",
message-format=0, settled=true, more=true] (16363)
"\x00Sp\xc0\x07\x05B..."
My guess would be that it is the delivery tag being null (or empty,
can't tell which) that is the problem. From the spec:
"This field MUST be specified for the first transfer of
a multi-transfer message and can only be omitted for
continuation transfers." [section 2.7.5]
So I think that whatever is sending that frame has a bug. Proton-c
has a
bug too of course, since it shouldn't segfault but should close the
connection with a framing-error or similar.
It says the field must be specified, it does not say it must not be an
empty binary value. Is the field really missing or is proton choking on
a 0-length delivery tag?
I'm not sure the distinction between null and an empty value is very
useful here. The intent is that the delivery is clearly identified. I
would argue that a 'zero byte identifier' doesn't meet the spirit of the
law there.
It shouldn't, which might explain why rabbit is OK with
it.
I don't think RabbitMQ is ever seeing that frame. I believe that frame
is emitted by ApolloMQ to the receiving client.
I agree that proton should not choke on a zero byte delivery tag (or
indeed on a non-existent delivery tag). But I do think it's a bug to
send such a frame.
(I should say of course that this is all still somewhat speculative,
based only on a snippet of protocol trace and this thread. I haven't
actually reproduced myself to verify the bad behavior in ApolloMQ or
that the crash in proton is caused by the delivery tag value).
