I assume DataTree X and Y are in different shards. The snapshot of the DataTree in a backend shard is actually taken at the time of the first operation (read, write etc) referencing a path for that shard. Since the newXXXTransaction methods provide no path context, capturing the snapshot at the time of the newXXXTransaction call would entail creating a transaction/snapshot in every shard which would not be efficient.
I think the new DataTreeProducer APIs are designed to overcome this b/c you specify the path on creation of the DataTreeProducer so it knows up front which backend shards will be accessed. On Thu, Sep 15, 2016 at 8:26 AM, Sela, Guy <guy.s...@hpe.com> wrote: > Hi, > > This question and answers raised another question in my head. > > Today when calling DataBroker.newReadTransaction() we are supposed to get > a snaphost of the complete data tree. > > If we are running in a cluster, it means that some shard aren’t led by the > current instance. > > How can the snapshost work? > > > > Let’s say I have 2 instances in the Cluster – ODL X and ODL Y. > > And I have 2 data trees – DataTree X and DataTree Y. Both reside in the > configuration data store. > > > > In ODL X I call DataBroker.newReadTransaction(). > > Up until now I thought it does some kind of a reference to the data in all > MD-SAL, and use some kind of “copy on write”, to handle modifications. > > Now, since I read that the reads are actually invoked in the Leader > instance, I understand this can’t be the case. > > > > If I’ll take the transaction object and do two reads, first read from > DataTree X and second read from DataTree Y, will they be of the same > snapshot? The snapshot that was “created” at the time I called > newReadTransaction()? > > > > > > *From:* controller-dev-boun...@lists.opendaylight.org [mailto: > controller-dev-boun...@lists.opendaylight.org] *On Behalf Of *Muthukumaran > K > *Sent:* Thursday, September 15, 2016 7:29 AM > *To:* Moiz Raja (moraja) <mor...@cisco.com>; Tom Pantelis < > tompante...@gmail.com>; Srini Seetharaman <srini.seethara...@gmail.com> > *Cc:* controller-dev <controller-dev@lists.opendaylight.org> > > *Subject:* Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > Hi Srini, > > > > We have tried the approach what Moiz had mentioned – using CDTCN and > caching data, and it was quite performant in one of our reference > application. You may want to look - https://git.opendaylight.org/ > gerrit/#/c/45131/ > > > > Regards > > Muthu > > > > > > > > *From:* controller-dev-boun...@lists.opendaylight.org [ > mailto:controller-dev-boun...@lists.opendaylight.org > <controller-dev-boun...@lists.opendaylight.org>] *On Behalf Of *Moiz Raja > (moraja) > *Sent:* Thursday, September 15, 2016 3:06 AM > *To:* Tom Pantelis; Srini Seetharaman > *Cc:* controller-dev > *Subject:* Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > 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> > *Date: *Wednesday, September 14, 2016 at 2:26 PM > *To: *Srini Seetharaman <srini.seethara...@gmail.com> > *Cc: *Moiz Raja <mor...@cisco.com>, controller-dev <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> 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> 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> > 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> > 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> 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 > https://lists.opendaylight.org/mailman/listinfo/documentation > > > > > > _______________________________________________ > controller-dev mailing list > 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 > > > > > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
