3 Replies Latest reply on Jan 4, 2013 5:16 AM by bernd.koecke

    No reuse of naming contexts with scoped EJB client context

    bernd.koecke

      I'm calling EJBs deployed on a JBossAS 7.2.0.Alpha1-Snapshot and I use the description from https://community.jboss.org/message/764451#764451 to generate the InitialContext from a Hashtable. But the naming context is never reused. My environment is:

       

      • Sun/Oracle Java 1.6.0.31 64-Bit Linux
      • JBossAS 7.2.0.Alpha1 from git
      • jboss-ejb-client 1.0.15.Final

       

      I create the InitialContext only once, but for each lookup through the InitialContext a new EJBNamingContext is created, which opens his own connections to all server nodes. The InitialContext only reuses a naming context from the naming provider when it was created from a factory configured by the Context.INITIAL_CONTEXT_FACTORY value from the JNDI environment. But the ejb client library uses the lookup URL scheme "ejb:". This causes a call to ejbURLContextFactory.getObjectInstance for each lookup. This context is only used for the resulting bean proxy.

       

      I would like to reuse the context for more than one bean proxy. So I build a small helper class for generating the context which gets the JNDI environment and use one entry as a key to store it

      in a map and reuse it when a context for the same cluster is needed. I expected to save resources (sockets, memory for the registry etc.), but because of the above it doesn't work.

       

      My question is, do I use it in the wrong way? Or do I misunderstand the meaning of reusing a naming context?

       

      I found two options to come around this:

       

      I can do my first lookup with the string "ejb:". This returns a subcontext which is a EjbNamingContext instance. When I store this in my helper classes map, I can reuse the context as expected.

      But the drawback is, that I don't have access to the EjbClientContext instance to register a listener for a context close event. And I have to remove "ejb:" from all lookup names.

       

      The other one is to use the ejbURLContextFactory.getObjectInstance directly. It is the only public available method. But then I loose the JDKs environment handling for the jndi.properties file.

      I don't use it at the moment. However when I need it, I could do

       

      {code}Context tmpCtx = new InitialContext(env);

      Hashtable<?,?> myEnv = tmpCtx.getEnvironment();{code}

       

      to get it and merge it with my own properties.

       

      Both options look a little bit hacky. I think I must be overlooking something, it would be nice when you can tell me what .

        • 1. Re: No reuse of naming contexts with scoped EJB client context
          jaikiran

          I'm not sure I understand the problem. Are you saying each lookup creates a different EJB client context instead of one per JNDI context?

          • 2. Re: No reuse of naming contexts with scoped EJB client context
            jaikiran

            Never mind, I just had a look at the code and it is a bug. Can you please file a EJBCLIENT JIRA for this one please?

            • 3. Re: No reuse of naming contexts with scoped EJB client context
              bernd.koecke

              I filed the issue: https://issues.jboss.org/browse/EJBCLIENT-59.

               

              To solve the issue might be a little bit tricky. I'm not a big expert of the JNDI SPI, but one option might be to use a value for Context.INITIAL_CONTEXT_FACTORY. Because the resulting context is stored and reused inside the InitialContext instance. But I don't know what the requirements of this factory is and how difficult it is to develop.

               

              With the current object factory it is difficult to decide that a context can be reused. I used a property in the JNDI environment. To be more precise I used the "endpoint.name" property and I think this will work for me in future. But I don't know if it is a good general solution. And I've done it in my code outside the ejb client lib. It doesn't need such a high quality like an implementation insde the ejb client lib.

               

              The reason why I'm thinking about the resource consumption is, because I want to let JBossAS 4.2.3 cluster be able to call beans on an AS7 cluster.

               

              Thanks a lot for your help!