У меня есть приложение EE, которое я хочу развернуть на 2 экземплярах wildfly13 в кластере. У меня есть сущность, использующая @Cache
(из hibernate) и @NamedQuery
с подсказками для использования кеша: сущность может быть запрошена как по id (будет использовать @Cache
), так и по другому запросу (в этом случае используется подсказка запроса) .
Область кэша, используемая для подсказки, называется «реплицированный запрос».
Я использую wildfly 13, поэтому у меня есть hibernate 5.1.14 (не в режиме предварительного просмотра ee 8), infinispan 9.2.4 и jgroups 4.0.11 и java 10 (мы не можем перейти на java 11 из-за некоторого удаления в классе Unsafe, мы все еще есть библиотеки в зависимости от этого).
Приложение на 100+ EJB и близко к 150k LOC, так что обновление wildfly пока не вариант.
Проблема: реплицируемый кеш не реплицируется, даже не запускается как реплицированный.
Реплицированный кэш Infinispan, не реплицирующий объекты для чтения, не полезен и Реплицируемый кэш с бесконечным временем с Wildfly 11 .
Я использую jgroups с tcpping (так как приложение будет развернуто в частном облаке, нам нужно поддерживать как можно более низкую сеть, чтобы udp не был опцией). Кластер хорошо формируется между двумя экземплярами wildfly (подтверждено журналами и jmx), но реплицируемый кеш не запускается при развертывании, как если бы он не мог найти транспорт.
Имя кеша, которое я использую для типа «replicated-cache», не имеет значения, включая предварительно сконфигурированный «replicated-query».
Использование «не рекомендуемой конфигурации» для jgroups, как упомянуто Полом Ферраро здесь , не позволило кластеру сформироваться (что в моем случае является шагом назад, потому что кластер формируется при использовании моего conf ).
Одна странная вещь: кэш UpdateTimestamp, настроенный как реплицируемый, реплицируется (подтверждается журналами и jmx: к имени региона добавляется суффикс repl_async).
Кэши находятся в invalidation_sync по умолчанию и работают нормально, поскольку SQL-запрос выдается только один раз с теми же параметрами (подтверждено журналами и статистикой).
На данный момент (в целях тестирования / отладки) я развернул оба экземпляра на своем локальном компьютере. omega1 со смещением порта 20000 и omega2 со смещением порта 30000.
Я не пробовал распределенный кеш, потому что из того, что я прочитал, я столкнулся с такой же проблемой.
Вот соответствующая часть сущности:
@Entity
@Table(name = "my_entity", schema = "public")
@NamedQueries({
@NamedQuery(name = "myEntityTest", query = "select p from MyEntity p where p.value = :val", hints = {
@QueryHint(name = org.hibernate.annotations.QueryHints.CACHEABLE, value = "true"),
@QueryHint(name = org.hibernate.annotations.QueryHints.CACHE_REGION, value = "RPL-myEntityTest")
})
})
@Cache(usage = CacheConcurrencyStrategy.NONE, region = "replicated-entity")
Вот часть подсистемы jgroups standalone-full-ha.xml:
<subsystem xmlns="urn:jboss:domain:jgroups:6.0">
<channels default="omega-ee">
<channel name="omega-ee" stack="tcpping" cluster="omega-ejb" statistics-enabled="true"/>
</channels>
<stacks>
<stack name="tcpping">
<transport type="TCP" statistics-enabled="true" socket-binding="jgroups-tcp"/>
<protocol type="org.jgroups.protocols.TCPPING">
<property name="port_range">
10
</property>
<property name="discovery_rsp_expiry_time">
3000
</property>
<property name="send_cache_on_join">
true
</property>
<property name="initial_hosts">
localhost[27600],localhost[37600]
</property>
</protocol>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"/>
<protocol type="FD_ALL"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="pbcast.NAKACK2"/>
<protocol type="UNICAST3"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
Вот привязка к сокету для jgroups-tcp:
<socket-binding name="jgroups-tcp" interface="private" port="7600"/>
И это раздел контейнера кэша hibernate на неопределенный срок в standalone-full-ha.xml:
<cache-container name="hibernate" module="org.infinispan.hibernate-cache">
<transport channel="omega-ee" lock-timeout="60000"/>
<local-cache name="local-query">
<object-memory size="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity">
<transaction mode="NON_XA"/>
<object-memory size="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="replicated-query">
<transaction mode="NON_XA"/>
</replicated-cache>
<replicated-cache name="RPL-myEntityTest" statistics-enabled="true">
<transaction mode="BATCH"/>
</replicated-cache>
<replicated-cache name="replicated-entity" statistics-enabled="true">
<transaction mode="NONE"/>
</replicated-cache>
</cache-container>
и я установил следующие свойства в файле persistence.xml
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQL9Dialect"/>
<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.show_sql" value="true"/>
<property name="hibernate.format_sql" value="true"/>
</properties>
Я ожидаю:
реплицированные кэши для запуска при развертывании (возможно, даже при запуске, если они настроены в подсистеме Infispan)
кэшированные данные для репликации между узлами на чтение и недействительным кластером в целом при обновлении / истечении срока действия / аннулировании
данные для извлечения из кэша (локальные, потому что они должны были быть реплицированы).
Я чувствую, что не так далеко от ожидаемого результата, но я что-то упускаю.
Любая помощь будет высоко ценится!
Обновление 1 :
Я просто попробовал то, что предложил @Bela Ban, и установил начальные хосты на localhost[7600]
на обоих узлах, но безуспешно: кластер не формируется. Я использую смещение порта, чтобы запустить оба узла на моем локальном компьютере, чтобы избежать перекрытия портов.
При localhost[7600]
на обоих хостах, как один узел узнает, к какому порту подключаться к другому, поскольку мне нужно использовать смещение порта?
Я даже пытался localhost[7600],localhost[37600]
на узле, который я начинаю со смещением 20000, и localhost[7600],localhost[27600]
на узле, который я начинаю со смещением 30000. Кластер формируется, но кэш не реплицируется.
Обновление 2 :
TКэш сущности находится в invalidation_sync и работает как положено, что означает, что jgroups работает должным образом и подтверждает, что кластер сформирован правильно, поэтому я предполагаю, что проблема связана с бесконечностью или с мухами.