Reduce ConflictingVersionException log level to debug 47/41847/2
authorSai MarapaReddy <sai.marapareddy@gmail.com>
Thu, 14 Jul 2016 16:50:11 +0000 (09:50 -0700)
committerSai MarapaReddy <sai.marapareddy@gmail.com>
Thu, 14 Jul 2016 18:18:19 +0000 (11:18 -0700)
In general it happens when there is  a ConflictingVersionException,
it retries and if it times out while retrying, it will log the error

The ConflictingVersionException is similar to the OptimisticLockFailuerEx
in the data store, i.e. the current config version is incremented and
recorded at the start of a push and if a second config is pushed before
 the first completes, the version changes and it detects that and
 re-pushes the first config. The CSS pushes one config at a time
 but this can happen during dependency resolution if it finds a
 dependent module that wasn't created yet or its config changed
 and needs to be dynamically recreated. The dependent module is
 pushed which results in a conflicting version. This
 happens with BGP.

Signed-off-by: Sai MarapaReddy <sai.marapareddy@gmail.com>
Author: Sai MarapaReddy <sai.marapareddy@gmail.com>
Change-Id: Ic1d4639625fa54ccc3d54331a960f421ad6fa1dd

opendaylight/config/config-manager-facade-xml/src/main/java/org/opendaylight/controller/config/facade/xml/transactions/TransactionProvider.java

index 716ed79..eebc1ba 100644 (file)
@@ -149,7 +149,7 @@ public class TransactionProvider implements AutoCloseable {
             LOG.warn("Transaction {} failed on {}", taON, validationException.toString());
             throw validationException;
         } catch (ConflictingVersionException e) {
-            LOG.error("Exception while commit of {}, aborting transaction", taON, e);
+            LOG.debug("Exception while commit of {}, aborting transaction", taON, e);
             // clean up
             abortTransaction();
             throw e;