We are in the process of upgrading. Unfortunately some incompatibilities
exist (like the Jakarta namespace) so this may take a while. But we
intend to try and keep closer to released versions once we are upgraded.
In the meantime is there anything you could say about one of my original
questio
Thank you.
On 01-11-2024 20:00, Clebert Suconic wrote:
this was
https://github.com/apache/activemq-artemis/commit/e719622de5488f859f70beda926afaa51d5b0ff9
https://issues.apache.org/jira/browse/ARTEMIS-4285
with the new Wildfly, perhaps you have to add in the new settings to
have it preventi
this was
https://github.com/apache/activemq-artemis/commit/e719622de5488f859f70beda926afaa51d5b0ff9
https://issues.apache.org/jira/browse/ARTEMIS-4285
with the new Wildfly, perhaps you have to add in the new settings to
have it preventing the issue.
You could also use max redelivery and send
In the meantime, I strongly recommend you upgrade. The latest version of
WildFly is 34.0.0 and it has ActiveMQ Artemis 2.37.0 (which isn't the
latest, but it's much closer than 2.16.0).
Justin
On Fri, Nov 1, 2024 at 5:11 AM Bisil wrote:
> > I assume you're referring to redelivery-delay-multipl
Thank you Clebert. It would be very interesting to know more about this.
As far as I know infinite redelivery is what you get with a max
redelivery count of -1 which we do not use. And we have DQL configured
but nonetheless I would love to investigate this.
Silvio
On 31-10-2024 10:59, Clebe
I assume you're referring to redelivery-delay-multiplier and
max-delivery-attempts here.
Yes, that is correct.
I don't think that is relevant here.
Ok, good to know.
I had a look through the JDBC code and I see now that compaction is a red
herring. The normal file-based journal is append-only
I remember an old issue where rescheduling deliveries were updated over and
over.
As of the latest version as far as I remember I only update it once.
If you have an infinite redelivery without DLQ you might get into that
situation.
It would be difficult for me to find the exact JIRA now. But I
> We do use indirect scheduled messages intensively since we have
redelivery-delay=1000, redelivery-multiplier=2, redelivery-attempts=9
settings for the majority of queues.
I assume you're referring to redelivery-delay-multiplier and
max-delivery-attempts here.
> We also use message-counter-histo
Hi Justin,
Thanks again for your valuable insights.
We do use indirect scheduled messages intensively since we have
redelivery-delay=1000, redelivery-multiplier=2, redelivery-attempts=9
settings for the majority of queues. We also use
message-counter-history-day-limit=10 for all queues if tha
Based on the information you provided I can say that the problem isn't what
I originally expected. Here's how the data breaks down per record type:
- Add (11)
- Set scheduled delivery time (36): 376,143,458
- Update delivery count(34): 290,102
- Add Transactional (13)
- Add message (45): 63
Thanks for the reply Justin.
After restoring the database in its original state I ran counts on
recordType/userRecordType and got this:
recordType userRecordType count(*)
11 36 376143458
11 34 290102
13 45 63893
14 32 63893
18 255 22941
17
This sounds similar to an issue involving duplicate IDs proliferating in
the journal. I can't find the specific Jira at the moment, but the issue
was something like a huge build-up of duplicate ID records. Can you inspect
the "userRecordType" for the offending rows?
Also, how are you sending your
12 matches
Mail list logo
