Ich untersuche gerade, wie man die RMI-Verteilungsoption in ehcache verwendet. Ich habe richtig ehcache.xml konfiguriert und die Replikation scheint gut zu funktionieren. Allerdings habe ich 2 Fragen:
- & gt; Es scheint, dass ehcache / hibernate 1 Cache pro Entity erstellt. 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 sehr groß erscheint
- & gt; 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
Wir haben bereits einen Hack, in dem wir eine eigene Kopie des Hibernate EhCacheProvider haben, die buildCache () überschreibt, um eigene Cache-Objekte mit verkürzten Namen (dem 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 die umgekehrte Suche.
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 in die Produktion zu bringen, sondern schauen es uns wieder an. So habe ich diesen Beitrag gefunden:)
Haben Sie JBossCache als Alternative zu EHcache betrachtet? JBossCache hat Transaktionen verteilt und ist auf hohe Belastungen getestet. Es verfügt über untergeordnete Replikationsmechanismen, mit denen Sie UDP- oder TCP-Multicasting / Broadcasting-Replikation verwenden können.
Haben Sie EHCache über Terracotta betrachtet? Sehen Sie sich die Integration von Terracotta Hibernate und Terrakotta EHCache Integration
Wichtig ist, dass der Terracotta-verteilte EHCache kohärent ist - alle Knoten haben die gleiche Ansicht des Caches. Dies ist sehr wichtig für eine der Anwendungen, mit denen ich gearbeitet habe.
Sieh es dir an. Es wirkt wie ein Zauber für uns.
/ RS
Übrigens, das Limit von 1500 Byte wurde für die Ehcache 1.7.1-Version von ehcache-core behoben. Siehe EHC-424 .
Ist Jms-Replikation eine Option?
(Ich habe versucht, es mit asynchronem Verhalten zu verwenden, es funktioniert gut. 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. Gute Sache mit jms ist, dass wenn Sie Wenn diese Infrastruktur eingerichtet ist, müssen Sie keine Firewalls konfigurieren und so weiter.)
Tags und Links java hibernate ehcache replication