[
https://issues.apache.org/jira/browse/QPID-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michal Zerola updated QPID-4779:
--------------------------------
Attachment: policies_prototype.patch
> Implementation of policies for queues in Java Qpid Broker
> ---------------------------------------------------------
>
> Key: QPID-4779
> URL: https://issues.apache.org/jira/browse/QPID-4779
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Affects Versions: Future
> Reporter: Michal Zerola
> Priority: Minor
> Fix For: Future
>
> Attachments: policies_prototype.patch
>
>
> Hi,
> currently the Java Broker doesn't provide the same policies for queues like
> C++ Broker does. In particular, there is no option to hard limit the maximum
> number of messages for queue and instruct the broker to act according to some
> policy if there is an attempt to exceed this limit.
> I think it would be nice to have possibility to set queue to REJECT or
> RING-TYPE policy like in C++ version.
> In the attachment is a dirty-prototype using which I am trying to outline the
> main idea of possible implementation. Please, consider it is as an
> illustration of the principle, there is definitely more (technical) work
> needed (including tests).
> Some explanation along the way:
> REJECT policy:
> The idea should be quite straight-forward. If the new message is supposed to
> be enqueued on some queue which current depth is already at the limit, the
> message should be rejected.
> RING policy:
> Each queue should be able to delete the least important message and create
> the free slot for new incoming message if the limit is met. The definition of
> least important differs among the queue types. For standard queue, it should
> be the oldest message, which can be easily found at the head of the queue.
> For priority queues (inspired by C++ implementation) it should be the oldest
> message with the lowest priority. For sorted queues I leave this up to
> discussion. Personally, I would assume that oldest message is the least
> important.
> NONE policy:
> Current situation, the queue grows until JVM memory limits allow it.
> As you can see from the patch, I have added the decision what to do with the
> message into the postCommit() method of PostEnqueueAction. According to the
> policy type, the new message is either rejected (AMQException thrown) or
> enqueued. In the case of RING policy, the least important message is deleted.
> I have added the method deleteLowestPriorityEntry() into the AMQQueue. The
> implementation in SimpleAMQQueue illustrates the idea - try to acquire and
> delete the least priority entry. To find the lowest priority entry from the
> entry list I have added the new iterator into the QueueEntryList interface.
> Each implementation can have different way how to find such an entry.
> SimpleAMQQueueEntryList just takes the first (oldest one). PriorityQueueList
> starts with the oldest with the lowest priority entry. I have not implemented
> yet the version for Sorted queues.
> Please try to look into the patch and let me know if the implementation based
> on this idea would be reasonable. I will provide the enhanced version of the
> patch then.
> Thank you.
> Michal
--
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]
