[
https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17368326#comment-17368326
]
ASF subversion and git services commented on QPID-8484:
-------------------------------------------------------
Commit a1b19a267d9a0c79df42b533df6cb9106895eaa3 in qpid-broker-j's branch
refs/heads/main from Marek Laca
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=a1b19a2 ]
QPID-8484: [Broker-J] Reimplementation of the limit number of connections per
user
This closes #76
> [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: [email protected]
For additional commands, e-mail: [email protected]
