activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Kahadb journal logs only deleted when activemq restarts
Date Sat, 20 Apr 2019 14:15:52 GMT
On Fri, Apr 19, 2019, 6:34 PM TC <> wrote:

> "I wasn't aware of any reason that the logging config and debugging
> techniques described on that page would not work properly with mKahaDB. Can
> you please elaborate on the failure you referenced?"
> - Added the with the following
> log4j.appender.kahadb=org.apache.log4j.RollingFileAppender
> log4j.appender.kahadb.file=/myowndirectory/kahadb.log
> /data/kahadb.log log4j.appender.kahadb.maxFileSize=1024KB
> log4j.appender.kahadb.maxBackupIndex=5 log4j.appender.kahadb.append=true
> log4j.appender.kahadb.layout=org.apache.log4j.PatternLayout
> log4j.appender.kahadb.layout.ConversionPattern=%d [%-15.15t] %-5p
> %-30.30c{1} - %m%n
>, kahadb
> - did not restart the ActiveMQ - rather than waited for 10 minutes or so

Do you have any information to indicate that this process (waiting 10
minutes) will cause the ActiveMQ process to reload its Log4J config file?
The page Chris referenced describes two procedures (the only two I'm aware
of), neither of which is to wait for a set amount of time. Try using the
JMX procedure and see if that works with your mKahaDB setup.

- there is no kahadb.log file exist in the directory.
> The ActiveMQ version i am using 5.14.4
> " Also, Sunil rightly pointed out that the behavior you've described can be
> caused by uncommitted transactions. Are transactions in use anywhere, and
> if so have you explored the possibility that they might not be getting
> committed?  "
> - What is uncommitted transactions ? Based on mKahaDB  with per destination
> journal logs , the increasing logs are increasing are the 2 queues
> mentioned
> earlier, i.e. forwarded from topic using VirtualDestination.  These queue
> are processed by a Node.js stomp client which basically inserting the
> message data into a NoSQL database - there is no transactions per say in
> the
> code itself.

Transactions in this context are a JMS concept: Although they can be
tied to a SQL transaction, they don't have to be, and wouldn't be since
you're using mKahaDB. Since your consumers all use STOMP, then there are no
transactions in use, because STOMP doesn't support transactions. So we'll
have to see what you learn from following the process described on the page
Chris provided.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message