A small update to this thread before I go back to the related new thread: What I said below around Proton-J sending out a Flow frame immediately after its Begin frame was a little incomplete, in that I had yet to appreciate that while the clients incoming window is increased at this point its outgoing window generally wouldnt be increased from 0 due to the method and points in time it is calculated and sent by proton coupled with how the client operates, so it probably isnt actually possible to see using the client what ServiceBus would do in the case that the outgoing window was increased via a subsequent Flow frame.
On 29 June 2015 at 12:27, Robbie Gemmell <[email protected]> wrote: > 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]
