-
1. Re: Remote server connection problem
poorboy Apr 22, 2004 4:23 AM (in response to poorboy)Small correction - should be "connection refused" not a time out. Would be nice to make these forums editable...
-
2. Re: Remote server connection problem
raja05 Apr 22, 2004 5:02 AM (in response to poorboy)have u enabled remote connections to be contacted .
i mean xhost + -
3. Re: Remote server connection problem
ibruell Apr 22, 2004 5:07 AM (in response to poorboy)Which OS do you use ? If you use redhat, check the host table.
-
4. Re: Remote server connection problem
poorboy Apr 22, 2004 5:09 AM (in response to poorboy)It's not done through a remote X session, but rather through the RMI mechanism. The client app runs on client machine and sends/receives messages to the server app.
-
5. Re: Remote server connection problem
poorboy Apr 22, 2004 5:28 AM (in response to poorboy)I'm using Mandrake Linux on the client, and Adamantix on the server. All hosts resolve properly on all machines. The same error happens with a Windows client too.
-
6. Re: Remote server connection problem
raja05 Apr 22, 2004 5:45 AM (in response to poorboy)Can you just ping from the client machine to the server? Are u able to get a response.
-
7. Re: Remote server connection problem
ibruell Apr 22, 2004 5:59 AM (in response to poorboy)Does the client software work if you install it on the client (not using JNLP) ?
-
8. Re: Remote server connection problem
poorboy Apr 22, 2004 7:18 AM (in response to poorboy)Yes, networking is fine - pings and things work as per normal. The app behaves equally badly from the command line.
java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused
at com.freedomwigs.client.gui.app.LoginScreen.manageException(LoginScreen.java:96)
at com.freedomwigs.client.gui.app.LoginScreen.authenticateAgainstServer(LoginScreen.java:179)
at com.freedomwigs.client.gui.app.LoginScreen.doLogin(LoginScreen.java:156)
at com.freedomwigs.client.gui.app.LoginScreen.access$0(LoginScreen.java:149)
at com.freedomwigs.client.gui.app.LoginScreen$1.actionPerformed(LoginScreen.java:198)
The doLogin method is ok, then calls authenticateAgainstServer which fails. It can lookup the LoginBeanHome interface but fails when creating the LoginBean EJB. The 127.0.0.1 is referring to the client machine. -
9. Re: Remote server connection problem
ibruell Apr 22, 2004 8:22 AM (in response to poorboy)I am a little bit confused. I think the authenticateAgainstServer is called cause you try to instantiate a Bean, right ?
Here how i set the properties:
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
prop.put(Context.PROVIDER_URL, "jnp://JBossServer:1099");
prop.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
ctx = new InitialContext(prop);
I have activated authentification, too. And it works well. -
10. Re: Remote server connection problem
poorboy Apr 22, 2004 10:57 PM (in response to poorboy)I had been setting the properties through the JNLP, and then through the lib/jnpi.properties file for the command line test. I removed those, and tried a command line test using the example code you gave. The first time was a timeout, after I forgot to change the server name (oops) but after fixing that, the result was another connection refused from 127.0.0.1. This happened with both the HTTPS and JNP interfaces.
What I think is happening is that it's looking up the EJB, and the server is telling it to get it from 127.0.0.1, rather than from the server's local network address....
... playing with it while replying ...
BINGO. :-D
While digging around looking for answers, I found that the server was in fact resolving itself to the external (nat'd www) IP address. This meant that the address used for this stuff couldn't get past the firewall. I noticed this while shutting down the server, it said the name wasn't bound. So as far as JBoss was concerned, it couldn't access 210.x.x.x, and it never knew about 192.168.0.10, so sending 127.0.0.1 was a perfectly resonably thing to do :-/ I'd actually fixed this yesterday while the server was up, but it didn't re-bind, so the fix didn't really get fixed until I restarted JBoss. Oops.
Thanks for the help folks.