Hi Matt, Appreciate the response. We'll keep digging on our side and loop back if we're able to provide anything more concrete.
Regards, Derek Zhang On Fri, 26 Apr 2024 at 13:31, Matt Pavlovich <mattr...@gmail.com> wrote: > Hi Derek- > > No known report with a similar scenario. Without a specific exception > message or reproducible use case, this isn’t something that the Apache > community is able to effectively support given all the possible factors in > your organizations specific environment. > > If you are able to reproduce it in a unit test or get a specific error > message, we’d be able to give it a shot. > > If your organization really needs a root cause — checkout out the > commercial support options. > > Thanks, > Matt Pavlovich > > > On Apr 26, 2024, at 3:19 PM, Derek Zhang <derekdyzh...@gmail.com> wrote: > > > > Thanks Justin, > > > > Yes, we realize that we're not doing ourselves any favours by staying on > > 5.15.x in this case as there have been numerous improvements to ActiveMQ > > since. > > > > Because this issue is very sporadic and hard to reproduce, we're mostly > > curious if anyone else has seen this in the past at all. In the off > chance > > that this was a known issue and has been fixed in later versions, we'd be > > very interested in learning the root cause as well. > > > > Regards, > > Derek Zhang > > > > On Fri, 26 Apr 2024 at 13:06, Justin Bertram <jbert...@apache.org> > wrote: > > > >> I can't comment regarding your specific issue, but it's worth noting > that > >> 5.15.x is no longer actively maintained. It may be worth upgrading to > the > >> latest 5.18.x version or perhaps even 6.x. > >> > >> > >> Justin > >> > >> On Fri, Apr 26, 2024 at 2:26 PM Derek Zhang <derekdyzh...@gmail.com> > >> wrote: > >> > >>> Hello ActiveMQ Classic community, > >>> > >>> We recently saw a broker running 5.15.16 getting stuck during recovery. > >>> When ActiveMQ was started, we saw the following log messages and then > >>> nothing else: > >>> > >>> 2024-04-18 17:21:52,670 | INFO | Refreshing > >>> org.apache.activemq.xbean.XBeanBrokerFactory$1@25bbe1b6: startup date > >> [Thu > >>> Apr 18 17:21:52 UTC 2024]; root of context hierarchy | > >>> org.apache.activemq.xbean.XBeanBrokerFactory$1 | main > >>> 2024-04-18 17:21:53,886 | INFO | Using Persistence Adapter: > >>> KahaDBPersistenceAdapter[/data/kahadb] | > >>> org.apache.activemq.broker.BrokerService | main > >>> 2024-04-18 17:22:04,246 | INFO | Page File: /data/kahadb/db.data. > >>> Recovering pageFile free list due to prior unclean shutdown.. | > >>> org.apache.activemq.store.kahadb.disk.page.PageFile | KahaDB Index Free > >>> Page Recovery > >>> 2024-04-18 17:22:04,250 | INFO | KahaDB is version 6 | > >>> org.apache.activemq.store.kahadb.MessageDatabase | main > >>> 2024-04-18 17:22:09,123 | INFO | Recovering from the journal > >>> @190198:17434278 | org.apache.activemq.store.kahadb.MessageDatabase | > >> main > >>> 2024-04-18 17:53:10,507 | INFO | Page File: /data/kahadb/db.data. > >>> Recovered pageFile free list of size: 377183 | > >>> org.apache.activemq.store.kahadb.disk.page.PageFile | KahaDB Index Free > >>> Page Recovery > >>> > >>> During this time, we saw our KahaDB directory starting to grow in size. > >>> Over the course of around a day, we saw our KahaDB directory grow by > >> around > >>> 1 TB. Taking a look in the directory, the space was primarily consumed > by > >>> *.tmp files. > >>> > >>> We were able to fix our broker by deleting db.redo and the large *.tmp > >>> files and restarting ActiveMQ. We are still in the process of digging > >>> deeper into what exactly happened here, but has the ActiveMQ Classic > >>> community seen anything like this before? > >>> > >>> Thank you in advance. > >>> > >>> Regards, > >>> Derek Zhang > >>> > >> > > > > > > -- > > -Derek Zhang > > -- -Derek Zhang
