Thanks,
found it, and it's 3 minutes in our cases.
2 another questions
Q1: As I found this FD timeout have been configure to 'Jgroup', 'Postoffice's DataChannel, Postoffice's ControlChannel',each of the timeout will cause node drop? and should be the shortest timeout will be the trigger in the majority of the cases?
--Cache timeout
Q2.1: Jboss TreeCache have been configure FD timeout too, is this the real timeout or is the value of parameter SyncReplTimeout ? I think is the former one according to your last reply
Q2.2: in the following cache log clip, it seems node lost in the JGroup, cause the node lost in the CacheView, my question is the CacheView maintainance combined by the answer of Q2.1 and the JGroupView ?
(1099 is JNDI port, 7930 is replication cache port, 7920 is invalidation cache port, 7910 is the ControlChannel port, 7900 is the DataChannel port 7800 is JGroup port)
2012-06-14 03:28:01,049 New cluster view for partition PRODPartition_HA: 12 ([10.164.107.69:1099, 10.164.218.18:1099, 10.164.107.65:1099] delta: -1)
2012-06-14 03:28:01,091 viewAccepted(): [10.164.107.69:7930|12] [10.164.107.69:7930, 10.164.218.18:7930, 10.164.107.65:7930]
2012-06-14 03:28:01,057 I am (10.164.107.65:1099) received membershipChanged event:
2012-06-14 03:28:02,047 Dead members: 1 ([10.164.218.14:1099])
2012-06-14 03:28:02,161 New Members : 0 ([])
2012-06-14 03:28:02,161 All Members : 3 ([10.164.107.69:1099, 10.164.218.18:1099, 10.164.107.65:1099])
2012-06-14 03:28:02,161 Suspected member: 10.164.218.14:7800
2012-06-14 03:28:02,293 viewAccepted(): [10.164.107.69:7920|12] [10.164.107.69:7920, 10.164.218.18:7920, 10.164.107.65:7920
Bond