Client disconnects..

Classic Servoy
1

We are running Servoy version 5.1.4 -build 964 and are having the following logged on the server when our ArchiOffice clients get booted off. The problem seems random, and I’ve been unable to reproduce it.
More server information…
JDK Information
java.vm.name=Java HotSpot™ Client VM
java.version=1.6.0_32
java.vm.info=mixed mode, sharing
java.vm.vendor=Sun Microsystems Inc.

Operating System Information
os.name=Windows XP
os.version=5.1
os.arch=x86

Any help is much apprecated.

2012-06-05 17:40:14,262 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name temp_user_document_project_folder from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name temp_user_document_project_folder_filtered from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name temp_user_document_project_folder_tree from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name tmp_user_document_project_folder from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name tmp_user_document_project_folder_filtered from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name tmp_user_document_project_folder_tree from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:14,278 WARN [WrapperSimpleAppMain] com.servoy.j2db.persistence.Server - Table name user_pref_document_template_filter from server archioffice is too long (>30 chars) – this is not supported by all databases
2012-06-05 17:40:45,670 ERROR [pool-1-thread-1] com.servoy.j2db.persistence.Server - Final get connection failure for server ao2010 in 1 times
2012-06-05 17:40:55,311 ERROR [ClientExportNotifyListner[3]] com.servoy.j2db.util.Debug - Signalling channel lost when reading pings or client export notifies, removing ports: [3011]
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(Unknown Source)
at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at com.servoy.j2db.util.rmi.compressing.Zc.Za(Zc.java:27)
at com.servoy.j2db.util.rmi.compressing.Zc.read(Zc.java:46)
at java.io.DataInputStream.readInt(Unknown Source)
at com.servoy.j2db.util.rmi.Zj.run(Zj.java:21)

2

do you also have really problems in the clients?
This is just a clean up action because some client did disconnect, but that doesn’t have to be a problem

(why is this in the WebClient section?)

3

If this is the wrong forum, please move it Johan.

All clients are disconnected at the same time when the error is logged on the server. I didn’t post the whole log, there are many “Signalling channel lost when reading pings or client export notifies, removing ports: …” it’s not limited to just one client.

As per suggested here http://wiki.servoy.com/display/Serv52/N … d+settings, I changed the ApplicationServer.pingDelay from the default of 300 down to 150. The change has just been made and connections are lost about once a day (at inconsistent times) so we are still monitoring to see if it’s made a difference.

Are there other logs that I can initiate or view to troubleshoot the problem?
Thanks.

4

If all client loose there connection at the same time
then there is something in between that does that, that terminates those connections (a (nat) router or something)

what you also can try is to use the tunnel in Http&Socket mode to see if that is more stable.

5

Thanks Johan,

As per http://wiki.servoy.com/display/public/D … d+settings, I’ve made the following changes on the server,

SocketFactory.useTwoWaySocket: set to false
SocketFactory.rmiServerFactory: set to com.servoy.j2db.server.rmi.tunnel.ServerTunnelRMISocketFactoryFactory
SocketFactory.useSSL: set to true 1
SocketFactory.compress: set to true
and tunnel mode to http&socket

I’m unclear as to whether a change should be made on the clients too?
Thanks

6

This is a server side setting, no need for clients to do anything

7

Thank you Johan.
I’ve made the changes and we’re continuing to monitor the server. No repeat of the disconnects so far!

8

We have had only one mass dicsonnect this week, and the “usual” disconnect errors were not logged, so I think the change has really helped. We’re still monitoring…

Thanks for the support.

Mark.

9

So we’ve been having this same issue for the past week and a half (a redux of what we experienced back in 2008).

I made the changes suggested above and all seemed to go well until all the clients were booted from the server in the late afternoon.

Miraculously, this time a reboot of the app server was not required in order to enable the clients to be able to log back in.

And, the Signaling channel lost errors were replaced by:

multiplexer-reader-b113c7[SSL_NULL_WITH_NULL_NULL: Socket[addr=/10.1.1.30,port=1684,localport=1099]] ERROR com.sebster.tunnel.impl.sd multiplexer failed for client 07a9e0f7-f5eb-4d3c-be83-e3478add2c95

Client being kicked off the system were preceded by a dramatic slow to a crawl for everyone.

I look forward to any sage advice you have on this subject.