Replikacja Ehcache/Hibernate i RMI z dużą liczbą jednostek

Question

Obecnie badam sposób korzystania z opcji dystrybucji RMI w ehcache. Mam poprawnie skonfigurowany ehcache.xml i wydaje mi się, że replikacja działa dobrze. Mam jednak 2 pytania:

-> Wygląda na to, że ehcache/hibernate tworzy 1 cache na Entity. Jest to w porządku, jednak gdy replikacja jest na miejscu, tworzy 1 wątek/pamięć podręczną do replikacji. Czy to jest zamierzone zachowanie? Ponieważ nasza domena jest duża, tworzy około 300 wątków, co wydaje mi się naprawdę duże. Kolejną nieprzyjemną konsekwencją jest to, że wiadomość z pulsu wydaje się agregować wszystkie te nazwy w pamięci podręcznej. Z tego, co widziałem, wiadomość powinna zmieścić się w 1500 bajtach, czego nie ma, co prowadzi do tego komunikatu w moich dziennikach: Heartbeat nie działa. Skonfiguruj mniej pamięci podręcznych dla replikacji. Rozmiar to 1747, ale nie powinien być większy niż 1500. Masz pomysł, jak to zmienić?

dziękuję za waszą pomoc

Answer 1

Mamy już jeden siekać gdzie mamy własną niestandardową kopię EhCacheProvider hibernacji, który nadpisuje buildCache(), aby tworzyć własne obiekty Cache ze skróconymi nazwami (hash z nazwy). Obejmuje to limit 1500. Zachowujemy hashmap oryginalnych nazw z nazwami skrótów do wyszukiwania wstecznego.

Zrobiliśmy to jakiś czas temu i używamy go w produkcji.

Przyjrzeliśmy się także Twojemu innemu problemowi, aby mieć jeden wątek replikatora. Najpierw skopiowaliśmy RMICacheReplicatorFactory i zmieniliśmy createCacheEventListener(), aby zwrócić naszą kopię RMIAsynchronousCacheReplicator, którą zmieniliśmy przez uczynienie pola replicationThread statycznym, a następnie wykonanie koniecznych dla niego poprawek. Nie obejdzieliśmy się, aby dokładnie przetestować lub wprowadzić go do produkcji, ale patrzymy na to jeszcze raz, tak to znalazłem ten post :)

Answer 2

Czy rozważałeś JBossCache jako alternatywa dla ehcache? JBossCache dzieli transakcje i jest dobrze przetestowany pod kątem dużych obciążeń. Posiada on mechanizmy replikacji na niższym poziomie, które umożliwiają korzystanie z replikacji multiemisji i emisji UDP lub TCP.

Answer 3

Czy replikacja jms jest opcją?

(Szukałem go z zachowaniem asynchronicznym, działa dobrze, dokumentacja była błędna, więc musiałem sprawdzić kod źródłowy, aby zobaczyć rzeczywiste atrybuty potrzebne do prawidłowej konfiguracji.) Dobrze z jms jest to, że jeśli masz skonfigurowaną infrastrukturę, nie musisz konfigurować żadnych zapór ogniowych itd.).

Answer 4

Czy uważałeś EHCache za terakotę? Spójrz na: Terracotta Hibernate Integration i Terracotta EHCache IntegrationWażne, że rozproszony EHCache z Terracotta jest spójny - wszystkie węzły mają ten sam widok pamięci podręcznej. Jest to bardzo ważne dla jednej z aplikacji, z którymi współpracowałem.

Zobacz. Działa jak urok dla nas.

/RS

Answer 5

Przy okazji, limit 1500 bajtów został zaadresowany do Ehcache 1.7 .1 wydanie ehcache-core. Zobacz EHC-424.