Hey, I figured out why cache listeners notifications were not fired. We have to add listener *after* cache.start() has been called. If listener is added before start it will not be registered.

That aside I found some problems mapping our events to jsr 107 events. The problem is specifically with JSR107 CacheEntryCreatedListener and CacheEntryExpiredListener. The first one is not easy to implement because we need both key/value pair for jsr listener and our CacheEntryCreatedEvent does not provide value. I found some references where people used CacheEntryModified instead with pre being null and post being value to detect new entry in cache. In that case listener translator class would have to keep state and track pre(true/false) for CacheEntryModified, right? Any other way to do it?

The second I have no idea how to implement as we do not have CacheEntryExpired event. True, spec is not rigorous that such an event has to be fired immediately after an entry has expired but eventually (which might be on access). Either way, I am all ears on suggestions how to implement this one.

> > If you're ok with changing the core, you could add a getValue() > method to CacheEntryCreatedEvent, and an isCreated() method to > CacheEntryModifiedEvent (as I suppose you don't want to call the > updates listener when an entry is created). Both changes should be > backwards-compatible. > That could work.

> > > > The second I have no idea how to implement as we do not have > > CacheEntryExpired event. True, spec is not rigorous that such an event > > has to be fired immediately after an entry has expired but eventually > > (which might be on access). Either way, I am all ears on > suggestions how > > to implement this one. > > > > I guess @CacheEntryEvicted/@CacheEntriesEvicted would be the closest > thing we have in Infinispan. But you can't check in the listener if > the entry was evicted because it expired or because there wasn't > enough space in the data container (yet). > There could definitely be something clever we could do here. Adding the (expired or evicted) entry to a queue for later notification. But that would definitely need to be something we explicitly enable rather than have running all the time, since it kinda defeats the purpose of evicting something to save memory only to have it put in a different queue elsewhere until an event is fired.

On 28 Jan 2013, at 15:22, Vladimir Blagojevic <vblagoje(a)redhat.com&gt; wrote: On 13-01-28 7:31 AM, Manik Surtani wrote: If you're ok with changing the core, you could add a getValue() method to CacheEntryCreatedEvent, and an isCreated() method to CacheEntryModifiedEvent (as I suppose you don't want to call the updates listener when an entry is created). Both changes should be backwards-compatible. That could work. The second one Manik? As I was researching how to do this I found you were against the first option https://issues.jboss.org/browse/ISPN-881 Yes, isCreated(). > The second I have no idea how to implement as we do not have > CacheEntryExpired event. True, spec is not rigorous that such an event > has to be fired immediately after an entry has expired but eventually > (which might be on access). Either way, I am all ears on suggestions how > to implement this one. > I guess @CacheEntryEvicted/@CacheEntriesEvicted would be the closest thing we have in Infinispan. But you can't check in the listener if the entry was evicted because it expired or because there wasn't enough space in the data container (yet). There could definitely be something clever we could do here. Adding the (expired or evicted) entry to a queue for later notification. But that would definitely need to be something we explicitly enable rather than have running all the time, since it kinda defeats the purpose of evicting something to save memory only to have it put in a different queue elsewhere until an event is fired. Exactly! One thing we could do is what RI does. Check for expired on entry access from JSR module and during normal expired cleanup cycle..... Be mindful of performance considerations here - this could get very expensive.

On 25 Jan 2013 23:26, "Vladimir Blagojevic" <vblagoje(a)redhat.com <mailto:vblagoje@redhat.com>> wrote: > > Hey, > > I figured out why cache listeners notifications were not fired. We have > to add listener *after* cache.start() has been called. If listener is > added before start it will not be registered. > This doesn't sound right... DefaultCacheManager calls cache.start() automatically, so you should never have to call it explicitly. Looking at the code, the listener should be registered even if the cache wasn't started yet (e.g. ListenerRegistrationTest never calls start()). The only odd thing is that if you stop a cache, all the listeners are lost. Maybe that's what happened in your case?

You could add an interceptor to trigger your events, without using the cache's notifications at all. If you're ok with changing the core, you could add a getValue() method to CacheEntryCreatedEvent, and an isCreated() method to CacheEntryModifiedEvent (as I suppose you don't want to call the updates listener when an entry is created). Both changes should be backwards-compatible.

> The second I have no idea how to implement as we do not have > CacheEntryExpired event. True, spec is not rigorous that such an event > has to be fired immediately after an entry has expired but eventually > (which might be on access). Either way, I am all ears on suggestions how > to implement this one. > I guess @CacheEntryEvicted/@CacheEntriesEvicted would be the closest thing we have in Infinispan. But you can't check in the listener if the entry was evicted because it expired or because there wasn't enough space in the data container (yet). Come to think of it, if an entry is evicted because of size constraints, there isn't any way to keep track of its expiration time and invoke the expiration listener on access either. Is the expiration event mandatory in the JSR?