Se usate Log4J vi sarà capitata la necessità di loggare package o classi differenti in file o più genericamente su appender separati. Questo articolo spiega con un semplice esempio come risolvere questa richiesta.

Immaginiamo di voler loggare separatamente la seguente lista:

• il package it.mio.package
• il package it.tuo.package
• la classe it.mio.package.LaMiaClasse

Sarà sufficiente avere il seguente file di configurazione di log4j: continua a leggere »

Cos’è JCS

Nell’articolo “Un sistema di cache” ho descritto cos’è un generico sistema di cache, con questo articolo voglio introdurre un’implementazione scritta in Java di un meccanismo di cache.

The Java Caching System (JCS), giunto attualmente alla versione 1.3 fa parte del progetto Apache Jakarta Project; funziona con JDK 1.3 e superiore . Necessita solo di due dipendenze: Commons Logging e Doug Lea’s Util Concurrent.

Si tratta di un sistema di cache distribuito scritto in Java. Il suo scopo è quello di velocizzare le applicazioni fornendo un meccanismo per gestire un sistema di cache di dati di varia natura. Come tutti i sistemi di cache, JCS è più utile per insiemi di dati con grandi moli di letture e scarse quantità di scritture.

JCS va al di là del del cachare i dati in memoria, offre molte altre funzionalità:

• Gestione della memoria
• Disk overflow (e deframmentazione)
• Controlli dei Thread pool
• Raggruppamento degli elementi
• Dipendenze minime
• Tempo di scadenza (il tempo di inattività e tempo massimo di vita)
• Framework estendibile
• Parametri configurabili a runtime
• Separazione dei dati per regione
• Configurazione della granularità degli elementi
• Sincronizzazione remota
• Recuper remoto
• Non-blocking “zombie” (balking facade) pattern
• Distribuzione degli elementi via HTTP, TCP, o UDP
• Scoperta tramite UDP di altre cache
• Gestione degli eventi
• Chaining (o clustering) di server remoti

Cosa non è JCS

JCS non è una tag library o una applicazione specifica per il web. JCS è un sistema di cache general purpose che può essere usato nelle web applications, nei servizi, nelle applicazioni Java stand alone, ecc…

JCS non è un meccanismo transazionale distribuito. Le cahce transazionali distribuite non sono scalabili. JCS è una cache non un database. I meccanismi distribuiti forniti da JCS può espandersi in decine di server. In una service oriented architecture ben studiata, JCS può essere usato in servizi con numerosi nodi. Questo non può essere possibile se il meccanismo di distribuzione è transazionale.

JCS non usa AOP. JCS è un sistema di cache non invasivo ad alte performance. Esso non può manipolare gli oggetti cachati e non è in grado di inviare solamente una porzione di essi.

JCS non deriva da nessun altro progetto, JCS è un progetto maturo sviluppato e utilizzato fin dal 2001. Con gli anni JCS ha risolto numerosi bug e aggiunto decine di features, fatto con il miglior design possibile ed è uno dei sistemi di cache migliori in circolazione.

Come funziona

La base di JCS c’è una Composite Cache, nella quale possono essere pluggate quattro diversi tipi di cahce per ogni regione: (1) Memory, (2) Disk, (3) Lateral, and (4) Remote. La Composite Cache orchestra l’accesso alle varie cache configurate per l’utilizzo in una regione.

Il jar di JCS fornisce l’implementazioni di ciascuno dei quattro tipi di cache. In aggiunta ai quattro core, JCS fornisce inoltre ulteriori plugin per ogni tipo.

I tipi di cahce

1. LRU Memory Cache: la LRU Memory Cache è estremamente veloce e profondamente configurabile. Usa un algoritmo Least Recently Used (i dati utilizzati meno di recente vengono eliminati dalla cache per far spazio ai nuovi) per gestire gli elementi memorizzati. Questa cache usa una propria implementazione di una LRU Map significativamente più veloce di entrambe le implementazioni fornite dalla JDK 1.4 (LRUMap e LinkedHashMap).
2. Indexed Disk Cache: la Indexed Disk Cache segue il pattern più veloce per il disk swapping. Gli elementi in cache sono scritti su disco attraverso continui processi basati su code. La lunghezza del dato e scritta nei primi byte della entry. L’offset è salvato in memoria e può essere referenziato tramite la chiave. Quando i dati sono spostati dalla cache del disco, la posizione e la grandezza vengono memorizzate per essere riutilizzate quando possibile.
3. TCP Lateral Cach: la TCP Lateral Cache fornisce un semplice modo per distribuire la cache su più server. Si basa su un meccanismo di scoperta UDP, in modo che si possano aggiungere nuovi nodi senza dover riconfigurare tutto. La TCP Lateral Cache funziona stabilendo delle connessioni con i nodi, ognuno dei quali mantiene una connessione con ogni altro
4. RMI Remote Cache: JCS fornisce una cache basata su RMI . Piuttosto che dover collegare ogni nodo ad ogni altro nodo, è possibile utilizzare il cache server remoto come il punto di connessione. Ogni nodo si connette al server remoto, che poi trasmetterà gli eventi agli altri nodi. Per mantenere la coerenza in un cluster senza incorrere nell’overhead di serializzazione, è possibile decidere di inviare messaggi di invalidazione agli altri nodi locali, piuttosto che inviare l’oggetto su filo. La cache del server remoto mantiene una versione serializzata degli oggetti, in modo che non ha bisogno di essere deployato con le vostre librerie di classi. Il server remoto può essere concatenato e un elenco di failover server può essere configurato sul client.