qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [proton-j] handling of link-credit
Date Wed, 01 Mar 2017 17:19:55 GMT
On 1 March 2017 at 16:47, Gordon Sim <gsim@redhat.com> 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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message