Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-713

TransportImpl#setChannelMax does not enforce legal value range, may cause unexpected results

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 0.8
    • Fix Version/s: 0.12.0
    • Component/s: proton-j
    • Labels:
      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

            Activity

              People

              • Assignee:
                gemmellr Robbie Gemmell
                Reporter:
                gemmellr Robbie Gemmell
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: