[CONTROLLER-1500] Sporadic YangTextSchemaContextResolver error failing to fully assemble schema context Created: 20/Mar/16  Updated: 19/Oct/17  Resolved: 22/Mar/16

Status: Resolved
Project: controller
Component/s: config
Affects Version/s: Beryllium
Fix Version/s: None

Type: Bug
Reporter: Ryan Goulding Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File karaf.log    
External issue ID: 5563

 Description   

I occasionally see YangTextSchemaContextResolver failures in my log, showing that the schema context failed to fully assemble. I find this strange since the message reports no unsatisfied imports. I have attached a karaf.log that demonstrates one such run.

This seems like a race condition in the way config provider models are loaded from first glance.



 Comments   
Comment by Ryan Goulding [ 20/Mar/16 ]

Attachment karaf.log has been added with description: karaf.log showing spoaradic YangTextSchemaContextResolver failure

Comment by Ryan Goulding [ 20/Mar/16 ]

I will also add that the controller fails to come up in a reasonable amount of time when this error is observed. It doesn't seem harmless.

Comment by Ryan Goulding [ 20/Mar/16 ]

I will clarify:

I will also add that the controller fails to come up at all. We waited over 15 minutes and still didn't see it come up.

Comment by Tony Tkacik [ 22/Mar/16 ]

TLDR:
Seems your JVM is corrupted, please use Java 8.

Root stacktrace is

Caused by: java.lang.NullPointerException
at java.util.HashMap.inflateTable(HashMap.java:315)[:1.7.0_95]
at java.util.HashMap.<init>(HashMap.java:296)[:1.7.0_95]
at com.google.common.collect.Maps.difference(Maps.java:416)
at com.google.common.collect.Maps.difference(Maps.java:387)
at org.opendaylight.yangtools.yang.parser.spi.SubstatementValidator.validate(SubstatementValidator.java:113)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.ValueStatementImpl$Definition.onFullDefinitionDeclared(ValueStatementImpl.java:65)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.StatementDefinitionContext.onDeclarationFinished(StatementDefinitionContext.java:61)

Looking through our code
https://github.com/opendaylight/yangtools/blob/c652590993b1e4660d5d557868665dbfa634ed27/yang/yang-parser-impl/src/main/java/org/opendaylight/yangtools/yang/parser/spi/SubstatementValidator.java#L113

we never pass NULL value to Maps.difference, Guava also does not pass NULL
to HashMap constructor.

If you look into HashMap from 1.7.0_95 and offending method inflateTable - http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/3a74fee9ba00/src/share/classes/java/util/HashMap.java

you could see there is no way that at offending place NULL value could be available.

Comment by Tom Pantelis [ 22/Mar/16 ]

I agree with Tony. I had looked at the YangTextSchemaContextResolver and it never passes a null Map. It seems that java 7u79 has a bug. I could not find the source for u79 but in an earlier update line 315 didn't match up and I didn't see where HashMap.inflateTable could generate an NPE.

Java 8 re-implemented the HashMap ctor and removed the inflateTable method.

Comment by Tom Pantelis [ 22/Mar/16 ]

Sorry it was 7u95 and I see Tony did find the source. Line 315 should not generate an NPE.

Comment by Ryan Goulding [ 22/Mar/16 ]

This was seen on internal CI system w/o doing 'apt-get dist-upgrade' so it was likely due to really old linux distro with latest/greatest JRE. I have reported back to our internal team and I am fine resolving this, as it seems to have been caused by environmental issues.

Generated at Wed Feb 07 19:55:42 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.