FD_HOST's ping task reports how old it's been suspected for by "age=X secs" as follows.

~~~
2014-10-29 16:22:43.045 TRACE [org.jgroups.protocols.FD_HOST] (Timer-2,shared=udp) AAAAAAAA/clustered(s1): /10.9.64.67 is not alive (age=5 secs)
~~~

Normally it will be counted up to "age=5 secs" if the configuration is as follows (timeout/interval = 5).

~~~
        <protocol type="FD_HOST">
             <property name="timeout">5000</property>
             <property name="interval">1000</property>
             <property name="check_timeout">1000</property>
        </protocol>
~~~

But we found a node has been directly dead without such ageing count-up as follows.

~~~
2014-10-29 16:23:17.371 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (Timer-2,shared=udp) verifying that BBBBBBBB/clustered(s1) is dead
~~~

Of course server's busyness and such a tight interval contributes to the direct death without ageing count-up.  But the current implementation of FD_HOST$PingTask seems to behave more like this if the number of hosts is large.  See this comment [1] for the detail.


[1] https://github.com/belaban/JGroups/pull/156#issuecomment-47315801

> We have 60 hosts, each ping takes 0.5 sec, timeout=30 sec. Suspect cond is: if(current_time - timestamp >= timeout) suspect(host);
> 
> The current impl is:
> 
>     start_time = 0
>     for (hosts) update timetamps, first is 0.5 and last is 30
>     current_time = 30
>     in suspect check, 30 - 0.5 = 29.5
> 
> The first member is almost timed out although it responds to ping in 0.5 sec. It'll be suspected if there is a GC pause.

(The last comment in the above conversation is saying that the old timestamp would be overwritten by new task thread.  But FD_HOST$PingTask is scheduled by scheduleAtFixedRate(), which indicates there is no such concurrent execution, according to JavaDoc of java.util.concurrent.ScheduledExecutorService.)