Based on our tests we get DuplicatedYangResourceException error, when we send cmHandle registration using 4 parallel threads.
The issue has two sides.
One is that there was a retry mechanism introduced previously when DuplicatedYangResourceException occured. It seems that this solution was not fully working since it was introduced. The problem is with Backoff handling, because the 5 retries are executed in around 0.1 seconds. Backoff seems not to be working, because there are no waiting between retries even if we try to set different backoff parameters
According to the parameters in the code (see org.onap.cps.spi.impl.CpsModulePersistenceServiceImpl#storeSchemaSetFromModules) the retry attempt should be at least 0.2 seconds and double on each attempt.
@Retryable(value = DuplicatedYangResourceException.class, maxAttempts = 5, backoff = @Backoff(random = true, delay = 200, maxDelay = 2000, multiplier = 2))
This Backoff problem caused no issues before, because even if there was a DuplicatedYangResourceException at the last retry, it did not cause 500 internal server error in cps-rest.
From the following commit this exception is causing 500 internal server error and that makes our discovery procedure failed: