The single use ClusteredDataChange/ClusteredDataTreeChange listeners are fine and may perform better than the remote read but if you really have a lot of reads even this mechanism is expensive as there is quite a bit of overhead associated with setting up a listener.
I would recommend that you setup a ClusteredDataTreeChangeListener (for long term use) for the data that you want to constantly read and cache the data in that listener. Then provide a way to read from that cache. -Moiz From: Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> Date: Wednesday, September 14, 2016 at 2:26 PM To: Srini Seetharaman <srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>> Cc: Moiz Raja <mor...@cisco.com<mailto:mor...@cisco.com>>, controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>> Subject: Re: [controller-dev] [documentation] Questions about ODL clustering All reads still go to the leader. There has been an enhancement https://bugs.opendaylight.org/show_bug.cgi?id=2504 open for this but hasn't been implemented. There is an alternative way using a DataTreeChangeListener as Moiz mentioned in the bug. On Wed, Sep 14, 2016 at 4:57 PM, Srini Seetharaman <srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>> wrote: With Beryllium-SR3, I just verified using tcpdump on port 2550 that the data for the read operation at the follower came over the network from the shard leader. Is there any plan with Boron to make it a local read from the replica? On Wed, Sep 14, 2016 at 1:43 PM, Srini Seetharaman <srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>> wrote: Hi Tom and Moiz Is it still the case with Beryllium and Boron that the read transactions from a follower are forwarded to the leader? Thanks Srini. On Sat, Feb 28, 2015 at 8:26 AM, Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> wrote: Colin, Tianzhu Reads are also forwarded to the leader so, yes, remote reads would take longer. With IMDS, reads are actually synchronous so the returned Future is immediate but with CDS, the read is async, whether it's local or not. So it's best to not block on the Future as there will be some latency with CDS, but rather use a Future callback if possible. Tom On Sat, Feb 28, 2015 at 10:42 AM, Colin Dixon <co...@colindixon.com<mailto:co...@colindixon.com>> wrote: I'm cc'ing controller-dev since they will have the authoritative answer. I *think* the answer is that all data is replicated to all nodes in the cluster and so all reads can be local. Only writes have to go to the shard leader, but I could be wrong. Moiz and Tom Pantelis would know more. --Colin On Sat, Feb 28, 2015 at 4:55 AM, 我心永恒 <zhuzhuaiqiqi1...@gmail.com<mailto:zhuzhuaiqiqi1...@gmail.com>> wrote: Dear all, I am studying ODL and have one question: When a consumer launches a read transaction, if I'm not wrong, it has to be forwarded to the primary shard controller. So if this case is possible that the transaction is remote and the consumer has to wait longer since the transaction is not local? Thanks & regards Tianzhu _______________________________________________ documentation mailing list documentat...@lists.opendaylight.org<mailto:documentat...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/documentation _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
