Tim, I think you are referring to this fix here: https://issues.apache.org/jira/browse/AMQ-4832
Looks like it was done in 5.9.1 and later. There's also been some other fixes and improvements done in this area recently so I would definitely recommend upgrading to a more recent version and giving that a shot. On Wed, Nov 18, 2015 at 8:55 AM, Tim Bain <tb...@alumni.duke.edu> wrote: > I have a vague memory of seeing a fix for exactly this bug in one of the > most recent (5.11.x or later) versions, but I couldn't find it in a quick > search of JIRA. Can anyone confirm my memory? > > If I'm remembering correctly, then an upgrade to 5.12.1 should fix your > problem. If your organization will let you, you could upgrade your staging > environment to see if the observed behavior changes. > > Tim > On Nov 18, 2015 2:53 AM, "patrikwettergren" <patrik.wetterg...@tr.com> > wrote: > > > Hello we are running on a Master/Slave Setup of two ActiveMQ Brokers with > > version 5.9. > > > > We have taken a copy of our ActiveMQ Production KahaDB and placed it in > the > > Stage Environment. This to resolve an issue with DLQ placed Messages. > > > > The issue we are seeing now is that the Stage ActiveMQ Brokers are > running > > a > > full re-index every time they are restarted and when the re-indexing are > > done the Broker states that there is not enough space on the disk and it > > then caps the usage of the disk to what it reads is available. > > > > The problem is here that the used disk space is from the copied KahaDB > that > > the AMQ Broker just re-indexed. > > > > So in other word it reads the KahaDB files fine to re-index the data in > > them, but does not take into account of what diskspace it is already > using > > when reading space available when it is finished the re-indexing. > > > > The Size of the KahaDB Set is 226GB it is placed on a 500GB Mount on and > > the > > ActiveMQ Brokers are runninng on Oracle Linux Server release 6.5 > > OL-6.5.1-64 > > servers with JDK 6. > > > > > > In activemq.xml we have set the flow control so that anyhting above 75% > of > > storage usage stops messages handling on specific queues and the storage > > usage is set : > > <systemUsage> > > <systemUsage> > > <memoryUsage> > > <memoryUsage percentOfJvmHeap="75" /> > > </memoryUsage> > > <storeUsage> > > <storeUsage limit="400 gb"/> > > </storeUsage> > > <tempUsage> > > <tempUsage limit="50 gb"/> > > </tempUsage> > > </systemUsage> > > </systemUsage> > > > > But even so the AMQ Brokers only sees the availble Disk space in '500G > > 226G > > 275G 46%' on the Mount and activates the flow control since the 275Gb > > available space is smaller then the 400GB stated in activemq.xml. > > > > So the question is now why is the Broker doing this even after it have > read > > through the KahaDB data and reindexed it and updated the db.data file and > > is > > using the 226GB but does not take this into account when reading the > > 'storageUsage' limit in activemq.xml > > > > > > I might be missing something here ot is it just as simple that I need to > > get > > the Mountpoint of 500GB larger. So any help would be very appriciated. > > > > > > Kind regards > > Patrik Wettergren > > > > > > > > > > > > -- > > View this message in context: > > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Brokers-starts-the-reindex-of-the-KahaDB-on-every-startup-tp4704035.html > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > >
