Robbie Gemmell created PROTON-713:
-------------------------------------
Summary: TransportImpl#setChannelMax does not enforce legal value
range, may cause unexpected results
Key: PROTON-713
URL: https://issues.apache.org/jira/browse/PROTON-713
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.8
Reporter: Robbie Gemmell
Priority: Minor
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.
{noformat}
if (_channelMax > 0) {
open.setChannelMax(UnsignedShort.valueOf((short) _channelMax));
}
{noformat}
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
