ActiveMQ Артемида блокирует на старте
Наша система активно использует Artemis в качестве сервиса JMS. В последнее время начало процесса блокирует на 1 минуту Артемида. Мы использовали Jstack для получения трассировки стека, и это выглядит так:
Thread 4515: (state = IN_JAVA)
- org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(org.apache.activemq.artemis.core.io.SequentialFileFactory, org.apache.activemq.artemis.core.journal.impl.JournalFile, org.apache.activemq.artemis.core.journal.impl.JournalReaderCallback) @bci=143, line=461 (Compiled frame; information may be imprecise)
- org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(org.apache.activemq.artemis.core.journal.LoaderCallback, boolean, org.apache.activemq.artemis.core.journal.Journal$JournalState) @bci=283, line=1728 (Interpreted frame)
- org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(java.util.List, java.util.List, org.apache.activemq.artemis.core.journal.TransactionFailureCallback, boolean) @bci=41, line=1365 (Interpreted frame)
- org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(java.util.List, java.util.List, org.apache.activemq.artemis.core.journal.TransactionFailureCallback) @bci=5, line=1349 (Interpreted frame)
- org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.loadMessageJournal(org.apache.activemq.artemis.core.postoffice.PostOffice, org.apache.activemq.artemis.core.paging.PagingManager, org.apache.activemq.artemis.core.transaction.ResourceManager, java.util.Map, java.util.Map, java.util.Set, java.util.List, org.apache.activemq.artemis.core.server.impl.JournalLoader) @bci=49, line=839 (Interpreted frame)
- org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals() @bci=195, line=2585 (Interpreted frame)
- org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(boolean) @bci=31, line=2352 (Interpreted frame)
- org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run() @bci=58, line=71 (Interpreted frame)
- org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart() @bci=390, line=635 (Interpreted frame)
- org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start() @bci=6, line=479 (Interpreted frame)
- org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start() @bci=27, line=390 (Interpreted frame)
- org.apache.activemq.artemis.jms.server.embedded.EmbeddedJMS.start() @bci=155, line=126 (Interpreted frame)
- org.javalite.async.Async.start() @bci=28, line=195 (Interpreted frame)
- app.services.jms.JmsServiceImpl.start() @bci=129, line=107 (Interpreted frame)
- app.config.AppBootstrap.getInjector() @bci=35, line=60 (Interpreted frame)
- org.javalite.activeweb.RequestDispatcher.initAppConfig(java.lang.String, org.javalite.activeweb.AppContext, boolean) @bci=51, line=136 (Interpreted frame)
- org.javalite.activeweb.RequestDispatcher.initApp(org.javalite.activeweb.AppContext) @bci=6, line=71 (Interpreted frame)
- org.javalite.activeweb.RequestDispatcher.init(javax.servlet.FilterConfig) @bci=134, line=65 (Interpreted frame)
- org.apache.catalina.core.ApplicationFilterConfig.initFilter() @bci=99, line=285 (Interpreted frame)
- org.apache.catalina.core.ApplicationFilterConfig.getFilter() @bci=38, line=266 (Interpreted frame)
- org.apache.catalina.core.ApplicationFilterConfig.<init>(org.apache.catalina.Context, org.apache.tomcat.util.descriptor.web.FilterDef) @bci=37, line=108 (Interpreted frame)
- org.apache.catalina.core.StandardContext.filterStart() @bci=148, line=4637 (Interpreted frame)
- org.apache.catalina.core.StandardContext.startInternal() @bci=1235, line=5282 (Interpreted frame)
- org.apache.catalina.util.LifecycleBase.start() @bci=210, line=150 (Interpreted frame)
- org.apache.catalina.core.ContainerBase.addChildInternal(org.apache.catalina.Container) @bci=170, line=754 (Interpreted frame)
- org.apache.catalina.core.ContainerBase.addChild(org.apache.catalina.Container) @bci=26, line=730 (Interpreted frame)
- org.apache.catalina.core.StandardHost.addChild(org.apache.catalina.Container) @bci=40, line=734 (Interpreted frame)
- org.apache.catalina.startup.HostConfig.deployWAR(org.apache.catalina.util.ContextName, java.io.File) @bci=1905, line=985 (Interpreted frame)
- org.apache.catalina.startup.HostConfig$DeployWar.run() @bci=12, line=1857 (Interpreted frame)
- java.util.concurrent.Executors$RunnableAdapter.call() @bci=4, line=511 (Interpreted frame)
- java.util.concurrent.FutureTask.run() @bci=42, line=266 (Interpreted frame)
- java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) @bci=95, line=1149 (Interpreted frame)
- java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=624 (Interpreted frame)
- java.lang.Thread.run() @bci=11, line=748 (Interpreted frame)
После изучения файлов журнала мы видим это:
du -m --max-depth 1
9721 ./journal
4 ./bindings
0 ./largemessages
1 ./paging
9725 .
Другими словами, размер журнала составляет около 10 ГБ, а все очереди пусты.
Это причина медленного старта? Как мы можем избежать этого в будущем с помощью метода, отличного от уничтожения всех файлов журнала и перезапуска процесса?
РЕДАКТИРОВАТЬ: вышеупомянутая трассировка стека является единственным с состоянием = IN_JAVA. Все остальные потоки припаркованы во время ожидания процесса. Все ожидание занимает от минуты до двух. Все остальные темы взяты из jstack не имеют значения.