I have a client using a servoy solution hosted on a machine at my office;
the client can connect from his primary site (“site #1”), and until receintly,
was able to connect from a secondary site (“site #2”) with no problems.
now, he’s getting errors when he attempts to start servoy client from
site #2; when this occurs, I see errors in servoy server’s log as well.
the error seen on the client side is “you are disconnected from
the server. trying to reconnect”. the servoy client java console
shows this:
java.lang.NullPointerException
at com.servoy.j2db.util.a.g.<init>Unknown Source)
at com.servoy.j2db.util.a.c.run(Unkown Source)
repeated over and over many times, and then gives up with a message about no licensenes remaining.
meanwhile, the server shows the following messages:
2006-02-23 13:19 : java.rmi.ConnectException: Connection refused to host: 192.168.1.86; nested exception is:
java.net.ConnectException: Connection timed out: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at com.servoy.j2db.UserClient_Stub.getClientInfo(Unknown Source)
at com.servoy.j2db.dataprocessing.j.a(Unknown Source)
at com.servoy.j2db.dataprocessing.SQLEngine.register(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.(Unknown Source)
at java.net.Socket.(Unknown Source)
at com.servoy.j2db.util.a.d.createSocket(Unknown Source)
... 18 more
a really strange part of all this is, the ip address in the server log,
192.168.1.86, is not a node anywhere on our network (it’s a small
network, and I personally manage it, so I know every machine’s ip
address)
I checked with the guy who handles all the networks at
site #2, and he says nothing’s been changed in quite a while.
we were running ok from this site about two weeks ago.
as far as the 192.168.1.86 ip address, you’re right. it turns
out that’s the internal address of the machine we’re trying
to use with servoy client.
do you think this could be related to the ‘2-way socket’ setting?
we changed that a while ago to prevent disconnection errors
from occuring…
RobertMeyer:
do you think this could be related to the ‘2-way socket’ setting?
we changed that a while ago to prevent disconnection errors
from occuring…
Yes, it could be related if they are using a NAT/Firewall. Check also if they are using a proxy in combination with Java 1.5 on Windows clients, there are problems with Java 1.5 proxy settings.
Try to clear the client java cache and redownload the servoy client from the server. Or manually change “use two-way socket” on all clients, if it is modified on the server the change is not broadcasted to clients and must be manually applied.
I suggest you try some basic network debugging first. Try to connect on the relevant ports from the remote client to the server, i.e., ports 8080 and 1099. Try trace routes, pings, telnets to these ports, etc.. You can do all these things without even starting a Servoy client on the remote machine (but you must have Servoy server running). Only when all these things are working and Servoy is not, is it a problem with Servoy’s configuration…
according to the documentation for the ‘ping’ utility (I’m running
linux here), there doesn’t appear to be any way to specify
what port to use when sending ping packets.
when I telnet to port 8080 of the machine running servoy
server, and try a simple get request ("get /') I get the folloiwng
response:
<html><head><title>Apache Tomcat/4.0.1 - Error report</title><STYLE></STYLE> </head><body><h1>Apache Tomcat/4.0.1 - HTTP Status 501 - Method get is not defined in RFC 2068 and is not supported by the Servlet API </h1><HR size="1" noshade><p><b>type</b> Status report</p><p><b>message</b> <u>Method get is not defined in RFC 2068 and is not supported by the Servlet API </u></p><p><b>description</b> <u>The server does not support the functionality needed to fulfill this request (Method get is not defined in RFC 2068 and is not supported by the Servlet API ).</u></p><HR size="1" noshade></body></html>Connection closed by foreign host.
as strange as that response is, it does appear to be coming from the
tomcat server running on that machine, so I think that’s ok.
when I try to telnet to the rmi port on that machine, I don’t get any
response. could you tell me what to ‘say’ to the rmi port that would
tell me if it’s working and reachable?
Ping is just for determining if the machine is reachable at all (although this might not work in certain firewall configurations).
Telnet (or even better, netcat) can be used to test TCP ports. TCP port 8080 and 1099 should be reachable in the default configuration. BTW, the correct syntax for an HTTP get is with the protocol after the GET, i.e., GET / HTTP/1.0. Also you should use caps for the get.
As far as RMI is concerned, it’s a binary protocol and I don’t really speak it myself, and especially with SSL tunneling enabled it’s even more difficult to speak (I guess you could use openssl s_client to connect so you don’t have to do the encryption in your head). Anyway, you should be able to connect to 1099 and if you type some random stuff you should get this in your server log:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA6275)
Anyway, you not getting ANY connection to the RMI port suggests that either RMI is not on the default port, or it’s being filtered by a firewall. You should at least be getting connected.
the connection to port 8080 seems to be working fine;
if I do the correct request, I get back the servoy index.html
page as one would see in a browser
when I try sending some random characters to the rmi
port (thru telnet) I get back a message saying the connection
was closed by the remote host.
as an experiment, I opened another terminal window, and
telneted over to the server, and ran windump, to see if the rmi
traffic was getting to it, and it is. I can see the text I sent to the
rmi port, and I can see a response coming back from that port
to my machine here at the client site. although I can’t tell what’s
actually coming back from whomever is listening on the rmi port,
it would appear that I’m able to reach it from here.
also, my client is able to use servoy with no problems from their
other location (‘site #1’), just not from here (‘site #2’), so I’m thinking
the server, router, network, database, etc. are all operating properly.
Can you tell me the version of Servoy you are using? The null pointer exception is certainly strange, and also the message that you are disconnected from te server. I’ll have a look at it.
here’s the info from the admin page for the server:
Server Information
Servoy version R2 2.2.3-build 335, repository version 27
Current time: Wed Mar 01 10:34:47 EST 2006
Uptime: 1 day 18 hours 54 minutes 43 seconds
User Information
Logged in as: robertmeyer
JDK Information
java.vm.name=Java HotSpot(TM) Client VM
java.vm.version=1.4.2_10-b03
java.vm.info=mixed mode
java.vm.vendor=Sun Microsystems Inc.
Operating System Information
os.name=Windows XP
os.version=5.1
os.arch=x86
I could give you access to the server if you like.
rm.