Попытка установить Solr 6.2.1 на Debian Jessie Я попал в блокпост, в котором я не могу создать коллекцию. Последовательность командSolr 6.x не может создавать коллекции на одном Debian Jessie 8.6
unzip solr-6.2.1.zip
export JAVA_HOME=/opt/java64/jdk1.8.0_101
./solr-6.2.1/bin/solr -c
./solr-6.2.1/bin/solr create_collection -c hktesting
не может быть более невинным и работает на другом Debian Jessie, а также на Ubuntu 16.10. Однако на этой машине create_collection работает с таймаутом. Я даже использовал недавно добавленного пользователя без каких-либо настроек dotfile.
Полный журнал довольно длинный, поэтому я стараюсь выбирать строки, которые, по моему мнению, актуальны. Все начинается хорошо с:
2016-11-03 08:08:36.360 INFO (qtp110456297-20) [ ] o.a.s.h.a.CollectionsHandler Invoked Collection Action :create with params replicationFactor=1&maxShardsPerNode=1&collection.configName=hktesting&name=hktesting&action=CREATE&numShards=1&wt=json and sendToOCPQueue=true
Сообщений следуют которые все выглядят хорошо, показывая много будут дополнения в создании коллекции. Все это относится к промежуточному концу:
2016-11-03 08:08:38.399 WARN (qtp110456297-18) [c:hktesting s:shard1 r:core_node1 x:hktesting_shard1_replica1] o.a.s.c.SolrCore [hktesting_shard1_replica1] Solr index directory '/home/badsolr/tmp/solr-6.2.1/server/solr/hktesting_shard1_replica1/data/index' doesn't exist. Creating new index...
2016-11-03 08:08:38.408 INFO (qtp110456297-18) [c:hktesting s:shard1 r:core_node1 x:hktesting_shard1_replica1] o.a.s.c.CachingDirectoryFactory return new directory for /home/badsolr/tmp/solr-6.2.1/server/solr/hktesting_shard1_replica1/data/index
который все еще выглядит нормально для меня. Затем идет три минуты отверстие в журнале с ничего не происходит, после которого неуспеха:
2016-11-03 08:11:36.373 ERROR (qtp110456297-20) [ ] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: create the collection time out:180s
at org.apache.solr.handler.admin.CollectionsHandler.handleResponse(CollectionsHandler.java:289)
at org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:215)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:658)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:440)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
Этой машина включена проверка подлинности Kerberos, что о только возможно, соответствующей разнице в другие машины я не знаю (но не переходите к выводам).
Получаете ли вы что-нибудь в своем syslog/messages/dmesg? (т. е. убийства OOM, предупреждения об атаках, конфликты с файловыми замками, ошибка диска и т. д.) – MatsLindh
Ничего не нужно для 'rgrep '09: 08'' или 09:11 в'/var/log'. Solr, похоже, регистрирует UTC, поэтому 1hour сдвиг в grep против '/ var/log'. И ничего в эти времена тоже. И ничего в 'dmesg -T'. – Harald
Если вы используете 'jstack' против pid виртуальной машины, вы сможете получить трассировку стека из того, что делает сервер Solr. Может быть, это может сказать вам, что именно ждет. Сложность JVM также может помочь, но на более низком уровне. – MatsLindh