[jira] [Comment Edited] (PROTON-961) messenger doesn't handle multi-frame transfers

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645871#comment-14645871 ] 

Robbie Gemmell edited comment on PROTON-961 at 7/29/15 1:49 PM:
----------------------------------------------------------------

I'm sure it probably doesnt change the effect, but still worth noting that max frame size MUST be 512 bytes or higher.

I don't think the problem you saw necessarily points to an issue with the fix Gordon sugested, but instead to an issue with the engine in general...

The problem presumably happens at 1MB because the session defaults to a 1MB 'incoming bytes capacity'. If a local max-frame-size is set, this capacity is used to calculate the incoming window size as the number of max-sized frames that could be accepted at the time without breaching the 'capacity'. If a local max-frame-size is not specified (default), then a fixed window size of 2^31-1 is 'calculated' each time.

Proton-j and by the looks of it proton-c both recalculate their session incoming window whenever they are issuing a flow, which amongst other cases they will look to do during a process of the transport if the session incoming window hits 0. The issue is presumably that if the incoming window hits 0 (because a local max-frame-size was set, and the resulting window has now been used) and the session has also received its capacity of incoming bytes at the same time, then the re-cacluated window will still be 0, something that happens if you send messages over <session-capacity> in size. 

In short, if the local max-frame-size is being set, then the incoming session window behaviour seems basically broken for messages over <session-capacity>. If so, this likely hasnt been noticed for the most part because few are setting max-frame-size.

EDIT: fixed remote -> local for frame size usage.


was (Author: gemmellr):
I'm sure it probably doesnt change the effect, but still worth noting that max frame size MUST be 512 bytes or higher.

I don't think the problem you saw necessarily points to an issue with the fix Gordon sugested, but instead to an issue with the engine in general...

The problem presumably happens at 1MB because the session defaults to a 1MB 'incoming bytes capacity'. If a remote max-frame-size is set, this capacity is used to calculate the incoming window size as the number of max-sized frames that could be accepted at the time without breaching the 'capacity'. If a remote max-frame-size is not specified, then a fixed window size of 2^31-1 is 'calculated' each time.

Proton-j and by the looks of it proton-c both recalculate their session incoming window whenever they are issuing a flow, which amongst other cases they will look to do during a process of the transport if the session incoming window hits 0. The issue is presumably that if the incoming window hits 0 (because a remote max-frame-size was set, and the resulting window has now been used) and the session has also received its capacity of incoming bytes at the same time, then the re-cacluated window will still be 0, something that happens if you send messages over <session-capacity> in size. 

In short, if the remote max-frame-size is being set (as it was in the scenario this issue was noticed), then the incoming session window behaviour seems basically broken for messages over <session-capacity>. If so, this likely hasnt been noticed for the most part because few are setting max-frame-size.

> messenger doesn't handle multi-frame transfers
> ----------------------------------------------
>
>                 Key: PROTON-961
>                 URL: https://issues.apache.org/jira/browse/PROTON-961
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.9.1, 0.10, 0.11
>            Reporter: Gordon Sim
>
> See QPID-6651 for a reproducer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)