qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Using AMQP pre-fetch windowing with JMS transactional sessions and client acknowledge
Date Thu, 21 Sep 2006 22:10:38 GMT
I kind of like this - it's minimalist.
So what Gordon is saying is that a prefetch resize is like a block ack?

I also agree that our Flow Control is perhaps too simplistic and should have
some kind of rate specifier or hold off timer sent by the server (i.e server
says to client "no more messages for X milliseconds").  Or zero for stop
until told otherwise.

This would be cool because then the server can measure the rate of flow for
each client and then send a flow control message to tell the client to hold
off a bit - effectively altering the rate the client is producing to a more
acceptable rate.   Perhaps the client should also have a way of telling the
server how much back pressure it is experiencing as a publisher -- ie. the
client can say "give me more bandwidth I'm about to die".  Then the server
could make choices about who to penalise...  or is this all too complex?


At some stage, soon, we should write a precise description of how the JMS
ack/tran modes map to the protocol.  Its important that the clients and
servers interact consistently even across implementations, imho.  Sounds
like something we could proposed to those at the AMQP WG offsite...

John


On 21/09/06, Gordon Sim < gsim@redhat.com> wrote:
>
> robert.j.greig@jpmorgan.com wrote:
> > My initial reaction to your suggestion is: does this actually change
> > anything?
> >
> > i.e. if the prefetch is 100 and you resize it to 180, what do you do
> when
> > you reach that limit? Resize again? If the prefetch is in place to
> prevent
> > the memory footprint getting too large, resizing it may not be
> desirable.
>
> You only resize it once messages have been processed. It seems to me
> that the memory footprint is controlled by preventing the number of
> unprocessed messages in the client going above a specific value . But as
> messages are processed, they in effect 'make room' for more. However as
> the server has not received acks it is unaware of this extra space and
> wont send more messages unless the prefetch is increased.
>
> Once the application acknowledges a message the prefetch can be set back
> to the original value.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message