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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...