Hi Chris ,
How did you solve this caching issue while your brokers standing on master
slave ..?
Did you put out any settings in activemq xml to startup the broker in quick
time or making it quick failover ?
Thanks,
Akhil.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f234
Sure, YOU know it was a clean shutdown, but how does your slave broker know
which type it was?
Methods to signal that fact could be added, but none currently exists in
the code.
On Apr 29, 2016 7:14 AM, "Christian Schneider"
wrote:
> I do not assume that the restart will be clean when the master
I do not assume that the restart will be clean when the master dies.
In our case the brokers are shutdown orderly during a regular
maintenance where some of the customer software is updated on the system.
So in the case were we experienced the slow start it was a clean shutdown.
Christian
On
Also, your question makes the assumption that files your broker stumbles
upon when it becomes master were written by a previous master that shutdown
cleanly, which is a rather optimistic assumption to make.
On Apr 29, 2016 7:01 AM, "Tim Bain" wrote:
> By reading the code (
> http://www.grepcode.c
By reading the code (
http://www.grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-kahadb-store/5.11.1/org/apache/activemq/store/kahadb/disk/journal/Journal.java#Journal.recoveryCheck%28org.apache.activemq.store.kahadb.disk.journal.DataFile%29),
I found that we're reading the da
We have found the main cause for this issue. Current Master and new
Master seem to do the exact same things on startup.
They read all the journals.
It seems that the OS is caching the files in memory in some cases.
The master seems to have all the jorunal files in the cache. So when it
restarts
I now took thread dumps of activemq while it was taking so long to
start up.
This is where it seemed to spend most of the time:
http://apaste.info/H1c
So it looks like it is reading the kahadb journals. Does anyone have an
idea why it seems to matter if the master restarts (fast) or the dlave
he startup (perhaps one every 15 seconds), and look at the
stack trace of the main broker startup thread. That should help determine
the cause.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Failover-very-slow-with-kahadb-while-restart-of-master-is-fast-tp4707500p4708777.html
You could use a profiler such as JVisualVM to tell you what work is being
done. You could get some of that information from thread dumps via jstack,
but I think a profiler would give much more useful and detailed information
for less effort.
Tim
On Feb 15, 2016 5:37 AM, "Jean-Baptiste Onofré" wr
Hi Christian,
what's the option on the NFS ?
Most of the time, I use I use sync and I increase the rsize and wsize.
Anyway, the difference is huge. The problem could be related to the
journal checksum check. Can you try checkForCorruptJournalFiles="false"
on the kahadb configuration ?
Maybe
At a customer we are experiencing a very strange behaviour of activemq.
We have two brokers on separate machines A and B. Storage is on a third
machine and imported using nfsv4.
Kahadb contains about 18 GB of journal files.
Scenario 1:
- Stop B
- Stop A (master now)
- Start A
The start of A t
11 matches
Mail list logo
