[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBPAPP-863 -- FC blocks during slow failure detection

[bstansberry@jboss.com]

The issue of whether to include FC in a config should be better covered in the docs:

http://jira.jboss.com/jira/browse/JBAS-5677

Re: mod_jk doing retries, I expect the config described would cause test failures even if there were a much faster failure timeout (say 20-30 seconds).  After 8 secs, mod_jk will retry, and this is a counter-based test, so the counter will increase by 2 and you'll get a failure.

This illustrates why a retry when the request has reached a server is dangerous.  For EJB proxies the clustering logics forbids this.

If you want to enable retries, suggest you use the recovery_options parameter (see http://tomcat.apache.org/connectors-doc/reference/workers.html ) and set it to 1 such that retries are not attempted if the request reaches the server.

OK, now back to this JIRA and the general testing program.

First, besides the good points Bela makes about 2.4.x vs. 2.6.x, I wouldn't want to change config files in a micro release or EAP CP. So, if we don't change the defaults, this becomes a knowledge-base issue. Hence the docs update JIRA, and I know the support guys are aware of this thread.

For the general testing program, a bigger cluster is probably better if you're testing what happens when the plug is pulled on a single node.  *If* you need to drill further into what happens with a 2 node cluster, then removing FC from your TCP-based config makes sense.  We already know the effect FC has, and removing FC from a 2 node TCP config is correct. So removing it will let you check for other effects.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160565#4160565

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160565