[pferraro]

OK, so it sounds like the issue isn't with the injection, but rather with the "ISPN000196: Failed to recover cluster state after the current node became the coordinator CacheNotFoundResponse" exception preventing the cache from starting.  As mentioned in the thread you referenced, this bug was fixed in Infinispan 8, but not in the branch used by WF 9.x (i.e. 7.2.x).

Some background on the problem, and why you didn't have it in WF8: WF9 introduced fork channels, which allow each Infinispan cache container to share a single jgroups channel, via the FORK protocol.  While this feature helps conserve resources, it introduces a new condition where a given cache may not exist on a given channel.  When broadcasting a message to the cluster, Infinispan needs to anticipate that any synchronous request may return a CacheNotFoundResponse.  The bug is due to a missing handling of this condition.

You have a few options:

1. Configure your Infinispan cache container to use a JChannel rather than a ForkChannel.  By default, your cache container will share the "ee" channel, defined in the jgroups subsystem.  You can probably circumvent this issue in WF9 by creating a separate channel for use by your cache container.

e.g.

<cache-container name="infinicheck">
 <transport channel="my-channel"/>
</cache-container>

<channels default="ee">
 <channel name="ee" stack="udp"/>
 <channel name="my-channel" stack="udp"/>
</channels>

2. Downgrade to WF8, where this bug does not exist.

3. Upgrade to WF10, where this bug is fixed.  WildFly 10.0.0.CR1 is due to be released this week.

[salamont]

Hi Paul, thanks for the thorough explanation. It makes sense. So far we are using a workaround - splitting the cluster to a smaller subclusters - which works, but it definitely isn't ideal (that's why I asked about this).

We will try 1).

2) is no go now, and about 3) I am a bit afraid of using non-final version for production environment.

Many thanks

Tomas