Thanks David for response.You mean i need to create one folder in Liferay home and add liferay-multi-vm.xml file there  and read the file as below.ehcache.multi.vm.config.location={Liferay_home}\custom\liferay-multi-vm.xml

This already sounds like a disaster.


First, if they need to make a change, it may not take effect for 30 minutes under this plan. That means for 30 minutes someone will see something they shouldn't or won't see something they should.

Second, the Liferay permission system is already established which handles visibility on assets. I'm not sure what you're doing, but if you were using permission assignments (either changing permissions on assets or changing roles for the users), the regular Liferay functionality would just work, it applies across the cluster and doesn't require some kind of whacky multi-vm pool usage.

I don't know what these "complex rules" actually are, but if they are processed when they are changed and either modify permissions on assets or adjust user roles, it would apply immediately and would leverage the normal Liferay OOTB functionality to determine who has permission to see what.

As we are using Liferay Portal in clustered  environment and there are certain complex  rules  based on some rules we include ,exclude content and after that we show final content to accomplish this every  30 min a scheduler  runs which refresh  the cache and final result shown to user.

"Complex caching rules" - if that's what you wanted to say - indeed sound like a bad idea. Caches should be dead simple.
From the ticket mentioned above, I've clicked through to https://github.com/dantewang/liferay-docs/pull/7/commits/978ad4e4c22797f0c7c2613a79e670319c9f81a2 (in some indirections). In general: The regular clustered cache-invalidation (e.g. server[1] changes an object and signals server[2..n] that the object in question should be flushed from the cache) is fine - and if you need to configure your cache size accordingly: That's fine.
Complex caching rules that span the cluster sound like a solution on the wrong level of abstraction (without further explanation).

3.Add the replicatePutsViaCopy=true value we can check from PortalCacheReplicator.java base on requirement.
 

Rarely (read: never) have I seen a justification for "replicatePut" based on actual necessity. Always, in what I've seen so far, it was a bad idea: If you need an entity on one server, that doesn't have any effect on the other server. In fact, you limit the capacity of the whole cluster by assuming that you have the same objects in all caches.
If you need an object on another server, it will be fetched from the regular storage (database) anyway -  and flushed from the cache if it's modified on any other cluster machine.