Hi Andrew, Yes, I had noticed later on Friday that the initial Begin frame Proton-J sends had a window of 0, with the next thing it does being to send a Flow frame with updated window valus (though I have yet to look into out how/why it does that), and these going out in the same write.
The AMQP spec discusses both each peers own local window values based on what it can currently send/receive, and also the ongoing computation of the remote peers windows which gets updated when sending/receiving Transfer frames and receiving Flow frames. From your logs of both clients, it looks to me that ServiceBus picks its local incoming window based directly on the initial outgoing window value the peer advertises in its Begin frames, and then would seem to always uses that starting value as a basis to populate the Flow frames it sends out even if the peer Flows new window information, so if it was zero initially then it simply stays that way. Its unclear if they have simply collapsed the local and remote outgoing window to be considered a single value, as that information is never shared. On the other hand, proton does some recalculation of its local windows and does not use the peers advertised windows to choose its own, instead just using that info to update the current remote windows and whether it can send without violating them, and so isn't affected by the use of an initial 0 and subsequent updates. Similarly, the Qpid Java broker looks to pick its own local window values and tracks those seperately from the computed remote windows, and so again appears to be similarly unaffected by the behaviour. If I'm reading things correctly I think it could be argued that ServiceBus probably shouldn't base its incoming window so directly on the Begin values, or if doing so then should possibly ensure to update it based on related Flow info. However, I would also say I don't know of a reason for proton-j to do what it is doing, and assume proton-c doesn't do the same otherwise the issue would have been noted long ago (based on known usage with Service Bus). I'm going to have a closer look to see if I can figure out where the difference is and how easy it would be to align them. Robbie On 28 June 2015 at 13:40, acartcat <[email protected]> wrote: > Robbie, > Appreciate the quick response. I followed your leed and tracked down the > story behind the window sizes. I created a Jira QPIDJMS-80 and put my > findings in. I got it to work with a small mod to TransportSession.java in > Proton-J, I've no idea if that's where it should be fixed but that was where > the difference was when compared the frame trace of the earlier JMS lib. > > Cheers > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Qpid-JMS-0-3-0-Holding-message-send-until-credit-is-available-tp7627277p7627336.html > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
