[jboss-jira] [JBoss JIRA] Commented: (JBAS-1984) HttpNamingContextFactory unable to reconnect

[Adrian Brock (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12428086#action_12428086 ] 

Adrian Brock commented on JBAS-1984:
------------------------------------

I think this should be a feature request since you should always recreate the InitialContext
after an "IOException".

It only works for jnp by "accident". The "stub" lookup on the bootstrap port 1099 is lazy
and cached for jnp. When we get an I/O exception we clear the cache .

This is actually because otherwise the stale cached version would mean you could never recreate the
InitialContext due to the way the RMI protocol works (not because it is intended to provide
a semi-transparent failover mechanism).

For HTTP the "stub" lookup is not lazy. If it tries to reconnect, it will use the jnp bootstrap mechanism
which will fail since it has the wrong information in the provider url (and is the wrong protocol anyway).

Incidently, for HTTP we don't need to clear the cache because the protocol is stateless unlike RMI.

So there are two possible "fixes":

1) A way to tell NamingContext not to flush the cache for HTTP when an I/O Exception occurs
so we can take advantage of the stateless behaviour.

2) A way to override the (re)connect logic in NamingContext.getServer(host, port, refEnv)
so the HTTPNamingContextFactory can tell it to use the http mechanism.

The second solution would also have the advantage that it could be lazy about retrieving
the stub, i.e. HTTPNamingContextFactory could just do 

// Parse/check the env and prefix
return new NamingContext(env, prefix, null);

like the jnp version.

In practice, some element of both solutions would be desirable.

> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
>                 Key: JBAS-1984
>                 URL: https://jira.jboss.org/jira/browse/JBAS-1984
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: XP
>            Reporter: Bernd Eckenfels
>            Assignee: Emanuel Muckenhuber
>             Fix For: JBossAS-5.0.1.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> 	at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> 	... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> 	... 4 more
> Caused by: java.net.UnknownHostException: http: http
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> 	at java.net.InetAddress.getByName(InetAddress.java:958)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> 	... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> 		p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> 		p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> 		p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> 		p.put("jnp.disableDiscovery", "true");
>                Context rootCtx = (Context)new InitialContext(p);
> 		while(true)
> 		{
> 			try
> 			{
> 			// rootCtx = new InitialContext(p);
> 			Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> 			l = jmxCtx.list("");
> 			while(l.hasMore())
> 			{
> 				System.out.println(" - " + l.next());
> 			}
> 			} catch (Throwable t) {
> 				System.out.println("ex: " + t); t.printStackTrace(System.out);
> 			}
> 			try{Thread.sleep(10000);}catch(Throwable t) { }
> 		}
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira