Geek Answers Handbook

Wildfly 9 - mod_cluster on TCP

We are currently testing the transition from Wildfly 8.2.0 to Wildfly 9.0.0.CR1 (or CR2 created from a snapshot). The system is a cluster using mod_cluster and runs on VPS, which in fact prevents its use of multicast.

In 8.2.0, we used the following modcluster configuration, which works well:

<mod-cluster-config proxy-list="1.2.3.4:10001,1.2.3.5:10001" advertise="false" connector="ajp"> <dynamic-load-provider> <load-metric type="cpu"/> </dynamic-load-provider> </mod-cluster-config>

Unfortunately, in 9.0.0 the proxy list is out of date, and the server’s start will fail. There is a terrible lack of documentation, however, after several attempts, I found that the proxy list has been replaced by proxies, which are a list of outbound socket bindings. Therefore, the configuration is as follows:

  <mod-cluster-config proxies="mc-prox1 mc-prox2" advertise="false" connector="ajp"> <dynamic-load-provider> <load-metric type="cpu"/> </dynamic-load-provider> </mod-cluster-config>

And in the appropriate socket-binding-group (full-ha in my case), you should add the following:

  <outbound-socket-binding name="mc-prox1"> <remote-destination host="1.2.3.4" port="10001"/> </outbound-socket-binding> <outbound-socket-binding name="mc-prox2"> <remote-destination host="1.2.3.5" port="10001"/> </outbound-socket-binding>

So far so good. After that, the httpd cluster begins to register nodes. However, I get errors from load balancing. When I look in / mod _cluster-manager, I see a couple of lines of Node REMOVED , as well as a lot of errors:

 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000042: Error MEM sending STATUS command to node1/1.2.3.4:10001, configuration will be reset: MEM: Can't read node

There are equivalent warnings in the mod_cluster log:

manager_handler STATUS error: MEM: Can't read node

As far as I understand, the problem is that although wildfly / modcluster can connect to httpd / mod_cluster, this does not work differently. Unfortunately, even after much effort, I was stuck.

Can someone help with installing mod_cluster for Wildfly 9.0.0 without ads? Thank you very much.

+5
source share
3 answers

After a couple of weeks, I returned to the problem and found a solution. The problem was, of course, in the configuration and had nothing to do with the specific version of Wildfly. Mode:

There were three nodes in the domain and three servers in each node. All nodes were started with the following property:

 -Djboss.node.name=nodeX

... where nodeX is the name of a particular node. However, this meant that all three servers in the node get the same name, which is exactly what confused the load balancing. As soon as I remove this property, everything started to work.

+2
source

There is no need for any unnecessary effort or worry about setting up a static proxy server. Each WildFly distribution comes with xsd sheets that describe the configuration of the xml subsystem. For example, with WildFly 9x this is:

 WILDFLY_DIRECTORY/docs/schema/jboss-as-mod-cluster_2_0.xsd

It says:

 <xs:attribute name="proxies" use="optional"> <xs:annotation> <xs:documentation>List of proxies for mod_cluster to register with defined by outbound-socket-binding in socket-binding-group.</xs:documentation> </xs:annotation> <xs:simpleType> <xs:list itemType="xs:string"/> </xs:simpleType> </xs:attribute>

The following setting works outside the field

  • Download wildfly-9.0.0.CR1.zip or create using ./build.sh from Sources
  • Suppose you have 2 blocks, an Apache HTTP server, mod_cluster acting as a proxy for load balancing, and your WildFly server acting as a working one. Ensure that botch servers can communicate with each other on both VirtualHost addresses and hosts with MCMP protocol support (Apache HTTP server side) and on the WildFly AJP and HTTP connector side. A common mistake is binf WildFLy in localhost; he then reports his addition as a local host to the Apache HTTP server located in the dofferent box, making it impossible to contact the WildFly server. The message is bidirectional.
  • This is my configuration diff from the standard wildfly-9.0.0.CR1.zip .

328c328
< <mod-cluster-config advertise-socket="modcluster" connector="ajp" advertise="false" proxies="my-proxy-one">
---
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
384c384
< <subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="worker-1">
---
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
435c435
< <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:102}">
---
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
452,454d451
< <outbound-socket-binding name="my-proxy-one">
< <remote-destination host="10.10.2.4" port="6666"/>
< </outbound-socket-binding>
456c453
< </server>
---
> </server>

Changes description

  • proxies="my-proxy-one" , outbound socket binding name; maybe more of them are here.
  • instance-id="worker-1" , worker name, aka JVMRoute .
  • offset - you can ignore it, it's just for my test setup. Offset does not apply to outbound socket bindings.
  • <outbound-socket-binding name="my-proxy-one"> - IP and VirtualHost port in Apache HTTP server containing the EnableMCPMReceive directive.

Conclusion

Typically, these read / node MEM error messages relate to network issues, for example. WildFly can contact Apache, but Apache cannot contact WildFly. And last, but not least, it may happen that the Apache HTTP server configuration uses the PersistSlots directive, and there has been some significant change in the environment configuration, for example. switch from mpm_prefork to mpm_worker. In this case, the MEM Read error messages do not apply to WildFly, but to the cached slotmem files in HTTPD / cache / mod_custer that need to be deleted. I am sure this is the network in your case.

+2
source

I ran into Node Removed problem. I managed to solve this problem using the following code: instance-id

 <subsystem xmlns="urn:jboss:domain:undertow:2.0" instance-id="${jboss.server.name}">

I hope this helps someone else;)

+2
source

More articles:


All Articles