Re: Errors building trunk?
On 01/05/2010 06:54 PM, Steve Huston wrote: Hi Kerry, Thought I'd mention this - I get some errors building a clean trunk on Ubuntu and Windows. On Windows, I'm running VC9 SP1 on XP (fully patched), CMake 2.8.0, boost 1.3.9 against r896143, clean checkout. cpp\src\qmf\engine\ResilientConnection.cpp gives me an error on line 416, 'write not a member of global namespace'. This causes qmfengine build to fail. This is a known issue; see QPID-1982 (https://issues.apache.org/jira/browse/QPID-1982) On Ubuntu, (my first build attempt there), Ubuntu x64, gcc 4.4.1, boost 1.40.0.cmake2, against r895713, clean checkout. cpp/src/qpid/broker/SaslAuthenticator.cpp line 26 gives me error 'type qualifiers ignored on function return type'. Is that definitely the right line number? I can't see where the problem might be... I'm not intimately familiar with this, but it sounds like a warning that could be ignored; you may get further by turning off the warnings-to-errors switch. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
On 01/04/2010 04:27 PM, Robert Godfrey wrote: Happy New Year all... So, at the start of this new year I think it is important that we try to focus on improving the experience of our project... and in particular I think we should be looking at making the project look like a single coherent whole. I agree, that is a valuable goal. Currently the Java and C++ Brokers look and behave almost completely differently, and I think we all should be trying hard to remedy that situation. The first step in my grand plan to fix this was obviously implementing AMQP 0-10 The next task I set myself was to investigate how we can use a single set of management and configuration tools across the two brokers such that the user experience is common. To that end I have spent the last couple of weeks implementing a prototype QMF management layer in the Java Broker, attempting to use the same management schema as used by the C++ broker. Further I have implemented the required methods to enable federation between Java and C++ (and to use the same tools to set it up) - both static and dynamic routing has been implemented. Excellent, thanks for your hard work! (I feel suitably embarrassed having spent the last two weeks eating and sleeping!) Once trunk is unfrozen I will be able to apply my patch that provides for qpid-tool, qpid-route et. al to work against the Java Broker. In implementing QMF Management and Federation I have come up against a number of obstacles caused by assumptions built in to the QMF management schema that are based on the behaviour of the C++ broker (e.g. that it doesn't support multiple vhosts), I also have a number of questions/comments on the schema as a whole. I've collected all these on the following wiki page: http://cwiki.apache.org/confluence/display/qpid/Broker+Management+QMF+Coverage I would be grateful if those familiar with the C++ broker and it's management could answer some of the questions therein... Further I would like to get feedback on my comments and suggestions for additions to the management capabilities. From those more familiar with the Java management capabilities - a review to point out any other capabilities that cannot be carried out through QMF would be very helpful. In terms of next steps in uniting the user experience: 1) I think we need to collectively agree on how we can update the management schema to work fully with the Java Broker and hopefully to expand its coverage to that it encompasses everything that can currently be performed by the Java JMX management solution. 2) I will be trying to put together a wiki page of all the extensions to AMQP that the brokers currently implement (e.g. arguments to queue/exchange declare, bind,subscribe, etc...). ultimately we should try to unify these as well - and also to define a mechanism so that clients can detect on connection which extensions are available. Beyond the configuration and management work I've started already, the biggest gap is probably ACLs - and I've not looked at all at that yet. Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. Your thoughts? Thanks for taking the lead on this! I think this would greatly benefit to the Qpid community. (I have filled in some detail on the c++ extensions and added a few comments/answers on the management coverage page to begin with). --Gordon. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Test suite vs optional xml config
On 01/04/2010 06:41 PM, john dunning wrote: I'm squiffing up qpid-config to add the ability to configure xml exchanges and queue bindings. I'm trying to add stuff to the test suite (cpp/src/tests/cli_tests.py and related) to match. The difficulty I have right now is that the xml support is optional. If you didn't configure for xml and load the module when you started the broker, you don't get xml support, and my test case flames out. It's not too hard to make the wrapper script (run_cli_tests) sense the presence of the module and only optionally add the --load-module arg. Presumably something analogous could be done on windows as well. It's less clear to me how to make the test code sense that the environment is sans-xml and DTRT. Possibilities which come to mind: 1. Trap the error (about xml being unhandled) and ignore it 2. Move the xml test out into a separate module, and only invoke it if we're configured the right way. 3. Interrogate the broker to ask him if he does xml (is this even possible?) Anybody care to express an opinion on the cleanest way to make the test suite seamlessly accomodate xml support? TIA... Just a suggestion: The run_cli_tests script uses the qpid-python-test tool which allows an ignore file to be specified. So you could detect the availability of the module and load it if available as you say, and if not available specify an ignore file that excludes the xml exchange related tests. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797080#action_12797080 ] Gordon Sim commented on QPID-2104: -- The property used as the key should ideally be configurable also. Improved LVQ implementation --- Key: QPID-2104 URL: https://issues.apache.org/jira/browse/QPID-2104 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.5 Reporter: Gordon Sim Assignee: Gordon Sim My view of what ideal 'LVQ' behaviour whould be like is that the 'queue' would really be more like a 'topic' where the last message for each key was always saved. Clients would subscribe to it and receive the last message published for each key and subsequently any updates (i.e. any new messages). I.e. the consumers are always non-competing. Rob Godfrey also points out that if subscribers fall behind they need only be sent the latest for every key (i.e. any superceded values can be skipped). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2325) [Java Broker] SASL PLAIN authentication does not work when both an authentication and authorization id are supplied
[Java Broker] SASL PLAIN authentication does not work when both an authentication and authorization id are supplied --- Key: QPID-2325 URL: https://issues.apache.org/jira/browse/QPID-2325 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Rob Godfrey Fix For: 0.7 The SASL PLAIN server in the Java Broker incorrectly constructed the String representing the authentication id if there was both an authorisation and authentication id present (it was calling the String constructor as if it were (src, start, end, encoding) rather than (src, start, *length*, encoding) This prevented C++ clients connecting with PLAIN as the SASL mechanism -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
SWIG Bindings Test Failure
Hello! On current trunk (r896256) I am getting this error after compiling --with-swig (see attachment) and running 'make check'. Best regards, Jan Sarenik make[3]: Entering directory `/home/jsarenik/qpid/qpid/cpp/bindings/qmf/tests' Running qmf interop tests using broker on port 40430 Python Agent (external storage) vs. Pure-Python Console Python agent started at pid 8660 2010-01-06 14:19:52 notice Initial object-id bank assigned: 1.10 python_console.QmfInteropTests.test_A_agent_presence pass python_console.QmfInteropTests.test_B_basic_method_invocation ... pass python_console.QmfInteropTests.test_C_basic_types_numeric_big ... pass python_console.QmfInteropTests.test_C_basic_types_numeric_negative .. pass python_console.QmfInteropTests.test_C_basic_types_numeric_small . pass python_console.QmfInteropTests.test_D_get_by_object_id .. pass python_console.QmfInteropTests.test_E_filter_by_object_id ... pass Totals: 7 tests, 7 passed, 0 skipped, 0 ignored, 0 failed Ruby Agent (external storage) vs. Pure-Python Console Ruby agent started at pid 8700 Agent Connection Established... 2010-01-06 14:20:00 notice Initial object-id bank assigned: 1.11 python_console.QmfInteropTests.test_A_agent_presence pass python_console.QmfInteropTests.test_B_basic_method_invocation ... pass python_console.QmfInteropTests.test_C_basic_types_numeric_big ... pass python_console.QmfInteropTests.test_C_basic_types_numeric_negative .. pass python_console.QmfInteropTests.test_C_basic_types_numeric_small . pass python_console.QmfInteropTests.test_D_get_by_object_id .. pass python_console.QmfInteropTests.test_E_filter_by_object_id ... pass Totals: 7 tests, 7 passed, 0 skipped, 0 ignored, 0 failed Ruby Agent (external storage) vs. Ruby Console Console Connection Established... test_A_agent_presence... Pass test_A_connection_settings... Pass test_B_basic_method_invocation... Pass test_C_basic_types_map... Pass test_C_basic_types_numeric_big... Pass test_C_basic_types_numeric_negative... Pass test_C_basic_types_numeric_small... Pass test_C_basic_types_string_long... Pass test_C_basic_types_string_short... Pass test_D_get_by_object_id... Pass test_D_get_with_agent... Pass test_D_userid_for_method... Fail: Assertion failed: != anonymous test_E_filter_by_object_id... Pass FAIL qmf interop tests (Ruby Console/Ruby Agent) Python Agent (external storage) vs. Ruby Console Console Connection Established... 2010-01-06 14:20:12 notice Initial object-id bank assigned: 1.12 test_A_agent_presence... Pass test_A_connection_settings... Pass test_B_basic_method_invocation... Pass test_C_basic_types_map... Pass test_C_basic_types_numeric_big... Pass test_C_basic_types_numeric_negative... Pass test_C_basic_types_numeric_small... Pass test_C_basic_types_string_long... Pass test_C_basic_types_string_short... Pass test_D_get_by_object_id... Pass test_D_get_with_agent... Pass test_D_userid_for_method... Fail: Assertion failed: != anonymous test_E_filter_by_object_id... Pass FAIL qmf interop tests (Ruby Console/Python Agent) Broker stopped TEST FAILED! FAIL: run_interop_tests 1 of 1 test failed Please report to dev@qpid.apache.org make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/jsarenik/qpid/qpid/cpp/bindings/qmf/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/jsarenik/qpid/qpid/cpp/bindings/qmf/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/jsarenik/qpid/qpid/cpp/bindings/qmf' make: *** [check-recursive] Error 1 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: SWIG Bindings Test Failure
On Wed, Jan 06, 2010 at 09:19:57AM -0500, Ted Ross wrote: The problem is that you've built without the cyrus-sasl-devel. The client in that test tries to set the user-id header with information extracted from the sasl context (which isn't there). This test should be disabled in the --without-sasl case. Exactly. After recompilation with SASL, the test finishes successfully. Thank you! Best regards, Jan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [RESULT] [VOTE] Committership Criteria
On Fri, 2009-12-18 at 12:48 -0500, Rafael Schloming wrote: Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. - A candidate must communicate openly about work planned/in-progress. - A candidate must demonstrate expertise in a significant area of the existing code base. - A candidate must demonstrate an extended commitment to the project. Tests for these qualities: - contacting the right team members to discuss changes - actively soliciting feedback for significant changes or new development - multiple independent contributions over a period of several months - sponsorship by someone who has worked directly with the candidate reviewing and committing patches - detailed positive feedback from those who have worked directly with the candidate - a record of patches that maintain or improve the quality of the code without the need for feedback or rework 14 Binding +1 Votes: Rob Godfrey Rafael Schloming Kim van der Reit Steve Huston Robert Greig Rajith Attapattu Jonathan Robie Ted Ross Martin Ritchie Alan Conway Robbie Gemmell Aidan Skinner Marnie McCormack Nuno Santos 2 Non-Binding +1 Votes: Andrew Stitcher Sam Joyce Gordon Sim commented that the first quality should be clarified. Mick Goulish voted +1 with the caveat that the first quality should be clarified/removed. There were no zero or -1 votes. I believe this passes. I'm not sure what the official rules are around the caveats, but I'm happy to work to clarify the first quality either way. --Rafael I think the rules around such caveats have to be as follow: 1. If the vote passes without the caveat votes, then it passes. 2. If the vote does not pass even with the caveat votes, then it does not pass. 3. If the vote passes only with the caveat votes, then you satisfy the caveats before considering it to have passed. In this case, it passes regardless of caveats so you can ignore them at your pleasure -- however, since they are asking for clarification, and since the item in question definitely needs a little, and since you're happy to do it -- take a whack at it and post the clarification. Can you make a 5- to 15-point list of how our project is structured and how we work ? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2326) exchange.declare should throw a 404 - not found exception if the exchange type is unknown
exchange.declare should throw a 404 - not found exception if the exchange type is unknown - Key: QPID-2326 URL: https://issues.apache.org/jira/browse/QPID-2326 Project: Qpid Issue Type: Bug Components: C++ Broker, Python Test Suite Affects Versions: 0.6 Reporter: Rob Godfrey The C++ Broker returns a 503 error when an exchange is declared as being of a type which the broker does not recognize, and the python test testTypeNotKnown in exchange.py tests for this behaviour However the AMQP0-10 spec (pg 217 of the PDF) says Exception: exchange-type-not-found Error:not-found If the client attempts to create an exchange which the server does not recognize, an exception MUST be sent. not-found is error code 404 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1982) QMF ResilientConnection notifyFd feature portability
[ https://issues.apache.org/jira/browse/QPID-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797149#action_12797149 ] Alan Conway commented on QPID-1982: --- We already have portable constructs for this type of notification. sys::PollableCondition is a low-level, portable mechanism that can be added to a Poller and allows you to wake a poller thread by setting the condition. sys::PollableQueue template is built on top of pollable condition. It allows dispatch to poller threads via an in-memory queue. I suspect PollableQueue is what's needed: replacing the use of ::write with a push to the pollable queue. If not a new portable mechansim can probably be built based on PollableCondition. QMF ResilientConnection notifyFd feature portability Key: QPID-1982 URL: https://issues.apache.org/jira/browse/QPID-1982 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Affects Versions: 0.5 Environment: Windows Reporter: Steve Huston The QMF's C++ qmfcommon ResilientConnection class has a setNotifyFd (int fd) method. The docs say this can receive a file descriptor that is written on when certain events take place, supposedly so the other end of the channel can listen, select, etc. and be notified of some event. This construct isn't portable, both because of the datatype of the fd (int is not necessarily a legit handle type everywhere) and because the code assumes a write() will work. The code can be abstracted out to get rid of the write() easily enough, but what is the usage for this facility? There are no calls to setNotifyFd() that I can find outside of the library containing the implementation. So I can't tell if this is something that can be replaced by qpid::sys::PollableCondition or not. What is the use case for this, and how can we make this portable? Different IPC type? Callback to some private hook? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Test suite vs optional xml config
On 01/06/2010 06:14 AM, Gordon Sim wrote: On 01/04/2010 06:41 PM, john dunning wrote: I'm squiffing up qpid-config to add the ability to configure xml exchanges and queue bindings. I'm trying to add stuff to the test suite (cpp/src/tests/cli_tests.py and related) to match. The difficulty I have right now is that the xml support is optional. If you didn't configure for xml and load the module when you started the broker, you don't get xml support, and my test case flames out. It's not too hard to make the wrapper script (run_cli_tests) sense the presence of the module and only optionally add the --load-module arg. Presumably something analogous could be done on windows as well. It's less clear to me how to make the test code sense that the environment is sans-xml and DTRT. Possibilities which come to mind: 1. Trap the error (about xml being unhandled) and ignore it 2. Move the xml test out into a separate module, and only invoke it if we're configured the right way. 3. Interrogate the broker to ask him if he does xml (is this even possible?) Anybody care to express an opinion on the cleanest way to make the test suite seamlessly accomodate xml support? TIA... Just a suggestion: The run_cli_tests script uses the qpid-python-test tool which allows an ignore file to be specified. So you could detect the availability of the module and load it if available as you say, and if not available specify an ignore file that excludes the xml exchange related tests. Thats true, but I think it is still worth splitting out test sets for optional modules into separate files for the sake of clarity and readability. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
On 01/06/2010 06:52 AM, Robert Godfrey wrote: 2010/1/6 Rafael Schlomingrafa...@redhat.com Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Test suite vs optional xml config
On 01/06/2010 04:05 PM, Alan Conway wrote: On 01/06/2010 06:14 AM, Gordon Sim wrote: On 01/04/2010 06:41 PM, john dunning wrote: I'm squiffing up qpid-config to add the ability to configure xml exchanges and queue bindings. I'm trying to add stuff to the test suite (cpp/src/tests/cli_tests.py and related) to match. The difficulty I have right now is that the xml support is optional. If you didn't configure for xml and load the module when you started the broker, you don't get xml support, and my test case flames out. It's not too hard to make the wrapper script (run_cli_tests) sense the presence of the module and only optionally add the --load-module arg. Presumably something analogous could be done on windows as well. It's less clear to me how to make the test code sense that the environment is sans-xml and DTRT. Possibilities which come to mind: 1. Trap the error (about xml being unhandled) and ignore it 2. Move the xml test out into a separate module, and only invoke it if we're configured the right way. 3. Interrogate the broker to ask him if he does xml (is this even possible?) Anybody care to express an opinion on the cleanest way to make the test suite seamlessly accomodate xml support? TIA... Just a suggestion: The run_cli_tests script uses the qpid-python-test tool which allows an ignore file to be specified. So you could detect the availability of the module and load it if available as you say, and if not available specify an ignore file that excludes the xml exchange related tests. Thats true, but I think it is still worth splitting out test sets for optional modules into separate files for the sake of clarity and readability. Yes, thats a fair point. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Test suite vs optional xml config
On Wed, 2010-01-06 at 16:11 +, Gordon Sim wrote: On 01/06/2010 04:05 PM, Alan Conway wrote: Thats true, but I think it is still worth splitting out test sets for optional modules into separate files for the sake of clarity and readability. Yes, thats a fair point. Thanks all. For the immediate goal (getting the new features into qpid-config and adding tests for them) I'm going to go with the least intrusive solution, which seems to be sensing the presence of the xml.so and driving the rest of the infrastructure accordingly. There likely does deserve to be some followon work to split up the test stuff in a more modular way. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Test suite vs optional xml config
On 01/06/2010 11:20 AM, john dunning wrote: On Wed, 2010-01-06 at 16:11 +, Gordon Sim wrote: On 01/06/2010 04:05 PM, Alan Conway wrote: Thats true, but I think it is still worth splitting out test sets for optional modules into separate files for the sake of clarity and readability. Yes, thats a fair point. Thanks all. For the immediate goal (getting the new features into qpid-config and adding tests for them) I'm going to go with the least intrusive solution, which seems to be sensing the presence of the xml.so and driving the rest of the infrastructure accordingly. There likely does deserve to be some followon work to split up the test stuff in a more modular way. Shoud have mentioned this earlier but the cluster module is an existing example of this. The way it works is - all cluster-specific build test rules are in src/tests/cluster.mk - cluster.mk has the form if HAVE_LIBCPG ... endif - cluster.mk is included in Makefile.am The existing XML tests are handled similarly but they're not broken out into a separate .mk file as they're currently quite trivial. If you add a lot of tests then it might be worth breaking this out int xml.mk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2327) Enhance qpid-config to deal with xml and headers brokers
Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Fix For: 0.7 qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2327) Enhance qpid-config to deal with xml and headers brokers
[ https://issues.apache.org/jira/browse/QPID-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] john dunning updated QPID-2327: --- Attachment: bz-549443.patch This patch implements the new qpid-config functionality, and enhances the test suite to test it. Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Fix For: 0.7 Attachments: bz-549443.patch qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2327) Enhance qpid-config to deal with xml and headers brokers
[ https://issues.apache.org/jira/browse/QPID-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2327: -- Assignee: Ted Ross Enhance qpid-config to deal with xml and headers brokers Key: QPID-2327 URL: https://issues.apache.org/jira/browse/QPID-2327 Project: Qpid Issue Type: Improvement Components: Python Test Suite, python tools Affects Versions: 0.7 Environment: Tested on linux (fedora), at least partially affects all platforms Reporter: john dunning Assignee: Ted Ross Fix For: 0.7 Attachments: bz-549443.patch qpid-config currently doesn't have a way to configure xml or header type bindings. This patch adds the ability to do so, with extra arg parsing to deal with the specialized args for those bind types. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: JMS Client Heartbeat configuration
On Tue, Jan 5, 2010 at 7:42 PM, Rajith Attapattu rajit...@gmail.com wrote: It appears that there are two different means configuring the heartbeat interval for the JMS client. The 0-9 codepath uses a jvm argument while the 0-10 codepath uses a broker URL property. From a users perspective we should provide a consistent interface. Therefore I propose we combine the two approaches. That sounds sensible to me. - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Test suite vs optional xml config
On 01/06/2010 11:20 AM, john dunning wrote: On Wed, 2010-01-06 at 16:11 +, Gordon Sim wrote: On 01/06/2010 04:05 PM, Alan Conway wrote: Thats true, but I think it is still worth splitting out test sets for optional modules into separate files for the sake of clarity and readability. Yes, thats a fair point. Thanks all. For the immediate goal (getting the new features into qpid-config and adding tests for them) I'm going to go with the least intrusive solution, which seems to be sensing the presence of the xml.so and driving the rest of the infrastructure accordingly. There likely does deserve to be some followon work to split up the test stuff in a more modular way. Shoud have mentioned this earlier but the cluster module is an existing example of this. The way it works is - all cluster-specific build test rules are in src/tests/cluster.mk - cluster.mk has the form if HAVE_LIBCPG ... endif - cluster.mk is included in Makefile.am The existing XML tests are handled similarly but they're not broken out into a separate .mk file as they're currently quite trivial. If you add a lot of tests then it might be worth breaking this out int xml.mk The additions should also be in the cmake builds. We're supposed to transition to cmake sometime post-0.6. -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2328) Querying for 500 objects causes C++ based ruby console to hang
Querying for 500 objects causes C++ based ruby console to hang -- Key: QPID-2328 URL: https://issues.apache.org/jira/browse/QPID-2328 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: Version: qmf-0.5.829175-3 Reporter: Ian Main Using the test framework at http://github.com/movitto/qmf/ we were able to cause the console to hang and require a SIGKILL to stop it by querying for 450 or so objects. To reproduce: in project_stress/stress_agent/src run: ./stress_agent -n 500 And in project_stress/ruby/bin run: ./console.rb -t testobject -s If you try rerunning the agent with fewer objects you will see what normal output looks like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2329) Queries require lower case versions of class names?
Queries require lower case versions of class names? --- Key: QPID-2329 URL: https://issues.apache.org/jira/browse/QPID-2329 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Reporter: Ian Main In the agent the class is named 'TestObject', but if you query for :class = 'TestObject' you get no returns. You must query for :class = 'testobject'. I'm guessing this is incorrect behaviour. I would think it should either be completely case insensitive or require exact string match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2330) Querying 30 to 100 objects and then calling methods causes some methods to not return?
Querying 30 to 100 objects and then calling methods causes some methods to not return? -- Key: QPID-2330 URL: https://issues.apache.org/jira/browse/QPID-2330 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Everything run on localhost. Reporter: Ian Main If you run the stress agent framework (http://github.com/movitto/qmf/) with: ./stress_agent -n 100 and ./console.rb -t testobject -s You will see return values for all the calls, however there is a join() at the end (the calls are made in threads). If you use 10 or so objects on the agent it works fine and all threads return and join. It seems around 30 or so objects it starts not join()'ing all threads presumably because some methods don't return. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2329) Queries require lower case versions of class names?
[ https://issues.apache.org/jira/browse/QPID-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2329: -- Assignee: Ted Ross Queries require lower case versions of class names? --- Key: QPID-2329 URL: https://issues.apache.org/jira/browse/QPID-2329 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Reporter: Ian Main Assignee: Ted Ross In the agent the class is named 'TestObject', but if you query for :class = 'TestObject' you get no returns. You must query for :class = 'testobject'. I'm guessing this is incorrect behaviour. I would think it should either be completely case insensitive or require exact string match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2330) Querying 30 to 100 objects and then calling methods causes some methods to not return?
[ https://issues.apache.org/jira/browse/QPID-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2330: -- Assignee: Ted Ross Querying 30 to 100 objects and then calling methods causes some methods to not return? -- Key: QPID-2330 URL: https://issues.apache.org/jira/browse/QPID-2330 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Everything run on localhost. Reporter: Ian Main Assignee: Ted Ross If you run the stress agent framework (http://github.com/movitto/qmf/) with: ./stress_agent -n 100 and ./console.rb -t testobject -s You will see return values for all the calls, however there is a join() at the end (the calls are made in threads). If you use 10 or so objects on the agent it works fine and all threads return and join. It seems around 30 or so objects it starts not join()'ing all threads presumably because some methods don't return. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2328) Querying for 500 objects causes C++ based ruby console to hang
[ https://issues.apache.org/jira/browse/QPID-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2328: -- Assignee: Ted Ross Querying for 500 objects causes C++ based ruby console to hang -- Key: QPID-2328 URL: https://issues.apache.org/jira/browse/QPID-2328 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: Version: qmf-0.5.829175-3 Reporter: Ian Main Assignee: Ted Ross Using the test framework at http://github.com/movitto/qmf/ we were able to cause the console to hang and require a SIGKILL to stop it by querying for 450 or so objects. To reproduce: in project_stress/stress_agent/src run: ./stress_agent -n 500 And in project_stress/ruby/bin run: ./console.rb -t testobject -s If you try rerunning the agent with fewer objects you will see what normal output looks like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2331) C++ based ruby console leaks memory?
C++ based ruby console leaks memory? Key: QPID-2331 URL: https://issues.apache.org/jira/browse/QPID-2331 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 All run on localhost. Reporter: Ian Main If you run: ./stress_agent -n 10 and ./console.rb -t testobject -s -x 10 The console will iterate over a search and calling a method on each returned object. If you load up 'top' you will see that it constantly grows in size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2332) Would be nice to have some kind of wait_for() functionality in the console API
Would be nice to have some kind of wait_for() functionality in the console API
--
Key: QPID-2332
URL: https://issues.apache.org/jira/browse/QPID-2332
Project: Qpid
Issue Type: New Feature
Reporter: Ian Main
Priority: Minor
We could easily implement a method which waits for a specific property or
statistic to become a specific value. The ugly way to do this would be eg:
object.wait_for('ready_property', true, 300)
Where the first argument is the name of the property, the second the value to
wait for and the third is a timeout. I think there would be more elegant ways
to do this in many languages however.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2331) C++ based ruby console leaks memory?
[ https://issues.apache.org/jira/browse/QPID-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2331: -- Assignee: Ted Ross C++ based ruby console leaks memory? Key: QPID-2331 URL: https://issues.apache.org/jira/browse/QPID-2331 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 All run on localhost. Reporter: Ian Main Assignee: Ted Ross If you run: ./stress_agent -n 10 and ./console.rb -t testobject -s -x 10 The console will iterate over a search and calling a method on each returned object. If you load up 'top' you will see that it constantly grows in size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2332) Would be nice to have some kind of wait_for() functionality in the console API
[
https://issues.apache.org/jira/browse/QPID-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned QPID-2332:
--
Assignee: Ted Ross
Would be nice to have some kind of wait_for() functionality in the console API
--
Key: QPID-2332
URL: https://issues.apache.org/jira/browse/QPID-2332
Project: Qpid
Issue Type: New Feature
Reporter: Ian Main
Assignee: Ted Ross
Priority: Minor
We could easily implement a method which waits for a specific property or
statistic to become a specific value. The ugly way to do this would be eg:
object.wait_for('ready_property', true, 300)
Where the first argument is the name of the property, the second the value to
wait for and the third is a timeout. I think there would be more elegant
ways to do this in many languages however.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2333) Seemingly random timeouts
Seemingly random timeouts - Key: QPID-2333 URL: https://issues.apache.org/jira/browse/QPID-2333 Project: Qpid Issue Type: Bug Environment: qmf-0.5.829175-3.fc11.x86_64 Running console and qpidd on one machine, with stress_agent on a different one. Reporter: Ian Main When running with the console and qpidd on localhost and the stress agent on another, I was able to produce this: /usr/lib/ruby/site_ruby/1.8/qmf.rb:357:in `method_missing': Timed out waiting for response (RuntimeError) from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:352:in `method_missing' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `each' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `method_missing' from ./console.rb:131:in `main' from ./console.rb:128:in `initialize' from ./console.rb:128:in `new' from ./console.rb:128:in `main' The agent was started with: $ ./stress_agent -b tp.mains.priv -n 50 and the console: $ ./console.rb -t testobject -s -x 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
Alan Conway wrote: On 01/06/2010 06:52 AM, Robert Godfrey wrote: 2010/1/6 Rafael Schlomingrafa...@redhat.com Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well. Possibly, I'm not a docbook expert. Either way I suspect a simple XML file could be trivially transformed into docbook and whatever else we need, e.g. something along the lines of: feature name=foo title=Foo description Blah blah blah. /description component name=java-broker/ component name=cpp-broker/ test ref=pointer-to-test/ ... /feature I'm not sure the extent to which we want to cross reference tests/components/etc against this sort of thing. If that's something we feel would be valuable then I suspect making up a simple XML format and translating to docbook would be the way to go. If on the other hand it's essentially just a documentation-only feature glossary then I'm sure docbook alone would be sufficient. As long as the format is fairly regular, I'm not particularly fussed either way as it should be straightforward to translate later if necessary. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2333) Seemingly random timeouts
[ https://issues.apache.org/jira/browse/QPID-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797285#action_12797285 ] Ian Main commented on QPID-2333: We saw this happen in ovirt a lot as well. Which is kind of strange because it saw a lot less traffic then this test is producing in order to reproduce the issue. Seemingly random timeouts - Key: QPID-2333 URL: https://issues.apache.org/jira/browse/QPID-2333 Project: Qpid Issue Type: Bug Environment: qmf-0.5.829175-3.fc11.x86_64 Running console and qpidd on one machine, with stress_agent on a different one. Reporter: Ian Main When running with the console and qpidd on localhost and the stress agent on another, I was able to produce this: /usr/lib/ruby/site_ruby/1.8/qmf.rb:357:in `method_missing': Timed out waiting for response (RuntimeError) from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:352:in `method_missing' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `each' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `method_missing' from ./console.rb:131:in `main' from ./console.rb:128:in `initialize' from ./console.rb:128:in `new' from ./console.rb:128:in `main' The agent was started with: $ ./stress_agent -b tp.mains.priv -n 50 and the console: $ ./console.rb -t testobject -s -x 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2330) Querying 30 to 100 objects and then calling methods causes some methods to not return?
[ https://issues.apache.org/jira/browse/QPID-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797286#action_12797286 ] Ian Main commented on QPID-2330: I actually think this may be a thread deadlock and may be the same as the issue in QPID-2328, but of course that's pure speculation on my part. Querying 30 to 100 objects and then calling methods causes some methods to not return? -- Key: QPID-2330 URL: https://issues.apache.org/jira/browse/QPID-2330 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Everything run on localhost. Reporter: Ian Main Assignee: Ted Ross If you run the stress agent framework (http://github.com/movitto/qmf/) with: ./stress_agent -n 100 and ./console.rb -t testobject -s You will see return values for all the calls, however there is a join() at the end (the calls are made in threads). If you use 10 or so objects on the agent it works fine and all threads return and join. It seems around 30 or so objects it starts not join()'ing all threads presumably because some methods don't return. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1875) Can't create durable queues that use amq.topic due to error in BindingURLParser.
[ https://issues.apache.org/jira/browse/QPID-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797294#action_12797294 ] Rajith Attapattu commented on QPID-1875: Martin I cannot recall who added the option either. We may have to dig through the svn logs. I have provided a fix at rev r779651 on Qpid trunk. Can't create durable queues that use amq.topic due to error in BindingURLParser. Key: QPID-1875 URL: https://issues.apache.org/jira/browse/QPID-1875 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.6 In BindingURLParser, process options method, line 420 has the following error queueName = _bindingURL.getOption(BindingURL.OPTION_CLIENTID + : + BindingURL.OPTION_SUBSCRIPTION); This results in the queue name being null and the subsequent queue-declare failing. It should be corrected to the following queueName = _bindingURL.getOption(BindingURL.OPTION_CLIENTID + : + BindingURL.OPTION_SUBSCRIPTION); However I am not sure if forcing a particular pattern for the queue name and treating it as a durable subscription if the exchange is amq.topic and queue is durable is correct either. This will create confusion as when they tried to work with this queue using mgt-tools or connect with other non java clients, it may not be obvious that the queue name was generated in this case. The users should have the freedom to define a queue name of their choice. There is a clear path to create durable subscriptions in the JMS API. So I don't think we need to force it in the jndi.properties format. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2334) Strange hang in console
Strange hang in console --- Key: QPID-2334 URL: https://issues.apache.org/jira/browse/QPID-2334 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Reporter: Ian Main When running console I got: Searching for objects of class testobject in packages com.redhat.stress_agent ^C!!! Unhandled exception /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `write' /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `kick' /usr/lib/ruby/site_ruby/1.8/qmf.rb:1128:in `send_query' /usr/lib/ruby/site_ruby/1.8/qmf.rb:976:in `objects' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/site_ruby/1.8/qmf.rb:971:in `objects' The console was hung for at least 5 minutes on the 'Searching for objects...' line, so I hit control-C and got that traceback. $ ./console.rb -t testobject -s -x 1 $ ./stress_agent -b tp.mains.priv -n 50 Again this is with the agent on a separate machine and qpidd and console on the same machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2334) Strange hang in console
[ https://issues.apache.org/jira/browse/QPID-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797298#action_12797298 ] Ian Main commented on QPID-2334: Actually this seems to be the most common error I'm seeing now when running this test. Strange hang in console --- Key: QPID-2334 URL: https://issues.apache.org/jira/browse/QPID-2334 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Reporter: Ian Main When running console I got: Searching for objects of class testobject in packages com.redhat.stress_agent ^C!!! Unhandled exception /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `write' /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `kick' /usr/lib/ruby/site_ruby/1.8/qmf.rb:1128:in `send_query' /usr/lib/ruby/site_ruby/1.8/qmf.rb:976:in `objects' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/site_ruby/1.8/qmf.rb:971:in `objects' The console was hung for at least 5 minutes on the 'Searching for objects...' line, so I hit control-C and got that traceback. $ ./console.rb -t testobject -s -x 1 $ ./stress_agent -b tp.mains.priv -n 50 Again this is with the agent on a separate machine and qpidd and console on the same machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
I don't wish to overcomplicate, but do you want some grouping of features... (e.g. a parentFeature tag) if we're looking at the same sort of granularity as unit tests, that should be quite fine... but many of them may be aspects of the same feature... -- Rob 2010/1/6 Rafael Schloming rafa...@redhat.com Alan Conway wrote: On 01/06/2010 06:52 AM, Robert Godfrey wrote: 2010/1/6 Rafael Schlomingrafa...@redhat.com Robert Godfrey wrote: Overall I think with a bit of work from both the C++ and Java communities we can get the brokers to look and behave much more similarly... however we will also need to change the way we work a bit so that when we decide to add new features we attempt to discuss and agree before implementing. It will do no good to get the brokers temporarily aligned if they immediately begin to drift apart again. I'm just thinking aloud here, but perhaps it would help to gather our various disparate documentation snippits into a single canonical feature glossary somewhere in SVN. Ideally in some format that could be easily fed into the documentation, but could also serve as a source for other things such as generating test matrices, and doing feature based coverage analysis. --Rafael That sounds like an excellent idea... Can jrobie's proposed docbook for documentation project provide the right format for this? It's XML so should be possible to generate various types of file. Seems like something we want to be able to inject into the user doc as well. Possibly, I'm not a docbook expert. Either way I suspect a simple XML file could be trivially transformed into docbook and whatever else we need, e.g. something along the lines of: feature name=foo title=Foo description Blah blah blah. /description component name=java-broker/ component name=cpp-broker/ test ref=pointer-to-test/ ... /feature I'm not sure the extent to which we want to cross reference tests/components/etc against this sort of thing. If that's something we feel would be valuable then I suspect making up a simple XML format and translating to docbook would be the way to go. If on the other hand it's essentially just a documentation-only feature glossary then I'm sure docbook alone would be sufficient. As long as the format is fairly regular, I'm not particularly fussed either way as it should be straightforward to translate later if necessary. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Tagging our releases
I was just trying to quickly figure out the svn rev the Java 0.5 release and found that there wasn't a tag available for it. (please note we do have a branch for it, but I still think we should be tagging the final release). It seems we have tags for the previous releases (all though some aren't explicitly named). I thinks its good practise to tag releases. Some of the previous releases even had tags for RC's as well. So lets make sure we tag the final release for 0.6 Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2333) Seemingly random timeouts
[ https://issues.apache.org/jira/browse/QPID-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2333: -- Assignee: Ted Ross Seemingly random timeouts - Key: QPID-2333 URL: https://issues.apache.org/jira/browse/QPID-2333 Project: Qpid Issue Type: Bug Environment: qmf-0.5.829175-3.fc11.x86_64 Running console and qpidd on one machine, with stress_agent on a different one. Reporter: Ian Main Assignee: Ted Ross When running with the console and qpidd on localhost and the stress agent on another, I was able to produce this: /usr/lib/ruby/site_ruby/1.8/qmf.rb:357:in `method_missing': Timed out waiting for response (RuntimeError) from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:352:in `method_missing' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `each' from /usr/lib/ruby/site_ruby/1.8/qmf.rb:348:in `method_missing' from ./console.rb:131:in `main' from ./console.rb:128:in `initialize' from ./console.rb:128:in `new' from ./console.rb:128:in `main' The agent was started with: $ ./stress_agent -b tp.mains.priv -n 50 and the console: $ ./console.rb -t testobject -s -x 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-2334) Strange hang in console
[ https://issues.apache.org/jira/browse/QPID-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned QPID-2334: -- Assignee: Ted Ross Strange hang in console --- Key: QPID-2334 URL: https://issues.apache.org/jira/browse/QPID-2334 Project: Qpid Issue Type: Bug Components: Qpid Managment Framework Environment: qmf-0.5.829175-3.fc11.x86_64 Reporter: Ian Main Assignee: Ted Ross When running console I got: Searching for objects of class testobject in packages com.redhat.stress_agent ^C!!! Unhandled exception /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `write' /usr/lib/ruby/site_ruby/1.8/qmf.rb:112:in `kick' /usr/lib/ruby/site_ruby/1.8/qmf.rb:1128:in `send_query' /usr/lib/ruby/site_ruby/1.8/qmf.rb:976:in `objects' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/site_ruby/1.8/qmf.rb:971:in `objects' The console was hung for at least 5 minutes on the 'Searching for objects...' line, so I hit control-C and got that traceback. $ ./console.rb -t testobject -s -x 1 $ ./stress_agent -b tp.mains.priv -n 50 Again this is with the agent on a separate machine and qpidd and console on the same machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1880) The new unmanaged objects are confusing
[ https://issues.apache.org/jira/browse/QPID-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797303#action_12797303 ] Ian Main commented on QPID-1880: Actually we had a conversation on irc and figured that so long as all the properties of a class were read only, then the 'unmanaged' part happens automatically. Therefore it should be enforced that unmanaged objects contain only read only attributes. The new unmanaged objects are confusing --- Key: QPID-1880 URL: https://issues.apache.org/jira/browse/QPID-1880 Project: Qpid Issue Type: Improvement Components: Qpid Managment Framework Reporter: Ian Main IMO the newly added managed objects are confusing in that they return and look just like the managed objects, but you are unable to call methods on them, nor use eg the refresh() method to get a newly updated instance. QMF up until this point has made all objects managed and backed by an implementation. The addition of a data structure type could be very useful but I don't think it should share the same name as the managed objects around which QMF revolves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Tagging our releases
On Wed, 2010-01-06 at 15:29 -0500, Rajith Attapattu wrote: I was just trying to quickly figure out the svn rev the Java 0.5 release and found that there wasn't a tag available for it. (please note we do have a branch for it, but I still think we should be tagging the final release). It seems we have tags for the previous releases (all though some aren't explicitly named). I thinks its good practise to tag releases. Some of the previous releases even had tags for RC's as well. So lets make sure we tag the final release for 0.6 I fully intend to tag the 0.6 release when I make it. However note that you can find a releases svn revision by looking in the *.svnrevision file in the distribution directory - obviously this is not massively convenient. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Subversion tags and branches (a little moan)
I've just noticed (after several hours of puzzling about what was screwing up my git branch history) that there are a number of branches and tags that omit the top level, redundant qpid directory. Now I'm for getting rid of uselessness like this as much as the next guy (and I'm in fact responsible for at least one of these tags myself). However it totally screws up git-svn's ability to figure out the correct branching structure of the project (and frankly git-svn is the best tool able to visualise this) so I'm a little unhappy it's broken into 2 pieces. I don't think this can be fixed now in the existing tree, but can we please, please, please remember when doing svn cp to do something like: svn cp -r895736 https://svn.apache.org/repos/asf/qpid/trunk https://svn.apache.org/repos/asf/qpid/branches/0.6-release [The -r is useful to make sure you know exactly which revision you are branching or tagging] Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2320) Failed acquire on LVQ causes broker crash
[ https://issues.apache.org/jira/browse/QPID-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Trieloff resolved QPID-2320. - Resolution: Fixed Fix Version/s: 0.7 Committed revision 896687. test and fix Failed acquire on LVQ causes broker crash - Key: QPID-2320 URL: https://issues.apache.org/jira/browse/QPID-2320 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Gordon Sim Fix For: 0.7 If an acquire fails for an LVQ because the message has already been acquired by some other subscriber, the failed attempt causes the broker to crash. This is due to lack of proper bounds checking in Queue::acquire() for the LVQ case and was I believe introduced by http://svn.apache.org/viewvc?view=revisionrevision=834172. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Tagging our releases
Shall we retroactively create a 0.5 tag for future usage? Andrews suggestion of looking at the .svnrevision file doesn't work for 0.5 as it reports HEAD. I just noticed from the users list why Rajith wanted to know the revision, and he understandably got the wrong revision from looking at the 0.5-release branch. It doesn't change the outcome discussed as no code was changed, but the noted rev 779632 was actually an error on my part after 0.5 was produced (due to a partially-switched SVN checkout) and 0.5 was released at rev 775777 as far as I can tell. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 21:26 To: dev@qpid.apache.org Subject: Re: Tagging our releases On Wed, 2010-01-06 at 15:29 -0500, Rajith Attapattu wrote: I was just trying to quickly figure out the svn rev the Java 0.5 release and found that there wasn't a tag available for it. (please note we do have a branch for it, but I still think we should be tagging the final release). It seems we have tags for the previous releases (all though some aren't explicitly named). I thinks its good practise to tag releases. Some of the previous releases even had tags for RC's as well. So lets make sure we tag the final release for 0.6 I fully intend to tag the 0.6 release when I make it. However note that you can find a releases svn revision by looking in the *.svnrevision file in the distribution directory - obviously this is not massively convenient. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Subversion tags and branches (a little moan)
It is indeed unfortunate, and I try my best to remember it when dealing with branches. While the topic is raised though, is the 0.6 branch rooted at: https://svn.apache.org/repos/asf/qpid/branches/0.6-release/qpid or https://svn.apache.org/repos/asf/qpid/branches/0.6-release/trunk/qpid ? Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 21:43 To: Qpid Dev List Subject: Subversion tags and branches (a little moan) I've just noticed (after several hours of puzzling about what was screwing up my git branch history) that there are a number of branches and tags that omit the top level, redundant qpid directory. Now I'm for getting rid of uselessness like this as much as the next guy (and I'm in fact responsible for at least one of these tags myself). However it totally screws up git-svn's ability to figure out the correct branching structure of the project (and frankly git-svn is the best tool able to visualise this) so I'm a little unhappy it's broken into 2 pieces. I don't think this can be fixed now in the existing tree, but can we please, please, please remember when doing svn cp to do something like: svn cp -r895736 https://svn.apache.org/repos/asf/qpid/trunk https://svn.apache.org/repos/asf/qpid/branches/0.6-release [The -r is useful to make sure you know exactly which revision you are branching or tagging] Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [jira] Created: (QPID-2320) Failed acquire on LVQ causes broker crash
I see this has been marked resolved for 0.7, was it decided it isn't a blocker? Robbie -Original Message- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: 04 January 2010 21:23 To: dev@qpid.apache.org Subject: Re: [jira] Created: (QPID-2320) Failed acquire on LVQ causes broker crash On 01/04/2010 02:55 PM, Gordon Sim (JIRA) wrote: Failed acquire on LVQ causes broker crash - Key: QPID-2320 URL: https://issues.apache.org/jira/browse/QPID- 2320 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Gordon Sim If an acquire fails for an LVQ because the message has already been acquired by some other subscriber, the failed attempt causes the broker to crash. This is due to lack of proper bounds checking in Queue::acquire() for the LVQ case and was I believe introduced by http://svn.apache.org/viewvc?view=revisionrevision=834172. This is a regression that causes a crash, should it be fixed for 0.6? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Tagging our releases
On Wed, 2010-01-06 at 21:51 +, Robbie Gemmell wrote: Shall we retroactively create a 0.5 tag for future usage? Andrews suggestion of looking at the .svnrevision file doesn't work for 0.5 as it reports HEAD. Oh - I think retroactively creating the tag would be useful. Thinking a little about it -I think our 0.5 branch/tag naming is broken: IMNSHO We should have a single 0.6 _branch_ and every release from it should be tagged. Leading to something like: branches/0.6 tags/0.6-release tags/0.6.1-release etc. The only work that should happen on the 0.6 branch would be related to a later release of the 0.6 line so I can't see the point of a 0.6-release branch (but I created it following the example from 0.5). So now I'm a bit stuck for tag names! I don't want to duplicate the branch name as it will confuse things. Suggestions? Andrew I just noticed from the users list why Rajith wanted to know the revision, and he understandably got the wrong revision from looking at the 0.5-release branch. It doesn't change the outcome discussed as no code was changed, but the noted rev 779632 was actually an error on my part after 0.5 was produced (due to a partially-switched SVN checkout) and 0.5 was released at rev 775777 as far as I can tell. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 21:26 To: dev@qpid.apache.org Subject: Re: Tagging our releases On Wed, 2010-01-06 at 15:29 -0500, Rajith Attapattu wrote: I was just trying to quickly figure out the svn rev the Java 0.5 release and found that there wasn't a tag available for it. (please note we do have a branch for it, but I still think we should be tagging the final release). It seems we have tags for the previous releases (all though some aren't explicitly named). I thinks its good practise to tag releases. Some of the previous releases even had tags for RC's as well. So lets make sure we tag the final release for 0.6 I fully intend to tag the 0.6 release when I make it. However note that you can find a releases svn revision by looking in the *.svnrevision file in the distribution directory - obviously this is not massively convenient. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Subversion tags and branches (a little moan)
I only ask as both already exist. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 22:09 To: dev@qpid.apache.org Subject: RE: Subversion tags and branches (a little moan) On Wed, 2010-01-06 at 22:00 +, Robbie Gemmell wrote: It is indeed unfortunate, and I try my best to remember it when dealing with branches. While the topic is raised though, is the 0.6 branch rooted at: https://svn.apache.org/repos/asf/qpid/branches/0.6-release/qpid or This one (above). https://svn.apache.org/repos/asf/qpid/branches/0.6-release/trunk/qpid ? Why in gods name would you introduce yet another redundant directory level (I mean it's not as if .../0.6-release/branches/... would have any meaning)? Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Subversion tags and branches (a little moan)
On Wed, 2010-01-06 at 22:14 +, Robbie Gemmell wrote: I only ask as both already exist. Bugger, you're right - I'm starting to hate svn branching. I'll fix it (when I figure out the idiot thing I did) Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Tagging our releases
Oh, and I forgot to add that I think Tag names should just be the direct version number, e.g. simply M4, 0.5, 0.6, 0.6.1 etc Robbie -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 06 January 2010 22:22 To: dev@qpid.apache.org Subject: RE: Tagging our releases As far as I understand, the rationale for creating the 0.X-release branch is just so that trunk can be unfrozen and any blockers committed back to the branch. When releases drag on like M4 and 0.5 did it is quite annoying having trunk frozen. We could as easily use the same temporary branch name for all such release scenarios, or create new ones for each release and then delete it when we are done with the release, as the eventual release Tag would serve as marker enough after that point. Alternatively, create a 0.X.x branch as the first 0.X release is completed and then leave it in place for any future micro revisions. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 22:15 To: dev@qpid.apache.org Subject: RE: Tagging our releases On Wed, 2010-01-06 at 21:51 +, Robbie Gemmell wrote: Shall we retroactively create a 0.5 tag for future usage? Andrews suggestion of looking at the .svnrevision file doesn't work for 0.5 as it reports HEAD. Oh - I think retroactively creating the tag would be useful. Thinking a little about it -I think our 0.5 branch/tag naming is broken: IMNSHO We should have a single 0.6 _branch_ and every release from it should be tagged. Leading to something like: branches/0.6 tags/0.6-release tags/0.6.1-release etc. The only work that should happen on the 0.6 branch would be related to a later release of the 0.6 line so I can't see the point of a 0.6- release branch (but I created it following the example from 0.5). So now I'm a bit stuck for tag names! I don't want to duplicate the branch name as it will confuse things. Suggestions? Andrew I just noticed from the users list why Rajith wanted to know the revision, and he understandably got the wrong revision from looking at the 0.5-release branch. It doesn't change the outcome discussed as no code was changed, but the noted rev 779632 was actually an error on my part after 0.5 was produced (due to a partially-switched SVN checkout) and 0.5 was released at rev 775777 as far as I can tell. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 06 January 2010 21:26 To: dev@qpid.apache.org Subject: Re: Tagging our releases On Wed, 2010-01-06 at 15:29 -0500, Rajith Attapattu wrote: I was just trying to quickly figure out the svn rev the Java 0.5 release and found that there wasn't a tag available for it. (please note we do have a branch for it, but I still think we should be tagging the final release). It seems we have tags for the previous releases (all though some aren't explicitly named). I thinks its good practise to tag releases. Some of the previous releases even had tags for RC's as well. So lets make sure we tag the final release for 0.6 I fully intend to tag the 0.6 release when I make it. However note that you can find a releases svn revision by looking in the *.svnrevision file in the distribution directory - obviously this is not massively convenient. Andrew - -- -- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org --- -- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Subversion tags and branches (a little moan)
On Wed, 2010-01-06 at 17:25 -0500, Andrew Stitcher wrote: On Wed, 2010-01-06 at 22:14 +, Robbie Gemmell wrote: I only ask as both already exist. Bugger, you're right - I'm starting to hate svn branching. I'll fix it (when I figure out the idiot thing I did) Figured it out and fixed it. (It was an idiot thing - somehow I managed to run the svn cp command twice within 10 minutes and not notice) A - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2283) java Testkit scripts should have sensible defaults when setting up the environment
[ https://issues.apache.org/jira/browse/QPID-2283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797474#action_12797474 ] Rajith Attapattu commented on QPID-2283: The first attempt at resolving the above is checked in at rev r891416 in Qpid trunk. java Testkit scripts should have sensible defaults when setting up the environment -- Key: QPID-2283 URL: https://issues.apache.org/jira/browse/QPID-2283 Project: Qpid Issue Type: Improvement Components: Java Tests Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.6 The scripts under java/testkit/bin should use sensible defaults when setting up the environment. It would be nice if the scripts first check if it's been run from an svn checkout and set the defaults accordingly. If not it should look for in well defined locations like PATH, PYTHONPATH etc.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
