[infinispan-issues] [JBoss JIRA] (ISPN-9127) Remote commands can access components before they are started

[Dan Berindei (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-9127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638607#comment-13638607 ] 

Dan Berindei commented on ISPN-9127:
------------------------------------

https://issues.jboss.org/browse/ISPN-9127

I extracted the main functionality of the component registries in a {{BasicComponentRegistry}} interface, implemented by {{BasicComponentRegistryImpl}}.

* It has no cache-specific logic or references to specific components.
* All the dependencies are wired before being injected in another component. {{ComponentRef<T>}} fields or injection method parameters can be used as lazy dependencies to break dependency cycles. Lazy dependencies are only created and wired when the {{wired()}} method is called.
* Start/stop priorities only have a meaning within a component, if a component has multiple start/stop methods. A component's start methods are always invoked after the start methods of its non-lazy dependencies.
* {{registerComponent()}} doesn't overwrite existing components.
* {{replaceComponent()}} replaces existing components, but it is intended only for tests.
* {{getComponent()}} and {{registerComponent()}} return a {{ComponentRef<T>}}, and the component is always at least wired (all the dependencies have been injected). Use {{running()}} to get the actual instance, or {{wired()}} iff {{running()}} would create a cycle.

I also changed the behaviour of {{[Global]ComponentRegistry}} a bit:
* {{getComponent()}} always tries to create and start the component (skips the start if the registry is only INSTANTIATED)
* {{registerComponent()}} doesn't overwrite existing components


> Remote commands can access components before they are started
> -------------------------------------------------------------
>
>                 Key: ISPN-9127
>                 URL: https://issues.jboss.org/browse/ISPN-9127
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 9.2.2.Final, 9.3.0.Alpha1
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>              Labels: testsuite_stability
>         Attachments: server0, server1, server2, trace.tar.gz
>
>
> {{PerCacheInboundInvocationHandler.handle()}} may be called before the component was started, because {{GlobalInboundInvocationHandler}} fetches it from the component registry without any checks. {{CommandsFactoryImpl.initializeReplicableCommand()}} doesn't wait for the components that it injects into remote commands to be started, either.
> This started causing random test failures in {{ConcurrentStartForkChannelTest}} after ISPN-8515, which moved most initialization work from {{init()}} methods to {{start()}} methods. Because {{StateProviderImpl}} starts after {{StateTransferManagerImpl}}, it's possible for a node to receive a {{StateRequestCommand}} before {{StateProviderImpl}} has initialized:
> {noformat}
> 16:15:09,549 TRACE (remote-thread-Test-NodeB-p51957-t2:[org.infinispan.CONFIG]) [StateProviderImpl] Starting outbound transfer to node Test-NodeA for cache null, topology id 2, segments {0-255}
> 16:15:09,551 WARN  (remote-thread-Test-NodeB-p51957-t2:[]) [NonTotalOrderPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command StateRequestCommand{cache=org.infinispan.CONFIG, origin=Test-NodeA, type=START_STATE_TRANSFER, topologyId=2, segments={0-255}}
> java.lang.IllegalArgumentException: chunkSize must be greater than 0
> 	at org.infinispan.statetransfer.OutboundTransferTask.<init>(OutboundTransferTask.java:114) ~[classes/:?]
> 	at org.infinispan.statetransfer.StateProviderImpl.startOutboundTransfer(StateProviderImpl.java:273) ~[classes/:?]
> 	at org.infinispan.statetransfer.StateRequestCommand.invokeAsync(StateRequestCommand.java:101) ~[classes/:?]
> 	at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94) ~[classes/:?]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)