[NETCONF-544] FilesystemSchemaSourceCache sometimes fails tests with: Unable to create cache directory at... Created: 09/May/18  Updated: 06/Aug/18  Resolved: 06/Aug/18

Status: Resolved
Project: netconf
Component/s: None
Affects Version/s: None
Fix Version/s: Fluorine

Type: Bug Priority: Medium
Reporter: Michael Vorburger Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

On https://lists.opendaylight.org/pipermail/yangtools-dev/2017-October/002036.html and https://lists.opendaylight.org/pipermail/netconf-dev/2018-May/001790.html the following problem was reported, but it seems to be a heisenbug occuring only occassionally (because the following mulipatch job went further):

Caused by: java.lang.IllegalArgumentException: Unable to create cache directory at cache/schema
     at com.google.common.base.Preconditions.checkArgument(Preconditions.java:210)
     at org.opendaylight.yangtools.yang.model.repo.util.FilesystemSchemaSourceCache.<init>(FilesystemSchemaSourceCache.java:74)
     at org.opendaylight.netconf.topology.AbstractNetconfTopology.<clinit>(AbstractNetconfTopology.java:147)
     ... 31 more

Looking at https://github.com/opendaylight/yangtools/blob/master/yang/yang-model-util/src/main/java/org/opendaylight/yangtools/yang/model/repo/util/FilesystemSchemaSourceCache.java I've noticed that while the error message says ""Unable to create..." there is actually no storageDirectory.mkdirs() there - perhaps that would help, in some corner case?



 Comments   
Comment by Robert Varga [ 16/May/18 ]
01:23:56.587 Unable to initialize bean callhomeProvider
01:23:56.588 org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to initialize bean callhomeProvider
01:23:56.589 	at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:738)
01:23:56.590 	at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:848)
01:23:56.591 	at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:811)
01:23:56.592 	at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
01:23:56.592 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:23:56.592 	at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
01:23:56.592 	at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
01:23:56.592 	at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
01:23:56.592 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:704)
01:23:56.592 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:410)
01:23:56.592 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:275)
01:23:56.592 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
01:23:56.592 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:23:56.592 	at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
01:23:56.592 	at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
01:23:56.592 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
01:23:56.592 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
01:23:56.592 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
01:23:56.592 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
01:23:56.592 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
01:23:56.592 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
01:23:56.592 	at java.lang.Thread.run(Thread.java:748)
01:23:56.592 Caused by: java.lang.ExceptionInInitializerError
01:23:56.592 	at org.opendaylight.netconf.callhome.mount.CallHomeMountDispatcher.createTopology(CallHomeMountDispatcher.java:95)
01:23:56.592 	at org.opendaylight.netconf.callhome.mount.IetfZeroTouchCallHomeServerProvider.initializeServer(IetfZeroTouchCallHomeServerProvider.java:111)
01:23:56.592 	at org.opendaylight.netconf.callhome.mount.IetfZeroTouchCallHomeServerProvider.init(IetfZeroTouchCallHomeServerProvider.java:77)
01:23:56.592 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
01:23:56.592 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
01:23:56.592 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
01:23:56.595 	at java.lang.reflect.Method.invoke(Method.java:498)
01:23:56.595 	at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:299)
01:23:56.595 	at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:980)
01:23:56.595 	at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:736)
01:23:56.595 	... 21 more
01:23:56.595 Caused by: java.lang.IllegalArgumentException: Unable to create cache directory at cache/schema
01:23:56.595 	at com.google.common.base.Preconditions.checkArgument(Preconditions.java:210)
01:23:56.595 	at org.opendaylight.yangtools.yang.model.repo.util.FilesystemSchemaSourceCache.<init>(FilesystemSchemaSourceCache.java:74)
01:23:56.595 	at org.opendaylight.netconf.topology.AbstractNetconfTopology.<clinit>(AbstractNetconfTopology.java:147)
01:23:56.595 	... 31 more
Comment by Robert Varga [ 16/May/18 ]
        if (!storageDirectory.exists()) {
            checkArgument(storageDirectory.mkdirs(), "Unable to create cache directory at %s", storageDirectory);
        }

is already there – it actually is the source of the exception. Is this perhaps some sort of a race condition? I do not see anything wrong with the yangtools code and it is a library, so perhaps it should be checked out by the netconf team?

Comment by Robert Varga [ 16/May/18 ]

ExceptionInInitializerError is coming from the static initialization of AbstractNetconfTopology, which seems weird.

Comment by Jakub Morvay [ 06/Aug/18 ]

Fix: https://git.opendaylight.org/gerrit/#/c/72775/

Generated at Wed Feb 07 20:15:18 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.