Re: Maven build?
So my 2 cents.. If your goal is to produce libraries which get published to maven central, then it's much easier to use maven than to use Ivy. Several project at the ASF have mastered that art of releasing using maven, so if Qpid feels timid about how to best set it up / use it, then reach out. Maven release builds are always reproducible to for me. Recent maven releases have helped in this respect. The new releases warn you when you do things which could lead to non-reproducible builds. A good example is making sure you specify versions for your maven plugins. Also I don't mind the long initial download times maven has. It's only the first time you use a project and I'd rather maven download all the build tools need to do a reproducible build than me figuring out what I need to install and setup. Usually maven can download the internet faster than it takes folks to setup all the build requirements in a complex builds. Thats why I use maven. The fact is that the proton build is about as vanilla as a build gets. There's no code generation, and no extra tools to post-process stuff. This guy will only need a small pom to get it working properly. Since the Apache wide parent pom configures all the ASF standard plugins, your release builds will: deploy the jar, a source jar, asc sigs for the artifacts, and md5s. Plus it will be deploying to the ASF nexus instance. Nexus handles staging and locking down build for voting. Finally, once the vote passes, it's a couple of clicks in nexus to release it to maven central. Then the rest of the world can enjoy downloading your part of the internet :) Regards, Hiram On Tue, Jul 24, 2012 at 6:09 PM, Rajith Attapattu wrote: > On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger > wrote: > > Fair enough. IMO, Maven is *the* build system for Java - people behind > > a security layer haven't proven to be impossible to serve with Maven, > > and the benefits in lifecycle are well worth it. But it's also not > > worth the pain if people are anti-Maven, when you *can* get what Maven > > gets you through the use of judicious scripting. > > I don't think it's a case of being anti-Maven. > It appears there are some serious concerns (within the Qpid community > and outside world in general) with not very convincing solutions. > > Even though I had a terrible experience the last time around, I > clearly mentioned that I will go with what the majority wants. > If everybody wants and loves Maven, then I'm not going to stick out > like a sore thumb and say no :D > > My personal opinion is that it's a waste of time, as I'm not so > convinced of the rewards that warrants a switch from the current build > system that just works! > If the current build system is sub optimal, then at least it's a > different story. > > Rajith > > > On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu > wrote: > >> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger < > j...@enigmastation.com> wrote: > >>> There *are* ways to turn that off - but the easiest is to run once > >> > >> While this might solve the developer headaches, it still doesn't solve > >> the issue with customers/users and release eng folks (at my employer). > >> For some users/customers downloading even once (from unsecured > >> repositories) is a definite no. > >> This I believe is also an issue with the RPM package process. > >> Trying to disable or setting up private repos seems more trouble than > worth it. > >> > >> We want to further adoption and IMO Maven seems an unnecessary burden > >> for some users. > >> A simple build system that does the job seems the best solution. > >> > >> As Matthew points out, I wonder why we need to jump through so many > >> hoops to make this work. > >> I want to write code not meddle with my build system. > >> > >> Besides the current build system works and I'm not aware of any issues. > >> So why are we trying to fix something that is not broken ? > >> > >> To be very blunt, this seems like a waste of time with little or no > benefit. > >> Perhaps adding the bits to make the ant system spit out maven > >> artefacts for proton (like we have for Qpid) seems a better > >> alternative. > >> > >> Rajith > >> > >>> (after which most of the downloads will be finished), and then manage > >>> dependency versions accurately; it won't redownload stuff it already > >>> has, so if you specify a given dependency, version 6.0.12, it's not > >>> going to redownload that unless it actually needs to (in which case > >>> you *want* it to.) > >>> > >>> You can say that you want dependencies with a given version range, but > >>> again, these aren't actual "download the world" mechanisms, especially > >>> if the libraries don't revise often - they'll check the dependency if > >>> they need to, then be done. > >>> > >>> And maven 2 is no longer in common usage; I don't think we need to > >>> compensate for it. > >>> > >>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen > wrote: > On 07/24/2012 01:41 PM, Go
Re: Maven build?
On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger wrote: > Fair enough. IMO, Maven is *the* build system for Java - people behind > a security layer haven't proven to be impossible to serve with Maven, > and the benefits in lifecycle are well worth it. But it's also not > worth the pain if people are anti-Maven, when you *can* get what Maven > gets you through the use of judicious scripting. I don't think it's a case of being anti-Maven. It appears there are some serious concerns (within the Qpid community and outside world in general) with not very convincing solutions. Even though I had a terrible experience the last time around, I clearly mentioned that I will go with what the majority wants. If everybody wants and loves Maven, then I'm not going to stick out like a sore thumb and say no :D My personal opinion is that it's a waste of time, as I'm not so convinced of the rewards that warrants a switch from the current build system that just works! If the current build system is sub optimal, then at least it's a different story. Rajith > On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu wrote: >> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger >> wrote: >>> There *are* ways to turn that off - but the easiest is to run once >> >> While this might solve the developer headaches, it still doesn't solve >> the issue with customers/users and release eng folks (at my employer). >> For some users/customers downloading even once (from unsecured >> repositories) is a definite no. >> This I believe is also an issue with the RPM package process. >> Trying to disable or setting up private repos seems more trouble than worth >> it. >> >> We want to further adoption and IMO Maven seems an unnecessary burden >> for some users. >> A simple build system that does the job seems the best solution. >> >> As Matthew points out, I wonder why we need to jump through so many >> hoops to make this work. >> I want to write code not meddle with my build system. >> >> Besides the current build system works and I'm not aware of any issues. >> So why are we trying to fix something that is not broken ? >> >> To be very blunt, this seems like a waste of time with little or no benefit. >> Perhaps adding the bits to make the ant system spit out maven >> artefacts for proton (like we have for Qpid) seems a better >> alternative. >> >> Rajith >> >>> (after which most of the downloads will be finished), and then manage >>> dependency versions accurately; it won't redownload stuff it already >>> has, so if you specify a given dependency, version 6.0.12, it's not >>> going to redownload that unless it actually needs to (in which case >>> you *want* it to.) >>> >>> You can say that you want dependencies with a given version range, but >>> again, these aren't actual "download the world" mechanisms, especially >>> if the libraries don't revise often - they'll check the dependency if >>> they need to, then be done. >>> >>> And maven 2 is no longer in common usage; I don't think we need to >>> compensate for it. >>> >>> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen wrote: On 07/24/2012 01:41 PM, Gordon Sim wrote: > On 07/23/2012 09:38 PM, Robbie Gemmell wrote: >> I wouldn't particularly be in favour of Ant+Ivy for proton. > > Any particular reason? > > I must be old or stupid (or both!) because I can't understand why people > like maven. Admittedly I haven't used it for a long time and the > usability may have improved. However my recollection is of more > frustration than I have ever experienced with a 'build system'. > > Even philosophically it seemed wrong to me - I want to compile my > changes and it goes off looking for any updates to jar files the project > or the tool itself might use. That sort of system update seems to me > like it should be an entirely separate step. There are ways to turn all that stuff off (e.g. force offline mode, instead distribute all the maven-supplied dependencies as a zip file that can be used to populate a local-cache repository, etc). The the "non-repeatable build" can be solved either by the zip file or by hosting your own nexus server (which mirrors anything it fetches for you, thereby ensuring that you have access to it later even if the upstream goes away). But yes, that's all a lot of overhead to just get going compiling code; it's painful, and IMO not worth it. Oh, and you get strange errors if you try to build a maven2 project with maven3 (i.e., nothing in the error mentions that maybe maven3 doesn't grok the old-style config). I've used maven (involuntarily) for a while now, and will avoid it at all costs in the future. Full disclosure: I'm old enough to wish everything was just done with gmake... Matt - To unsubscribe, e-mail: dev-unsubscr...@qpi
Re: Maven build?
Fair enough. IMO, Maven is *the* build system for Java - people behind a security layer haven't proven to be impossible to serve with Maven, and the benefits in lifecycle are well worth it. But it's also not worth the pain if people are anti-Maven, when you *can* get what Maven gets you through the use of judicious scripting. On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu wrote: > On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger > wrote: >> There *are* ways to turn that off - but the easiest is to run once > > While this might solve the developer headaches, it still doesn't solve > the issue with customers/users and release eng folks (at my employer). > For some users/customers downloading even once (from unsecured > repositories) is a definite no. > This I believe is also an issue with the RPM package process. > Trying to disable or setting up private repos seems more trouble than worth > it. > > We want to further adoption and IMO Maven seems an unnecessary burden > for some users. > A simple build system that does the job seems the best solution. > > As Matthew points out, I wonder why we need to jump through so many > hoops to make this work. > I want to write code not meddle with my build system. > > Besides the current build system works and I'm not aware of any issues. > So why are we trying to fix something that is not broken ? > > To be very blunt, this seems like a waste of time with little or no benefit. > Perhaps adding the bits to make the ant system spit out maven > artefacts for proton (like we have for Qpid) seems a better > alternative. > > Rajith > >> (after which most of the downloads will be finished), and then manage >> dependency versions accurately; it won't redownload stuff it already >> has, so if you specify a given dependency, version 6.0.12, it's not >> going to redownload that unless it actually needs to (in which case >> you *want* it to.) >> >> You can say that you want dependencies with a given version range, but >> again, these aren't actual "download the world" mechanisms, especially >> if the libraries don't revise often - they'll check the dependency if >> they need to, then be done. >> >> And maven 2 is no longer in common usage; I don't think we need to >> compensate for it. >> >> On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen wrote: >>> On 07/24/2012 01:41 PM, Gordon Sim wrote: On 07/23/2012 09:38 PM, Robbie Gemmell wrote: > I wouldn't particularly be in favour of Ant+Ivy for proton. Any particular reason? I must be old or stupid (or both!) because I can't understand why people like maven. Admittedly I haven't used it for a long time and the usability may have improved. However my recollection is of more frustration than I have ever experienced with a 'build system'. Even philosophically it seemed wrong to me - I want to compile my changes and it goes off looking for any updates to jar files the project or the tool itself might use. That sort of system update seems to me like it should be an entirely separate step. >>> >>> There are ways to turn all that stuff off (e.g. force offline mode, >>> instead distribute all the maven-supplied dependencies as a zip file >>> that can be used to populate a local-cache repository, etc). >>> >>> The the "non-repeatable build" can be solved either by the zip file or >>> by hosting your own nexus server (which mirrors anything it fetches for >>> you, thereby ensuring that you have access to it later even if the >>> upstream goes away). >>> >>> But yes, that's all a lot of overhead to just get going compiling code; >>> it's painful, and IMO not worth it. Oh, and you get strange errors if >>> you try to build a maven2 project with maven3 (i.e., nothing in the >>> error mentions that maybe maven3 doesn't grok the old-style config). >>> I've used maven (involuntarily) for a while now, and will avoid it at >>> all costs in the future. >>> >>> Full disclosure: I'm old enough to wish everything was just done with >>> gmake... >>> >>> Matt >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >> >> >> >> -- >> Joseph B. Ottinger >> http://enigmastation.com >> Ça en vaut la peine. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > -- Joseph B. Ottinger http://enigmastation.com Ça en vaut la peine. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.o
Re: Maven build?
On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger wrote: > There *are* ways to turn that off - but the easiest is to run once While this might solve the developer headaches, it still doesn't solve the issue with customers/users and release eng folks (at my employer). For some users/customers downloading even once (from unsecured repositories) is a definite no. This I believe is also an issue with the RPM package process. Trying to disable or setting up private repos seems more trouble than worth it. We want to further adoption and IMO Maven seems an unnecessary burden for some users. A simple build system that does the job seems the best solution. As Matthew points out, I wonder why we need to jump through so many hoops to make this work. I want to write code not meddle with my build system. Besides the current build system works and I'm not aware of any issues. So why are we trying to fix something that is not broken ? To be very blunt, this seems like a waste of time with little or no benefit. Perhaps adding the bits to make the ant system spit out maven artefacts for proton (like we have for Qpid) seems a better alternative. Rajith > (after which most of the downloads will be finished), and then manage > dependency versions accurately; it won't redownload stuff it already > has, so if you specify a given dependency, version 6.0.12, it's not > going to redownload that unless it actually needs to (in which case > you *want* it to.) > > You can say that you want dependencies with a given version range, but > again, these aren't actual "download the world" mechanisms, especially > if the libraries don't revise often - they'll check the dependency if > they need to, then be done. > > And maven 2 is no longer in common usage; I don't think we need to > compensate for it. > > On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen wrote: >> On 07/24/2012 01:41 PM, Gordon Sim wrote: >>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote: I wouldn't particularly be in favour of Ant+Ivy for proton. >>> >>> Any particular reason? >>> >>> I must be old or stupid (or both!) because I can't understand why people >>> like maven. Admittedly I haven't used it for a long time and the >>> usability may have improved. However my recollection is of more >>> frustration than I have ever experienced with a 'build system'. >>> >>> Even philosophically it seemed wrong to me - I want to compile my >>> changes and it goes off looking for any updates to jar files the project >>> or the tool itself might use. That sort of system update seems to me >>> like it should be an entirely separate step. >> >> There are ways to turn all that stuff off (e.g. force offline mode, >> instead distribute all the maven-supplied dependencies as a zip file >> that can be used to populate a local-cache repository, etc). >> >> The the "non-repeatable build" can be solved either by the zip file or >> by hosting your own nexus server (which mirrors anything it fetches for >> you, thereby ensuring that you have access to it later even if the >> upstream goes away). >> >> But yes, that's all a lot of overhead to just get going compiling code; >> it's painful, and IMO not worth it. Oh, and you get strange errors if >> you try to build a maven2 project with maven3 (i.e., nothing in the >> error mentions that maybe maven3 doesn't grok the old-style config). >> I've used maven (involuntarily) for a while now, and will avoid it at >> all costs in the future. >> >> Full disclosure: I'm old enough to wish everything was just done with >> gmake... >> >> Matt >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> > > > > -- > Joseph B. Ottinger > http://enigmastation.com > Ça en vaut la peine. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Maven build?
There *are* ways to turn that off - but the easiest is to run once (after which most of the downloads will be finished), and then manage dependency versions accurately; it won't redownload stuff it already has, so if you specify a given dependency, version 6.0.12, it's not going to redownload that unless it actually needs to (in which case you *want* it to.) You can say that you want dependencies with a given version range, but again, these aren't actual "download the world" mechanisms, especially if the libraries don't revise often - they'll check the dependency if they need to, then be done. And maven 2 is no longer in common usage; I don't think we need to compensate for it. On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen wrote: > On 07/24/2012 01:41 PM, Gordon Sim wrote: >> On 07/23/2012 09:38 PM, Robbie Gemmell wrote: >>> I wouldn't particularly be in favour of Ant+Ivy for proton. >> >> Any particular reason? >> >> I must be old or stupid (or both!) because I can't understand why people >> like maven. Admittedly I haven't used it for a long time and the >> usability may have improved. However my recollection is of more >> frustration than I have ever experienced with a 'build system'. >> >> Even philosophically it seemed wrong to me - I want to compile my >> changes and it goes off looking for any updates to jar files the project >> or the tool itself might use. That sort of system update seems to me >> like it should be an entirely separate step. > > There are ways to turn all that stuff off (e.g. force offline mode, > instead distribute all the maven-supplied dependencies as a zip file > that can be used to populate a local-cache repository, etc). > > The the "non-repeatable build" can be solved either by the zip file or > by hosting your own nexus server (which mirrors anything it fetches for > you, thereby ensuring that you have access to it later even if the > upstream goes away). > > But yes, that's all a lot of overhead to just get going compiling code; > it's painful, and IMO not worth it. Oh, and you get strange errors if > you try to build a maven2 project with maven3 (i.e., nothing in the > error mentions that maybe maven3 doesn't grok the old-style config). > I've used maven (involuntarily) for a while now, and will avoid it at > all costs in the future. > > Full disclosure: I'm old enough to wish everything was just done with > gmake... > > Matt > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > -- Joseph B. Ottinger http://enigmastation.com Ça en vaut la peine. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-4159) HA missing messages in failover test.
[ https://issues.apache.org/jira/browse/QPID-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened QPID-4159: --- The failures are still occuring, but less frequently. Reopening. > HA missing messages in failover test. > - > > Key: QPID-4159 > URL: https://issues.apache.org/jira/browse/QPID-4159 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Running this test: > ha_tests.py *.test_failover_send_receive -DDURATION=2 > in a loop eventually fails with something like: > AssertionError: test8 missing message 17529>17454 > The test should run indefinitely with no missing messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Maven build?
On 07/24/2012 01:41 PM, Gordon Sim wrote: > On 07/23/2012 09:38 PM, Robbie Gemmell wrote: >> I wouldn't particularly be in favour of Ant+Ivy for proton. > > Any particular reason? > > I must be old or stupid (or both!) because I can't understand why people > like maven. Admittedly I haven't used it for a long time and the > usability may have improved. However my recollection is of more > frustration than I have ever experienced with a 'build system'. > > Even philosophically it seemed wrong to me - I want to compile my > changes and it goes off looking for any updates to jar files the project > or the tool itself might use. That sort of system update seems to me > like it should be an entirely separate step. There are ways to turn all that stuff off (e.g. force offline mode, instead distribute all the maven-supplied dependencies as a zip file that can be used to populate a local-cache repository, etc). The the "non-repeatable build" can be solved either by the zip file or by hosting your own nexus server (which mirrors anything it fetches for you, thereby ensuring that you have access to it later even if the upstream goes away). But yes, that's all a lot of overhead to just get going compiling code; it's painful, and IMO not worth it. Oh, and you get strange errors if you try to build a maven2 project with maven3 (i.e., nothing in the error mentions that maybe maven3 doesn't grok the old-style config). I've used maven (involuntarily) for a while now, and will avoid it at all costs in the future. Full disclosure: I'm old enough to wish everything was just done with gmake... Matt - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
[ https://issues.apache.org/jira/browse/QPID-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4165. --- Resolution: Fixed Commit to 0.18 r1365251 > Fix unsused variable warnings when compiling with -DNDEBUG > --- > > Key: QPID-4165 > URL: https://issues.apache.org/jira/browse/QPID-4165 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ndebug.diff > > > Trivial fixes, patch attached. > request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
[ https://issues.apache.org/jira/browse/QPID-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421700#comment-13421700 ] Justin Ross commented on QPID-4165: --- Reviewed by Darryl. Approved for 0.18. > Fix unsused variable warnings when compiling with -DNDEBUG > --- > > Key: QPID-4165 > URL: https://issues.apache.org/jira/browse/QPID-4165 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ndebug.diff > > > Trivial fixes, patch attached. > request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4134) Creates a source tarball for use by the Perl distributions.
[ https://issues.apache.org/jira/browse/QPID-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421699#comment-13421699 ] Andrew Stitcher commented on QPID-4134: --- I'm not really happy that this is really a source tarball in any useful way. The "source" tarball packages up the code generated by swig. This is not really source in the sense that a developer could use it to change anything. I'd expect source to include the swig typemap and whatever other files that swig needs to do the generation, and perhaps the original qpid/messaging.h and other C++ header files .Although for packaging purposes you could have a build dependency on the appropriate -devel package and not include the actual files. The extra work I think this needs is to make the Cmake tooling now work both standalone and as part of the full build - I'm not sure how good cmake is at that. > Creates a source tarball for use by the Perl distributions. > --- > > Key: QPID-4134 > URL: https://issues.apache.org/jira/browse/QPID-4134 > Project: Qpid > Issue Type: Bug > Components: Packaging >Reporter: Darryl L. Pierce > Labels: bindings, perl, > Attachments: > 0001-Adds-a-Cmake-target-to-generate-a-source-tarball-for.patch > > > This patch adds a new target to the Cmake build system to produce a source > tarball for the Perl bindings. > It replaces Makefile.PL.in with Makefile.PL, and removes Perl from the > autotools build. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
[ https://issues.apache.org/jira/browse/QPID-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421696#comment-13421696 ] Darryl L. Pierce commented on QPID-4165: This patch works for me. > Fix unsused variable warnings when compiling with -DNDEBUG > --- > > Key: QPID-4165 > URL: https://issues.apache.org/jira/browse/QPID-4165 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ndebug.diff > > > Trivial fixes, patch attached. > request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
[ https://issues.apache.org/jira/browse/QPID-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421680#comment-13421680 ] Alan Conway commented on QPID-4165: --- Commit to trunk r1365234 > Fix unsused variable warnings when compiling with -DNDEBUG > --- > > Key: QPID-4165 > URL: https://issues.apache.org/jira/browse/QPID-4165 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ndebug.diff > > > Trivial fixes, patch attached. > request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
[ https://issues.apache.org/jira/browse/QPID-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated QPID-4165: -- Attachment: ndebug.diff > Fix unsused variable warnings when compiling with -DNDEBUG > --- > > Key: QPID-4165 > URL: https://issues.apache.org/jira/browse/QPID-4165 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ndebug.diff > > > Trivial fixes, patch attached. > request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4165) Fix unsused variable warnings when compiling with -DNDEBUG
Alan Conway created QPID-4165: - Summary: Fix unsused variable warnings when compiling with -DNDEBUG Key: QPID-4165 URL: https://issues.apache.org/jira/browse/QPID-4165 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.17 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.18 Trivial fixes, patch attached. request merge to 0.18. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Maven build?
On Tue, Jul 24, 2012 at 1:50 PM, Weston M. Price wrote: > On Jul 24, 2012, at 1:24 PM, Rafael Schloming wrote: > >> Sorry to jump in late on this thread. I'm totally for making proton as >> easy to consume as possible, so I definitely support making maven >> artifacts available, but I also had a very bad experience with maven >> last time I was exposed to it. >> >> As I recall there were two major issues, one being non repeatable builds >> due to a variety of reasons, some of which may have been addressed since >> then. >> >> The other big issue we had was with integration of the maven built >> software into other environments. I don't know if this has changed, but >> maven didn't really have a concept of configuration. Rather than >> adapting the software to build within the host environment, e.g. use >> supplied libraries and/or leave out optional portions of the build, >> maven takes the approach of adapting the host environment to fit the >> software, i.e. download whatever is necessary to build, even if that set >> of stuff is incompatible with the host environment. This actually makes >> it very difficult to integrate maven built software into controlled >> build environments, e.g. distros or release builds. >> >> Given that it's pretty straightforward to get ant to play well with >> others (including maven) and a core goal of proton is to be super easy >> to integrate, I'd be concerned that moving to a maven build might prove >> to be a barrier to broader integration. I'd certainly like to understand >> what it's impact will be e.g. on maintaining proton in distros or >> getting it to build in embedded environments. >> > +1 > My tentative endorsement for maven had more to do with being a good citizen > than any inherent approval. >> --Rafael I've already stated my concerns as a developer. Let me also state a few concerns from the packaging/distribution side. The issue of repeatable builds and downloading updates from repositories that are outside of our control is really a big concern from a packaging pov. Certain customers/users who would want to build Qpid from source does not like to download bits from all over the internet for security reasons. In some ways moving to maven may infact be a barrier for adoption due to the above issue. Ant on the other hand can spit out maven artefacts. As long as we produce maven artefacts, projects that use maven could easily use proton and Qpid. That to me seems like a win-win situation. Regards, Rajith >> >> On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote: >>> Well, what I'll do then is convert proton's build to maven and submit that >>> as a patch attached to an issue, then I'll look into what it would take to >>> get qpid-java's build to maven, too. If those diffs pass inspection, good. >>> If not, we can fix them or ignore them as desired. >>> >>> On Monday, July 23, 2012, Robbie Gemmell wrote: I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for the main Qpid java stuff because it allowed a long overdue clean up of our repo and didn't involve changing the entire build system (if it had, I woudn't have done it), but if I was starting afresh I'd be using Maven for that too. Robbie On 23 July 2012 20:54, Weston M. Price wrote: > > On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote: > >> I think its safe to say Maven is a lot more mature now than it was back >> then, and is much more widely used. The issues that existed then > certainly >> don't seem to bother the massive numbers of large projects using it > today. >> >> Given how popular it is with other developers as a build system and as >>> a >> route for their projects to consume artifacts, I'd generally be in >>> favour >> of making the switch if only to be nice citizens to prospective users >>> of >> proton. > +1 > Notwithstanding my personal dislike of maven, it seems to have become the > de facto standard. Although, we could use Ivy+Ant like we do in the >>> current > code base. This would be my personal preference but the maven thing has > truly become a 'if you can't beat them, join them' thing for me so I >>> would > be fine either way. > > Weston > >> >> Robbie >> On 23 Jul 2012 20:00, "Rajith Attapattu" wrote: >> >>> I personally prefer the simple ant based system. >>> The last time Qpid used maven it was horrible :) .. it downloaded the >>> entire universe into my computer. >>> We also had trouble doing repeatable builds. >>> Now I don't know if it was due to the way Maven was used or if it was >>> an issue with Maven itself. >>> I've never had issues with ant before --- it always worked for me :) >>> With Maven it wasn't particularly a pleasant experience. >>> So I'm biased there and please don't blame me for that. >>> >>> Having said that, I'm not going to make
Re: Maven build?
On Jul 24, 2012, at 1:24 PM, Rafael Schloming wrote: > Sorry to jump in late on this thread. I'm totally for making proton as > easy to consume as possible, so I definitely support making maven > artifacts available, but I also had a very bad experience with maven > last time I was exposed to it. > > As I recall there were two major issues, one being non repeatable builds > due to a variety of reasons, some of which may have been addressed since > then. > > The other big issue we had was with integration of the maven built > software into other environments. I don't know if this has changed, but > maven didn't really have a concept of configuration. Rather than > adapting the software to build within the host environment, e.g. use > supplied libraries and/or leave out optional portions of the build, > maven takes the approach of adapting the host environment to fit the > software, i.e. download whatever is necessary to build, even if that set > of stuff is incompatible with the host environment. This actually makes > it very difficult to integrate maven built software into controlled > build environments, e.g. distros or release builds. > > Given that it's pretty straightforward to get ant to play well with > others (including maven) and a core goal of proton is to be super easy > to integrate, I'd be concerned that moving to a maven build might prove > to be a barrier to broader integration. I'd certainly like to understand > what it's impact will be e.g. on maintaining proton in distros or > getting it to build in embedded environments. > +1 My tentative endorsement for maven had more to do with being a good citizen than any inherent approval. > --Rafael > > On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote: >> Well, what I'll do then is convert proton's build to maven and submit that >> as a patch attached to an issue, then I'll look into what it would take to >> get qpid-java's build to maven, too. If those diffs pass inspection, good. >> If not, we can fix them or ignore them as desired. >> >> On Monday, July 23, 2012, Robbie Gemmell wrote: >>> I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for >>> the main Qpid java stuff because it allowed a long overdue clean up of our >>> repo and didn't involve changing the entire build system (if it had, I >>> woudn't have done it), but if I was starting afresh I'd be using Maven for >>> that too. >>> >>> Robbie >>> >>> On 23 July 2012 20:54, Weston M. Price wrote: >>> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote: > I think its safe to say Maven is a lot more mature now than it was back > then, and is much more widely used. The issues that existed then certainly > don't seem to bother the massive numbers of large projects using it today. > > Given how popular it is with other developers as a build system and as >> a > route for their projects to consume artifacts, I'd generally be in >> favour > of making the switch if only to be nice citizens to prospective users >> of > proton. +1 Notwithstanding my personal dislike of maven, it seems to have become the de facto standard. Although, we could use Ivy+Ant like we do in the >> current code base. This would be my personal preference but the maven thing has truly become a 'if you can't beat them, join them' thing for me so I >> would be fine either way. Weston > > Robbie > On 23 Jul 2012 20:00, "Rajith Attapattu" wrote: > >> I personally prefer the simple ant based system. >> The last time Qpid used maven it was horrible :) .. it downloaded the >> entire universe into my computer. >> We also had trouble doing repeatable builds. >> Now I don't know if it was due to the way Maven was used or if it was >> an issue with Maven itself. >> I've never had issues with ant before --- it always worked for me :) >> With Maven it wasn't particularly a pleasant experience. >> So I'm biased there and please don't blame me for that. >> >> Having said that, I'm not going to make a fuss, if the majority wants >> Maven ! >> >> One more thing. Converting the build system to maven is fine, but who >> ever does that should also take the responsibility of maintaining it >> as well :) >> To a certain extent that was also an issue with the previous attempt >> at using maven. >> >> Rajith >> >> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy wrote: >>> Hi, >>> >>> I completely support Joseph's proposal to use maven as building >> system >>> for j-poton module. >>> >>> Kind Regards, >>> Alex >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >>> For additional commands, e-mail: dev-h...@qpid.apache.org >>> >> >> -
Re: Maven build?
Sorry to jump in late on this thread. I'm totally for making proton as easy to consume as possible, so I definitely support making maven artifacts available, but I also had a very bad experience with maven last time I was exposed to it. As I recall there were two major issues, one being non repeatable builds due to a variety of reasons, some of which may have been addressed since then. The other big issue we had was with integration of the maven built software into other environments. I don't know if this has changed, but maven didn't really have a concept of configuration. Rather than adapting the software to build within the host environment, e.g. use supplied libraries and/or leave out optional portions of the build, maven takes the approach of adapting the host environment to fit the software, i.e. download whatever is necessary to build, even if that set of stuff is incompatible with the host environment. This actually makes it very difficult to integrate maven built software into controlled build environments, e.g. distros or release builds. Given that it's pretty straightforward to get ant to play well with others (including maven) and a core goal of proton is to be super easy to integrate, I'd be concerned that moving to a maven build might prove to be a barrier to broader integration. I'd certainly like to understand what it's impact will be e.g. on maintaining proton in distros or getting it to build in embedded environments. --Rafael On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote: > Well, what I'll do then is convert proton's build to maven and submit that > as a patch attached to an issue, then I'll look into what it would take to > get qpid-java's build to maven, too. If those diffs pass inspection, good. > If not, we can fix them or ignore them as desired. > > On Monday, July 23, 2012, Robbie Gemmell wrote: > > I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for > > the main Qpid java stuff because it allowed a long overdue clean up of our > > repo and didn't involve changing the entire build system (if it had, I > > woudn't have done it), but if I was starting afresh I'd be using Maven for > > that too. > > > > Robbie > > > > On 23 July 2012 20:54, Weston M. Price wrote: > > > >> > >> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote: > >> > >> > I think its safe to say Maven is a lot more mature now than it was back > >> > then, and is much more widely used. The issues that existed then > >> certainly > >> > don't seem to bother the massive numbers of large projects using it > >> today. > >> > > >> > Given how popular it is with other developers as a build system and as > a > >> > route for their projects to consume artifacts, I'd generally be in > favour > >> > of making the switch if only to be nice citizens to prospective users > of > >> > proton. > >> +1 > >> Notwithstanding my personal dislike of maven, it seems to have become the > >> de facto standard. Although, we could use Ivy+Ant like we do in the > current > >> code base. This would be my personal preference but the maven thing has > >> truly become a 'if you can't beat them, join them' thing for me so I > would > >> be fine either way. > >> > >> Weston > >> > >> > > >> > Robbie > >> > On 23 Jul 2012 20:00, "Rajith Attapattu" wrote: > >> > > >> >> I personally prefer the simple ant based system. > >> >> The last time Qpid used maven it was horrible :) .. it downloaded the > >> >> entire universe into my computer. > >> >> We also had trouble doing repeatable builds. > >> >> Now I don't know if it was due to the way Maven was used or if it was > >> >> an issue with Maven itself. > >> >> I've never had issues with ant before --- it always worked for me :) > >> >> With Maven it wasn't particularly a pleasant experience. > >> >> So I'm biased there and please don't blame me for that. > >> >> > >> >> Having said that, I'm not going to make a fuss, if the majority wants > >> >> Maven ! > >> >> > >> >> One more thing. Converting the build system to maven is fine, but who > >> >> ever does that should also take the responsibility of maintaining it > >> >> as well :) > >> >> To a certain extent that was also an issue with the previous attempt > >> >> at using maven. > >> >> > >> >> Rajith > >> >> > >> >> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy > >> wrote: > >> >>> Hi, > >> >>> > >> >>> I completely support Joseph's proposal to use maven as building > system > >> >>> for j-poton module. > >> >>> > >> >>> Kind Regards, > >> >>> Alex > >> >>> > >> >>> - > >> >>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> >>> For additional commands, e-mail: dev-h...@qpid.apache.org > >> >>> > >> >> > >> >> - > >> >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> >> For additional commands, e-mail: dev-h...@qpid.apache.org > >> >> > >> >> > >
Re: Maven build?
On 07/23/2012 09:38 PM, Robbie Gemmell wrote: I wouldn't particularly be in favour of Ant+Ivy for proton. Any particular reason? I must be old or stupid (or both!) because I can't understand why people like maven. Admittedly I haven't used it for a long time and the usability may have improved. However my recollection is of more frustration than I have ever experienced with a 'build system'. Even philosophically it seemed wrong to me - I want to compile my changes and it goes off looking for any updates to jar files the project or the tool itself might use. That sort of system update seems to me like it should be an entirely separate step. At present sadly I don't have the time to spend on proton-j that I would like, so my opinion should not be given much weight if the preference for maven is widespread amongst real users and developers. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: 0.18 release update - RC1 is available
On Sat, Jul 21, 2012 at 07:53:15PM -0400, Justin wrote: > Hi, folks. RC1 is ready at revision 1363863 of our product branch. > Get it here: > > http://people.apache.org/~jross/qpid-0.18-rc1/ The qpid-cpp RPMs failed to build on F17/x86 with: qpid/amqp_0_10/Codecs.cpp: In function 'void qpid::amqp_0_10::encode(const Map&, uint32_t, qpid::framing::Buffer&)': qpid/amqp_0_10/Codecs.cpp:402:14: error: unused variable 's' [-Werror=unused-variable] qpid/amqp_0_10/Codecs.cpp: In function 'void qpid::amqp_0_10::encode(const Map&, const string&, const qpid::types::Variant&, uint32_t, qpid::framing::Buffer&)': qpid/amqp_0_10/Codecs.cpp:414:14: error: unused variable 's' [-Werror=unused-variable] qpid/amqp_0_10/Codecs.cpp: In function 'void qpid::amqp_0_10::encode(const List&, uint32_t, qpid::framing::Buffer&)': qpid/amqp_0_10/Codecs.cpp:429:14: error: unused variable 's' [-Werror=unused-variable] cc1plus: all warnings being treated as errors In all three functions there's a local variable introduced that doesn't appear to be used except in an assert() call. And since RPMs are built with NDEBUG defined this is going to cause RPM builds to fail. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpP07avdRfcW.pgp Description: PGP signature
[jira] [Resolved] (QPID-4107) HA does not replicate alternate-exchange
[ https://issues.apache.org/jira/browse/QPID-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4107. --- Resolution: Fixed > HA does not replicate alternate-exchange > > > Key: QPID-4107 > URL: https://issues.apache.org/jira/browse/QPID-4107 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > > In a HA cluster, the alternate-exchange setting on queues and exchanges is > not replicated. > Note that to replicate it, you need to solve the problem of ensuring you have > replicated the required exchange before you try to set it on a newly > replicated queue (or exchange). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4159) HA missing messages in failover test.
[ https://issues.apache.org/jira/browse/QPID-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4159. --- Resolution: Fixed Committed to 0.18 branch r1365044 > HA missing messages in failover test. > - > > Key: QPID-4159 > URL: https://issues.apache.org/jira/browse/QPID-4159 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Running this test: > ha_tests.py *.test_failover_send_receive -DDURATION=2 > in a loop eventually fails with something like: > AssertionError: test8 missing message 17529>17454 > The test should run indefinitely with no missing messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4163) Deadlock between LinkRegistry and TimerTask locks
[ https://issues.apache.org/jira/browse/QPID-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4163. --- Resolution: Fixed Comitted to 0.18 branch r1365045 > Deadlock between LinkRegistry and TimerTask locks > - > > Key: QPID-4163 > URL: https://issues.apache.org/jira/browse/QPID-4163 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > Attachments: ha-timer-hang.pstack > > > Very occasionally (about 2% of runs), when running ha_tests.py in a long loop > one of the brokers deadlocks with the attached stack trace. The problem is a > call to TimerTask::cancel with the LinkRegsitry lock held, while another > thread is in TimerTask::fire and waiting for the LinkRegistry lock. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4159) HA missing messages in failover test.
[ https://issues.apache.org/jira/browse/QPID-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421333#comment-13421333 ] Justin Ross commented on QPID-4159: --- Reviewed by Gordon. Approved for 0.18. > HA missing messages in failover test. > - > > Key: QPID-4159 > URL: https://issues.apache.org/jira/browse/QPID-4159 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Running this test: > ha_tests.py *.test_failover_send_receive -DDURATION=2 > in a loop eventually fails with something like: > AssertionError: test8 missing message 17529>17454 > The test should run indefinitely with no missing messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: qpidd refactor
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5833/ --- (Updated July 24, 2012, 11:13 a.m.) Review request for qpid, Alan Conway and Kenneth Giusti. Changes --- Brought main description up to date. Description (updated) --- == Background == I've been looking at what would be required to get AMQP 1.0 support in the qpidd broker (using proton-c). In that context I felt there was a need to refactor the broker code, particularly that part that would be shared between different protocol versions. Part of the motivation was clearer separation of 0-10 specific logic, so that 1.0 logic could be introduced as an alternative. However part of it was also simply the recognition of some long-standing problems that we have never stopped to address. So, here is a patch representing my ideas on what is needed. This is a little stale again (patch was generated against r13613342) and needs (yet) another rebase. However it is getting to the point where I'll be asking to commit it soon, so if anyone has feedback, now is the time to give it! == Key Changes == qpid::broker::Message This is now supposed to be a protocol neutral representation of a message. It no longer exposes qpid::framing::FrameSet. It can be based on data received in different encodings (this patch only includes the existing 0-10 encoding). The immutable, sharable state is separated from the mutable queue-specific state. Messages themselves are no longer held through a shared pointer but are passed by reference or copied if needed. The immutable state (essentially the data as received) *is* still shared and referenced internally through an intrusive pointer. There is no longer a message level lock. A message instance is 'owned' by someother entity (usually the queue it is on) which controls concurrent access/modification if necessary. The persistence context is a separate part of the message also. Currently that can be shared between two message instances if desired. qpid::broker::Messages Switched from using qpid::broker::QueuedMessage (which relied on shared pointer to message itself and made sequence number the explicit - and only - way to refer to a specific message) to using modified Message class directly and a new qpid::broker::QueueCursor. The cursor is opaque outside the Messages implementation to which it relates. It provides a way to refer to a specific message (without directly using sequence number, though at present that is what is used 'under the covers') and/or to track progress through a sequence of messages (for consumers or other iterating entities). I.e. its an iterator to a Message within its containing Messages instance that is not invalidated by changes to that container. A Messages instance *owns* the Message instances within it. Other classes access this through a reference or (raw) pointer, or if needed copy it (the immutable part can be - and is - safely shared). The codepath for browse/consume is a lot more unified now. You use a cursor and call Messages::next() in each case. This also lays the foundation for selectors. The simplified Messages interface led to a simplied MessageDistributor. There is still a little more to do to clarify these separate roles (or indeed perhaps unify them?) but more on that later. qpid::broker::amqp_0_10::MessageTransfer This represents the familiar 0-10 encoding of a message. This class is broadly similar to the old Message class, based on a FrameSet. However it represents the shared and essentially immutable state. The sendHeader() method now explicitly takes a copy of the original headers and adds to it or otherwise modifies it if needed (e.g. for redelivered flag, ttl, annotations etc). [Ideally I'd like to move more of the 0-10 specific classes out of qpid::broker and into qpid::broker::amqp_0_10, but that has no functional relevance so I've left existing classes alone for now.] qpid::broker::Consumer The deliver() method now takes a QueueCursor (representing a 'handle' to this message for use in subsequent operations such as accept, relese etc) and a *constant reference* to the Message itself (i.e. consumers can't alter the state of the message on the queue directly, but only through operations on the queue itself). qpid::broker::QueueRegistry The actual queue creation has been pulled out into a base class, QueueFactory. The actual class of the Queue returned can now be varied and there are two subclasses in the current patch. The first is a replacement for the ring policy logic, whereby messages are removed from the queue in order to keep the queue from growing above a configured limit. The second is for last value queues and simply pulls the special case behaviour out of the common code path. The handling of queue configuration has also been made cleaner and more uniform, based on the QueueSetting
[jira] [Commented] (QPID-4159) HA missing messages in failover test.
[ https://issues.apache.org/jira/browse/QPID-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421282#comment-13421282 ] Gordon Sim commented on QPID-4159: -- Change poses no risk for 0.18 if there is still time to squeeze it in. It is a clear defect so would be very nice to see it fixed in this release. > HA missing messages in failover test. > - > > Key: QPID-4159 > URL: https://issues.apache.org/jira/browse/QPID-4159 > Project: Qpid > Issue Type: Bug > Components: C++ Clustering >Affects Versions: 0.17 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.18 > > > Running this test: > ha_tests.py *.test_failover_send_receive -DDURATION=2 > in a loop eventually fails with something like: > AssertionError: test8 missing message 17529>17454 > The test should run indefinitely with no missing messages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: QPID-4159: HA Missing messages in failover test.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6093/#review9391 --- Ship it! Ship It! - Gordon Sim On July 23, 2012, 4:11 p.m., Alan Conway wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/6093/ > --- > > (Updated July 23, 2012, 4:11 p.m.) > > > Review request for qpid and Gordon Sim. > > > Description > --- > > QueueGuard was taking its snapshot of the initial queue range *before* it > registered its QueueObserver. That means it was possible to have unguarded > messages > between the end of the snapshot and the first position protected by the guard. > > Request merge to 0.18 > > > Diffs > - > > /trunk/qpid/cpp/src/qpid/ha/Primary.cpp 1363520 > /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1363520 > /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1363520 > > Diff: https://reviews.apache.org/r/6093/diff/ > > > Testing > --- > > make check, ran ha_tests.py overnight in a loop > > > Thanks, > > Alan Conway > >
Re: Review Request: qpidd refactor
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5833/ --- (Updated July 24, 2012, 9 a.m.) Review request for qpid, Alan Conway and Kenneth Giusti. Changes --- Fixed CMake build; cleaned up and re-enabled unit tests; Altered Queue::seek() signature following Alan's comments (went with overloaded methods as opposed to a boost optional). Description --- == Background == I've been looking at what would be required to get AMQP 1.0 support in the qpidd broker (using proton-c). In that context I felt there was a need to refactor the broker code, particularly that part that would be shared between different protocol versions. Part of the motivation was clearer separation of 0-10 specific logic, so that 1.0 logic could be introduced as an alternative. However part of it was also simply the recognition of some long-standing problems that we have never stopped to address. So, here is a patch representing my ideas on what is needed. This is already a little stale (patch was generated against r1331342) and needs a rebase. However I think the basic ideas involved are clear enough that it would be worth getting some early feedback. == Key Changes == qpid::broker::Message This is now supposed to be a protocol neutral representation of a message. It no longer exposes qpid::framing::FrameSet. It can be based on data received in different encodings (this patch only includes the existing 0-10 encoding). The immutable, sharable state is separated from the mutable queue-specific state. Messages themselves are no longer held through a shared pointer but are passed by reference or copied if needed. The immutable state (essentially the data as received) *is* still shared and referenced internally through an intrusive pointer. There is no longer a message level lock. A message instance is 'owned' by someother entity (usually the queue it is on) which controls concurrent access/modification if necessary. The persistence context is a separate part of the message also. Currently that can be shared between two message instances if desired. qpid::broker::Messages Switched from using qpid::broker::QueuedMessage (which relied on shared pointer to message itself and made sequence number the explicit - and only - way to refer to a specific message) to using modified Message class directly and a new qpid::broker::QueueCursor. The cursor is opaque outside the Messages implementation to which it relates. It provides a way to refer to a specific message (without directly using sequence number, though at present that is what is used 'under the covers') and/or to track progress through a sequence of messages (for consumers or other iterating entities). I.e. its an iterator to a Message within its containing Messages instance that is not invalidated by changes to that container. A Messages instance *owns* the Message instances within it. Other classes access this through a reference or (raw) pointer, or if needed copy it (the immutable part can be - and is - safely shared). The codepath for browse/consume is a lot more unified now. You use a cursor and call Messages::next() in each case. This also lays the foundation for selectors. The simplified Messages interface led to a simplied MessageDistributor. There is still a little more to do to clarify these separate roles (or indeed perhaps unify them?) but more on that later. qpid::broker::amqp_0_10::MessageTransfer This represents the familiar 0-10 encoding of a message. This class is broadly similar to the old Message class, based on a FrameSet. However it represents the shared and essentially immutable state. The sendHeader() method now explicitly takes a copy of the original headers and adds to it or otherwise modifies it if needed (e.g. for redelivered flag, ttl, annotations etc). [Ideally I'd like to move more of the 0-10 specific classes out of qpid::broker and into qpid::broker::amqp_0_10, but that has no functional relevance so I've left existing classes alone for now.] qpid::broker::Consumer The deliver() method now takes a QueueCursor (representing a 'handle' to this message for use in subsequent operations such as accept, relese etc) and a *constant reference* to the Message itself (i.e. consumers can't alter the state of the message on the queue directly, but only through operations on the queue itself). qpid::broker::QueueRegistry The actual queue creation has been pulled out into a base class, QueueFactory. The actual class of the Queue returned can now be varied and there are two subclasses in the current patch. The first is a replacement for the ring policy logic, whereby messages are removed from the queue in order to keep the queue from growing above a configured limit. The second is for last value queues and simply pulls the special case behaviour out of the common code path. The handl
