Utilizamos hibernate-search para la indexación de texto completo de nuestras entidades en wildfly 8.2 (usando las bibliotecas hibernate / hibernate-search e infinspan incluidas con wildfly 8.2). Ejecutando como nodo independiente o en un dominio con un maestro de búsqueda de hibernación dedicado y elorg.hibernate.search.store.impl.FSDirectoryProvider Esto ha estado funcionando bien durante varios años (y versiones jboss).

Ahora nos gustaría implementar este sistema en un entorno en clúster HA con wildfly 8.2 ejecutándose detrás de un proxy de equilibrio de carga. Queremos tener un clúster escalable dinámicamente sin un punto de falla en el sentido de un maestro de dominio o un maestro de búsqueda de hibernación y lo hemos configurado para esto con nodos independientes sin un dominio. Para elegir el maestro HS estamos usando el backend jgroups y para replicar los datos de búsqueda de hibernación estamos usando el proveedor infinispan con unfile-store para persistir datos entre reinicios.

Lo puse en marcha, bastante rápido y estaba bastante emocionado, ya que parece un escenario robusto y escalable, pero dudo un poco en poner esta configuración en producción, ya que el backend de jgroups se ha denominado "experimental" (y en algunos foros "extremadamente experimental"). ¿Cuál es el estado actual del backend? ¿Las personas lo usan actualmente en producción? ¿Qué podemos hacer para minimizar el riesgo con esta configuración?

Además, ¿alguien tiene experiencia con el uso de infinispan junto con hibernate-search en esta constelación? La mayoría de las configuraciones con respectoreplicated-cache simplemente se reutilizaron a partir de ejemplos existentes, si alguien tiene algunos consejos o sugerencias con respecto a esta configuración, por ejemplo, ¿se escalará con índices de ~ 50 GB? Estaría muy agradecido por cualquier comentario o experiencia con escenarios similares.

La configuración se realizó principalmente utilizando material de referencia de aquí:

http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/https://forum.hibernate.org/viewtopic.php?f=9&t=1035437

Los pasos detallados que hemos tomado se incluyen a continuación.

Como base, tomamos y ampliamos elstandalone-ha-full.xmlconfigurar jgroups para usar la pila TCPejecute TCPPING en lugar de MPing (estamos planeando que esto se ejecute en un contexto de nube donde la multidifusión / udp causa problemas; podemos pasar a JDBCPing para que sea más flexible en algún momento).corremos con las siguientes Propiedades del sistema por nodo (cambios de nombre / puerto por nodo, por supuesto)

Propiedades del sistema:

<system-properties>        
   <property name="jboss.node.name" value="node2" />  
   <property name="jboss.socket.binding.port-offset" value="889" />  
   <!-- Automatic master election via JGroups, requires Infinispan directory provider -->
   <property name="hibernate.search.default.worker.backend" value="jgroups"/>
   <!-- Enable cluster-replicated index, but the default configuration does not enable any 
   form of permanent persistence for the index, we do this with cache-container/file-store below  -->
   <property name="hibernate.search.default.directory_provider" value="infinispan" />
   <property name="hibernate.search.infinispan.chunk_size" value="300000000" />
   <property name="hibernate.search.reader.strategy" value="shared" />
   <property name="hibernate.search.worker.execution" value="sync" />
   <property name="hibernate.search.default.optimizer.operation_limit.max"    value="10000"/>
   <property name="hibernate.search.default.optimizer.transaction_limit.max"    value="1000"/>
   <!-- Use CacheManager defined in WildFly configuration file, e.g., standalone.xml -->
   <property name="hibernate.search.infinispan.cachemanager_jndiname" value="java:jboss/infinispan/container/hibernate-search"/>
</system-properties>     

Hemos definido lo siguiente<cache-container> para infinispan:

<!-- BEGIN HIBERNATE INFINISPAN CACHE -->
<cache-container name="hibernate-search" jndi-name="java:jboss/infinispan/container/hibernate-search" start="EAGER">
    <transport lock-timeout="330000"/>
    <replicated-cache name="LuceneIndexesMetadata" start="EAGER" mode="SYNC" remote-timeout="330000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
        <file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
            <write-behind/>
        </file-store>
        <indexing index="NONE"/>
    </replicated-cache>
    <replicated-cache name="LuceneIndexesData" start="EAGER" mode="SYNC" remote-timeout="25000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
       <file-store preload="true" purge="false" passivation="false" relative-to="jboss.home.dir" path="..\namespaces\mc\infinispan-file-store">
            <write-behind/>
        </file-store>
        <indexing index="NONE"/>
    </replicated-cache>
    <replicated-cache name="LuceneIndexesLocking" start="EAGER" mode="SYNC" remote-timeout="25000">
        <locking striping="false" acquire-timeout="330000" concurrency-level="500"/>
        <transaction mode="NONE"/>
        <eviction strategy="NONE" max-entries="-1"/>
        <expiration max-idle="-1"/>
        <state-transfer enabled="true" timeout="480000"/>
        <indexing index="NONE"/>
    </replicated-cache>
</cache-container>
<!-- END HIBERNATE INFINISPAN CACHE -->

Tengo entendido (y parece funcionar en la práctica con mis pruebas) que infinispan serializará sus datos a la configuración<file-store> y los datos se retienen entre reinicios de nodo. Incluso algunas pruebas catastróficas (p. Ej.kill -9 <jboss-pid>) han demostrado recuperar el índice limpiamente cuando el nodo vuelve a funcionar. Durante el período fuera de línea, otro nodo asume el control y el clúster funciona sin problemas.