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

Transport null if websocket connectTimeout exceeds and reconnect fails in Javascript #627

Open
sandaruny opened this Issue Jan 14, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@sandaruny

sandaruny commented Jan 14, 2016

If I set the connectTimeout to a limited time and if the websockets headers are not updated before it handshake, websocket org.cometdWebsocketTransport fails on delayedHandshake. So it displays a transport null error in the console.

Isn't it better to switch to Long Polling or any other available transport when websocket transport expires?

@sbordet

This comment has been minimized.

Show comment
Hide comment
@sbordet

sbordet Jan 14, 2016

Member

Switching to long polling is how it is supposed to work.
Are you sure you have configured the server properly ?
Do you have server-side and client-side DEBUG level logs for this issue ?

Member

sbordet commented Jan 14, 2016

Switching to long polling is how it is supposed to work.
Are you sure you have configured the server properly ?
Do you have server-side and client-side DEBUG level logs for this issue ?

@sandaruny

This comment has been minimized.

Show comment
Hide comment
@sandaruny

sandaruny Jan 18, 2016

Yes I have all working and I tested it with dojo client without timeouts and when websocket is disabled it successfully initiate and continue the long polling transport. This happens when we set a timeout at the params with

connectTimeout : 2000

If the headers are not received before 2 seconds the websocket transport is closed. But if headers are received after that 2 seconds console gives the warning about transport null issue.

What I am suggesting is that we should switch to the next transport and wait for another 2 seconds whether it fails or not. I tried to implement it outside the basic library as a wrapper but it was not successful yet as even I removed a transport, some handlers are giving errors in due to null transport at the registry. I think its better to reshape how the lib work.

PS: This happened at the first time due to a congestion at the network side. As long polling is more promising in that case and I noticed that if websocket is timed out nothing happens afterwards.

sandaruny commented Jan 18, 2016

Yes I have all working and I tested it with dojo client without timeouts and when websocket is disabled it successfully initiate and continue the long polling transport. This happens when we set a timeout at the params with

connectTimeout : 2000

If the headers are not received before 2 seconds the websocket transport is closed. But if headers are received after that 2 seconds console gives the warning about transport null issue.

What I am suggesting is that we should switch to the next transport and wait for another 2 seconds whether it fails or not. I tried to implement it outside the basic library as a wrapper but it was not successful yet as even I removed a transport, some handlers are giving errors in due to null transport at the registry. I think its better to reshape how the lib work.

PS: This happened at the first time due to a congestion at the network side. As long polling is more promising in that case and I noticed that if websocket is timed out nothing happens afterwards.

@sbordet

This comment has been minimized.

Show comment
Hide comment
@sbordet

sbordet Jan 18, 2016

Member

Without exact CometD version and logs I cannot help you.
There are tests in the test suite that prove that the scenario you describe works fine.
Can you please attach client-side and server-side DEBUG logs ?

Member

sbordet commented Jan 18, 2016

Without exact CometD version and logs I cannot help you.
There are tests in the test suite that prove that the scenario you describe works fine.
Can you please attach client-side and server-side DEBUG logs ?

@sandaruny

This comment has been minimized.

Show comment
Hide comment
@sandaruny

sandaruny Jan 18, 2016

These are the console logs. There are no stack traces in the server side.

WebSocket connection to 'ws://192.168.1.2/cometd' failed: WebSocket is closed before the connection is established.

14:34:31.083 Could not negotiate transport; client=[]

After this I think there should be a way to check other transports from the transport registry too. I am using 3.0.7

This doesnot happen if the network is good. If the response packets are dropped before the timeout, this happens and long polling is not initiated. Is it clear? ✌️

sandaruny commented Jan 18, 2016

These are the console logs. There are no stack traces in the server side.

WebSocket connection to 'ws://192.168.1.2/cometd' failed: WebSocket is closed before the connection is established.

14:34:31.083 Could not negotiate transport; client=[]

After this I think there should be a way to check other transports from the transport registry too. I am using 3.0.7

This doesnot happen if the network is good. If the response packets are dropped before the timeout, this happens and long polling is not initiated. Is it clear? ✌️

@sbordet

This comment has been minimized.

Show comment
Hide comment
@sbordet

sbordet Jan 18, 2016

Member

There already is code that checks for other transports.
What you reported are not the full logs in DEBUG level.
Can you please report the full DEBUG logs ? Client and server.

Member

sbordet commented Jan 18, 2016

There already is code that checks for other transports.
What you reported are not the full logs in DEBUG level.
Can you please report the full DEBUG logs ? Client and server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment