First, client-side interceptors are basically not relevant to an HTTP client talking to the cluster (e.g. a normal webapp where the client is a browser).
Cluster-aware client side interceptors are involved when a Java client contacts a server in the cluster and downloads proxy, which it then uses to invoke operations on servers in the cluster. E.g.:
1) Create an InitialContext configured to use HA-JNDI on port 1100. This results in a communication to the HA-JNDI service on 1100 and the download of a cluster-aware naming service proxy. This is all transparent to your code. When you then do lookups using that context, the proxy includes interceptors that handle load balancing and failover of the naming lookups.
2) Contact JNDI or HA-JNDI (doesn't matter which) and look up an EJB that's configured as clustered. You get an EJB proxy that includes a cluster-aware interceptor. When you make invocations on the bean, the interceptor handles load balancing and failover.
I have a situation where the entire application is bundled within a single ear (the web and the ejb layer are part of the single ear) and deployed in Jboss.
Now since the no. of users has increased and due to performance issues, we have put 3 instances of jboss machines running with these ears. We are currently having another machine with Apache with mod_jk for load balancing and it works good.
1. Is it advisable to do ejb clustering (in addition to load balancing) here. (Because the web and the business layer are not clearly separated i.e., everthing is part of a single ear).
2. If its possible to do ejb clustering in this type of situation, will the performance be increased in any way, since I hope simply increasing the no. of beans in the stateless session bean would suffice in this situation.
I think you have a conceptual misunderstanding here.
- Clustering is done for fault tolerance (aka high availability) of an application.
- Load balancing is to distribute load, and hence for scalability.
Clustering any object (incl. HTTPSession, Stateful EJB ...) comes at a price, because the state has to be replicated to other members(nodes) of the cluster.
So, if scalability is your problem clustering will not help.
Apart from increasing number of instances, you need to determine bottleneck, and tune.
Some potential areas are:
- Web tier (mod_jk to jboss-web connection)
- DataSource Connection Pool
- Entity load (fetch policy, eager/lazy reads etc.)
- Java VM (garbage collection, optimal heapsize etc.)
If your EJB tier consists of SLSBs that are only invoked from the web tier, don't make them clustered, and don't use HA-JNDI to look them up from the web tier. JBoss is going to detect that the EJB is available in the same VM as the web tier and is going to send any call to the EJB in the same VM, which in almost all cases is the most performant solution.
If you have SFSBs, then whether to cluster them or not depends on whether you need the fault tolerance that replicating them provides. So, as cheenu2 said, you would cluster them for fault tolerance, not scalability. Clustering SFSBs carries a performance cost.
For entities, if you are caching entities beyond the life of a transaction, then you need to think about keeping the caches consistent across the cluster via cache invalidation (EJB2) or replication (EJB3).