
|
If you were logged in you would be able to see more operations.
|
|
|
|
|
| Component/s: |
None
|
| Affects Version/s: |
None
|
| Fix Version/s: |
1.4.0.SP3
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
|
The current consumer flow control algorithm sends messages from server to client as fast as it can.
The client sends a stop message when the client buffer reaches it's max size. It then sends a start message when the buffer reaches half it's max size.
An issue can arise here when sending from server-->client is fast, in that due to the finite amount of time sending the stop message to the server, significantly more messages than max buffer size can arrives at the consumer buffer.
While this is to be expected - the buffer size is not a hard limit. This can cause undesired effects when there are many consumers consuming from a queue and message processing rate is fairly slow - resulting in some slow consumers buffering many of the messages so they are not available to other consumers.
Workaround for this is to turn of bufering altogether by setting slowConsumers to true on the connection factory, but this may be too drastic.
The algorithm should be changed so the server stops sending when bufferSize messages have been sent and starts again when receives a start from the consumer.
This should result in a hard limit to buffer size and much smoother distribution of messages across competing consumers on a queue.
|
|
Description
|
The current consumer flow control algorithm sends messages from server to client as fast as it can.
The client sends a stop message when the client buffer reaches it's max size. It then sends a start message when the buffer reaches half it's max size.
An issue can arise here when sending from server-->client is fast, in that due to the finite amount of time sending the stop message to the server, significantly more messages than max buffer size can arrives at the consumer buffer.
While this is to be expected - the buffer size is not a hard limit. This can cause undesired effects when there are many consumers consuming from a queue and message processing rate is fairly slow - resulting in some slow consumers buffering many of the messages so they are not available to other consumers.
Workaround for this is to turn of bufering altogether by setting slowConsumers to true on the connection factory, but this may be too drastic.
The algorithm should be changed so the server stops sending when bufferSize messages have been sent and starts again when receives a start from the consumer.
This should result in a hard limit to buffer size and much smoother distribution of messages across competing consumers on a queue.
|
Show » |
|
There are no comments yet on this issue.
|
| |
|
|