credit" have been
>> >> > worked out. The simple algorithm of a single credit number works
>> properly
>> >> > only if credit is never revoked. Proton's negative credit doesn't give
>> >> you
>> >> > enough info to handle in-flight mess
finite
> >> > credit. Wahey!
> >> >
> >> > It's probably something we should address and test across the board
> since
> >> > it is a feature of AMQP, but we haven't needed it so far and I would
> >> avoid
> >> > it if there's
it. Wahey!
>> >
>> > It's probably something we should address and test across the board since
>> > it is a feature of AMQP, but we haven't needed it so far and I would
>> avoid
>> > it if there's another solution as even i
eded it so far and I would
> avoid
> > it if there's another solution as even if we do put our house in order
> > it'll be a backwards interop issue for a long time.
> >
> >
> >> Overall, I also like the idea of releasing the messages. K
'll be a backwards interop issue for a long time.
>
>
>> Overall, I also like the idea of releasing the messages. Keeping the
>> messages around increases the router's
>> memory footprint. The messages could stay forever in the sender's
>> undel
does not disconnect
> and a receiver never shows up.
>
> >
> > ----- Original Message -
> > > From: "Ted Ross"
> > > To: users@qpid.apache.org
> > > Sent: Thursday, May 24, 2018 11:59:32 AM
> > > Subject: Re: Handling of undelivera
s URL so that we can track it?
>
>
> From: Ted Ross
> Sent: Thursday, May 24, 2018 5:59:32 PM
> To: users@qpid.apache.org
> Subject: Re: Handling of undeliverable messages in Dispatch Router
>
> I've given this a bit more thought and I
e.org
Subject: Re: Handling of undeliverable messages in Dispatch Router
I've given this a bit more thought and I think that the second option
is the correct one. Philosophically, Qpid Dispatch Router is about
minimizing the number of deliveries in flight. This reduces latency,
reduces memor
receiver never shows up.
>
> - Original Message -
> > From: "Ted Ross"
> > To: users@qpid.apache.org
> > Sent: Thursday, May 24, 2018 11:59:32 AM
> > Subject: Re: Handling of undeliverable messages in Dispatch Router
> >
> > I've g
day, May 24, 2018 11:59:32 AM
> Subject: Re: Handling of undeliverable messages in Dispatch Router
>
> I've given this a bit more thought and I think that the second option
> is the correct one. Philosophically, Qpid Dispatch Router is about
> minimizing the number of deliv
I've given this a bit more thought and I think that the second option
is the correct one. Philosophically, Qpid Dispatch Router is about
minimizing the number of deliveries in flight. This reduces latency,
reduces memory use, and increases aggregate capacity and scale.
Releasing rather than hold
Hi Kai,
What you describe is the current behavior of the router. When the
consumer detaches, the router does not revoke the credit already given
to the producer. There are two ways we can address this issue (I
agree that the current behavior is not optimal).
We could implement time-to-live expi
Hi,
we are experiencing some unwanted/unexpected behavior when using message
routing in Dispatch Router 1.0.1.
1. Receiver opens a receiver link on control/my-tenant/my-device
2. Sender opens a sender link on control/my-tenant/my-device
3. Sender gets credit from the router
4. Rece
13 matches
Mail list logo
