5 Replies Latest reply on Aug 26, 2005 2:21 PM by hmesha

TreeCacheListener - introducing new event types design

hmesha Aug 22, 2005 4:35 PM

Hi all,

Below is a proposed solution to adding new event types needed in 1.2.4 release of JBossCache. Please provide your suggestion and/ or comments. Also, if you'd like to see any other event types added, please provide the use case and we'll seriously consider it.

JIRA issues:
------------
1. http://jira.jboss.com/jira/browse/JBCACHE-87
2. http://jira.jboss.com/jira/browse/JBCACHE-159
3. http://jira.jboss.com/jira/browse/JBCACHE-229
4. http://jira.jboss.com/jira/browse/JBCACHE-261

Goal:
-----

New event types are needed for added new features to JBossCache in 1.2.4 release
and enhancements requests by users. Adding new event types to the current
TreeCacheListener interface will break the current implementation forcing
implementators to re-work their implementation. This document presents a solution
to this problem in release 1.2.4 which will also serve as a long term startegy
to be completed in release 1.3 to avoid such a problem in the future.

Design
------
1. Create ExtendedTreeCacheListener interface to include the new event types. Instead of following
TreeCacheListener way of defining event types pre... and ...'ed, create action method cooresponds to
node event with a boolean to indicate whether the notification should be issued before or after the action.
The user would implement the event interested in by passing to the method the boolean vlaue.

Currently the following new events are needed for callbacks:
a. Passivate/Activate (JBCACHE-229)
1. nodeActivate(Fqn fqn, boolean pre)
2. nodePassivate(Fqn fqn, boolean pre)
b. Evict and Remove (JBCACHE-159)
1. nodeEvict(Fqn fqn, boolean pre) // post should not be implemented at this point since nodEvicted
// already exist in TreeCacheListener, refactoring will be needed
// in release 1.3
2. nodeRemove(Fqn fqn, boolean pre) // post should not be implemented at this point since nodRemoved
// already exist in TreeCacheListener, refactoring will be needed
// in release 1.3
c. (JBCACHE-261)??

Note: ExtendedTreeCacheListener will be used to include new events in 1.2.4 and 1.2.5. In 1.3,
it will be merged with TreeCacheListener. The nature of this merge is out of the scope of this effort.

2. Create AbstractTreeCacheListener implements TreeCacheListener and ExtendedTreeCacheListener (JBCACHE-87).
The abstract class will allow the integration of the new events and any future events to be added into
existing classes without interruption. Also, classes that are not interested in the event can simply
ignore it. Refactoring is needed to extend the abstract class instead of implementing the listeners directly.

Classes that need refactoring: Only classes that need to implement any of the new event types.

3. Create Notification Interceptor and add it to the bottom of the interceptor stack on cache startup.
This interceptor will assume the responsibility of notification on behalf of all the interceptors in
the stack. Therefore, the other interceptors will not worry about notifications.
The notification interceptor will simply invoke TreeCache callback implemented methods. If "pre=true",
on the way in pre-notification is issued for the particular method call. If "pre=false", on the way out to
invokes the notification.

Issues:
-------

1. JBCACHE-48, JBCACHE-49 are not relevant to this effort, is the assumption true here?
2. JBCACHE-261 requirements are not clear with respect to this effort.
Note: Based on the discussion we had during our meeting, Bela added to JGroups 2.2.9
"payload" in MethodCall put and get methods.

Note: The above proposal has been added in a document to CVS under JBossCache/docs/design/NewTreeCacheListener.txt.

Thanks,

- Hany Mesha

1. Re: TreeCacheListener - introducing new event types design

belaban Aug 23, 2005 2:40 AM (in response to hmesha)
Yes, I guess JBCACHE-48 (adds modified data to callbacks) is not relevant here. This will be part of the finalized and merged TreeCacheListener in 1.3 though.

JBCACHE-49 is something to look at in the 1.3 time frame too. This is about what are the semantics when you call a CRUD method from within a callback, e.g.
void nodeModified(Fqn fqn) { if(!cache.exists("/a/b/c") cache.put("/a/b/c", null); }

Not sure if we should alow this in the first place, but if we do we have to implement this. Note that this can lead to recursive cycles, e.g. if we omit the if() check, we blindly pt an element into the cache, which emits another nodeModified(), which adds another node, which emits another notification and so on...
Actions
2. Re: TreeCacheListener - introducing new event types design

ben.wang Aug 25, 2005 5:40 PM (in response to hmesha)

Just have couple quick comments:

1. Looks like we have going toward the roads of reactoring the whole notification mechansim. I am good for it. But I'd prefer to insulate this from 1.2.4 release. The plan for 1.2.4 now is 9/12 for Beta. Oce we go beta, I will branch it out so new features on JBossCache can be checked in to head.

2. If we are talking about the queue for events, do we need ThreadLocal to store it? If we do, it may be good that we have a startInterceptor and endInterceptor in the interceptor chain. So startInterceptor can do some initialization, e.g., create an Invocation object, etc. This is not all to do with event nofitication interceptor. But that may be handy.

3. One current main user of event nofitication is the eviction policy framework. If you look at the code logic, there are places where I said put() but has a flag of not emmitting event. This is needed to prevent recrusive loop. So somthing to keep in mind here.

-Ben
Actions
3. Re: TreeCacheListener - introducing new event types design

manik Aug 26, 2005 6:07 AM (in response to hmesha)

"ben.wang@jboss.com" wrote:

2. If we are talking about the queue for events, do we need ThreadLocal to store it? If we do, it may be good that we have a startInterceptor and endInterceptor in the interceptor chain. So startInterceptor can do some initialization, e.g., create an Invocation object, etc. This is not all to do with event nofitication interceptor. But that may be handy.

I second having a startInterceptor and endInterceptor to initialise/clean up stuff in the chain... there have been places in the Optimistic chain where such a framework could have been useful.
Actions
4. Re: TreeCacheListener - introducing new event types design

belaban Aug 26, 2005 6:58 AM (in response to hmesha)

This will only make sense once we have the payload in MethodCall, otherwise what's the benefit ? Just 2 more useless interceptors who clutter up the interceptor chain ? :-)
Actions
5. Re: TreeCacheListener - introducing new event types design

hmesha Aug 26, 2005 2:21 PM (in response to hmesha)

I actually divided the work for now to get what's possible in release 1.2.4, the issue of NotificationInterceptor turned out to be a bigger job than what I originally thought would be. It does actually open the door for major refactor of the notification mechanism as Ben pointed out. I had a conversation with Bela about this and all the concerns raised are included in JBCACHE-270. This issue has been moved to 1.2.5 to give us more time to think about the best approach to the entire notification mechanism. I'll add you suggestions and questions to JBCACHE-270 to consider them when we get to it.

As far as which approach to take, I'm not sure yet.

What I decided to do in 1.2.4 to satisfy immediate requirements and serve as a starting point to the bigger effor in 1.2.5 are:

1. Created ExtendedTreeCacheListener to satisfy JBCACHE-229
2. Added methods nodeActivate(Fqn fqn, boolean pre), nodePassivate(), nodeEvict(), nodeRemove() to satisfy JBCACHE-229, JBCACHE-159
3. Created AbstractTreeCacheListener that implements TreeCacheListener, ExtendedTreeCacheListener to satifsy JBCACHE-87.

Thanks for all your input, keep them coming! :-)

- Hany
Actions

Go to original post