Robbie Gemmell resolved PROTON-713.
       Resolution: Fixed
    Fix Version/s: 0.12.0

The behaviour was already changed somewhat in Proton 0.10 via PROTON-842, such 
that setting values above 2^16-1 were silently constrained to 2^16-1, in line 
with proton-c behaviour was adjusted to (seemingly for compatibility, due to 
lack of return type to supply an error). his isn't consistent with the other 
related range enforcements in proton-j, and still leaves negative values 
unchecked, so these latest changes address it in a more typical fashion of 
throwing an exception if the value is outside the allowed range.

> 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
>            Assignee: Robbie Gemmell
>            Priority: Minor
>             Fix For: 0.12.0
> 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

Reply via email to