On 6/16/20 5:14 PM, Gordon Sim wrote:
> On 16/06/2020 8:46 am, Ivo Wever wrote:
>> Hi,
>>
>> I'm trying to interact with an AMQP endpoint using the Ruby
>> implementation. The endpoint is very specific in requiring a ulong
>> message id, even though the message id they want is 1 [1]. However
>> if I set it to 1 using Ruby, it is sent as a smallint (verified
>> using wireshark), which they reject.
>
> That sounds like a bug in the ruby wrapper code. I assume this is
> for the proton API?
>
> The python equivalent has an explicit test for a numeric value which
> it then ensures is a ulong. I don't see anything equivalent in the
> ruby (but I'm not that familiar with that binding).
>
> Arguably the c library should not emit invalid AMQP but I don't
> think there is any check at present.
Well, not so much a bug as a missing feature :).
I've now wrapped my head around things a bit: I figured out the SWIG
bindings automatically convert a Ruby '1' into a C int (data.u.as_int),
which makes sense [1], but is not sufficient for my needs, as I need to
somehow explicitly tell it to treat it as a ulong, as the receiver
checks the type and just rejects it if the type is wrong, even if they
could work with the value just fine :(.
My current workaround is setting
data = QP::Codec::Data.new(Cproton.pn_message_id(message.impl))
data.clear
data.ulong = value
explicitly, instead of using the message.id setter. This works, although
I think that's because I also fixed bug [1] locally, so the value is
autoconverted into a long and passing that as the uint64_t required
for the ulong value works.
The next quest is to get it to treat the body as binary... :)
[1] There is a bug there though: there's an incompatibility between the
SWIG bindings and Ruby versions above 2.4. The SWIG bindings assume
a distinction between 'Fixnum' and 'Bignum' types that no longer
exists at the Ruby type level for those versions. If you try to set
a number larger than 2**31-1, it will wrap around. If you try to set
a number larger than 2**32-1, you get 0, always.
This is because the bindings uses a macro from the Ruby C bindings,
FIX2LONG, which should be NUM2LONG for these versions. The FIX2LONG
doesn't take the unification of 'Fixnum' and 'Bignum' into account
and converts anything it can't handle into 0.
(For Ruby versions above 2.4 the T_BIGNUM case in the SWIG bindings
is simply never matched, as the T_FIXNUM case is matched by any
integer)
best regards,
--
Ivo Wever
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
