Репликация Ehcache/Hibernate и RMI с большим количеством объектов

Question

В настоящее время я изучаю, как использовать опцию распределения RMI в ehcache. Я правильно настроил ehcache.xml, и репликация работает нормально. Однако у меня есть 2 вопроса:

-> Кажется, ehcache/hibernate создает 1 кеш на сущность. Это хорошо, однако, когда репликация на месте, она создает 1 поток/кеш для репликации. Это задумано? Поскольку наш домен большой, он создает около 300 потоков, которые мне кажутся очень большими

-> Еще одно неприятное последствие - это то, что heartbeat messagre объединяет все эти имена кешей. Из того, что я видел, сообщение должно соответствовать 1500 байтам, чего нет, что приводит к этому сообщению в моих журналах: Heartbeat не работает. Настройте меньшее количество кешей для репликации. Размер 1747, но не должен быть больше 1500. Любая идея о том, как это можно изменить?

Большое спасибо за вашу помощь

Answer 1

У нас уже есть один хак, где мы имеем нашу собственную копию спящего EhCacheProvider, отменяющий buildCache() для создания собственных объектов Cache с укороченными именами (хэш имени). Это составляет около 1500 предел. Мы сохраняем хэш-образ исходных имен с именами хэшей для обратного поиска.

Мы сделали это некоторое время назад и использовали его в производстве.

Мы также рассмотрели вашу другую проблему, чтобы иметь один поток репликатора. Сначала мы скопировали RMICacheReplicatorFactory и изменили createCacheEventListener(), чтобы вернуть нашу копию RMIAsynchronousCacheReplicator, которую мы изменили, сделав поле replicationThread статическим, а затем сделав для этого исправления. Мы не обходились, чтобы тщательно протестировать его или поставить на производство, но смотрим на него снова, вот как я нашел этот пост :)

Answer 2

Вы рассматривали JBossCache в качестве альтернативы Ehcache? JBossCache распространяет транзакции и хорошо тестируется на большие нагрузки. Он имеет механизмы репликации более низкого уровня, которые могут позволить вам использовать репликацию многоадресной/широковещательной передачи UDP или TCP.

Answer 3

Возможно ли использование jms-репликации?

(Я искал использование его с асинхронным поведением, он работает хорошо. Документация была неправильной, поэтому я должен был проверить исходный код, чтобы увидеть фактические атрибуты, необходимые для его правильной настройки. Хорошая вещь с jms заключается в том, что если у вас есть такая инфраструктура, вам не нужно настраивать какие-либо брандмауэры и т. д., чтобы пропустить ее.)

Answer 4

Вы считали EHCache над терракотой? Взгляните на Terracotta Hibernate Integration и Terracotta EHCache Integration

Важно, что распределенный EHCache с терракотой является когерентным - все узлы имеют одинаковый вид кеша. Это очень важно для одного из приложений, с которыми я работал.

Посмотрите. Он работает как прелесть для нас.

/RS

Answer 5

Кстати, ограничение по 1500 байт адресовано для Ehcache 1.7 .1 выпуск ядра ehcache. См. EHC-424.