2 Replies Latest reply on Jun 17, 2004 12:10 PM by David Budworth

    HA-JNDI "there but not"

    hank Newbie

      I am unable to use a clustered HA-JNDI lookup.
      using load jboss-3.2.4RC2, j2sdk1.4.2_04 on Linux.

      I have a clean default jboss install and run from the 'all' deployment.
      I bind a hashtable to the HA-JNDI using the HA-JDNI properties as described in the "JBoss As Clustering" manual, page 43:
      INITIAL_CONTXT_FACTORY is org.jnp.interfaces.NamingContextFactory
      URL_PKG_PREFIXES is jboss.naming:org.lnp.interfaces
      PROVIDER_URL is localhost:1100

      The initial JBoss instance comes up fine and a startup class binds the hashtable (named "ATL") to HA-JNDI. I am able to store and retrieve values in the hashtable.

      I bring up a second identical instance of JBoss on another box. From the trace I can see that the two instances discover each other. The startup class first checks to see if HA-JDNI has a bound "ATL" hashtable, see's that it does, so no need to create one.

      But that is about all the second JBoss instance can do with the ATL hashtable. The second JBoss can obtain a reference to the ATL hashtable and call its methods, except that get always return null. Odd that I can both obtain a reference and call methods to no effect. Its there but its not.

      I tried not passing in a PROVIDER_URL, result was that each instance had its own working copy of an 'ATL' instance.


        • 1. Re: HA-JNDI
          Nicholas Whitehead Novice

          Are you sure that the contents of the hashtable are serializable ?


          • 2. Re: HA-JNDI
            David Budworth Newbie

            I believe that items stored in JNDI are stored as serialized objects.

            Basically meaning that when your first server started, it created a new (empty) map and stored it in the JNDI tree. At that point, it was serialized as an empty map.

            Every subsequent lookup would then be getting the empty map.

            What leads me to think this is that with HARMI stubs, you must re-bind the object every time the replicant group changes. Which sounds like it's stored serialized, rather than as a live instance.

            If you are looking to just share data between nodes in a cluster, DistributedState is probably what you are looking for.

            Otherwise, you may have to rebind the MAP back to ha jndi every time you modify it. Which isn't really a valid approach as you'll get your nodes overwriting each other.

            The JNDI = serialized thing is just a guess, I haven't looked in to the code to be sure. But I do know that when I change things stored in JNDI, I must re-bind them to the tree so the next time it's looked up it's a 'current' object.

            Hope that helps,