[ 
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)

Reply via email to