Cluster exploration of ejb3 in jboss5

Ejb3InJboss5xInternal cluster Exploration

This article introduces the basic configurations and precautions of ejb3 in jboss5x clusters. Our main purpose is to cluster ejb3 in jboss5x and then be client (which can be a web application ), does not involve the content of the JBoss HTTP request cluster. For details, see:

I,Program preparation

We have two projects, ejb.rar and webapp. War. The former is the ejb3 project and the latter is a Web application. The main code is as follows:

Ejb.rar main code:

 

Interface:

Package com. sample;

@ Remote

// @ Local

Public interface hellobeanitf {

Public void dosomething ();

}

Implementation:

Package com. sample;

Import java. Io. serializable;

Import javax. EJB .*;

Import org. JBoss. annotation. EJB. Clustered;

 

@ Stateless

@ Clustered

Public class hellobean implements hellobeanitf {

Int counter = 0;

Public void dosomething (){

Counter ++;

System. Out. println ("stateless: Value of counter is" + counter );

}

}

The above is a stateless Session Bean. Note that annotation @ clustered is required. If annotation is not made, the Session Bean will not be used by the cluster. The cluster Declaration for stateful session beans is also as follows:

@ Stateful

@ Clustered

Public class hellobean2 implements hellobeanitf, serializable {

Int counter = 0;

Public void dosomething (){

Counter ++;

System. Out. println ("stateful: Value of counter is" + counter );

}

}

 

Main webapp. War code:

Create the index. jsp file to call the stateless Session Bean. The main code is as follows:

<%

Public void jspinit (){

Try {

Hellobeanitf EJB = NULL;

Initialcontext CTX = new initialcontext ();

For (INT I = 0; I <10; I ++ ){

// EJB = (hellobeanitf) CTX. Lookup ("hellobean/local ");

EJB = (hellobeanitf) CTX. Lookup ("hellobean/remote ");

}

}

Catch (exception exc ){

Exc. printstacktrace ();

}

}

EJB. dosomething ();

%>

Stateless EJB invoked

Create an index2.jsp file to call a stateful Session Bean. The main code is as follows:

<%

Public void jspinit (){

Try {

Hellobeanitf EJB = NULL;

Initialcontext CTX = new initialcontext ();

For (INT I = 0; I <10; I ++ ){

// EJB = (hellobeanitf) CTX. Lookup ("hellobean2/local ");

EJB = (hellobeanitf) CTX. Lookup ("hellobean2/remote ");

}

}

Catch (exception exc ){

Exc. printstacktrace ();

}

}

EJB. dosomething ();

%>

Stateful EJB invoked

 

 

Add the JNDI. porperties file under classpath as follows:

Java. Naming. Factory. Initial = org. jnp. Interfaces. namingcontextfactory

Java. Naming. Factory. url. pkgs = org. JBoss. Naming: org. jnp. Interfaces

Java. Naming. provider. url = 192.168.1.2: 1099,192.168 .1.3: 1099

II,Configure JBoss

It is a little troublesome to configure JBoss. We deploy JBoss on the three machines with the names jboss1, jboss2, and jboss3 respectively. The corresponding IP addresses are 192.168.1.1, 192.168.1.2, and 192.168.1.3 respectively. The configuration procedure is as follows:

(1) Enable the JBoss to access the JBoss by IP address. Find the JBoss-home \ Server \ All \ deploy \ jbossweb file under the jboss2 and jboss3 installation directories respectively. SAR \ Server. XML and open, put

<Connector protocol = "HTTP/1.1" Port = "8080" address = "$ {JBoss. Bind. Address}" connectiontimeout = "20000" redirectport = "8443"/>

Changed:

<Connector protocol = "HTTP/1.1" Port = "8080" address = "0.0.0.0" connectiontimeout = "20000" redirectport = "8443"/>

(2) Configure jvmroute, open the JBoss-home \ Server \ All \ deploy \ jbossweb. Sar \ Server. xml file in jboss2 and jboss3, and modify

 

<Engine name = "JBoss. Web" defaulthost = "localhost">

Change jboss2 to: <engine name = "JBoss. Web" defaulthost = "localhost" jvmroute = "jboss2">

Change jboss3 to: <engine name = "JBoss. Web" defaulthost = "localhost" jvmroute = "jboss3">

(3) set serverpeerid, open the JBoss-home \ Server \ All \ deploy \ messaging \ messaging-service.xml file in jboss2 and jboss3, modify

 

<Attribute name = "serverpeerid" >$ {JBoss. messaging. serverpeerid: 0} </attribute>

Change jboss2 to <attribute name = "serverpeerid" >$ {JBoss. messaging. serverpeerid: 2} </attribute>

Change jboss3 to <attribute name = "serverpeerid" >$ {JBoss. messaging. serverpeerid: 3} </attribute>

 

III,Deployment

We deploy ejbs in jboss2 and jboss3 respectively to make them cluster. Deploy the Web Client to jboss1 to access ejbs, as follows:

(1) Copy EJB. jar to jboss2's JBoss-home \ Server \ All \ farm, use all for deployment because all contains all services, cluster services and JBoss cache services are what we need, put in farm to automatically deploy ejbs to their respective farm directories after several JBoss clusters. However, this function occasionally fails to be deployed and can be copied manually. Of course, you can also manually copy ejbs to the JBoss-home \ Server \ All \ deploy directory of jboss2 and jboss3 respectively, with the same cluster effect.

(2) log on to jboss2 and jboss3 respectively. log on to the JBoss installation directory and run. Bat-c All-B 0.0.0.0 to start JBoss.

Of course, we can also use run. Bat-c All-B 192.168.1.2 run. Bat-c All-B 192.168.1.3 to start

(3) Deploy webapp. War to the JBoss-home \ Server \ Default \ deploy directory of jboss1, and start jboss1

(4) Deploy webapp. War to the JBoss-home \ Server \ All \ deploy directory of jboss2 for comparison with the jboss1 Web Client.

IV,Operation Analysis

(1) run the Web Client in jboss1

Enter http: // 192.168.1.1/webapp/index. jsp in the browser, and then observe the jboss2 and jboss3 consoles.

Jboss2	Jboss3
Stateless: Value of counter is 1 Stateless: Value of counter is 1 Stateless: Value of counter is 2 Stateless: Value of counter is 2 Stateless: Value of counter is 3	Stateless: Value of counter is 1 Stateless: Value of counter is 2 Stateless: Value of counter is 3 Stateless: Value of counter is 4 Stateless: Value of counter is 5

Refresh again as follows:

Jboss2	Jboss3
Stateless: Value of counter is 3 Stateless: Value of counter is 4 Stateless: Value of counter is 4 Stateless: Value of counter is 5 Stateless: Value of counter is 5	Stateless: Value of counter is 6 Stateless: Value of counter is 7 Stateless: Value of counter is 8 Stateless: Value of counter is 9 Stateless: Value of counter is 10

During the first visit, we made ten rounds and found that we ran five times on JBoss, which achieved the goal of Server Load balancer. The second visit. We can see that the rule of counter in JBoss is 11223344... This indicates that two hellobean instances are generated in jboss1 for round-training access, while jboss2 only has one hellobean instance, which fully complies with the stateless Session Bean feature, as to why jboss2 has two instances, it is not clear yet and remains to be explored.

 

Then, enter http: // 192.168.1.1/webapp/index2.jsp in the browser, and then observe the jboss2 and jboss3 consoles.

Jboss2	Jboss3
	Stateful: Value of counter is 1 Stateful: Value of counter is 2 Stateful: Value of counter is 3 Stateful: Value of counter is 4 Stateful: Value of counter is 5 Stateful: Value of counter is 6 Stateful: Value of counter is 7 Stateful: Value of counter is 8 Stateful: Value of counter is 9 Stateful: Value of counter is 10

Refresh again as follows:

Jboss2	Jboss3
Statefu L: Value of counter is 1 Stateful: Value of counter is 2 Stateful: Value of counter is 3 Stateful: Value of counter is 4 Stateful: Value of counter is 5 Statefu L: Value of counter is 6 Stateful: Value of counter is 7 Stateful: Value of counter is 8 Stateful: Value of counter is 9 Stateful: Value of counter is 10

If the input is Refresh two times in a row, it is found that the input is the same as the above. During the first visit, we made 10 rounds and found that a hellobean2 instance was generated when we ran 10 times on jboss3, and a hellobean2 instance was generated 10 times when we ran the second jboss2, in this way, we can see that the cluster will randomly find an EJB service for each access, and a new session bean instance will be generated for each access, which fully complies with the stateful Session Bean feature.

(2) Disable jboss3. We performed the following operations in the previous step and found that the access was normal. All requests responded to jboss2, so that we achieved the purpose of failover.

(3) Restart jboss3 in the same way. We Use http: // 192.168.1.2/webapp/index. access through JSP, http: // 192.168.1.2/webapp/index2.jsp. It is not difficult to find that all requests are responded to in jboss2, this is because if the Web Client in JBoss accesses the cluster EJB and the local EJB cluster to be accessed also participates, the cluster will only return the local EJB, of course, if the local EJB fails, the cluster can randomly allocate ejbs in other JBoss.

(4) We can change the hellobeanitf annotation to @ local to index. CTX in JSP and index2.jsp. lookup ("hellobean2/remote"); changed to CTX. lookup ("hellobean2/local"); then Redeploy according to the previous method, we found that only http: // 192.168.1.2/webapp/index can be used. JSP, http: // 192.168.1.2/webapp/index2.jsp for access, and all requests are responded on jboss2, which also conforms to the features of the local Session Bean.

 

V. Discussion

Through the above test, we can imagine that we can construct such a cluster system, constructing an external web client in a JBoss to access the EJB service system of multiple other clusters is completely feasible. Therefore, JBoss of this external web client cannot participate in the EJB cluster. This method looks a bit similar to the HTTP cluster of Apache + mod_jk + JBoss, but it is not the same in nature. Which of the two clusters is better? I have not tested them yet. I hope I will have a chance to test them myself in the future. The above are some of my research on the cluster EJB in JBoss. I forget to give you some advice on the shortcomings and errors.