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