Late cluster cache swap after joining new cluster

[evdherberg]

In #65 we observed that, at the moment the memberAdded(final MembershipEvent event) is received in the ClusterListener, the CacheFactory is still using the DefaultLocalCacheStrategy instead of the strategy from the plugin. This resulted in a silent ignore of the cluster task we introduced in that method. Because that's what the default cache strategy does with cluster tasks.

The problem was resolved in b454bff by introducing a short wait, until we observe the CacheFactory actually using the strategy provided by this plugin. In local testing, this always happened within the first 200ms of waiting.

Probably it is wise to check whether there are any other event handlers that rely on the cache being properly swapped already. Note that the joinedCluster() events are evoked from the memberAdded handler in the plugin, so those could possibly be vulnerable in this respect.

[guusdk]

Those joinedCluster() invocations are no longer vulnerable with the fix in b454bff in place, correct?

If that's the case, then the only thing to do is to verify that this plugin has no other event listeners that could trigger a 'premature' task execution?