Servoy Forum

Hi guys,
I have a solution that is acting like a crazed animal. I have about 3 users accessing the solution - when they do find using ctrl F, it sometimes works, sometimes doesn't, sometimes it says it is in find mode, but doesn't display the find form. Sometimes after 3 or 4 finds, it locks up the solution, and the user is dead in the water. The latest escapade produced the following in the server logs, after crashing the solution.

2005-11-22 10:44 : Error flushing message buffer to client f699f36e-5b70-11da-9e03-a340a3769ddd, Connection refused to host: 172.16.136.142; nested exception is: java.net.ConnectException: Connection refused
2005-11-22 14:34 : Error flushing message buffer to client 0b7c8b87-5b9f-11da-9e03-a340a3769ddd, Connection refused to host: 172.16.136.142; nested exception is: java.net.ConnectException: Connection refused
2005-11-22 14:34 : Error flushing message buffer to client 0b7c8b87-5b9f-11da-9e03-a340a3769ddd, Connection refused to host: 172.16.136.142; nested exception is: java.net.ConnectException: Connection refused

I am running developer version 2.2.1 on a PC, accessing the repository on a UNIX machine in a sybase db. The server is running on the same Unix machine as the repository. I have released a couple new releases directly from the PC to the Unix machine.

Has anyone seen this behavior before - I don't have any problems when I run the application in the developer from the PC. My users so far are willing to be guinea pigs and debug the problem, but this is behavior I haven't seen at all.

Any ideas are appreciated

Thanks
Graham

In the Servoy admin page you can set a ping delay to keep connections open over strict filewalls/routers, it seems connections do timeout between client and server.

Hi Graham

As Jan suggests try reducing the ApplicationServer.pingDelay - one of my Clients had real problems with a Mac laptop - was improved when set pingDelay to 50 and virtually eliminated at 30. Although Server log is still showing some lost connections the Client is able to reconnect very quickly and no longer complains about 'lost' work.

For some reason have never had this problem with clients using Windows computers so may just be that *nix systems are more sensitive.

Regards

Graham Greensall
Worxinfo Ltd