Re: [infinispan-dev] Design of temote event handling in Hot Rod
On Feb 21, 2012, at 5:50 PM, Manik Surtani wrote:
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.
+1, but the question is, how do you define "same client"? This is what I was
getting to with "origin" earlier (a way to identify cache managers). You
can't assume that a client IP to differentiate between different clients cos you could
have multiple Hot Rod clients running independently in a machine.
If you have any other ideas, I'm happy to hear
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,
+1 again, this can very easily done by using the isLocal() call in listeners. I was only
planning to send notifications from the node where the operation is local, which gets
around this issue.
Also, what are your thoughts around batching notifications?
This could be handy to avoid overloading clients as well, but wasn't in my initial
plans.
What might be important at this stage is if we consider batching of notifications to be
important, whether we'd want to embedd it into the protocol, so that an event
notification response could return 1 to N notifications in a single message. This would be
more optimal and should not result in a huge message since values will not be sent over,
only keys if anything.
Otherwise, batching of notifications could be implemented at a later stage using a similar
method to the replication queue. We could even consider using disruptor instead of a
blocking queue...
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache