[NETCONF-683] Mountpoints cannot connect due to BaseSchema failing to initialize Created: 11/May/20 Updated: 14/May/20 Resolved: 13/May/20 |
|
| Status: | Resolved |
| Project: | netconf |
| Component/s: | None |
| Affects Version/s: | Aluminium |
| Fix Version/s: | Aluminium |
| Type: | Bug | Priority: | High |
| Reporter: | Tomas Cere | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When creating a mountpoint the connection seems to always fail with:
2020-05-11T11:55:15,686 | WARN | nioEventLoopGroupCloseable-3-1 | AbstractNetconfSessionNegotiator | 272 - org.opendaylight.netconf.netty-util - 1.9.0.SNAPSHOT | An exception occurred during negotiation with null io.netty.channel.ChannelPipelineException: org.opendaylight.netconf.client.NetconfClientSession.handlerAdded() has thrown an exception; removed. at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:624) [bundleFile:4.1.48.Final] at io.netty.channel.DefaultChannelPipeline.replace(DefaultChannelPipeline.java:572) [bundleFile:4.1.48.Final] at io.netty.channel.DefaultChannelPipeline.replace(DefaultChannelPipeline.java:509) [bundleFile:4.1.48.Final] at org.opendaylight.netconf.nettyutil.AbstractNetconfSessionNegotiator.negotiationSuccessful(AbstractNetconfSessionNegotiator.java:283) [bundleFile:?] at org.opendaylight.netconf.client.NetconfClientSessionNegotiator.access$100(NetconfClientSessionNegotiator.java:43) [bundleFile:?] at org.opendaylight.netconf.client.NetconfClientSessionNegotiator$ExiConfirmationInboundHandler.channelRead(NetconfClientSessionNegotiator.java:216) [bundleFile:?] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [bundleFile:4.1.48.Final] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:321) [bundleFile:4.1.48.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:295) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) [bundleFile:4.1.48.Final] at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:321) [bundleFile:4.1.48.Final] at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:295) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:61) [bundleFile:4.1.48.Final] at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:370) [bundleFile:4.1.48.Final] at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) [bundleFile:4.1.48.Final] at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) [bundleFile:4.1.48.Final] at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500) [bundleFile:4.1.48.Final] at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) [bundleFile:4.1.48.Final] at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [bundleFile:4.1.48.Final] at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [bundleFile:4.1.48.Final] at java.lang.Thread.run(Thread.java:834) [?:?] Caused by: java.util.ServiceConfigurationError: org.opendaylight.yangtools.yang.model.parser.api.YangParserFactory: Provider org.opendaylight.yangtools.yang.parser.impl.YangParserFactoryImpl could not be instantiated at java.util.ServiceLoader.fail(ServiceLoader.java:581) ~[?:?] at java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:803) ~[?:?] at java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721) ~[?:?] at java.util.ServiceLoader$3.next(ServiceLoader.java:1394) ~[?:?] at java.util.ServiceLoader.findFirst(ServiceLoader.java:1809) ~[?:?] at org.opendaylight.binding.runtime.spi.ServiceLoaderState$ParserFactory.<clinit>(ServiceLoaderState.java:27) ~[bundleFile:?] at org.opendaylight.binding.runtime.spi.BindingRuntimeHelpers.createEffectiveModel(BindingRuntimeHelpers.java:43) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.BaseSchema.<init>(BaseSchema.java:44) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.BaseSchema.<clinit>(BaseSchema.java:27) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.resolveBaseSchema(NetconfDevice.java:370) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.onRemoteSessionUp(NetconfDevice.java:159) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.onRemoteSessionUp(NetconfDevice.java:85) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onSessionUp(NetconfDeviceCommunicator.java:132) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onSessionUp(NetconfDeviceCommunicator.java:48) ~[bundleFile:?] at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.sessionUp(AbstractNetconfSession.java:101) ~[bundleFile:?] at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handlerAdded(AbstractNetconfSession.java:192) ~[bundleFile:?] at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:971) [bundleFile:4.1.48.Final] at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) [bundleFile:4.1.48.Final] ... 25 more Caused by: java.lang.ExceptionInInitializerError: No YangXPathParserFactory found at org.opendaylight.yangtools.yang.parser.rfc7950.reactor.ServiceLoaderState$XPath.lambda$static$0(ServiceLoaderState.java:32) ~[bundleFile:?] at java.util.Optional.orElseThrow(Optional.java:408) ~[?:?] at org.opendaylight.yangtools.yang.parser.rfc7950.reactor.ServiceLoaderState$XPath.<clinit>(ServiceLoaderState.java:32) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.rfc7950.reactor.RFC7950Reactors.vanillaReactorBuilder(RFC7950Reactors.java:326) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.rfc7950.reactor.RFC7950Reactors.defaultReactorBuilder(RFC7950Reactors.java:289) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.impl.DefaultReactors.defaultReactorBuilder(DefaultReactors.java:70) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.impl.DefaultReactors$DefaultReactor.<clinit>(DefaultReactors.java:39) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.impl.DefaultReactors.defaultReactor(DefaultReactors.java:60) ~[bundleFile:?] at org.opendaylight.yangtools.yang.parser.impl.YangParserFactoryImpl.<init>(YangParserFactoryImpl.java:43) ~[bundleFile:?] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?] at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:?] at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?] at java.lang.reflect.Constructor.newInstance(Constructor.java:490) ~[?:?] at java.util.ServiceLoader$ProviderImpl.newInstance(ServiceLoader.java:779) ~[?:?] at java.util.ServiceLoader$ProviderImpl.get(ServiceLoader.java:721) ~[?:?] at java.util.ServiceLoader$3.next(ServiceLoader.java:1394) ~[?:?] at java.util.ServiceLoader.findFirst(ServiceLoader.java:1809) ~[?:?] at org.opendaylight.binding.runtime.spi.ServiceLoaderState$ParserFactory.<clinit>(ServiceLoaderState.java:27) ~[bundleFile:?] at org.opendaylight.binding.runtime.spi.BindingRuntimeHelpers.createEffectiveModel(BindingRuntimeHelpers.java:43) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.BaseSchema.<init>(BaseSchema.java:44) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.schema.mapping.BaseSchema.<clinit>(BaseSchema.java:27) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.resolveBaseSchema(NetconfDevice.java:370) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.onRemoteSessionUp(NetconfDevice.java:159) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.NetconfDevice.onRemoteSessionUp(NetconfDevice.java:85) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onSessionUp(NetconfDeviceCommunicator.java:132) ~[bundleFile:?] at org.opendaylight.netconf.sal.connect.netconf.listener.NetconfDeviceCommunicator.onSessionUp(NetconfDeviceCommunicator.java:48) ~[bundleFile:?] at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.sessionUp(AbstractNetconfSession.java:101) ~[bundleFile:?] at org.opendaylight.netconf.nettyutil.AbstractNetconfSession.handlerAdded(AbstractNetconfSession.java:192) ~[bundleFile:?] at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:971) [bundleFile:4.1.48.Final] at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609) ~[bundleFile:4.1.48.Final] ... 25 more
|
| Comments |
| Comment by Jamo Luhrsen [ 11/May/20 ] |
|
What version are you using? |
| Comment by Tomas Cere [ 12/May/20 ] |
|
Current master. Connecting to testtool using https://wiki-archive.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf#Spawning_netconf_connectors_via_topology_configuration |
| Comment by Robert Varga [ 13/May/20 ] |
|
This is related to the MRI bump, we need a bit more dynamic wiring in netconf. |
| Comment by Jamo Luhrsen [ 13/May/20 ] |
|
Any idea why we aren't seeing this in CSIT? It's using the testtool and mount config looks like: <input xmlns="urn:opendaylight:netconf-node-topology"> <node-id>netconf-test-device</node-id> <host>10.30.170.82</host> <port>17830</port> <username>admin</username> <password>topsecret</password> <tcp-only>false</tcp-only> <keepalive-delay>0</keepalive-delay> </input> the netty-util warning is not in the karaf.log and the device shows up as connected: {
"node": [
{
"node-id": "netconf-test-device",
"netconf-node-topology:available-capabilities": {
"available-capability": [
{
"capability-origin": "device-advertised",
"capability": "urn:ietf:params:netconf:base:1.1"
},
{
"capability-origin": "device-advertised",
"capability": "urn:ietf:params:netconf:capability:exi:1.0"
},
{
"capability-origin": "device-advertised",
"capability": "urn:ietf:params:netconf:base:1.0"
},
{
"capability-origin": "device-advertised",
"capability": "urn:ietf:params:netconf:capability:candidate:1.0"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car-purchase?revision=2014-08-18)car-purchase"
},
{
"capability-origin": "device-advertised",
"capability": "(https://example.com/ns/example-action?revision=2016-07-07)example-action"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:ietf:params:xml:ns:yang:ietf-inet-types?revision=2013-07-15)ietf-inet-types"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring-extension?revision=2013-12-10)ietf-netconf-monitoring-extension"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:yang:extension:yang-ext?revision=2013-07-09)yang-ext"
},
{
"capability-origin": "device-advertised",
"capability": "(org:opendaylight:coretutorials:ncmount:example:l2fib?revision=2016-03-07)ncmount-l2fib"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car-people?revision=2014-08-18)car-people"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car?revision=2014-08-18)car"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:people?revision=2014-08-18)people"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?revision=2010-10-04)ietf-netconf-monitoring"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:ietf:params:xml:ns:yang:ietf-yang-types?revision=2013-07-15)ietf-yang-types"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:opendaylight:test:netconf:crud?revision=2014-10-18)test"
},
{
"capability-origin": "device-advertised",
"capability": "(urn:ietf:params:xml:ns:yang:ietf-inet-types?revision=2010-09-24)ietf-inet-types"
}
]
},
"netconf-node-topology:host": "10.30.170.82",
"netconf-node-topology:connection-status": "connected",
"netconf-node-topology:port": 17830
}
]
}
|
| Comment by Robert Varga [ 13/May/20 ] |
|
No idea... CSIT is using netconf-topology-impl, perhaps Tomas was using netconf-topology-singleton? This also pertains static field initialization, so it is subject to luck as to which codepath touched the constants first – ThreadContextClassLoader is weird that way... |
| Comment by Robert Varga [ 14/May/20 ] |
|
Actually I do know: since we have the bump ongoing still, there has not been a refreshed distro, and the above quoted job used: Nexus timestamp is 0.13.0-20200501.055618-691 Distribution bundle URL is https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/karaf/0.13.0-SNAPSHOT/karaf-0.13.0-20200501.055618-691.zip Distribution bundle is karaf-0.13.0-20200501.055618-691.zip |
| Comment by Jamo Luhrsen [ 14/May/20 ] |
|
yes, that's right. Thanks rovarga. Another downside to the bump taking so long. |