Our application requires a configuration of two JBoss clusters. For development, we use single-node clusters on one machine, each bound to different host names. Clusters are separated in different mcast spaces (and have unique partition names, to prevent JNDI autodiscovery).
Cluster A contains certain services and cluster B contains other services. Services in this case mean stateless session beans. In some cases, cluster B works as a delegate for cluster A. The communication between the clusters uses HTTPS. This has been live and working for some time now, on JBoss 3.2.3. In development, our application has been ported to JBoss 3.2.5, and we've been running this development version for many months on several machines. Because of certain issues, we need to update to 3.2.7. This is what I'm working on at the moment. The problem: after the update, JNDI lookups over HTTPS for session beans do not seem to work any more. When cluster B tries to get the naming context from cluster A, cluster A's JNDIFactory marshalls the naming context as it should, but then something goes wrong and cluster B seems to default to its own initial context. I'm trace logging org.jnp, org.jboss.naming and org.jboss.invocation.http on both sides. This is what I get from cluster A side: 2005-06-15 15:29:01,012 TRACE [org.jboss.invocation.http.servlet.NamingFactoryServlet.JNDIFactory] processRequest 2005-06-15 15:29:01,078 TRACE [org.jboss.invocation.http.servlet.NamingFactoryServlet.JNDIFactory] Serialized Naming proxy, size=1321 And this is from the cluster B: 2005-06-15 15:29:00,174 DEBUG [org.jboss.invocation.http.interfaces.Util] httpsConnClass: class javax.net.ssl.HttpsURLConnection 2005-06-15 15:29:00,183 TRACE [org.jboss.naming.HttpNamingContextFactory] Retrieving content from : https://[hostname]:8443/invoker/JNDIFactory 2005-06-15 15:29:01,094 TRACE [org.jboss.naming.HttpNamingContextFactory] ContentLength: -1 ContentType: application/x-java-serialized-object; class=org.jboss.invocation.MarshalledValue So, the logs would seem normal to me. The delegate in cluster B receives an InitialContext, and when I print out the environment for the context, it seems correct. But when I print out the bindings in it, I get cluster B's services. So I'm guessing that something has gone wrong and cluster B has defaulted to its own initial context. I just can't find any indication of what has gone wrong. If I configure cluster B to use cluster A's HA-JNDI (jnp://[hostname]:1100) instead of HTTPS, everything works. Does anyone have an idea what might be happening, or how to proceed in debugging this? A side note: during shutdown, I get stack traces like this: 2005-06-13 18:19:53,190 TRACE [org.jboss.naming.Util] Unable to remove context queue javax.naming.OperationNotSupportedException at org.jnp.interfaces.NamingContext.destroySubcontext(NamingContext.java:983) ... Are these entirely normal, or indication that something is wrong in the configuration? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3881588#3881588 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3881588 ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
