Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OnClose is not called when client disconnect #900

Closed
kunluo2019 opened this issue Jun 5, 2019 · 16 comments · Fixed by #914
Closed

OnClose is not called when client disconnect #900

kunluo2019 opened this issue Jun 5, 2019 · 16 comments · Fixed by #914
Assignees
Milestone

Comments

@kunluo2019
Copy link

We just upgraded to the latest version. And I noticed that if client process is killed, On server side, onClose is not called. Instead after 30 seconds or so (related to default value in setConnectionLostTimeout), onClose is then called.

Because we were using a old version before, we know, in old version, if we kill the client process, server side, onClose is immediately get called.

Now, it does not do that.

I searched your bug report and found that bug #886 also described the similar situation.

Is this intented change? or there is way for server side to immediately know client socket disconnection?

@marci4
Copy link
Collaborator

marci4 commented Jun 11, 2019

Hello @kunluo2019,

no there were no (intentional) changes to that behaviour.

What two versions are you comparing?
Could you provide an example code?

Best regards,
Marcel

@kunluo2019
Copy link
Author

The issue can be reproduced by compiling sample ChatServer and ChatClient program with old/new websocket library.

After ChatClient is connected to ChatServer

In old version, if I kill ChatClient, ChatServer will immediately printout "has left the room!" message.

In new version, ChatServer won't print that message until the timeOut has reached (setConnectionLostTimeout(100) for 100 seconds in ChatServer code).

If you can tell me how to print the version info from the websocket.jar file, I can provide you corresponding old version number.

The new version is latest 1.4.0.

thanks

@marci4
Copy link
Collaborator

marci4 commented Jun 12, 2019

What is your old version?

@kunluo2019
Copy link
Author

I downloaded around Jan 2018, so it should be between 1.3.7 and 1.3.8.

I still have the corresponding source code.

Does the source code have embedded version number? If so, I can find out.

@marci4
Copy link
Collaborator

marci4 commented Jun 12, 2019

Pom.xml should contain the version.

Best regards,
Marcel

@kunluo2019
Copy link
Author

1.3.8

thanks

@marci4
Copy link
Collaborator

marci4 commented Jun 12, 2019

No I was not able to find any change that jump out.

Could you please provide a unit test which shows the issue?

Thank you!

Best regards,
Marcel

@kunluo2019
Copy link
Author

If you just compile the sample ChatServer and ChatClient that are in examples directory as part of Java-WebSocket, run it, you will see the issue.

In the latest version, if you kill ChatClient, ChatServer will not print "has left the room!" until 100 second timeout has reached.

If you need me to provide the old version, I can upload it for you.

thanks

@maiph
Copy link
Contributor

maiph commented Jun 12, 2019

I was able to reproduce it.

  1. Start the CharServer
  2. Start 2 ChatClient
  3. Press connect on both clients
  4. Kill one of the ChatClient
  5. The message "has left the room" takes a while to show

I didn't test an older version, only the current version on master 1.4.1-SNAPSHOT

Edit: Just confirmed v1.3.7 doesn't have this problem.

@marci4
Copy link
Collaborator

marci4 commented Jun 24, 2019

Was able to reproduce the issue!

Fixed it and steps to repeat work and currently working on a unit test.

Best regards,
Marcel

@marci4 marci4 added this to the Release 1.4.1 milestone Jun 24, 2019
@marci4
Copy link
Collaborator

marci4 commented Jun 28, 2019

To be honest I am not sure if I can even write a test for this issue.

Normally closing the socket of the WebSocketClient does not trigger the IOException since it is a normal close.
I would have to start a separate process for the client and kill this process, so the JVM then triggers the IOException on the server side.

Anyone else has an idea?

Best regards,
Marcel

@maiph
Copy link
Contributor

maiph commented Jun 28, 2019

Can you share the fix for this issue? Maybe that can give some insight on how to reproduce other than spawning a new process.

marci4 added a commit to marci4/Java-WebSocket-Dev that referenced this issue Jun 28, 2019
@marci4
Copy link
Collaborator

marci4 commented Jun 28, 2019

Pushed the changes to branch Issue900 (https://github.com/marci4/Java-WebSocket-Dev/tree/Issue900)

In short, the WebSocket was always null therefore close was never called when an IOException happened.

@maiph
Copy link
Contributor

maiph commented Jun 28, 2019

Can't we force the underlying socket to close using reflection ?

@marci4
Copy link
Collaborator

marci4 commented Jun 28, 2019

I tried it this way https://gist.github.com/marci4/6b47a9475d440a3dcd0d5212095d5ab3 and it just triggers a close due to eot() being called.

@Lloyd0577
Copy link

@marci4 use this 1.4.1.jar file ,build error :
com.android.builder.dexing.DexArchiveMergerException: Error while merging dex archives:
Learn how to resolve the issue at https://developer.android.com/studio/build/dependencies#duplicate_classes.
Program type already present: org.java_websocket.SSLSocketChannel

marci4 added a commit to marci4/Java-WebSocket-Dev that referenced this issue Jan 19, 2020
Overwrite channel to always throw IOException
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants