Re: [controller-dev] [documentation] Questions about ODL clustering

[Sela, Guy]

So in order to get a snapshot of time 
So could I theoretically do:
* DOMDataReadTransaction.read(YangInstanceIdentifier.EMPTY)
* Get the BI root.
* Extract the BI subtrees from the BI Root
* Convert the BI subtrees to BA subtrees using TPUtils-like code?

Do you think this is the best way to get a snapshot of multiple subtrees? Or is 
there a better solution?

-Original Message-
From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
Sent: Monday, September 19, 2016 2:45 PM
To: Sela, Guy <guy.s...@hpe.com>; Tom Pantelis <tompante...@gmail.com>
Cc: controller-dev <controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

On 09/19/2016 12:20 PM, Sela, Guy wrote:
> Oh I missed the fact you are talking about the new API that returns 
> NormalizedNode (BI).
> I was referring to the old API: 
> org.opendaylight.controller.md.sal.binding.api.ReadOnlyTransaction.rea
> d(..)

Top-level root is not representable in BA because it does not have a model 
hence it does not have a corresponding DataObject.

Bye,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Robert Varga]

On 09/19/2016 11:13 AM, Sela, Guy wrote:
> Do all of them have a joint root? (YangInstanceIdentifier.EMPTY)?

In BI world they do. In BA world they do not.

> Will issuing DOMDataReadTransaction.read(YangInstanceIdentifier.EMPTY) 
> provide me a snapshot of all?
> Sounds like it can't work in a Clustered Data Store, because the reads are 
> not from the local replica.

CDS does recognize the query and assembles the information from all
shards -- otherwise RESTCONF would not work.

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Sela, Guy]

When saying specific data tree I mean like "inventory data model", "topology 
data model", "netvirt data model", etc.
Am I mistakenly using the term "data tree" instead of "sub tree"? 
Do all of them have a joint root? (YangInstanceIdentifier.EMPTY)?

Will issuing DOMDataReadTransaction.read(YangInstanceIdentifier.EMPTY) provide 
me a snapshot of all?
Sounds like it can't work in a Clustered Data Store, because the reads are not 
from the local replica.

-Original Message-
From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
Sent: Monday, September 19, 2016 11:26 AM
To: Sela, Guy <guy.s...@hpe.com>; Tom Pantelis <tompante...@gmail.com>
Cc: controller-dev <controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

On 09/18/2016 02:28 PM, Sela, Guy wrote:
> What I mean is to be able to create a snapshot of the entire state and not 
> only a specific data tree.

Do you by 'specific data tree' mean 'specific subtree'?

We do not guarantee consistency across shards, but you can read all shards by 
issuing a DOMDataReadTransaction.read(YangInstanceIdentifier.EMPTY).

Bye,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Robert Varga]

On 09/18/2016 02:28 PM, Sela, Guy wrote:
> What I mean is to be able to create a snapshot of the entire state and not 
> only a specific data tree.

Do you by 'specific data tree' mean 'specific subtree'?

We do not guarantee consistency across shards, but you can read all
shards by issuing a
DOMDataReadTransaction.read(YangInstanceIdentifier.EMPTY).

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Sela, Guy]

Thanks.
Are there any plans to do something regarding snapshots that resembles Snapshot 
Isolation in a DB?

For example:
https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx

-Original Message-
From: controller-dev-boun...@lists.opendaylight.org 
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
Sent: Sunday, September 18, 2016 1:28 PM
To: Sela, Guy <guy.s...@hpe.com>; Tom Pantelis <tompante...@gmail.com>
Cc: controller-dev <controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

On 09/15/2016 05:17 PM, Sela, Guy wrote:
> ReadOnlyTransaction tx = db.newReadOnlyTransaction();
> 
> CheckedFuture<Optional, ReadFailedException> read1 = 
> tx.read(X, Y)
> 
> CheckedFuture<Optional, ReadFailedException> read2 = 
> tx.read(Z, H)
> 
>  
> 
> read1 and read2 were read from different snapshots?
> 
> Does the answer change if they were invoked on the same/different data 
> trees?
> 

If both reads target the same shard, they will be executed from the same 
snapshot.

Bye,
Robert

___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Robert Varga]

On 09/15/2016 05:17 PM, Sela, Guy wrote:
> ReadOnlyTransaction tx = db.newReadOnlyTransaction();
> 
> CheckedFuture read1 =
> tx.read(X, Y)
> 
> CheckedFuture read2 =
> tx.read(Z, H)
> 
>  
> 
> read1 and read2 were read from different snapshots?
> 
> Does the answer change if they were invoked on the same/different data
> trees?
> 

If both reads target the same shard, they will be executed from the same
snapshot.

Bye,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [documentation] Questions about ODL clustering

[Sela, Guy]

?

From: Sela, Guy
Sent: Thursday, September 15, 2016 6:17 PM
To: 'Tom Pantelis' <tompante...@gmail.com>
Cc: Muthukumaran K <muthukumara...@ericsson.com>; Moiz Raja (moraja) 
<mor...@cisco.com>; Srini Seetharaman <srini.seethara...@gmail.com>; 
controller-dev <controller-dev@lists.opendaylight.org>
Subject: RE: [controller-dev] [documentation] Questions about ODL clustering

ReadOnlyTransaction tx = db.newReadOnlyTransaction();
CheckedFuture<Optional, ReadFailedException> read1 = tx.read(X, Y)
CheckedFuture<Optional, ReadFailedException> read2 = tx.read(Z, H)

read1 and read2 were read from different snapshots?
Does the answer change if they were invoked on the same/different data trees?
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Thursday, September 15, 2016 6:13 PM
To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>
Cc: Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Moiz Raja 
(moraja) <mor...@cisco.com<mailto:mor...@cisco.com>>; Srini Seetharaman 
<srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>>; 
controller-dev 
<controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>
Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

Not sure I follow your exact meaning but the snapshot isn't retaken on every 
read operation for a transaction. After opening a transaction, the first read 
operation to a shard will take the snapshot and read from it The second read 
operation to that shard will also read from it. If you open another 
transaction, that will take another snapshot.

On Thu, Sep 15, 2016 at 10:57 AM, Sela, Guy 
<guy.s...@hpe.com<mailto:guy.s...@hpe.com>> wrote:
Understood, so this means there is no way to get a snapshot of the entire 
MD-SAL state, even in a single instance deployment, because the snapshot is 
retaken on every read operation. Correct?

From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>]
Sent: Thursday, September 15, 2016 4:29 PM
To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>
Cc: Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Moiz Raja 
(moraja) <mor...@cisco.com<mailto:mor...@cisco.com>>; Srini Seetharaman 
<srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>>; 
controller-dev 
<controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>

Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

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<mailto: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>
 
[mailto: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<mailto:mor...@cisco.com>>; Tom 
Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>; Srini 
Seetharaman <srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>>
Cc: controller

Re: [controller-dev] [documentation] Questions about ODL clustering

[Sela, Guy]

ReadOnlyTransaction tx = db.newReadOnlyTransaction();
CheckedFuture<Optional, ReadFailedException> read1 = tx.read(X, Y)
CheckedFuture<Optional, ReadFailedException> read2 = tx.read(Z, H)

read1 and read2 were read from different snapshots?
Does the answer change if they were invoked on the same/different data trees?
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Thursday, September 15, 2016 6:13 PM
To: Sela, Guy <guy.s...@hpe.com>
Cc: Muthukumaran K <muthukumara...@ericsson.com>; Moiz Raja (moraja) 
<mor...@cisco.com>; Srini Seetharaman <srini.seethara...@gmail.com>; 
controller-dev <controller-dev@lists.opendaylight.org>
Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

Not sure I follow your exact meaning but the snapshot isn't retaken on every 
read operation for a transaction. After opening a transaction, the first read 
operation to a shard will take the snapshot and read from it The second read 
operation to that shard will also read from it. If you open another 
transaction, that will take another snapshot.

On Thu, Sep 15, 2016 at 10:57 AM, Sela, Guy 
<guy.s...@hpe.com<mailto:guy.s...@hpe.com>> wrote:
Understood, so this means there is no way to get a snapshot of the entire 
MD-SAL state, even in a single instance deployment, because the snapshot is 
retaken on every read operation. Correct?

From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>]
Sent: Thursday, September 15, 2016 4:29 PM
To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>
Cc: Muthukumaran K 
<muthukumara...@ericsson.com<mailto:muthukumara...@ericsson.com>>; Moiz Raja 
(moraja) <mor...@cisco.com<mailto:mor...@cisco.com>>; Srini Seetharaman 
<srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>>; 
controller-dev 
<controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>

Subject: Re: [controller-dev] [documentation] Questions about ODL clustering

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<mailto: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>
 
[mailto: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<mailto:mor...@cisco.com>>; Tom 
Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>; Srini 
Seetharaman <srini.seethara...@gmail.com<mailto:srini.seethara...@gmail.com>>
Cc: controller-dev 
<controller-dev@lists.opendaylight.org<mailto: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>
 [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf

Re: [controller-dev] [documentation] Questions about ODL clustering

[Tom Pantelis]

Not sure I follow your exact meaning but the snapshot isn't retaken on
every read operation for a transaction. After opening a transaction, the
first read operation to a shard will take the snapshot and read from it The
second read operation to that shard will also read from it. If you open
another transaction, that will take another snapshot.

On Thu, Sep 15, 2016 at 10:57 AM, Sela, Guy <guy.s...@hpe.com> wrote:

> Understood, so this means there is no way to get a snapshot of the entire
> MD-SAL state, even in a single instance deployment, because the snapshot is
> *retaken* on every read operation. Correct?
>
>
>
> *From:* Tom Pantelis [mailto:tompante...@gmail.com]
> *Sent:* Thursday, September 15, 2016 4:29 PM
> *To:* Sela, Guy <guy.s...@hpe.com>
> *Cc:* Muthukumaran K <muthukumara...@ericsson.com>; Moiz Raja (moraja) <
> mor...@cisco.com>; Srini Seetharaman <srini.seethara...@gmail.com>;
> controller-dev <controller-dev@lists.opendaylight.org>
>
> *Subject:* Re: [controller-dev] [documentation] Questions about ODL
> clustering
>
>
>
> 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.
>
&g

Re: [controller-dev] [documentation] Questions about ODL clustering

[Muthukumaran K]

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] 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<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

Re: [controller-dev] [documentation] Questions about ODL clustering

[Moiz Raja (moraja)]

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