
| Key: |
MB-910
|
| Type: |
Improvement
|
| Status: |
Open
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Sean O'Callaghan
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
From the user..
There are 2 uses of memory that we understand - messages in flight are kept in memory, and messages ready for dispatch are kept in memory.
We want a low amount of messages able to be kept in memory when there are no consumers, so that they are spooled to disk quickly before ever being able to block the JMS with flow control.
We want a large amount of messages able to be kept in flight, so that if a consumer is running slow we do not block it before we need to.
What we want, is to be able to say that we only want a relatively small number of messages kept ready for dispatch in memory before spooling them to disk.
But if we start to get a buildup of dispatched but unacknowledged messages, we want to set a separate limit for how many are allowed.
|
|
Description
|
From the user..
There are 2 uses of memory that we understand - messages in flight are kept in memory, and messages ready for dispatch are kept in memory.
We want a low amount of messages able to be kept in memory when there are no consumers, so that they are spooled to disk quickly before ever being able to block the JMS with flow control.
We want a large amount of messages able to be kept in flight, so that if a consumer is running slow we do not block it before we need to.
What we want, is to be able to say that we only want a relatively small number of messages kept ready for dispatch in memory before spooling them to disk.
But if we start to get a buildup of dispatched but unacknowledged messages, we want to set a separate limit for how many are allowed.
|
Show » |
| There are no comments yet on this issue.
|
|