"[EMAIL PROTECTED]" wrote : You *cannot* use async repl and expect that the backup cache(s) have already been updated when you update the primary cache. Use sync_repl. BTW: there is a unit test case (forgot which one) that tests this. Check it out.
I agree with the above; I do not expect an update from one cache VM to be immediately propogated to the VMs in the cache cluster (and I have been testing with SYNC replication anyway though I prefer ASYNCH replication). The problem I am seeing is after the replication occurs. A key/value pair exists in a node's map, then it does not, then it does. All of this happens inside the *same* VM. Isn't the initial presence of the key/value pair, in the node's map proof that replication has already occurred? The VM in which this behavior occurs does not place this value into the map, but after it is replicated, it disappers only to reappear again later (as the log showed). The disappearance/reappearance of the key/value pair is my concern, not when it is replicated. Note, the key/value pair that goes missing (there are actually two that exhibit this behavior), is not being modified or removed by any VM in the cache cluster once it has been added. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3856724#3856724 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3856724 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
