[
https://issues.apache.org/jira/browse/QPID-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288146#comment-13288146
]
Paul Colby commented on QPID-4036:
----------------------------------
I've done a quick review of the changes from r1215127 that have since been
dropped, and it seems unlikely that the subsequent changes would have regresses
QPID-3438.
Also, I've found a simpler test case:
# Compile and install 0.16 from source; make sure CPG is enabled (ie install
openais or corosync).
# Configure SASL to allow only PLAIN (or at least disable ANONYMOUS).
# Run: {{qpidd --cluster-name=test}}
#* you'll probably need to run it as {{root}}, or some other user with
permission to access the underlying cluster services.
# Run: {{for i in `seq 1 550`; do echo $i; qpid-stat -q; done}}
That's it... sit back and watch the broker become unusable ;)
Incidentally, the problem does not occur if the broker is not instructed to use
clustering.
> Failed client connections permanently exhaust broker's max connections limit
> ----------------------------------------------------------------------------
>
> Key: QPID-4036
> URL: https://issues.apache.org/jira/browse/QPID-4036
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.16
> Environment: CentOS release 5.5 (Final)
> Linux 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64
> x86_64 GNU/Linux
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
> Reporter: Paul Colby
> Priority: Critical
> Labels: sasl, ssl
>
> I'm running a set of Qpid 0.16 C++ brokers with configuration like:
> {code}
> cluster-name="mm-queue-cluster"
> cluster-cman=yes
> cluster-mechanism=PLAIN
> cluster-username=broker
> cluster-password=abc123
> cluster-url=ssl:gateway02:5671
> auth=yes
> ssl-cert-db=/etc/qpid/certs/broker
> ssl-cert-password-file=/etc/qpid/certs/pass.txt
> ssl-cert-name=broker.messagemedia.com.au
> require-encryption=yes
> {code}
> ie the broker is requiring both encryption and authentication (configured
> SASL mech list is CRAM-MD5 DIGEST-MD5 EXTERNAL PLAIN).
> Now, if a client (let's use {{qpid-stat}} for example) connects via SSL
> (amqps) and authenticates successfully, then everything is happy.
> However, if a client repeatedly fails to use SSL and/or fails to provide
> credentials, then the broker loses one of it's configured max connections
> every time!
> So, for example, if we start the broker using the configuration shown above,
> then do this:
> {code}for i in `seq 1 550`; do echo $i; qpid-stat -q ; done{code}
> The above loop will report ~ 500 {{AuthenticationFailure}} errors, then
> switch to {{ConnectionError}} errors. Once the {{ConnectionError}} errors
> begin, all further connections to the broker will be rejected - permanently
> (until the broker is restarted), with the broker logging:
> {code}error Client max connection count limit exceeded: 500 connection
> refused{code}
> From my testing, the following loops never cause an issue (with this
> configuration):
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/guest@localhost
> -q ; done # Works as expected.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://guest/wrong@localhost
> -q ; done # AuthenticationFailure as expected.
> {code}
> Whereas any of the following will break the broker:
> {code:none}
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/guest@localhost
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://guest/wrong@localhost
> -q ; done # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqp://localhost -q ; done
> # AuthenticationFailure, then ConnectionError.
> for i in `seq 1 550`; do echo $i; qpid-stat -b amqps://localhost -q ; done
> # AuthenticationFailure, then ConnectionError.
> {code}
--
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]
