Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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?
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.
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?