All geek questions in one place

JBoss clustering and Lighttpd load balancing showing inconsistent behavior

PROBLEM

We have two JBossAS 4.2.3 installed on separate machines, and they are grouped. We also use Lighttpd, which acts as a load balancer and is located between our Tomcat servers (Tomcat servers are not clustered) and JBoss servers. When all the servers are up and running, the application runs flawlessly. If I remove one JBoss server, requests will be redirected to another server, as expected. My problem starts after exiting the application. When I try to re-enter the application, I get an exception that says that Tomcat cannot connect to the server that was down.

CONFIGURING SERVERS

  • Machine01 - Tomcat7
  • Machine02 - Tomcat7
  • Machine03 - JBoss 4.2.3
  • Machine04 - JBoss 4.2.3
  • Machine05 - Lighttpd 1.4.28

OTHER INFORMATION

  • All machines use Ubuntu 12.04 OS.
  • JBoss machines are grouped.
  • The EAR is dropped to the all/deploy folder.
  • JBossAS is launched using the following command - ./run.sh -b 0.0.0.0 -c all --partition=SomePartitionName &> /dev/null & .
  • Tomcat7 starts as a service, so they start as sudo service tomcat7 start .
  • Lighttpd is configured to work as a load balancer for JBoss machines.

  • The following mod_proxy configuration on lighttpd:

     server.modules += ( "mod_proxy" ) proxy.balance = "fair" proxy.server = ( "" => (( "host" => "Machine03", "port" => 1100 ), ( "host" => "Machine04", "port" => 1100 ))

  • jndi.properties have the following entry

     java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces java.naming.provider.url=Machine05:80

It is impossible to find out why, after I hit the car and quit the application, Tomcats no longer have proxy links to JBoss machines.

+4
source share
1 answer

Now I have decided. Thanks to smallworld for pointing me in the right direction. It happened that we cached the remote interfaces obtained from the jndi search. Now, from what I understand, this remote interface points to only one specific server from the cluster. (We thought that the remote interface would be smart enough to determine that the server was down. It seems that the smartness is somewhere with the original context when you perform the search). Therefore, as soon as the server is down, any ejb call made for this remote interface will connect to the server that was down. Therefore, to solve this problem, we stopped caching the remote interface and each time we search every time we need the services of this EJB. If any server does not work, the search will return the remote interface of the server that is up and running. With this cluster works flawlessly! So guys, your code should look something like this:

  // Some where at class level we have the following map declared private static final Map remoteEJBHashMap = new HashMap(100, 0.9f); public static final <T> T getEJBInterface(String jndiLookupName) { String jndiName = jndiLookupMap.get(jndiLookupName); T ejbInterface = null; //T ejbInterface = (T) remoteEJBHashMap.get(jndiLookupName); //if (ejbInterface == null) { try { ejbInterface = (T) ctx.lookup(jndiName); } catch (NamingException e) { throw new RuntimeException(e); } //remoteEJBHashMap.put(jndiLookupName, ejbInterface); //} return ejbInterface; }

Commented lines are the ones that caused the problem. Now the only thing left for the study is the best solution for this, if any.

0
source

Source: https://habr.com/ru/post/1481359/

More articles:


All Articles