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
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org