Yes, the "delay" indication is what I have been thinking of.
It would allow us to regulate the rate without introducing extra
"chattiness" to the protocol - or at least that is what I think it should
allow.
RG
|---------+---------------------------->
| | "John O'Hara" |
| | <[EMAIL PROTECTED]|
| | il.com> |
| | |
| | 21/09/2006 23:10 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
| cc:
|
| Subject: Re: Using AMQP pre-fetch windowing with JMS transactional
sessions and client acknowledge |
>------------------------------------------------------------------------------------------------------------------------------|
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 < [EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] 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.
>
>
This communication is for informational purposes only. It is not intended as an
offer or solicitation for the purchase or sale of any financial instrument or
as an official confirmation of any transaction. All market prices, data and
other information are not warranted as to completeness or accuracy and are
subject to change without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and
affiliates.
This transmission may contain information that is privileged, confidential,
legally privileged, and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information contained herein (including
any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other defect that might
affect any computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and
affiliates, as applicable, for any loss or damage arising in any way from its
use. If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
