[jira] [Resolved] (QPID-1726) Develop an ASF licensed, Qpid hosted store module
[ https://issues.apache.org/jira/browse/QPID-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-1726. -- Resolution: Fixed This is complete as far as I can see. Tests are now integrated. Develop an ASF licensed, Qpid hosted store module - Key: QPID-1726 URL: https://issues.apache.org/jira/browse/QPID-1726 Project: Qpid Issue Type: New Feature Components: C++ Broker Reporter: Gordon Sim Assignee: Chuck Rolke Fix For: 0.23 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3914) SSL Client Authentication support for the Windows C++ client
[ https://issues.apache.org/jira/browse/QPID-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817186#comment-13817186 ] JAkub Scholz commented on QPID-3914: Yes, we played with it and it seems to work fine. SSL Client Authentication support for the Windows C++ client Key: QPID-3914 URL: https://issues.apache.org/jira/browse/QPID-3914 Project: Qpid Issue Type: New Feature Components: C++ Client Affects Versions: 0.14, 0.16 Environment: Windows (all versions) Reporter: JAkub Scholz Assignee: Cliff Jansen Attachments: ssl-client-auth-filecert-updated.patch, ssl-client-auth-filecert.patch, ssl-client-authentication-updated.patch, ssl-client-authentication.patch The Windows C++ client has been missing support for the SSL Client Authentication - authentication using SSL certificates on the client side. The patch attached to this JIRA implements this feature. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: svn commit: r1539510 - in /qpid/trunk/qpid/cpp/src/tests: ./ legacystore/
On 11/07/2013 12:42 AM, astitc...@apache.org wrote: Author: astitcher Date: Thu Nov 7 00:42:42 2013 New Revision: 1539510 URL: http://svn.apache.org/r1539510 Log: QPID-5306: Improve c++ tests some more: Add options to run_test script: --working-dir - run the test in this directory --build-dir- set the top of the build tree --source-dir - set the top of the source tree --python - run a python test --start-broker - start/stop broker before and after test --broker-options - allow non default broker options Remove a bunch of now obsolete testing related scripts Removed: qpid/trunk/qpid/cpp/src/tests/legacystore/tests_env.sh qpid/trunk/qpid/cpp/src/tests/start_broker qpid/trunk/qpid/cpp/src/tests/start_broker.ps1 qpid/trunk/qpid/cpp/src/tests/stop_broker qpid/trunk/qpid/cpp/src/tests/stop_broker.ps1 qpid/trunk/qpid/cpp/src/tests/test_wrap Modified: qpid/trunk/qpid/cpp/src/tests/CMakeLists.txt qpid/trunk/qpid/cpp/src/tests/legacystore/CMakeLists.txt qpid/trunk/qpid/cpp/src/tests/run_header_test qpid/trunk/qpid/cpp/src/tests/run_msg_group_tests qpid/trunk/qpid/cpp/src/tests/run_queue_flow_limit_tests qpid/trunk/qpid/cpp/src/tests/run_test qpid/trunk/qpid/cpp/src/tests/test_env.sh.in This triggers a test failure: legacystore_OrderingTest - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On 11/07/2013 09:56 PM, Irina Boverman wrote: Currently there are 2 tests, cpp and java/jms, in respective source trees. qpid/cpp/src/tests/qpid-cpp-benchmark qpid/java/tools/bin/qpid-jms-benchmark Both tests use similar options (with a couple of exceptions). They also share majority of code, the exceptions are calls to qpid-send, qpid-receive and few other minor differences. There is a desire to provide one interface for all language implementations (as well as, extend implementation to other language clients). This goal can be accomplished in different ways: Option 1: Add a thin layer (new test) to check language preference and pass control to the corresponding test. In this case existing tests are preserved and continue to exist in the language specific source trees. The disadvantage is that we end up maintaining similar code in multiple places. I'm strongly against this option. As you note, the qpid-jms-benchmark is essentially a copy-and-paste of qpid-cpp-benchmark with one or two lines commented out (presumably because they break something or aren't supported?) or tweaked (seemingly just due to different 'executable' names and again some options not supported) and the recent addition of options to control the path on which qpid-send/qpid-receive are located. The latter is a good example of the usual problem with the copy-and-paste approach, since an update contributed to the original was not made to the copy. This addition is also designed to allow the same script to drive different implementations of send and receive. Option 2: Consolidate tests into one source and place it in qpid/tests/src/py/qpid_tests/client/ location. The advantage is reduced maintenance, the disadvantage is that now one needs all qpid source to run a specific test. As above, the scripts are so close that consolidating[1] them is the obvious choice. However I don't think the qpid/tests location is the best option. So... Option 3: Consolidate the tests into one source and place it in qpid/python. I.e. consider the benchmark script to be part of (or related to) the python client much as the qpid-python-test script is. Since both the existing tests already import qpid.messaging this isn't actually imposing any significant extra dependency. There are also python equivalents of qpid-send and qpid-receive. Providing we keep the ability recently added to qpid-cpp-benchmark to specify the path to qpid-send and qpid-receive, that test can then be used to run either c++ or java based equivalents. --Gordon [1] In practice I think consolidation is simply a mater or renaming the qpid-cpp-benchmark, renaming qpid-jms-send and qpid-jms-receive to qpid-send and qpid-receive respectively, and then modifying those to accept the options passed in, even if they don't yet actually support them. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5311) Website improvements for the 0.26 timeframe
Justin Ross created QPID-5311: - Summary: Website improvements for the 0.26 timeframe Key: QPID-5311 URL: https://issues.apache.org/jira/browse/QPID-5311 Project: Qpid Issue Type: Task Components: Website Affects Versions: 0.24 Reporter: Justin Ross Assignee: Justin Ross Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5311) Website improvements for the 0.26 timeframe
[ https://issues.apache.org/jira/browse/QPID-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817245#comment-13817245 ] ASF subversion and git services commented on QPID-5311: --- Commit 1540008 from [~justi9] [ https://svn.apache.org/r1540008 ] QPID-5311: Update the committer list; remove a duplicate entry Website improvements for the 0.26 timeframe --- Key: QPID-5311 URL: https://issues.apache.org/jira/browse/QPID-5311 Project: Qpid Issue Type: Task Components: Website Affects Versions: 0.24 Reporter: Justin Ross Assignee: Justin Ross Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4990) Website improvements for the 0.24 timeframe
[ https://issues.apache.org/jira/browse/QPID-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed QPID-4990. - Website improvements for the 0.24 timeframe --- Key: QPID-4990 URL: https://issues.apache.org/jira/browse/QPID-4990 Project: Qpid Issue Type: Task Components: Website Affects Versions: 0.22 Reporter: Justin Ross Assignee: Justin Ross Fix For: 0.24 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5300) [AMQP 1.0] Some ACL errors are returned as internal error instead of unauthorized error
[
https://issues.apache.org/jira/browse/QPID-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817298#comment-13817298
]
ASF subversion and git services commented on QPID-5300:
---
Commit 1540040 from [~gsim] in branch 'qpid/trunk'
[ https://svn.apache.org/r1540040 ]
QPID-5300: correct error condition for certain unauthorized access errors
[AMQP 1.0] Some ACL errors are returned as internal error instead of
unauthorized error
---
Key: QPID-5300
URL: https://issues.apache.org/jira/browse/QPID-5300
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.25
Reporter: JAkub Scholz
Assignee: Gordon Sim
Fix For: 0.25
It seems when some ACL errors occur, the C++ broker is sometimes using the
AMQP 1.0 error code unauthorized-access and sometimes internal-error. For
example the ACL denied queue access error is amqp:unauthorized-access:
{{[0x24ca9d0:0] - @detach [handle=0, closed=true, error=@error
{condition=:amqp:unauthorized-access, description=ACL denied queue access
request from ABCFR_ABCFRALMMACC1@QPID
(/home/jakub/qpid/qpid-trunk/cpp/src/qpid/broker/amqp/Authorise.cpp:72)]]}}
But ACL denied queue create access is amqp:internal-error:
{{[0x1d14b10:0] - @detach [handle=1, closed=true, error=@error
[condition=:amqp:internal-error, description=unauthorized-access: ACL
denied queue create request from ABCFR_ABCFRALMMACC1@QPID
(/home/jakub/qpid/qpid-trunk/cpp/src/qpid/broker/Broker.cpp:1295)]]}}
I would expect that all ACL errors should be returned as
amqp:unauthorized-access.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5299) [AMQP 1.0] ACL rules should be checked before checking node's existence and returning amqp:not-found error
[ https://issues.apache.org/jira/browse/QPID-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817300#comment-13817300 ] ASF subversion and git services commented on QPID-5299: --- Commit 1540041 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1540041 ] QPID-5299: check access permissions before resolving node [AMQP 1.0] ACL rules should be checked before checking node's existence and returning amqp:not-found error -- Key: QPID-5299 URL: https://issues.apache.org/jira/browse/QPID-5299 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.25 Environment: Apache Qpid C++ broker, CentOS Reporter: JAkub Scholz Assignee: Gordon Sim Fix For: 0.25 When a client is connecting with AMQP 1.0 to the C++ broker and the node from which it wants to consume messages doesn't exist, the broker throws an amqp:not-found error even when ACL rules deny the user to access or publish from the given node (queue). This problem might to some extent exist also with AMQP 0.10. But the Qpid AMQP 0.10 clients always query the existence of a queue/exchange before connecting to it and the QueueQuery / QueueDeclare calls are ACL protected, so the Qpid based AMQP 0.10 client always receives the ACL error before the not-found error. But I guess if you skip the QueueQuery / QueueDeclare and go directly to MessageSubscribe the same problem as with AMQP 1.0 might exist in AMQP 0.10 as well. For a security reasons, I would assume that the ACL check for access or publish rules should be done before revealing that the queue doesn't exist. The broker should not reveal any details about its configuration if the ACL rights don't allow it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5309) PagedQueue page file created as executable
[ https://issues.apache.org/jira/browse/QPID-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817297#comment-13817297 ] ASF subversion and git services commented on QPID-5309: --- Commit 1540039 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1540039 ] QPID-5309: don't set executable flag on page file PagedQueue page file created as executable -- Key: QPID-5309 URL: https://issues.apache.org/jira/browse/QPID-5309 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5299) [AMQP 1.0] ACL rules should be checked before checking node's existence and returning amqp:not-found error
[ https://issues.apache.org/jira/browse/QPID-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-5299. -- Resolution: Fixed [AMQP 1.0] ACL rules should be checked before checking node's existence and returning amqp:not-found error -- Key: QPID-5299 URL: https://issues.apache.org/jira/browse/QPID-5299 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.25 Environment: Apache Qpid C++ broker, CentOS Reporter: JAkub Scholz Assignee: Gordon Sim Fix For: 0.25 When a client is connecting with AMQP 1.0 to the C++ broker and the node from which it wants to consume messages doesn't exist, the broker throws an amqp:not-found error even when ACL rules deny the user to access or publish from the given node (queue). This problem might to some extent exist also with AMQP 0.10. But the Qpid AMQP 0.10 clients always query the existence of a queue/exchange before connecting to it and the QueueQuery / QueueDeclare calls are ACL protected, so the Qpid based AMQP 0.10 client always receives the ACL error before the not-found error. But I guess if you skip the QueueQuery / QueueDeclare and go directly to MessageSubscribe the same problem as with AMQP 1.0 might exist in AMQP 0.10 as well. For a security reasons, I would assume that the ACL check for access or publish rules should be done before revealing that the queue doesn't exist. The broker should not reveal any details about its configuration if the ACL rights don't allow it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5300) [AMQP 1.0] Some ACL errors are returned as internal error instead of unauthorized error
[
https://issues.apache.org/jira/browse/QPID-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved QPID-5300.
--
Resolution: Fixed
[AMQP 1.0] Some ACL errors are returned as internal error instead of
unauthorized error
---
Key: QPID-5300
URL: https://issues.apache.org/jira/browse/QPID-5300
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.25
Reporter: JAkub Scholz
Assignee: Gordon Sim
Fix For: 0.25
It seems when some ACL errors occur, the C++ broker is sometimes using the
AMQP 1.0 error code unauthorized-access and sometimes internal-error. For
example the ACL denied queue access error is amqp:unauthorized-access:
{{[0x24ca9d0:0] - @detach [handle=0, closed=true, error=@error
{condition=:amqp:unauthorized-access, description=ACL denied queue access
request from ABCFR_ABCFRALMMACC1@QPID
(/home/jakub/qpid/qpid-trunk/cpp/src/qpid/broker/amqp/Authorise.cpp:72)]]}}
But ACL denied queue create access is amqp:internal-error:
{{[0x1d14b10:0] - @detach [handle=1, closed=true, error=@error
[condition=:amqp:internal-error, description=unauthorized-access: ACL
denied queue create request from ABCFR_ABCFRALMMACC1@QPID
(/home/jakub/qpid/qpid-trunk/cpp/src/qpid/broker/Broker.cpp:1295)]]}}
I would expect that all ACL errors should be returned as
amqp:unauthorized-access.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5309) PagedQueue page file created as executable
[ https://issues.apache.org/jira/browse/QPID-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-5309. -- Resolution: Fixed PagedQueue page file created as executable -- Key: QPID-5309 URL: https://issues.apache.org/jira/browse/QPID-5309 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5312) Paged queue does not deliver all messages
Gordon Sim created QPID-5312: Summary: Paged queue does not deliver all messages Key: QPID-5312 URL: https://issues.apache.org/jira/browse/QPID-5312 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 In particular when either max-pages-loaded is 1 or when selectors are used. The problem in both cases is where the head of the queue is not loaded when a new subscription comes in, and the logic doesn't recognise this and load the page, but rather just assumes there is nothing in it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: svn commit: r1539510 - in /qpid/trunk/qpid/cpp/src/tests: ./ legacystore/
On Fri, 2013-11-08 at 11:23 +, Gordon Sim wrote: ... This triggers a test failure: legacystore_OrderingTest Sadly, it just exposes a test failure that was latent before as a leak detected by valgrind. [previously valgrind wasn't actually being run on the legacystore tests] It's on my list to jira. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5313) qpid-dxrouterd binary should install the /usr/sbin on *nix
Darryl L. Pierce created QPID-5313: -- Summary: qpid-dxrouterd binary should install the /usr/sbin on *nix Key: QPID-5313 URL: https://issues.apache.org/jira/browse/QPID-5313 Project: Qpid Issue Type: Bug Components: Qpid Dispatch Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Since this binary is meant to run as a daemon process, it should install in /usr/sbin. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5314) Don't include full path for paging file in paged queue exceptions
Gordon Sim created QPID-5314: Summary: Don't include full path for paging file in paged queue exceptions Key: QPID-5314 URL: https://issues.apache.org/jira/browse/QPID-5314 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5313) qpid-dxrouterd binary should install the /usr/sbin on *nix
[ https://issues.apache.org/jira/browse/QPID-5313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817338#comment-13817338 ] ASF subversion and git services commented on QPID-5313: --- Commit 1540072 from [~mcpierce] in branch 'dispatch/trunk' [ https://svn.apache.org/r1540072 ] QPID-5313: Install qpid-dxrouterd to /usr/sbin. qpid-dxrouterd binary should install the /usr/sbin on *nix -- Key: QPID-5313 URL: https://issues.apache.org/jira/browse/QPID-5313 Project: Qpid Issue Type: Bug Components: Qpid Dispatch Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Since this binary is meant to run as a daemon process, it should install in /usr/sbin. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5307) Change test scripts to cross-platform language
[ https://issues.apache.org/jira/browse/QPID-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817347#comment-13817347 ] Alan Conway commented on QPID-5307: --- I think there are two overall options for structuring the tests in python: 1) Write python scripts that closely mimic the shell scripts in terms of starting processes etc. 2) Use the python unit-test suite and qpid's brokertest.py to structure the tests in a more pythonesque way. 1. may be easier (initially) as it is more or less just transcribing shell into python 2. may be more work initially but offers some advantages: - a more normal python test suite that can be handled by various python test runners - e.g. qpid-python-test allows you to specify tests to include/exclude by regexp etc. - somewhat more structured, can group tests into sensible suites. - brokertest.Popen and brokertest.Broker takes care of some stuff in a central way: - safe broker port allocation. - verify expected exit status of brokers and clients. - create separate directory for each test, at end of test it has: - broker logs - stdout, stderr of clients - core files - Simple functions to verify queue contents by browsing, VERY useful - assorted other stuff... To see how all this works check out cpp/src/tests/ - brokertest.py: The framework - ha_test.py: extended framework for HA cluster tests - ha_tests.py: The HA test suite. There are currently a few conveniences in ha_test.py that aren't really ha-only, I can move them into brokertest.py and will be happy to help with any new features that might be needed. So obviously I'm a fan of 2) as without it my head would have long ago exploded doing the cluster ha work. I think 1) may look easier in the short term but 2) may be a better move in the long term. Change test scripts to cross-platform language -- Key: QPID-5307 URL: https://issues.apache.org/jira/browse/QPID-5307 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client, C++ Clustering Reporter: Steve Huston Assignee: Steve Huston Labels: test Fix For: Future The C++ tree's test suite drivers are primarily shell scripts. Many were duplicated as Windows PowerShell scripts along the way. However, not all scripts were PowerShell-ized, and the dual set of test scripts is not maintained in sync. Someone (Cliff?) suggested a while back that the test driver scripts be written in a common language across Linux and Windows, and for other platforms as well. Python, Perl, Ruby are all possible choices - python and ruby need to be on build systems anyway for code generation. What do people think about a) this idea in general, b) language to use? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-5307) Change test scripts to cross-platform language
[ https://issues.apache.org/jira/browse/QPID-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817347#comment-13817347 ] Alan Conway edited comment on QPID-5307 at 11/8/13 3:31 PM: I think there are two overall options for structuring the tests in python: 1) Write python scripts that closely mimic the shell scripts in terms of starting processes etc. 2) Use the python unit-test suite and qpid's brokertest.py to structure the tests in a more pythonesque way. 1. may be easier (initially) as it is more or less just transcribing shell into python 2. may be more work initially but offers some advantages: - a more normal python test suite that can be handled by various python test runners - e.g. qpid-python-test allows you to specify tests to include/exclude by regexp etc. - somewhat more structured, can group tests into sensible suites. - brokertest.Popen and brokertest.Broker takes care of some stuff in a central way: -- safe broker port allocation. -- verify expected exit status of brokers and clients. -- create separate directory for each test, at end of test it has: --- broker logs --- stdout, stderr of clients --- core files - Simple functions to verify queue contents by browsing, VERY useful - assorted other stuff... To see how all this works check out cpp/src/tests/ - brokertest.py: The framework - ha_test.py: extended framework for HA cluster tests - ha_tests.py: The HA test suite. There are currently a few conveniences in ha_test.py that aren't really ha-only, I can move them into brokertest.py and will be happy to help with any new features that might be needed. So obviously I'm a fan of 2) as without it my head would have long ago exploded doing the cluster ha work. I think 1) may look easier in the short term but 2) may be a better move in the long term. was (Author: aconway): I think there are two overall options for structuring the tests in python: 1) Write python scripts that closely mimic the shell scripts in terms of starting processes etc. 2) Use the python unit-test suite and qpid's brokertest.py to structure the tests in a more pythonesque way. 1. may be easier (initially) as it is more or less just transcribing shell into python 2. may be more work initially but offers some advantages: - a more normal python test suite that can be handled by various python test runners - e.g. qpid-python-test allows you to specify tests to include/exclude by regexp etc. - somewhat more structured, can group tests into sensible suites. - brokertest.Popen and brokertest.Broker takes care of some stuff in a central way: - safe broker port allocation. - verify expected exit status of brokers and clients. - create separate directory for each test, at end of test it has: - broker logs - stdout, stderr of clients - core files - Simple functions to verify queue contents by browsing, VERY useful - assorted other stuff... To see how all this works check out cpp/src/tests/ - brokertest.py: The framework - ha_test.py: extended framework for HA cluster tests - ha_tests.py: The HA test suite. There are currently a few conveniences in ha_test.py that aren't really ha-only, I can move them into brokertest.py and will be happy to help with any new features that might be needed. So obviously I'm a fan of 2) as without it my head would have long ago exploded doing the cluster ha work. I think 1) may look easier in the short term but 2) may be a better move in the long term. Change test scripts to cross-platform language -- Key: QPID-5307 URL: https://issues.apache.org/jira/browse/QPID-5307 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client, C++ Clustering Reporter: Steve Huston Assignee: Steve Huston Labels: test Fix For: Future The C++ tree's test suite drivers are primarily shell scripts. Many were duplicated as Windows PowerShell scripts along the way. However, not all scripts were PowerShell-ized, and the dual set of test scripts is not maintained in sync. Someone (Cliff?) suggested a while back that the test driver scripts be written in a common language across Linux and Windows, and for other platforms as well. Python, Perl, Ruby are all possible choices - python and ruby need to be on build systems anyway for code generation. What do people think about a) this idea in general, b) language to use? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On Fri, 2013-11-08 at 11:43 +, Gordon Sim wrote: ... Option 1: Add a thin layer (new test) to check language preference and pass control to the corresponding test. In this case existing tests are preserved and continue to exist in the language specific source trees. The disadvantage is that we end up maintaining similar code in multiple places. I'm strongly against this option. I absolutely agree. Option 3: Consolidate the tests into one source and place it in qpid/python. I.e. consider the benchmark script to be part of (or related to) the python client much as the qpid-python-test script is. This makes a lot of sense to me too Since both the existing tests already import qpid.messaging this isn't actually imposing any significant extra dependency. There are also python equivalents of qpid-send and qpid-receive. Providing we keep the ability recently added to qpid-cpp-benchmark to specify the path to qpid-send and qpid-receive, that test can then be used to run either c++ or java based equivalents. One disagreement I may have here is that I think we should retain different names for the different implementations of qpid-send and qpid-receive. So I think we need to add an option to qpid-benchmark to not only set the path it uses to find them, but also the names of the executables it uses. An approach the works for the Java testing is to use profiles that set a bunch of related parameters and that can be switched as a whole. The reason I want to do this is that I want to move to a testing regime where we can run a specific build and use its install result (with probably a special testing tools install location) to run the subsequent test run. If we are to do this with multiple of the the qpid subtrees together, say c++ and java then it will be confusing if the *-send and *-receive executables have the same name. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5315) paging out of memory loses persistence id for messages
Gordon Sim created QPID-5315: Summary: paging out of memory loses persistence id for messages Key: QPID-5315 URL: https://issues.apache.org/jira/browse/QPID-5315 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 Meaning that attempt to dequeue fails with 'Dequeuing message with null persistence Id.' error. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On 11/08/2013 03:37 PM, Andrew Stitcher wrote: On Fri, 2013-11-08 at 11:43 +, Gordon Sim wrote: Since both the existing tests already import qpid.messaging this isn't actually imposing any significant extra dependency. There are also python equivalents of qpid-send and qpid-receive. Providing we keep the ability recently added to qpid-cpp-benchmark to specify the path to qpid-send and qpid-receive, that test can then be used to run either c++ or java based equivalents. One disagreement I may have here is that I think we should retain different names for the different implementations of qpid-send and qpid-receive. So I think we need to add an option to qpid-benchmark to not only set the path it uses to find them, but also the names of the executables it uses. An approach the works for the Java testing is to use profiles that set a bunch of related parameters and that can be switched as a whole. The reason I want to do this is that I want to move to a testing regime where we can run a specific build and use its install result (with probably a special testing tools install location) to run the subsequent test run. If we are to do this with multiple of the the qpid subtrees together, say c++ and java then it will be confusing if the *-send and *-receive executables have the same name. I wouldn't object to such an option. I'd be much less keen on renaming the existing c++ tests though. Since the java test scripts already use a different name, then renaming the python equivalents (which are rarely used at present) would then be all that was required. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On Fri, 2013-11-08 at 15:45 +, Gordon Sim wrote: On 11/08/2013 03:37 PM, Andrew Stitcher wrote: On Fri, 2013-11-08 at 11:43 +, Gordon Sim wrote: Since both the existing tests already import qpid.messaging this isn't actually imposing any significant extra dependency. There are also python equivalents of qpid-send and qpid-receive. Providing we keep the ability recently added to qpid-cpp-benchmark to specify the path to qpid-send and qpid-receive, that test can then be used to run either c++ or java based equivalents. One disagreement I may have here is that I think we should retain different names for the different implementations of qpid-send and qpid-receive. So I think we need to add an option to qpid-benchmark to not only set the path it uses to find them, but also the names of the executables it uses. An approach the works for the Java testing is to use profiles that set a bunch of related parameters and that can be switched as a whole. The reason I want to do this is that I want to move to a testing regime where we can run a specific build and use its install result (with probably a special testing tools install location) to run the subsequent test run. If we are to do this with multiple of the the qpid subtrees together, say c++ and java then it will be confusing if the *-send and *-receive executables have the same name. I wouldn't object to such an option. I'd be much less keen on renaming the existing c++ tests though. I agree - I tend to regard (somewhat chauvinistically I admit) the c++ qpid-send and qpid-receive as the default versions! Since the java test scripts already use a different name, then renaming the python equivalents (which are rarely used at present) would then be all that was required. That sounds good to me. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On Fri, Nov 8, 2013 at 10:54 AM, Andrew Stitcher astitc...@redhat.com wrote: The reason I want to do this is that I want to move to a testing regime where we can run a specific build and use its install result (with probably a special testing tools install location) to run the subsequent test run. If we are to do this with multiple of the the qpid subtrees together, say c++ and java then it will be confusing if the *-send and *-receive executables have the same name. I wouldn't object to such an option. I'd be much less keen on renaming the existing c++ tests though. I agree - I tend to regard (somewhat chauvinistically I admit) the c++ qpid-send and qpid-receive as the default versions! For what it's worth (and I wouldn't say it's worth much), I'd prefer renaming the C++ ones as well. I think it does a better job of telling the user what they're using, one of several variants of qpid-send or -receive. It would also leave space for introducing a simple wrapper with a parameter similar to the one proposed for qpid-benchmark: qpid-send --lang python|java|cpp. This would be a nicer way to expose the variants for testing. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5316) add paging-dir option to control location of page file for paged queues
Gordon Sim created QPID-5316: Summary: add paging-dir option to control location of page file for paged queues Key: QPID-5316 URL: https://issues.apache.org/jira/browse/QPID-5316 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5310) copy the correlationID into management replies
[ https://issues.apache.org/jira/browse/QPID-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817468#comment-13817468 ] ASF subversion and git services commented on QPID-5310: --- Commit 1540121 from [~tedross] in branch 'dispatch/trunk' [ https://svn.apache.org/r1540121 ] QPID-5310 - Added echoing of the correlation_id in management agent requests. - Since correlation_id may have multiple types, the field infrastructure was changed to allow for fields that hold the type tags so we don't need to write type-specific code for things like correlation_id. copy the correlationID into management replies -- Key: QPID-5310 URL: https://issues.apache.org/jira/browse/QPID-5310 Project: Qpid Issue Type: Bug Components: Qpid Dispatch Reporter: michael goulish Assignee: Ted Ross Replies to management messages need their correlation IDs so I can tell who is replying when I send management messages to multiple routers at once. I need to send management messages to multiple routers at once, because if I do it one-at-a-time and wait for a reply, and if one router is down, then I will hang for 60 seconds. ( 6e10 nsec ! ) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5310) copy the correlationID into management replies
[ https://issues.apache.org/jira/browse/QPID-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-5310. Resolution: Fixed Fix Version/s: Future copy the correlationID into management replies -- Key: QPID-5310 URL: https://issues.apache.org/jira/browse/QPID-5310 Project: Qpid Issue Type: Bug Components: Qpid Dispatch Reporter: michael goulish Assignee: Ted Ross Fix For: Future Replies to management messages need their correlation IDs so I can tell who is replying when I send management messages to multiple routers at once. I need to send management messages to multiple routers at once, because if I do it one-at-a-time and wait for a reply, and if one router is down, then I will hang for 60 seconds. ( 6e10 nsec ! ) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 15322: Add management interface to return the connections for a dispatch router
On Nov. 7, 2013, 9:51 p.m., Ted Ross wrote: This looks great! One thing I would change is the container attribute in the connections object. It should be the name of the remote container for the connection, not this container. We can add a container object to provide information about the local container. I don't see the linkage between the connection and the remote container's name? Is it available through the context or link_context? - Ernie --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15322/#review28453 --- On Nov. 7, 2013, 8:47 p.m., Ernie Allen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15322/ --- (Updated Nov. 7, 2013, 8:47 p.m.) Review request for qpid and Ted Ross. Repository: qpid Description --- Respond to a management request to display the list of connections for a dispatch router. The router responds with the following info for each connection: container - the name of the router handling the request state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat was updated to honor the -c command line switch. ./qdstat -c -b localhost:20001 container statehost port sasl role === QDR.A Operational 0.0.0.0 20002 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20003 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20004 ANONYMOUS inter-router Diffs - /dispatch/trunk/src/server.c 1538673 /dispatch/trunk/src/server_private.h 1538673 /dispatch/trunk/tools/src/py/qdstat 1538673 Diff: https://reviews.apache.org/r/15322/diff/ Testing --- Start a network of routers Display connections using qdstat -c for each router Verify connections match config file entries for each router Kill a router in the network Verify connections to the killed router are no longer listed Restart the killed router Verify connections to the restarted router are displayed Thanks, Ernie Allen
Re: Proposal to consolidate qpid benchmark tests
On Fri, 2013-11-08 at 11:15 -0500, Justin Ross wrote: On Fri, Nov 8, 2013 at 10:54 AM, Andrew Stitcher astitc...@redhat.com wrote: The reason I want to do this is that I want to move to a testing regime where we can run a specific build and use its install result (with probably a special testing tools install location) to run the subsequent test run. If we are to do this with multiple of the the qpid subtrees together, say c++ and java then it will be confusing if the *-send and *-receive executables have the same name. I wouldn't object to such an option. I'd be much less keen on renaming the existing c++ tests though. I agree - I tend to regard (somewhat chauvinistically I admit) the c++ qpid-send and qpid-receive as the default versions! For what it's worth (and I wouldn't say it's worth much), I'd prefer renaming the C++ ones as well. I think it does a better job of telling the user what they're using, one of several variants of qpid-send or -receive. I think there is a difference of mindset then. I view qpid-send/qpid-receive as generally useful utilities, that perhaps should be installed by default when we install qpid-clients. For simple enough cases they allow you to send/receive messages from the command line with no further tooling. And for this purpose on of the variants needs to be the default installed - I'd suggest the native code versions might be best suited. So keeping them called just qpid-send/receive works best for this. I'd certainly not object to installing links to them as part of the tests called qpid-cpp-send/receive. I think of the current set of test executables they are the only ons that qualify to be generally useful. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5314) Don't include full path for paging file in paged queue exceptions
[ https://issues.apache.org/jira/browse/QPID-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817502#comment-13817502 ] ASF subversion and git services commented on QPID-5314: --- Commit 1540137 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1540137 ] QPID-5314: exceptions should not contain full path for paging file Don't include full path for paging file in paged queue exceptions - Key: QPID-5314 URL: https://issues.apache.org/jira/browse/QPID-5314 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5312) Paged queue does not deliver all messages
[ https://issues.apache.org/jira/browse/QPID-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817501#comment-13817501 ] ASF subversion and git services commented on QPID-5312: --- Commit 1540136 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1540136 ] QPID-5312: make sure page is loaded before attempting to find message in it Paged queue does not deliver all messages - Key: QPID-5312 URL: https://issues.apache.org/jira/browse/QPID-5312 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 In particular when either max-pages-loaded is 1 or when selectors are used. The problem in both cases is where the head of the queue is not loaded when a new subscription comes in, and the logic doesn't recognise this and load the page, but rather just assumes there is nothing in it. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On Fri, Nov 8, 2013 at 12:21 PM, Andrew Stitcher astitc...@redhat.com wrote: For what it's worth (and I wouldn't say it's worth much), I'd prefer renaming the C++ ones as well. I think it does a better job of telling the user what they're using, one of several variants of qpid-send or -receive. I think there is a difference of mindset then. I view qpid-send/qpid-receive as generally useful utilities, that perhaps should be installed by default when we install qpid-clients. For simple enough cases they allow you to send/receive messages from the command line with no further tooling. And for this purpose on of the variants needs to be the default installed - I'd suggest the native code versions might be best suited. So keeping them called just qpid-send/receive works best for this. I'd certainly not object to installing links to them as part of the tests called qpid-cpp-send/receive. I think of the current set of test executables they are the only ons that qualify to be generally useful. Yes, I do think they're primarily for testing. Not narrow testing, but rather the kinds of one-off testing that end users might do when troubleshooting. Since the client may have as much part as the server in such troubleshooting, the language involved is still important, according to this view, and should be visible. I'm all for a default. If we had a qpid-send facade, I'd see no problem with defaulting the impl lang to C++. I just think it's slightly better to avoid obscuring the language: going with qpid-send, qpid-java-send, and qpid-python-send leaves the user to guess what that first one is. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 15353: Add --paging-dir broker option
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15353/ --- Review request for qpid. Bugs: QPID-5316 https://issues.apache.org/jira/browse/QPID-5316 Repository: qpid Description --- Adds a new option as suggested on user list, in order to control where the paging files go speartely from the other data-dir stuff. Diffs - /trunk/qpid/cpp/src/qpid/DataDir.h 1540138 /trunk/qpid/cpp/src/qpid/DataDir.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/QueueFactory.cpp 1540138 Diff: https://reviews.apache.org/r/15353/diff/ Testing --- Thanks, Gordon Sim
[jira] [Commented] (QPID-5315) paging out of memory loses persistence id for messages
[ https://issues.apache.org/jira/browse/QPID-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817503#comment-13817503 ] ASF subversion and git services commented on QPID-5315: --- Commit 1540138 from [~gsim] in branch 'qpid/trunk' [ https://svn.apache.org/r1540138 ] QPID-5315: record persistence ids in paging file so they can be restored after paging out paging out of memory loses persistence id for messages -- Key: QPID-5315 URL: https://issues.apache.org/jira/browse/QPID-5315 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 Meaning that attempt to dequeue fails with 'Dequeuing message with null persistence Id.' error. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5316) add paging-dir option to control location of page file for paged queues
[ https://issues.apache.org/jira/browse/QPID-5316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817505#comment-13817505 ] Gordon Sim commented on QPID-5316: -- Patch available for review: https://reviews.apache.org/r/15353/ add paging-dir option to control location of page file for paged queues --- Key: QPID-5316 URL: https://issues.apache.org/jira/browse/QPID-5316 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.24 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.25 -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On 11/08/2013 05:44 PM, Justin Ross wrote: I'm all for a default. If we had a qpid-send facade, I'd see no problem with defaulting the impl lang to C++. I just think it's slightly better to avoid obscuring the language: going with qpid-send, qpid-java-send, and qpid-python-send leaves the user to guess what that first one is. The 'first one' is the only one that is actually in use at present and has been for some time. I think the confusion is at present purely hypothetical. The inconvenience caused by renaming the current qpid-send/qpid-receive would however be real (and did I mention these are the only ones in actual use :-). - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 15353: Add --paging-dir broker option
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15353/#review28552 --- /trunk/qpid/cpp/src/qpid/DataDir.cpp https://reviews.apache.org/r/15353/#comment55351 I'm not sure I see the need for changing the DataDir class: Can't you just make the pagingDir another instance of a DataDir? /trunk/qpid/cpp/src/qpid/DataDir.cpp https://reviews.apache.org/r/15353/#comment55350 I think moving the code to actually create the data directory into the create lockfile code isn't the correct division of functionality. - Andrew Stitcher On Nov. 8, 2013, 5:44 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15353/ --- (Updated Nov. 8, 2013, 5:44 p.m.) Review request for qpid. Bugs: QPID-5316 https://issues.apache.org/jira/browse/QPID-5316 Repository: qpid Description --- Adds a new option as suggested on user list, in order to control where the paging files go speartely from the other data-dir stuff. Diffs - /trunk/qpid/cpp/src/qpid/DataDir.h 1540138 /trunk/qpid/cpp/src/qpid/DataDir.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/QueueFactory.cpp 1540138 Diff: https://reviews.apache.org/r/15353/diff/ Testing --- Thanks, Gordon Sim
Re: Review Request 15322: Add management interface to return the connections for a dispatch router
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15322/ --- (Updated Nov. 8, 2013, 6:28 p.m.) Review request for qpid and Ted Ross. Changes --- - Changed key from container to address for consistency with other requests - Changed to remote container name for address - Changed qdstat - renamed sasl to sasl-mechanisms - Changed qdstat - put address after port ./qdstat -c -b localhost:20001 statehost port address sasl-mechanisms role = Operational 0.0.0.0 20002 QDR.BANONYMOUSinter-router Operational 0.0.0.0 20004 QDR.DANONYMOUSinter-router Operational 0.0.0.0 20003 QDR.CANONYMOUSinter-router Repository: qpid Description --- Respond to a management request to display the list of connections for a dispatch router. The router responds with the following info for each connection: container - the name of the router handling the request state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat was updated to honor the -c command line switch. ./qdstat -c -b localhost:20001 container statehost port sasl role === QDR.A Operational 0.0.0.0 20002 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20003 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20004 ANONYMOUS inter-router Diffs (updated) - /dispatch/trunk/src/server.c 1538673 /dispatch/trunk/src/server_private.h 1538673 /dispatch/trunk/tools/src/py/qdstat 1538673 Diff: https://reviews.apache.org/r/15322/diff/ Testing --- Start a network of routers Display connections using qdstat -c for each router Verify connections match config file entries for each router Kill a router in the network Verify connections to the killed router are no longer listed Restart the killed router Verify connections to the restarted router are displayed Thanks, Ernie Allen
[jira] [Commented] (QPID-5307) Change test scripts to cross-platform language
[ https://issues.apache.org/jira/browse/QPID-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817590#comment-13817590 ] Steve Huston commented on QPID-5307: I agree - #2 is better from my point of view, As far as organizing how this all gets done... maybe add a comment here when you start working on a script? Alan, do you have time to convert one test to python we can use as an example? Change test scripts to cross-platform language -- Key: QPID-5307 URL: https://issues.apache.org/jira/browse/QPID-5307 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client, C++ Clustering Reporter: Steve Huston Assignee: Steve Huston Labels: test Fix For: Future The C++ tree's test suite drivers are primarily shell scripts. Many were duplicated as Windows PowerShell scripts along the way. However, not all scripts were PowerShell-ized, and the dual set of test scripts is not maintained in sync. Someone (Cliff?) suggested a while back that the test driver scripts be written in a common language across Linux and Windows, and for other platforms as well. Python, Perl, Ruby are all possible choices - python and ruby need to be on build systems anyway for code generation. What do people think about a) this idea in general, b) language to use? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 15273: support autodeleted exchanges
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15273/#review28562 --- This needs a bit more of HA work. Need to keep exchange it in memory on the backup until deleted by primary or backup is promoted. See markInUse/releaseFromUse in QueueReplicator::QueueReplicator BrokerReplicator::disconnectedExchange to see how this was done for Queues. The issue is: - Prevent race conditions: backup must not auto-delete before primary does. - Re-enable auto-delete semantics when the backup is disconnected from primary. (disconnectExchange is badly named - should be disconnectQueueReplicator as in this context its secondary that QRs are also exchanges.) - Alan Conway On Nov. 6, 2013, 5:50 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15273/ --- (Updated Nov. 6, 2013, 5:50 p.m.) Review request for qpid. Bugs: QPID-5301 https://issues.apache.org/jira/browse/QPID-5301 Repository: qpid Description --- Exchanges can now be set to be autodeleted. For 0-10 this means they are deleted as soon as the binding count drops to 0 (this does mean that an existing sender to that exchange will get an error on the next message they try to send, but this is as the spec dictates and there is no good way to track a sender in 0-10). For 1.0 there is an additional constraint that there are no active sender links to the exchange. Diffs - /trunk/qpid/cpp/src/qpid/broker/Broker.h 1538754 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/DirectExchange.h 1538754 /trunk/qpid/cpp/src/qpid/broker/DirectExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/Exchange.h 1538754 /trunk/qpid/cpp/src/qpid/broker/Exchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/ExchangeRegistry.h 1538754 /trunk/qpid/cpp/src/qpid/broker/ExchangeRegistry.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/FanOutExchange.h 1538754 /trunk/qpid/cpp/src/qpid/broker/FanOutExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/HeadersExchange.h 1538754 /trunk/qpid/cpp/src/qpid/broker/HeadersExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/Link.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/SessionAdapter.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/TopicExchange.h 1538754 /trunk/qpid/cpp/src/qpid/broker/TopicExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/amqp/NodeProperties.h 1538754 /trunk/qpid/cpp/src/qpid/broker/amqp/NodeProperties.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/amqp/Session.cpp 1538754 /trunk/qpid/cpp/src/qpid/broker/amqp/Topic.cpp 1538754 /trunk/qpid/cpp/src/qpid/ha/BrokerReplicator.h 1538754 /trunk/qpid/cpp/src/qpid/ha/BrokerReplicator.cpp 1538754 /trunk/qpid/cpp/src/qpid/ha/FailoverExchange.h 1538754 /trunk/qpid/cpp/src/qpid/ha/FailoverExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/ha/PrimaryTxObserver.cpp 1538754 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.h 1538754 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1538754 /trunk/qpid/cpp/src/qpid/management/ManagementDirectExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/management/ManagementTopicExchange.h 1538754 /trunk/qpid/cpp/src/qpid/management/ManagementTopicExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/xml/XmlExchange.h 1538754 /trunk/qpid/cpp/src/qpid/xml/XmlExchange.cpp 1538754 /trunk/qpid/cpp/src/qpid/xml/XmlExchangePlugin.cpp 1538754 /trunk/qpid/cpp/src/tests/ExchangeTest.cpp 1538754 /trunk/qpid/cpp/src/tests/legacystore/SimpleTest.cpp 1538754 /trunk/qpid/cpp/src/tests/misc.py 1538754 /trunk/qpid/java/test-profiles/python_tests/Java010PythonExcludes 1538754 /trunk/qpid/tests/src/py/qpid_tests/broker_0_10/exchange.py 1538754 Diff: https://reviews.apache.org/r/15273/diff/ Testing --- Added tests for autodelete and all existing tests pass. Thanks, Gordon Sim
Re: Review Request 15322: Add management interface to return the connections for a dispatch router
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15322/#review28563 --- Ship it! This is an improvement. The only change you should make is to replace address with container (like it was before). Calling the container name an address overloads the term too much. Please raise a Jira against Qpid (component Qpid Dispatch) and attach the patch. - Ted Ross On Nov. 8, 2013, 6:28 p.m., Ernie Allen wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15322/ --- (Updated Nov. 8, 2013, 6:28 p.m.) Review request for qpid and Ted Ross. Repository: qpid Description --- Respond to a management request to display the list of connections for a dispatch router. The router responds with the following info for each connection: container - the name of the router handling the request state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat was updated to honor the -c command line switch. ./qdstat -c -b localhost:20001 container statehost port sasl role === QDR.A Operational 0.0.0.0 20002 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20003 ANONYMOUS inter-router QDR.A Operational 0.0.0.0 20004 ANONYMOUS inter-router Diffs - /dispatch/trunk/src/server.c 1538673 /dispatch/trunk/src/server_private.h 1538673 /dispatch/trunk/tools/src/py/qdstat 1538673 Diff: https://reviews.apache.org/r/15322/diff/ Testing --- Start a network of routers Display connections using qdstat -c for each router Verify connections match config file entries for each router Kill a router in the network Verify connections to the killed router are no longer listed Restart the killed router Verify connections to the restarted router are displayed Thanks, Ernie Allen
Re: Proposal to consolidate qpid benchmark tests
Qpid-send (cpp) and qpid-jms-send use slightly different options, it seems to me it is best to add -l lang option to the driver, and then use correct method/options. It will not require renaming, nor passing method name as another argument. Regards, Irina. - Original Message - From: Gordon Sim g...@redhat.com To: dev@qpid.apache.org Sent: Friday, November 8, 2013 12:54:14 PM Subject: Re: Proposal to consolidate qpid benchmark tests On 11/08/2013 05:44 PM, Justin Ross wrote: I'm all for a default. If we had a qpid-send facade, I'd see no problem with defaulting the impl lang to C++. I just think it's slightly better to avoid obscuring the language: going with qpid-send, qpid-java-send, and qpid-python-send leaves the user to guess what that first one is. The 'first one' is the only one that is actually in use at present and has been for some time. I think the confusion is at present purely hypothetical. The inconvenience caused by renaming the current qpid-send/qpid-receive would however be real (and did I mention these are the only ones in actual use :-). - 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
[jira] [Commented] (QPID-5307) Change test scripts to cross-platform language
[ https://issues.apache.org/jira/browse/QPID-5307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817626#comment-13817626 ] Alan Conway commented on QPID-5307: --- Yes, I'll get something in next week. Change test scripts to cross-platform language -- Key: QPID-5307 URL: https://issues.apache.org/jira/browse/QPID-5307 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client, C++ Clustering Reporter: Steve Huston Assignee: Steve Huston Labels: test Fix For: Future The C++ tree's test suite drivers are primarily shell scripts. Many were duplicated as Windows PowerShell scripts along the way. However, not all scripts were PowerShell-ized, and the dual set of test scripts is not maintained in sync. Someone (Cliff?) suggested a while back that the test driver scripts be written in a common language across Linux and Windows, and for other platforms as well. Python, Perl, Ruby are all possible choices - python and ruby need to be on build systems anyway for code generation. What do people think about a) this idea in general, b) language to use? -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
On Fri, 2013-11-08 at 14:24 -0500, Irina Boverman wrote: Qpid-send (cpp) and qpid-jms-send use slightly different options, it seems to me it is best to add -l lang option to the driver, and then use correct method/options. It will not require renaming, nor passing method name as another argument. It seems to me that it would make more sense to change the different programs to have the same options. Or at least to have a common subset of options that can be used by the benchmark/interop tester. It makes much more sense to me from an engineering perspective to define/accept a common interface to the programs than to add a bunch of special cases to the driving program. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5317) Valgrind detects leaks in legacystore_OrderingTest unit test program
Andrew Stitcher created QPID-5317: - Summary: Valgrind detects leaks in legacystore_OrderingTest unit test program Key: QPID-5317 URL: https://issues.apache.org/jira/browse/QPID-5317 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.25 Environment: Unix Reporter: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5317) Valgrind detects leaks in legacystore_OrderingTest unit test program
[ https://issues.apache.org/jira/browse/QPID-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-5317: -- Attachment: legacystore_OrderingTest.vglog Attached the valgrind failure log. It seems that strings are being leaked somehow. Valgrind detects leaks in legacystore_OrderingTest unit test program Key: QPID-5317 URL: https://issues.apache.org/jira/browse/QPID-5317 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.25 Environment: Unix Reporter: Andrew Stitcher Attachments: legacystore_OrderingTest.vglog -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5318) HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name'
Alan Conway created QPID-5318: - Summary: HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name' Key: QPID-5318 URL: https://issues.apache.org/jira/browse/QPID-5318 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.24 Reporter: Alan Conway Assignee: Alan Conway Running ha_tests.py, tests occasionally fail with AttributeError: 'NoneType' object has no attribute 'name' -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5320) Need to avoid python_test timing out and causing erronous test failures
Andrew Stitcher created QPID-5320: - Summary: Need to avoid python_test timing out and causing erronous test failures Key: QPID-5320 URL: https://issues.apache.org/jira/browse/QPID-5320 Project: Qpid Issue Type: Improvement Affects Versions: 0.25 Reporter: Andrew Stitcher Having started running automated test runs, a common failure that is occurring in various places is that the python_test run times out after 25 mins (1500s) whilst seemingly still making progress. This has happened on underpowered and highly loaded machines, but doesn't happen on individual developer machines because they tend to be fast machines and not to be overloaded when running builds. Tactically to avoid this issue we probably just need to split the test up into a few shorter test runs. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5319) Add ability to get list of connections through server management agent
Ernest Allen created QPID-5319: -- Summary: Add ability to get list of connections through server management agent Key: QPID-5319 URL: https://issues.apache.org/jira/browse/QPID-5319 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Affects Versions: Future Reporter: Ernest Allen Add a management agent handler that will return a list of connections. The following info should be returned: state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container container - the name of the remote connection container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat should also be updated with a -c command line switch. ./qdstat -c -b localhost:20001 Connections statehost port container sasl-mechanisms role === Operational 0.0.0.0 20002 QDR.B ANONYMOUSinter-router Operational 0.0.0.0 20003 QDR.C ANONYMOUSinter-router Operational 0.0.0.0 20004 QDR.D ANONYMOUSinter-router -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5318) HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name'
[ https://issues.apache.org/jira/browse/QPID-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817646#comment-13817646 ] ASF subversion and git services commented on QPID-5318: --- Commit 1540171 from [~aconway] in branch 'qpid/trunk' [ https://svn.apache.org/r1540171 ] QPID-5318: HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name' This was due to a race condition where a session was deleted while the QmfAgent was looking it up. HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name' --- Key: QPID-5318 URL: https://issues.apache.org/jira/browse/QPID-5318 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.24 Reporter: Alan Conway Assignee: Alan Conway Running ha_tests.py, tests occasionally fail with AttributeError: 'NoneType' object has no attribute 'name' -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Proposal to consolidate qpid benchmark tests
+1 from me on that train of thought. I think that we should aspire wherever possible to maximise cohesion, there has been a lot of divergence for various reasons but I think with the increased moves to modularisation it's time to draw a line in the sand and try to bring things together again. On 08/11/13 19:59, Andrew Stitcher wrote: It makes much more sense to me from an engineering perspective to define/accept a common interface to the programs than to add a bunch of special cases to the driving program. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: svn commit: r1539510 - in /qpid/trunk/qpid/cpp/src/tests: ./ legacystore/
On Fri, 2013-11-08 at 10:05 -0500, Andrew Stitcher wrote: On Fri, 2013-11-08 at 11:23 +, Gordon Sim wrote: ... This triggers a test failure: legacystore_OrderingTest Sadly, it just exposes a test failure that was latent before as a leak detected by valgrind. [previously valgrind wasn't actually being run on the legacystore tests] It's on my list to jira. Reported: QPID-5317 Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5318) HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name'
[ https://issues.apache.org/jira/browse/QPID-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-5318. --- Resolution: Fixed HA tests fail sporadically with AttributeError: 'NoneType' object has no attribute 'name' --- Key: QPID-5318 URL: https://issues.apache.org/jira/browse/QPID-5318 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.24 Reporter: Alan Conway Assignee: Alan Conway Running ha_tests.py, tests occasionally fail with AttributeError: 'NoneType' object has no attribute 'name' -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5319) Add ability to get list of connections through server management agent
[ https://issues.apache.org/jira/browse/QPID-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated QPID-5319: --- Attachment: dispatch.connectors.diff3 Modified server to maintain a list of connections. Added management agent handler on the server to return the requested info about the connections. Modified qdstat python tool to request and display the connections list. Add ability to get list of connections through server management agent -- Key: QPID-5319 URL: https://issues.apache.org/jira/browse/QPID-5319 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Affects Versions: Future Reporter: Ernest Allen Attachments: dispatch.connectors.diff3 Add a management agent handler that will return a list of connections. The following info should be returned: state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container container - the name of the remote connection container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat should also be updated with a -c command line switch. ./qdstat -c -b localhost:20001 Connections statehost port container sasl-mechanisms role === Operational 0.0.0.0 20002 QDR.B ANONYMOUSinter-router Operational 0.0.0.0 20003 QDR.C ANONYMOUSinter-router Operational 0.0.0.0 20004 QDR.D ANONYMOUSinter-router -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5319) Add ability to get list of connections through server management agent
[ https://issues.apache.org/jira/browse/QPID-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-5319: -- Assignee: Ted Ross Add ability to get list of connections through server management agent -- Key: QPID-5319 URL: https://issues.apache.org/jira/browse/QPID-5319 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Affects Versions: Future Reporter: Ernest Allen Assignee: Ted Ross Attachments: dispatch.connectors.diff3 Add a management agent handler that will return a list of connections. The following info should be returned: state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container container - the name of the remote connection container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat should also be updated with a -c command line switch. ./qdstat -c -b localhost:20001 Connections statehost port container sasl-mechanisms role === Operational 0.0.0.0 20002 QDR.B ANONYMOUSinter-router Operational 0.0.0.0 20003 QDR.C ANONYMOUSinter-router Operational 0.0.0.0 20004 QDR.D ANONYMOUSinter-router -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5319) Add ability to get list of connections through server management agent
[ https://issues.apache.org/jira/browse/QPID-5319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817773#comment-13817773 ] Ted Ross commented on QPID-5319: I tested this patch with two routers connected together. If I look at the connections on one router, I see a connection to the other. If I look at the other, I see no connections. If repeatedly invoke qdstat -c, the connections eventually disappear. Also, I never see the connection that comes from qdstat itself. Add ability to get list of connections through server management agent -- Key: QPID-5319 URL: https://issues.apache.org/jira/browse/QPID-5319 Project: Qpid Issue Type: Improvement Components: Qpid Dispatch Affects Versions: Future Reporter: Ernest Allen Assignee: Ted Ross Attachments: dispatch.connectors.diff3 Add a management agent handler that will return a list of connections. The following info should be returned: state - the state of the connection (Connecting, Opening, Operational, Failed, User) host - the host of the connection's container port - the post of the connection's container container - the name of the remote connection container sasl - the sasl mechanism list of the connection's container role - the role of the connection's container tools/src/py/qdstat should also be updated with a -c command line switch. ./qdstat -c -b localhost:20001 Connections statehost port container sasl-mechanisms role === Operational 0.0.0.0 20002 QDR.B ANONYMOUSinter-router Operational 0.0.0.0 20003 QDR.C ANONYMOUSinter-router Operational 0.0.0.0 20004 QDR.D ANONYMOUSinter-router -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5321) qpid-tool doesn't properly display exceptions which occurred when calling some methods
JAkub Scholz created QPID-5321:
--
Summary: qpid-tool doesn't properly display exceptions which
occurred when calling some methods
Key: QPID-5321
URL: https://issues.apache.org/jira/browse/QPID-5321
Project: Qpid
Issue Type: Bug
Components: C++ Broker
Affects Versions: 0.25
Reporter: JAkub Scholz
Priority: Minor
When an exception occurs during a call of some method from qpid-tool, the
actual exception is not displayed:
qpid: call 152 purge 0
{filter_type:header_match_str,filter_params:{header_key:status,header_value:suda}}
*Exception in do_call: %r*
intstead of:
qpid: call 152 purge 0
{filter_type:header_match_str,filter_params:{header_key:status,header_value:licha}}
*Exception in do_call: Timeout()*
This is because when the exception is catched in the do_call method, it doesn't
format the printed statement properly, because a , is used as a separator
instead of %.
I would attach a patch, but since it is just one character change, it does't
seem necessary:
Index: src/py/qpid-tool
===
--- src/py/qpid-tool(revision 1540216)
+++ src/py/qpid-tool(working copy)
@@ -144,7 +144,7 @@
try:
self.dataObject.do_call(data)
except Exception, e:
- print Exception in do_call: %r, e
+ print Exception in do_call: %r % e
def do_EOF(self, data):
print quit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5322) Allow changes to the queue paging configuration, especially the qpid.max_pages_loaded argument
JAkub Scholz created QPID-5322: -- Summary: Allow changes to the queue paging configuration, especially the qpid.max_pages_loaded argument Key: QPID-5322 URL: https://issues.apache.org/jira/browse/QPID-5322 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.25 Reporter: JAkub Scholz When a queue is configured to use paging, the values used when the queue is created are fixed. IT is not possible to modify them later without dropping the queue and creating a new one and that isn't exactly comfortable, especially when the queue contains some messages. It would be therefore nice to have a possibility to change some attributes of the existing queue - either on the go when the broker is running or at least when the broker is switched off (similarly to the queue journal files resizing utility). Obviously, it might not be possible to decrease the qpid.page_factor option if the queue already contains some messages bigger then the new page size. But changing the value of the qpid.max_pages_loaded might be relatively straight forward, especially when the broker is switched off, because the paging file is recreated during the broker startup. The possibility to change the qpid.max_pages_loaded parameter is important. If your broker runs out of memory because its queues contain too many messages it will crash. Right now, there is often no solution, because if you restart the broker it will run out of memory again before you get it online. But with the possibility to change the qpid.max_pages_loaded, you would be able to decrease the amount of used memory after it crashed and thus start the broker again (of course as long as you have been using paged queues already before). -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5323) Provide some statistics about the use of the queue paging
JAkub Scholz created QPID-5323: -- Summary: Provide some statistics about the use of the queue paging Key: QPID-5323 URL: https://issues.apache.org/jira/browse/QPID-5323 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.25 Reporter: JAkub Scholz When the queue paging is enabled, there are no statistics available about the utilization of the paging. In my opinion it might be useful to know some details about the queue paging as for example: - How many pages are kept in memory - How many messages are kept in memory - How many pages are already offloaded to the disk - How many messages are already offloaded to the disk These statistics can be provided for example per QMF together with all other queue statistics, so that users can display them with qpid-tool or qpid-config. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 15353: Add --paging-dir broker option
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15353/#review28601 --- I can't really comment on the code. But as far as the functionality goes it works exactly as I expected. - Jakub Scholz On Nov. 8, 2013, 5:44 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15353/ --- (Updated Nov. 8, 2013, 5:44 p.m.) Review request for qpid. Bugs: QPID-5316 https://issues.apache.org/jira/browse/QPID-5316 Repository: qpid Description --- Adds a new option as suggested on user list, in order to control where the paging files go speartely from the other data-dir stuff. Diffs - /trunk/qpid/cpp/src/qpid/DataDir.h 1540138 /trunk/qpid/cpp/src/qpid/DataDir.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.h 1540138 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1540138 /trunk/qpid/cpp/src/qpid/broker/QueueFactory.cpp 1540138 Diff: https://reviews.apache.org/r/15353/diff/ Testing --- Thanks, Gordon Sim
