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.
Or do you envisage only being able to resize it once? If so is it really
any different from just having the limit set at the larger value in the
first place?
I was thinking along the lines of allowing the client to indicate some kind
of "rate" information to the broker so that it can slow down (or if
possible speed up) the rate of delivery, thereby providing a more graceful
flow control. I believe that SwiftMQ does something along those lines.
RG
|---------+---------------------------->
| | Gordon Sim |
| | <[EMAIL PROTECTED]>|
| | |
| | 21/09/2006 13:49 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
| cc:
|
| Subject: Re: Using AMQP pre-fetch windowing with JMS transactional
sessions and client acknowledge |
>------------------------------------------------------------------------------------------------------------------------------|
Gordon Sim wrote:
> Tim Fox wrote:
>> Perhaps the protocol needs to be extended?
>
> It does seem that it could be useful to be able to move the prefetch
> window without having to acknowledge the message.
A further thought here: it would be possible to resize the prefetch
winddow instead of moving it. i.e. if the prefetch is 100 and the
application is in control of when acknowledgements will be sent, then
after passing say the 80th message to the application, we could resize
the window to 180. When the acknowledgement is sent, we can resize it
back to 100.
I'm not saying that is ideal, but it seems like a workaround.
Alternatively if we were able to modify the channel.flow message then
instead of just a simple stop/go flag it could allow the 'position'
prefetch window to be stated (e.g. an unacknowledged messages received
count). (Theres no real reason this has to be put into channel.flow
apart from the fact that it does seem like flow control). That would
obviously require a protocol modification though.
Thoughts?
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.
