Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
proton-0.8
-
None
Description
Whilst helping debug an issue yesterday with Tim (which turned out to be with the old Qpid 0.2X/0.3X AMQP 1.0 JMS client), we noticed some unexpected results from using Transport#setChannelMax method.
The chanel-max field of the Open frame is a ushort. The API expsoses this via the signed Java int to allow easily onfiguring the values outwith the signed short range. When using the value in TransportImp, it is cast to a short, which truncates the bit length of the value and may turn it negative (which is expected by the UnsignedShort wrapper). If a value over 2^16-1 is used, you thus do not get quite what you expect, and if you happen to use 2^16 then you will actually see 0.
if (_channelMax > 0) { open.setChannelMax(UnsignedShort.valueOf((short) _channelMax)); }
The legal range should be enforced so that the outgoing Open frame actually contains what the user asked for, and the legal values are clear.
Attachments
Issue Links
- is related to
-
PROTON-968 [proton-j] validate local/remote channel-max is adhered to
- Open