Ah, nope. My PR has been closed. :/ I’ll try locally then.
Ok, my 2 cents:
The proper Groovy way of doing
try {
configuration.setGlobalMaxMessages(10);
} catch (Exception ignored) {
configuration.setGlobalMaxSize(10 * 1024);
}
would be
if (configuration.metaClass.hasMetaProperty("globalMaxMessages")) {
configuration.globalMaxMessages = 10
} else {
configuration.globalMaxSize = 10 * 1024
}
Jan
From: Jan Šmucr<mailto:jan.sm...@aimtecglobal.com>
Sent: sobota 16. července 2022 18:00
To: dev@activemq.apache.org<mailto:dev@activemq.apache.org>
Subject: RE: Help with ARTEMIS-3767
Works with my tests. Let’s see if it builds.
Jan
From: Clebert Suconic<mailto:clebert.suco...@gmail.com>
Sent: sobota 16. července 2022 5:29
To: dev@activemq.apache.org<mailto:dev@activemq.apache.org>
Subject: Re: Help with ARTEMIS-3767
The test I wrote is actually failing with 2.17.
I will check on Monday. But the idea is already there
If you can figure out what I did wrong it would be a great help. But I can
wait for the release.
Let’s talk on Monday.
On Fri, Jul 15, 2022 at 4:52 PM Clebert Suconic <clebert.suco...@gmail.com>
wrote:
> I'm particular confused if I should make the check on < 2_18 or <= 2_18
>
>
> I'm adding a test on 2.17 and 2.18 just to be sure... depending on
> failures I will change the < or <=
>
> On Fri, Jul 15, 2022 at 4:24 PM Jan Šmucr <jan.sm...@aimtecglobal.com>
> wrote:
> >
> > Thank you very much. I appreciate it. I'll post some feedback tomorrow.
> >
> > Jan
> >
> > Dne 15. 7. 2022 22:05 napsal uživatel Clebert Suconic <
> clebert.suco...@gmail.com>:
> > I have sent a new PR:
> https://github.com/apache/activemq-artemis/pull/4150
> >
> >
> > I have sent a release HEADS up to early next week. if we fix this
> > issue it would go right on time for the 2.24.0 release.
> >
> > (@Jan: I would appreciate your feedback on the PR)
> >
> > On Fri, Jul 15, 2022 at 3:12 PM Clebert Suconic
> > <clebert.suco...@gmail.com> wrote:
> > >
> > > ... and I always thought replication would always be used within the
> > > same server.
> > >
> > >
> > > Recently we added a test on replication versioning (compatibility
> test).
> > >
> > >
> > > I will see what I can do with the versioning.
> > >
> > > On Fri, Jul 15, 2022 at 11:43 AM Robbie Gemmell
> > > <robbie.gemm...@gmail.com> wrote:
> > > >
> > > > Perhaps, I didnt go looking at the year old commits to see the
> > > > relative sequence of when it changed. The problem being raised wasnt
> > > > that the particular PR didnt change the version though (albeit the
> > > > version either already had, or subsequently did change, which I was
> > > > simply noting in case it wasnt already clear to Jan). Instead its
> that
> > > > it changed that packet contents without adding a new packet version,
> > > > and its being said that the old server cant handle the new data now
> > > > being sent in the old packet, and also that the new server cant
> handle
> > > > the absence of the new data that the old server obviously doesnt know
> > > > about to send it.
> > > >
> > > > Which or both of those is true I dont know. I do recall other similar
> > > > cases before of suggesting not sending new fields to old servers, and
> > > > being told it shouldnt matter as theyd simply not use it, though
> > > > personally I argued it still should never be sent to them as then it
> > > > definitely cant cause any change in behaviour.
> > > >
> > > > On Fri, 15 Jul 2022 at 16:00, Clebert Suconic <
> clebert.suco...@gmail.com> wrote:
> > > > >
> > > > > as far as I know that PR did not make a switch in the protocol
> version
> > > > > because there was already another change in there for the same
> > > > > version... right?
> > > > >
> > > > > On Fri, Jul 15, 2022 at 6:07 AM Robbie Gemmell <
> robbie.gemm...@gmail.com> wrote:
> > > > > >
> > > > > > This isnt an area I know about but what I vaguely recalled/can
> see is
> > > > > > that there was coincidentally a wire version bump in 2.18.0 as
> part of
> > > > > > other changes, see the ARTEMIS_2_18_0_VERSION constant in
> PacketImpl.
> > > > > > From that I would guess it should be possible for newer servers
> to
> > > > > > specifically tell whether they are connected to <=2.17.0 or >=
> > > > > > 2.18.0. Perhaps the new one could then handle the situation in
> some
> > > > > > way if the issue can be fixed from the new side only, by
> changing what
> > > > > > it sends and expects in the existing packet?
> > > > > >
> > > > > > If it can be handled that way, I doubt there would be appetite
> for
> > > > > > releasing fixes across all the superceded intermediate versions
> rather
> > > > > > than just the latest. It doesnt appear to be widely hit so far in
> > > > > > nearly a year, people using only any versions >=2.18.0 wont be
> > > > > > affected, and anyone not yet affected could become so should use
> a
> > > > > > more recent fixed release (or else can patch the old superceded
> > > > > > intermediate release with the fix themselves).
> > > > > >
> > > > > > On Fri, 15 Jul 2022 at 09:57, Jan Šmucr <
> jan.sm...@aimtecglobal.com> wrote:
> > > > > > >
> > > > > > > Dear devs,
> > > > > > >
> > > > > > > I'd like to ask you for help with the communication
> incompatibility between pre-2.18.0 servers and the newer ones. What I've
> learned so far is that in 2.18.0 there's been a change in the
> REPLICATION_START_FINISH_SYNC packet, yet no new version of that packet has
> been introduced. There have been some additional data appended to that
> packet, so that newer servers expect older servers to send more data than
> they actually do, and older servers can't cope with the additional data
> they receive. The fact that until now nobody noticed that replication
> between pre-2.18.0 and post-2.18.0 does not work confuses me a little.
> > > > > > >
> > > > > > > Before learning the actual reason of the incompatibility, I
> have developed a test which would eventually pass after the issue has been
> fixed. But now I see that fixing it would mean releasing a set of at least
> five minor bugfix releases. Shall I even attempt? If not, will you accept
> at least the test suite so that nothing like that happens in the future?
> Also mentioning the incompatibility somewhere might help others as
> unfortunate as me.
> > > > > > >
> > > > > > > The WIP PR is here:
> https://github.com/apache/activemq-artemis/pull/4144
> > > > > > > [
> https://opengraph.githubassets.com/1fef362275960b2364da60ecddb76ca361b56b67aca157a2a2d25e3145d32d99/apache/activemq-artemis/pull/4144
> ]<https://github.com/apache/activemq-artemis/pull/4144>
> > > > > > > ARTEMIS-3767 Fix replication incompatibility between pre
> 2.18.0 and SNAPSHOT (WIP) by jsmucr · Pull Request #4144 ·
> apache/activemq-artemis<
> https://github.com/apache/activemq-artemis/pull/4144><https://github.com/apache/activemq-artemis/pull/4144%3e>
> > > > > > > This PR attempts to solve the issue described in
> https://issues.apache.org/jira/browse/ARTEMIS-3767. TL;DR replication
> between =<2.17.0 and newer Artemis versions is broken since 2.18.0.
> > > > > > > github.com
> > > > > > >
> > > > > > > Thanks for your suggestions.
> > > > > > >
> > > > > > > Jan
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
--
Clebert Suconic
