CONTROLLER-1587, OPNFLWPLUG-870, GENIUS-162, NETVIRT-988 mention/have logs related to PacketProcessingService ... Also looking at the source code of what the <odl:action-provider>  actually does could perhaps shed some light on this. But the easiest would be if someone actually had a good grasp on what magic is going on behind the scenes here and could jump in with an explanation here...

Put in another way, to goal of this issue is just to get https://github.com/vorburger/opendaylight-simple/pull/76 to pass...

odl:action-provider basically wraps RpcProviderService.registerRpcImplementation just like odl:rpc-service. However if no implementation bean is provided, odl:action-provider registers a no-op implementation for each RPC - it seems this is for routed RPCs to register a placeholder for the actual instantiations that are registered in code per RPC context. This is done for PacketProcessingService in ./openflowplugin-impl/src/main/resources/OSGI-INF/blueprint/openflowplugin-impl.xml:

<odl:action-provider interface="org.opendaylight.yang.gen.v1.urn.opendaylight.packet.service.rev130709.PacketProcessingService"/>

I think to satisfy the odl:rpc-service BP dependency in consumers which waits for an underlying implementation to be available - which makes sense for "global" RPCs but not really for routed RPCs so hence the placeholder. Before odl:action-provider, odl:rpc-service happened to work b/c the placeholders were (incorrectly) provided by the sal-remoterpc-connector implementation.

So for PacketProcessingService, no equivalent of odl:action-provider should be needed in ODL simple.

> no equivalent of odl:action-provider should be needed in ODL simple

but e.g. (in genius) ArpUtilImpl and Ipv6NsHelper do require an OFP PacketProcessingService @Inject-ed, so what do we bind it to?

> the actual instantiations that are registered in code per RPC context

perhaps we have a bigger issue with routed RPC in a standalone environment... the Guice (or other DI) framework probably needs to made to support those...

> perhaps we have a bigger issue with routed RPC in a standalone environment... the Guice (or other DI) framework probably needs to made to support those...

right.. I think the binding of RPC consumers is currently compeltely wrong - we need to go through the... which one, RpcProviderRegistry or RpcProviderService?!

tpantelis and I spoke for 1/2h by voice about this today and clarified what needs to be happen here next:

The Guice *Module currently binds PacketProcessingService to PacketProcessingServiceImpl directly, and that was wrong & NOK for a routed RPC - my bad, sorry.

Instead, we need to use the mdsal.RpcConsumerRegistry's getRpcService(). (FTR: There is also the now @Deprecated controller.RpcConsumerRegistry but Tom says that it should be OK to only use mdsal one to look up the RPC - even if openflowplugin still uses the controller one to register the RPC - because behind the scenes they are, or should be, aligned.)

> So for PacketProcessingService, no equivalent of odl:action-provider should be needed in ODL simple.

We also discussed this and weren't 100% sure.. so we can see that OFP uses controller.RpcProviderRegistry (and not, yet, the mdsal.RpcProviderService) to register routed RPC implementations. We are unsure if this is sufficient; but if it's not, it actually seems trivial to do the equivalent of <odl:action-provider> in a Guice Module.

> The Guice *Module currently binds PacketProcessingService to PacketProcessingServiceImpl directly, and that was wrong & NOK for a routed > RPC - my bad, sorry.

It's NOK for global RPCs either. All RPC providers and consumers must go thru the *Registry interfaces. The consumer actually receives an internal proxy implementation that does various things including handling distributed RPC invocations across the cluster.

My gut feeling is that the equivalent of <odl:action-provider> is not needed. IIRC, this was needed due to the BP extension waiting for an underlying DOM implementation to become available to satisfy the dependency (see my comment above on 12/Dec/18).

tpantelis I think https://github.com/vorburger/opendaylight-simple/commit/b9abb1de16eecd2467e9c8ca1bde527ccf8ca96b is probably about right? skitt FYI, if interested.

> It's NOK for global RPCs either. All RPC providers and consumers must go thru the *Registry interfaces. The consumer actually receives an internal proxy implementation that does various things including handling distributed RPC invocations across the cluster.

But have we actually implemented / are we really using distributed RPCs? Can you point to an example in an application?

> My gut feeling is that the equivalent of <odl:action-provider> is not needed.

Yeah, it wasn't.

I think it looks right. Does it work? If so then it's probably right

> But have we actually implemented / are we really using distributed RPCs? Can you point to an example in an application?

yes - opendaylight/md-sal/sal-remoterpc-connector in controller. Apps don't specifically use them - it's done transparently under the hood. Eg, OFP registers routed RPCs on the node that gets the entity ownership for the device - these RPCs are advertised across the cluster and can be invoked from any node. The app is unaware of this happening under the hood.

for non-routed RPCs, how does it decide when to route an RPC to another node? (Asking because apart from this particular routed one in openflowplugin where we have to go through the mechanism,I'm reluctant to just let all and any other RPC calls go through a machine that is not needed in a simple package... my feeling is that it's overused; think something like genius lockmanager or idmanager - having those as RPC is non-sense, IMHO.)

Routed and global RPCs work the same way. If there is a local implementation registered, it uses that otherwise it looks for a registration advertised from a remote node. If found, it proxies the RPC invocation across the wire (using akka) to the remote node. It's all part of ODL clustering.

Anyway that's really orthogonal here. The bottom line is that you have to go thru the mdsal RPC registries to provide or consume RPC services for various reasons, otherwise it won't work properly. You can't just inject an RPC service implementation instance directly as you had originally done.