When using self-signed, multiple connections crashes server

[amishshah]

So I'm hosting a Web Socket Server with a self-signed SSL license. It works until there is more than 1 connection. The third connection kills the server and it stops responding. The server runs on android and I'm connecting to it using WebSockets. Here's a stacktrace:

http://hastebin.com/uxoxalarab.avrasm

any ideas? thanks

[BrushfireDigitalServices]

The server should not crash/become unresponsive due to failed connections, but here it does. All three attempts in the stack trace are failing.

Are you sure that your client is configured to accept the current version of your self-signed certificate? The stack trace looks like that's the underlying issue to me.

I've tagged this as unclear until we can determine whether this is tied to an untrusted cert issue. If so, there's still likely diagnostics to be done.

[amishshah]

It should do, I went to https://192.168.0.8:25517/ (where my WSS server runs), accepted the certificate and opened websockets to it in chrome.

[BrushfireDigitalServices]

Ok. Adjusted tags accordingly. What is the source of the NPE on line 161 of the stack trace?

[amishshah]

I've no idea, although I updated the version of this library I'm using and now it doesn't error but it still crashes :\

[BrushfireDigitalServices]

We can still try to help sort it out. We recently changed WebSocketServer and SSLSocketChannel2, so it might be related to #307 or #171. Do you happen to know which commit of this library you were previously using?

Are you experiencing CPU or memory leak symptoms before or during the crash?

[amishshah]

I'm not sure, although it was fairly old. I think 1.3.0?

I will check for CPU and memory leaks tomorrow ;)

Thanks for your help!

edit: I don't think that there would be any leaks (but I'll still check), if there were the application would be totally unresponsive and get sluggish, but that's not the case.

[amishshah]

I don't believe there were any CPU or memory leaks, however I think there must be something wrong during the handshake as the onOpen event is not even called, and is also fixed by disconnecting the client and then reconnecting.

[amishshah]

I have found a development in this issue, and am very sure that is an isolated case within Chrome (not tested on other browsers). I just did a spam connect using Java and it was fine, there were no errors. This leads me to believe that you were correct @BrushfireDigitalServices, it seems that chrome is messing up something with SSL.