#java #elasticsearch #hibernate-search
#java #elasticsearch #гибернационный режим-поиск
Вопрос:
Я рассматриваю возможность переноса нашей реализации гибернационного поиска с файловых индексов lucene на elasticsearch, но меня смущает документация. В частности, для стратегии управления индексной схемой НЕТ:
Индекс, его сопоставления и определения анализатора не будут созданы, удалены или изменены. Поиск в режиме гибернации даже не проверяет, что индекс уже существует.
Мы хотим удалить зависимость от запуска hibernate search (чтобы он не пытался запрашивать elasticsearch при запуске). Чтение стратегий управления схемой показывает, что НИКТО не должен этого делать.
Однако, глядя на реализацию кода, я вижу, что он по-прежнему явно проверяет, существует ли индекс:
if (this.schemaManagementStrategy == IndexSchemaManagementStrategy.NONE) {
this.schemaCreator.checkIndexExists(this.actualIndexName, this.schemaManagementExecutionOptions);
return false;
}
Я бы ожидал, что этого не произошло. Когда я ввел намеренно неправильный хост для подключения, запуск сервера по-прежнему завершается сбоем с:
Request:
========
Operation: IndicesExists
URI: registryreference
Data:
null
Response:
=========
null
at org.hibernate.search.elasticsearch.client.impl.JestClient.executeRequest(JestClient.java:188) ~[hibernate-search-elasticsearch-5.6.5.Final.jar:5.6.5.Final]
... (omitted rest of stack)
Caused by: java.net.ConnectException: Connection refused: connect
Мы используем hibernate search 5.6.5 и elasticsearch 2.4.6.
Комментарии:
1. даже если не проверять схему индекса, ожидается, что пул подключений будет подготовлен для индексации, и запрос будет выполнен. Не могли бы вы подробнее описать ваш вариант использования и как вы собираетесь контролировать, когда, наконец, безопасно пытаться установить соединения?
2. Привет @Sanne , мы предпочли бы, чтобы обновления / запросы завершались сбоем во время выполнения из-за сбоя elasticsearch, а не из-за сбоя веб-серверов / пакетных заданий из-за того, что мы не можем запустить сервер, что случалось с нами в прошлом. Отсутствие индекса для нас не критично и не должно препятствовать возможности перезагрузки приложения в случае необходимости — мы всегда можем повторно проиндексировать, если потребуется, после простоя. Разве невозможно подготовить пул соединений отдельно от проверки, существует ли индекс?
Ответ №1:
Это ошибка: HSEARCH-2568.
Это было исправлено в Hibernate Search 5.7.0.Final, поэтому обновление должно сработать. Однако вам также придется обновить Hibernate ORM до версии 5.2. Если вы пойдете по этому пути, я бы посоветовал перейти непосредственно на Hibernate Search 5.11 и ORM 5.4, самые последние версии, в которых было исправлено довольно много ошибок.
Имейте в виду, что, как упоминал @Sanne, даже если Hibernate Search не отправляет запрос в кластер Elasticsearch, он все равно может создать пул TCP-соединений. Может быть, вы можете рассказать нам больше о вашем варианте использования, чтобы мы могли помочь?
Комментарии:
1. мы рассматривали возможность обновления, но, к сожалению, проект QueryDSL заблокирован и мы все еще застряли с 5.1, по крайней мере, в краткосрочной и среднесрочной перспективе. Есть ли вероятность обратного переноса в 5.6?
2. Это маловероятно, если только кто-то не вызвался добровольно: Search 5.6 довольно старый, а ORM 5.1 даже больше не поддерживается. Возможно, в какой-то момент мы выпустим последний релиз, но сейчас это явно не приоритет.