Support for Event-Driven-Architecture.

[thabach]

Hi list

does Infinispan provide some means of allowing one to build an event driven architecture ?

I.e. is there some facility (or plans to provide it, as I could not find anything in the documentation) in registering a collocated listener with a cache node's backing storage data structure, that would be notified in-process ? Something similar to a Coherence Backing Map Listener ?

Cheers, Christian.

[galder.zamarreno]

In Infinispan you can register listeners at the Cache or Cache Manager for local or embedded caches that are clustered or running in single mode: http://community.jboss.org/docs/DOC-14871

Is this not good enough for what you need? If you're talking to a remote cache, remember that remote events have not yet been implemented (https://issues.jboss.org/browse/ISPN-374)

[thabach]

Thanks for your reply, Galder, what I want to achieve is to have some code being executed once per cache item (on the cluster as a whole, running in distribution mode). I guess for such a scenario a custom interceptor rather than a listener would be the perfect fit, or is it ? But how could I limit the code to execute only on the primary node and on none of the secondaries ? (and further on failover how does a secondary learn about becoming primary and possibly reprocess all the cache items it became responsible for and build up an object model in preparation of handling the next events ?)

Is there some documentation on when to use a custom interceptor and on when to use a listener ? I am confused as the 'Listeners and Notifications' page you sent me to reads: "By default, all notifications are dispatched in the same thread that generates the event.", which sure does sound as if the listener was local to the cache node hosting an entry too.....

[galder.zamarreno]

Regardless of interceptor or listeners, you can find out whether your in the primary copy of a key by getting first the distribution manager (http://docs.jboss.org/infinispan/4.2/apidocs/org/infinispan/AdvancedCache.html#getDistributionManager()) and then locate the key. Out of the list returned, you can stick to the first result and that way assume that's your primary location. You can compare that first value with the address of where the code is being executed. I wouldn't get too hanged out on primary secondary. At the end of the day, you'd want only one node to execute some code, you don't really care whether it's primary/secondary as long as one of them only does it.

The thread that caches the key will generate the event in that node, but of course, when that value is replicated, the thread doing the replication in the other nodes will execute the listener in the other nodes. So, if you put a k,v, you'll get callbacks in all nodes involved.

[galder.zamarreno]

Wrt differences between listeners and interceptors. The first are much simpler to implement and the latter requires inner knowledge of infinispan, and so it's only recommended for very advanced usages. So, I'd stick with listeners and if you find any limitations, switch to interceptor.

[thabach]

Ok, lemme re-iterate a bit in order to fully understand what you are saying:

"At the end of the day, you'd want only one node to execute some code, you don't really care whether it's primary/secondary as long as one of them only does it."

Hmmm, not sure, I do care that at any given point in time there is only one node that owns an item. Only this node should get events targeting the item (based on some affinity/colocation key) and "apply" the event on the owned item. This item-owning node (what I was equating with being the primary node) must be the one receiving all the events. It should not be the secondary (the node with the replicated item state) that potentially handles an event, unless the secondary becomes the new primary at some point and takes over the ownership.

Subsequently you add : "but of course, when that value is replicated, the thread doing the replication in the other nodes will execute the listener in the other nodes." which totally confuses me now ... I need to ensure that only the owning node executes code on event arrival and none of the replicated nodes execute event processing code against the replicated item in the secondary on storing a copy/a replica of the event ? Will I thus have to opt for the DistributionManager enquiry in determing if the node executing is the primary node and is that a safe thing to do even in the face of primary/secondary failover ?

Looking forward to your reply, very helpful stuff, thx a lot, Christian.

[galder.zamarreno]

Christian, to understand this fully you're gonna have to check the code, but remember this: There's not such concept of owner of data in Infinispan. The consistent hash algorithm comes up with 1..N nodes where data should live. N is determined by the number of owners/copies you configured. So, you could, if that makes sense in your mind, imagine that the first node is the owner. Or, you could think that the Nth node is the owner. All it matter is that you do it consistently. That's what my comment was about.

To make sure sure only one of the nodes executes the code, your listener will need to have access to the DistributionManager and based on that, decide whether to execute the code or not. All N nodes will get the listener callback though, so up to you to decide whether to execute or not.