On 21 Feb 2012, at 16:00, Galder Zamarreño wrote: >> >> For the implementation, I'd be interested in what you have in mind, >> especially from a performance perspective. I'm adding Clebert and Mike in >> cc, since some of the stuff they do is related to such event >> bus/notification/pub-sub models and they may have insights to add. > > So far I've found 2 factors to be important here when it comes to performance: > 1. Avoid remote eventing to have a major impact on consumption of cache > operations. > 2. Avoid swamping clients with too many notifications. > > For 1, I had thought about implementing notification in a sync=false > listener.
Yes, that would be necessary. It should be async on the server side. > For 2, imagine a client that starts a remote cache manager, signs up for > notifications in cache C, and has 50 threads interacting with cache C > concurrently (so, 50 channels are open with the server). I don't want the > server to send back 50 events for each interested cache operation that > happens on the server side. 1 notification should be enough. This is one of > the reasons I want "option #1". Yes, the server definitely needs to be smart enough to identify multiple connections from the same client, and this also needs to be distributed. E.g., if client C is connected to 2 server nodes S1 and S2, we don't want both S1 and S2 to send back the same notification, Also, what are your thoughts around batching notifications? Cheers Manik -- Manik Surtani [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
