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

[Vladimir Blagojevic]

On 13-01-28 3:11 AM, Dan Berindei wrote:
>
>
> On 25 Jan 2013 23:26, "Vladimir Blagojevic" <vblagoje at redhat.com 
> <mailto: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?
>

Nevermind. Our listeners are good, it was my mistake about start/stop 
and how stop wiped out listeners.
>
> 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.
>
Ok, I like isCreated(), I found a JIRA where Manik was against this idea 
of changing CacheEntryCreatedEvent for unrelated but similar reason!


>
> > 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?
>
>
Yes, but eventually have to notify not at time of expiration! RI for 
example simply checks on access and regular housekeeping if entry is 
expired.


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