[jira] [Updated] (QPID-6676) QPID 0.32 throughput drop sharply with HA module
[ https://issues.apache.org/jira/browse/QPID-6676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 李翰林 updated QPID-6676: -- Priority: Critical (was: Major) > QPID 0.32 throughput drop sharply with HA module > > > Key: QPID-6676 > URL: https://issues.apache.org/jira/browse/QPID-6676 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Clustering >Affects Versions: 0.32, qpid-cpp-0.34 > Environment: CentOS6.5 X86_64 >Reporter: 李翰林 >Assignee: Alan Conway >Priority: Critical > > I build QPID 0.32 C++ broker with HA module on CentOS6.5 and run a cluster of > 2 nodes with --ha-replicate=all, Then send messages using QPID Messaging API > continuously with protocol AMQP0-10 and I meet a strange problem,If I purge > all of messages in a queue and continue to send messages,The throughput drop > sharply. And the same problem seen on QPID 0.34 > Steps to reproduce: > 1: > qpid-config add exchange direct testHA.exchange > qpid-config add queue testHA.queue --max-queue-size 1048576000 > qpid-config bind testHA.exchange testHA.queue testHA.binding > 2: > Run "qpid-queue-stats -f testHA.queue" on a console > 3: > Send 10 messages to testHA.exchange with routingkey testHA.binding > 4: > Purge queue use the QPID manager tool (qpid-tool) > 5: > Repeat step 3 > get the output from step 2: > Queue Name SecDepthEnq RateDeq Rate > === > testHA.queue 1064.00 11350 10.670.00 <== > step3 > testHA.queue2.00 28965 8807.350.00 > testHA.queue2.00 46650 8842.570.00 > testHA.queue2.00 64300 8825.080.00 > testHA.queue2.00 81950 8824.850.00 > testHA.queue2.00 99600 8825.040.00 > testHA.queue2.00 10 199.970.00 > testHA.queue 40.01 0 0.00 2499.65 > <== step4 > testHA.queue 16.00 250 15.630.00 > <== step5 > testHA.queue2.00 900 325.070.00 > testHA.queue2.00 1600 350.050.00 > testHA.queue2.00 2300 350.120.00 > testHA.queue2.00 3000 349.980.00 > testHA.queue 2.003700 349.960.00 > testHA.queue 2.004350 324.960.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-6676) QPID 0.32 throughput drop sharply with HA module
李翰林 created QPID-6676: - Summary: QPID 0.32 throughput drop sharply with HA module Key: QPID-6676 URL: https://issues.apache.org/jira/browse/QPID-6676 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Clustering Affects Versions: qpid-cpp-0.34, 0.32 Environment: CentOS6.5 X86_64 Reporter: 李翰林 Assignee: Alan Conway I build QPID 0.32 C++ broker with HA module on CentOS6.5 and run a cluster of 2 nodes with --ha-replicate=all, Then send messages using QPID Messaging API continuously with protocol AMQP0-10 and I meet a strange problem,If I purge all of messages in a queue and continue to send messages,The throughput drop sharply. And the same problem seen on QPID 0.34 Steps to reproduce: 1: qpid-config add exchange direct testHA.exchange qpid-config add queue testHA.queue --max-queue-size 1048576000 qpid-config bind testHA.exchange testHA.queue testHA.binding 2: Run "qpid-queue-stats -f testHA.queue" on a console 3: Send 10 messages to testHA.exchange with routingkey testHA.binding 4: Purge queue use the QPID manager tool (qpid-tool) 5: Repeat step 3 get the output from step 2: Queue Name SecDepthEnq RateDeq Rate === testHA.queue 1064.00 11350 10.670.00 <== step3 testHA.queue2.00 28965 8807.350.00 testHA.queue2.00 46650 8842.570.00 testHA.queue2.00 64300 8825.080.00 testHA.queue2.00 81950 8824.850.00 testHA.queue2.00 99600 8825.040.00 testHA.queue2.00 10 199.970.00 testHA.queue 40.01 0 0.00 2499.65 <== step4 testHA.queue 16.00 250 15.630.00 <== step5 testHA.queue2.00 900 325.070.00 testHA.queue2.00 1600 350.050.00 testHA.queue2.00 2300 350.120.00 testHA.queue2.00 3000 349.980.00 testHA.queue 2.003700 349.960.00 testHA.queue 2.004350 324.960.00 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-6675) Setting sasl_max_ssf causes traceback in qpid.messaging
Brian Bouterse created QPID-6675:
Summary: Setting sasl_max_ssf causes traceback in qpid.messaging
Key: QPID-6675
URL: https://issues.apache.org/jira/browse/QPID-6675
Project: Qpid
Issue Type: Bug
Components: Python Client
Affects Versions: 0.26
Environment: cyrus-sasl-scram-2.1.26-14.fc20.x86_64
cyrus-sasl-plain-2.1.26-14.fc20.x86_64
cyrus-sasl-gssapi-2.1.26-14.fc20.x86_64
cyrus-sasl-2.1.26-14.fc20.x86_64
python-saslwrapper-0.16-5.fc20.x86_64
erlang-sasl-R16B-03.10.fc20.x86_64
cyrus-sasl-lib-2.1.26-14.fc20.x86_64
cyrus-sasl-md5-2.1.26-14.fc20.x86_64
cyrus-sasl-devel-2.1.26-14.fc20.x86_64
saslwrapper-0.16-5.fc20.x86_64
qpid-cpp-server-0.26-13.fc20.x86_64
python-qpid-proton-0.7-3.fc20.x86_64
qpid-tools-0.26-13.fc20.noarch
qpid-cpp-client-0.26-13.fc20.x86_64
qpid-cpp-server-store-0.26-13.fc20.x86_64
qpid-proton-c-0.7-3.fc20.x86_64
python-qpid-qmf-0.26-2.fc20.x86_64
python-qpid-0.26-2.fc20.noarch
qpid-qmf-0.26-2.fc20.x86_64
python-qpid-common-0.26-2.fc20.noarch
Reporter: Brian Bouterse
I tried to set sasl_max_ssf on a call to establish() in qpid.messaging, but
when I do I get the following traceback.
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/qpid/messaging/driver.py", line 504,
in dispatch
self.connect()
File "/usr/lib/python2.7/site-packages/qpid/messaging/driver.py", line 526,
in connect
self.engine = Engine(self.connection)
File "/usr/lib/python2.7/site-packages/qpid/messaging/driver.py", line 612,
in __init__
self._sasl.setAttr("maxssf", self.connection.sasl_max_ssf)
File "/usr/lib/python2.7/site-packages/qpid/sasl.py", line 36, in setAttr
raise SASLError(self._cli.getError())
SASLError: Error in setAttr (-1) Unknown string attribute name - maxssf
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-6674) EXTERNAL sasl mech without username gives "no mechanism available" error message
Brian Bouterse created QPID-6674:
Summary: EXTERNAL sasl mech without username gives "no mechanism
available" error message
Key: QPID-6674
URL: https://issues.apache.org/jira/browse/QPID-6674
Project: Qpid
Issue Type: Bug
Components: Python Client
Affects Versions: 0.26
Environment: cyrus-sasl-scram-2.1.26-14.fc20.x86_64
cyrus-sasl-plain-2.1.26-14.fc20.x86_64
cyrus-sasl-gssapi-2.1.26-14.fc20.x86_64
cyrus-sasl-2.1.26-14.fc20.x86_64
python-saslwrapper-0.16-5.fc20.x86_64
erlang-sasl-R16B-03.10.fc20.x86_64
cyrus-sasl-lib-2.1.26-14.fc20.x86_64
cyrus-sasl-md5-2.1.26-14.fc20.x86_64
cyrus-sasl-devel-2.1.26-14.fc20.x86_64
saslwrapper-0.16-5.fc20.x86_64
qpid-cpp-server-0.26-13.fc20.x86_64
python-qpid-proton-0.7-3.fc20.x86_64
qpid-tools-0.26-13.fc20.noarch
qpid-cpp-client-0.26-13.fc20.x86_64
qpid-cpp-server-store-0.26-13.fc20.x86_64
qpid-proton-c-0.7-3.fc20.x86_64
python-qpid-qmf-0.26-2.fc20.x86_64
python-qpid-0.26-2.fc20.noarch
qpid-qmf-0.26-2.fc20.x86_64
python-qpid-common-0.26-2.fc20.noarch
Reporter: Brian Bouterse
I tried to use qpid.messaging with EXTERNAL. I was not specifying a username
and I received an error message that makes no sense: "no mechanism available"
I have the following line in sasl2/qpidd.conf:
mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN
The contents of qpidd.conf are:
auth=yes
require-encryption=yes
ssl-require-client-authentication=yes
ssl-cert-db=/etc/pki/pulp/qpid/nss
ssl-cert-password-file=/etc/pki/pulp/qpid/nss/password
ssl-cert-name=broker
ssl-port=5671
If I use ANONYMOUS or PLAIN it works for me, but when I use EXTERNAL I get the
strange message. Here is my reproducer script:
from qpid.messaging.endpoints import Connection
opts = {'ssl_certfile': '/etc/pki/pulp/qpid/client.crt', 'ssl_trustfile':
'/etc/pki/pulp/qpid/ca.crt', 'ssl_skip_hostname_check': False,
'sasl_mechanisms': 'EXTERNAL', 'host': 'dhcp129-138.rdu.redhat.com', 'timeout':
4, 'ssl_keyfile': '/etc/pki/pulp/qpid/client.crt', 'port': 5671, 'transport':
'ssl'}
print 'no username'
try:
Connection.establish(**opts)
except Exception as err:
print err
print 'wrong username'
opts['username'] = 'wrongusername'
try:
Connection.establish(**opts)
except Exception as err:
print err
print 'right username'
opts['username'] = 'client'
try:
Connection.establish(**opts)
except Exception as err:
print err
else:
print 'no error'
When I run that I get this output:
no username
Error in sasl_client_start (-4) SASL(-4): no mechanism available:
wrong username
connection-forced: Authentication failed(320)
right username
no error
I expected that if a username is required that I would be told that from the
error message. If not all cases require a username then I expect not including
a username would give me a "Authentication failed(320)" also
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDIT-17) Add JMS test suite
[ https://issues.apache.org/jira/browse/QPIDIT-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPIDIT-17: --- Component/s: JmsMessageTest > Add JMS test suite > -- > > Key: QPIDIT-17 > URL: https://issues.apache.org/jira/browse/QPIDIT-17 > Project: Apache QPID IT > Issue Type: Task > Components: JmsMessageTest >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > The existing test, the Simple Type Test is centred around the AMQP 1.0 simple > types, and is designed to send AMQP types between clients to check > interoperability. > However, in the world of JMS, this approach is not ideal, as there is no > direct mapping between JMS message types and AMQP simple types. The idea is > to add another test, which is centred around the five basic JMS message types > rather than the AMQP types. This will allow these message types to drive the > test values rather than the AMQP types, and will provide a more efficient > mechanism for testing JMS interoperability between clients. While it may be > possible to test between non-JMS clients, it makes sense that one or more JMS > clients (such as qpid-jms) always be one of the two test clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDIT-17) Add JMS test suite
Kim van der Riet created QPIDIT-17: -- Summary: Add JMS test suite Key: QPIDIT-17 URL: https://issues.apache.org/jira/browse/QPIDIT-17 Project: Apache QPID IT Issue Type: Task Reporter: Kim van der Riet Assignee: Kim van der Riet The existing test, the Simple Type Test is centred around the AMQP 1.0 simple types, and is designed to send AMQP types between clients to check interoperability. However, in the world of JMS, this approach is not ideal, as there is no direct mapping between JMS message types and AMQP simple types. The idea is to add another test, which is centred around the five basic JMS message types rather than the AMQP types. This will allow these message types to drive the test values rather than the AMQP types, and will provide a more efficient mechanism for testing JMS interoperability between clients. While it may be possible to test between non-JMS clients, it makes sense that one or more JMS clients (such as qpid-jms) always be one of the two test clients. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3521) failover process for the 0-8 client does not clear the pre-dispatch queue
[ https://issues.apache.org/jira/browse/QPID-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652040#comment-14652040 ] Keith Wall commented on QPID-3521: -- A couple of comments: # Code changes seem to make a functional change to the 0-10 Connection#stop path, but this is not called out in the JIRA. I suggest a new JIRA describing the issue/user impact is appropriate. # I like the fact that we are now testing failover + connectio#stop, but it is the test assumes internals of the Java Broker (the statistic unacknowledgedMessages) and this is distasteful, as is spreading knowledge of the management interfaces across the test suite. Why is it not sufficient countdown after the message listener's Connection#stop and kill the Broker to cause failover? # AMQSession#stopExistingDispatcher is a check then act with the risk of a NPE if _dispatcher is nulled between. Copy the reference and then use the copy. # AMQSession#drainDispatchQueueWithDispatcher use a try/finally to help ensure that the dispatcher cleanup flag is always returned to its unset state. > failover process for the 0-8 client does not clear the pre-dispatch queue > - > > Key: QPID-3521 > URL: https://issues.apache.org/jira/browse/QPID-3521 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Robbie Gemmell >Assignee: Keith Wall > Labels: failover > Attachments: clear-dispatch-queue-on-failover.diff > > > failover process for the 0-8 client does not clear the pre-dispatch queue, > only the consumer receive queue. > This is currently masked by an issue with the rollbackMark. The changes made > in QPID-3546 to fix the 0-10 client path need to be applied to the 0-8/9/9-1 > client path when this issue is resolved. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Dispatch devs: any interest in moving to git?
+1 It does clear like the development universe has decided that git is the preferred technology. Then it's worth it just so that developers on this project will not have to keep two different source code control systems in their heads. Also, I do _not_ think that git is just a fashion. It's a fundamentally different way for sccs to work, and I bet that most projects will still be using it 10 years from now. I sure cannot say that about svn. - Original Message - Show of hands: would any of the dispatch developers object to moving the dispatch project from subversion to git? I've been using the git-svn conduit with dispatch, and, well, it just feels like a hack. Sure, I'm personally biased towards git, and maybe there really isn't a solid technical reason behind moving to it (though I'd bet some github users would argue that). Opinions? -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
