[
https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222288#comment-17222288
]
Alex Rudyy commented on QPID-8484:
----------------------------------
Hi [~lacam],
The ACL logic should use connection creation time to determine the oldest
connections and close those exceeding the limit. Thus, the number of open AMQP
connections can exceed the limit for a short time until ACL check is performed.
Even after moving the check out of ACL, the limit would be breakable because
connections are opened in IO threads and registered in a configuration thread.
There will be always a delay between a check and a connection open.
I will try to address issue in pp 1. I do not think that pp. 2 can be
addressed. The improvements can be made for pp.3.
As for implementation, I would like suggest to encapsulate connection
registration functionality into some sort of ConnectionRegistry interface
extending Pluggable . The ConnectionRegistry implementation to use can be
governed by new VirtualHost context variable and attribute.
The interface might have the methods listed below:
* connectionRegistered(Connection):boolean
* connectionUnregistered(Connection):boolean
* visit(ConnectionVisitor)
* getConnectionCount(): int
ConnectionVisitor interface can be used to visit the connections in the
registry and perform some operations on the connection (like connection close
on VirtualHost close).
ConnectionVisitor can only have one method :
visit(Connection):boolean
If true is returned by visit(), the registry should top iterating over
registered connections.
We can move existing connection registration/unregistreation logic into some
sort of standard ConnectionRegistry implementation.
You can implement an instance of a ConnectionRegistry performing the user
limit checks. For the limits, we can add new attributes into the VirtualHost.
Thus, with a registry approach you do not need to change anything in
NamedAddressSpace. All the required checks could be performed in the registry
implementation.
What do you think about adding ConnectionRegistry and implementing user limits
in a specific implementation?
Kind Regards,
Alex
> [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]
