[JBoss JIRA] Commented: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Adrian Brock (JIRA)
[ 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
17 years, 3 months
[JBoss JIRA] Closed: (JBAS-2766) tomcat libraries not available to remoting when using http transport
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-2766?page=com.atlassian.jira.plug... ]
Dimitris Andreadis closed JBAS-2766.
------------------------------------
Resolution: Won't Fix
Assignee: (was: Tom Elrod)
> tomcat libraries not available to remoting when using http transport
> --------------------------------------------------------------------
>
> Key: JBAS-2766
> URL: https://jira.jboss.org/jira/browse/JBAS-2766
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Remoting
> Affects Versions: JBossAS-4.0.4.CR2
> Reporter: Tom Elrod
> Priority: Critical
> Attachments: jboss-service.xml, remoting-service.xml, standardjboss.xml
>
>
> As of JBoss Remoting 1.4.0 final (which is now included for JBossAS 4.0.4 and JBossAS 5), the http transport implementation uses Tomcat connectors. Therefore, the following jars need to be available to remoting when running within JBossAS:
> tomcat-apr.jar
> tomcat-coyote.jar
> tomcat-http.jar
> tomcat-util.jar
> These are included in the jbossweb-tomcat55.sar directory, but are not on the classpath when the UnifiedInvoker is used (which uses remoting). So if use the http transport within remoting when using UnifiedInvoker, get errors since the needed classes are not found.
> BTW, does not matter if 'UseJBossWebLoader' is true or false within jbossweb-tomcat55.jar/META-INF/jboss-service.xml.
--
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
17 years, 3 months
[JBoss JIRA] Updated: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ]
Dimitris Andreadis updated JBAS-1984:
-------------------------------------
Component/s: (was: Remoting)
Fix Version/s: JBossAS-5.0.1.CR1
> 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
17 years, 3 months
[JBoss JIRA] Assigned: (JBAS-1984) HttpNamingContextFactory unable to reconnect
by Dimitris Andreadis (JIRA)
[ https://jira.jboss.org/jira/browse/JBAS-1984?page=com.atlassian.jira.plug... ]
Dimitris Andreadis reassigned JBAS-1984:
----------------------------------------
Assignee: Emanuel Muckenhuber (was: Tom Elrod)
Emanuel, this is an old issue. Do you want to check if it still current and get a stub at it? (after AS5)
> 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, Remoting
> Affects Versions: JBossAS-3.2.7 Final
> Environment: XP
> Reporter: Bernd Eckenfels
> Assignee: Emanuel Muckenhuber
>
> 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
17 years, 3 months
[JBoss JIRA] Created: (JGRP-821) Starting VERIFY_SUSPECT timer thread causes java.lang.IllegalThreadStateException
by Vladimir Blagojevic (JIRA)
Starting VERIFY_SUSPECT timer thread causes java.lang.IllegalThreadStateException
---------------------------------------------------------------------------------
Key: JGRP-821
URL: https://jira.jboss.org/jira/browse/JGRP-821
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.3, 2.7
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Fix For: 2.6.4, 2.7
I believe this is related to concurrent message processing of multiple suspect messages. Timer needs to be started while holding a lock - we properly publish thread references as well.
java.lang.IllegalThreadStateException
at java.lang.Thread.start(Unknown Source)
at org.jgroups.protocols.VERIFY_SUSPECT.startTimer(VERIFY_SUSPECT.java:293)
at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:240)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:122)
at org.jgroups.protocols.FD.up(FD.java:269)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:309)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
at org.jgroups.protocols.Discovery.up(Discovery.java:244)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1266)
at org.jgroups.protocols.TP.access$100(TP.java:49)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1809)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1788)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
--
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
17 years, 3 months