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
