The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.

Hibernate Search ガイド

Hibernate ORMベースのアプリケーションを持ってますか?フル機能の全文検索をユーザーに提供したいですか?あなたは正しいドキュメントを読んでいます。

このガイドでは、Hibernate Search を使用して、エンティティを Elasticsearch または OpenSearch クラスタに瞬時に同期させる方法を学びます。また、Hibernate Search API を使用して Elasticsearch または OpenSearch クラスタにクエリを実行する方法についても説明します。

前提条件

このガイドを完成させるには、以下が必要です:

  • ざっと 20 minutes

  • IDE

  • JDK 11+ がインストールされ、 JAVA_HOME が適切に設定されていること

  • Apache Maven 3.8.6

  • 動作するコンテナランタイム(Docker, Podman)

  • 使用したい場合は、 Quarkus CLI

  • ネイティブ実行可能ファイルをビルドしたい場合、MandrelまたはGraalVM(あるいはネイティブなコンテナビルドを使用する場合はDocker)をインストールし、 適切に設定していること

アーキテクチャ

このガイドに記載されているアプリケーションは、(シンプルな) 図書館を管理することができます:あなたは、著者とその本を管理します。

エンティティはPostgreSQLデータベースに格納され、Elasticsearchクラスターにインデックスされます。

ソリューション

次のセクションで紹介する手順に沿って、ステップを踏んでアプリを作成することをお勧めします。ただし、完成した例にそのまま進んでも構いません。

Gitレポジトリをクローンするか git clone https://github.com/quarkusio/quarkus-quickstarts.gitアーカイブ をダウンロードします。

ソリューションは hibernate-search-orm-elasticsearch-quickstart ディレクトリ にあります。

提供されるソリューションには、テストやテストのインフラストラクチャなど、いくつかの追加要素が含まれています。

Mavenプロジェクトの作成

まず、新しいプロジェクトが必要です。以下のコマンドで新規プロジェクトを作成します:

コマンドラインインタフェース
quarkus create app org.acme:hibernate-search-orm-elasticsearch-quickstart \
    --extension='hibernate-orm-panache,jdbc-postgresql,hibernate-search-orm-elasticsearch,resteasy-reactive-jackson' \
    --no-code
cd hibernate-search-orm-elasticsearch-quickstart

Gradleプロジェクトを作成するには、 --gradle または --gradle-kotlin-dsl オプションを追加します。

Quarkus CLIのインストール方法や使用方法については、<a href="cli-tooling.html">Quarkus CLIガイド</a> を参照してください。

Maven
mvn io.quarkus.platform:quarkus-maven-plugin:2.14.2.Final:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=hibernate-search-orm-elasticsearch-quickstart \
    -Dextensions='hibernate-orm-panache,jdbc-postgresql,hibernate-search-orm-elasticsearch,resteasy-reactive-jackson' \
    -DnoCode
cd hibernate-search-orm-elasticsearch-quickstart

Gradleプロジェクトを作成するには、 -DbuildTool=gradle または -DbuildTool=gradle-kotlin-dsl オプションを追加します。

このコマンドは、以下のエクステンションをインポートするMaven構造体を生成します:

  • Hibernate ORM with Panache,

  • PostgreSQL JDBCドライバー,

  • Hibernate Search + Elasticsearch,

  • RESTEasy Reactive と Jackson.

すでにQuarkusプロジェクトが設定されている場合はプロジェクトのベースディレクトリで以下のコマンドを実行すればプロジェクトに hibernate-search-orm-elasticsearch エクステンションを追加することができます:

コマンドラインインタフェース
quarkus extension add 'hibernate-search-orm-elasticsearch'
Maven
./mvnw quarkus:add-extension -Dextensions='hibernate-search-orm-elasticsearch'
Gradle
./gradlew addExtension --extensions='hibernate-search-orm-elasticsearch'

これにより、 pom.xml に以下が追加されます:

pom.xml
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-hibernate-search-orm-elasticsearch</artifactId>
</dependency>
build.gradle
implementation("io.quarkus:quarkus-hibernate-search-orm-elasticsearch")

ただのエンティティの作成

まず、 model サブパッケージに Hibernate ORM エンティティ BookAuthor を作成しましょう。

package org.acme.hibernate.search.elasticsearch.model;

import java.util.List;
import java.util.Objects;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.OneToMany;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
public class Author extends PanacheEntity { (1)

    public String firstName;

    public String lastName;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.EAGER) (2)
    public List<Book> books;

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Author)) {
            return false;
        }

        Author other = (Author) o;

        return Objects.equals(id, other.id);
    }

    @Override
    public int hashCode() {
        return 31;
    }
}
1 Hibernate ORM with Panacheを使用していますが、必須ではありません。
2 私たちは、これらの要素がJSON出力に存在するように前もってロードしています。実際のアプリケーションでは、おそらくDTOアプローチを使うべきでしょう。
package org.acme.hibernate.search.elasticsearch.model;

import java.util.Objects;

import javax.persistence.Entity;
import javax.persistence.ManyToOne;

import com.fasterxml.jackson.annotation.JsonIgnore;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
public class Book extends PanacheEntity {

    public String title;

    @ManyToOne
    @JsonIgnore (1)
    public Author author;

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (!(o instanceof Book)) {
            return false;
        }

        Book other = (Book) o;

        return Objects.equals(id, other.id);
    }

    @Override
    public int hashCode() {
        return 31;
    }
}
1 このプロパティを @JsonIgnore でマークしてJacksonでシリアル化する際の無限ループを避けます。

RESTサービスの初期化

まだRESTサービスの設定はすべて終わっていませんが、必要となる標準的なCRUD操作で初期化することができます。

org.acme.hibernate.search.elasticsearch.LibraryResource クラスを作成します:

package org.acme.hibernate.search.elasticsearch;

import java.util.List;
import java.util.Optional;

import javax.enterprise.event.Observes;
import javax.inject.Inject;
import javax.transaction.Transactional;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.core.MediaType;

import org.acme.hibernate.search.elasticsearch.model.Author;
import org.acme.hibernate.search.elasticsearch.model.Book;
import org.hibernate.search.mapper.orm.session.SearchSession;
import org.jboss.resteasy.reactive.RestForm;
import org.jboss.resteasy.reactive.RestQuery;

import io.quarkus.runtime.StartupEvent;

@Path("/library")
public class LibraryResource {

    @PUT
    @Path("book")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void addBook(@RestForm String title, @RestForm Long authorId) {
        Author author = Author.findById(authorId);
        if (author == null) {
            return;
        }

        Book book = new Book();
        book.title = title;
        book.author = author;
        book.persist();

        author.books.add(book);
        author.persist();
    }

    @DELETE
    @Path("book/{id}")
    @Transactional
    public void deleteBook(Long id) {
        Book book = Book.findById(id);
        if (book != null) {
            book.author.books.remove(book);
            book.delete();
        }
    }

    @PUT
    @Path("author")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void addAuthor(@RestForm String firstName, @RestForm String lastName) {
        Author author = new Author();
        author.firstName = firstName;
        author.lastName = lastName;
        author.persist();
    }

    @POST
    @Path("author/{id}")
    @Transactional
    @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
    public void updateAuthor(Long id, @RestForm String firstName, @RestForm String lastName) {
        Author author = Author.findById(id);
        if (author == null) {
            return;
        }
        author.firstName = firstName;
        author.lastName = lastName;
        author.persist();
    }

    @DELETE
    @Path("author/{id}")
    @Transactional
    public void deleteAuthor(Long id) {
        Author author = Author.findById(id);
        if (author != null) {
            author.delete();
        }
    }
}

特別なことは何もありません。RESTサービスでのPanacheの処理と古き良きHibernateです。

実は、全文検索アプリケーションを動作させるために必要な要素はごくわずかです。

Hibernate Searchアノテーションの使用

エンティティに戻りましょう。

全文検索機能を有効にするには、いくつかのアノテーションを追加するだけで簡単です。

Book エンティティを再度編集して、この内容を入れてみましょう:

package org.acme.hibernate.search.elasticsearch.model;

import java.util.Objects;

import javax.persistence.Entity;
import javax.persistence.ManyToOne;

import org.hibernate.search.mapper.pojo.mapping.definition.annotation.FullTextField;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.Indexed;

import com.fasterxml.jackson.annotation.JsonIgnore;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
@Indexed (1)
public class Book extends PanacheEntity {

    @FullTextField(analyzer = "english") (2)
    public String title;

    @ManyToOne
    @JsonIgnore
    public Author author;

    // Preexisting equals()/hashCode() methods
}
1 まず、 @Indexed アノテーションを使って、 Book エンティティを全文検索インデックスの一部として登録してみましょう。
2 @FullTextField アノテーションは、全文検索用に特別に調整されたインデックスのフィールドを宣言します。特に、トークン(~単語)を分割して分析するためのアナライザーを定義する必要があります。 - これについては後で説明します。

Book がインデックス化されたことで、 Author にも同じことができるようになりました。

Author クラスを開き、以下の内容を記載します。

@Indexed@FullTextField@KeywordField のアノテーションを使用していますが、こちらもよく似ている機能です。

しかし、いくつかの違いや付加価値があります。それを見てみましょう。

package org.acme.hibernate.search.elasticsearch.model;

import java.util.List;
import java.util.Objects;

import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.OneToMany;

import org.hibernate.search.engine.backend.types.Sortable;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.FullTextField;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.Indexed;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.IndexedEmbedded;
import org.hibernate.search.mapper.pojo.mapping.definition.annotation.KeywordField;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
@Indexed
public class Author extends PanacheEntity {

    @FullTextField(analyzer = "name") (1)
    @KeywordField(name = "firstName_sort", sortable = Sortable.YES, normalizer = "sort") (2)
    public String firstName;

    @FullTextField(analyzer = "name")
    @KeywordField(name = "lastName_sort", sortable = Sortable.YES, normalizer = "sort")
    public String lastName;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.EAGER)
    @IndexedEmbedded (3)
    public List<Book> books;

    // Preexisting equals()/hashCode() methods
}
1 @FullTextFieldBook と同様のものを使用しますが、アナライザーが異なることに気がつくでしょう - これについては後で説明します。
2 このように、同じプロパティに複数のフィールドを定義することができます。ここでは、固有の名前を持つ @KeywordField を定義しています。主な違いは、キーワードフィールドはトークン化されません(文字列は1つのトークンとして保持される)が、正規化(すなわちフィルタリング)することができるということです。これについては後で説明します。このフィールドは Author のソートに使用することを意図しているため、ソート可能であるとマークされています。
3 @IndexedEmbedded の目的は Book のフィールドを Author のインデックスに含めることです。この場合はデフォルトの設定を使用します。つまり、関連する Book エンティティのすべてのフィールドがインデックスに含まれます (つまり title フィールドも含まれます)。 @IndexedEmbedded の優れた点は双方向の関係により Book のいずれかが更新された場合も Author のインデックスを自動的に再作成できることです。 @IndexedEmbedded は、入れ子になったドキュメントもサポートしていますが( storage = NESTED 属性を使用)ここでは必要ありません。また、すべてのフィールドを親インデックスに含める必要のない場合は、 includePaths 属性を使って含めるフィールドを指定することができます。

アナライザーとノーマライザー

はじめに

アナライズは全文検索の大きな部分を占めています。インデックス作成や検索クエリ構築の際に、テキストがどのように処理されるかを定義します。

アナライザーの役割は、テキストをトークン(~単語)に分割し、フィルターをかけることです(例えば、すべて小文字にしたり、アクセントを削除したり)。

ノーマライザーは入力を1つのトークンとして保持する特殊なアナライザです。特に、キーワードのソートやインデックス作成に有効です。

多くのバンドルされたアナライザーがありますが、自分の目的に合わせて独自に開発することもできます。

Elasticsearchアナリシスフレームワークについては、 ElasticsearchドキュメントのText analysis セクション で詳しく説明しています。

使用するアナライザーの定義

エンティティにHibernate Searchアノテーションを追加する際に、使用するアナライザーとノーマライザーを定義しました。典型的には:

@FullTextField(analyzer = "english")
@FullTextField(analyzer = "name")
@KeywordField(name = "lastName_sort", sortable = Sortable.YES, normalizer = "sort")

以下のものを使用しています:

  • 人名用の name というアナライザー,

  • 書籍のタイトル用の english というアナライザー,

  • ソートフィールド用の sort というノーマライザー

ですが、まだ設定していません。

それでは、Hibernate Searchを使ってどのように設定できるのか見てみましょう。

アナライザーのセットアップ

これは簡単な作業で、 ElasticsearchAnalysisConfigurer の実装を作成するだけです(そして、それを使用するようにQuarkusを設定します、詳細は後述します)。

要件を満たすために、次のような実装を作ってみましょう:

package org.acme.hibernate.search.elasticsearch.config;

import org.hibernate.search.backend.elasticsearch.analysis.ElasticsearchAnalysisConfigurationContext;
import org.hibernate.search.backend.elasticsearch.analysis.ElasticsearchAnalysisConfigurer;

import javax.enterprise.context.Dependent;
import javax.inject.Named;

@SearchExtension (1)
public class AnalysisConfigurer implements ElasticsearchAnalysisConfigurer {

    @Override
    public void configure(ElasticsearchAnalysisConfigurationContext context) {
        context.analyzer("name").custom() (2)
                .tokenizer("standard")
                .tokenFilters("asciifolding", "lowercase");

        context.analyzer("english").custom() (3)
                .tokenizer("standard")
                .tokenFilters("asciifolding", "lowercase", "porter_stem");

        context.normalizer("sort").custom() (4)
                .tokenFilters("asciifolding", "lowercase");
    }
}
1 Configurerの実装に @SearchExtension アノテーションを付けて、QuarkusにすべてのElasticsearchインデックスに(デフォルトで)デフォルトの永続化ユニットを使用するように指示します。

アノテーションは、特定の永続ユニット (@SearchExtension(persistenceUnit = "nameOfYourPU"))、 バックエンド (@SearchExtension(backend = "nameOfYourBackend"))、 インデックス (@SearchExtension(index = "nameOfYourIndex"))もターゲットにすることができます。

2 これは、スペースで単語を分離し、ASCII以外の文字をASCIIの対応する文字で置換し(したがって、アクセントを除去し)、すべてを小文字にするシンプルなアナライザーです。これは、例では著者名に使用されています。
3 これはもう少し積極的で、ステミングも含まれています。インデックス化された入力に mysteries が含まれていても、 mystery を検索して結果を得ることができます。人名に対しては確かに強引すぎますが、書籍のタイトルに対しては完璧です。
4 ここではソートに使われるノーマライザーを紹介します。最初のアナライザーと非常によく似ていますが、1つだけのトークンが欲しいので、単語をトークン化しないことを除けば同じです。

また、何らかの理由で @SearchExtension アノテーションを付けられない、あるいは付けたくない場合には、単純に @Dependent @Named("myAnalysisConfigurer") のアノテーションを付けて設定のプロパティから参照することも可能です:

quarkus.hibernate-search-orm.elasticsearch.analysis.configurer=bean:myAnalysisConfigurer

RESTサービスに全文検索機能を追加

既存の LibraryResource に、SearchSession をインジェクションするだけです:

    @Inject
    SearchSession searchSession; (1)
1 Hibernate Search セッションをインジェクションします。このセッションは内部で EntityManager に依存しています。複数の永続化ユニットを持つアプリケーションではCDI修飾子 @io.quarkus.hibernate.orm.PersistenceUnit を使用して正しいユニットを選択することができます: CDI統合 を参照してください。

そして、次のようなメソッドを追加します(いくつかの import もあります):

    @Transactional (1)
    void onStart(@Observes StartupEvent ev) throws InterruptedException { (2)
        // only reindex if we imported some content
        if (Book.count() > 0) {
            searchSession.massIndexer()
                    .startAndWait();
        }
    }

    @GET
    @Path("author/search") (3)
    @Transactional
    public List<Author> searchAuthors(@RestQuery String pattern, (4)
            @RestQuery Optional<Integer> size) {
        return searchSession.search(Author.class) (5)
                .where(f ->
                    pattern == null || pattern.trim().isEmpty() ?
                        f.matchAll() : (6)
                        f.simpleQueryString()
                                .fields("firstName", "lastName", "books.title").matching(pattern) (7)
                )
                .sort(f -> f.field("lastName_sort").then().field("firstName_sort")) (8)
                .fetchHits(size.orElse(20)); (9)
    }
1 重要なポイント:これらのメソッドには、トランザクションコンテキストが必要です。
2 SQLスクリプトを使用してPostgreSQLデータベースにデータをインポートするために起動時にデータのインデックスを再作成する必要があります。Hibernate Searchのマスインデクサーを使用して大量のデータを効率的にインデクシングすることができます(パフォーマンスを向上させるために微調整できます)。Hibernate ORMの操作によるその後のすべての更新は自動的に全文インデックスに同期されます。マスインデクサーを使用するのはインデクシング構成を変更したりして(新しいフィールドの追加、アナライザーの構成の変更など)、新しい構成を既存のエンティティに適用したい場合のみです。
3 エンティティにアノテーションを追加するだけで、全文検索が可能になり、Hibernate Search DSLを使ってインデックスにクエリーを投げることができるようになります。
4 パラメーター名の繰り返しを避けるために org.jboss.resteasy.annotations.jaxrs.QueryParam アノテーションを使用します。
5 Author を検索していることを示しています。
6 述語を作成します。パターンが空の場合は matchAll() 述語を使用します。
7 有効なパターンがあれば、パターンにマッチする firstNamelastNamebooks.title フィールドに対する simpleQueryString() 述語を作成します。
8 結果のソート順を定義します。ここでは、姓でソートし、次に名でソートしています。ソートには作成した特定のフィールドを使用していることに注意してください。
9 size で指定した数の一致度が高いものをフェッチします。デフォルトでは 20 です。もちろんページングもサポートしています。

Hibernate Search DSLはElasticsearchの述語(match、range、nested、phrase、spatial…​)の重要なサブセットをサポートしています。オートコンプリートを使ってDSLをご自由にお試しください。

それだけでは不十分な場合は、 JSONを直接使う述語を定義 することもできます。

アプリケーションの設定

いつものように、Quarkusの設定ファイル( application.properties )ですべての設定を行うことができます。

以下の内容の src/main/resources/import.sql ファイルを作成してみましょう:

quarkus.ssl.native=false (1)

quarkus.datasource.db-kind=postgresql (2)

quarkus.hibernate-orm.sql-load-script=import.sql (3)

quarkus.hibernate-search-orm.elasticsearch.version=7 (4)
quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=sync (5)

%prod.quarkus.datasource.jdbc.url=jdbc:postgresql://localhost/quarkus_test (6)
%prod.quarkus.datasource.username=quarkus_test
%prod.quarkus.datasource.password=quarkus_test
%prod.quarkus.hibernate-orm.database.generation=create
%prod.hibernate-search-orm.elasticsearch.hosts=localhost:9200 (6)
1 SSLは使用しないので、ネイティブ実行可能ファイルをよりコンパクトにするために無効にしています。
2 それでは、PostgreSQLのデータソースを作成してみましょう。
3 いくつかの初期データを読み込みます。
4 使用するElasticsearchのバージョンをHibernate Searchに伝える必要があります。Elasticsearchのバージョンによってマッピング構文に大きな違いがあるので重要です。マッピングは起動時間を短縮するためにビルド時に作成されるので、Hibernate Searchはクラスタに接続してバージョンを自動的に検出することができません。なお、OpenSearchの場合は、バージョンの前に opensearch: を付ける必要があります; OpenSearch対応を参照してください。
5 これは、エンティティが検索可能になるのを待ってから書き込みが完了したとみなすことを意味します。本番環境では、デフォルトの write-sync の方がパフォーマンスが高くなります。テスト時にはエンティティがすぐに検索可能になる必要があるため sync を使用することが特に重要です。
6 開発およびテストでは、 Dev Services に依存します。これは、QuarkusがPostgreSQLデータベースとElasticsearchクラスタを自動的に開始することを意味します。 しかし、本番モードでは、PostgreSQLデータベースとElasticsearchクラスターを手動で起動したいと思うでしょう。そのため、この接続情報を prod プロファイル( %prod. プレフィックス)でQuarkusに提供します。

Dev Services 依存しているため、データベースとElasticsearchスキーマはテストと開発モードのアプリケーションの起動ごとに自動的に削除され、再作成されます( quarkus.hibernate-search-orm.schema-management.strategy が明示的に設定されていなければ、このようなことはありません)。

何らかの理由でDev Servicesを利用できない場合は以下のプロパティを設定することで、同様の動作をさせることができます:

%dev.quarkus.hibernate-orm.database.generation=drop-and-create
%test.quarkus.hibernate-orm.database.generation=drop-and-create
%dev.quarkus.hibernate-search-orm.schema-management.strategy=drop-and-create
%test.quarkus.hibernate-search-orm.schema-management.strategy=drop-and-create
Hibernate Searchエクステンションの設定については、 設定リファレンス を参照してください。

開発サービス(コンフィグレーション・フリー・データベース)

Quarkusは、Dev Servicesという機能をサポートしており、設定なしでさまざまなコンテナを起動することができます。Elasticsearchの場合はこのサポートはデフォルトのElasticsearch接続にも及んでいます。つまり、 quarkus.hibernate-search-orm.elasticsearch.hosts を設定していない場合、テスト実行時や 開発モード 時にQuarkusは自動的にElasticsearchコンテナを起動し、接続を自動的に設定します。

アプリケーションの本番環境版を実行する場合、Elasticsearch接続は通常通り設定する必要があります。したがって、 application.properties に本番環境版のデータベース設定を含め、Dev Servicesを引き続き使用したい場合は、 %prod. プロファイルを使用してElasticsearch設定を定義することをお勧めします。

Dev Services for Elasticsearchは現時点では複数のクラスタを同時に起動することができず、デフォルトの永続化ユニットのデフォルトのバックエンドでのみ動作します:名前付き永続化ユニットや名前付きバックエンドはDev Services for Elasticsearchを利用することができません。

詳細については、 Dev Services for Elasticsearch ガイド をご覧ください。

フロントエンドの作成

それでは、 LibraryResource を操作するための簡単なWebページを追加してみましょう。Quarkusは、 META-INF/resources ディレクトリの下にある静的リソースを自動的に提供します。 src/main/resources/META-INF/resources ディレクトリで、既存の index.html ファイルを、この index.html ファイルの内容で上書きしてください。

自動インポートスクリプト

このデモの目的のために、初期データセットをインポートしてみましょう。

以下の内容の src/main/resources/import.sql ファイルを作成してみましょう:

INSERT INTO author(id, firstname, lastname) VALUES (nextval('hibernate_sequence'), 'John', 'Irving');
INSERT INTO author(id, firstname, lastname) VALUES (nextval('hibernate_sequence'), 'Paul', 'Auster');

INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The World According to Garp', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Hotel New Hampshire', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Cider House Rules', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'A Prayer for Owen Meany', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Last Night in Twisted River', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'In One Person', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Avenue of Mysteries', 1);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The New York Trilogy', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Mr. Vertigo', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'The Brooklyn Follies', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Invisible', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), 'Sunset Park', 2);
INSERT INTO book(id, title, author_id) VALUES (nextval('hibernate_sequence'), '4 3 2 1', 2);

アプリケーションで遊ぶ時間

これで、REST サービスと対話できるようになりました:

  • 次のようにQuarkusアプリケーションを起動します:

    コマンドラインインタフェース
    quarkus dev
    Maven
    ./mvnw quarkus:dev
    Gradle
    ./gradlew --console=plain quarkusDev
  • ブラウザで http://localhost:8080/ を開きます

  • 著者や書名の検索してください(いくつかのデータを入れておきました)

  • 新しい著者や書籍を作成し、それらを検索することもできます

ご覧のように、すべての更新が自動的にElasticsearchクラスタに同期されます。

OpenSearch対応

Hibernate Searchは ElasticsearchOpenSearchの両方に対応していますが、デフォルトではElasticsearchクラスタとの連携を前提としています。

Hibernate Search を OpenSearch クラスタで動作させるには次のように 指定したバージョン番号の前に opensearch: を付けます。

quarkus.hibernate-search-orm.elasticsearch.version=opensearch:1.2

その他の設定オプションやAPIはElasticsearchの場合と全く同じです。

互換性のあるディストリビューションやElasticsearchのバージョンについては、 Hibernate Searchのリファレンスドキュメントのこのセクション に詳細情報が記載されています。

複数の永続化ユニット

複数の永続化ユニットを設定

Hibernate ORM エクステンションでは、 複数の永続化ユニットを設定することができ、それぞれが独自のデータソースと設定を持つことができます。

複数の永続化ユニットを宣言する場合は、それぞれの永続化ユニットに対して個別にHibernate Searchを設定することになります。

quarkus.hibernate-search-orm. 名前空間のルートにあるプロパティは、デフォルトの永続化ユニットを定義します。たとえば、次のスニペットでは、デフォルトのデータソースとデフォルトの永続化ユニットを定義し、その永続化ユニットのElasticsearchホストを es1.mycompany.com:9200 に設定しています。

quarkus.datasource.db-kind=h2
quarkus.datasource.jdbc.url=jdbc:h2:mem:default;DB_CLOSE_DELAY=-1

quarkus.hibernate-search-orm.elasticsearch.hosts=es1.mycompany.com:9200
quarkus.hibernate-search-orm.elasticsearch.version=7

マップベースのアプローチで名前付きの永続化ユニットを構成することも可能です:

quarkus.datasource."users".db-kind=h2 (1)
quarkus.datasource."users".jdbc.url=jdbc:h2:mem:users;DB_CLOSE_DELAY=-1

quarkus.datasource."inventory".db-kind=h2 (2)
quarkus.datasource."inventory".jdbc.url=jdbc:h2:mem:inventory;DB_CLOSE_DELAY=-1

quarkus.hibernate-orm."users".datasource=users (3)
quarkus.hibernate-orm."users".packages=org.acme.model.user

quarkus.hibernate-orm."inventory".datasource=inventory (4)
quarkus.hibernate-orm."inventory".packages=org.acme.model.inventory

quarkus.hibernate-search-orm."users".elasticsearch.hosts=es1.mycompany.com:9200 (5)
quarkus.hibernate-search-orm."users".elasticsearch.version=7

quarkus.hibernate-search-orm."inventory".elasticsearch.hosts=es2.mycompany.com:9200 (6)
quarkus.hibernate-search-orm."inventory".elasticsearch.version=7
1 users という名前のデータソースを定義します。
2 inventory という名前のデータソースを定義します。
3 users データソースを指す users という名前の永続化ユニットを定義します。
4 inventory データソースを指す inventory という名前の永続化ユニットを定義します。
5 users 永続化ユニットにHibernate Searchを設定し、その永続化ユニットのElasticsearchホストを es1.mycompany.com:9200 に設定します。
6 inventory 永続化ユニットにHibernate Searchを設定し、その永続化ユニットのElasticsearchホストを es2.mycompany.com:9200 に設定します。

モデルクラスの永続化ユニットへのアタッチメント

各永続化ユニットについて、Hibernate Searchは、その永続化ユニットにアタッチされているインデックス付きエンティティのみを考慮します。エンティティは、 Hibernate ORMエクステンションを設定することで、永続化ユニットにアタッチされます。

CDI統合

CDI を使用して、Hibernate Search のメインエントリーポイント SearchSessionSearchMapping をインジェクションすることができます:

@Inject
SearchSession searchSession;

これは、デフォルトの永続化ユニットの SearchSession をインジェクションします。

名前付き永続化ユニット(この例では users )の SearchSession をインジェクションするには、修飾子を追加するだけです:

@Inject
@PersistenceUnit("users") (1)
SearchSession searchSession;
1 これは @io.quarkus.hibernate.orm.PersistenceUnit アノテーションです。

全く同じメカニズムを使って、名前付き永続化ユニットの SearchMapping をインジェクションすることができます:

@Inject
@PersistenceUnit("users")
SearchMapping searchMapping;

ネイティブ実行可能ファイルの構築

通常のコマンド ./mvnw package -Pnative でネイティブ実行可能ファイルをビルドすることができます。

ネイティブ実行可能ファイルのコンパイルと同様に、この操作は大量のメモリーを消費します。

ネイティブ実行可能ファイルをビルドしている間は2つのコンテナーを停止して、ビルドが終わったら再度起動した方が安全かもしれません。

実行は ./target/hibernate-search-orm-elasticsearch-quickstart-1.0-SNAPSHOT-runner を実行するだけで簡単です。

その後、ブラウザで http://localhost:8080/ を開きアプリケーションを使用します。

起動がいつもより少し遅いのは、起動時に毎回データベーススキーマとElasticsearchマッピングを削除して再作成しているのが原因です。また、いくつかのデータを登録し、マスインデクサーを実行しています。

実際のアプリケーションでは、明らかに起動時に実行しないことです。

オフライン起動

デフォルトではHibernate Search は起動時に Elasticsearch クラスタにいくつかのリクエストを送信します。Hibernate Searchの起動時にElasticsearchクラスタが稼働していない場合は起動失敗の原因となります。

これに対処するためには起動時にリクエストを送信しないようにHibernate Searchを設定します:

もちろん、この構成でも、Elasticsearchクラスタにアクセスできるようになるまでは、Hibernate Searchはインデックスを作成したり、検索クエリを実行したりすることはできません。

quarkus.hibernate-search-orm.schema-management.strategynone に設定してスキーマの自動作成を無効にした場合、アプリケーションがエンティティの永続化/更新や検索リクエストの実行を開始する前に、手動でスキーマを作成する必要があります。

詳細については、 Hibernate Searchのリファレンスドキュメントのこのセクション を参照してください。

アウトボックスポーリングによる調整

アウトボックスポーリングによる調整は、プレビューとみなされます。

プレビュー版 では、後方互換性やエコシステムでの存在は保証されていません。具体的な改善のためには、設定やAPI、あるいはストレージのフォーマットを変更する必要があるかもしれませんが、 安定化 に向けた計画は進行中です。ご意見・ご感想は、 メーリングリストGitHubのイシュートラッカーでお寄せください。

Hibernate SearchやElasticsearchを分散型アプリケーションで使用することは技術的には可能ですが、デフォルトでは いくつかの制限があります。

これらはHibernate Searchがデフォルトではスレッドやアプリケーションノード間の調整を行わないことによる制限です。

このような制限をなくすために、 outbox-polling 調整ストラテジーを使用することができます。このストラテジーではデータベースに outbox テーブルを作成してエンティティ変更イベントをプッシュし、バックグラウンドでイベントを処理し、自動インデックス作成を行います。

outbox-polling 調整ストラテジーを有効にするには、追加のエクステンションが必要です:

コマンドラインインタフェース
quarkus extension add 'hibernate-search-orm-coordination-outbox-polling'
Maven
./mvnw quarkus:add-extension -Dextensions='hibernate-search-orm-coordination-outbox-polling'
Gradle
./gradlew addExtension --extensions='hibernate-search-orm-coordination-outbox-polling'

エクステンションをインストールしたら、 quarkus.hibernate-search-orm.coordination.strategyoutbox-polling に設定し、明示的に outbox-polling ストラテジーを選択する必要があります。

最後に、Hibernate Searchによって追加されたHibernate ORMエンティティ(アウトボックスとエージェントを表す)が、データベース内に対応するテーブル/シーケンスを持っていることを確認する必要があります:

上記の作業が完了したら、アウトボックスを使ったHibernate Searchを使用する準備が整いました。コードを変更せず、アプリケーションを起動するだけで大丈夫です。複数のアプリケーションが同じデータベースに接続されていることを自動的に検出し、それに応じてインデックスの更新が調整されます。

Hibernate Searchは、 outbox-polling 調整ストラテジーを使用してもしなくても、ほとんど同じ動作をします。アプリケーションコード(エンティティの永続化、検索など)を変更する必要はありません。

しかし重要な違いが1つあります。インデックスの更新は必然的に非同期で行われ、 いつかは 行われることが保証されますが、すぐには行われません。

これは特に outbox-polling 調整ストラテジーを使用している場合に構成プロパティ quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy を設定できないことを意味しています。Hibernate Searchは、このプロパティが常に write-sync (デフォルトの値)に設定されているかのように動作します。

この動作は、Elasticsearchの Near real-time searchと一致しており、連携が無効な場合でもHibernate Searchを使用する場合は推奨されています。

Hibernate Search の調整について詳しく知りたい方は、 リファレンスドキュメント を参照してください。

調整に関連する設定オプションの詳細については、 アウトボックスポーリングとの連携の設定 を参照してください。

AWSのリクエストの署名

Amazonが管理するElasticsearchサービスを使用する必要がある場合、リクエストの署名を含む独自の認証方法を必要になります。

Hibernate SearchでAWSリクエストの署名を有効にするには、専用のエクステンションをプロジェクトに追加して設定します。

参考資料

Hibernate Search 6について詳しく知りたい方は、Hibernateチームが 幅広いリファレンスドキュメント を公開しています。

FAQ

なぜElasticsearchだけなのか?

Hibernate SearchはLuceneバックエンドとElasticsearchバックエンドの両方をサポートしています。

Quarkusとマイクロサービスを構築するという文脈では、後者の方がより理にかなっていると考えました。そこで、私たちは後者に力を入れました。

今のところ、QuarkusでLuceneバックエンドをサポートする予定はありません。

Hibernate Search 設定リファレンス

主な構成

ビルド時に固定される設定プロパティ - その他の設定プロパティはランタイムでオーバーライド可能です。

Configuration property

デフォルト

Whether Hibernate Search is enabled during the build.

If Hibernate Search is disabled during the build, all processing related to Hibernate Search will be skipped, but it will not be possible to activate Hibernate Search at runtime: quarkus.hibernate-search-orm.active will default to false and setting it to true will lead to an error.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ENABLED

boolean

true

A bean reference to a component that should be notified of any failure occurring in a background process (mainly index operations).

The referenced bean must implement FailureHandler.

Instead of setting this configuration property, you can simply annotate your custom FailureHandler implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_BACKGROUND_FAILURE_HANDLER

string

The strategy to use for coordinating between threads or even separate instances of the application, in particular in automatic indexing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_STRATEGY

string

none

Whether Hibernate Search should be active for this persistence unit at runtime.

If Hibernate Search is not active, it won’t index Hibernate ORM entities, and accessing the SearchMapping/SearchSession of the relevant persistence unit for search or other operation will not be possible.

Note that if Hibernate Search is disabled (i.e. quarkus.hibernate-search-orm.enabled is set to false), it won’t be active for any persistence unit, and setting this property to true will fail.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ACTIVE

boolean

'true' if Hibernate Search is enabled; 'false' otherwise

The schema management strategy, controlling how indexes and their schema are created, updated, validated or dropped on startup and shutdown.

Available values:

Strategy

Definition

none

Do nothing: assume that indexes already exist and that their schema matches Hibernate Search’s expectations.

validate

Validate that indexes exist and that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, do nothing: assume that their schema matches Hibernate Search’s expectations.

create-or-validate (default unless using Dev Services)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create-or-update

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations; if it does not match expectations, try to update it.

This strategy is unfit for production environments, due to several important limitations, but can be useful when developing.

drop-and-create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

drop-and-create-and-drop (default when using Dev Services)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

Also, drop indexes and their schema on shutdown.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_SCHEMA_MANAGEMENT_STRATEGY

none, validate, create, create-or-validate, create-or-update, drop-and-create, drop-and-create-and-drop

create-or-validate

The strategy to use when loading entities during the execution of a search query.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_QUERY_LOADING_CACHE_LOOKUP_STRATEGY

skip, persistence-context, persistence-context-then-second-level-cache

skip

The fetch size to use when loading entities during the execution of a search query.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_QUERY_LOADING_FETCH_SIZE

int

100

The synchronization strategy to use when indexing automatically.

Defines how complete indexing should be before resuming the application thread after a database transaction is committed.

Indexing synchronization is only relevant when coordination is disabled (which is the default).

With the outbox-polling coordination strategy, indexing happens in background threads and is always asynchronous; the behavior is equivalent to the write-sync synchronization strategy.

Available values:

Strategy

Throughput

Guarantees when the application thread resumes

Changes applied

Changes safe from crash/power loss

Changes visible on search

async

Best

write-sync (default)

Medium

read-sync

Medium to worst

sync

Worst

This property also accepts a bean reference to a custom implementations of AutomaticIndexingSynchronizationStrategy.

Instead of setting this configuration property, you can simply annotate your custom AutomaticIndexingSynchronizationStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_AUTOMATIC_INDEXING_SYNCHRONIZATION_STRATEGY

string

write-sync

Whether to check if dirty properties are relevant to indexing before actually reindexing an entity.

When enabled, re-indexing of an entity is skipped if the only changes are on properties that are not used when indexing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_AUTOMATIC_INDEXING_ENABLE_DIRTY_CHECK

boolean

true

An exhaustive list of all tenant identifiers that may be used by the application when multi-tenancy is enabled.

Mainly useful when using the {@code outbox-polling} coordination strategy, since it involves setting up one background processor per tenant.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_MULTI_TENANCY_TENANT_IDS

list of string

Default backend

デフォルト

The version of Elasticsearch used in the cluster.

As the schema is generated without a connection to the server, this item is mandatory.

It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch).

There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_VERSION

ElasticsearchVersion

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

Instead of setting this configuration property, you can simply annotate your custom IndexLayoutStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_LAYOUT_STRATEGY

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_ANALYSIS_CONFIGURER

string

The list of hosts of the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_HOSTS

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_PROTOCOL

http, https

http

The username used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_USERNAME

string

The password used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_PASSWORD

string

The timeout when establishing a connection to an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_CONNECTION_TIMEOUT

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_READ_TIMEOUT

Duration

30S

The timeout when executing a request to an Elasticsearch server.

This includes the time needed to wait for a connection to be available, send the request and read the response.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_REQUEST_TIMEOUT

Duration

The maximum number of connections to all the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_MAX_CONNECTIONS

int

20

The maximum number of connections per Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_MAX_CONNECTIONS_PER_ROUTE

int

10

Defines if automatic discovery is enabled.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_DISCOVERY_ENABLED

boolean

false

Refresh interval of the node list.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_DISCOVERY_REFRESH_INTERVAL

Duration

10S

The size of the thread pool assigned to the backend.

Note that number is per backend, not per index. Adding more indexes will not add more threads.

As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads.

Defaults to the number of processor cores available to the JVM on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_THREAD_POOL_SIZE

int

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup.

Set to false if the Elasticsearch cluster may not be available on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_VERSION_CHECK_ENABLED

boolean

true

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXING_MAX_BULK_SIZE

int

100

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__ANALYSIS_CONFIGURER

string

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_MAX_BULK_SIZE

int

100

Named backends

デフォルト

The version of Elasticsearch used in the cluster.

As the schema is generated without a connection to the server, this item is mandatory.

It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch).

There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__VERSION

ElasticsearchVersion

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

Instead of setting this configuration property, you can simply annotate your custom IndexLayoutStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__LAYOUT_STRATEGY

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__ANALYSIS_CONFIGURER

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__ANALYSIS_CONFIGURER

string

The list of hosts of the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__HOSTS

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__PROTOCOL

http, https

http

The username used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__USERNAME

string

The password used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__PASSWORD

string

The timeout when establishing a connection to an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__CONNECTION_TIMEOUT

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__READ_TIMEOUT

Duration

30S

The timeout when executing a request to an Elasticsearch server.

This includes the time needed to wait for a connection to be available, send the request and read the response.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__REQUEST_TIMEOUT

Duration

The maximum number of connections to all the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__MAX_CONNECTIONS

int

20

The maximum number of connections per Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__MAX_CONNECTIONS_PER_ROUTE

int

10

Defines if automatic discovery is enabled.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__DISCOVERY_ENABLED

boolean

false

Refresh interval of the node list.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__DISCOVERY_REFRESH_INTERVAL

Duration

10S

The size of the thread pool assigned to the backend.

Note that number is per backend, not per index. Adding more indexes will not add more threads.

As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads.

Defaults to the number of processor cores available to the JVM on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__THREAD_POOL_SIZE

int

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup.

Set to false if the Elasticsearch cluster may not be available on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__VERSION_CHECK_ENABLED

boolean

true

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_MAX_BULK_SIZE

int

100

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_MAX_BULK_SIZE

int

100

Configuration for additional named persistence units

デフォルト

A bean reference to a component that should be notified of any failure occurring in a background process (mainly index operations).

The referenced bean must implement FailureHandler.

Instead of setting this configuration property, you can simply annotate your custom FailureHandler implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__BACKGROUND_FAILURE_HANDLER

string

The strategy to use for coordinating between threads or even separate instances of the application, in particular in automatic indexing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_STRATEGY

string

none

Whether Hibernate Search should be active for this persistence unit at runtime.

If Hibernate Search is not active, it won’t index Hibernate ORM entities, and accessing the SearchMapping/SearchSession of the relevant persistence unit for search or other operation will not be possible.

Note that if Hibernate Search is disabled (i.e. quarkus.hibernate-search-orm.enabled is set to false), it won’t be active for any persistence unit, and setting this property to true will fail.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ACTIVE

boolean

'true' if Hibernate Search is enabled; 'false' otherwise

The schema management strategy, controlling how indexes and their schema are created, updated, validated or dropped on startup and shutdown.

Available values:

Strategy

Definition

none

Do nothing: assume that indexes already exist and that their schema matches Hibernate Search’s expectations.

validate

Validate that indexes exist and that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, do nothing: assume that their schema matches Hibernate Search’s expectations.

create-or-validate (default unless using Dev Services)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations.

If it does not, throw an exception, but make no attempt to fix the problem.

create-or-update

For indexes that do not exist, create them along with their schema.

For indexes that already exist, validate that their schema matches Hibernate Search’s expectations; if it does not match expectations, try to update it.

This strategy is unfit for production environments, due to several important limitations, but can be useful when developing.

drop-and-create

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

drop-and-create-and-drop (default when using Dev Services)

For indexes that do not exist, create them along with their schema.

For indexes that already exist, drop them, then create them along with their schema.

Also, drop indexes and their schema on shutdown.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__SCHEMA_MANAGEMENT_STRATEGY

none, validate, create, create-or-validate, create-or-update, drop-and-create, drop-and-create-and-drop

create-or-validate

The strategy to use when loading entities during the execution of a search query.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__QUERY_LOADING_CACHE_LOOKUP_STRATEGY

skip, persistence-context, persistence-context-then-second-level-cache

skip

The fetch size to use when loading entities during the execution of a search query.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__QUERY_LOADING_FETCH_SIZE

int

100

The synchronization strategy to use when indexing automatically.

Defines how complete indexing should be before resuming the application thread after a database transaction is committed.

Indexing synchronization is only relevant when coordination is disabled (which is the default).

With the outbox-polling coordination strategy, indexing happens in background threads and is always asynchronous; the behavior is equivalent to the write-sync synchronization strategy.

Available values:

Strategy

Throughput

Guarantees when the application thread resumes

Changes applied

Changes safe from crash/power loss

Changes visible on search

async

Best

write-sync (default)

Medium

read-sync

Medium to worst

sync

Worst

This property also accepts a bean reference to a custom implementations of AutomaticIndexingSynchronizationStrategy.

Instead of setting this configuration property, you can simply annotate your custom AutomaticIndexingSynchronizationStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__AUTOMATIC_INDEXING_SYNCHRONIZATION_STRATEGY

string

write-sync

Whether to check if dirty properties are relevant to indexing before actually reindexing an entity.

When enabled, re-indexing of an entity is skipped if the only changes are on properties that are not used when indexing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__AUTOMATIC_INDEXING_ENABLE_DIRTY_CHECK

boolean

true

An exhaustive list of all tenant identifiers that may be used by the application when multi-tenancy is enabled.

Mainly useful when using the {@code outbox-polling} coordination strategy, since it involves setting up one background processor per tenant.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__MULTI_TENANCY_TENANT_IDS

list of string

Default backend

デフォルト

The version of Elasticsearch used in the cluster.

As the schema is generated without a connection to the server, this item is mandatory.

It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch).

There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_VERSION

ElasticsearchVersion

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

Instead of setting this configuration property, you can simply annotate your custom IndexLayoutStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_LAYOUT_STRATEGY

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_ANALYSIS_CONFIGURER

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__ANALYSIS_CONFIGURER

string

The list of hosts of the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_HOSTS

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_PROTOCOL

http, https

http

The username used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_USERNAME

string

The password used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_PASSWORD

string

The timeout when establishing a connection to an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_CONNECTION_TIMEOUT

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_READ_TIMEOUT

Duration

30S

The timeout when executing a request to an Elasticsearch server.

This includes the time needed to wait for a connection to be available, send the request and read the response.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_REQUEST_TIMEOUT

Duration

The maximum number of connections to all the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_MAX_CONNECTIONS

int

20

The maximum number of connections per Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_MAX_CONNECTIONS_PER_ROUTE

int

10

Defines if automatic discovery is enabled.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_DISCOVERY_ENABLED

boolean

false

Refresh interval of the node list.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_DISCOVERY_REFRESH_INTERVAL

Duration

10S

The size of the thread pool assigned to the backend.

Note that number is per backend, not per index. Adding more indexes will not add more threads.

As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads.

Defaults to the number of processor cores available to the JVM on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_THREAD_POOL_SIZE

int

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup.

Set to false if the Elasticsearch cluster may not be available on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_VERSION_CHECK_ENABLED

boolean

true

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXING_MAX_BULK_SIZE

int

100

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_INDEXES__INDEX_NAME__INDEXING_MAX_BULK_SIZE

int

100

Named backends

デフォルト

The version of Elasticsearch used in the cluster.

As the schema is generated without a connection to the server, this item is mandatory.

It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used to communicate with Elasticsearch).

There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__VERSION

ElasticsearchVersion

A bean reference to the component used to configure layout (e.g. index names, index aliases).

The referenced bean must implement IndexLayoutStrategy.

Available built-in implementations:

simple

The default, future-proof strategy: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex-000001, an alias for write operations named myindex-write, and an alias for read operations named myindex-read.

no-alias

A strategy without index aliases, mostly useful on legacy clusters: if the index name in Hibernate Search is myIndex, this strategy will create an index named myindex, and will not use any alias.

Instead of setting this configuration property, you can simply annotate your custom IndexLayoutStrategy implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__LAYOUT_STRATEGY

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__ANALYSIS_CONFIGURER

string

Path to a file in the classpath holding custom index settings to be included in the index definition when creating an Elasticsearch index.

The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions. When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined; it should not be relied upon.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_SETTINGS_FILE

string

Path to a file in the classpath holding a custom index mapping to be included in the index definition when creating an Elasticsearch index.

The file does not need to (and generally shouldn’t) contain the full mapping: Hibernate Search will automatically inject missing properties (index fields) in the given mapping.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_MAPPING_FILE

string

A bean reference to the component used to configure full text analysis (e.g. analyzers, normalizers).

The referenced bean must implement ElasticsearchAnalysisConfigurer.

See アナライザーのセットアップ for more information.

Instead of setting this configuration property, you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically. If this configuration property is set, it takes precedence over any @SearchExtension annotation.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__ANALYSIS_CONFIGURER

string

The list of hosts of the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__HOSTS

list of string

localhost:9200

The protocol to use when contacting Elasticsearch servers. Set to "https" to enable SSL/TLS.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__PROTOCOL

http, https

http

The username used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__USERNAME

string

The password used for authentication.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__PASSWORD

string

The timeout when establishing a connection to an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__CONNECTION_TIMEOUT

Duration

1S

The timeout when reading responses from an Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__READ_TIMEOUT

Duration

30S

The timeout when executing a request to an Elasticsearch server.

This includes the time needed to wait for a connection to be available, send the request and read the response.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__REQUEST_TIMEOUT

Duration

The maximum number of connections to all the Elasticsearch servers.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__MAX_CONNECTIONS

int

20

The maximum number of connections per Elasticsearch server.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__MAX_CONNECTIONS_PER_ROUTE

int

10

Defines if automatic discovery is enabled.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__DISCOVERY_ENABLED

boolean

false

Refresh interval of the node list.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__DISCOVERY_REFRESH_INTERVAL

Duration

10S

The size of the thread pool assigned to the backend.

Note that number is per backend, not per index. Adding more indexes will not add more threads.

As all operations happening in this thread-pool are non-blocking, raising its size above the number of processor cores available to the JVM will not bring noticeable performance benefit. The only reason to alter this setting would be to reduce the number of threads; for example, in an application with a single index with a single indexing queue, running on a machine with 64 processor cores, you might want to bring down the number of threads.

Defaults to the number of processor cores available to the JVM on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__THREAD_POOL_SIZE

int

Whether Hibernate Search should check the version of the Elasticsearch cluster on startup.

Set to false if the Elasticsearch cluster may not be available on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__VERSION_CHECK_ENABLED

boolean

true

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXING_MAX_BULK_SIZE

int

100

The minimal Elasticsearch cluster status required on startup.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS

green, yellow, red

yellow

How long we should wait for the status before failing the bootstrap.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__SCHEMA_MANAGEMENT_REQUIRED_STATUS_WAIT_TIMEOUT

Duration

10S

The number of indexing queues assigned to each index.

Higher values will lead to more connections being used in parallel, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_QUEUE_COUNT

int

10

The size of indexing queues.

Lower values may lead to lower memory usage, especially if there are many queues, but values that are too low will reduce the likeliness of reaching the max bulk size and increase the likeliness of application threads blocking because the queue is full, which may lead to lower indexing throughput.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_QUEUE_SIZE

int

1000

The maximum size of bulk requests created when processing indexing queues.

Higher values will lead to more documents being sent in each HTTP request sent to Elasticsearch, which may lead to higher indexing throughput, but incurs a risk of overloading Elasticsearch, i.e. of overflowing its HTTP request buffers and tripping circuit breakers, leading to Elasticsearch giving up on some request and resulting in indexing failures.

Note that raising this number above the queue size has no effect, as bulks cannot include more requests than are contained in the queue.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__ELASTICSEARCH_BACKENDS__BACKEND_NAME__INDEXES__INDEX_NAME__INDEXING_MAX_BULK_SIZE

int

100

期間フォーマットについて

期間のフォーマットは標準の java.time.Duration フォーマットを使用します。詳細は Duration#parse() javadoc を参照してください。

数値で始まる期間の値を指定することもできます。この場合、値が数値のみで構成されている場合、コンバーターは値を秒として扱います。そうでない場合は、 PT が暗黙的に値の前に付加され、標準の java.time.Duration 形式が得られます。

Bean参照について

設定プロパティーで文字列の値を使用してBeanを参照する場合、その文字列は解析されます。

最も一般的なフォーマットは以下の通りです:

  • bean: の後に @Named CDI Beanの名前が続きます。例えば bean:myBean .

  • class: の後にクラスの完全修飾名を付けて、CDI Beanの場合は CDI を通して、そうでない場合はパブリックで引数なしのコンストラクタを通してインスタンス化されます。例えば class:com.mycompany.MyClass .

  • ビルトイン実装を参照する任意の文字列。 async read-sync write-sync sync 利用可能な値は、各設定プロパティーのドキュメントで詳しく説明されています。 quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy .

他の形式も認められていますが、高度なユースケースでのみ有用です。詳細については、 Hibernate Searchのリファレンスドキュメントのこのセクション を参照してください。

アウトボックスポーリングとの連携の設定

これらの設定プロパティには、追加のエクステンションが必要です。 アウトボックスポーリングによる調整 を参照してください。

ビルド時に固定される設定プロパティ - その他の設定プロパティはランタイムでオーバーライド可能です。

Default config

デフォルト

Whether the event processor is enabled, i.e. whether events will be processed to perform automatic reindexing on this instance of the application.

This can be set to false to disable event processing on some application nodes, for example to dedicate some nodes to HTTP request processing and other nodes to event processing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_ENABLED

boolean

true

The total number of shards that will form a partition of the entity change events to process.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the assigned shards (see shards.assigned) is necessary.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_SHARDS_TOTAL_COUNT

int

Among shards that will form a partition of the entity change events, the shards that will be processed by this application instance.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the total shard count is necessary.

Shards are referred to by an index in the range [0, total_count - 1] (see shards.total-count). A given application node must be assigned at least one shard but may be assigned multiple shards by setting shards.assigned to a comma-separated list, e.g. 0,3.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_SHARDS_ASSIGNED

list of int

How long to wait for another query to the outbox events table after a query didn’t return any event.

Lower values will reduce the time it takes for a change to be reflected in the index, but will increase the stress on the database when there are no new events.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_POLLING_INTERVAL

Duration

0.100S

How long the event processor can poll for events before it must perform a "pulse", updating and checking registrations in the agents table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean less time wasted not processing events when a node joins or leaves the cluster, and reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but more stress on the database because of more frequent checks of the list of agents.

High values (closer to the expiration interval) mean more time wasted not processing events when a node joins or leaves the cluster, and increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but less stress on the database because of less frequent checks of the list of agents.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_PULSE_EXPIRATION

Duration

30S

How many outbox events, at most, are processed in a single transaction.

Higher values will reduce the number of transactions opened by the background process and may increase performance thanks to the first-level cache (persistence context), but will increase memory usage and in extreme cases may lead to OutOfMemoryErrors.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_BATCH_SIZE

int

50

The timeout for transactions processing outbox events.

When this property is not set, Hibernate Search will use whatever default transaction timeout is configured in the JTA transaction manager, which may be too low for batch processing and lead to transaction timeouts when processing batches of events. If this happens, set a higher transaction timeout for event processing using this property.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_TRANSACTION_TIMEOUT

Duration

How long the event processor must wait before re-processing an event after its previous processing failed.

Use the value 0S to reprocess failed events as soon as possible, with no delay.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_EVENT_PROCESSOR_RETRY_DELAY

Duration

30S

How long to wait for another query to the agent table when actively waiting for event processors to suspend themselves.

Low values will reduce the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will increase the stress on the database while the mass indexer agent is actively waiting.

High values will increase the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will reduce the stress on the database while the mass indexer agent is actively waiting.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_MASS_INDEXER_POLLING_INTERVAL

Duration

0.100S

How long the mass indexer can wait before it must perform a "pulse", updating and checking registrations in the agent table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but more stress on the database because of more frequent updates of the mass indexer agent’s entry in the agent table.

High values (closer to the expiration interval) mean increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but less stress on the database because of less frequent updates of the mass indexer agent’s entry in the agent table.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_MASS_INDEXER_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_MASS_INDEXER_PULSE_EXPIRATION

Duration

30S

Per-tenant config

デフォルト

Whether the event processor is enabled, i.e. whether events will be processed to perform automatic reindexing on this instance of the application.

This can be set to false to disable event processing on some application nodes, for example to dedicate some nodes to HTTP request processing and other nodes to event processing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_ENABLED

boolean

true

The total number of shards that will form a partition of the entity change events to process.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the assigned shards (see shards.assigned) is necessary.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_SHARDS_TOTAL_COUNT

int

Among shards that will form a partition of the entity change events, the shards that will be processed by this application instance.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the total shard count is necessary.

Shards are referred to by an index in the range [0, total_count - 1] (see shards.total-count). A given application node must be assigned at least one shard but may be assigned multiple shards by setting shards.assigned to a comma-separated list, e.g. 0,3.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_SHARDS_ASSIGNED

list of int

How long to wait for another query to the outbox events table after a query didn’t return any event.

Lower values will reduce the time it takes for a change to be reflected in the index, but will increase the stress on the database when there are no new events.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_POLLING_INTERVAL

Duration

0.100S

How long the event processor can poll for events before it must perform a "pulse", updating and checking registrations in the agents table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean less time wasted not processing events when a node joins or leaves the cluster, and reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but more stress on the database because of more frequent checks of the list of agents.

High values (closer to the expiration interval) mean more time wasted not processing events when a node joins or leaves the cluster, and increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but less stress on the database because of less frequent checks of the list of agents.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_PULSE_EXPIRATION

Duration

30S

How many outbox events, at most, are processed in a single transaction.

Higher values will reduce the number of transactions opened by the background process and may increase performance thanks to the first-level cache (persistence context), but will increase memory usage and in extreme cases may lead to OutOfMemoryErrors.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_BATCH_SIZE

int

50

The timeout for transactions processing outbox events.

When this property is not set, Hibernate Search will use whatever default transaction timeout is configured in the JTA transaction manager, which may be too low for batch processing and lead to transaction timeouts when processing batches of events. If this happens, set a higher transaction timeout for event processing using this property.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_TRANSACTION_TIMEOUT

Duration

How long the event processor must wait before re-processing an event after its previous processing failed.

Use the value 0S to reprocess failed events as soon as possible, with no delay.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_RETRY_DELAY

Duration

30S

How long to wait for another query to the agent table when actively waiting for event processors to suspend themselves.

Low values will reduce the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will increase the stress on the database while the mass indexer agent is actively waiting.

High values will increase the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will reduce the stress on the database while the mass indexer agent is actively waiting.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_POLLING_INTERVAL

Duration

0.100S

How long the mass indexer can wait before it must perform a "pulse", updating and checking registrations in the agent table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but more stress on the database because of more frequent updates of the mass indexer agent’s entry in the agent table.

High values (closer to the expiration interval) mean increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but less stress on the database because of less frequent updates of the mass indexer agent’s entry in the agent table.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM_COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_PULSE_EXPIRATION

Duration

30S

Configuration for additional named persistence units

デフォルト

Default config

デフォルト

Whether the event processor is enabled, i.e. whether events will be processed to perform automatic reindexing on this instance of the application.

This can be set to false to disable event processing on some application nodes, for example to dedicate some nodes to HTTP request processing and other nodes to event processing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_ENABLED

boolean

true

The total number of shards that will form a partition of the entity change events to process.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the assigned shards (see shards.assigned) is necessary.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_SHARDS_TOTAL_COUNT

int

Among shards that will form a partition of the entity change events, the shards that will be processed by this application instance.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the total shard count is necessary.

Shards are referred to by an index in the range [0, total_count - 1] (see shards.total-count). A given application node must be assigned at least one shard but may be assigned multiple shards by setting shards.assigned to a comma-separated list, e.g. 0,3.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_SHARDS_ASSIGNED

list of int

How long to wait for another query to the outbox events table after a query didn’t return any event.

Lower values will reduce the time it takes for a change to be reflected in the index, but will increase the stress on the database when there are no new events.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_POLLING_INTERVAL

Duration

0.100S

How long the event processor can poll for events before it must perform a "pulse", updating and checking registrations in the agents table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean less time wasted not processing events when a node joins or leaves the cluster, and reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but more stress on the database because of more frequent checks of the list of agents.

High values (closer to the expiration interval) mean more time wasted not processing events when a node joins or leaves the cluster, and increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but less stress on the database because of less frequent checks of the list of agents.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_PULSE_EXPIRATION

Duration

30S

How many outbox events, at most, are processed in a single transaction.

Higher values will reduce the number of transactions opened by the background process and may increase performance thanks to the first-level cache (persistence context), but will increase memory usage and in extreme cases may lead to OutOfMemoryErrors.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_BATCH_SIZE

int

50

The timeout for transactions processing outbox events.

When this property is not set, Hibernate Search will use whatever default transaction timeout is configured in the JTA transaction manager, which may be too low for batch processing and lead to transaction timeouts when processing batches of events. If this happens, set a higher transaction timeout for event processing using this property.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_TRANSACTION_TIMEOUT

Duration

How long the event processor must wait before re-processing an event after its previous processing failed.

Use the value 0S to reprocess failed events as soon as possible, with no delay.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_EVENT_PROCESSOR_RETRY_DELAY

Duration

30S

How long to wait for another query to the agent table when actively waiting for event processors to suspend themselves.

Low values will reduce the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will increase the stress on the database while the mass indexer agent is actively waiting.

High values will increase the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will reduce the stress on the database while the mass indexer agent is actively waiting.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_MASS_INDEXER_POLLING_INTERVAL

Duration

0.100S

How long the mass indexer can wait before it must perform a "pulse", updating and checking registrations in the agent table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but more stress on the database because of more frequent updates of the mass indexer agent’s entry in the agent table.

High values (closer to the expiration interval) mean increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but less stress on the database because of less frequent updates of the mass indexer agent’s entry in the agent table.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_MASS_INDEXER_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_MASS_INDEXER_PULSE_EXPIRATION

Duration

30S

Per-tenant config

デフォルト

Whether the event processor is enabled, i.e. whether events will be processed to perform automatic reindexing on this instance of the application.

This can be set to false to disable event processing on some application nodes, for example to dedicate some nodes to HTTP request processing and other nodes to event processing.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_ENABLED

boolean

true

The total number of shards that will form a partition of the entity change events to process.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the assigned shards (see shards.assigned) is necessary.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_SHARDS_TOTAL_COUNT

int

Among shards that will form a partition of the entity change events, the shards that will be processed by this application instance.

By default, sharding is dynamic and setting this property is not necessary.

If you want to control explicitly the number and assignment of shards, you must configure static sharding and then setting this property as well as the total shard count is necessary.

Shards are referred to by an index in the range [0, total_count - 1] (see shards.total-count). A given application node must be assigned at least one shard but may be assigned multiple shards by setting shards.assigned to a comma-separated list, e.g. 0,3.

See this section of the reference documentation for more information about event processor sharding.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_SHARDS_ASSIGNED

list of int

How long to wait for another query to the outbox events table after a query didn’t return any event.

Lower values will reduce the time it takes for a change to be reflected in the index, but will increase the stress on the database when there are no new events.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_POLLING_INTERVAL

Duration

0.100S

How long the event processor can poll for events before it must perform a "pulse", updating and checking registrations in the agents table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean less time wasted not processing events when a node joins or leaves the cluster, and reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but more stress on the database because of more frequent checks of the list of agents.

High values (closer to the expiration interval) mean more time wasted not processing events when a node joins or leaves the cluster, and increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected, but less stress on the database because of less frequent checks of the list of agents.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but increased risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted not processing events when a node abruptly leaves the cluster due to a crash or network failure, but reduced risk of wasting time not processing events because an event processor is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_PULSE_EXPIRATION

Duration

30S

How many outbox events, at most, are processed in a single transaction.

Higher values will reduce the number of transactions opened by the background process and may increase performance thanks to the first-level cache (persistence context), but will increase memory usage and in extreme cases may lead to OutOfMemoryErrors.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_BATCH_SIZE

int

50

The timeout for transactions processing outbox events.

When this property is not set, Hibernate Search will use whatever default transaction timeout is configured in the JTA transaction manager, which may be too low for batch processing and lead to transaction timeouts when processing batches of events. If this happens, set a higher transaction timeout for event processing using this property.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_TRANSACTION_TIMEOUT

Duration

How long the event processor must wait before re-processing an event after its previous processing failed.

Use the value 0S to reprocess failed events as soon as possible, with no delay.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__EVENT_PROCESSOR_RETRY_DELAY

Duration

30S

How long to wait for another query to the agent table when actively waiting for event processors to suspend themselves.

Low values will reduce the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will increase the stress on the database while the mass indexer agent is actively waiting.

High values will increase the time it takes for the mass indexer agent to detect that event processors finally suspended themselves, but will reduce the stress on the database while the mass indexer agent is actively waiting.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_POLLING_INTERVAL

Duration

0.100S

How long the mass indexer can wait before it must perform a "pulse", updating and checking registrations in the agent table.

The pulse interval must be set to a value between the polling interval and one third (1/3) of the expiration interval.

Low values (closer to the polling interval) mean reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but more stress on the database because of more frequent updates of the mass indexer agent’s entry in the agent table.

High values (closer to the expiration interval) mean increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected, but less stress on the database because of less frequent updates of the mass indexer agent’s entry in the agent table.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_PULSE_INTERVAL

Duration

2S

How long an event processor "pulse" remains valid before considering the processor disconnected and forcibly removing it from the cluster.

The expiration interval must be set to a value at least 3 times larger than the pulse interval.

Low values (closer to the pulse interval) mean less time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but increased risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

High values (much larger than the pulse interval) mean more time wasted with event processors not processing events when a mass indexer agent terminates due to a crash, but reduced risk of event processors starting to process events again during mass indexing because a mass indexer agent is incorrectly considered disconnected.

Environment variable: QUARKUS_HIBERNATE_SEARCH_ORM__PERSISTENCE_UNIT_NAME__COORDINATION_TENANTS__TENANT_ID__MASS_INDEXER_PULSE_EXPIRATION

Duration

30S

期間フォーマットについて

期間のフォーマットは標準の java.time.Duration フォーマットを使用します。詳細は Duration#parse() javadoc を参照してください。

数値で始まる期間の値を指定することもできます。この場合、値が数値のみで構成されている場合、コンバーターは値を秒として扱います。そうでない場合は、 PT が暗黙的に値の前に付加され、標準の java.time.Duration 形式が得られます。