Attached is an example that illustrates how to setup, deploy, and test your POJOs inside http session replication using FIELD-level granuluarity using JDK 5.0 annotations.
The included readme.txt is repeated here for easier reading.
This is an example that illustrates how to use the FIELD replication granularity to replicate state information about students and the courses they take over a JBoss AS/EAP 4.2 or higher cluster (I am currently running it using AS 4.2.2.GA). In addition, the application is run with the JBoss scoped classloader. If you don't need the scoped classloader, you can comment it out from jboss-web.xml (in etc/WEB-INF).
In this example, where necessary the domain model classes have been annotated with @org.jboss.cache.aop.annotation.PojoCacheable and @org.jboss.cache.aop.annotation.InstanceOfPojoCacheable (PojoCache JDK 5.0 annotations) where "InstanceOfPojoCacheable" signifies that every subclass will be instrumented as well, e.g., no need for Student to annotate again).
To run the example, the aopc target needs to be executed to instrument the classes in the domain model before the example is run (such that you don't need a special class loader during start up). Note that aopc target has been bundled into dist target in build.xml. Please refer it there for details.
The example involves 4 domain model classes: Person, Student, Address and Course where Student is a subclass of Person. A Person has an Address, while a Student can be registered for 0 or more Courses (use of Collection here).
Note that in order to run this example, you will need to have run JBoss web clustering before (e.g., know how to use a load balancer, failover, and sticky sessions). If you have not done that, please refer to JBossHA. Please also refer to How to configure multiple instances of JBoss on how to setup two separate JBoss instances on the same machine, and also go through the "Web Clustering" section, specifically, this wiki. It will be a little involved to set it up first to make sure sticky sessions and loadbalancing are working correctly. But if you use a HW load balancer, I think life will be easier for you (well, to some extent).
Also, note that this example requires Ant 1.6.5 and higher to run, and the JDK required is 1.5.0.
To run it:
1) build the war file (by typing ant dist -Djboss.config=XXX) where "XXX" is the path to your jboss config directory (e.g. /home/jdoe/jboss-4.2.2.GA/server/all or /home/jdoe/jboss-eap-4.2.0.ga/jboss-as/server/all). That is, you need to define jboss.config first. (Note that if you have spaces in your jboss.config path, you can enclose it with "".) This will produce a war file called test-http-scoped-FIELD-50.war under dist directory.
2) Copy this war file to your jboss clustered deploy directories, an equivalent of all/deploy, e.g.). In my case, they are node0 and node1 (and the jvmRoute that I assigned for jk loadbalancer are node0 and node1 as well).
3) Make sure that UseRegionBasedMarshalling and InactiveOnStartup attributes are set to true in deploy/jboss-web-cluster.sar/META-INF/jboss-service.xml for all nodes in the cluster.
4) Start up your 2 JBoss instances. For example, in my case, "run.sh -c node0 -b $" and "run.sh -c node1 -b $.
5) The relevant urls are:
where hostX points to the loadbalancer, e.g., Apache.
You can examine the jsps under the etc directory. Basically, setSession.jsp tries to store the POJOS in the http session using session.setAttribute(), modifyAttribute.jsp then tries to modify it, and finally getAttribute.jsp can retrieve the POJOs.
To illustrate the fine-grained replication, here is what I run (assuming we have
clustered node of 0 & 1):
setSession.jsp (should go to node0). snapshot
getAttribute.jsp (go to node0) snapshot
kill node0 (so the next request will failover to node1)
getAttribute.jsp to validate the values (go to node1 now) snapshot
modifyAttribute.jsp to modify the POJOs (go to node1). snapshot
restart node0 to join the cluster
kill node1 so it will failover back to node0
getAttribute.jsp (go to node0 now). snapshot
Note that you can check the session id for the jvmRoute suffix to check which node the request went to.
When you get to this far, you can also modify the jsps and experiment further!
To help make it easier to use aopc in your own builds, the example uses an Ant script PojoCacheTasks.xml that includes an independent declaration of the aopc target. A copy of this file can be directly imported into to your project's build using the Ant <import/> task. Take a look at the example's build.xml to see how this can be used.
Please report problems to the [Clustering user forum|
http://www.jboss.com/index.html?module=bb&op=viewforum&f=64]
Referenced by:
Comments