[
https://issues.apache.org/jira/browse/QPID-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16070375#comment-16070375
]
Keith Wall commented on QPID-7815:
----------------------------------
In reply to Lorenz's point on the 21st, one possibility is to have the overflow
policy handlers consulted *before* the enqueue occurs. I am imagining a method
like {{OverflowPolicyHandler#preEnqueue(ServerMessage)}}. The method would
allow the routing to the queue(s) to be vetoed if necessary.
For the {{RejectOverflowPolicyHandler}}, its {{preEnqueue}} method would work
out if the message would be acceptable to the queue or not. It will do this by
maintaining {{pendingMessages}} and {{pendingBytes}} atomic counters. To
decide whether the message is acceptable or not, it would sum the pending
counters these with the queue's actual message/bytes statistics. The reject
policy's {{checkOverflow}} method would merely be tasked with reducing the
pending counters. It would not be able to veto the message's enqueue. To
ensure that the pending counters are decremented on rollback case, the reject
policy would need to register a on-delete listener with the message itself
(proposed: {{ServerMessage#addDeleteAction}}).
For the existing overview policies, the {{preEnqueue}} would simply accept the
message.
{{ServerMessage#isResourceAcceptable}} would be given the responsibility to
consult {{OverflowPolicyHandler#preEnqueue(ServerMessage)}}, if the queue has
an overflow policy.
I can see a disadvantage with this approach There is a race which would
manifest when a queue is approaching its limits: a newly arrive message could
be spuriously rejected if it's enqueue races 'unlucky' with another thread's
maintenance of the pending counters. I can't see how to avoid this without
single threading the some parts of the enqueue path (which I think would be
unacceptable). My hope is that this would not present problem in practice.
I also want to highlight another aspect of the proposal's behaviour. If a
message is routed to am exchange that is bound to many queues, if any queue
rejects, the message will be rejected globally and will go to none (see
RoutingResult.java:103). I don't see this is a problem, but wanted to call it
out for discussion.
> Reject policy type
> ------------------
>
> Key: QPID-7815
> URL: https://issues.apache.org/jira/browse/QPID-7815
> Project: Qpid
> Issue Type: New Feature
> Components: Java Broker
> Affects Versions: qpid-java-broker-7.0.0
> Reporter: Tomas Vavricka
> Assignee: Lorenz Quack
> Labels: policy-type, queue, reject
> Fix For: qpid-java-broker-7.0.0
>
> Attachments:
> 0001-QPID-7815-Java-Broker-Enable-QueuePolicyTests-on-all.patch,
> 0001-QPID-7815-Reject-policy-type.patch
>
>
> It would be good if Java Broker will support reject policy.
> Reject policy - reject incoming message(s) when queue capacity is reached
> Queue capacity can be defined by maximum count of message and maximum size of
> messages (including header).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
