On 1 March 2017 at 16:47, Gordon Sim <[email protected]> wrote: > On 01/03/17 16:07, Robbie Gemmell wrote: >> >> The are issues around delivery count handling and the credit due to in >> flight messages and how thats handled. It also requires echo support >> (which proton lacks, theres another JRIA I raised for that) to do >> properly, and you essentially need to remember you reduced the credit >> to handle the state later when thigns actually do stop and start >> again. None of which proton currently does. > > > Not sure whether you are talking about proton-j specifically, or whether you > are saying that proton-c won't actually work correctly here either. It would > be good to know one way or the other whether this is a valid workaround for > proton-c. >
I was talking generally, I havent tried either specifically, and couldnt say if they behave the same or not. I dont think proton-j can handle this properly, and I doubt if proton-c does fully unless specific support was added after proton-j was based on it. I do think its entirely possible this may appear to work when it doesnt really, i.e messages may arrive but the delivery counts/credit calculations on either end become incorrect based on precisely what occurs on the connection. > I modified the example to re-issue credit after a timeout (I also fixed the > revocation to account for any queued messages). I then sent 10000 messages > to the queue and as far as I can see the example behaves as expected. A flow > is issued with 0 credit, eventually the broker handles this by not sending > any more messages and then after 30 seconds credit is issued again and more > messages are received and accepted. > > Log and example attached. Is there any issue I am missing or that the > example doesn't highlight? > How did you know they had actually stopped or that it was then safe to flow them new credit, just waiting for a while? If you flow new credit before the link is actually stopped you need to cope with that fairly specifically in case they hadnt really stopped. There is scope for things to get out of whack otherwise, on both ends, as they need to carefully handle the delivery-count and credit based on what occurs and whether they have already exceeded the previous allowances or not when the updates get sent/arrive. > > > --------------------------------------------------------------------- > 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]
