[PROTON-968] [proton-j] validate local/remote channel-max is adhered to

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: proton-0.12.0
• Fix Version/s: proton-j-future
• Component/s: proton-j
• Assignee: Unassigned
• Reporter: Robbie Gemmell
• Created: 30/Jul/15 14:38
• Updated: 19/Jul/17 21:23

Description

The channel-max handling in proton-j is broken.

Transport[Impl] defines get/setChannelMax methods, which allow controlling the value sent in the Open frame emmitted for the connection. It defaults to the maximum 65535.

The ConnectionImpl object has a getMaxChannels method that returns a hard coded value of 65535, and it is this limit value that is used by TransportImpl when selecting local channel numbers for sending Begin frame for new sessions. As such, it pays no notice of the limit value it announced in its Open frame, which may have been lower if configured on the transport.

The remote channel-max receiver from the peer isn't used at all other than for return via getRemoteChannelMax(). The above process will similarly pay it no attention to it when selecting channel numbers for new sessions and so may select a channel number above the remote peers limit [and perhaps also its own, again].

Issue Links

• is blocked by: PROTON-281 Engine should handle errors by generating implicit CLOSE frame
• is related to: PROTON-493 channel max is not exposed
• is related to: PROTON-918 Jython interop tests failing since e38957ae5115
• relates to: PROTON-842 proton-c should honor channel_max
• relates to: PROTON-713 TransportImpl#setChannelMax does not enforce legal value range, may cause unexpected results