[
https://issues.apache.org/jira/browse/QPID-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17222804#comment-17222804
]
Marek Laca commented on QPID-8484:
----------------------------------
Hi [~orudyy],
the definition of the 'connection creation time' is shaky. The client opens a
connection, connection is received by the server machine, then operating system
hand over the broker and broker creates a connection object. The client does
not know the time when the broker creates a new connection object, hence he
does not known the order of the connection on the broker side.
When client opens 3 parallel connections and the limit is 2, broker should
close/reject one connection. But broker can pick up a connection randomly to
meet the limit.
Your requirement that broker should use connection creation time is redundant
because the client can not spot a difference and it is cause of troubles.
We can use the 'registration time' and address all three issues with 'check and
register' method when the method should be called as soon as possible.
If the broker has a free slot then the new connection will take up the slot and
processing of the connection can continue.
If the broker does not have a free slot then the connection will be rejected
and closed immediately.
The registration time has a nice property, it creates strictly increasing
sequence.
In case of
1) Connection count limit - only single counter of the occupied slots is needed.
2) Connection frequency limit - the last n registration times are needed at the
most (n = frequency limit).
We have to ensure that 'check and register' performs action in atomically. Only
two methods are needed: 'check and register' and 'de-register'.
Your suggested approach 'ConnectionRegistry 'is very generic and I do not think
so wide genericity is needed. I don't see another use case. I have doubts about:
* Performance - The limits were introduced to reduce performance issues when
some user consumed too many resources. The impact on the clients that does not
use any connection limits.
* Configuration - We would like to store the configuration in a file. I am
writing about hundreds of user accounts with connection limits.
* Strange conduct of the broker when a connection is accepted and then
rejected. A new connection (called B) can kick out previously register
connection (called A) and it could be kicked out by another connection (called
C) later and so on.
I planned to reuse a existing methods in NamedAddressSpace: registerConnection,
deregisterConnection. But I would have needed a new methods in AMQPConnection
interface. Hence I decided for the new methods in NamedAddressSpace interface
with default implementation "do nothing".
> [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
