+netconf-dev: On Mon, Oct 23, 2017 at 3:24 PM, Tom Pantelis <[email protected]> wrote:
> On Mon, Oct 23, 2017 at 8:41 AM, Michael Vorburger <[email protected]> > wrote: > >> Hello, >> >> Any idea who would have to do what to precent SFT from (only >> occassionally?!) failing on odl-integration-compatible-with-all due to >> ConflictingModificationAppliedException: Node was created by other >> transaction, as seen on https://logs.opendaylight.o >> rg/releng/jenkins092/infrautils-distribution-check-oxygen/ >> 144/console.log.gz for https://git.opendaylight.org/gerrit/#/c/63466/ ? >> > > It would be nice if the exception included some context like the path. > Does this test install all netconf features? I've seen such sporadic issues > with the callhome feature when it's installed with all the other netconf > features. > > How does SFT even pick this up to fail the test? Log scraping? Or was it > a "caused by" thrown on blueprint startup? > No, no log scraping in SFT.. it must be a "caused by" thrown by a BP constructor.. You can see interesting background on https://logs.opendaylight.org/releng/jenkins092/infrautils-distribution-check-oxygen/144/distribution/features/singles/odl-integration-compatible-with-all/target/surefire-reports/org.opendaylight.odlparent.featuretest.SingleFeatureTest-output.txt.gz ... >From what I gathered, it must be the org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceTopologyAdapter, NB its constructor -> initDeviceData() -> commitTransaction() -> with the onFailure() doing a throw new IllegalStateException() in Futures.addCallback() by MoreExecutors.directExecutor(), right? BTW: Wouldn't that code better be sync and just do a block get() on the Tx? And handle a ConflictingModificationAppliedException with a retry? Also, somehow it feels something in SFT is slightly off somewhere, because ideally really it should show that "IllegalStateException: RemoteDevice{controller-config} Transaction(init) not committed correctly at org.opendaylight.netconf.sal.connect.netconf.sal.NetconfDeviceTopologyAdapter" instead of (only) its "...ConflictingModificationAppliedException..." cause - but I'm struggling to find the wrong getCause in odlparent's bundles-test-lib or features4-test behind this! :-( If you can spot it, please shout so we can fix it and make get a clearer pointer to the offender more directly, next time.
_______________________________________________ controller-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/controller-dev
