2 p.m.
[
https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug...
]
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