Ehcache/Hibernate und RMI-Replikation mit einer großen Anzahl von Entitäten

Question

Ich untersuche derzeit, wie die RMI-Verteilungsoption in ehcache verwendet wird. Ich habe richtig ehcache.xml konfiguriert und die Replikation scheint gut zu funktionieren. Allerdings habe ich 2 Fragen:

-> Es scheint, ehcache/hibernate erstellt 1 Cache pro Entity. Dies ist in Ordnung, wenn jedoch eine Replikation vorhanden ist, wird 1 Thread/Cache zum Replizieren erstellt. Ist das das beabsichtigte Verhalten? Da unsere Domain groß ist, erzeugt sie etwa 300 Threads, was mir wirklich sehr groß erscheint.

-> Eine weitere unangenehme Konsequenz ist, dass der Heartbeat messagre all diese Cache-Namen zu aggregieren scheint. Von dem, was ich sah, sollte die Nachricht in 1500 Bytes passen, was es nicht tut, was zu dieser Nachricht in meinen Protokollen führt: Heartbeat funktioniert nicht. Konfigurieren Sie weniger Caches für die Replikation. Größe ist 1747, sollte aber nicht größer als 1500 sein. Irgendeine Idee, wie dies geändert werden könnte?

Vielen Dank für Ihre Hilfe

Answer 1

Wir haben bereits ein Hack, wo wir unsere eigene Kopie des Hibernate EhCacheProvider haben, die buildCache überschreibt() unsere eigenen Cache-Objekte mit verkürztem Namen (der Hash des Namens) zu erstellen. Dies geht um die 1500 Grenze. Wir behalten eine Hashmap der ursprünglichen Namen mit den Hash-Namen für Reverse-Lookup.

Wir haben das vor einer Weile gemacht und haben es in der Produktion verwendet.

Wir haben uns auch Ihr anderes Problem angesehen, um einen einzelnen Replikator Thread zu haben. Zuerst haben wir RMICacheReplicatorFactory kopiert und createCacheEventListener() geändert, um unsere Kopie von RMIAsynchronousCacheReplicator zurückzugeben, die wir modifiziert haben, indem wir das replicationThread-Feld statisch gemacht haben und dann die notwendigen Korrekturen dafür vorgenommen haben. Wir sind nicht dazu gekommen, es gründlich zu testen oder es in Produktion zu bringen, sondern schauen es wieder an, wie ich diesen Beitrag gefunden habe :)

Answer 2

Haben Sie JBossCache als Alternative zu ehcache in Betracht ziehen? JBossCache hat Transaktionen verteilt und ist auf hohe Belastungen getestet. Es verfügt über Replikationsmechanismen auf niedriger Ebene, mit denen Sie UDP- oder TCP-Multicasting/Broadcasting-Replikation verwenden können.

Answer 3

Ist Jms-Replikation eine Option?

(Ich habe versucht, es mit Async-Verhalten zu verwenden, funktioniert es schön. Dokumentation war falsch, also musste ich den Quellcode überprüfen, um die tatsächlichen Attribute zu sehen, die benötigt werden, um es richtig zu konfigurieren. Gut mit JMS ist, dass wenn Sie müssen diese Infrastruktur eingerichtet haben Sie müssen keine Firewalls konfigurieren und so weiter, um es durchzulassen.)

Answer 4

Haben Sie EHCache über Terracotta in Betracht gezogen? Schauen Sie sich Terracotta Hibernate Integration und Terracotta EHCache Integration

Wichtig ist die Terracotta verteilt EHCache ist kohärent - alle Knoten haben die gleiche Ansicht auf den Cache. Dies ist sehr wichtig für eine der Anwendungen, mit denen ich gearbeitet habe.

Werfen Sie einen Blick. Es wirkt wie ein Zauber für uns.

/RS

Answer 5

Übrigens, das Limit von 1500 Byte wurde für den Ehcache 1.7 adressiert .1 Freisetzung von Ehcache-Core. Siehe EHC-424.