[controller-dev] Issues when using AbstractDataBrokerTest
Hi,
I am extending the AbstractDataBrokerTest for writing my unit TCs. As part of
AbstractDataBrokerTest -> setupWithSchema(), DataBrokerTestCustomizer is
instantiated where the SchemaContext is being registered with the
SchemaService. But the SchemaContext is always null. Is there any issues in the
org.opendaylight.controller.md.sal.binding.test.DataBrokerTestCustomizer ? I am
using Boron SR3 release
public class AbstractDataBrokerTest extends AbstractSchemaAwareTest {
private DataBrokerTestCustomizer testCustomizer;
private DataBroker dataBroker;
private DOMDataBroker domBroker;
@Override
protected void setupWithSchema(final SchemaContext context) {
testCustomizer = createDataBrokerTestCustomizer();
dataBroker = testCustomizer.createDataBroker();
...
...
...
}
}
public class DataBrokerTestCustomizer {
private DOMDataBroker domDataBroker;
private final DOMNotificationRouter domNotificationRouter;
private final MockSchemaService schemaService;
...
public DataBrokerTestCustomizer() {
schemaService = new MockSchemaService();
final ClassPool pool = ClassPool.getDefault();
final DataObjectSerializerGenerator generator =
StreamWriterGenerator.create(JavassistUtils.forClassPool(pool));
final BindingNormalizedNodeCodecRegistry codecRegistry = new
BindingNormalizedNodeCodecRegistry(generator);
final GeneratedClassLoadingStrategy loading =
GeneratedClassLoadingStrategy.getTCCLClassLoadingStrategy();
bindingToNormalized = new BindingToNormalizedNodeCodec(loading,
codecRegistry);
schemaService.registerSchemaContextListener(bindingToNormalized);
}
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] List element cohort validation causes issue
Thanks Tom -Satish From: Tom Pantelis Sent: Sunday, March 11, 2018 9:09 AM To: Satish Dutt Cc: controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] List element cohort validation causes issue On Sat, Mar 10, 2018 at 11:53 AM, Satish Dutt mailto:sd...@advaoptical.com>> wrote: Hi All, I have a cohort validation for the list element. If I try to create the entire list having multiple items, I am getting the below error. If I try to create a single list element, then its successful. Is there any way I can avoid this issue. I am trying this in Boron-SR3 2018-03-07 14:53:01,681 | ERROR | ult-dispatcher-4 | OneForOneStrategy | 153 - com.typesafe.akka.slf4j - 2.4.7 | Unexpected message class org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in cohort behavior PostCanCommit java.lang.UnsupportedOperationException: Unexpected message class org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in cohort behavior PostCanCommit at org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CohortBehaviour.handle(DataTreeCohortActor.java:152)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3] at org.opendaylight.controller.cluster.datastore.DataTreeCohortActor.handleReceive(DataTreeCohortActor.java:45)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3] at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[164:org.opendaylight.controller.sal-clustering-commons:1.4.3.Boron-SR3] at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.Actor$class.aroundReceive(Actor.scala:484)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.ActorCell.invoke(ActorCell.scala:495)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.run(Mailbox.scala:224)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.exec(Mailbox.scala:234)[152:com.typesafe.akka.actor:2.4.7] at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] This was fixed by https://git.opendaylight.org/gerrit/#/c/51584/ which is in Nitrogen. Regards -Satish ___ 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
[controller-dev] List element cohort validation causes issue
Hi All, I have a cohort validation for the list element. If I try to create the entire list having multiple items, I am getting the below error. If I try to create a single list element, then its successful. Is there any way I can avoid this issue. I am trying this in Boron-SR3 2018-03-07 14:53:01,681 | ERROR | ult-dispatcher-4 | OneForOneStrategy | 153 - com.typesafe.akka.slf4j - 2.4.7 | Unexpected message class org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in cohort behavior PostCanCommit java.lang.UnsupportedOperationException: Unexpected message class org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CanCommit in cohort behavior PostCanCommit at org.opendaylight.controller.cluster.datastore.DataTreeCohortActor$CohortBehaviour.handle(DataTreeCohortActor.java:152)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3] at org.opendaylight.controller.cluster.datastore.DataTreeCohortActor.handleReceive(DataTreeCohortActor.java:45)[170:org.opendaylight.controller.sal-distributed-datastore:1.4.3.Boron-SR3] at org.opendaylight.controller.cluster.common.actor.AbstractUntypedActor.onReceive(AbstractUntypedActor.java:26)[164:org.opendaylight.controller.sal-clustering-commons:1.4.3.Boron-SR3] at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse(UntypedActor.scala:165)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.Actor$class.aroundReceive(Actor.scala:484)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.UntypedActor.aroundReceive(UntypedActor.scala:95)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)[152:com.typesafe.akka.actor:2.4.7] at akka.actor.ActorCell.invoke(ActorCell.scala:495)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.run(Mailbox.scala:224)[152:com.typesafe.akka.actor:2.4.7] at akka.dispatch.Mailbox.exec(Mailbox.scala:234)[152:com.typesafe.akka.actor:2.4.7] at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)[148:org.scala-lang.scala-library:2.11.8.v20160304-115712-1706a37eb8] Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] How to get HTTP request details ?
Hi All, Is there any way to know the HTTP request details in any of User-defined Cohort class which extends the DomDataTreeCohort of the package org.opendaylight.mdsal.dom.api package ? Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ?
Hi Anil, I completely agree with your comments. It would be great if the cohort timeout value is configurable as per the UCs requisites. Regards -Satish From: controller-dev-boun...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Anil Vishnoi Sent: Wednesday, May 17, 2017 5:32 AM To: Robert Varga Cc: controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org Subject: Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ? On Tue, May 16, 2017 at 3:05 PM, Robert Varga mailto:n...@hq.sk>> wrote: On 16/05/17 20:40, Anil Vishnoi wrote: > Tom, > > I think it depends on the use case for which user is using cohort. For > example If user have a use case where it sends very few rest request to > the controller from northbound side but want to make sure it runs all > the possible checks against that data to make sure that it can avoid any > wrong configuration (according to the use case and not really as per > yang schema). In general i agree with you that anything that takes more > then 5 second, it's better to probably write that logic in the > application rather than in the cohort, but we don't know all the use > cases people use it for. So i think having a config knob (with default > value to 5 second or lower) will give user an option to change it > (increase or decrease) as per their usecase. Note that this fires for any change in the registered subtree and no other transactions involving that shard can make forward progress until the cohort finishes preCommit(). This API is very strict and should be used only as a last resort at this point. As the associated documentation states very explictly, any bugs in a user of the API has cluster-wide consequences which manifest as 'CDS is broken'. I think it's pretty clear from the documentation. That implies you should not be talking to the data store and expect it to respond in the cohort -- which begs the question: what sort of validation takes more than 5 seconds? I think given the context API sets, even 1 second is a high value, so what kind of transaction can even take 5 seconds, let aside more than 5 second ? For example for my application I might even prefer to use 1 second, but there is no way to configure it as of now. So rather than assuming that no cohort will take more then 5 second, let user decide what value they want to use based on their use case. Bye, Robert -- Thanks Anil ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ?
Thanks Anil. I was able to change the timeout value through the code and its
working fine.
Regards
-Satish
From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Tuesday, May 16, 2017 7:50 AM
To: Michael Vorburger
Cc: Satish Dutt ; controller-dev@lists.opendaylight.org;
mdsal-...@lists.opendaylight.org
Subject: Re: [controller-dev] [mdsal-dev] How to increase the timeout value for
a commit operation to the data store ?
I believe this is where it is set
https://github.com/opendaylight/controller/blob/master/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/ShardDataTree.java#L106
Not sure if there is any way to configure it though any akka/cluster config
knob.
On Mon, May 15, 2017 at 8:23 AM, Michael Vorburger
mailto:vorbur...@redhat.com>> wrote:
On Mon, May 15, 2017 at 5:06 PM, Satish Dutt
mailto:sd...@advaoptical.com>> wrote:
Hi Michael,
Thanks for your response. I am writing a custom cohort class for some
validation purpose, which extends the DOMDataTreeCommitCohort of the
mdsal.dom.api package and overrides the canCommit(). canCommit() in my cohort
does some validations and just return a Future object indicating success or
failure. I am NOT actually timing out the Future . Sometimes my cohort class
takes more than 5 seconds to execute and the MDSAL commit times-out.
Oh you didn't specify that in your first email... sorry, I don't know anything
more about this; maybe others will chime in.
I suspect that some classes in MDSAL are probably timing out the commit,
since it is exceeding the default timeout value of 5 seconds. But in my
application, I can wait for more than 5 seconds possibly around 20 seconds for
doing the validation. For this I want to know the code of the MDSAL which I can
tweak for setting a higher timeout value and use that code locally in my
application.
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure",
"error-info": "java.util.concurrent.TimeoutException: Futures timed out
after [5 seconds]\n\tat
scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)\n\tat
scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)\n\tat
scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)\n\tat
akka.dispatch.MonitorableThreadFactory$AkkaForkJoinWorkerThread$$anon$3.block(ThreadPoolBuilder.scala:167)\n\tat
scala.concurrent.forkjoin.ForkJoinPool.managedBlock(ForkJoinPool.java:3640)\n\tat
akka.dispatch.MonitorableThreadFactory$AkkaForkJoinWorkerThread.blockOn(ThreadPoolBuilder.scala:165)\n\tat
scala.concurrent.Await$.result(package.scala:190)\n\tat
scala.concurrent.Await.result(package.scala)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CompositeDataTreeCohort.processResponses(CompositeDataTreeCohort.java:162)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CompositeDataTreeCohort.canCommit(CompositeDataTreeCohort.java:122)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.userPreCommit(SimpleShardDataTreeCohort.java:162)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardDataTree.startPreCommit(ShardDataTree.java:584)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.preCommit(SimpleShardDataTreeCohort.java:91)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.CohortEntry.pr<http://uster.datastore.CohortEntry.pr>eCommit(CohortEntry.java:102)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator.doCommit(ShardCommitCoordinator.java:296)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator.access$200(ShardCommitCoordinator.java:49)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator$2.onSuccess(ShardCommitCoordinator.java:243)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardCommitCoordinator$2.onSuccess(ShardCommitCoordinator.java:237)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.SimpleShardDataTreeCohort.successfulCanCommit(SimpleShardDataTreeCohort.java:145)\n\tat
org.opendaylight.controller.cl<http://org.opendaylight.controller.cl>uster.datastore.ShardDataTree.processNextTransaction(ShardDataTree.java:526)\n\tat
org.opendaylight.co
Re: [controller-dev] [mdsal-dev] How to increase the timeout value for a commit operation to the data store ?
)\n\tat
akka.persistence.UntypedPersistentActor.aroundReceive(PersistentActor.scala:168)\n\tat
akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)\n\tat
akka.actor.ActorCell.invoke(ActorCell.scala:495)\n\tat
akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)\n\tat
akka.dispatch.Mailbox.run(Mailbox.scala:224)\n\tat
akka.dispatch.Mailbox.exec(Mailbox.scala:234)\n\tat
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)\n\tat
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)\n\tat
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)\n\tat
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)\n"
}
]
}
}
Regards
-Satish
From: Michael Vorburger [mailto:vorbur...@redhat.com]
Sent: Monday, May 15, 2017 8:10 PM
To: Satish Dutt
Cc: mdsal-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Subject: Re: [mdsal-dev] How to increase the timeout value for a commit
operation to the data store ?
Satish,
On Mon, May 15, 2017 at 2:26 PM, Satish Dutt
mailto:sd...@advaoptical.com>> wrote:
Hi,
Is there any way to increase the timeout value for a commit operation to the
datastore ? Sometimes I get timeout value during the commit operation
AFAIK, the 5s timeout you're experience below from a commit to the datastore is
probably not coming from mdsal (controller) code itself, but from something
using it .. if I were you I would look more at the code doing the commit - it
receives a Future in return, and some code in your application is probably
timing out on that Future - could that be?hh
Tx,
M.
--
Michael Vorburger, Red Hat
vorbur...@redhat.com<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode |
~ = http://vorburger.ch<http://vorburger.ch/>
{
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure",
"error-info": "java.util.concurrent.TimeoutException: Futures timed out
after [5 seconds]\n\tat
scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)\n\tat
…
…
…
akka.dispatch.Mailbox.exec(Mailbox.scala:234)\n\tat
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)\n\tat
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)\n\tat
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)\n\tat
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)\n"
}
]
}
}
Regards
-Satish
___
mdsal-dev mailing list
mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/mdsal-dev
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] How to increase the timeout value for a commit operation to the data store ?
Hi,
Is there any way to increase the timeout value for a commit operation to the
datastore ? Sometimes I get timeout value during the commit operation
{
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure",
"error-info": "java.util.concurrent.TimeoutException: Futures timed out
after [5 seconds]\n\tat
scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)\n\tat
...
...
...
akka.dispatch.Mailbox.exec(Mailbox.scala:234)\n\tat
scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)\n\tat
scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)\n\tat
scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)\n\tat
scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)\n"
}
]
}
}
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] PATCH response not having the error details
Hi,
I am using yang-patch to modify some of the leaf node values. But whenever the
PATCH request fails, it is not giving the cause of the failure unlike the POST
or PUT methods, but just gives an one-liner error that "canCommit encountered
an unexpected failure". Is there any way in which the PATCH response can give
the details regarding the failure ?
In the below example I am trying to modify one of the attribute leaf node
'hostname' value of a non-existing list node "12' . Ideally it is expected that
it PATCH should report the data does not exist for the node 12, but it is
reporting "canCommit encountered an unexpected failure". How to make the PATCH
response to have more details in the error message ?
GET : http://{{ipaddr}}:8181/restconf/config/connector-config:connectors
{
"connectors": {
"connector": [
{
"uid": "7",
"mgmt-ip": "1.1.1.1",
"hostname": "onus.org"
}
]
}
}
PATCH request :
http://{{ipaddr}}:8181/restconf/config/connector-config:connectors
{"ietf-restconf:yang-patch" : {
"patch-id" : "0",
"edit" :[
{
"edit-id" : "edit1",
"operation" : "merge",
"target" : "/connector-config:connector[connector-config:uid ='12']",
"value": {
"connector" : {
"uid":"12",
"hostname": "opendaylight.org"
}
}
}
]
}
}
PATCH response :
{
"ietf-yang-patch:yang-patch-status": {
"patch-id": "0",
"errors": {
"error": [
{
"error-type": "application",
"error-tag": "operation-failed",
"error-message": "canCommit encountered an unexpected failure"
}
]
},
"edit-status": {
"edit": [
{
"edit-id": "edit1",
"ok": [
null
]
}
]
}
}
}
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Timeout value of Cohert methods
Hi Tomas, Currently the canCommit() of DomDataTreeCohert will timeout in 5 seconds. How can this timeout value be increased ? Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Cohert not getting triggered for augmented nodes
Hi Tomas,
I am writing a Cohert trying to validate a subtree data, which is augmented to
a target node in the same module. For registering the cohert, I am creating an
instance of the same and also the DomDataTreeIdentifier by using the
YangInstanceIdentifier instance having the sub-tree path. Registration does not
throw any exception, but the canCommit() of my cohert is not triggered whenever
I push the JSON data to the sub-tree. I have put below the yang and the code
snippets. Is the way of registering the subtree for the the Cohert validations
wrong in my case ? Please advise.
container controller {
}
module connector-config {
...
...
container controller {
}
/*
* Augumented -> controllerconfig management model
*/
augment "/controller" {
ext:augment-identifier ControllerMgmtAugmentation;
container controller-common-mgmt {
config true;
list tenant {
key id;
leaf id {
type string;
description "ID of tenant";
mandatory true;
}
Description "Tenant details";
uses controller-common-group;
}
}
}
...
...
}
@Override
public synchronized Future> registerCommitCohort() {
...
...
final YangInstanceIdentifier connectorConfigPath =
YangInstanceIdentifier.builder(
YangInstanceIdentifier.of(Controller.QNAME)).node(ControllerCommonMgmt.QNAME).
node(Tenant.QNAME).node(Tenant.QNAME).build();
commitCohortReg.set(commitCohortRegistry.registerCommitCohort(
new org.opendaylight.mdsal.dom.api.DOMDataTreeIdentifier(
org.opendaylight.mdsal.common.api.LogicalDatastoreType.CONFIGURATION,
connectorConfigPath), new
ConnectorDataTreeCommitCohort(domDataBroker, dataProvider)));
return RpcResultBuilder.success().buildFuture();
}
Regards,
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] IncorrectNestingException when writing to an augmented data-tree
Hi,
I have created a project using boron-SR3 archetype. In one of the yang I have
augmented a container. In the code (File3.java) I am trying to write the data
to that container to the DataStore, but I am getting IncorrectNestingException
exception. The same code is working fine in the boron stable project. Below
are the yang and code snippets. So is this a bug in the boron-SR3 ?
File1.yang :
module test-controller {
yang-version 1;
namespace "http://www.test.com/controllerconfiguration/core";;
prefix "testconfig";
description "";
revision "2016-09-22" {
description "Initial revision of model";
}
container controller {
}
}
File2.yang :
module device-config {
yang-version 1;
namespace
"urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:device-config";
prefix "deviceconfig";
import test-controller { prefix testconfig; revision-date 2016-09-22; }
import yang-ext { prefix ext; }
import ietf-inet-types { prefix "inet-types"; revision-date 2013-07-15; }
revision "2016-09-28" {
description "Initial revision of connector configuration model";
}
grouping controller-common-group {
container version-info {
leaf version {
type string;
mandatory true;
description
"Controller version.";
}
}
}
/*
* Augumented
*/
augment "/testconfig:controller" {
ext:augment-identifier ControllerMgmtAugmentation;
container controller-common-mgmt {
config false;
description
"Controller version";
uses controller-common-group;
}
}
}
File3.java :
VersionInfoBuilder versionInfoBuilder = new VersionInfoBuilder();
versionInfoBuilder.setVersion("17.1.1.1");
InstanceIdentifier in =
InstanceIdentifier.create(Controller.class)
.augmentation(ControllerMgmtAugmentation.class).child(ControllerCommonMgmt.class)
.child(VersionInfo.class);
WriteTransaction writeTranaction = dataBroker.newWriteOnlyTransaction();
writeTranaction.merge(LogicalDatastoreType.OPERATIONAL, in,
versionInfoBuilder.build(), true);
writeTranaction.submit();
File4.java :
public interface ControllerMgmtAugmentation
extends
DataObject,
Augmentation
{
/**
* Controller version and backup details.
*
*
*
* @return
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal.clustering.it.device.config.rev160928.controller.ControllerCommonMgmt
controllerCommonMgmt, or null if not present
*/
ControllerCommonMgmt getControllerCommonMgmt();
}
LOG Traces :
2017-04-14 17:33:17,565 | ERROR | on-dispatcher-34 |
DataTreeChangeListenerActor | 176 -
org.opendaylight.controller.sal-distributed-datastore - 1.4.3.Boron-SR3 | Error
notify
ing listener
org.opendaylight.controller.md.sal.binding.impl.BindingDOMDataTreeChangeListenerAdapter@85aac52
org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException:
Class interface
org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.controller.config.sal
.clustering.it.device.config.rev160928.ControllerMgmtAugmentation is not valid
child of interface
org.opendaylight.yang.gen.v1.http.www.test.com.controllerconfiguration.core.rev160
922.Controller
at
org.opendaylight.yangtools.binding.data.codec.impl.IncorrectNestingException.create(IncorrectNestingException.java:28)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.
Boron-SR3]
at
org.opendaylight.yangtools.binding.data.codec.impl.DataContainerCodecContext.childNonNull(DataContainerCodecContext.java:180)[74:org.opendaylight.mdsal.binding-dom-codec
:0.9.3.Boron-SR3]
at
org.opendaylight.yangtools.binding.data.codec.impl.DataObjectCodecContext.bindingPathArgumentChild(DataObjectCodecContext.java:184)[74:org.opendaylight.mdsal.binding-dom
-codec:0.9.3.Boron-SR3]
at
org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.getCodecContextNode(BindingCodecContext.java:127)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.
3.Boron-SR3]
at
org.opendaylight.yangtools.binding.data.codec.impl.BindingCodecContext.newWriter(BindingCodecContext.java:104)[74:org.opendaylight.mdsal.binding-dom-codec:0.9.3.Boron-SR
3]
at
org.opendaylight.yangtools.binding.data.codec.impl.BindingNormalizedNodeCodecRegistry.toNormalizedNode(BindingNormalizedNodeCodecRegistry.java:102)[74:org.opendaylight.m
dsal.binding-dom-codec:0.9.3.Boron-SR3]
at
org.opendaylight.controller.md.sal.binding.impl.BindingToNormalizedNodeCodec.toNormalizedNode(BindingToNormalizedNodeCodec.java:135)[146:org.opendaylight.controller.sal-
binding-broker-impl:1.4.3.Boron-SR3]
at
org.opendaylight.controller.md.sal.binding.impl.AbstractWriteTransaction.merge(A
Re: [controller-dev] Getting RPC error when registering my cohert
Thanks for the clarification. Is there any way we can set the response code in
the canCommit() method of the cohert in case of failure ?
Regards,
-Satish
From: Tom Pantelis [mailto:tompante...@gmail.com]
Sent: Monday, April 03, 2017 7:34 PM
To: Satish Dutt
Cc: tpant...@brocade.com; controller-dev@lists.opendaylight.org;
controller-us...@lists.opendaylight.org
Subject: Re: Getting RPC error when registering my cohert
You need Boron SR3. The DOMDataTreeCommitCohortRegistry wasn't advertised prior
to that.
On Sun, Apr 2, 2017 at 8:01 AM, Satish Dutt
mailto:sd...@advaoptical.com>> wrote:
Hi Thomas,
I have taken the example code provided in the CarProvider for registering my
cohert in my provider class. But whenever I am trying to register my cohert, I
am always getting the ” RPC error DOMDataTreeCommitCohortRegistry not found “ .
Below is my code snippet :
@Override
public synchronized Future> registerCommitCohort() {
if (commitCohortReg.get() != null) {
return RpcResultBuilder.success().buildFuture();
}
final DOMDataTreeCommitCohortRegistry commitCohortRegistry =
(DOMDataTreeCommitCohortRegistry)
domDataBroker.getSupportedExtensions().get(DOMDataTreeCommitCohortRegistry.class);
if (commitCohortRegistry == null) {
// Shouldn't happen
return RpcResultBuilder.failed().withError(ErrorType.APPLICATION,
"DOMDataTreeCommitCohortRegistry not found").buildFuture();
}
…
…
}
I am using the mdsal-dom-api-2.1.0-Boron.jar . Is the issue related to the
older jar version being used ?
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Yang default values not being honored
Hi ,
In the below model some of the attributes have the default values. But When I
am pushing the JSON without the default valued attributes to the config data
store, those attributes are not getting populated with the default values and
hence not stored in the CDS. So are the yang default values not honored ? I
tried this by creating a sample project with the carbon project archetype.
container connector-configs {
presence true;
list connector-config {
key uid;
uses connector-config-info;
leaf mgmt-ip {
type inet-types:ipv4-address;
config true;
description "IP address of the connector";
}
leaf netmask {
type inet-types:ipv4-address;
config true;
description "netmask of the connector";
}
leaf tunnel-id {
type uint32 {
range "0..1000";
}
config true;
default 10;
description "Tunnel ID to management tunnel to be created";
}
}
}
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Getting RPC error when registering my cohert
Hi Thomas,
I have taken the example code provided in the CarProvider for registering my
cohert in my provider class. But whenever I am trying to register my cohert, I
am always getting the " RPC error DOMDataTreeCommitCohortRegistry not found " .
Below is my code snippet :
@Override
public synchronized Future> registerCommitCohort() {
if (commitCohortReg.get() != null) {
return RpcResultBuilder.success().buildFuture();
}
final DOMDataTreeCommitCohortRegistry commitCohortRegistry =
(DOMDataTreeCommitCohortRegistry)
domDataBroker.getSupportedExtensions().get(DOMDataTreeCommitCohortRegistry.class);
if (commitCohortRegistry == null) {
// Shouldn't happen
return RpcResultBuilder.failed().withError(ErrorType.APPLICATION,
"DOMDataTreeCommitCohortRegistry not found").buildFuture();
}
...
...
}
I am using the mdsal-dom-api-2.1.0-Boron.jar . Is the issue related to the
older jar version being used ?
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [netconf-dev] Validation hooks when using restconf
Hi Tomas,
You told in the previous mail the below API needs to be overridden in the class
which extends the DOMDataTreeCommitCohort class, for implementing the
validation logic, before storing the data in the datastore.
default CheckedFuture
canCommit(@Nonnull Object txId,
@Nonnull Collection candidates, @Nonnull
SchemaContext ctx) {
}
But I am not able to figure out what needs to be passed for the txID parameter.
I assume it to be transaction ID. But how to get access of that before the
canCommit() can be called ?
Regards
-Satish
From: Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco)
[mailto:tc...@cisco.com]
Sent: Monday, March 20, 2017 8:58 PM
To: Satish Dutt ; controller-dev@lists.opendaylight.org;
controller-us...@lists.opendaylight.org; netconf-...@lists.opendaylight.org
Subject: RE: [netconf-dev] Validation hooks when using restconf
This should be possible by leveraging the DOMDataTreeCommitCohort api's.
https://github.com/opendaylight/mdsal/blob/454903c516e9405ff4a1af6392a31b00c04852fa/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohort.java
https://github.com/opendaylight/mdsal/blob/596b89ec503f56c87d066c00d6550e675eb7cf0c/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohortRegistry.java
Tomas
From:
netconf-dev-boun...@lists.opendaylight.org<mailto:netconf-dev-boun...@lists.opendaylight.org>
[mailto:netconf-dev-boun...@lists.opendaylight.org] On Behalf Of Satish Dutt
Sent: Sunday, March 19, 2017 16:07
To:
controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>;
controller-us...@lists.opendaylight.org<mailto:controller-us...@lists.opendaylight.org>;
netconf-...@lists.opendaylight.org<mailto:netconf-...@lists.opendaylight.org>
Subject: [netconf-dev] Validation hooks when using restconf
Hi,
>From the northbound applications we are using the restconf APIs to push the
>JSON data to the ODL controller. Is there any programming hooks through which
>the JSON data can be validated in the controller before allowing the data to
>be stored in the configuration datastore ?
Regards
Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [netconf-dev] Validation hooks when using restconf
Thanks Tomas From: Tomas Cere -X (tcere - PANTHEON TECHNOLOGIES at Cisco) [mailto:tc...@cisco.com] Sent: Monday, March 20, 2017 8:58 PM To: Satish Dutt ; controller-dev@lists.opendaylight.org; controller-us...@lists.opendaylight.org; netconf-...@lists.opendaylight.org Subject: RE: [netconf-dev] Validation hooks when using restconf This should be possible by leveraging the DOMDataTreeCommitCohort api's. https://github.com/opendaylight/mdsal/blob/454903c516e9405ff4a1af6392a31b00c04852fa/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohort.java https://github.com/opendaylight/mdsal/blob/596b89ec503f56c87d066c00d6550e675eb7cf0c/dom/mdsal-dom-api/src/main/java/org/opendaylight/mdsal/dom/api/DOMDataTreeCommitCohortRegistry.java Tomas From: netconf-dev-boun...@lists.opendaylight.org<mailto:netconf-dev-boun...@lists.opendaylight.org> [mailto:netconf-dev-boun...@lists.opendaylight.org] On Behalf Of Satish Dutt Sent: Sunday, March 19, 2017 16:07 To: controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>; controller-us...@lists.opendaylight.org<mailto:controller-us...@lists.opendaylight.org>; netconf-...@lists.opendaylight.org<mailto:netconf-...@lists.opendaylight.org> Subject: [netconf-dev] Validation hooks when using restconf Hi, >From the northbound applications we are using the restconf APIs to push the >JSON data to the ODL controller. Is there any programming hooks through which >the JSON data can be validated in the controller before allowing the data to >be stored in the configuration datastore ? Regards Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Validation hooks when using restconf
Hi, >From the northbound applications we are using the restconf APIs to push the >JSON data to the ODL controller. Is there any programming hooks through which >the JSON data can be validated in the controller before allowing the data to >be stored in the configuration datastore ? Regards Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] How to refine an attribute present in a container ?
Hi,
I have three groups A, B and C. I am trying to refine the attribute "password"
in grouping C as below :
grouping A {
leaf password {
type string;
description "Password to connect the connector";
}
}
grouping B {
container connector-configs {
uses A;
leaf mgmt-ip {
type inet-types:ipv4-address;
description "IP address of the
connector";
}
}
}
grouping C {
uses B {
refine "password" {
default "password";
}
}
But when I compile I am getting an exception [ERROR] yang-to-sources: Unable
to parse yang files from
C:\workspace\controller\controller\odl\controllerconfiguration\api\src\main\yang
java.lang.IllegalArgumentException: Refine target node Relative{path=[(..]}
not found
>From the error I am able to understand that the path to the attribute is wrong
>when refine statement is used. But how do we refine an attribute which is
>inside a container ?
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] [yangtools-dev] Query regarding the default value of an attribute in yang model
Basically I have two RPC operations :
rpc create-device-config {
input {
uses device-config-info;
}
output {
leaf status {
type string;
description "returns the status
of operation";
}
leaf error-message {
type string;
description "failure message
will be indicated otherwise empty";
}
}
}
rpc update-device-config {
input {
uses device-config-info;
}
output {
leaf status {
type string;
description "returns the status
of operation";
}
leaf error-message {
type string;
description "failure message
will be indicated otherwise empty";
}
}
}
typedef device-type-t {
type enumeration {
enum switch;
enum router;
}
default switch;
}
grouping device-config-info {
list device-config {
key uid;
leaf hostname {
type string;
mandatory true;
description "Host name of the device";
}
leaf device-type {
type device-type-t;
description "Type of the device being
configured";
}
}
Assume this scenario. NBI user invokes the create-device-config and passes UID,
hostname and the device-type attribute value as 'router''. Then the code which
processes the create-device-config stores these values in the datastore. Now
the NBI user just wants to change the hostname. So he invokes the
update-device-config RPC and passes the UID, hostname attribute but does not
pass the device-type attribute . So the UpdateDeviceConfig will have the
device-type attribute value as 'switch' . But I have a validation in the update
processing code which prevents the deviceType not to be changed. But in our
case the NBI user just wants to change the hostname attribute and is not
bothered to change the device type. So how can I determine in the update case
that the device-type attribute is not injected by the yang so that I can
validate. OR is there any other way in which I can proceed ?
Regards
-Satish
-Original Message-----
From: Robert Varga [mailto:n...@hq.sk]
Sent: Monday, March 13, 2017 5:11 PM
To: Satish Dutt ; yang-push-...@lists.opendaylight.org;
yangtools-us...@lists.opendaylight.org; yangtools-...@lists.opendaylight.org;
controller-us...@lists.opendaylight.org; controller-dev@lists.opendaylight.org
Subject: Re: [yangtools-dev] Query regarding the default value of an attribute
in yang model
On 03/13/2017 12:25 PM, Satish Dutt wrote:
> *_Is there any way in the Java code which processes the RPC request.
> to know if the 'device-type' value was passed by the NBI user or the
> default value auto-injected by the yang ?_*
Depends on what 'Java code' means.
Binding-Independent APIs do not inject default values, as the applications are
expected to have a SchemaContext available and hence can look up the value.
This is appropriate for data funneling type of applications expected at this
layer.
Binding-Aware APIs inject the default value as the applications do not have a
means to look them up and should not care about the source of the date -- the
semantics is the same. This is appropriate for model-specific applications,
which bind to model semantics.
Why would you need to differentiate between the two?
Regards,
Robert
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Query regarding the default value of an attribute in yang model
Hi,
In one of the modules I have defined a enum device-type-t with a default value
as 'switch' and then have a grouping which defines a leaf attribute of the enum
device-type-t
typedef device-type-t {
type enumeration {
enum switch;
enum router;
}
default switch;
}
grouping device-config-info {
list device-config {
key uid;
leaf hostname {
type string;
mandatory true;
description "Host name of the device";
}
leaf device-type {
type device-type-t;
description "Type of the device being
configured";
}
}
rpc create-device-config {
input {
uses device-config-info;
}
output {
leaf status {
type string;
description "returns the status
of operation";
}
leaf error-message {
type string;
description "failure message
will be indicated otherwise empty";
}
}
}
Now if the NBI user creates device config using the RPC create-device-config
but does not pass the device-type attribute. So the yang will inject the
default value of switch for the device-type attribute in the Java object. Is
there any way in the Java code which processes the RPC request. to know if the
'device-type' value was passed by the NBI user or the default value
auto-injected by the yang ?
Regards
-Satish
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Re: [controller-dev] Getting exception when using Transaction Chain
Yes Tom, we are accessing a chain concurrently. Is there any waiting mechanism provided by the transaction chain such that the transaction chain waits for allocating a new one till the previous write transaction is submitted ? Regards -Satish From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Tuesday, March 07, 2017 2:38 AM To: Satish Dutt Cc: Robert Varga ; controller-us...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] Getting exception when using Transaction Chain It seems you're trying to access a chain concurrently? If so, this is not supported. You must coordinate access to the chain such that the previous write transaction is submitted before you allocate a new one. Tom On Mon, Mar 6, 2017 at 7:05 AM, Satish Dutt mailto:sd...@advaoptical.com>> wrote: Thanks Robert for the clarification. So to solve the issue, can I handle this IllegalStateException and retry the read or write operations for a finite number of times, which makes the best effort of previous write-capable transactions to get completed. Or is there a more elegant way of solving this issue ? Regards -Satish -Original Message- From: Robert Varga [mailto:n...@hq.sk<mailto:n...@hq.sk>] Sent: Monday, March 06, 2017 5:23 PM To: Satish Dutt mailto:sd...@advaoptical.com>>; controller-us...@lists.opendaylight.org<mailto:controller-us...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> Subject: Re: [controller-dev] Getting exception when using Transaction Chain On 03/06/2017 12:39 PM, Satish Dutt wrote: > When multiple requests are sent concurrently, IllegalStateException is > thrown. Is there any way to solve this issue, apart from synchronizing > the method which does the above operations ? This is actually part of the API contract: https://github.com/opendaylight/controller/blob/a81d98f692b80c45bce3fe6a87e731abfb012a9f/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java#L59 The reason is very simple: if there is a write-capable transaction open and it has seen some modifications, does the second transaction observe those modifications as applied or as unapplied? Bye, Robert ___ 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] Getting exception when using Transaction Chain
Thanks Robert for the clarification. So to solve the issue, can I handle this IllegalStateException and retry the read or write operations for a finite number of times, which makes the best effort of previous write-capable transactions to get completed. Or is there a more elegant way of solving this issue ? Regards -Satish -Original Message- From: Robert Varga [mailto:n...@hq.sk] Sent: Monday, March 06, 2017 5:23 PM To: Satish Dutt ; controller-us...@lists.opendaylight.org; controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] Getting exception when using Transaction Chain On 03/06/2017 12:39 PM, Satish Dutt wrote: > When multiple requests are sent concurrently, IllegalStateException is > thrown. Is there any way to solve this issue, apart from synchronizing > the method which does the above operations ? This is actually part of the API contract: https://github.com/opendaylight/controller/blob/a81d98f692b80c45bce3fe6a87e731abfb012a9f/opendaylight/md-sal/sal-common-api/src/main/java/org/opendaylight/controller/md/sal/common/api/data/TransactionChain.java#L59 The reason is very simple: if there is a write-capable transaction open and it has seen some modifications, does the second transaction observe those modifications as applied or as unapplied? Bye, Robert ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Getting exception when using Transaction Chain
Hi,
In a method we are creating a new instance of ReadOnlyTransaction and
WriteTransaction from the transaction chain and subsequently doing the read and
write operations on the datastore. When multiple requests are sent
concurrently, IllegalStateException is thrown. Is there any way to solve this
issue, apart from synchronizing the method which does the above operations ?
Method pseudocode :
doSomeTask(BindingTransactionChain txnChain) {
1) final WriteTransaction writeTxn =
txnChain.newWriteOnlyTransaction();
2) final ReadOnlyTransaction readTxn =
txnChain.newReadOnlyTransaction();
3) Read the data and close the transaction readTxn.close()
4) Write the data.
}
Exception trace :
java.lang.IllegalStateException: Previous transaction
member-1-datastore-operational-fe-0-chn-3-txn-1018 is not ready yet
at
org.opendaylight.controller.cluster.datastore.TransactionChainProxy$Allocated.checkReady(TransactionChainProxy.java:85)
at
org.opendaylight.controller.cluster.datastore.TransactionChainProxy.allocateWriteTransaction(TransactionChainProxy.java:190)
at
org.opendaylight.controller.cluster.datastore.TransactionChainProxy.newWriteOnlyTransaction(TransactionChainProxy.java:171)
at
org.opendaylight.controller.cluster.databroker.DOMBrokerWriteOnlyTransaction.createTransaction(DOMBrokerWriteOnlyTransaction.java:32)
at
org.opendaylight.controller.cluster.databroker.DOMBrokerWriteOnlyTransaction.createTransaction(DOMBrokerWriteOnlyTransaction.java:16)
at
org.opendaylight.controller.cluster.databroker.AbstractDOMBrokerTransaction.getSubtransaction(AbstractDOMBrokerTransaction.java:57)
at
org.opendaylight.controller.cluster.databroker.AbstractDOMBrokerWriteTransaction.merge(AbstractDOMBrokerWriteTransaction.java:97)
at
org.opendaylight.controller.md.sal.binding.impl.BindingDOMWriteTransactionAdapter.ensureParentsByMerge(BindingDOMWriteTransactionAdapter.java:67)
at
org.opendaylight.controller.md.sal.binding.impl.AbstractWriteTransaction.merge(AbstractWriteTransaction.java:55)
at
com.adva.ensemble.controller.controllerconfiguration.util.NetworkAssignmentHelper.updateManagementIpAddress(NetworkAssignmentHelper.java:234)
at
com.adva.ensemble.controller.controllerconfiguration.util.NetworkResourcePool.offerMgmtIp(NetworkResourcePool.java:79)
at
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.setMgmtIp(ControllerConfigurationUtil.java:936)
at
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.setManagementIp(ControllerConfigurationUtil.java:1343)
at
com.adva.ensemble.controller.controllerconfiguration.util.ControllerConfigurationUtil.processCreateOrUpdate(ControllerConfigurationUtil.java:798)
at
com.adva.ensemble.controller.controllerconfiguration.impl.ConnectorConfigRpcServiceImpl.createConnectorConfig(ConnectorConfigRpcServiceImpl.java:177)
at
org.opendaylight.yangtools.yang.binding.util.RpcMethodInvokerWithInput.invokeOn(RpcMethodInvokerWithInput.java:30)
at
org.opendaylight.yangtools.yang.binding.util.AbstractMappedRpcInvoker.invokeRpc(AbstractMappedRpcInvoker.java:52)
at
org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invoke(BindingDOMRpcImplementationAdapter.java:85)
at
org.opendaylight.controller.md.sal.binding.impl.BindingDOMRpcImplementationAdapter.invokeRpc(BindingDOMRpcImplementationAdapter.java:72)
at
org.opendaylight.controller.md.sal.dom.broker.impl.GlobalDOMRpcRoutingTableEntry.invokeRpc(GlobalDOMRpcRoutingTableEntry.java:39)
at
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRoutingTable.invokeRpc(DOMRpcRoutingTable.java:186)
at
org.opendaylight.controller.md.sal.dom.broker.impl.DOMRpcRouter.invokeRpc(DOMRpcRouter.java:131)
at Proxycf92d5e4_0a26_40ab_b779_fd8b6d8a16b2.invokeRpc(Unknown Source)
at
org.opendaylight.netconf.sal.restconf.impl.BrokerFacade.invokeRpc(BrokerFacade.java:350)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at
org.opendaylight.netconf.sal.restconf.impl.RestconfImpl.invokeRpc(RestconfImpl.java:443)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at
org.opendaylight.netconf.sal.restconf.impl.StatisticsRestconfServiceWrapper.invokeRpc(StatisticsRestconfServiceWrapper.java:82)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at
org.opendaylight.netconf.sal.rest.impl.RestconfCompositeWrapper.invokeRpc(RestconfCompositeWrapper.java:64)[274:org.opendaylight.netconf.sal-rest-connector:1.4.0.Boron]
at sun.reflect.GeneratedMethodAccessor63.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_102]
at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_102]
at
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60
Re: [controller-dev] Shard leader down scenario
Hi Tom, Please correct me if am wrong in understanding the below statement. The CheckedFuture will produce a derived TransactionCommitFailedException indicating there's no leader or it timed out. You have to wait for the CheckedFuture to be completed one way or another. It may take some number of seconds for it to time out (there are retries to wait for a new shard leader) so it's best not to block on the future. : If we introduce a wait mechanism for the CheckedFuture to be completed, how will this be different than using the CheckedFuture.checkedGet(). In either of these cases the caller (main) thread gets blocked. So are any other ways for the main thread to wait for the CheckedFuture to get completed ? Regards, -Satish From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Thursday, February 23, 2017 12:27 AM To: Satish Dutt Cc: controller-dev@lists.opendaylight.org Subject: Re: [controller-dev] Shard leader down scenario On Wed, Feb 22, 2017 at 1:36 PM, Satish Dutt mailto:sd...@advaoptical.com>> wrote: Hi All, We have a 3-node clustered deployment. Code extract : WriteTransaction writeTxn = dataBroker.newWriteOnlyTransaction(); writeTxn.put() CheckedFuture<> checkedFuture = writeTxn.submit() Scenario : 1) Three nodes in the setup N1, N2, N3 2) N3 is the shard leader. 3) All RPC requests from the NBI are sent to N2. 4) First two requests are successful. 5) Before the third request, N3 goes down and there is NO SHARD LEADER 6) Third RPC request is sent to N2 Now will the checkedFuture value be null or error since there is no shard-leader ? Are there any ways to know the shard-leader is down without blocking on the checkedFuture and send an error in the RPC response to the NBI user ? The CheckedFuture will produce a derived TransactionCommitFailedException indicating there's no leader or it timed out. You have to wait for the CheckedFuture to be completed one way or another. It may take some number of seconds for it to time out (there are retries to wait for a new shard leader) so it's best not to block on the future. We are basically hitting this issue while scaling the requests. Regards -Satish ___ 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
[controller-dev] Blocking a transaction in the transaction chain
Hi, I have created two WriteTransactions from a TransactionChain instance. If I block using the checkGet() on checkedFuture after submit on the first transaction, will there be any impacts on the other transaction apart from the performance deterioration ? BindingTransactionChain bindingTransactionChain = dataBroker.createTransactionChain(listener); WriteTransaction writeTxn1 = bindingTransactionChain.newWriteOnlyTransaction(); WriteTransaction writeTxn2 = bindingTransactionChain.newWriteOnlyTransaction(); writeTxn1.put() writeTxn2.put() CheckedFuture<> checkedFuture = writeTxn1.submit() checkedFuture.checkedGet() writeTxn2.submit() Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] Shard leader down scenario
Hi All, We have a 3-node clustered deployment. Code extract : WriteTransaction writeTxn = dataBroker.newWriteOnlyTransaction(); writeTxn.put() CheckedFuture<> checkedFuture = writeTxn.submit() Scenario : 1) Three nodes in the setup N1, N2, N3 2) N3 is the shard leader. 3) All RPC requests from the NBI are sent to N2. 4) First two requests are successful. 5) Before the third request, N3 goes down and there is NO SHARD LEADER 6) Third RPC request is sent to N2 Now will the checkedFuture value be null or error since there is no shard-leader ? Are there any ways to know the shard-leader is down without blocking on the checkedFuture and send an error in the RPC response to the NBI user ? We are basically hitting this issue while scaling the requests. Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
[controller-dev] How to set the execute permission for a shell script
Hi All, I am trying to set the execute permission for one of the script using the maven directive in my project specific pom file like below : org.apache.maven.plugins maven-antrun-plugin prepare-package run After the maven build is completed, I untarred the gz file. But in the scripts folder the test script is still no having the execute permission. Any ideas of how to make the script executable ? Regards -Satish ___ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
