InitialContext can not do lookup against separate endpoints

[chammerman]

Description

---

A naming exception is thrown if new endpoints are defined for an existing InitialContext object and lookup(SomeClass.class.getName()) is called. This seems to be because it continues to use the original endpoints defined instead of the new ones.

Expected Outcome

InitialContext should be able to be re-instantiated with new endpoints that replace the old ones and perform name lookups against those new endpoints.
This was the behavior in GF3 but became broken in GF4.

Current Outcome

InitialContext is instantiated with endpoints and a lookup(RemoteSessionBeanOnEndpoint1) is performed and returned successfully.
InitialContext is then re-instantiated with different endpoints (different server:iiop ports) and lookup(RemoteSessionBeanOnEndpoint2) fails with a NamingException because it is still attempting to connect to the former endpoints.

Steps to reproduce (Only for bug reports)

1. Create 2 separate payara server installs on two separate servers.

2. Create a Cluster on each server that use a different iiop listener port.

3. Create an instance for each cluster.

4. Deploy an application to each cluster where each application has a set of mutually exclusive remote session beans.

5. Create a client application/test that instantiates InitialContext using endpoints for the first server defined in a Properties Object and named "com.sun.appserv.iiop.endpoints"

       contextEnv.setProperty("com.sun.appserv.iiop.endpoints", "server01:21037");
       ctx = new InitialContext(contextEnv);

6. Perform a lookup to retrieve a remote session bean against the first server's application. It should succeed.

    ServerOneSessionRemote sosr = (ServerOneSessionRemote) ctx.lookup(ServerOneSessionRemote.class.getName());

7. Re-instantiate the InitialContext object with a new Properties Object using endpoints for the second server.

       contextEnv.setProperty("com.sun.appserv.iiop.endpoints", "server02:11037");
       ctx = new InitialContext(contextEnv);

8. Perform a lookup to retrieve a remote session bean against the second server's application. It will fail to find the bean and throw a NamingException.

    ServerTwoSessionRemote stsr = (ServerTwoSessionRemote) ctx.lookup(ServerTwoSessionRemote.class.getName());

Samples

    @Test 
    public void testMultiEndpoints() throws NamingException{
       InitialContext ctx;
        
       Properties contextEnv1 = new Properties();
       contextEnv1.setProperty("com.sun.appserv.iiop.endpoints", "prepaejb08.prep.appriss.com:11037,prepaejb09.prep.appriss.com:11037");        
       ctx = new InitialContext(contextEnv1);

       SiteAgencySessionRemote sasr = (SiteAgencySessionRemote) ctx.lookup(SiteAgencySessionRemote.class.getName());

       Properties contextEnv2 = new Properties();
       contextEnv2.setProperty("com.sun.appserv.iiop.endpoints", "devantejb11.dev.appriss.com:21037,devantejb12.dev.appriss.com:21037");
       ctx = new InitialContext(contextEnv2);
       InterfaceExecutionSessionRemote iesr = (InterfaceExecutionSessionRemote) ctx.lookup(InterfaceExecutionSessionRemote.class.getName());
 
    }

Here is the relevant stacktrace from the sample above:

javax.naming.NamingException: Lookup failed for 'com.appriss.core.interfaceexecution.InterfaceExecutionSessionRemote' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.corba.orb=com.sun.corba.ee.impl.orb.ORBImpl@425d5d46, java.naming.factory.url.pkgs=com.sun.enterprise.naming, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, com.sun.appserv.ee.iiop.endpointslist=corbaloc:iiop:1.2@prepaejb08.prep.appriss.com:11037,iiop:1.2@prepaejb09.prep.appriss.com:11037,iiop:1.2@prepaejb09:11037, com.sun.appserv.iiop.endpoints=devantejb11.dev.appriss.com:21037,devantejb12.dev.appriss.com:21037} [Root exception is javax.naming.NameNotFoundException: com.appriss.core.interfaceexecution.InterfaceExecutionSessionRemote not found]
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at com.appriss.core.stats.StatisticSearchRemoteTest.testMultiEndpoints(StatisticSearchRemoteTest.java:150)

FWIW com.sun.enterprise.naming.impl.SerialContext.lookup lives in glassfish-naming.jar

Context (Optional)

We have an application that loads and executes subclassed workflows written by other application teams.
The main application defines an InitialContext with endpoints. The subclass workflow also tries to define the super.ctx with different endpoints which causes their application to throw a naming exception and fail.

Environment

• Payara Version: 4.1.1.171.1
• Edition: Full
• JDK Version: 1.8.0_77
• Operating System: Server running on Linux (Sles12), Client tested from Mac OSX 10.11.4

[mikecroft]

Hi @chammerman I spent some time this week looking into this, but didn't have much luck reproducing. Do you have a "Short, Self Contained, Correct (Compilable), Example" that shows the problem?

My setup was slightly different to yours in that I created 2 "hello world" EJBs and deployed EJB1 to Payara Server instance 1 and EJB2 to Payara Server instance 2, so each lookup was only contacting a single endpoint rather than multiple endpoints.

[chammerman]

Hi Mike, I think that the single vs multiple endpoint item you mention is not the problem here. It should still reproduce that way. Are your hello world EJBs unique per server instance? If not then the test will always succeed because it is still referencing the first endpoint, which also has the object of desire. The only other thing I can think to check is to make sure the cluster iiop ports are not the same on Payara Server instance 1/2. (I have not verified if this matters, but it is how our system is currently set up.) It will take me a day or so to get the SSCCE together, which I assume would include the 2 test ejb applications and a compliable test. Let me know if I am missing anything else. Charles

[lprimak]

Internal issue PAYARA-1685

[chammerman]

@mikecroft @lprimak I was able to test with the patched version and I can confirm the issue is resolved. Thanks so much guys!