Clients Unable to Load Solutions

Classic Servoy
1

Hi,

We have a problem where some client machines can get to the “Select solution” dialog, but they are unable to load an actual solution (they just see the spinning logo). Here is what they get in the Java console:

Starting Servoy from C:\WINNT
Servoy R2 2.2.7 build-339 on Windows 2000 using Java 1.5.0_02
getWebStartURL http://10.3.51.15:8080/
getWebStartURL http://10.3.51.15:8080/
getWebStartURL http://10.3.51.15:8080/
java.net.ConnectException: Connection timed out: connect

This line comes up in the server log file each time one of these clients tries to open a solution:

impossible request,questiondata *= new Object();*
*```*
*We have found a "workaround", which is to use various ways of specifying the server's location. For example, using the hostname instead of the IP address might work on one machine, whereas only the fully qualified domain name might work on another machine, and even the vice versa can be true on other machines. What works one day might not work the next day. So right now all of our client machines have 3 Servoy icons, where hopefully at least 1 of them will work.*
*We're running Servoy R2 2.2.7 build-339 on Windows 2000 with Java version 1.5.0_02. In the network settings: java.rmi.server.hostname is blank, servoy.rmiStartPort is 1099, rmi.connection.timeout is 120, ApplicationServer.pingDelay is 300, SocketFactory.useTwoWaySocket is checked, and SocketFactory.useSSL is checked (but SSLKeystorePath and SSLKeystorePassphrase are blank).* 
*Any help would be greatly appreciated. Thanks!*
2

sammyzheng:
We’re running Servoy R2 2.2.7 build-339 on Windows 2000 with Java version 1.5.0_02. In the network settings: java.rmi.server.hostname is blank, servoy.rmiStartPort is 1099, rmi.connection.timeout is 120, ApplicationServer.pingDelay is 300, SocketFactory.useTwoWaySocket is checked, and SocketFactory.useSSL is checked (but SSLKeystorePath and SSLKeystorePassphrase are blank).

Any help would be greatly appreciated. Thanks!

Try to set java.rmi.server.hostname to 127.0.0.1, from what I read the problem is that the clients are not able to reach the server, are all the clients in the same LAN? Is there any NAT router between the server and the clients? Are you deploying over a WAN?
Take a look at the various JNLP files (the ones downloades from the server) in the client machines, and look for the address written there:

<jnlp spec="1.0+" codebase="http://192.168.0.30:8080" href="/servoy-client/servoy_client.jnlp">

it should be reachable by the clients (try to telnet to that address on port 1099).

3

Thanks. One thing I failed to mention is that the server does have multiple network interface cards. I’ll try putting in both 127.0.0.1 and the IP address of the correct network interface.

4

Unfortunately, setting java.rmi.server.hostname did not fix the problem.

All clients are on the same LAN as the server, and there are no NAT routers between the server & clients.

One thing I noticed is that if the client waits long enough, it eventually does load the solution (after several “connection timed out” error messages in the Java console). However, any actions within the solution take just as long as it did to get in (with more “connection timed out” messages in the Java console). So if an operator presses a button, it will look like the software is frozen for 3 or 4 minutes until that action goes through.

At this point, I think the biggest clue is this one line from the service_log.txt file. Any idea what it means?

impossible request,questiondata *= new Object();*
*```*
*Thanks*
5

This seems related to other issues that have been discussed on the forum on using SQL with arguments in 3.5.

The error you are getting means that somewhere a prepared SQL statement gets the wrong value. For example, when you do something like

var vQuery = 'SELECT... WHERE myId = ?'
var vQueryArgs = [myId];
controller.loadRecords(vQuery, vQueryArgs)

then that results in a prepared statement, where the value of myId is placed instead of the ?. Since a while ago, it seems that some datatypes fail to be passed right to the arguments.

6

Do you see that same error message in the server log? We are currently using Servoy 2.27 and we don’t have any prepared SQL queries in our solutions.

7

sammyzheng:
Unfortunately, setting java.rmi.server.hostname did not fix the problem.

Have you tried to delete the Java cache on the client and redownload the JNLP from the server? Can you post the content of the JNLP file?

8

Yeah, clearing & redownloading the Java cache does not fix the problem. Here is an example of one of the JNLP files (created by a deep link to the solution):

<jnlp spec="1.0+" codebase="http://10.3.51.15:8080" href="/servoy-client/servoy_client/MSW4242_NDC_Data_Collection_System.jnlp">

This one uses the IP address, which works on some computers, whereas others have to use the fully qualified domain name or just the hostname. Currently there are at least two computers where none of the three methods work properly, so we can’t use those computers for Servoy at all.

UPDATE: I was just testing various shortcuts on one of the machines where IP address, FQDN, and hostname all do not work. I found that the problem only exists for this one solution called “MSW4242_NDC_Data_Collection_System”. We have 2 other solutions on that same server, and both of them work just fine on this computer (regardless of whether the shortcut uses IP address, FQDN, or hostname).

So the problem is specific to just this one solution, and it causes that “impossible request” error message. Is there any way to track it down?

Thanks.

9

At this point I think you best option is o create a case in the support system, it’s too strange to be a misconfiguration problem.

10

Okay, thanks again!