Open vorburger opened 5 years ago
There are two problems here:
Caused by: java.lang.ClassCastException: Cannot cast java.lang.RuntimeException to org.opendaylight.mdsal.common.api.TransactionCommitFailedException
... this is because of the big TODOs in org.opendaylight.etcd.ds.impl.EtcdDataStore.commit(DataTreeCandidate) re. error handling; it's done wrong, and should be fixed - but that's "small" problem just affecting reporting.
Caused by: io.etcd.jetcd.shaded.io.grpc.StatusRuntimeException: INVALID_ARGUMENT: etcdserver: too many operations in txn request
this one is much more interesting ... probably related to https://github.com/etcd-io/etcd/issues/4109 - but I don't understand how we're putting too many operations into a TXN...
I'm also struggling to reproduce this in a simple standalone test case (above is in Karaf).
I'm also struggling to reproduce this in a simple standalone test case (above is in Karaf)
Oh I think that this is "just" because IRL there are just a lot more YANG models loaded than in my isolated simple test case ... the karaf.log
has a lot more of these TXN put
than the standalone test:
2019-02-06T21:28:42,669 | INFO | EtcdDB-commitCoordinator-0 | EtcdYangKV | 203 - org.opendaylight.etcd.ds - 0.0.1.SNAPSHOT | -O TXN put: «O·000000010202000D·modules-state·0200·-urn:ietf:params:xml:ns:yang:ietf-yang-library·02000A·2016-06-21» ➠ «·040D»
It DOES reproduce in the opendaylight-etcd/features/odl-etcd-demo-restconf
as well.
According to the documentation, there is a --max-txn-ops
CLI flag, or env variable ETCD_MAX_TXN_OPS
, which default to 128 and could probably be increased...
But the etcd Version: 3.2.16 which I currently have on Fedora 29 doesn't have that flag yet, so I'll need to custom build a more recent one from source. And then the Maven plugin which is used in odl-etcd-demo-restconf would have to support this...
the Maven plugin which is used in odl-etcd-demo-restconf would have to support this...
https://github.com/etcd-io/jetcd/pull/497
https://github.com/vorburger/opendaylight-etcd/compare/issue-8 has WIP re. this but it still fails :sob:
https://github.com/vorburger/opendaylight-etcd/commit/e8c67078368ea0cb2d3328cfd777c71a03bb3b2e has the details why ...
https://github.com/vorburger/opendaylight-etcd/compare/issue-8 has WIP
that branch just reverted the "comment out odl-etcd-demo-restconf" commit (in features/features-etcd/pom.xml
and features/pom.xml
), and then changed the jetcd-launcher-maven-plugin
in features/odl-etcd-demo-restconf/pom.xml
to be:
<artifactId>jetcd-launcher-maven-plugin</artifactId>
<version>0.3.1-SNAPSHOT</version>
<configuration>
<additionalArguments>
<additionalArgument>--max-txn-ops</additionalArgument>
<additionalArgument>1024</additionalArgument>
</additionalArguments>
</configuration>
which requires https://github.com/etcd-io/jetcd/pull/498 (and, in an ideal world, a jetcd 0.3.1 release, so that we don't depend on SNAPSHOT) ... BUT it then causes the old problem mentioned in https://jira.opendaylight.org/browse/AAA-169 to surface again:
Caused by: java.lang.IllegalStateException: There is already a Shiro environment associated with the current ServletContext. Check if you have multiple EnvironmentLoader* definitions in your web.xml!
but unclear to me right now why - somehow AAA is getting init twice?! We solved this old problem, long ago, but it looks like somehow it's back.
@bertrandlow FYI as I'm making progress re. the broken build (re. #5) I'm finding a new problem: