> 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-history-day-limit=10 for all queues if that is at all significant. I don't think that is relevant here. > We have not tried explicit compacting the journal yet... 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 which is why it requires occasional compaction. However, JDBC is not append-only. Records are removed during normal processing, including the set-scheduled-delivery-time records that are accumulating in your database. I tested this with both 2.16.0 and 2.38.0 (i.e. the latest) and I didn't see any accumulation. As soon as the message associated with the set-scheduled-delivery-time records was acknowledged all those records were cleaned up. In any case, I don't believe that WildFly even supports the "data compact" command so it would almost certainly be a head-ache to execute it. To be clear, I typically only recommend folks use the embedded broker in WildFly for the most trivial use-cases. As soon as complexity increases it's usually good to have a standalone broker which can be managed (e.g. upgraded, restarted, etc.) separately. > I was under the impression that Artemis also compacts the journal during startup. Despite the fact that compaction doesn't appear to be related here I just wanted to say that I don't believe the broker always compacts the journal at startup. What gave you that impression? Ultimately I'm not sure what's going on here. I'd need to be able to reproduce the problem myself for further investigation. Do you have a way to reproduce this problem? Justin On Tue, Oct 29, 2024 at 8:05 AM Bisil <bi...@idfix.nl> wrote: > 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 that is at all > significant. > > We have not tried explicit compacting the journal yet and since the > AMQ-related tables on production environments that ran into this > situation were truncated to get things back up we can not do this right > now. > I was under the impression that Artemis also compacts the journal during > startup. If that is true could we not simply try restarting the Wildfly > server if we see large journal volumes to check if that makes a > difference, or is that not the same? If so, could you elaborate a bit > since I know how to stop/start the broker from the JBoss CLI but have no > knowledge about an explicit journal compaction command. > > We use JDBC persistence for a couple of reasons. Having the journal > inside the database makes it easier for us to keep things in sync with > backups/restores which we also use heavily for trouble shooting. In > addition to that using file based persistence comes with additional > costs in our cloud environments. > > Silvio > > > On 28-10-2024 15:04, Justin Bertram wrote: > > 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,893 > > - Update Transactional (14) > > - Add reference (32) 63,893 > > - Acknowledge reference (33) 2 > > - Prepare (17): 228 > > - Commit (18): 22,941 > > > > So it looks like you're using a lot of scheduled messages, either > directly > > or indirectly (e.g. via redelivery delay), and the records related to the > > delivery schedule are accumulating. If you stop the broker and run the > > "journal compact" command does the number of records in the database > drop? > > > > Out of curiosity, is there a specific reason you're using JDBC vs. the > > traditional file-based journal on local disk? > > > > > > Justin > > > >
