Event log
by Tristan Tarrant
Hi guys,
in order to keep track of notable events (nodes joining, leaving,
rebalances, availability, task execution) and present them in the
console I was thinking of using specific logging categories. These logs
would be then collected by dedicated appenders on each node. The idea
would then be to have some distexec tasks exposed to the management
interface (console/CLI) which can query and aggregate the data.
Initially I was thinking about using a local cache per-node with a SFCS,
eviction, expiration and indexing and creating a log4j appender which
writes to this cache, but probably a simpler lucene-based appender would
suffice.
WDYT ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 10 months
Cache entry creation and modification events
by Dan Berindei
Hi guys
We have two different listener types for cache entry creation
(@CacheEntryCreated) and modification (of an already-existing entry,
@CacheEntryModified). However, PutMapCommand and
PutKeyValueCommand/IGNORE_RETURN_VALUES do not read the previous value
from loaders and/or remote nodes, so we sometimes notify the
@CacheEntryCreated listeners instead of the @CacheEntryModified
listeners.
PutMapCommand has a "workaround" for this: it also notifies the
@CacheEntryModified listener, regardless of whether it found the entry
or not. I'd like to change this [1] and make PutMapCommand and
PutKeyValueCommand behave the same way.
These are the options I'm considering:
1. Replicate the PutKeyValueCommand behaviour, and document that we
may sometimes notify the @CacheEntryCreated listener even though the
entry already exists.
It would be the simplest to implement (in fact I already have a
patch), but it doesn't feel right.
2. Always read the previous value from loaders and/or remote nodes
when a @CacheEntryCreated/Modified event listener is registered.
This would give us the correct behaviour, at the expense of performance.
3. Same as option 2, but also add a @CacheEntryWritten listener type,
which only receives the new value and is notified regardless of
whether the entry was created or modified.
This would give users a choice: if they don't care about the previous
value, the cache will be just as fast as usual, but if they need the
previous value, they need to accept a slowdown.
4. Add the @CacheEntryWritten listener type, but only notify these
listeners instead of the @CacheEntryCreated/Modified listeners for
cache.putAll() and cache.withFlags(IGNORE_RETURN_VALUES).put().
This is the option Galder chose for the functional API, but the
difference between write-only and read-write operations is a lot
clearer there, so I'm not convinced it's ok for the ConcurrentMap API.
Personally I would choose option 3, because it would be mostly
backwards-compatible: old code would only need to change if existing
listeners are slowing down the cache.
Cheers
Dan
[1] https://issues.jboss.org/browse/ISPN-5752
10 years, 10 months
