1 Reply Latest reply on May 18, 2002 3:53 AM by Sacha Labourey

    partitions and lookupLocaly

    Dawid Newbie

      I created 2 partitions (P1 and P2) on 4 computers (C1-C4) - C1 and C2 belongs to P1; C3 and C4 belongs to P2. In partition P1 is deployed bean B1 and in P2 bean B2. Everything works fine, except small exception which server throws. Always when i.e. C1 (more generally from partition P1) try invoke bean B2 from P2 I have following exception:

      09:34:17,012 ERROR [HAJNDI] lookupLocally failed for B2
      javax.naming.NameNotFoundException: inubit not bound
      at org.jnp.server.NamingServer.getBinding(NamingServer.java:495)
      at org.jnp.server.NamingServer.getBinding(NamingServer.java:503)
      at org.jnp.server.NamingServer.getObject(NamingServer.java:509)
      at org.jnp.server.NamingServer.lookup(NamingServer.java:253)
      at org.jboss.ha.jndi.HAJNDI.lookupLocally(HAJNDI.java:230)
      at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:174)
      at java.lang.reflect.Method.invoke(Native Method)
      at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java
      at $Proxy22.lookup(Unknown Source)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:368)
      at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:352)
      at javax.naming.InitialContext.lookup(InitialContext.java:350)

      I understand this exception - "lookupLocaly" can not find B2 because it is of course not deployed on C1 (P1). I could not understand why "lookupLocaly" was processed if C1 don't belongs to P2 and doesn't have B2 deployed.

      After this exception all works fine because C1 in the end obtains reference to B2 (HA-JNDI takes references from other nodes in cluster).
      My question:
      What should I do that "lookupLocaly" was not process (invoke) for bean deployed in another partition and server doesn't throw this exception.

      best regards

        • 1. Re: partitions and lookupLocaly
          Sacha Labourey Master

          Hello Sojka,

          That's interesting.

          In your example, what I found strange is that when C1 needs to access some bean on C3, you need to understand that they have *nothing* in common: they are not the same node (trivial ) *and* they are not part of the same cluster.

          Consequently, when you do a lookup, you need to use an initial context that has been initialied with configuration properties that target a node from P2.

          Now, one thing for sure, we should probably modify HA-JNDI so you can initialize it by giving it a partition name. Otherwise, if you have two partitions on the same node, you may not tell with which partition you want to work. You can add this as a feature request for clustering on SF (*if it solves a real problem for you only*)