We got error logs on the servoy server admin site, but we have no idea about the meaning and how to fix that.
Is there anybody who can explain what the reason is and what’s to do?
Thank you for help,
Thomas
It means that the server can no longer reach the client in question. This is a typical error if, for example, a laptop user closes the laptop while Servoy is running and the OS suspends.
We have only desktop computers without set in sleep or hibernate mode in that network! If the clients are running for a while, it seems that the server connection get lost and not all functions in the methodes would be finished. For example a find + search methode returns ‘no record found’, although the record exists defnetly and was found by the same methode an hour before.
We have always Servoy Server/Client problems with error messages in the server log. But I don’t understand what the real problem is. What does it mean ‘Signalling channel lost…’ (please take a look on the attached file)?? And why removing ports to 3002, 3004…? I thought the port is 1099 (that is what I have set)! In the network area there is no computer (mac) in sleep or hibernate mode, firewall settings are off and all other network activities are working perfect. What is the best network setting in servoy-admin and how can I fix that problem?
Thank you for help
Thomas
Are the clients using dhcp? How is the refresh rate of addresses?
Hi Patrick!
No, DHCP is disabled and all the network depends on static IP’s.
Ok. Anyway: the error means, the clients cannot be reached when the server tries to send a notification. So something on the way from server to client is “broken”, maybe only for a short time. It could be a bad hub or something like that as well. Usually, Servoy clients recover from connection drops. However, data broadcasting is not reliable anymore if a client “missed” a message.
Thank you Patrick, this helps because sometimes we need a confirmation of our ideas about the issues. Do you have one more tip how should be the Servoy Server Network settings?
I have set:
java.rmi.server.hostname: ‘Server IP’
servoy.rmiStartPort: 1099
rmi.connection.timeout: 10
ApplicationServer.pingDelay: 30
SocketFactory.useTwoWaySocket: true
SocketFactory.useSSL: false
Could it be better with setting more memory?
System Information is:
runtime.allocatedMemory=68240K
runtime.usedMemory=41336K
servoy.initialClientHeap: 256
servoy.maxClientHeap: 512
best regards, Thomas
We usually do not fill the server.hostname (except on Linux).
Our connection.timeout is 120 (default), the ping relay 300 (default). We also use SSL. As far as I know, the 120 is the default for the timeout. Maybe yours is just too short.
Ok, I have changed the servoy-server settings to default, replaced the network cable connections, installed a brand new managed switch, but no improvement. Ok, that is not complete correct, because I got no more server log errors. In the meantime I could find out, that the problem/issue occurs the longer the client is running. After a restart the solution works fine for a couple of hours (sometimes one, sometimes two to three or four). Could it be a chache and/or memory issue?
Thomas
Wait: if you have no more errors in the server, then you successfully solved these connection timeouts.
What other problem do you have now? Clients get slower and slower?
Yes, the longer the solution/clients are running, the performance get slower and slower. That means changing forms, displaying valuelists, creating new records and so on takes a lot more time than before. Also funtions don’t work correct and we get curious system messages.
p.s.
A curious message for example is: “No form selected for print”!?
One minute before the print methode worked perfect…
Have you made sure that there are no errors especially from calculations (the little yellow warning sign in the lower left corner). Once you have errors in calcs, things really slow down.
No calculation errors! On some print forms only printSliding errors.
Then I really don’t know. We do not observe this.
Thank you very much for your effort and replays! Now I have an idea how to search and find the reason of the issues. Hopefully successful. I will post the result in this topic.
Kind regards, Thomas
Now a short report:
I could fix a couple of the discribed problems by
- relocating the server settings to default
- setting down the client memory to 256/128
- adding the function <databaseManager.updateUI(500)> into the onShow methodes
- deleting the .servoy properties file in the user directory on the client macs
- downloading a new servoy_client.app