glassfish
  1. glassfish
  2. GLASSFISH-3888

Can't create new InitialContext with different host

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 9.0pe
    • Fix Version/s: 4.0
    • Component/s: orb
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      3,888

      Description

      Following client code:
      package test;

      import java.util.Properties;
      import java.util.logging.Level;
      import java.util.logging.Logger;
      import javax.naming.InitialContext;
      import javax.naming.NamingException;
      import org.logicstreams.server.engine.service.StatusService;

      /**
      *

      • @author Marek Mosiewicz
        */
        public class GlassfishTest {

      public static void main(String args[]) {
      try

      { Properties props = new Properties(); props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost"); props.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); InitialContext ic; ic = new InitialContext(props); ic.lookup(StatusService.class.getCanonicalName()); props = new Properties(); props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming"); props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); //change host to non existing one props.setProperty("org.omg.CORBA.ORBInitialHost", "bleee"); props.setProperty("org.omg.CORBA.ORBInitialPort", "3700"); ic = new InitialContext(props); //lookup succesed ic.lookup(StatusService.class.getCanonicalName()); }

      catch (NamingException ex)

      { Logger.getLogger(GlassfishTest.class.getName()).log(Level.SEVERE, null, ex); }

      }
      }
      will succeed althogh second host does not exists. Glassfish will always connect
      to first entered server no matter I will change parameters for second
      InitialContext. Same with port number.

      Marek Mosiewicz
      http://www.jotel.com.pl

        Activity

        Hide
        Ken Cavanaugh added a comment -

        I think what is probably happening is that the first InitialContext
        sets up the single shared ORB instance that is used to communicate with
        the server ORB using CosNaming. After that, a subsequent attempt to
        set initial host and port is ignored, because the ORB has already been
        created.

        This is currently the way this is designed to work, and there is no
        workaround at the new InitialContext level. CosNaming is flexible
        enough to get around this, by binding the root naming context of the
        second host into the namespace of the name service running on the first
        host, but I don't know if there is a reasonable workaround with GlassFish.

        It might be more helpful to broaden your issue and to understand what
        you are trying to do, to see if there is a better way to approach the
        problem.

        Show
        Ken Cavanaugh added a comment - I think what is probably happening is that the first InitialContext sets up the single shared ORB instance that is used to communicate with the server ORB using CosNaming. After that, a subsequent attempt to set initial host and port is ignored, because the ORB has already been created. This is currently the way this is designed to work, and there is no workaround at the new InitialContext level. CosNaming is flexible enough to get around this, by binding the root naming context of the second host into the namespace of the name service running on the first host, but I don't know if there is a reasonable workaround with GlassFish. It might be more helpful to broaden your issue and to understand what you are trying to do, to see if there is a better way to approach the problem.
        Hide
        marekmosiewicz added a comment -

        I want to have dialog to choose server I want to connect. But there is also
        option to verify given connection so there is possible to choose try many
        different connections in application.

        I believe that creating new initial context SHOULD connect to new server. If
        there is shared ORB maybe it should return different part of subtree in this
        case which binds to different server.

        Initial Context is standrd way to connect EJB server not CORBA (we want to
        connect to different servers too) (not mentioning servapp-rt.jar which is
        limited to one server only)

        Show
        marekmosiewicz added a comment - I want to have dialog to choose server I want to connect. But there is also option to verify given connection so there is possible to choose try many different connections in application. I believe that creating new initial context SHOULD connect to new server. If there is shared ORB maybe it should return different part of subtree in this case which binds to different server. Initial Context is standrd way to connect EJB server not CORBA (we want to connect to different servers too) (not mentioning servapp-rt.jar which is limited to one server only)
        Hide
        marekmosiewicz added a comment -

        I looked into the code and it would be not difficult to change it.
        com.sun.enterprise.naming.SerialInitContextFactory calls for
        ORBManager.getORB(Properties) where is static reference to ORB. It ignores
        properties if there is already ORB instance.

        I could aplly patch for it if it would be accepted. There are two solutions I
        see. One add some refresh.orb property to initial context properties which will
        force refresh. Second is to remember host and port and make new orb if it
        changed (but there maybe also other properties which can change)

        This issue also not work if you first connect to not existing host. Then there
        is no way to get new host.

        Show
        marekmosiewicz added a comment - I looked into the code and it would be not difficult to change it. com.sun.enterprise.naming.SerialInitContextFactory calls for ORBManager.getORB(Properties) where is static reference to ORB. It ignores properties if there is already ORB instance. I could aplly patch for it if it would be accepted. There are two solutions I see. One add some refresh.orb property to initial context properties which will force refresh. Second is to remember host and port and make new orb if it changed (but there maybe also other properties which can change) This issue also not work if you first connect to not existing host. Then there is no way to get new host.
        Hide
        Ken Cavanaugh added a comment -

        Changed target to V3.

        A few thoughts on this:

        1. It's unfortunate that the naming client is bound to the ORB. Creating an ORB
        is a fairly heavy-weight operation, and we do not want to create multiple
        ORBs just for handling this case.

        2. This entire mechanism does not work well in a cluster. We have made all EJB
        references support IIOP failover, but the bootstrap does not, which creates a
        single point of failure.

        3. The code example makes sense: it's the internal GlassFish implementation that
        is incorrect. But it's not just an ORB problem: it spans the ORB, GlassFish,
        SerialContextFactory, and the JNDI CosNaming provider.

        What is needed here is a different path through the naming provider to get
        a root naming context without binding the root naming context to the ORB
        instance. Keeping the same APIs makes sense, and so we need to change
        the context provider initialization to create an appropriate IIOP URL for
        the desired name service instance while using the ORB instance in the
        GlassFish server. This is probably doable, but more investigation of the
        naming code is required.

        Show
        Ken Cavanaugh added a comment - Changed target to V3. A few thoughts on this: 1. It's unfortunate that the naming client is bound to the ORB. Creating an ORB is a fairly heavy-weight operation, and we do not want to create multiple ORBs just for handling this case. 2. This entire mechanism does not work well in a cluster. We have made all EJB references support IIOP failover, but the bootstrap does not, which creates a single point of failure. 3. The code example makes sense: it's the internal GlassFish implementation that is incorrect. But it's not just an ORB problem: it spans the ORB, GlassFish, SerialContextFactory, and the JNDI CosNaming provider. What is needed here is a different path through the naming provider to get a root naming context without binding the root naming context to the ORB instance. Keeping the same APIs makes sense, and so we need to change the context provider initialization to create an appropriate IIOP URL for the desired name service instance while using the ORB instance in the GlassFish server. This is probably doable, but more investigation of the naming code is required.
        Hide
        sanandal added a comment -

        "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
        release whose primary release driver is SailFin.
        This issue will be scrubbed after this release and will be given the right
        priority for the next release."

        Show
        sanandal added a comment - "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1 release whose primary release driver is SailFin. This issue will be scrubbed after this release and will be given the right priority for the next release."
        Hide
        Ken Cavanaugh added a comment -

        Moving to v3.1.

        Show
        Ken Cavanaugh added a comment - Moving to v3.1.
        Hide
        Ken Cavanaugh added a comment -

        I THINK this should in GF3.1. I should write a test and see if it does
        or not.

        Show
        Ken Cavanaugh added a comment - I THINK this should in GF3.1. I should write a test and see if it does or not.
        Hide
        Ken Cavanaugh added a comment -

        No time to write test and make sure this is fixed in 3.1.
        Deferring to 3.2. Proper use requires setting an IIOP URL
        for the endpoints, rather than ORBInitialHost/Port, which as
        noted only applies the first time the ORB is created.

        Show
        Ken Cavanaugh added a comment - No time to write test and make sure this is fixed in 3.1. Deferring to 3.2. Proper use requires setting an IIOP URL for the endpoints, rather than ORBInitialHost/Port, which as noted only applies the first time the ORB is created.
        Hide
        salocinxxx added a comment -

        Hi - is this issues meanwhile solved ? Thanks

        Show
        salocinxxx added a comment - Hi - is this issues meanwhile solved ? Thanks

          People

          • Assignee:
            Harshad Vilekar
            Reporter:
            marekmosiewicz
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: