Usamos hibernate-search para indexação de texto completo de nossas entidades no wildfly 8.2 (usando as bibliotecas hibernate / hibernate-search e infinspan incluídas no wildfly 8.2). Executando como nó independente ou em um domínio com um mestre de pesquisa hibernado dedicado e oorg.hibernate.search.store.impl.FSDirectoryProvider isso tem funcionado bem por vários anos (e versões do jboss).

Agora, gostaríamos de implantar esse sistema em um ambiente em cluster de alta disponibilidade com o wildfly 8.2 executando atrás de um proxy de balanceamento de carga. Queremos ter um cluster escalável dinamicamente sem um ponto de falha no sentido de um mestre de domínio ou mestre de pesquisa de hibernação e configuramos isso com nós independentes sem domínio. Para eleger o mestre HS, estamos usando o back-end jgroups e, para replicar os dados de pesquisa de hibernação, estamos usando o provedor infinispan com umfile-store para manter os dados entre as reinicializações.

Eu instalei tudo isso rapidamente, e fiquei bastante empolgado, pois parece um cenário robusto e escalável, mas estou um pouco hesitante em colocar essa configuração em produção, já que o back-end do jgroups foi chamado de "experimental" (e em alguns fóruns). "extremamente experimental"). Qual é o status atual do back-end? As pessoas estão usando atualmente na produção? O que podemos fazer para minimizar os riscos usando essa configuração?

Além disso, alguém tem experiência em usar o infinispan junto com a pesquisa de hibernação nesta constelação? A maioria das configurações relacionadasreplicated-cache foram simplesmente reutilizados a partir de exemplos existentes, se alguém tiver algumas dicas ou conselhos sobre essas configurações, por exemplo, será dimensionado com índices de ~ 50 GB? Ficaria muito grato por qualquer feedback ou experiência com cenários semelhantes.

A configuração foi feita principalmente usando material de referência daqui:

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

As etapas detalhadas que tomamos estão incluídas abaixo.

Como base, pegamos e ampliamos ostandalone-ha-full.xmlconfigurar jgroups para usar a pilha TCPexecute TCPPING em vez de MPing (estamos planejando executá-lo em um contexto de nuvem em que o multicast / udp causa problemas - podemos mudar para JDBCPing para tornar isso mais flexível em algum momento).corremos com as seguintes propriedades do sistema por nó (mudanças de nome / porta por nó, é claro)

Propriedades do 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>     

Definimos o seguinte<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 -->

É meu entendimento (e parece funcionar na prática com meus testes) que o infinispan serializará seus dados para o configurado<file-store> e os dados são retidos entre as reinicializações do nó. Mesmo alguns testes catastróficos (por exemplo,kill -9 <jboss-pid>) demonstraram recuperar o índice corretamente quando o nó voltar. Durante o período offline, outro nó assume o controle como mestre e o cluster é executado sem problemas.