[ https://issues.apache.org/jira/browse/PROTON-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108460#comment-15108460 ]
ASF subversion and git services commented on PROTON-713: -------------------------------------------------------- Commit 701e8d07c29748168879e50680b1d4bb9340b271 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=701e8d0 ] PROTON-713: restrict the permitted values, throw exception when invalid value given, javadoc related methods to explain their use > 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)