DefaultMessagePropertiesConverter#toMessageProperties should handle x-delay in Short about spring-amqp HOT 4 CLOSED

The -5000 is even explained in the respective RabbitMQ docs: https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq#checking-if-a-message-was-delayed.
They also mention that this property is an integer.
Plus it is not clear how that can be a short: #2602.

We probably can go ahead and try to resolve any Number impl over there into an expected long.

What RabbitMQ broker version do you use?

from spring-amqp.

I am using 3.12.12 broker:

I understand the where -5000 is from on the queue, but it looks like when client retrieves it, it provides back a positive number, I am not sure how the spec says about this behavior.
When I trace into ContentHeaderPropertyReader#readTable, the input stream's buffer has following values:
[0, 60, 0, 0, 0, 0, 0, 0, 0, 0, 0, 15, -96, -64, 10, 116, 101, 120, 116, 47, 112, 108, 97, 105, 110, 0, 0, 0, 11, 7, 120, 45, 100, 101, 108, 97, 121, 115, 19, -120, 36, 48, 56, 54, 54, 53, 102, 52, 55, 45, 100, 100, 99, 48, 45, 52, 55, 101, 56, 45, 57, 54, 98, 56, 45, 56, 51, 56, 51, 53, 51, 100, 100, 57, 54, 49, 98, 0, 0, 0, 0, 102, 4, 104, -29]
If I print it out, I get 13, -78 after x-delay, which is 0x1388, and translate into 5000 . I am not sure why in this case in specs, but it seems like it.

`
0x0
< 0x3c
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0x0
0xf
0xa0
0xc0

0xa

t 0x74
e 0x65
x 0x78
t 0x74
/ 0x2f
p 0x70
l 0x6c
a 0x61
i 0x69
n 0x6e
0x0
0x0
0x0
� 0xb
0x7
x 0x78

• 0x2d
  d 0x64
  e 0x65
  l 0x6c
  a 0x61
  y 0x79
  s 0x73
  0x13
  0x88
  $ 0x24
  d 0x64
  7 0x37
  0 0x30
  d 0x64
  2 0x32
  b 0x62
  6 0x36
  e 0x65
• 0x2d
  9 0x39
  9 0x39
  8 0x38
  9 0x39
• 0x2d
  4 0x34
  a 0x61
  9 0x39
  9 0x39
• 0x2d
  8 0x38
  9 0x39
  f 0x66
  3 0x33
• 0x2d
  c 0x63
  e 0x65
  4 0x34
  6 0x36
  c 0x63
  d 0x64
  c 0x63
  3 0x33
  a 0x61
  9 0x39
  3 0x33
  b 0x62
  0x0
  0x0
  0x0
  0x0
  f 0x66
  0x4
  0x7f
  0xd4
  `

from spring-amqp.

Yeah... I'm not very good in parsing HEX, but if whatever I suggested before about Number interaction in the DefaultMessagePropertiesConverter makes sense for you, I'll be more than happy to provide that fix.

Thanks

from spring-amqp.

That would be great, thanks.

from spring-amqp.