[infinispan-dev] Translating our events to JSR 107 events

[Manik Surtani]

On 28 Jan 2013, at 08:11, Dan Berindei <dan.berindei at gmail.com> wrote:

> 
> On 25 Jan 2013 23:26, "Vladimir Blagojevic" <vblagoje at 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?
> 
> > 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?
> >
> 
> 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.
> 
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.
> 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?
> 
Yes it is.  But it doesn't need to be accurate.  https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cache/event/CacheEntryExpiredListener.java

> Cheers
> 
> Dan
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130128/6d41081e/attachment-0001.html