Logs indicate that a member gets suspected by FD (Failure Detection). This might happen for various reasons, e.g. network issues or members being overloaded and freezing for long periods of time, hence not being able to respond to hart beat messages. A common scenario for latter situation is that there are a lot of writes on a/some nodes and this way another node on which replication takes place gets overwhelmed; this can be fixed by using flow control in the jgroups stack: <FC max_credits="500000" min_threshold="0.20"/> anonymous wrote : | is there a way to get the last modified/accessed time of an entry through the API without touching the entry and thereby increasing it's TTL? No. The entries are being processed by the eviction thread, and all the access information is being logged (TRACE) anonymous wrote : is there a way to remove an Fqn via JMX? no anonymous wrote : is there work that the application has to do with @NodeEvicted or other annotations to ensure that the cache state is the same on all nodes (I sort of thought this was the point of jbosscache). @NodeEvicted has nothing to do with cluster consistency. One thing that can be optimized re:eviction is to decrease the wake up time to run more frequently - that's only if a node gets overwhelmed quick and you run out of memory. I suggest you monitor that first: nodes getting 'full' and freezing because of that, as all the effects you describe here might be explained this way.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239908#4239908 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4239908 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
