@Iliya Grushevskiy thanks for the contributions... pretty impressive actually as you tweaked OperationContext and other IO operations.. thanks a lot. I would love to see more contributions coming :)
On Thu, Jun 30, 2022 at 3:47 PM Clebert Suconic <clebert.suco...@gmail.com> wrote: > > PR sent: https://github.com/apache/activemq-artemis/pull/4130 > > On Thu, Jun 30, 2022 at 9:33 AM Clebert Suconic > <clebert.suco...@gmail.com> wrote: > > > > Thanks for checking on that. > > > > I will take a look today. > > > > On Thu, Jun 30, 2022 at 4:39 AM Iliya Grushevskiy <iliya...@gmail.com> > > wrote: > >> > >> Hi, Clebert > >> > >> I think there is another related issue: > >> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3815 > >> <https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3815> > >> I have sent a PR https://github.com/apache/activemq-artemis/pull/4066. > >> It’s outdated now, but it contains test that I think is still relevant. > >> > >> > >> Regards > >> Iliya Grushevskiy > >> > >> > >> > >> > >> > 29 июня 2022 г., в 18:34, Clebert Suconic <clebert.suco...@gmail.com> > >> > написал(а): > >> > > >> > I have sent a PR for the mirror issues: > >> > > >> > https://github.com/apache/activemq-artemis/pull/4127 > >> > > >> > On Wed, Jun 1, 2022 at 10:06 AM Stephen Baker > >> > <stephen.ba...@rmssoftwareinc.com> wrote: > >> >> > >> >> I’m not on the DBA team so I don’t know specifics but it is asynchronous > >> >> replication to a secondary server in the same datacenter and a similar > >> >> primary/secondary server to the standby datacenter. > >> >> > >> >> Theoretically the mirroring in Artemis should offer the same resiliency > >> >> (synced to the disk, possibly not replicated in the event of a hard > >> >> failure); > >> >> But in practice mirroring is Artemis is relatively new and SQL > >> >> replication > >> >> has existed for decades with plenty of DBAs who are well versed in > >> >> mitigating > >> >> common problems. > >> >> > >> >> Some of the issues we have with mirroring that I can remember: > >> >> * The two sides get out of sync quickly as in: > >> >> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3766 > >> >> (not just the expiry queue – looking at one of our production sets > >> >> right now on > >> >> two of 6 queues I see message counts of 172 and 96 on the cold side, > >> >> and 0 > >> >> on the hot side. Because this is Artemis 2.20 I cannot browse them or > >> >> see if they > >> >> are really there but I hope to learn more when we complete our 2.22 > >> >> update.) > >> >> * The stats are not tracked correctly so it’s hard to tell how out of > >> >> sync > >> >> we are: > >> >> https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-3743 > >> >> * We use to end up with extremely large journals on the cold side that > >> >> would > >> >> prevent start up. Mitigated with aggressive TTL and purging on the > >> >> cold side. > >> >> * We’ve ended up with delivery of ancient messages when failing over. > >> >> Mitigated > >> >> somewhat with aggressive TTL. > >> >> * More often than not when performing a graceful failover we need to > >> >> restart Artemis > >> >> on the new live. Consumers connect but they don’t receive any > >> >> messages. > >> >> * In some instances the mirror queues have not shown up in the Artemis > >> >> console > >> >> but have functioned. No known steps to reproduce, in all cases > >> >> eventually resolved > >> >> themselves. > >> >> > >> >> * Messages in the logs that indicate problems we don’t know the effect > >> >> of like: > >> >> > >> >> 2022-05-30 00:30:12,964 WARN > >> >> [org.apache.activemq.artemis.protocol.amqp.connect.mirror.AMQPMirrorControllerTarget] > >> >> Queue activemq.management.665d289a-520e-40a6-9233-96265817ca6c not > >> >> found on mirror target, ignoring ack for > >> >> queue=activemq.management.665d289a-520e-40a6-9233-96265817ca6c, > >> >> messageID=68514641673, nodeID=dea32b83-efd5-11eb-b5b1-0050568fe3b2 > >> >> > >> >> > >> >> I hope as we grow we’ll be able to devote a resource to working on > >> >> Artemis. > >> >> It’s a critical and highly performant part of our infrastructure. I > >> >> have personally been > >> >> advocating for it to replace our aging JbossMQ 4 (pre-hornet) > >> >> infrastructure. > >> >> > >> >> The JDBC replication is part of that plan, to replace a similarly JDBC > >> >> replicated > >> >> JbossMQ 4 cluster that is for the first time, outside of products that > >> >> I’m directly > >> >> responsible for. > >> >> > >> >> A bit more than I intended to write, but I hope this helps understand > >> >> our where > >> >> we are and our motivations. > >> >> > >> >> > >> >> From: Justin Bertram <jbert...@apache.org> > >> >> Date: Wednesday, June 1, 2022 at 12:34 AM > >> >> To: users@activemq.apache.org <users@activemq.apache.org> > >> >> Subject: Re: Artemis MQ with JDBC persistence not starting since 2.22 > >> >> update > >> >> I sent a commit to update the docs in the repo, and I also updated the > >> >> website. > >> >> > >> >> Out of curiosity, how is your MySQL replication configured? Are you > >> >> using > >> >> the default asynchronous, semisynchronous, or fully synchronous NDB > >> >> cluster? > >> >> > >> >> > >> >> Justin > >> >> > >> >> On Tue, May 31, 2022 at 4:09 PM Stephen Baker < > >> >> stephen.ba...@rmssoftwareinc.com> wrote: > >> >> > >> >>> Understood thank you. We (the company I work for) are definitely > >> >>> getting > >> >>> more value out of the product than we are contributing, so that point > >> >>> is > >> >>> taken. The JDBC replication route was recommended by a consultant from > >> >>> Savoir as more established/reliable than mirroring when delivery > >> >>> guarantees > >> >>> are important, which is why we are pursuing it. > >> >>> > >> >>> > >> >> [EXTERNAL]: This email originated from outside of Rave Mobile Safety. > >> >> Do not click links or open attachments unless you recognize the sender > >> >> and know the content is safe. > >> > > >> > > >> > > >> > -- > >> > Clebert Suconic > >> > > -- > > Clebert Suconic > > > > -- > Clebert Suconic -- Clebert Suconic