[
https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220574#comment-17220574
]
Alex Rudyy commented on QPID-8484:
----------------------------------
Hi [~lacam],
I agree that limiting connection number and frequency would be better to do as
a resource restriction rather than ACL. Implementation of the special broker
plugin for it seems like a good idea. Though, if it would be difficult to do, I
do not mind adding the functionality into the broker-core. It would be
beneficial, if you could share some design for the work or at least provide a
bit more details on the implementation approach.
{quote}
ACL logic compares the actual counter value with the limit for every connection
(the counter value at the moment of the acl rule check) and 2,3 … or all 7
connections can be denied. The ACL logic does not know which connection broke
the limit.
{quote}
That is a defect. The intention was to deny only connections above the limit. I
will try to fix the issue.
> [Broker-J] Reimplementation of the limit number of connections per user
> -----------------------------------------------------------------------
>
> Key: QPID-8484
> URL: https://issues.apache.org/jira/browse/QPID-8484
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Affects Versions: qpid-java-broker-8.0.1, qpid-java-broker-8.0.2
> Reporter: Marek Laca
> Priority: Major
> Labels: connection, limit, user
>
> If some user creates too much connections, he can prevent other users from
> connecting to amqp ports.
> [QPID-8369|https://issues.apache.org/jira/projects/QPID/issues/QPID-8369]
> added an ability to limit maximum open connections per user.
> The user connection limit was implemented as ACL dynamic rule and it is part
> of the access control logic.
> But I have queries about the implementation:
> * The connection count of the user is not checked properly.
> For example 2 connections should be rejected when an user has limit 5 and
> tries to open 7 parallel connections. But what happens:
> ## Every connection increments the counter then the counter will be 7.
> ## ACL logic compares the actual counter value with the limit for every
> connection (the counter value at the moment of the acl rule check) and 2,3 …
> or all 7 connections can be denied. The ACL logic does not know which
> connection broke the limit.
> ## The counter is decremented when connection is closed.
> * ACL rules were static and so the result of the check did not vary in time
> and the Broker could cache the result ALLOWED or DENIED. From my point of
> view a dynamic check should not be part of the ACL logic because it makes ACL
> logic time dependent.
> * The user connection limit should be checked as soon as possible.
> I suggest to introduce a new plugin (similar to the access control provider
> plugin) that will hold the user's counters of open connections.
> It will provide following functionality:
> * It registers new connections for given user and the connection will be
> rejected if the user breaks the limit. The registration and update of user's
> counters will be an atomic operation.
> * It de-registers the connections for given user.
> If user breaks the limit then the connection will be closed with proper
> response "amqp:resource-limit-exceeded" instead of "amqp:not-allowed".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
