[JBoss-user] [EJB/JBoss] - Potential Bug when looking up on localhost

2004-06-16 Thread bruciadmin 
Hi There,

I hope this is the right place to post this, I think I've found a bug with the naming 
component of JBoss 3.2.4.  I've tested with JDK 1.4.2_02 and 1.4.2_04. This problem 
was not in the previous version we were using (3.2.3) and was discovered initially 
upon upgrade. The problem seems to manifest when I configure the JBoss servers JNDI 
bound interface to the loopback (localhost).

It appears that JBoss itself is working, but the lookup is failing (the client code, 
not the server).  Every attempt to lookup the home interface results in the following:

javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: 
Connection refused to host: 192.168.X.X; nested exception is: 
java.net.ConnectException: Connection refused: connect]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:647)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:507)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at 
au.com.distillery.iqore.utilities.ejb.test.JNDILookupTest.testJNDILookup(JNDILookupTest.java:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:392)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:276)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:167)
Caused by: java.rmi.ConnectException: Connection refused to host: 192.168.1.26; nested 
exception is: 
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:567)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:528)
... 18 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:452)
at java.net.Socket.connect(Socket.java:402)
at java.net.Socket.(Socket.java:309)
at java.net.Socket.(Socket.java:124)
at 
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22)
at 
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:562)
... 23 more


For a long time I tested various scenarios, and everything points to an error on the 
client. I've tested this against a fresh jboss installation with only one change to 
the configuration (the bind interface for JNDI is localhost).  I eventually got 
annoyed enough to write a simple testcase which I've included below.

public class JNDILookupTest extends TestCase
{
  public void testJNDILookup() {
Context ctx = null; 
Hashtable ht = new Hashtable(); 
ht.put(Context.INITIAL_CONTEXT_FACTORY, 
org.jnp.interfaces.NamingContextFactory); 
ht.put(Context.PROVIDER_URL, jnp://localhost:1099);
CommandManagerHome home = null;
try { 
  ctx = new InitialContext(ht); 
  String lookupClassName = CommandManagerHome.class.getName();
  home = (CommandManagerHome) ctx.lookup(lookupClassName);
} catch (Exception e) { 
  e.printStackTrace(); 
} finally { 
try { 
ctx.close(); 
} catch (Exception e) { } 

} 
assertTrue(home != null);

  }
}


Please help or confirm the issue, a workaround isn't hard to implement (just don't use 
localhost) but I would rather not.

Thanks,

David L

View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3839033#3839033

Reply to the post :

[JBoss-user] [Clustering/JBoss] - Re: How to clear HAJNDI's HARMI stub being cached in NamingC

2004-06-16 Thread budworth 
Hi Scott, thank you for the response. (sorry for my delay, got side tracked for quite 
a bit)

Your example works fine, but if you auto-discover the host, it won't.

Simply change your

  | env.setProperty(Context.PROVIDER_URL, localhost:1100);
  | 

to:


  |   env.setProperty(Context.PROVIDER_URL, );
  |   env.setProperty(jnp.partitionName,DefaultPartition);
  | 

And you'll find the second lookup fails.

I tracked it down to the URL - NamingContext cache.

Upon getting a RMI failure, it removes the 'url' from the cache and throws a 
CommunicationsException Problem is, the 'URL' key in the cache doesn't seem to 
match, because on next lookup, it just gets the cached version back.

If you wait long enough (set the sleep to 5 minutes), you'll get the weak ref to 
expire and the lookup to occur again.

I know it's not specifically an issue with the muilticast locator code, as in my 
project I've implemented my own mcast server/locator/IC factory... 

And my IC factory composes a targetd HOST:1100 url matching the discovered host sets 
up some props and passes it to the jboss NamingContext.

So it's somewhere in the NamingContext class.

-David

View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3839034#3839034

Reply to the post : 
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3839034


---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

[JBoss-user] [Clustering/JBoss] - Re: How to clear HAJNDI's HARMI stub being cached in NamingC

2004-06-16 Thread budworth 
Forgot to mention, it's happening in 3.2.3, as well as 3.2.4


View the original post : 
http://www.jboss.org/index.html?module=bbop=viewtopicp=3839035#3839035

Reply to the post : 
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3839035


---
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

<    1   2