Simple split cache semantics on System.exit?

Question

We have observed, with the default configuration (no override xmls at all), that cache entries get lost under the following case:
1) Start an instance with java -jar coherence.jar
2) Run an application, also with no config overrides, that:
-puts some entries in a named cache (timeout long)
-System.exit()
3) Then immediately run another app that tries to pull the entries from the same named cache
Sometimes #3 works, and sometimes it finds nothing. In all cases, 2 & 3 do connect with 1.
This leads to the following questions:
1) Is the problem that the local cache is not being pushed into the backing partitioned cache before the exit?
2) How can this be rectified (other than sleeping before exiting)?
2A) Is there a "I'm done with this cache, but keep it in the backing store" semantics in one of the calls #2 could make?
2B) Is there a parameter in getting the cache that can be used
2C) Is there config that can insure that this always works
2D) Is there a way that #2 can tell when its data has made it to the cluster (backing cache)?
Thanks in advance

Answer 1

Hi John,
We have observed, with the default configuration (no
override xmls at all), that cache entries get lost
under the following case:
1) Start an instance with java -jar coherence.jarAs I mentioned earlier, we used to have some problems with using the console application as a cache server. Please use DefaultCacheServer instead.
2) Run an application, also with no config overrides,
that:
-puts some entries in a named cache (timeout long)
-System.exit()Which cache? Different named caches have different semantics in the stock configuration. Did you use a transactional cache?
Would you post your test code?
3) Then immediately run another app that tries to
pull the entries from the same named cache
Sometimes #3 works, and sometimes it finds nothing.
In all cases, 2 & 3 do connect with 1.
This leads to the following questions:
1) Is the problem that the local cache is not being
pushed into the backing partitioned cache before the
exit?There is no such concept as a local cache and a non-local in case of Coherence clustered caches.
If the put method call returned, then that data is supposed to be cluster durable.
The only situations I can come up with off my head for what you wrote to be normal (considering that there is cluster node 1 which supposed to live through all which you wrote) is if you
- either put your data to a cache configured to be a LocalCache (it is not clustered)
- or if you put it into a partitioned cache with backup-count configured to be zero (which is not the default setting).
- or if you put it into a TransactionMap and you did not commit it.
- programming errors somewhere
2) How can this be rectified (other than sleeping
before exiting)?I think that should work fine as it is.
2A) Is there a "I'm done with this cache, but keep it
in the backing store" semantics in one of the calls
#2 could make?There is the CacheFactory.shutdown() call indicating polite departure. However its omission should not explain this situation.
2B) Is there a parameter in getting the cache that
can be usedUsed for what? I don't understand the question...
2C) Is there config that can insure that this always
worksI think, it should work out of the box.
2D) Is there a way that #2 can tell when its data
has made it to the cluster (backing cache)?
In general, the return of the put operation means that the data is cluster-durable (if backup count is at least one for partitioned caches and there is another node or there is another node running the service in case of replicated caches).
Best regards,
Robert