New in 3.4 - ReplicatedCache startup timeout triggered while resyncing

Question

Something changed from Coherence 3.3 -> 3.4 in handling or setting-up the start-up timeout of the ReplicatedCache service. There was no problem in 3.3 but in 3.4 the service start-up times out while resyncing caches. I found out that the time it takes to time-out is equal to the cluster's packet publisher's resend time-out (which according to recommendations should be set to max(60 sec, 2 * greatest GC pause). In my situation I set it to 5 minutes (with greatest GC pauses of about 1 minute or so). But with large caches this is not nearly enough (it takes up to 30 minutes to resync caches in my situation).
I worked arround the problem by creating a subclass of ReplicatedCache with an overriden getStartupTimeount() method and configuring it in the tangosol-coherence-override.xml in place of the default ReplicatedCache service.
Maybe a "startup-timeout" configuration parameter should be adequate here.
Peter

Answer 1

Hi Peter,
Yes, this is indeed a new "deterministic" behavior in 3.4. I will open a corresponding enhancement request.
The important question though is: why does it take so long to replicate the caches in a first place. I just tested a replicated cache with 200,000 objects (not optimized Java serialization) totaling 100MB and it took about 20 seconds to start a new node (relatively slow development machines). There must be something else going on in your environment if it takes so long to start a replicated cache service. Do you see any "remote GC" messages? What is the Publisher success rate during the start? Did you run the datagram test?
Regards,
Gene
Correction: I was wrong in the original suggestion that the service would not be stopped.
Edited by: ggleyzer on Oct 15, 2008 2:33 PM