Proposed approach for Issue #165 : Decouple event creation from event firing

[Rishabh Monga]

Here's the proposal for Decoupling cache event creation from firing.

 

The event firing mechanism will essentially be spilt into a two-stage process.

 

The first being the event creation, where the cache operation creates an event in the ‘apply’ method of the Bi-Function. This event will be added (produced) to an event queue maintained by the CacheEventNotificationService. Now if the said cache operation is successful, i.e. the apply method in Bi-Function returns successfully, the event will be marked `fireable`. At this point the event can be removed from the queue and fired.

 

The event firing takes place depending on the event ordering configured by the user. Incase of ‘ordered’ firing, a single thread will wait until the event is marked `fireable`, after which it can fire (consume) the events. An event whose `apply` fails to successfully return can be removed from the queue.

 

The queue here can be something like a `ConcurrentLinkedQueue`, to allow a fast non-blocking access. The queue will however need to have a conditional bound (ConsumerBarrier?) to prevent memory overflow incase of asynchronous-ordered mode, where multiple events are added to the queue but only a single thread has the responsibility of firing them.

 

 

C1

 

                                                                                                                 Event Added

 

 

 

R1

U2

U1

C1

 

                                                Events Marked `Fireable`                 

 

 

R2

U3

C3

R1

U2

U1

C1

 

                                  Worker thread can now remove C1 event from queue and fire it. It will then wait for U1 to become `fireable` before moving to U2

 

 

Whereas in case of ‘unordered’ firing, there are two possible approaches:

1. While marking `fireable` we can move the event to a separate queue from where worker threads can pick events to fire and mark them as `fired`. The problem here is cleaning up the ` ConcurrentLinkedQueue` as these `fired` events might stay in this queue for a while.
   
2. Else, we can have two separate implementations at work. We check registered listeners; if we do not have an ordered listener present we can directly send the event to one of the worker threads to fire it instead of marking it `fireable`. Incase an ordered event listener is registered; we can fall back to storing listeners in a queue.
   

Please provide comments/feedback

[Louis Jacomet]

Hi Rishabh,

All the complexity hides in the details of this task I believe. So I agree with what I understand from your approach but it lacks a number of things.

• How are event creation and "allow to fire" linked?
• Note that here, there is a catch as Expiration/Eviction events are created at the Store level while the "allow to fire" will always happen at the Cache level.
• What's the impact of sync / async listeners?
• Mostly, how will you handle sync ones as your proposal is async in nature.
• We do not have the centralised service for threading, but think of the impact(s) on thread creation/usage this solution has.
• Are you linear in thread use per cache or is there some sharing happening?

Regards,

Louis

--
You received this message because you are subscribed to the Google Groups "ehcache-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ehcache-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ehcache-dev/2e1f78dc-bab0-49e1-80ba-3f45c0263a41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rishabh Monga]

With regards to handling events at store level, the approach I was planning, is to have the onEvent method in CacheEventNotificationService return a reference to the event, so it can be marked as 'fireable' once the operation completes.

public AtomicReference<CacheEvent> onEvent(final CacheEvent<K, V> event) 

0

This works in case of events happening at cache level, but for stores, especially caches with multiple tiers, some more steps would be required. Presently, I'm thinking of having the 'StoreEventListener' methods i.e. onExpiration() and onEviction() also return reference to the event so it can be marked at the store level itself.

Another approach is to have a ThreadLocal that stores and fires events at the store level. This can be cleaned later. Not sure if this have acceptable cost

Please provide comments/feedback or another approach