Re: [VOTE] Committership Criteria
2009/12/8 Rafael Schloming rafa...@redhat.com: 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 Please cast your vote below: [ +1 ] Adopt the above statements as our official committership criteria. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
+1 Adopt the below statements as our official committership criteria. regards, Sam. 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 Please cast your vote below: [ ] Adopt the above statements as our official committership criteria. --Rafael - 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: Project Etiquette
Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
FWIW, the stuff I wrote was all intended for the benefit of new guys especially, even though I think it is equally good for us to have it written down for ourselves. I'm happy to add to it with some guidelines specifically for new contributors, I'm just less sure of what those are since it's been a while since I was a new contributor. If anyone has specific suggestions, please post and I'm happy to try to incorporate them somehow. As I mentioned, this wasn't intended to be a complete and definitive document, just a start that can evolve. --Rafael Sam Joyce wrote: Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... 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
[QMF] public github repo for QMFv2 api work
Hi all, Just fyi - I've set up a public git repo at github so I can develop the QMFv2 API code publicly. I've created this because I am not a committer, but I want this stuff available to all during development. git://github.com/kgiusti/qpid.git This repo is based on the apache qpid trunk repo on github. thanks, -K - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? - 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 The above is I think a particularly important point. For new features or components it is vital that there is a clear attempt to build consensus as to the approach taken. Its also important that other members of the community be actively encouraged to try it out and that doing this is made fairly easy. It's often harder to demonstrate collaboration and consensus based development on a new component than it is for fixes and enhancements to existing code (that hopefully already has users and maintainers who will point out issues or ask questions). However it is especially relevant in those situations (to prevent accumulating code that does not have users or maintainers). - 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 Please cast your vote below: [ ] Adopt the above statements as our official committership criteria. --Rafael - 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: First Qpid 0.6 Beta Release available for download and testing
On 12/07/2009 11:04 AM, Andrew Stitcher wrote: On Mon, 2009-12-07 at 10:28 -0500, Alan Conway wrote: On 12/04/2009 12:20 PM, Andrew Stitcher wrote: On Fri, 2009-12-04 at 11:07 -0500, Alan Conway wrote: ...On 12/02/2009 07:53 PM, Andrew Stitcher wrote: Cmake build is mostly fine - however the clustering module doesn't build due to a complication of recent versions of boost. The cluster cluster test build pass for me on f11 with boost-1.37.0-7.fc11.x86_64, which is the yum latest. Is there a machine I can log into where you see the problem? In response - I don't understand how you can be building this! The StoreStatus.o has references to symbols that are only in libboost_system but it's not directly linked. However having said this I also can't understand why the autotools build does work by the same token - it's a bit of a mystery! ldd shows that in my build cluster.so is indeed linked with boost_system-mt. [acon...@rolf cmake]$ ldd src/cluster.so | grep boost libboost_filesystem-mt.so.4 = /usr/lib64/libboost_filesystem-mt.so.4 (0x7f1d97f67000) libboost_program_options-mt.so.4 = /usr/lib64/libboost_program_options-mt.so.4 (0x7f1d978ac000) libboost_system-mt.so.4 = /usr/lib64/libboost_system-mt.so.4 (0x7f1d95f44000) Also note that libcommon uses boost::filesystem and links without problems, although perhaps StoreStatus is using different symbols. What missing symbols are you seeing? Ok, I haven't explained in enough detail: libqpidcommon isn't a problem because by default shared objects are allowed to have unresolved symbols at link time on the Unix systems I know - if they weren't resolved at the run time load you'd get an error - generally sigkill to the process. ldd doesn't tell you what you need to know here as it gives the transitive linkage - ie in this case libboost_system is loaded because libboost_filesystem requires it. To get the actual (non transitive) requires of an object you need to use objdump -p. When we build plugin modules for qpid we tell the linker to give an error if it finds unresolved symbols when linking against the non transitive requirements (--no-undefined to the linker -Wl,--no-undefined to the compiler). It's possible that libtool adds another option to make it check the symbols transitively, which would explain why the autotools build works, but I can't see why your cmake build could be different from mine. My cmake build does not have those flags in the link line for cluster.so: /usr/bin/ccache /usr/bin/distcc g++ -fPIC -g -O -shared -Wl,-soname,cluster.so -o cluster.so CMakeFiles/cluster.dir/qpid/cluster/Quorum_cman.o CMakeFiles/cluster.dir/qpid/cluster/Cluster.o CMakeFiles/cluster.dir/qpid/cluster/Decoder.o CMakeFiles/cluster.dir/qpid/cluster/ClusterMap.o CMakeFiles/cluster.dir/qpid/cluster/ClusterPlugin.o CMakeFiles/cluster.dir/qpid/cluster/Connection.o CMakeFiles/cluster.dir/qpid/cluster/ConnectionCodec.o CMakeFiles/cluster.dir/qpid/cluster/Cpg.o CMakeFiles/cluster.dir/qpid/cluster/UpdateClient.o CMakeFiles/cluster.dir/qpid/cluster/RetractClient.o CMakeFiles/cluster.dir/qpid/cluster/ErrorCheck.o CMakeFiles/cluster.dir/qpid/cluster/Event.o CMakeFiles/cluster.dir/qpid/cluster/EventFrame.o CMakeFiles/cluster.dir/qpid/cluster/ExpiryPolicy.o CMakeFiles/cluster.dir/qpid/cluster/FailoverExchange.o CMakeFiles/cluster.dir/qpid/cluster/Multicaster.o CMakeFiles/cluster.dir/qpid/cluster/OutputInterceptor.o CMakeFiles/cluster.dir/qpid/cluster/PollerDispatch.o CMakeFiles/cluster.dir/qpid/cluster/InitialStatusMap.o CMakeFiles/cluster.dir/qpid/cluster/MemberSet.o CMakeFiles/cluster.dir/qpid/cluster/StoreStatus.o -lcpg -lcman libqpidbroker.so.0.6 libqpidclient.so.0.6 -lboost_filesystem-mt libqpidcommon.so.0.6 -lboost_program_options-mt -lboost_filesystem-mt -luuid -ldl -lrt -lsasl2 -Wl,-rpath,/home/aconway/qpid/qpid/cmake/src I don't know why those flags aren't present, maybe something wrong with the CMAKE_COMPILER_IS_GNUCXX that's causing it to fail on my box? How can I debug what cmake is doing here? The symbols that are unresolved in all of the shared objects that use boost_filesystem due to inline expansions of things from it are: U boost::system::get_system_category() U boost::system::get_generic_category() Yep, they're undefined for me as well but not causing a compile error due to the missing flags. I'm still not clear on what the solution is here: - drop the --no-undefined-flags - explicitly link with boost system if present We could drop the --no-undefined flag for cluster.so only as a workaround if linking with boost system is tricky. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On 12/08/2009 02:34 PM, 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 Please cast your vote below: [+1] Adopt the above statements as our official committership criteria. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2253) Cluster node shutsdown with inconsistent error
Cluster node shutsdown with inconsistent error --- Key: QPID-2253 URL: https://issues.apache.org/jira/browse/QPID-2253 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.6 Description of problem: When running the test_failover test case in the qpid-python-testkit framework where cluster nodes are shutdown and new members are added, a new node just joined encounters an error of the form confirmed N but only sent N-1 which is only raised on the said member causing it to shut down as inconsistent. Version-Release number of selected component (if applicable): qpid trunk How reproducible: Always Steps to Reproduce: 1. checkout svn 2. build c++ broker and cluster module 3. go to java/testkit/bin and run ./qpid-python-testkit Actual results: cluster2-5: 2009-12-04 14:44:35 notice cluster(192.168.1.103:14491 READY) caught up, active cluster member. cluster2-5: 2009-12-04 14:44:36 error Execution exception: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 critical cluster(192.168.1.103:14491 READY/error) local error 599 did not occur on member 192.168.1.103:14453: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 error Error delivering frames: local error did not occur on all cluster members : invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) (qpid/cluster/ErrorCheck.cpp:89) cluster2-5: 2009-12-04 14:44:36 notice cluster(192.168.1.103:14491 LEFT/error) leaving cluster cluster2-helaya:13958 cluster2-5: 2009-12-04 14:44:36 notice Shut down Expected results: There should not be any inconsistent errors. -- 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: [VOTE] Committership Criteria
-Original Message- From: Rafael Schloming [mailto:rafa...@redhat.com] Sent: 08 December 2009 19:34 To: dev@qpid.apache.org Subject: [VOTE] Committership Criteria 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 Please cast your vote below: [+1] Adopt the above statements as our official committership criteria. Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On 12/09/2009 03:06 PM, Gordon Sim wrote: On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? Just to be clear, I am not opposing the vote here. I'm just suggesting that by spelling out how our project is structured and how we work we cold make the list of qualities more precise. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
2009/12/9 Gordon Sim g...@redhat.com On 12/09/2009 03:06 PM, Gordon Sim wrote: On 12/08/2009 07:34 PM, Rafael Schloming wrote: As there have been no comments or questions on the discussion thread, I'm going to move this to a vote: Sorry for jumping in late here, I was away on holiday when the mail was first sent. Qualities we look for: - A candidate must demonstrate an understanding of how our project is structured and how we work. Could we make this a bit more concrete/specific? For me the key to how we work is a collaborative, consensus based approach to development. What is meant by project structure here? A knowledge of the different components and how they are intended to work as a whole? Or an appreciation of the individuals that work on particular areas (i.e. the team structure)? Or something else? Just to be clear, I am not opposing the vote here. I'm just suggesting that by spelling out how our project is structured and how we work we cold make the list of qualities more precise. Defining how we work and how our project is structured is probably a separate document and a separate vote... I think some of the other threads recently have been moving us forward on those points, and I would like to see that work completed as soon as possible. It doesn't seem to me, however, to be a barrier to voting in the Committership Criteria that we have not yet formally defined these, since we may anyway change our structure and practice over time. -- Rob - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-2253) Cluster node shutsdown with inconsistent error
[ https://issues.apache.org/jira/browse/QPID-2253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-2253. --- Resolution: Fixed Fixed in r74 Cluster node shutsdown with inconsistent error --- Key: QPID-2253 URL: https://issues.apache.org/jira/browse/QPID-2253 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.6 Description of problem: When running the test_failover test case in the qpid-python-testkit framework where cluster nodes are shutdown and new members are added, a new node just joined encounters an error of the form confirmed N but only sent N-1 which is only raised on the said member causing it to shut down as inconsistent. Version-Release number of selected component (if applicable): qpid trunk How reproducible: Always Steps to Reproduce: 1. checkout svn 2. build c++ broker and cluster module 3. go to java/testkit/bin and run ./qpid-python-testkit Actual results: cluster2-5: 2009-12-04 14:44:35 notice cluster(192.168.1.103:14491 READY) caught up, active cluster member. cluster2-5: 2009-12-04 14:44:36 error Execution exception: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 critical cluster(192.168.1.103:14491 READY/error) local error 599 did not occur on member 192.168.1.103:14453: invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) cluster2-5: 2009-12-04 14:44:36 error Error delivering frames: local error did not occur on all cluster members : invalid-argument: anonymous.e3a66a8d-330d-47c2-b96d-bb0b1315248b: confirmed (2+0) but only sent (1+0) (qpid/SessionState.cpp:151) (qpid/cluster/ErrorCheck.cpp:89) cluster2-5: 2009-12-04 14:44:36 notice cluster(192.168.1.103:14491 LEFT/error) leaving cluster cluster2-helaya:13958 cluster2-5: 2009-12-04 14:44:36 notice Shut down Expected results: There should not be any inconsistent errors. -- 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: First Qpid 0.6 Beta Release available for download and testing
The single component package for QMan is not currently being created (although I seem to recall this happening with 0.5 as well). I think it uses a slightly non standard target to build the package just now, so ill see if I can modify it to be the same as the others and then the release script just needs updated to perform the copy. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 03 December 2009 00:54 To: dev@qpid.apache.org Subject: First Qpid 0.6 Beta Release available for download and testing Apologies for the long message, but there actually is a fair bit to say: I've uploaded the artifacts for a 0.6 beta release to qpid.apache.org: http://qpid.apache.org/dist/qpid-0.6beta1/ Please download and test this release. No, really, please download and at least look at it. I've called it a beta because, it seems to me in the area that I know (C ++) and in the currently outstanding bugs it seems very usable. I plan that every one should give this a good beating for 1-2 weeks and then I'll spin a release candidate, or if there are many problems found and fixed a beta2. So all being well I'd like to vote on releasing 0.6 in a couple of weeks. --- The status of this beta: My testing has been building the C++ tar source under various linux platforms (using this release or very slightly earlier ones). Essentially configure; make check. Fedora 11/Fedora 12 (these both tested with the same results): Autotools build is fine including all broker modules. It doesn't seem that the build as it stands in the C++ source release builds the qmf bindings. Cmake build is mostly fine - however the clustering module doesn't build due to a complication of recent versions of boost. And r886259 breaks building the clustering tests (due to missing the new tests/cluster.cmake from EXTRA_DIST) Red Hat Enterprise Linux 5: Autotools builds fine. Cmake builds fine (but this was a slightly earlier release and this would have been broken by r886259 as above). Debian 5 (lenny). Neither the clustering module nor the XML module have their necessary prerequisites so can't be built here. Given this both autotools and cmake builds were fine. --- Overall Release Status: I've put up a page for the release on the wiki: http://cwiki.apache.org/confluence/display/qpid/0.6+Release (don't use the mirror on qpid.apache.org as it won't have the dynamically updated bug list) Please edit the release page to add your understanding to it - it's a little biased to the areas that I know about presently. One area that needs attention is the Release notes, I appeal to you to add any release notes to that wiki page and I will turn them into something to put in the release itself. Otherwise the only release notes will be for the C++ code and whatever I can get from the 0.6 fixed bugs. --- Deficiencies: I've removed the separate dotnet package from the release as it doesn't build for me using the release script. More about this separately. I've not packaged the wcf code separately as I've no idea how it should look and I doubt I could build it under Linux anyway. I'm concerned there appear to be 5 13Mb eclipse plugins labelled for various platforms - is this really necessary - it certainly took a long time to upload and constitutes a large amount of space. --- At this point I suggest that any bugs important enough to be fixed before the 0.6 release should be tagged with Fix version 0.6 and be a blocker or critical. So if you find an issue that must be fixed before release then put it in Jira like this. Conversely if you know of a bug that is in this state that can be resolved then resolve it poste haste. I will assume that as long as there *any* bugs like this 0.6 release is blocked. Regards 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
Feedback from Qpid users
Hi, During the FUDCon in Toronto last weekend, I was pleasantly surprised to see that Qpid was used in several upstream projects connected to the Fedora community. However the feedback from the folks I spoke to shows that we could certainly do better to make the end user experience work. On the bright side it seems we are on track to resolve these issues. The top 3 complains I heard from people. 1. The Qpid documentation is incomplete, disorganized and often lacking crucial information completely. (Ex. there is no guide for SASL setup in the c++ broker) 2. The documentation does not reflect the code. Especially documentation for clients was poor. 3. The clients (non JMS) are difficult to use without reasonable knowledge about AMQP. I think items 1 2 will be addressed to a reasonable extent with re-organizing our website and having version controlled documentation in svn. Item 3 would be addressed by our current effort around high level client APIs - infact many said that is what they need. 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
Re: Release artifacts
Robbie Gemmell wrote: Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. I think it's a bit late for 0.6, if I understand the timeline correctly. The Java broker, client, and tools multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. I sort of disagree with this. There is a philosophy behind using the just a copy approach. The benefit is that we can eliminate a whole class of bugs resulting from complex transformations necessary to turn the build artifacts into release artifacts. Not to mention it is easier for us to reproducer user issues if dev and user environments are as similar as possible. That said I'm fine cleaning up the release artifacts and what not, I'm just -1 on doing it by introducing complex transformations between build and release artifacts. If we want the release artifacts to look different we should make the build artifacts look different. As I've said before I'm happy to help with this, but we sort of need to figure out what we want things to look like first, and IMHO such an effort should also include making release artifacts more consistent across the whole project. Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the full release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. I also think it's a shame that our artifacts look like they come from entirely different projects. Even little things like readme capitalization, general directory layout, etc is completely different from artifact to artifact, and this is even after the release script hacks to rearchive stuff to make things a bit more consistent. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Committership Criteria
On Tue, Dec 8, 2009 at 7:34 PM, Rafael Schloming rafa...@redhat.com wrote: [ ] Adopt the above statements as our official committership criteria. +1 - 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
Documentation (was Re: Feedback from Qpid users)
Rajith, Everyone: 1. The Qpid documentation is incomplete, disorganized and often 2. The documentation does not reflect the code. Especially 3. The clients (non JMS) are difficult to use without reasonable knowledge about AMQP. I had an article on QPid in the November issue of Linux Journal. Thankfully, the author's contract for LJ permits me to use the article in project documentation after the magazine has been out for a month. My article specifically addresses how to set up a C++ broker and Python clients and use them in several configurations (direct, pub-sub). I am more than happy to contribute this. To whom should I send it to review for inclusion in the docs? Thanks, -Joshua Kramer -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Release artifacts
I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together. Robbie -Original Message- From: Rafael Schloming [mailto:rafa...@redhat.com] Sent: 09 December 2009 17:17 To: dev@qpid.apache.org Subject: Re: Release artifacts Robbie Gemmell wrote: Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. I think it's a bit late for 0.6, if I understand the timeline correctly. The Java broker, client, and tools multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. I sort of disagree with this. There is a philosophy behind using the just a copy approach. The benefit is that we can eliminate a whole class of bugs resulting from complex transformations necessary to turn the build artifacts into release artifacts. Not to mention it is easier for us to reproducer user issues if dev and user environments are as similar as possible. That said I'm fine cleaning up the release artifacts and what not, I'm just -1 on doing it by introducing complex transformations between build and release artifacts. If we want the release artifacts to look different we should make the build artifacts look different. As I've said before I'm happy to help with this, but we sort of need to figure out what we want things to look like first, and IMHO such an effort should also include making release artifacts more consistent across the whole project. Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi- component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the full release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. I also think it's a shame that our artifacts look like they come from entirely different projects. Even little things like readme capitalization, general directory layout, etc is completely different from artifact to artifact, and this is even after the release script hacks to rearchive stuff to make things a bit more consistent. --Rafael - 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: Release artifacts
2009/12/9 Rafael Schloming rafa...@redhat.com Robbie Gemmell wrote: Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. I think it's a bit late for 0.6, if I understand the timeline correctly. The Java broker, client, and tools multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. I sort of disagree with this. There is a philosophy behind using the just a copy approach. The benefit is that we can eliminate a whole class of bugs resulting from complex transformations necessary to turn the build artifacts into release artifacts. Not to mention it is easier for us to reproducer user issues if dev and user environments are as similar as possible. That said I'm fine cleaning up the release artifacts and what not, I'm just -1 on doing it by introducing complex transformations between build and release artifacts. If we want the release artifacts to look different we should make the build artifacts look different. As I've said before I'm happy to help with this, but we sort of need to figure out what we want things to look like first, and IMHO such an effort should also include making release artifacts more consistent across the whole project. I think this is the key point - we need to work out how our build and release artefacts look; since what we have today is clearly unsatisfactory. If there are quick, non-risky, changes that we could put in place for 0.6 that are universally acknowledged as a step in the right direction, I wouldn't necessarily be against them - however I don't think we want to embark on anything that will negatively impact a 0.6 release date at this stage. I am hugely +1 in doing this work before 0.7 (it's clearly a necessity for us if we ever want to get to a 1.0 release) Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the full release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. I also think it's a shame that our artifacts look like they come from entirely different projects. Even little things like readme capitalization, general directory layout, etc is completely different from artifact to artifact, and this is even after the release script hacks to rearchive stuff to make things a bit more consistent. Agree again completely. We have a lot of work to do - which we should do as a matter of priority - in sorting out our artefacts to present a more consistent appearance across the project. -- Rob --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2254) Documentation: Review attached article for inclusion in documentation
Documentation: Review attached article for inclusion in documentation - Key: QPID-2254 URL: https://issues.apache.org/jira/browse/QPID-2254 Project: Qpid Issue Type: Task Components: C++ Broker, Python Client, Qpid Examples Affects Versions: 0.5, M4 Environment: RHEL / CentOS 5.4 Reporter: Joshua Kramer For an improvement to the documentation, I have attached my article that appeared in November 2009 Linux Journal. -- 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-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Listing2.py Listing1.py AMQP-Article-Final.txt Documentation: Review attached article for inclusion in documentation - Key: QPID-2254 URL: https://issues.apache.org/jira/browse/QPID-2254 Project: Qpid Issue Type: Task Components: C++ Broker, Python Client, Qpid Examples Affects Versions: M4, 0.5 Environment: RHEL / CentOS 5.4 Reporter: Joshua Kramer Attachments: AMQP-Article-Final.txt, Listing1.py, Listing2.py For an improvement to the documentation, I have attached my article that appeared in November 2009 Linux Journal. -- 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-2255) new API doesn't properly parse mime types when interpreting message content
new API doesn't properly parse mime types when interpreting message content --- Key: QPID-2255 URL: https://issues.apache.org/jira/browse/QPID-2255 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.6 Reporter: Rafael H. Schloming Assignee: Rafael H. Schloming the python impl of the new API just does a simple lookup on mime types rather than parsing them properly, e.g. it should correctly handle. text/plain vs text/plain; charset=utf8 -- 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-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Figure1-v2.pdf Listing4.py Listing3.py Documentation: Review attached article for inclusion in documentation - Key: QPID-2254 URL: https://issues.apache.org/jira/browse/QPID-2254 Project: Qpid Issue Type: Task Components: C++ Broker, Python Client, Qpid Examples Affects Versions: M4, 0.5 Environment: RHEL / CentOS 5.4 Reporter: Joshua Kramer Attachments: AMQP-Article-Final.txt, Figure1-v2.pdf, Listing1.py, Listing2.py, Listing3.py, Listing4.py For an improvement to the documentation, I have attached my article that appeared in November 2009 Linux Journal. -- 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-2254) Documentation: Review attached article for inclusion in documentation
[ https://issues.apache.org/jira/browse/QPID-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Kramer updated QPID-2254: Attachment: Figure1-v2.png Documentation: Review attached article for inclusion in documentation - Key: QPID-2254 URL: https://issues.apache.org/jira/browse/QPID-2254 Project: Qpid Issue Type: Task Components: C++ Broker, Python Client, Qpid Examples Affects Versions: M4, 0.5 Environment: RHEL / CentOS 5.4 Reporter: Joshua Kramer Attachments: AMQP-Article-Final.txt, Figure1-v2.pdf, Figure1-v2.png, Listing1.py, Listing2.py, Listing3.py, Listing4.py For an improvement to the documentation, I have attached my article that appeared in November 2009 Linux Journal. -- 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: Release artifacts
I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are. Robbie -Original Message- From: Rafael Schloming [mailto:rafa...@redhat.com] Sent: 09 December 2009 17:45 To: dev@qpid.apache.org Subject: Re: Release artifacts Robbie Gemmell wrote: I'm not meaning to suggest doing any complex transformations, rather using what is already there. We have single-component packages that we already release separately for all these items, I'm just talking about whacking the relevant ones in a new tar and calling job done, instead of having a mashup that contains things people don't want or that can't even be used together. My issue with this is that the single-component packages weren't done according to the philosophy of the build system, and as such the process for producing component release artifacts diverges somewhat significantly from the process for producing build artifacts. So while what you suggest might not involve additional complex transformations, it does result in something that I would prefer to avoid, which is two separate systems, one for producing build artifacts, and the other for producing release artifacts. --Rafael - 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: Release artifacts
On Wed, Dec 9, 2009 at 12:30 PM, Robert Godfrey rob.j.godf...@gmail.com wrote: 2009/12/9 Rafael Schloming rafa...@redhat.com Robbie Gemmell wrote: Hi all, Now that we have entered another release phase I think it would be a good time to discuss the release artifacts. I would like to see 0.6 ship with some updates to the artifacts we produce to make things more useful and obvious for our users. I think it's a bit late for 0.6, if I understand the timeline correctly.  The Java broker, client, and tools multi-component package appears to be just a copy of the etc/ lib/ and bin/ directories from the qpid/java/build/ dir after performing a build and this makes it quite messy. A lot of test configuration files are left in the etc/ dir and there are loads of jars in the lib/ dir, which make it very hard to know which is being used where or allow splitting them up easily. You also end up with jars that just aren't intended to be used from there (eg the eclipse-plugin used in the JMX Management Console releases). We have single component packages for the Java broker, client, and management tools so if we want a multi-component package including any of these I think we should simply bundle those up instead of just tarring the build folder and mashing everything together. I sort of disagree with this. There is a philosophy behind using the just a copy approach. The benefit is that we can eliminate a whole class of bugs resulting from complex transformations necessary to turn the build artifacts into release artifacts. Not to mention it is easier for us to reproducer user issues if dev and user environments are as similar as possible. That said I'm fine cleaning up the release artifacts and what not, I'm just -1 on doing it by introducing complex transformations between build and release artifacts. If we want the release artifacts to look different we should make the build artifacts look different. As I've said before I'm happy to help with this, but we sort of need to figure out what we want things to look like first, and IMHO such an effort should also include making release artifacts more consistent across the whole project. I think this is the key point - we need to work out how our build and release artefacts look; since what we have today is clearly unsatisfactory. If there are quick, non-risky, changes that we could put in place for 0.6 that are universally acknowledged as a step in the right direction, I wouldn't necessarily be against them - however I don't think we want to embark on anything that will negatively impact a 0.6 release date at this stage.  I am hugely +1 in doing this work before 0.7 (it's clearly a necessity for us if we ever want to get to a 1.0 release) Totally agree here. I think for the 0.7 release we definitely need to consider sorting out our documentation and release artifacts a top priority. I also agree that we need to have a consistent story across all our components than a per language approach.  Another result of the above is that QMan is shipped in the Java multi-component bundle despite the fact it is only useful if you have a C++ broker. I realise it is written in Java, but those packages don't seem to me like they should necessarily be language specific. If anything I would say that QMan should surely ship in the multi-component bundle along with the items it can actually be used with (ie the C++ broker and client bundle), or just be made available standalone (which it already is). Users aren't necessarily going to expect they need to download both multi-component packages to make use of everything contained in one of them, and as mentioned above, splitting QMan alone out of the java multi-component bundle would be a bit hideous and non obvious anyway. I would also like to see us tagging the source-only release artifacts with 'src', ie the C++ and the full release artifact that is just a copy of the entire repo. It isn't exactly helpful for a user to download the 50MB file then find out what they are looking for isn't actually in there. I also think it's a shame that our artifacts look like they come from entirely different projects. Even little things like readme capitalization, general directory layout, etc is completely different from artifact to artifact, and this is even after the release script hacks to rearchive stuff to make things a bit more consistent. Agree again completely.  We have a lot of work to do - which we should do as a matter of priority - in sorting out  our artefacts to present a more consistent appearance across the project. -- Rob --Rafael - Apache Qpid - AMQP Messaging Implementation Project:    http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
Re: Documentation (was Re: Feedback from Qpid users)
On Wed, Dec 9, 2009 at 1:57 PM, Joshua Kramer j...@globalherald.net wrote: Rajith, Everyone: 1. The Qpid documentation is incomplete, disorganized and often 2. The documentation does not reflect the code. Â Especially 3. The clients (non JMS) are difficult to use without reasonable knowledge about AMQP. I had an article on QPid in the November issue of Linux Journal. Thankfully, the author's contract for LJ permits me to use the article in project documentation after the magazine has been out for a month. My article specifically addresses how to set up a C++ broker and Python clients and use them in several configurations (direct, pub-sub). Â I am more than happy to contribute this. Â To whom should I send it to review for inclusion in the docs? +1 Thanks for doing this and I hope you continue to help. Once you attach it to JIRA we could try to incorporate it into the documentation that we are trying to put in place in svn. Jonathan is currently trying to organize this effort. Once the structure is put in place you could directly submit patches against the doc-book source. Currently there is a lot of gaps and contributions are most welcome. However I'd wait until Jonathan gets a chance to take stock of the existing docs and port it to the new format. That way we could ensure no effort is duplicated. Thanks, -Joshua Kramer -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: Â Â Â http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- 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] Created: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.5 Reporter: Alan Conway Assignee: Alan Conway Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5b162 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::handleAdder::operator() (this=0x4357dad0, ptr=0x1acd4bc0) at ../../cpp/src/qpid/sys/DeletionManager.h:128 #6 0x2af116f5b1d3 in
Blocker for 0.6 release
I think this is a blocker for the release. I'm looking into it. It does not appear to be a cluster-specific problem although cluster_test is the only way I know to reproduce it at this point. https://issues.apache.org/jira/browse/QPID-2256 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: C++ broker: LockFile and shutdown (eliminating pid_t)
On Tue, 2009-12-08 at 18:25 -0500, Steve Huston wrote: Hi Andrew, I'm looking at QPID-1951: Eliminating ssize_t is trivial. Ok. pid_t is used in a few more places though. However it is only used in connection with LockFile. Either internally in Lockfile or to communicate a pid out of LockFile so that the process can be signalled. The other things the pid is used for are: It's not using the pid that is a problem per se it's using the type pid_t. So if you are using a DWORD type coming from GetCurrentProcessId() then this is not an issue. Also using pid_t in purely posix code isn't an issue as the windows code never sees it. The issue is using pid_t in the platform independent code. - print it to cout (Windows, posix) - use it to open a handle to the broker process (Windows) Ah yes, I see that now - it looks like it would be encapsulatable though or replaced with another event, as it's being used not for signalling but to detect process exit. It seems to me that the entire LockFile class could be better factored to eliminate passing non portable process ids around by delegating signalling the other process to the LockFile class itself. I would change the name to something else at that point (suggestions?). In that case the lockfile itself becomes just an internal part of the signalling mechanism. Following in that direction it looks to me like for Windows at least doing this allows you to entirely replace the lock file itself with the named event that is already being used. No, the pid is still needed to get a handle to the process that's being signalled. As above actually not for the signalling itself though. Steve, Alan (as you are both mostly responsible for these implementations) is there anything I'm missing here or is this a good direction? It seems the pid is still needed; maybe using a qpid::pid_t type would be easier? Probably easier, but not necessarily better! I'll fiddle around a bit and see if I can get something simple enough. Andrew -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-2256: -- Affects Version/s: (was: 0.5) 0.6 cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Alan Conway Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at
[jira] Commented: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788259#action_12788259 ] Andrew Stitcher commented on QPID-2256: --- This might be related to having client and broker in the same process, as under this one case the DeletionManager would be shared. cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Alan Conway Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at
Re: Release artifacts
Robbie Gemmell wrote: I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are. I'm saying more than just always generate the release style artifacts, they need to be generated in such a way that starting up a devel server is using the same scripting and artifacts that the end user encounters when they attempt the same sort of exercise from the release tarball. Moreover I'm saying that there should be no such thing as release style artifacts, only build artifacts, and the various release tarballs should simply be archives (either whole or in part) of the build artifacts. And on top of all this it needs to be simple, fast, and properly do incremental builds so that it's actually usable for those of us who have chosen not to participate in this passing IDE fad. ;) I don't want to seem discouraging, I agree with your goals, I'm just particular about how we get there and I'm not eager to pile another quick hack on top of things. Doing all this without hacks shouldn't be terribly difficult as long as we figure out what we want first and choose something sensible. --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1753) Create QMan / WsDmAdapter package
[ https://issues.apache.org/jira/browse/QPID-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-1753: - Fix Version/s: (was: 0.5) 0.6 Assignee: Robbie Gemmell (was: Martin Ritchie) Create QMan / WsDmAdapter package - Key: QPID-1753 URL: https://issues.apache.org/jira/browse/QPID-1753 Project: Qpid Issue Type: Sub-task Components: Build Tools Reporter: Martin Ritchie Assignee: Robbie Gemmell Fix For: 0.6 -- 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-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788275#action_12788275 ] Alan Conway commented on QPID-2256: --- There is a lock hierarchy error causing the deadlock as follows # threads 1-6,8,9 DeletionManager::destroyThreadState threadStatus-lock AllThreadsStatuses::delThreadStatus lock # thread 7 AllThreadsStatuses::handleAdder ptr-lock AllThreadsStatuses::addHandle lock ptr-lock And threadStatus == ptr threadStatus == ptr and the same AllThreadsStatuses instance is involved in all cases. cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Alan Conway Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait ()
[jira] Created: (QPID-2257) Tests for Transactional WCF channel
Tests for Transactional WCF channel --- Key: QPID-2257 URL: https://issues.apache.org/jira/browse/QPID-2257 Project: Qpid Issue Type: Task Components: WCF/C++ Client Affects Versions: 0.6 Reporter: Devang Gandhi Fix For: 0.6 New tests are needed for the transactional functionality of the WCF channel. -- 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: Release artifacts
I think you have misunderstood what I meant by that entirely, as by the build system in general to always generate the release style artifacts I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO. Robbie -Original Message- From: Rafael Schloming [mailto:rafa...@redhat.com] Sent: 09 December 2009 19:38 To: dev@qpid.apache.org Subject: Re: Release artifacts Robbie Gemmell wrote: I can see what you are saying and thus agree that it would be beneficial for the build system in general to always generate the release style artifacts. However I don't see that this means we shouldn't use what we have at our disposal now in order to give our users a better experience than we currently are. I'm saying more than just always generate the release style artifacts, they need to be generated in such a way that starting up a devel server is using the same scripting and artifacts that the end user encounters when they attempt the same sort of exercise from the release tarball. Moreover I'm saying that there should be no such thing as release style artifacts, only build artifacts, and the various release tarballs should simply be archives (either whole or in part) of the build artifacts. And on top of all this it needs to be simple, fast, and properly do incremental builds so that it's actually usable for those of us who have chosen not to participate in this passing IDE fad. ;) I don't want to seem discouraging, I agree with your goals, I'm just particular about how we get there and I'm not eager to pile another quick hack on top of things. Doing all this without hacks shouldn't be terribly difficult as long as we figure out what we want first and choose something sensible. --Rafael - 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
[jira] Assigned: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-2256: - Assignee: Andrew Stitcher (was: Alan Conway) cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4357da30, l...@0x1acd4bc0) at
[jira] Commented: (QPID-1753) Create QMan / WsDmAdapter package
[ https://issues.apache.org/jira/browse/QPID-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788284#action_12788284 ] Robbie Gemmell commented on QPID-1753: -- Updated the build.xml for the QMan module to override the dummy holder release-bin task from module.xml and invoke its packaging process. Updated the release.sh script to copy the artifact during release. Create QMan / WsDmAdapter package - Key: QPID-1753 URL: https://issues.apache.org/jira/browse/QPID-1753 Project: Qpid Issue Type: Sub-task Components: Build Tools Reporter: Martin Ritchie Assignee: Robbie Gemmell Fix For: 0.6 -- 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: Release artifacts
Robbie Gemmell wrote: I think you have misunderstood what I meant by that entirely, as by the build system in general to always generate the release style artifacts I meant exactly what you are suggesting, that the build system should be modified to generate something we can simply take a (partial) tarball of and end up with what we release...ie release style. The reason there is anything else in place right now is that they arent, IMO. Sorry, I see how you meant that now. My mistake. Clearly I've been too eager to rant recently. ;) --Rafael - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently Is it not possible for us to create a branch and give Ken commit rights *only* to the branch? As long as he has signed the CLA that should be much simpler all round since someone just has to merge - Ken could use Jiras or the mailing list to prompt a buddy to review and merge at appropriate points. For the rest of us who are interested in what is going on but not so interested that we are willing to mess about with patches from Jira this would be better too. Steve, as someone who had to go through the process of jiras relatively recently, would that have been easier for you? Thanks, Robert - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Robert Greig wrote: I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently Is it not possible for us to create a branch and give Ken commit rights *only* to the branch? As long as he has signed the CLA that should be much simpler all round since someone just has to merge - Ken could use Jiras or the mailing list to prompt a buddy to review and merge at appropriate points. For the rest of us who are interested in what is going on but not so interested that we are willing to mess about with patches from Jira this would be better too. Steve, as someone who had to go through the process of jiras relatively recently, would that have been easier for you? In the ASF, unfortunately to give commit rights to anything we need to get through the committer nomination and vote process. He can hold a GIT and then update JIRA with patches as he goes and someone then has to take the patches from from JIRA due to lic issues on the JIRA click through. best if for new people to be visible on the project and lists to get to committership. Carl.
Re: [VOTE] Committership Criteria
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 Please cast your vote below: [ ] Adopt the above statements as our official committership criteria. [+1] Adopt the above statements as our official committership criteria.
Re: [QMF] public github repo for QMFv2 api work
2009/12/9 Carl Trieloff cctriel...@redhat.com: In the ASF, unfortunately to give commit rights to anything we need to get through the committer nomination and vote process. Do you (or anyone else) know what the rationale for this is? Thanks, Robert - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Project Etiquette
Hi Rafi, Thanks for taking the time to write these. I think they're a good idea to have for new people. At risk of incurring your wrath - I found it them a little long, at first reading. I wonder if you'd consider a more concise version - be happy to have a shot at it if that'd be helpful and not cross making ? I'd like to think we should welcome people in, tell them what they might need to know but I'm hoping we won't scare them off. What do you think ? Regards, Marnie On Wed, Dec 9, 2009 at 11:55 AM, Rafael Schloming rafa...@redhat.comwrote: FWIW, the stuff I wrote was all intended for the benefit of new guys especially, even though I think it is equally good for us to have it written down for ourselves. I'm happy to add to it with some guidelines specifically for new contributors, I'm just less sure of what those are since it's been a while since I was a new contributor. If anyone has specific suggestions, please post and I'm happy to try to incorporate them somehow. As I mentioned, this wasn't intended to be a complete and definitive document, just a start that can evolve. --Rafael Sam Joyce wrote: Hi Folks, Personally I think Carl's idea is a good one, as I am new :) I was involved with QPID and AMQP a few years ago and have only just come back to the fold. I think having a getting involved - etiquette section is a good idea. As has already been mentioned, there is a lot of latent awareness about how to go about things, but as a new member of the community it would certainly be of benefit to me to be able to read about it! cheers, Sam. Carl Trieloff wrote: Robert Godfrey wrote: 2009/12/8 Rafael Schloming rafa...@redhat.com A number of recent threads have made it clear that we have a fair amount of unspoken etiquette about how we do things around here, and the fact that it is unspoken can be confusing to newcomers and old-timers alike. Looking at a few other apache project web sites, they often seem to have a page or two devoted to documenting their project etiquette. I think this would be a good thing for us to have as well, and I've taken the liberty of trying to seed this effort with some content. I think there are some obvious places where it would make sense to formalize some of this etiquette into some lightweight process, e.g. having maintainers files in svn, having a sandbox for new code contributions, etc, however this text is *not* intended to be a proposal for that sort of thing, merely an attempt to put into words what I believe most of us consider to be the status quo wrt the unspoken etiquette of the project. Of course the problem with unspoken etiquette is that we might not all have the same concept of what it actually is, so please let me know if you disagree with something I've written or you think something important is missing. --Rafael All this sounds very sensible to me; and there's nothing I can immediately think of that I would like to add. Having this on a Getting Involved section of the website, along, perhaps, with a list of the Big Ideas people are currently working on would seem to make a lot of sense... -- Rob Should we also add a getting involved Etiquette section, i.e. if you are new, how should I work with the team... 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: [QMF] public github repo for QMFv2 api work
-Original Message- From: Robert Greig [mailto:robert.j.gr...@gmail.com] Sent: Wednesday, December 09, 2009 3:25 PM To: dev@qpid.apache.org Subject: Re: [QMF] public github repo for QMFv2 api work I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently Is it not possible for us to create a branch and give Ken commit rights *only* to the branch? As long as he has signed the CLA that should be much simpler all round since someone just has to merge - Ken could use Jiras or the mailing list to prompt a buddy to review and merge at appropriate points. For the rest of us who are interested in what is going on but not so interested that we are willing to mess about with patches from Jira this would be better too. Steve, as someone who had to go through the process of jiras relatively recently, would that have been easier for you? I think Carl's comments made this moot, but... Yes, it would have been easier for me at the time. But it would have been worse in the end. Having to do patches and jiras had the benefits: - Something to notify the community that there was something to review. Not being familiar with the personnel at the time, this was what got me some answers quickly on who was most related to what I needed to know. - Got me into the Apache Way quicker and I think it has helped in the long run. -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [QMF] public github repo for QMFv2 api work
Robert Greig wrote: 2009/12/9 Carl Trieloff cctriel...@redhat.com: In the ASF, unfortunately to give commit rights to anything we need to get through the committer nomination and vote process. Do you (or anyone else) know what the rationale for this is? Main thing is infra does not want to deal with high churn on accounts etc of people that may not stick around. So for net new committers for apache this is the process. Carl.
Re: [QMF] public github repo for QMFv2 api work
On Wed, 2009-12-09 at 20:25 +, Robert Greig wrote: I think the safest option is to expose your work through a series of JIRA's. If we need to make the code available immediately and/or collaborate with others we could create a branch. You could work off the branch and then Ted could apply the patches as an when they are made available. I think this approach - creating patches and applying them to Jira is very poor for several reasons: 1) it is a pain to create patches and attach them to jira (at least I think so) 2) it is a pain for a reviewer to extract them from the jira, review and commit 3) because of the above it encourages the large code drops that we have discussed recently I'd say that using git is pretty good for the purposes of working in the open conveniently but still producing patches attached to jiras. The alternative would be for Ken to work in private producing patches, at the end of the process. Surely working in the open based on the git.apache.org/qpid repo and producing git patches relative to that using git format-patch will ultimately make it very easy for anyone to apply the patches with no ambiguity, and in the meantime allow us to also pull from his work. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
On Wed, 2009-12-09 at 20:36 +, Robbie Gemmell wrote: I have updated (r888939) the build process to and release script so the QMan package is generated and copied over. Additionally, I have noticed that because you are using Git (presumably, since the ability was added recently) to do the checkout the Java modules are failing to identify the SVN revision used in the build and so are generating property files that contain exported where the revision should be, since svnversion didnt find the .svn folders. As a result, exported will show up wherever the revision would normally be mentioned, eg broker startup. The actual released artifacts were produced from an svn export, not git - that was for convenience leading up to a final release as svn export is slow because it needs to go over the internet. So that doesn't explain this (unless I've made a mistake). Andrew One way to handle this would be to add a property in the ant build process that can be set via command line in the release script with the value parsed from Git, and modify the build process to only use svnversion to figure it out the revision if that hasn't been set. That's certainly not in my skill set re java, I'm just about capable of running release.sh and seeing whether java built! Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: First Qpid 0.6 Beta Release available for download and testing
No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :) By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was). I will have a look at updating the Ant scripting to allow specifying the revision to handle this. Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 09 December 2009 21:55 To: dev@qpid.apache.org Subject: RE: First Qpid 0.6 Beta Release available for download and testing On Wed, 2009-12-09 at 20:36 +, Robbie Gemmell wrote: I have updated (r888939) the build process to and release script so the QMan package is generated and copied over. Additionally, I have noticed that because you are using Git (presumably, since the ability was added recently) to do the checkout the Java modules are failing to identify the SVN revision used in the build and so are generating property files that contain exported where the revision should be, since svnversion didnt find the .svn folders. As a result, exported will show up wherever the revision would normally be mentioned, eg broker startup. The actual released artifacts were produced from an svn export, not git - that was for convenience leading up to a final release as svn export is slow because it needs to go over the internet. So that doesn't explain this (unless I've made a mistake). Andrew One way to handle this would be to add a property in the ant build process that can be set via command line in the release script with the value parsed from Git, and modify the build process to only use svnversion to figure it out the revision if that hasn't been set. That's certainly not in my skill set re java, I'm just about capable of running release.sh and seeing whether java built! 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
[jira] Closed: (QPID-1027) verify script is sensitive to shell in use
[ https://issues.apache.org/jira/browse/QPID-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed QPID-1027. - Resolution: Won't Fix This doesn't seem to be a problem for most users, marking this wont fix. If we really wanted to fix it, there are probably more scripts than just verify that have bashisms. verify script is sensitive to shell in use -- Key: QPID-1027 URL: https://issues.apache.org/jira/browse/QPID-1027 Project: Qpid Issue Type: Bug Components: Qpid Examples Affects Versions: M4 Reporter: Senaka Fernando Assignee: Alan Conway Attachments: verify.patch.txt, verify_patch_java.patch.txt verify (found in C++ examples) script is sensitive to the shell in use. And, the fix incorporated in the attached patch that will specifically revert the script to use the type of shell in which it is being run. I was inspired by [1], which better describes the problem of scripts that are sensitive to the type of shell. [1] http://forum.java.sun.com/thread.jspa?messageID=9948827tstart=0 Regards, Senaka -- 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: First Qpid 0.6 Beta Release available for download and testing
On Wed, 2009-12-09 at 22:01 +, Robbie Gemmell wrote: No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :) By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was). I will have a look at updating the Ant scripting to allow specifying the revision to handle this. FWIW in that case this isn't a regression as I believe previous releases were produced using svn export also. A - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2258) [Java Broker] AMQP 0-9-1 Compliance issues
[Java Broker] AMQP 0-9-1 Compliance issues -- Key: QPID-2258 URL: https://issues.apache.org/jira/browse/QPID-2258 Project: Qpid Issue Type: Bug Components: Java Broker, Java Client, Java Tests Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.6 Testing for compliance with AMQP0-9-1 has shown up errors particuarly around dealing with the redeclaration of queues and handling queue exclusivity. When implementing these features (such as disallowing redeclaration from exclusive to non-exclusive or durable to non-durable) it became apparent that some of our system tests were performing such erroneous redeclaration. Fixes are mostly in the method handlers in the Java Broker -- 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-2259) Add static build support in cmake for Windows
Add static build support in cmake for Windows - Key: QPID-2259 URL: https://issues.apache.org/jira/browse/QPID-2259 Project: Qpid Issue Type: Improvement Components: Build Tools Environment: Windows XP SP3, VC++ 9.0 Reporter: Pete MacKinnon Some projects (e.g., Condor) that depend on qpid specifically for QMF integration require static builds of qpid cpp on Windows. Propose a new var (QPID_WINDOWS_STATIC) that when set makes available static release and debug configuration targets for VC++. -- 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] Resolved: (QPID-2256) cluster_test hangs with theads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-2256. --- Resolution: Fixed Fixed by removing unnecessary locking introduced by previous change for QPID-2214 cluster_test hangs with theads deadlocked on mutex in DeletionManager. -- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4357da30,
[jira] Created: (QPID-2260) Build of Release configuration fails
Build of Release configuration fails Key: QPID-2260 URL: https://issues.apache.org/jira/browse/QPID-2260 Project: Qpid Issue Type: Bug Components: WCF/C++ Client Affects Versions: 0.6 Environment: Windows Reporter: Cliff Jansen Priority: Blocker Fix For: 0.6 Locations for the Release intermediaries are not properly resolved. This is known issue #1 in the ReadMe.txt file and prevents non-debug versions of the code from building without user intervention. This should be easy to fix. -- 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-2256) cluster_test hangs with threads deadlocked on mutex in DeletionManager.
[ https://issues.apache.org/jira/browse/QPID-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-2256: - Summary: cluster_test hangs with threads deadlocked on mutex in DeletionManager. (was: cluster_test hangs with theads deadlocked on mutex in DeletionManager.) cluster_test hangs with threads deadlocked on mutex in DeletionManager. --- Key: QPID-2256 URL: https://issues.apache.org/jira/browse/QPID-2256 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Alan Conway Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.6 Running cluster_test in a loop will fairly quickly result in a deadlock. The test is blocked waiting for a child broker to exit. The broker appears deadlocked around a mutex in DeletionManager, here are the stack traces of the deadlocked broker: Thread 10 (Thread 0x414b2940 (LWP 2351)): #0 0x003da400af70 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x2af11703c21d in qpid::sys::Condition::wait (this=0x1accd4e0, mut...@0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/posix/Condition.h:69 #2 0x2af11703c48b in qpid::sys::Monitor::wait (this=0x1accd4b8, absoluteti...@0x1acccae0) at ../../cpp/include/qpid/sys/Monitor.h:45 #3 0x2af1170396ac in qpid::sys::Timer::run (this=0x1accd4b0) at ../../cpp/src/qpid/sys/Timer.cpp:139 #4 0x2af116f4f7cc in runRunnable (p=0x1accd4b0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #5 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #6 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x4217c940 (LWP 2353)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x4217bd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd4d00) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x42b7d940 (LWP 2354)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x2af11730c360) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4 0x2af1169651e6 in ScopedLock (this=0x42b7cd70, l...@0x2af11730c360) at ../../cpp/include/qpid/sys/Mutex.h:33 #5 0x2af116f5c29a in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::AllThreadsStatuses::delThreadStatus (this=0x2af11730c360, t=0x1acd6160) at ../../cpp/src/qpid/sys/DeletionManager.h:148 #6 0x2af116f5c340 in qpid::sys::DeletionManagerqpid::sys::PollerHandlePrivate::destroyThreadState () at ../../cpp/src/qpid/sys/DeletionManager.h:83 #7 0x2af116f56b52 in qpid::sys::Poller::run (this=0x1acc9b50) at ../../cpp/src/qpid/sys/epoll/EpollPoller.cpp:488 #8 0x2af1170379c2 in qpid::sys::Dispatcher::run (this=0x7fff608801d0) at ../../cpp/src/qpid/sys/Dispatcher.cpp:37 #9 0x2af116f4f7cc in runRunnable (p=0x7fff608801d0) at ../../cpp/src/qpid/sys/posix/Thread.cpp:35 #10 0x003da4006617 in start_thread () from /lib64/libpthread.so.0 #11 0x003da34d3c2d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x4357e940 (LWP 2355)): #0 0x003da400d2e4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x003da4008c55 in _L_lock_1127 () from /lib64/libpthread.so.0 #2 0x003da4008b53 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x2af116965181 in qpid::sys::Mutex::lock (this=0x1acd4bc0) at ../../cpp/include/qpid/sys/posix/Mutex.h:116 #4
