Red Hat Training
A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform
23.2.5. Configuration d'un worker
Il est possible de préciser comment Hibernate Search interagit avec Lucene par la configuration de worker. Il existe plusieurs composants architecturaux et points d'extension possibles. Voyons cela de plus près.
Il y a tout d'abord un
Worker. Une implémentation de l'interface Worker est responsable de recevoir tous les changements d'entité, de les mettre en file d'attente selon le contexte et de les appliquer une fois que le contexte prend fin. Le contexte le plus intuitif, en connexion à ORM, est la transaction. Pour cette raison, Hibernate Search utilisera par défaut le TransactionalWorker pour scoper tous les changements par transaction. On peut, cependant, imaginer un scénario où le contexte dépend, par exemple, du nombre de changements d'entités ou d'autres événements d'applications (cycle de vie). Pour cette raison, l'implémentation Worker est configurable, comme on peut le voir dans Tableau 23.1, « Configuration de l'étendue ».
Tableau 23.1. Configuration de l'étendue
| Property | Description |
| hibernate.search.worker.scope | Le nom de classe complet de l'implémentation de Worker à utiliser. Si cette propriété n'est pas définie, est vide ou transaction, le TransactionalWorker par défaut sera utilisé. |
| hibernate.search.worker.* | Toutes les propriétés de configuration ayant comme préfixe hibernate.search.worker sont passées au worker pendant l'initialisation. Cela permet d'ajouter des paramètres spécifiques au worker et personnalisés. |
| hibernate.search.worker.batch_size | Définit le nombre maximal d'opérations d'indexation par lots de contexte. Une fois la limite atteinte, l'indexation se déclenchera même si le contexte n'est pas encore terminé. Cette propriété ne fonctionne que si l'implémentation du worker délègue le travail en file d'attente à BatchedQueueingProcessor (ce que fait le TransactionalWorker) |
Une fois qu'un contexte se termine, il est temps de préparer et d'appliquer les modifications d'index. Cela peut être fait, de façon synchrone ou asynchrone, à partir d'un nouveau thread. Les mises à jour synchrones ont l'avantage que l'index est en synchronisation avec les bases de données en permanence . Les mises à jour asynchrones, en revanche, peuvent aider à minimiser le temps de réponse utilisateur. L'inconvénient est qu'il puisse y avoir des divergences entre les états d'indexes et de bases de données. Étudions les options de configuration indiquées dans Tableau 23.2, « Configuration d'exécution ».
Note
Les options suivantes peuvent être différentes pour chaque index; en fait, elles ont besoin du préfixe indexName, ou bien, utiliser
default pour définir la valeur par défaut pour tous les indexes.
Tableau 23.2. Configuration d'exécution
| Property | Description |
| hibernate.search.<indexName>.worker.execution | sync: exécution synchronisée (valeur par défaut)
async: exécution asynchronisée
|
| hibernate.search.<indexName>.worker.thread_pool.size | Le backend peut appliquer des mises à jour depuis le même contexte de transaction (ou lot) en parallèle, à l'aide d'un pool de threads. La valeur par défaut est 1. Vous pouvez expérimenter avec des valeurs plus grandes si vous avez beaucoup d'opérations par transaction. |
| hibernate.search.<indexName>.worker.buffer_queue.max | Définit le nombre maximal de files d'attente de travail si le pool de threads n'est pas alimenté. Utile uniquement pour une exécution asynchrone. Par défaut à l'infini. Si la limite est atteinte, le travail sera effectué par le thread principal. |
Jusqu'à présent, tout le travail est fait dans la même Machine virtuelle (VM), quel que soit le mode d'exécution. Le montant total de travail ne change pas pour la machine virtuelle. Heureusement, il y a une meilleure approche: la délégation. Il est possible d'envoyer le travail d'indexation sur un autre serveur en configurant hibernate.search.default.worker.backend - voir Tableau 23.3, « Configuration Backend ». Encore une fois, cette option peut être configurée différemment pour chaque index.
Tableau 23.3. Configuration Backend
| Property | Description |
| hibernate.search.<indexName>.worker.backend | lucene: le backend par défaut qui exécute les mises à jour des indexes dans une même VM. Utilisé également quand la propriété est indéfinie ou vide.
jms: JMS backend. Les mises à jour d'indexes sont envoyées dans une file d'attente JMS afin d'être traitées par un master d'indexation. Voir Tableau 23.4, « Configuration de JMS Backend » pour obtenir des options de configuration supplémentaires et Section 23.2.5.1, « JMS Master/Esclave Backend » pour obtenir une description plus détaillée pour cette installation.
blackhole: une configuration test/developer qui ignore tout le travail d'indexation
Vous pouvez également spécifier le nom complet d'une classe qui implémente
BackendQueueProcessor. De cette façon, vous pouvez implémenter votre propre couche de communication. L'implémentation est chargée de retourner une instance Runnable (exécutable) qui, sur l'exécution, traitera le travail de l'index.
|
Tableau 23.4. Configuration de JMS Backend
| Property | Description |
|---|---|
| hibernate.search.<indexName>.worker.jndi.* | Définit les propriétés JNDI pour initier InitialContext (si besoin est). JNDI n'est utilisé que par JMS Backend. |
| hibernate.search.<indexName>.worker.jms.connection_factory | Obligatoire avec JMS Backend. Définit le nom JNDI pour rechercher la fabrique de connexions JMS (/ ConnectionFactory par défaut dans Red Hat JBoss Enterprise Application Platform) |
| hibernate.search.<indexName>.worker.jms.queue | Obligatoire avec JMS Backend. Définit le nom JNDI pour rechercher la file d'attente JMS. La file d'attente sera utilisée pour poster les messages travail. |
Avertissement
Comme vous l'avez sans doute remarqué, certaines des propriétés indiquées sont corrélées, ce qui signifie que toutes les combinaisons de valeurs de propriété ne sont pas forcément logiques. En fait, vous pouvez vous retrouver avec une configuration non fonctionnelle. Cela est particulièrement vrai dans le cas où vous fournissiez vos propres implémentations de certains des interfaces illustrées. Assurez-vous d'étudier le code existant avant d'écrire votre propre implémentation de
Worker ou de BackendQueueProcessor.
23.2.5.1. JMS Master/Esclave Backend
Cette section décrit comment configurer l'architecture d'Hibernate Search Master/Esclave.
Figure 23.3. Configuration de JMS Backend