Open amarzavery opened 5 years ago
Javscript only uses 53 bits for numbers which limits the range of longs that can be accurately represented. In decoding, rhea will only decode the long to a number if it is non-lossy to do so, otherwise it will return a buffer.
[0,137,0,0,0,0,0,9] is outside the range that can be expressed with 53 bytes so it is returned as a buffer.
If you pass the buffer to int64-buffer's Int64BE that should work, e.g.:
var value = require('int64-buffer').Int64BE(Buffer.from([0,137,0,0,0,0,0,9]));
console.log('value is %s', value);
I have a management operation in ServiceBus where the user can schedule a message to be active on the Queue at a later time. ServiceBus returns the sequenceNumber (of AMQP LONG type) of the message in response. If the user wishes to cancel the scheduled message, the sequenceNumber needs to be provided to ServiceBus for it to determine the right message to be cancelled.
Thus I need to be able to round trip the sequence number correctly. Problem with int64-buffer library is that the round trip cannot happen successfully as can be seen in this issue. Some bytes are lost in the transformation. When I specify the sequence number to ServiceBus, it returns an error stating that the sequenceNumber is not correct.
In decoding, rhea will only decode the long to a number if it is non-lossy to do so, otherwise it will return a buffer.
Is it possible to tell rhea to always send a buffer and let the customer handle the conversion?
In the issue filed in int64-buffer, you can see the Int64LE round trip number <---> buffer representation works fine. Once I saw it converting to a negative number, hence was thinking to use UInt64LE over Int64BE. Do you think that should be fine? Is there a reason to use the BE flavor over LE flavor?
The precision is lost because you are converting to a javascript number which does not have sufficient precision. You need to use a different javascript type if externalizing the value. An AMQP long is a signed value (a ulong would be unsigned) and you want the bigendian version.
Have decided to take a dependency on long.js. It provides a nice Long
type with methods for addition/substraction, etc. Commenting here so other folks can benefit from this.
At times, rhea correctly gives me the sequenceNumber of the message which happens to be an AMQP Long type. At times it gives me a Buffer. Not sure, why it cannot be consistent.
sequence-numbers is an array of number
Sequence-numbers is an array of buffer
I tried using the int64-buffer library to convert the buffer
[0,137,0,0,0,0,0,9]
into a number (long). However, it has other issues where it is not able to convert the number into the same buffer accurately.Is it possible for rhea to always convert the long type into a buffer or into a number consistently?