@Gary Tully <gary.tu...@gmail.com> - thank you for the clarification.
@Christopher Shannon <christopher.l.shan...@gmail.com> - for my personal learning -- do you have a link to a good read on what it takes to support JDK 11? Or can you give a brief list of issues? I'm curious of the technical parts involved. Art On Thu, Nov 29, 2018 at 8:14 AM Jamie G. <jamie.goody...@gmail.com> wrote: > JDK 11 support sounds great :) > On Thu, Nov 29, 2018 at 11:34 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > > It sounds good for JDK 11. It's something I planned to start for a while > > (now that JDK 11 support is complete in Karaf). Don't hesitate to ping > > me if I can help. > > > > Thanks > > Regards > > JB > > > > On 29/11/2018 16:02, Christopher Shannon wrote: > > > I'm actually working on getting JDK 11 support right now. The idea is > > > ActiveMQ will still have a compile/runtime target of JDK 8 but will run > > > without issue on JDK 11 and be able to be built with JDK 11 etc. We > need > > > to have that done before going to 5.16.0 as long as a bunch of > dependency > > > updates. Otherwise there isn't anything else stopping us from doing a > > > 5.16.0 > > > > > > On Thu, Nov 29, 2018 at 9:03 AM Clebert Suconic < > clebert.suco...@gmail.com> > > > wrote: > > > > > >> iMHO since you are now a commuter you have the power to call it > 5,16.0. And > > >> even make a release when you are ready. > > >> > > >> On Thu, Nov 29, 2018 at 7:53 AM Jamie G. <jamie.goody...@gmail.com> > wrote: > > >> > > >>> Hi Gary, > > >>> > > >>> Just want to clarify, you're asking to wait for 5.16.0 to be > released, > > >>> than bring in the refactoring effort? > > >>> > > >>> If you feel 5.16.0 is imminent than I'm happy to hold off. I'd prefer > > >>> to get this in sooner rather than later so as to reduce the amount of > > >>> rebasing/cherry picking i need to do in the meantime. > > >>> > > >>> By the way, thank you for the support and looking at the code. I > > >>> really appreciate it :) > > >>> > > >>> Cheers, > > >>> Jamie > > >>> On Thu, Nov 29, 2018 at 8:56 AM Gary Tully <gary.tu...@gmail.com> > wrote: > > >>>> > > >>>> Hey Arthur, > > >>>> I am not asserting that they need to be small. > > >>>> I am pointing out that they currently are small changes; there has > > >>>> been no significant refactor to date; it is all very conservative. > > >>>> Release 5.16.0 as a line in the sand, then move code around to make > it > > >>>> better etc.. go for it. > > >>>> > > >>>> I know too well it is not perfect and I think it is great that there > > >>>> is interest in making it better. > > >>>> > > >>>> On Wed, 28 Nov 2018 at 16:22, Arthur Naseef <a...@amlinv.com> wrote: > > >>>>> > > >>>>> Hey Gary - I agree that these changes belong on a minor version > > >>> increase. > > >>>>> > > >>>>> What I don't understand is the assertion that the changes between > > >>> 5.15.x > > >>>>> and 5.16.0 need to be small. Given that the minor version bump can > > >>> mean > > >>>>> significant changes, as long as they are backward compatible, I see > > >> no > > >>>>> reason to adhere to a small set of changes between 5.15.x and > 5.16.0. > > >>> Add > > >>>>> to that fact that ActiveMQ's minor releases are sometimes really > > >> major > > >>>>> changes (i.e. include breaking changes), and that makes even less > > >>> sense. > > >>>>> > > >>>>> Is there something more to this that perhaps I'm missing? > > >>>>> > > >>>>> Making the code more maintainable by the community, as ActiveMQ is > an > > >>>>> Apache *community* project, is the goal. As for it being > maintained > > >>> for 7 > > >>>>> years, that's great. However, I'm sure you'll agree it's not > > >> perfect, > > >>> and > > >>>>> community improvements are welcome. > > >>>>> > > >>>>> Art > > >>>>> > > >>>>> > > >>>>> On Wed, Nov 28, 2018 at 3:30 AM Gary Tully <gary.tu...@gmail.com> > > >>> wrote: > > >>>>> > > >>>>>> Jamie, > > >>>>>> you are missing my point. it is a tradeoff plain and simple. > easier > > >>> to > > >>>>>> maintain for who? It has been carefully maintained for more than 7 > > >>>>>> years. > > >>>>>> Do refactoring at the beginning of a release cycle, not at the > end. > > >>>>>> diffs between 5.15.x and 5.16 will be meaningless otherwise. > > >>>>>> push out 5.16.0, which has loads of incremental (non refactored) > > >>> small > > >>>>>> changes. Then refactor away on master for 5.17.0 and make it > better > > >>> in > > >>>>>> any way that works for the future and for you. > > >>>>>> On Tue, 27 Nov 2018 at 15:34, Jamie G. <jamie.goody...@gmail.com> > > >>> wrote: > > >>>>>>> > > >>>>>>> Hi Gary, > > >>>>>>> > > >>>>>>> To address your concerns: > > >>>>>>> > > >>>>>>> 1. The code is being cleaned up, not completely rewritten. This > > >> is > > >>>>>>> making it easier to maintain over the monolithic classes. It's > > >>> also > > >>>>>>> why it was brought to the community… to review it and be sure the > > >>>>>>> changes are just cleaning it up. There was no intent to change > > >> the > > >>>>>>> logic for the reason that you suggested. > > >>>>>>> > > >>>>>>> 2. I answered above, its easy on the back port as we can just > > >> make > > >>> it > > >>>>>>> a part of 5.15.9 (too my understanding the community supports > > >>> master > > >>>>>>> and the last release branch). There are little differences > > >>> between 16 > > >>>>>>> and 15.9 in the KahaDB realm. So placing it in 15.9 does not > > >>> change > > >>>>>>> any way it operates or works. It only cleans up the readability > > >> of > > >>>>>>> the code. > > >>>>>>> > > >>>>>>> > > >>>>>>> "A dream you dream alone is only a dream. A dream you dream > > >>> together > > >>>>>>> is reality." > > >>>>>>> > > >>>>>>> ― John Lennon > > >>>>>>> > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> Jamie > > >>>>>>> On Tue, Nov 27, 2018 at 8:29 AM Gary Tully <gary.tu...@gmail.com > > >>> > > >>> wrote: > > >>>>>>>> > > >>>>>>>> Hi Jamie G, > > >>>>>>>> There are a few trade offs to consider: > > >>>>>>>> 1) those familiar with the code will have to reacquaint > > >>> themselves > > >>>>>>>> with anything that is refactored > > >>>>>>>> 2) backporting fixes will be more difficult when the code > > >>> structure > > >>>>>> changes > > >>>>>>>> > > >>>>>>>> Of the two, I think #2 is more critical. > > >>>>>>>> > > >>>>>>>> On #1: > > >>>>>>>> context builds up over time and code structure is an integral > > >>> part of > > >>>>>>>> that, for better or for worse. > > >>>>>>>> Switching context is not something us humans like doing, most > > >>>>>>>> especially when stability is a key concern. > > >>>>>>>> > > >>>>>>>> Refactoring with purpose (for a new feature) can be great, > > >> doing > > >>> it at > > >>>>>>>> this stage for readability may be less great. > > >>>>>>>> > > >>>>>>>> Mr. W. B. Yeats put it nicely: "tread softly because you tread > > >>> on my > > >>>>>> dreams" > > >>>>>>>> > > >>>>>>>> s/dreams/mental model/ > > >>>>>>>> On Mon, 26 Nov 2018 at 19:44, Christopher Shannon > > >>>>>>>> <christopher.l.shan...@gmail.com> wrote: > > >>>>>>>>> > > >>>>>>>>> I didn't say I definitely wouldn't support it but I just want > > >>> to > > >>>>>> make sure > > >>>>>>>>> we are careful and the benefits of the refactor (in this case > > >>>>>> improved > > >>>>>>>>> maintainability) are really going to be worth the risk > > >>> specifically > > >>>>>> because > > >>>>>>>>> of the component being touched. Too often things get > > >>> committed and > > >>>>>> then > > >>>>>>>>> issues are uncovered with the patch later that were missed. > > >>>>>>>>> > > >>>>>>>>> Some parts of the broker are critical and this is one of them > > >>>>>> because a bug > > >>>>>>>>> that corrupts a store could lead to losing lots of production > > >>> data > > >>>>>> which is > > >>>>>>>>> a very different type of bug than a random web console bug or > > >>>>>> transport > > >>>>>>>>> error that just causes an error with a single client or with > > >> a > > >>> single > > >>>>>>>>> message. Granted the risk of a critical bug being introduced > > >>> with a > > >>>>>>>>> refactor like this is not very high but if there is one it > > >>> could have > > >>>>>>>>> pretty bad consequences. > > >>>>>>>>> > > >>>>>>>>> Now all that being said ... as long as we are careful to make > > >>> sure > > >>>>>> all > > >>>>>>>>> tests pass and have a few people thoroughly review it (such > > >> as > > >>> Gary > > >>>>>> who has > > >>>>>>>>> the most experience out of anyone in KahaDB) then I would +1 > > >>> the > > >>>>>> change for > > >>>>>>>>> a 5.16.0 release. > > >>>>>>>>> > > >>>>>>>>> On Mon, Nov 26, 2018 at 2:07 PM Arthur Naseef < > > >> a...@amlinv.com> > > >>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>>> Improving the existing code is a great goal. > > >>>>>>>>>> > > >>>>>>>>>> While cleaning up code is nice KahaDB has gotten pretty > > >>> stable > > >>>>>> over the > > >>>>>>>>>>> years and doing a bunch of refactoring just opens it up > > >> to > > >>> new > > >>>>>> bugs that > > >>>>>>>>>>> have to be fixed. Fixing bugs is not a problem however I > > >>> tend > > >>>>>> to be more > > >>>>>>>>>>> sensitive to store related changes because of the > > >> possible > > >>> data > > >>>>>> loss or > > >>>>>>>>>>> corruption issues to production data that can occur from > > >>> store > > >>>>>> bugs vs > > >>>>>>>>>> some > > >>>>>>>>>>> other random bug in the broker. > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> I understand the desire to avoid the risk of introducing > > >>> bugs. > > >>>>>> However, as > > >>>>>>>>>> long as the project is active and maintained, that really > > >>> isn't a > > >>>>>> valid > > >>>>>>>>>> approach to its maintenance overall. > > >>>>>>>>>> > > >>>>>>>>>> So that leads us to the question of risk mitigation. > > >>> Build-time > > >>>>>> tests are > > >>>>>>>>>> an industry standard, and ActiveMQ certainly has a large > > >>> number of > > >>>>>> such > > >>>>>>>>>> tests. Code reviews are another best-practice, and there > > >> are > > >>>>>> multiple > > >>>>>>>>>> individuals looking at these code changes now. More are > > >>> always > > >>>>>> welcome, > > >>>>>>>>>> and access is certainly not a problem! > > >>>>>>>>>> > > >>>>>>>>>> If there are specific concerns within the code changes, > > >> let's > > >>>>>> discuss > > >>>>>>>>>> them. It'll be great to have actual technical discussions! > > >>>>>>>>>> > > >>>>>>>>>> As for the concern that this is the broker's storage, > > >> similar > > >>>>>> arguments > > >>>>>>>>>> could be made for just about any part of the code. > > >> Reliable > > >>>>>> handling of > > >>>>>>>>>> messages is ActiveMQ's core benefit to its users. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> FWIW, the current community goal is for ActiveMQ Artemis > > >> to > > >>>>>> become > > >>>>>>>>>> ActiveMQ > > >>>>>>>>>> > > >>>>>>>>>> 6.x when acceptable feature parity is reached (which is > > >>> actively > > >>>>>> being > > >>>>>>>>>>> worked on). > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> Whether Artemis will eventually become ActiveMQ 6.x is not > > >>>>>> pertitent to > > >>>>>>>>>> this discussion. Let's not open that discussion as part of > > >>> this > > >>>>>> technical > > >>>>>>>>>> code conversation. > > >>>>>>>>>> > > >>>>>>>>>> Making the existing code base, which has heavy usage in the > > >>>>>> industry, more > > >>>>>>>>>> maintainable is always a good goal to achieve. And having > > >>> more > > >>>>>> folks in > > >>>>>>>>>> the community engaging in working on the project can only > > >>> benefit > > >>>>>> the > > >>>>>>>>>> entire community regardless of the long-term destination. > > >>>>>>>>>> > > >>>>>>>>>> Art > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On Mon, Nov 26, 2018 at 10:22 AM Justin Bertram < > > >>>>>> jbert...@apache.org> > > >>>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>>> FWIW, the current community goal is for ActiveMQ Artemis > > >> to > > >>>>>> become > > >>>>>>>>>> ActiveMQ > > >>>>>>>>>>> 6.x when acceptable feature parity is reached (which is > > >>> actively > > >>>>>> being > > >>>>>>>>>>> worked on). > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Justin > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On Mon, Nov 26, 2018 at 11:01 AM Jamie G. < > > >>>>>> jamie.goody...@gmail.com> > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> The idea here is to ensure that it’s development and > > >>>>>> maintenance > > >>>>>>>>>>>> moving forward is easier as we work to make it better > > >> in > > >>> the > > >>>>>> future. > > >>>>>>>>>>>> > > >>>>>>>>>>>> KahaDB currently has massive classes (KahaDBStore, > > >>>>>> MessageDatabase) > > >>>>>>>>>>>> and code base and is extremely hard to follow. My > > >>> desire to > > >>>>>> do this > > >>>>>>>>>>>> was to make this so we could make the continued > > >>> maintenance > > >>>>>> easier and > > >>>>>>>>>>>> also make it more inviting to improvements. The unit > > >>> tests > > >>>>>> all pass, > > >>>>>>>>>>>> so as long as we have a good solid testing coverage, > > >> the > > >>> risks > > >>>>>> are not > > >>>>>>>>>>>> huge. If a bug appears to be introduced, than we may > > >>> have > > >>>>>> uncovered a > > >>>>>>>>>>>> testing hole - finding these is a good thing. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Since we are going to continue to support ActiveMQ > > >> moving > > >>>>>> forward, > > >>>>>>>>>>>> it’s a good idea to make it more maintainable. My > > >>> motivation > > >>>>>> to doing > > >>>>>>>>>>>> this was spurred by the recent JIRAs surrounding > > >> KahaDB I > > >>>>>> helped out > > >>>>>>>>>>>> upon. I really believe this is a good improvement to > > >>> help > > >>>>>> moving > > >>>>>>>>>>>> ActiveMQ forward. > > >>>>>>>>>>>> On Mon, Nov 26, 2018 at 12:33 PM Christopher Shannon > > >>>>>>>>>>>> <christopher.l.shan...@gmail.com> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> I'm not really sure this is worthwhile or something > > >> we > > >>> want > > >>>>>> to do...I > > >>>>>>>>>>>> would > > >>>>>>>>>>>>> have to think about it more before I gave it a +1. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> While cleaning up code is nice KahaDB has gotten > > >> pretty > > >>>>>> stable over > > >>>>>>>>>> the > > >>>>>>>>>>>>> years and doing a bunch of refactoring just opens it > > >>> up to > > >>>>>> new bugs > > >>>>>>>>>>> that > > >>>>>>>>>>>>> have to be fixed. Fixing bugs is not a problem > > >>> however I > > >>>>>> tend to be > > >>>>>>>>>>> more > > >>>>>>>>>>>>> sensitive to store related changes because of the > > >>> possible > > >>>>>> data loss > > >>>>>>>>>> or > > >>>>>>>>>>>>> corruption issues to production data that can occur > > >>> from > > >>>>>> store bugs > > >>>>>>>>>> vs > > >>>>>>>>>>>> some > > >>>>>>>>>>>>> other random bug in the broker. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Sun, Nov 25, 2018 at 11:59 PM Jean-Baptiste > > >> Onofré < > > >>>>>>>>>> j...@nanthrax.net > > >>>>>>>>>>>> > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> OK, got it. It's more a syntax/codebase > > >> organization > > >>>>>> refactoring. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> If there's no impact on the behavior and features, > > >>> +1 from > > >>>>>> my side. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Regards > > >>>>>>>>>>>>>> JB > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On 25/11/2018 21:21, Jamie G. wrote: > > >>>>>>>>>>>>>>> Initially its to make KahaDB classes easier to > > >>> read & > > >>>>>> maintain. > > >>>>>>>>>>>>>>> Eventually it will help in features/performance; > > >>> smaller > > >>>>>> classes > > >>>>>>>>>>> are > > >>>>>>>>>>>>>>> easier to grok, easier to see improvements. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Instead of trying to refactor all of it in one > > >> go, > > >>> I'm > > >>>>>> taking the > > >>>>>>>>>>>>>>> approach of one area at a time. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> One pass for breaking out objects. > > >>>>>>>>>>>>>>> Another pass for small functional improvements. > > >>>>>>>>>>>>>>> Perhaps future passes for new Java features > > >> (bring > > >>> all > > >>>>>> code up to > > >>>>>>>>>>>> Java > > >>>>>>>>>>>>>>> 8 perhaps?). > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On Sun, Nov 25, 2018 at 4:32 PM Jean-Baptiste > > >>> Onofré < > > >>>>>>>>>>>> j...@nanthrax.net> > > >>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Hi Jamie, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> That's interesting. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> What's the rationale behind the refactoring ? > > >> New > > >>>>>> features or > > >>>>>>>>>> perf > > >>>>>>>>>>>>>>>> improvements ? > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Regards > > >>>>>>>>>>>>>>>> JB > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> On 25/11/2018 20:16, Jamie G. wrote: > > >>>>>>>>>>>>>>>>> Hi All, > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I've taken some time to prototype a refactored > > >>>>>> KahaDBStore > > >>>>>>>>>> class: > > >>>>>>>>>>>>>>>>> > > >>>>>> https://github.com/jgoodyear/activemq/tree/KahaDBRefactor > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> As KahaDBStore exists in Master, it contains 7 > > >>> internal > > >>>>>>>>>> classes, > > >>>>>>>>>>>> over > > >>>>>>>>>>>>>>>>> some 1677 lines of code. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> In my refactor branch I've separated out those > > >>> classes > > >>>>>> into > > >>>>>>>>>> their > > >>>>>>>>>>>> own > > >>>>>>>>>>>>>>>>> files, and applied some gentle clean code > > >>> practices to > > >>>>>> help > > >>>>>>>>>> make > > >>>>>>>>>>>> these > > >>>>>>>>>>>>>>>>> files easier to read and maintain. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I'd like to gather feed back from the > > >> community; > > >>> I've > > >>>>>> taken > > >>>>>>>>>> care > > >>>>>>>>>>> to > > >>>>>>>>>>>>>>>>> change functionality as little as possible - > > >> the > > >>> aim > > >>>>>> here is to > > >>>>>>>>>>>> reduce > > >>>>>>>>>>>>>>>>> complexity and improve maintainability. If the > > >>>>>> community feels > > >>>>>>>>>>>> this is > > >>>>>>>>>>>>>>>>> a worth while goal than I'll open a card on > > >> Jira > > >>> & > > >>>>>> prepare a > > >>>>>>>>>> PR. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Notes: > > >>>>>>>>>>>>>>>>> ActiveMQ KahaDB Store and ActiveMQ-Unit-Tests > > >>> suites > > >>>>>> remain > > >>>>>>>>>>>> passing > > >>>>>>>>>>>>>>>>> after refactor. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Cheers, > > >>>>>>>>>>>>>>>>> Jamie > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>>>> Jean-Baptiste Onofré > > >>>>>>>>>>>>>>>> jbono...@apache.org > > >>>>>>>>>>>>>>>> http://blog.nanthrax.net > > >>>>>>>>>>>>>>>> Talend - http://www.talend.com > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> -- > > >>>>>>>>>>>>>> Jean-Baptiste Onofré > > >>>>>>>>>>>>>> jbono...@apache.org > > >>>>>>>>>>>>>> http://blog.nanthrax.net > > >>>>>>>>>>>>>> Talend - http://www.talend.com > > >>>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>> > > >>> > > >> -- > > >> Clebert Suconic > > >> > > > > > > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com >
