2009-02-19 11 views
8

Attualmente sto studiando come utilizzare l'opzione di distribuzione RMI in ehcache. Ho configurato correttamente ehcache.xml e la replica sembra funzionare correttamente. Tuttavia ho 2 domande:Ehcache/Hibernate e replica RMI con un gran numero di entità

-> Sembra che ehcache/hibernate crei 1 cache per entità. Questo va bene, tuttavia quando la replica è a posto crea 1 thread/cache da replicare. È questo il comportamento previsto? Dato che il nostro dominio è grande, crea circa 300 thread, il che mi sembra davvero grande

-> Un'altra conseguenza sgradevole è che il messaggio di heartbeat sembra aggregare tutti quei nomi di cache. Da quello che ho visto il messaggio dovrebbe essere contenuto in 1500 byte, cosa che non funziona, che porta a questo messaggio nei miei registri: Heartbeat non funziona. Configura meno cache per la replica. La dimensione è 1747 ma non deve essere maggiore di 1500. Qualche idea su come questo potrebbe essere cambiato?

Grazie mille per il vostro aiuto

risposta

3

Abbiamo già una mod dove abbiamo la nostra propria copia personalizzata della EhCacheProvider ibernazione che sostituisce buildCache() per creare i nostri oggetti Cache con nomi abbreviati (l'hash del nome). Questo aggira il limite del 1500. Manteniamo una hashmap dei nomi originali con i nomi hash per la ricerca inversa.

L'abbiamo fatto un po 'di tempo fa e lo abbiamo utilizzato in produzione.

Abbiamo anche esaminato il tuo altro problema per avere un singolo thread di replica. Per prima cosa abbiamo copiato RMICacheReplicatorFactory e modificato createCacheEventListener() per restituire la nostra copia di RMIAsynchronousCacheReplicator che abbiamo modificato rendendo statico il campo replicationThread e quindi apportando le correzioni necessarie per questo. Non siamo riusciti a testarlo a fondo oa metterlo in produzione, ma lo stiamo osservando di nuovo, ecco come ho trovato questo post :)

+0

Il limite 1500 è indirizzato con https://jira.terracotta.org/jira/browse/EHC-424 per la prossima Ehcache 1.7.1. –

2

Avete considerato JBossCache come alternativa alla EHCache? JBossCache ha distribuito le transazioni ed è ben testato per carichi elevati. Ha meccanismi di replica di livello inferiore che possono consentire di utilizzare la replica multicasting/broadcast UDP o TCP.

0

La replica jms è un'opzione?

(Ho cercato di usarlo con il comportamento asincrono, funziona, la documentazione era sbagliata, quindi ho dovuto controllare il codice sorgente per vedere gli attributi reali necessari per configurarlo correttamente. hai questa infrastruttura impostata non devi configurare nessun firewall e così via per lasciarlo passare.)

+0

JMS non è dove quasi in tempo reale, qualsiasi trasporto che aggiorna una cache deve essere in tempo reale. –

+0

Se si imposta una cache predefinita, questa verrà clonata per creare ciascuna cache delle entità necessaria. AFAIK, NON otterrai "una grande cache". –

2

Hai considerato EHCache su Terracotta? Date un'occhiata a Terracotta Hibernate Integration e Terracotta EHCache Integration

Importantemente l'EHCache distribuita in Terracotta è coerente - tutti i nodi hanno la stessa vista della cache. Questo è molto importante per una delle applicazioni con cui ho lavorato.

Dai un'occhiata. Funziona come un fascino per noi.

/RS

0

A proposito, il limite di 1500 byte è stato indirizzato per Ehcache 1.7 .1 rilascio di ehcache-core. Vedi EHC-424.

Problemi correlati