[CONTROLLER-1139] EXI encode/decode failure with a specific config module Created: 05/Feb/15  Updated: 30/Jun/15  Resolved: 30/Jun/15

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

Type: Bug
Reporter: Maros Marsalek Assignee: Maros Marsalek
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File AbstractChannelInitializerTest.java    
Issue Links:
Blocks
is blocked by CONTROLLER-1052 Upgrade nagasena to 2.50.0 Resolved
External issue ID: 2679

 Description   

How to reproduce with fully built master distribution from integration project:
1. Send POST request to
http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/controller-config/yang-ext:mount/config:modules

with payload:
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-application-peer</type>
<name>example-bgp-peer-app</name>
<bgp-peer-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">10.25.1.9</bgp-peer-id>
<target-rib xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:rib-instance</type>
<name>example-bgp-rib</name>
</target-rib>
<application-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">example-app-rib</application-rib-id>
<data-broker xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:md:sal:binding">x:binding-async-data-broker</type>
<name>pingpong-binding-data-broker</name>
</data-broker>
</module>

2. Send GET request to
http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/controller-config/yang-ext:mount/config:modules

The deserialization fails with following exception:
2015-02-04 10:19:19,064 | WARN | oupCloseable-3-1 | DefaultChannelPipeline | 96 - io.netty.common - 4.0.23.Final | An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: java.lang.ArrayIndexOutOfBoundsException: -1
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:280)[162:io.netty.codec:4.0.23.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)[162:io.netty.codec:4.0.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)[105:io.netty.transport:4.0.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:319)[105:io.netty.transport:4.0.23.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:163)[162:io.netty.codec:4.0.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:333)[105:io.netty.transport:4.0.23.Final]
at io.netty.channel.AbstractChannelHandlerContext.access$700(AbstractChannelHandlerContext.java:32)[105:io.netty.transport:4.0.23.Final]
at io.netty.channel.AbstractChannelHandlerContext$8.run(AbstractChannelHandlerContext.java:324)[105:io.netty.transport:4.0.23.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:380)[96:io.netty.common:4.0.23.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)[105:io.netty.transport:4.0.23.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)[96:io.netty.common:4.0.23.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[96:io.netty.common:4.0.23.Final]
at java.lang.Thread.run(Unknown Source)[:1.7.0_67]
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at org.openexi.proc.io.SimpleScanner.nextEvent(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.doElement(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.doElement(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.doElement(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.doElement(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.doElement(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.parse(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.openexi.sax.EXIReader.parse(Unknown Source)[161:org.openexi.nagasena:0000.0002.0038.0]
at org.opendaylight.controller.netconf.nettyutil.handler.NetconfEXIToMessageDecoder.decode(NetconfEXIToMessageDecoder.java:78)[157:org.opendaylight.controller.netconf-netty-util:0.3.0.SNAPSHOT]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:249)[162:io.netty.codec:4.0.23.Final]
... 12 more



 Comments   
Comment by Maros Marsalek [ 05/Feb/15 ]

Workaround:
https://git.opendaylight.org/gerrit/14903

Reverts the reuse of transmogrifier

Comment by Maros Marsalek [ 02/Jun/15 ]

Attachment AbstractChannelInitializerTest.java has been added with description: Simple java class that demonstrates the issue without ODL stuff.

Comment by Maros Marsalek [ 03/Jun/15 ]

https://sourceforge.net/p/openexi/discussion/800031/thread/5a8554bd/

Comment by Tomas Cere [ 30/Jun/15 ]

Nagasena fixed the bug on their end, we bumpoed nagasena version and reintroduced reuse of Transmogrifiers.

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