jboss.mod_cluster.proxyList
by Bela Ban
I found that when I set jboss.mod_cluster.proxyList to include 2
elements, and the 2nd element is not reachable, the mod-cluster
subsystem takes a long time to start.
How to reproduce:
set jboss.mod_cluster.proxyList (either in the XML file, or via system
prop) to "http1.dyndns.org:8000,http2.dyndns.org:8000"
Currently http2.dyndns.org resolves to 192.168.1.5. If we cannot connect
to such an interface, the socket connection blocks.
I suspect, the following is done (in pseudo code) in mod-cluster (Java
side):
for(Host host: hosts) {
Socket sock=new Socket(host, port);
}
However, this can block up to N minutes (depending on OS), I'd suggest
the following code:
int CONNECT_TIMEOUT=1000; // try to connect, but only wait for 1 sec
Socket sock=new Socket();
try {
sock.connect(new InetSocketAddress(hostname, port), CONNECT_TIMEOUT);
}
catch(SocketTimeoutException ex) {
// skip hostname
}
WDYT ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
13 years, 4 months
Reuse of incoming AJP connections to send messages to workers
by Bela Ban
It seems httpd attempts to establish TCP connections to registered
workers. This won't work if a worker has a private IP address, e.g.
192.168.1.5.
Can't httpd reuse *incoming* TCP connections from workers to *send*
messages to them ? This would require httpd to keep incoming connections
from workers open.
The scenario is as follows:
* httpd runs on a public IP
* We have a worker W which runs on a private IP, e.g.
192.168.1.5:8009 is its AJP connector
* W registers with httpd under 192.168.1.5:8009, this works
* Now someone tries to access a webapp
* Say httpd picks W
* Now httpd attempts to connect to 192.168.1.5:8009, and this fails
The question is why does httpd not reuse the TCP connection established
by W to httpd to send the AJP request back to W ?
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
13 years, 4 months
Enabling mod_cluster by default in AS6
by Paul Ferraro
When discussing the initial integration of mod_cluster into the AS, it
was decided that we would keep it disabled by default - but make it as
simple as possible to enable, i.e. by uncommenting the
<!--depends>ModClusterListener</depends--> withing jbossweb's mc
configuration.
The reasoning for this was that mod_cluster added unwanted overhead in
the case where it wasn't being used. As of version 1.1.0.CR1
(specifically, the completion of MODCLUSTER-103), mod_cluster's
container event handling and load balance factor calculation is
effectively bypassed if it has no proxies with which to communicate.
Consequently, I want to revisit this discussion.
I can think of a couple issues that would need to be addressed if the AS
shipped mod_cluster enabled by default:
1. If a user deletes mod_cluster.sar from their profile, jbossweb will
refuse to start since it has a dependency on the ModClusterListener bean
- the configuration of which was just deleted. This is rather annoying.
a. A potential workaround for this: move the mod_cluster jar and
configuration xml within the jbossweb service itself, rather than a
separate deploy/mod_cluster.sar. Those profiles that include jbossweb,
but do not want to include mod_cluster could include a "dummy"
ModClusterListener bean configuration - so the dependency is satisfied.
This dummy bean config should reside within jbossweb.sar. I think this
is preferable to maintaining 2 copies of the jbossweb mc configuration,
one with and one without the mod_cluster dependency.
b. Hmm - now that I think of it we may actually be able to drop the
jbossweb dependency altogether... The reason this dependency exists in
the first place is to ensure that mod_cluster sends the necessary
DISABLE-APP/STOP-APP/REMOVE-APP mcmp messages prior to shutdown of
jbossweb. In my fix for MODCLUSTER-131, mod_cluster's shutdown handling
was enhanced to react to the "jboss.tomcat.connectors.stopped" JMX
event, emitted prior to stopping the Connectors, which is the first
thing jbossweb does during shutdown. If I'm not mistaken, this may
ultimately mean that we can finally let mod_cluster depend on jbossweb,
and not the other way around. We still need mod_cluster to start before
the WebServer, but a simple dummy bean configuration should do the
trick:
<bean name="ModClusterLoader" class="java.lang.Object">
<demand targetState="Installed">ModClusterListener</demand>
<demand targetState="Instantiated">WebServer</demand>
</bean>
I could not use this previously because this said nothing about the
shutdown order of the two beans. But now, I think it should work.
Thoughts?
13 years, 4 months
More info regarding failover failure
by Bela Ban
I noticed that [1] only occurs if the same config is used on the same
box, e.g.
- node1: run.sh -c all
- node2: run.sh -c all
If 'all' is copied to node1 and node2, and the nodes don't share the
'work' dir, then this works fine.
However, that's a nuisance, as have to update 2 configs now (yes, I
could use symbolic links), but this used to work in earlier versions (of
jbossweb?)...
[1] https://jira.jboss.org/jira/browse/MODCLUSTER-147
--
Bela Ban
Lead JGroups / Clustering Team
JBoss
13 years, 4 months
