JNDI vs. HA-JNDI lookups

[marlig]

Hi,

I've been using JBoss clustering for a while now and it's working great. Thanks!

Now I've come across a matter from which I thought I knew how it worked for sure, but somehow it doesnt. It's about the behaviour of (HA-) JNDI lookups from a remote client.

My assumption was the following: you have two ports on each node, one exposing the local JNDI tree (usually ports 1099, 1199, ...) and the other one exposing the HA-JNDI tree (usually ports 1100, 1200, ...).

Now when a client connects to the server using the port for the local tree (1099), the request should be handled on the node it called, and on that node only. When the client connects to the server using the port for the HA tree (1100), the request will be handled by any node in the cluster. Or, to be more precise, the smart proxy, which the client got with the first call, will distribute the calls across the nodes.

I'm pretty sure that's the behaviour I saw the last time I checked. But what I'm seeing now (we changed to JBoss 4.0.4 in the meantime) is that also the calls to the local port (1099 etc) are distributed across the nodes. However, for testing purposes, I need to call a certain node, and not any node in the cluster.

Is my understanding wrong (if so, what's the right way of doing it)?
Or was there a change with JBoss 4?
Or is there even a bug in JBoss 4?

Any enlightenment is appreciated. :-)

Martin

[marlig]

Btw, all nodes are running on the same server with the same IP address. Might this be important?

Martin

[jerrygauth]

I think you understanding is correct; at least it matches mine. :)

I was unable to replicate your findings using JBoss 4.0.5. I used multiple IP addresses rather than the service binding manager but I wouldn't think that would matter. When I bound objects locally on both nodes and then performed multiple lookups using local JNDI ports, refreshing the context each time, I obtained the expected results.

If something has changed, it would likely be in how proxies are used for local JNDI. The HA-JNDI service doesn't see requests directed to local ports so it wouldn't be responsible for the behavior you're reporting.

When you say that a call to a local port is likely to be distributed, are you indicating that JNDI would potentially return an incorrect result (i.e., because the nodes had different binding values or not all objects being looked up were bound on all nodes)?

Jerry

[brian.stansberry]

Perhaps you are confusing the behavior of the naming proxy vs. the EJB proxy? They are completely independent. If that's not what you're doing, ignore the rest of this, and just treat it as useful info for other people who stumble on this thread. ;-)

If you create an InitialContext that connects to an HA-JNDI server, you get a naming proxy that can provides failover and load balancing for *naming operations*. If your context connects to a non-HA JNDI server, then the naming proxy only knows conduct *naming operations* with the server from which it was downloaded. No failover, no load balancing.

Either way, when you lookup an EJB, you download a proxy for the EJB. You get the same proxy no matter whether you looked it up via HA-JNDI or regular JNDI. If that EJB is configured as clustered, when you start invoking *ejb operations* on it, those calls will be able to fail over if appropriate, and will be load balanced.

[marlig]

Thanks for your replies. I guess I'm seeing the behaviour that Brian described, where my client gets the EJB-proxy, and since the EJBs are configured as clustered, all calls to that EJBs are load-balanced.

I just remembered that we had to manually set the invoker-proxy-bindings to support some clients that run on older JDK versions:

 <invoker-proxy-bindings>
 <invoker-proxy-binding>
 <name>clustered-retry-stateless-rmi-invoker</name>
 <invoker-mbean>jboss:service=invoker,type=jrmpha</invoker-mbean>
 <proxy-factory>org.jboss.proxy.ejb.ProxyFactoryHA</proxy-factory>
 <proxy-factory-config>
 <client-interceptors>
 <home>
 <interceptor>org.jboss.proxy.ejb.HomeInterceptor</interceptor>
 <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
 <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
 <interceptor>org.jboss.proxy.ejb.RetryInterceptor</interceptor>
 <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
 </home>
 <bean>
 <interceptor>org.jboss.proxy.ejb.StatelessSessionInterceptor</interceptor>
 <interceptor>org.jboss.proxy.SecurityInterceptor</interceptor>
 <interceptor>org.jboss.proxy.TransactionInterceptor</interceptor>
 <interceptor>org.jboss.proxy.ejb.RetryInterceptor</interceptor>
 <interceptor>org.jboss.invocation.InvokerInterceptor</interceptor>
 </bean>
 </client-interceptors>
 </proxy-factory-config>
 </invoker-proxy-binding>

Maybe this forces the load-balancing, no matter which port I connect to??

Otherwise, how could I call my EJBs and make sure the call only goes to one of the nodes?

Thanks
Martin

[brian.stansberry]

Possibilities include:

1) Don't mark the bean as clustered if you don't want it clustered. The only clustering behavior an SLSB has is failover and loadbalancing; if you don't want that then there is no point making the bean clustered.

2) Only deploy the bean on the server you want, or deploy it in deploy-hasingleton so it's only active on one server.

3) Use FirstAvailable or FirstAvailableIdenticalAllProxies as your load balance policy. These will give varying degrees of server affinity, although the server they initially pick is still random, and each client will independently pick.

4) Some custom load balance policy, perhaps along with a custom interceptor that tells the policy which server to target.

The solution depends on what you want; i.e. why load balancing is bad and what server you want the call to go to.

[marlig]

Actually, load-balancing is not bad at all. It's just that our testers should test the system before it goes into production, and they should of course test a system that is as close to the final production version as possible.

This pretty much rules out all the options you have mentioned. But that's not really a problem, we can live with it. Though it would have been nice if the tester could have called the server and would have known exactly where the call went to. No need to search through the logs afterwards to find out where the call actually went to.

Anyway, I've learnt something new about JBoss clustering, and that's fine. :-)

Cheers
Martin