Я запускаю один (немасштабированный) экземпляр solr в службе приложений Azure.Служба приложений работает на Java 8 и контейнере Jetty 9.3.
Все работает очень хорошо, но когда Azure решает переключиться на другую виртуальную машину, иногда JVM, похоже, не завершает работу корректно, и мы сталкиваемся с проблемами.
Одной из причин, по которой Azure решило перейти на другую виртуальную машину, является обслуживание инфраструктуры.Например, установлены обновления Windows, и ваше приложение перемещено на другой компьютер.
Во избежание простоя Azure раскручивает новое приложение, а когда оно будет готово, оно переключается на новое приложение.Вроде бы нормально, но, похоже, это плохо работает с механизмом блокировки solr.
Мы используем нативный по умолчанию lockType, что должно быть хорошо, так как мы запускаем только один экземпляр.Solr должен удалить файл write.lock во время завершения работы, но, похоже, это происходит не всегда.
Инструменты диагностики Azure четко показывают, что это событие происходит: 
И использование памяти показывает оба приложения: 
Во время запуска второго экземпляра solr пытается заблокировать индекс, но это невозможно, поскольку первоевсе еще использует его (он также имеет файл write.lock).Иногда первый не удаляет файл write.lock, и это - то, с чего начинаются проблемы.Второй экземпляр solr никогда не будет работать правильно без ручного вмешательства (удаление файла write.lock вручную).
Журналы solr:
Caused by: org.apache.solr.common.SolrException: Index dir 'D:\home\site\wwwroot\server\solr\****\data\index/' of core '*****' is already locked. The most likely cause is another Solr server (or another solr core in this server) also configured to use this directory; other possible causes may be specific to lockType: native
и
org.apache.lucene.store.LockObtainFailedException
Что можно сделать по этому поводу?Я думал об изменении lockType на блокировку на основе памяти, но я не уверен, сработает ли это, потому что оба экземпляра живы одновременно в течение короткого периода времени.