Re: [infinispan-dev] InboundInvocationHandlerImpl optimization
Manik Surtani wrote:
This class is a bit of an anomaly.
There are 2 scopes in Infinispan - GLOBAL and NAMED_CACHE. Some
components are bound to a GLOBAL scope (such as a Transport and an
RpcManager), while others are bound to NAMED_CACHE (such as
Configuration, CommandsFactory, etc).
The problem is, you can inject a NAMED_CACHE component into another
NAMED_CACHE component, or a GLOBAL component into a NAMED_CACHE one,
but never a NAMED_CACHE component into a GLOBAL component. (Guess why!)
What about
having an IIH instance for each cache(scope == NAMED_CACHE),
each keeping a field references to Configuration, Cache, CommandsFactory
and ResponseGenmerator. The transport would look up the appropriate IIH
from a map, so we would reduce the number of lookups at one. Looking at
IIH itself it rather looks quite cache-based, as all its methods have a
cache name param.
So, the InboundInvocationHandler (IIH) is a GLOBAL component, since it
is accessed by the Transport to dispatch RPC from remote hosts to
local caches. Now the IIH *needs* references to NAMED_CACHE
components (such as the InterceptorChain, Configuration, etc) to be
able to dispatch remote RPC to local caches. And since these cannot
be injected, they need to be looked up directly in the named cache's
registry.
The reason why these are always looked up (and resulting in a
Map.get()), and not cached in the IIH, is that you will just be
recreating the maps again. E.g., to cache Configurations in the IIH,
the IIH would need to maintain a Map<String, Configuration> for all
the named caches. And a Map<String, CommandsFactory>. Etc. So, you
still have a map lookup. So why bother duplicating the map?
If you can think of a better way around this, I'd love to hear it.
Like I said, I'm not overly happy about this component, but this is
the best tradeoff between design simplicity and performance I could
come up with so far. :-)
On 13 May 2009, at 07:51, Mircea Markus wrote:
> Hi,
>
> There are several ComponentRegistry.getComponent() lookups in this
> class:
> perform():
> gcr.getNamedComponentRegistry(cacheName);
> cr.getComponent(Configuration.class)
> cr.getLocalComponent(CommandsFactory.class)
> cr.getComponent(ResponseGenerator.class)
>
> applyState() and generateState() call (indirectly):
> cr.getComponent(StateTransferManager.class);
>
> Now all this calls are indirectly map lookups. Another approach would
> be to cache them in class members, wdyt?
>
> Cheers,
> Mircea
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org