Chuck Rolke created QPID-4715:
---------------------------------
Summary: C++ Broker Replicating Event Listener needs a limit on
messages enqueued for replication
Key: QPID-4715
URL: https://issues.apache.org/jira/browse/QPID-4715
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: 0.22
Reporter: Chuck Rolke
Assignee: Chuck Rolke
A system has replication turned on (replicating_listener.so is loaded) and
events are being queued for replication. When the peer system stops receiving
messages then the replication queue grows unbounded and the broker runs out of
memory.
The proposed feature would have two parts:
# An optional upper limit may be placed on the replication queue size via the
CLI. When that limit is exceed then replication is stopped and the replication
queue is purged to reclaim its memory.
# A management method allows an administrator to stop replication at any time,
disabling the replication queue and reclaiming its memory.
Impact assessment:
||Design consideration||Proposed feature||
|Threading model|queues provide adequate locking|
|Memory management|n/a|
|Automated testing approach|easy to test|
|Impact on public API|Adds management method and Replication CLI switch|
|- Interoperability with implementations in other languages|n/a|
|- Backwards compatibility|n/a|
|Performance implications|Insignificant|
|Security implications|New method already protected by ACL|
|Platform support|n/a|
|Logging|Logs to be added|
|Monitoring|Event to be added|
|Management|New broker method|
This feature is a response to a panic situation. The theory is that it is
preferable to abandon replication than to drive the broker out of memory and
crash.
An administrator may want to trigger this feature based on several conditions:
# The qpidd process is using too much memory.
# The host system is running low on virtual memory
# The queue in question is using too much memory inside qpidd.
The proposal is to support feature #1 by specifying a _maximum message count_
for the replication queue. Queues already have this and it is a quick statistic
to compare for limit checking.
Queue sizes in bytes are not directly known. The customer is free to monitor
system and process virtual memory and still trigger the cleanup by using
feature #2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
