Hi, me again 
I noticed that when I press escape on my server that the client gets an ConnectorException
[java]
3-mei-2011 19:28:12 com.jme3.app.Application handleError
SEVERE: Uncaught exception thrown in Thread[com.jme3.network.kernel.tcp.SocketConnector@813bc1,5,main]
com.jme3.network.kernel.ConnectorException: Error reading from connection to:localhost/127.0.0.1:5050
at com.jme3.network.kernel.tcp.SocketConnector.read(SocketConnector.java:131)
at com.jme3.network.base.ConnectorAdapter.run(ConnectorAdapter.java:114)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.net.SocketInputStream.read(SocketInputStream.java:90)
at com.jme3.network.kernel.tcp.SocketConnector.read(SocketConnector.java:117)
… 1 more
[/java]
I’m just pressing escape on the server side and the above debug is what I get on client side. I also tried server.close();, in the destroy() method but it gives me exactly the same.
You close the server and the client gets an error saying the connection died?
What is it that you expected to happen?
I suppose SM could go and kick them all off first but the net effect is the same: error on the client, even if it’s a little different error.
Is it possible to somehow catch this error? Maybe a listener or something.
It happens in another thread so to me it seems like I might not even know it happened
Ah, I understand the issue now.
Up until a few days ago, JME snagged every exception from every thread to pass to the handleError() method. So some stuff like this was easy to slip through the cracks.
Hehe Wonder what other kinds of weird things await us since that change …
Sorry for the late reply. But is there a way to capture this? Because the error closes my client too…
If the error is closing your client then you can capture it. It is Applications’ handleError that is closing the app and you can always override that to be more selective.
It’s not the “right” way but it’s a way that will work until I hook up the error paths.
Any update on this? Seems like connection is killed before the destroy() method is called in SimpleApplication.
Even when doing
[java]
@Override
public void destroy() {
if (server.isRunning()) {
server.close();
}
super.destroy();
}
[/java]
It fails to close the connections before the connectorexception is thrown client side.
So still the best solution is overriding the handleError method?
When the server is shutting down through errors it is going to exit hard before all of the close messages make it out. When the JVM closes all of those sockets die.
Can you explain what you’d like to have happen on the clients when the server disappears?
Right, so the best way is to make a safe shutdown of the server I suppose, rather than killing the JVM.
Guess it would be stupid to believe it would not throw errors when killing the jvm.
Thanks anyways.
@pspeed said:
If the error is closing your client then you can capture it. It is Applications' handleError that is closing the app and you can always override that to be more selective.
It's not the "right" way but it's a way that will work until I hook up the error paths.
So is there a way to handle this client-side? I tried overriding the HandleError method, and it didn't catch the ConnectorException. I know that I can close the server correctly to prevent this, but say the server crashes for some unknown reason. I'd like the client to still function and at least show some output to the user as to why they got kicked out of their game.
Oh crap, you know, I’ve looked at that before and I completely forgot about it. Thanks pspeed!