Réplication Ehcache/Hibernate et RMI avec un grand nombre d'entités

Question

J'étudie actuellement comment utiliser l'option de distribution RMI dans ehcache. J'ai bien configuré ehcache.xml et la réplication semble fonctionner correctement. Cependant j'ai 2 questions:

-> Il semble que ehcache/hibernate crée 1 cache par entité. C'est très bien, cependant quand la réplication est en place, créez 1 thread/cache à répliquer. Est-ce le comportement attendu? Comme notre domaine est grand, il crée environ 300 threads, ce qui me semble vraiment énorme

-> Une autre conséquence désagréable est que le message de pulsation semble agréger tous ces noms de cache. De ce que j'ai vu le message devrait tenir dans 1500 octets, ce qui n'est pas le cas, ce qui conduit à ce message dans mes journaux: Heartbeat ne fonctionne pas. Configurez moins de caches pour la réplication. La taille est 1747 mais ne devrait pas être supérieure à 1500. Une idée sur la façon dont cela pourrait être changé?

Merci beaucoup pour votre aide

Answer 1

Nous avons déjà un bidouille où nous avons notre propre copie personnalisée du EhCacheProvider de mise en veille prolongée qui l'emporte sur buildCache() pour créer nos propres objets de cache avec des noms raccourcies (le hachage du nom). Cela contourne la limite de 1500. Nous conservons une hashmap des noms d'origine avec les noms de hachage pour la recherche inversée.

Nous l'avons fait il y a un certain temps et nous l'utilisons en production.

Nous avons également examiné votre autre problème pour avoir un seul thread de réplicateur. D'abord, nous avons copié RMICacheReplicatorFactory et changé createCacheEventListener() pour retourner notre copie de RMIAsynchronousCacheReplicator que nous avons modifié en rendant le champ replicationThread statique, puis en effectuant les corrections nécrassaires pour cela. Nous n'avons pas essayé de le tester complètement ou de le mettre en production, mais nous le réexaminons, et voici comment j'ai trouvé cet article :)

Answer 2

Avez-vous envisagé JBossCache comme une alternative à ehcache? JBossCache a des transactions distribuées et est testé pour les charges élevées. Il dispose de mécanismes de réplication de niveau inférieur qui peuvent vous permettre d'utiliser la réplication multidiffusion/diffusion UDP ou TCP.

Answer 3

La réplication jms est-elle une option?

(J'ai cherché à l'utiliser avec un comportement asynchrone, cela fonctionne bien.) La documentation était erronée, j'ai donc dû vérifier le code source pour voir les attributs nécessaires pour le configurer correctement. vous avez configuré cette infrastructure, vous n'avez pas à configurer de pare-feu et ainsi de suite.)

Answer 4

Avez-vous pensé à EHCache plutôt qu'à Terracotta? Jetez un oeil à Terracotta Hibernate Integration et Terracotta EHCache Integration

Important, le EHCache distribué en terre cuite est cohérent - tous les nœuds ont la même vue du cache. C'est très important pour l'une des applications avec lesquelles j'ai travaillé.

Jetez un coup d'œil. Cela fonctionne comme un charme pour nous.

/RS

Answer 5

Par ailleurs, la limite de 1500 octets a été adressée pour le Ehcache 1.7 .1 libération de ehcache-core. Voir EHC-424.