Operating System: All
Platform: All

Please let me add more information on the first example.

More precisely, when an AD-SAL application calls IStatisticsManager.getFlowsNoCache(Node), it fails to get up-to-date flow statistics.

The implmentation of IStatisticsManager.getFlowsNoCache(Node) calls IReadService.nonCachedReadAllFlows(Node), and the implementation of IReadService.nonCachedReadAllFlows(Node) calls IPluginInReadService.readAllFlow(Node, boolean).
However, because sal-compatiblity does not register IPluginInReadService, calling IPluginInReadService.readAllFlow(Node, boolean) fails, and IStatisticsManager.getFlowsNoCache(Node) fails to get flow statistics.

On the other hand, the implementation of IStatisticsManager.getFlows(Node) uses cached data, and does not call methods of IPluginInReadService.
This is why calling Northbound API of Statistics service is success.

https://jenkins.opendaylight.org/controller/job/controller-merge/lastSuccessfulBuild/artifact/opendaylight/northbound/statistics/target/site/wsdocs/index.html

The Northbound interface internally calls IStatisticsManager.getFlows(Node), and does not call IStatisticsManager.getFlowsNoCache(Node).

Hi Tony,

Thank you for updating the bug report.

Could you explain why you changed the "Product" of this report from controller to openflowplugin?
Have you find out the root cause of this problem in openflowplugin?

This is very strange, if you look at InventoryAndReadAdapter it implements IPluginInReadService, IPluginInInventoryService and ComponentActivator registers them.

Running in karaf:

opendaylight-user@root>feature:install odl-adsal-compatibility
GossipRouter started at Wed Sep 17 09:50:22 CDT 2014
Listening on port 12001 bound on address 0.0.0.0/0.0.0.0
Backlog is 1000, linger timeout is 2000, and read timeout is 0
opendaylight-user@root>bundle:list -s | grep compat
18 | Resolved | 20 | 1.0.0 | org.apache.aries.blueprint.core.compatibility, Hosts: 19
193 | Active | 80 | 1.1.0.SNAPSHOT | org.opendaylight.controller.sal-compatibility
opendaylight-user@root>bundle:services 193

MD-SAL to AD-SAL Adaptation (193) provides:
-------------------------------------------
[org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService]
[org.opendaylight.controller.sal.inventory.IPluginInInventoryService, org.opendaylight.controller.sal.reader.IPluginInReadService]
[org.opendaylight.controller.sal.utils.INodeFactory]
[org.opendaylight.controller.sal.utils.INodeConnectorFactory]
[org.opendaylight.controller.sal.topology.IPluginInTopologyService]
[org.opendaylight.controller.sal.core.IContainerAware]

Which basically shows that those services are in fact present and provided by odl-adsal-compatiblity.

(In reply to Ed Warnicke from comment #3)
> This is very strange, if you look at InventoryAndReadAdapter it implements
> IPluginInReadService, IPluginInInventoryService and ComponentActivator
> registers them.
>

Yes, this is very strange.

I've observed the same result Ed got.

Running in karaf (RC1):

feature:install odl-adsal-compatibility
feature:install odl-nsf-all

bundle:list -s | grep compat
18 | Resolved | 20 | 1.0.0 | org.apache.aries.blueprint.core.compatibility, Hosts: 19
190 | Active | 80 | 1.1.0.Helium-RC1 | org.opendaylight.controller.sal-compatibility

bundle:services 190

MD-SAL to AD-SAL Adaptation (190) provides:
-------------------------------------------
[org.opendaylight.controller.sal.flowprogrammer.IPluginInFlowProgrammerService]
[org.opendaylight.controller.sal.inventory.IPluginInInventoryService, org.opendaylight.controller.sal.reader.IPluginInReadService]
[org.opendaylight.controller.sal.utils.INodeFactory]
[org.opendaylight.controller.sal.utils.INodeConnectorFactory]
[org.opendaylight.controller.sal.topology.IPluginInTopologyService]
[org.opendaylight.controller.sal.core.IContainerAware]
[org.opendaylight.controller.sal.packet.IPluginInDataPacketService]

The sal-compatibility registers the following two services with dependency manager.
+ IPluginInReadService
+ IPluginInInventoryService

However, the correspondent AD-SAL methods are not called.
For example, if sal-compatibility correctly register InventoryAndReadAdapter (which implements IPluginInReadService), ReadService.setService(Map<?, ?>, IPluginInReadService) must be called.
(ReadService class is in org.opendaylight.controller.sal.implementation.internal.)

However, I've confirmed that the ReadService.setService method is not called.
To confirm that, I used RC1 Karaf distribution, and changed the log level of sal.implementation to TRACE.

log:set TRACE org.opendaylight.controller.sal.implementation

If the ReadService.setService method is called, I guess I can see the following TRACE message.

Received set service request: org.opendaylight.controller.sal.compatibility.InventoryAndReadAdapter

However, I couldn't see the above line.
What I saw is just the following two lines.

We guess that the root cause of this issue is sal-compatibility registers the two services as "global services".
+ IPluginInReadService
+ IPluginInInventoryService

On the other hand, AD-SAL openflow plugin registers the above services as "container services"

It seems to me that the bug is in sal-compatibility of Controller project.

And, there are no analysis from anyone which indicates that the root cause of this issue is in OpenFlow plugin project.

Therefore, I've reverted the "Product" of this bug from openflowplugin to controller.

https://git.opendaylight.org/gerrit/#/c/11400/

Hi, I pushed a patch which:

• solves sal-compatibility service provider wiring
• changes getAllStat behavior - stats are taken from operational (product of StatisticsManager)

But there seems to be no change in output of vtn/../detail url.

@Hideyuki: could you please test this patch a check if there is something wrong behind invocation of ReadService.nonCachedReadAllFlows()?

Thank you.

(In reply to michal rehak from comment #6)
> https://git.opendaylight.org/gerrit/#/c/11400/
>

(snip)

>
> @Hideyuki: could you please test this patch a check if there is something
> wrong behind invocation of ReadService.nonCachedReadAllFlows()?

Hi Michal,

I've pulled the above patch, and tested the CONTROLLER-833.
And, I've confirmed that your patch fixes CONTROLLER-833.

First, I saw the following TRACE log message.

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

I think it meant that sal-compatibility correctly registered InventoryAndReadAdapter (which implements IPluginInReadService).

Secondly, I didn't see the following WARN message.

Plugin OF unavailable

I think that indicates that sal-compatibility successfully registered IPluginInInventoryService with AD-SAL.

Thirdly, I observed that VTN Manager (an AD-SAL application) successfully got up-to-date flow statistics.

Therefore, VTN project would be very happy if controller project merges this patch.

Thank you!

https://git.opendaylight.org/gerrit/#/c/11400/ is merged.

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.