https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-833 controller <p>sal-comaptiblity does not register the following services with AD-SAL.</p> <p> + IPluginInReadService<br/> + IPluginInInventoryService</p> <p>Therefore, for example, an AS-SAL application cannot get flow statistics from the MD-SAL OF plugin, because sal-compatibility does not register IPluginInReadService.</p> <p>For instance, we saw the following ERROR message, because sal-compatiblity does not register IPluginInInventoryService with AD-SAL.</p> <p> WARN o.o.c.s.i.internal.ReadService - Plugin OF unavailable</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-833

sal-compatiblity does not register some services.

Bug Resolved Done Hideyuki Tai Hideyuki Tai Sun, 14 Sep 2014 23:03:23 +0000 Thu, 19 Oct 2017 16:36:45 +0000 Tue, 5 May 2015 15:17:13 +0000 Helium adsal 0 5 <p>Please let me add more information on the first example.</p> <p>More precisely, when an AD-SAL application calls IStatisticsManager.getFlowsNoCache(Node), it fails to get up-to-date flow statistics.</p> <p>The implmentation of IStatisticsManager.getFlowsNoCache(Node) calls IReadService.nonCachedReadAllFlows(Node), and the implementation of IReadService.nonCachedReadAllFlows(Node) calls IPluginInReadService.readAllFlow(Node, boolean).<br/> However, because sal-compatiblity does not register IPluginInReadService, calling IPluginInReadService.readAllFlow(Node, boolean) fails, and IStatisticsManager.getFlowsNoCache(Node) fails to get flow statistics.</p> <p>On the other hand, the implementation of IStatisticsManager.getFlows(Node) uses cached data, and does not call methods of IPluginInReadService.<br/> This is why calling Northbound API of Statistics service is success.</p> <p><a href="https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/northbound/statistics/target/site/wsdocs/index.html" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/northbound/statistics/target/site/wsdocs/index.html</a></p> <p>The Northbound interface internally calls IStatisticsManager.getFlows(Node), and does not call IStatisticsManager.getFlowsNoCache(Node).</p> <p>Hi Tony,</p> <p>Thank you for updating the bug report.</p> <p>Could you explain why you changed the "Product" of this report from controller to openflowplugin?<br/> Have you find out the root cause of this problem in openflowplugin?</p> <p>This is very strange, if you look at InventoryAndReadAdapter it implements IPluginInReadService, IPluginInInventoryService and ComponentActivator registers them.</p> <p>Running in karaf:</p> <p>opendaylight-user@root&gt;feature:install odl-adsal-compatibility<br/> GossipRouter started at Wed Sep 17 09:50:22 CDT 2014<br/> Listening on port 12001 bound on address 0.0.0.0/0.0.0.0<br/> Backlog is 1000, linger timeout is 2000, and read timeout is 0<br/> opendaylight-user@root&gt;bundle:list -s | grep compat<br/> 18 | Resolved | 20 | 1.0.0 | org.apache.aries.blueprint.core.compatibility, Hosts: 19 <br/> 193 | Active | 80 | 1.1.0.SNAPSHOT | org.opendaylight.controller.sal-compatibility <br/> opendaylight-user@root&gt;bundle:services 193</p> <p>MD-SAL to AD-SAL Adaptation (193) provides:<br/> -------------------------------------------<br/> <span class="error">&#91;org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.inventory.IPluginInInventoryService, org.opendaylight.controller.sal.reader.IPluginInReadService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.utils.INodeFactory&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.utils.INodeConnectorFactory&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.topology.IPluginInTopologyService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.core.IContainerAware&#93;</span></p> <p>Which basically shows that those services are in fact present and provided by odl-adsal-compatiblity.</p> <p>(In reply to Ed Warnicke from comment #3)<br/> &gt; This is very strange, if you look at InventoryAndReadAdapter it implements<br/> &gt; IPluginInReadService, IPluginInInventoryService and ComponentActivator<br/> &gt; registers them.<br/> &gt; </p> <p>Yes, this is very strange.</p> <p>I've observed the same result Ed got.</p> <p>Running in karaf (RC1):</p> <p>feature:install odl-adsal-compatibility<br/> feature:install odl-nsf-all</p> <p>bundle:list -s | grep compat<br/> 18 | Resolved | 20 | 1.0.0 | org.apache.aries.blueprint.core.compatibility, Hosts: 19<br/> 190 | Active | 80 | 1.1.0.Helium-RC1 | org.opendaylight.controller.sal-compatibility</p> <p>bundle:services 190</p> <p>MD-SAL to AD-SAL Adaptation (190) provides:<br/> -------------------------------------------<br/> <span class="error">&#91;org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.inventory.IPluginInInventoryService, org.opendaylight.controller.sal.reader.IPluginInReadService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.utils.INodeFactory&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.utils.INodeConnectorFactory&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.topology.IPluginInTopologyService&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.core.IContainerAware&#93;</span><br/> <span class="error">&#91;org.opendaylight.controller.sal.packet.IPluginInDataPacketService&#93;</span></p> <p>The sal-compatibility registers the following two services with dependency manager.<br/> + IPluginInReadService<br/> + IPluginInInventoryService</p> <p>However, the correspondent AD-SAL methods are not called.<br/> For example, if sal-compatibility correctly register InventoryAndReadAdapter (which implements IPluginInReadService), ReadService.setService(Map&lt;?, ?&gt;, IPluginInReadService) must be called.<br/> (ReadService class is in org.opendaylight.controller.sal.implementation.internal.)</p> <p>However, I've confirmed that the ReadService.setService method is not called.<br/> To confirm that, I used RC1 Karaf distribution, and changed the log level of sal.implementation to TRACE.</p> <p> log:set TRACE org.opendaylight.controller.sal.implementation</p> <p>If the ReadService.setService method is called, I guess I can see the following TRACE message.</p> <p> Received set service request: org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter</p> <p>However, I couldn't see the above line.<br/> What I saw is just the following two lines.</p> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <td class='confluenceTd'> TRACE </td> <td class='confluenceTd'> Local user karaf </td> <td class='confluenceTd'> FlowProgrammerService </td> <td class='confluenceTd'> 175 - org.opendaylight.controller.sal.implementation - 0.4.2.Helium-RC1 </td> <td class='confluenceTd'> Received set service request: org.opendaylight.controller.sal.compatibility.FlowProgrammerAdapter@55ad011c</td> </tr> </tbody></table> </div> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <td class='confluenceTd'> TRACE </td> <td class='confluenceTd'> Local user karaf </td> <td class='confluenceTd'> DataPacketService </td> <td class='confluenceTd'> 175 - org.opendaylight.controller.sal.implementation - 0.4.2.Helium-RC1 </td> <td class='confluenceTd'> Received set service request: org.opendaylight.controller.sal.compatibility.adsal.DataPacketServiceAdapter@145ddfea</td> </tr> </tbody></table> </div> <p>We guess that the root cause of this issue is sal-compatibility registers the two services as "global services".<br/> + IPluginInReadService<br/> + IPluginInInventoryService</p> <p>On the other hand, AD-SAL openflow plugin registers the above services as "container services"</p> <p>It seems to me that the bug is in sal-compatibility of Controller project.</p> <p>And, there are no analysis from anyone which indicates that the root cause of this issue is in OpenFlow plugin project.</p> <p>Therefore, I've reverted the "Product" of this bug from openflowplugin to controller.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/11400/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/11400/</a></p> <p>Hi, I pushed a patch which:</p> <ul class="alternate" type="square"> <li>solves sal-compatibility service provider wiring</li> <li>changes getAllStat behavior - stats are taken from operational (product of StatisticsManager)</li> </ul> <p>But there seems to be no change in output of vtn/../detail url.</p> <p>@Hideyuki: could you please test this patch a check if there is something wrong behind invocation of ReadService.nonCachedReadAllFlows()?</p> <p>Thank you.</p> <p>(In reply to michal rehak from comment #6)<br/> &gt; <a href="https://git.opendaylight.org/gerrit/#/c/11400/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/11400/</a><br/> &gt; </p> <p>(snip)</p> <p>&gt; <br/> &gt; @Hideyuki: could you please test this patch a check if there is something<br/> &gt; wrong behind invocation of ReadService.nonCachedReadAllFlows()?</p> <p>Hi Michal,</p> <p>I've pulled the above patch, and tested the <a href="https://jira.opendaylight.org/browse/CONTROLLER-833" title="sal-compatiblity does not register some services." class="issue-link" data-issue-key="CONTROLLER-833"><del>CONTROLLER-833</del></a>.<br/> And, I've confirmed that your patch fixes <a href="https://jira.opendaylight.org/browse/CONTROLLER-833" title="sal-compatiblity does not register some services." class="issue-link" data-issue-key="CONTROLLER-833"><del>CONTROLLER-833</del></a>.</p> <p>First, I saw the following TRACE log message.</p> <p>2014-09-20 20:24:13,151 | TRACE | Local user karaf | ReadService | 175 - org.opendaylight.controller.sal.implementation - 0.4.2.SNAPSHOT | Received set service request: org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter@26b0df73</p> <p>I think it meant that sal-compatibility correctly registered InventoryAndReadAdapter (which implements IPluginInReadService).</p> <p>Secondly, I didn't see the following WARN message.</p> <p> Plugin OF unavailable</p> <p>I think that indicates that sal-compatibility successfully registered IPluginInInventoryService with AD-SAL.</p> <p>Thirdly, I observed that VTN Manager (an AD-SAL application) successfully got up-to-date flow statistics.</p> <p>Therefore, VTN project would be very happy if controller project merges this patch.</p> <p>Thank you!</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/11400/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/11400/</a> is merged.</p> <p>This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.</p> Blocks VTN-40 Development External issue ID 1866 External issue URL ODL SR Target Milestone Rank 0|i02mu7: