The code attached to this wiki is not supported. The purpouse of the code is to show how JBAS-4455 could be implemented in JBoss AS 4.0.x.
The aim of JBAS-4455 is to provide a transaction sticky load balancer. This means that while a transaction is running, the same node is always hit unless there's a failure. This is what this example implementation includes:
Code:
a load balance policy, org.jboss.support.ha.framework.interfaces.TransactionSticky, that extends existing o.j.h.f.i.RoundRobin load balance policy. When a new transaction is started, a new target is chosen and added to the transient invocation payload. If there's an ongoing transaction running, the target associated with that transaction will be returned (as long as the target has not been removed from the cluster family, i.e. because it failed).
a high availability invoker proxy, org.jboss.support.invocation.jrmp.interfaces.TransactionStickyJRMPInvokerProxyHA, that extends o.j.i.j.i.JRMPInvokerProxyHA. This proxy maintains a map of transaction propagation contexts to targets, which has a double function:
first, it allows the proxy to associate a target to the invocation if there's an ongoing transaction.
secondly, it allows the proxy to decide, if an invocation fails, whether the invocation can failover to another node or not, for example:
if the very first invocation within a transaction fails (either on the client side, or didn't complete at the server), then it can failover
otherwise, the transaction has started at the server already so invocation failover to another node is forbidden; the client should rollback the transaction.
a high availability invoker, org.jboss.support.invocation.jrmp.server.TransactionStickyJRMPInvokerHA, that extends o.j.i.j.s.JRMPInvokerHA. This invoker creates instances of transaction sticky JRMP invoker proxies.
a JUnit test case that tests:
successful transaction sticky calls
failure situations, some of which are recoverable (allow failover) and others that are not.
two SLSB EJB implementations for testing purpouses, first one contains a method that returns the current time, and the second one contains a method that returns a unique id.
mock versions of the transaction sticky invoker proxy and invoker that based on EJB method parameters, generate different failure scenarios.
XML descriptors:
cluster-service.xml that contains transaction sticky invoker and mock version definitions.
ejb-jar.xml and jboss.xml that contain necessary configuration for:
EJBs that use:
container configuration based on transaction sticky invoker
invoker proxy binding based on transaction sticky invoker proxy
transaction sticky load balancer
Mock EJBs that use:
container configuration based on mock transaction sticky invoker
invoker proxy binding based on mock transaction sticky invoker proxy
transaction sticky load balancer
Properties descriptors:
client side jndi.properties for the JUnit test case
Finally, some notes executed tests, environmental details and attached files:
This code has been tested on a cluster:
of 2 nodes with addresses 127.0.0.1 and 127.0.0.2
where nodes were running JBoss AS 4.0.5.GA
The test case only tests standalone clients starting transactions via UserTransaction.
Behaviour when the clients are components, i.e. EJBs, Servlets..etc, deployed in JBoss AS has not been tested.
The files, where N is the version number, attached to the wiki are:
jboss-support-tx-sticky-lb-src-vN.zip : contains entire source code, build files, and several resource files (including cluster-service.xml).
jboss-support-tx-sticky-lb-vN.jar : contains the main load balance, invoker proxy and invoker implementations. This file should be put in the server's lib directory.
test-jboss-support-tx-sticky-lb-vN.jar : contains the mock invoker proxy and invoker implementations. This file should be put in the server's lib directory.
acme-tx-sticky-lb-vN.jar : is a deployable EJB jar file containing the compiled SLSBs are necessary descriptors, i.e. ejb-jar.xml and jboss.xml
Referenced by:
Comments