[
https://issues.apache.org/jira/browse/QPID-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved QPID-4022.
-------------------------------
Resolution: Fixed
Fix Version/s: 0.17
The connection limit specifications SHOULD be the same for all members of a
cluster but this is just to make management and log correlation easier. There
is no check for the limits being the same or not. The logic used to allow or
deny connections should not fail if the cluster members are configured with
different limits.
In practice a connection to a node is allowed or denied based on the current
number of connections known by this node. The number of current connections
includes the local connections made directly to this node and the shadowed
connections made to other cluster members.
* If a connection is denied due to configured connection limits then none of
the other cluster members sees the connection. The connection and its denial
are all handled on the local node.
*If the connection is allowed then the connection is shadowed to the other
cluster members who count the connection against their configured limits.
Shadowed and local connections count against all three connection limits:
--max-connections, --max-connections-per-user, and max-connections-per-ip.
Shadowed connections that cause a node to exceed a configured connection limit
only emit a warning log message and allow the connection to persist.
Connections are shadowed among cluster members. If node A has three local
connections and node B has three local connections then each node has six
connections in total. Configured connection limits are applied to new
connections being created on the local node. If nodes A and B have different
limits then each node will use a different limit when allowing connections to
itself.
The code in its current state also allows clusters to create more connections
than specified on the command line. For instance suppose you have a three node
cluster, --max-connections-per-user=4, and user bob is connected three times.
Next suppose each cluster member simultaneously receives a new connection from
bob. Each cluster member will see three connections from bob and allow the
connection. Each shadowed connection propagates to cluster peers and is
observed but not denied and bob may now have 6 connections. The rule is that a
cluster of M member nodes that specify N connections may have up to (N + M-1)
connections.
> C++ Broker connection limits by host ip and by user name can get confused
> -------------------------------------------------------------------------
>
> Key: QPID-4022
> URL: https://issues.apache.org/jira/browse/QPID-4022
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.16
> Reporter: Chuck Rolke
> Assignee: Chuck Rolke
> Fix For: 0.17
>
> Attachments: QPID-4022-conn-limits-rev2-10-with-tests.patch
>
>
> The current ACL module uses the ConnectionObserver to watch the life cycle of
> connections. It tries to disallow the creation of too many connections by a
> user or from an IP address. However, the method is uses is flawed especially
> in the cluster case.
> A better strategy to use it to provide approvers in the ConnectionObserver
> scheme and then to call them:
> 1. Limits by IP address are disapproved in the ConnectionFactories. If the
> limit is reached then the factory does not create the connection codec and
> the connection never begins a life cycle. This is enforced at the same point
> in code as the per-broker --max-connection limit using similar enforcement
> methods.
> 2. Limits by user name are disapproved at the same point as user
> authentication happens. Details to follow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
