While I was trying to integrate Upstox Ticker into my program, I saw that many disconnections are happening and reconnections as well.
Below are the various errors
Connection closed by remote peer. Info:
INFO Upstox - Upstox Connection closed by remote peer. Info: and code 1000 for 127656
ERROR Upstox - Upstox ticker Error for 127656
org.java_websocket.exceptions.WebsocketNotConnectedException
at org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:674)
at org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:664)
at org.java_websocket.WebSocketImpl.send(WebSocketImpl.java:669)
at org.java_websocket.client.WebSocketClient.send(WebSocketClient.java:440)
at com.broker.upstox.Upstox.sendSubscriptionRequest(Upstox.java:248)
at com.broker.upstox.Upstox$1.onOpen(Upstox.java:181)
at org.java_websocket.client.WebSocketClient.onWebsocketOpen(WebSocketClient.java:650)
at org.java_websocket.WebSocketImpl.open(WebSocketImpl.java:767)
at org.java_websocket.WebSocketImpl.decodeHandshake(WebSocketImpl.java:364)
at org.java_websocket.WebSocketImpl.decode(WebSocketImpl.java:237)
at org.java_websocket.client.WebSocketClient.run(WebSocketClient.java:516)
at java.base/java.lang.Thread.run(Thread.java:840)
INFO Upstox - Upstox Connection closed by us. Info: Invalid status code received: 401 Status line: HTTP/1.1 401 Unauthorized and code 1002 for 127656
Now, my logic is such that, when WebSocketClient#onClose listener is called, I manually invoke WebSocketClient#connect which is the reconnect mehanism used.
And then I see that, since the ticker tried to reconnect manually (when disconnected) it was called multiple times, finally Too many requests error was sent (which is understandable)
But, why is this disconnection happening? Also is there an inbuilt reconnection mechanism for upstox ticker?
Please help me understand this behavior
Iâve reviewed the various error scenarios youâve mentioned. It appears that the delayed pong response and the 401 error are likely issues on the clientâs side. The pong response delay could be due to network-related problems.
Regarding the other issue, we would require your user ID to accurately pinpoint and understand the specific error scenario. Please share your user ID with us, and we will follow up with you shortly.
Thank you for the update on the issue youâve encountered with the socket connection.
We appreciate the detailed description of the problem. Our team is actively investigating this matter to identify the root cause. We understand the importance of resolving this as efficiently as possible and are committed to providing a solution.
Please be aware that this investigation may take some time. We greatly appreciate your patience and understanding in this matter. Rest assured, we will get back to you with more information as soon as we have significant insights or a resolution.
Apologies for the inconvenience youâre experiencing. When the socket disconnects, are you able to initiate a new connection? Depending on the websocket libraryâs built-in reconnect feature might not be effective, since the authentication code used in the initial socket request is only valid for a single use.
Good to know you have a fallback. Do remember that the default reconnect logic that gets shipped with the client usually uses the URL provided to connect back. If your approach is to use the WebSocket URL with the auth code, it might fail, as the auth code will be valid only once.
While we work on resolving the disconnect issue as a whole, we request that you have a fallback for the connect approach to ensure your operations run smoothly daily.
This issue is certainly of top priority to us, and we are committed to having this resolved.
Sorry, but I need a bit more clarity on what you have mentioned above.
The auth code is used only during the process of login which eventually leads to me receiving the âaccess-tokenâ.
I use this âaccess-tokenâ everywhere else in my code for invoking all other APIs.
Now, the websocket implementation is also following the same steps as suggested in your documentation.
This above is the code flow.
My current fallback approach is to trigger reconnect when OnClose listener is called.
What other fallback approach are you suggesting?
The standard behavior of websocket reconnect is to use the previously utilized socket URL for reconnecting. However, this approach wonât work for us because our socket URLs come with a one-time authentication code.
You should ideally use the accessToken to obtain a fresh authorizedRedirectUri, which will enable you to restart the process.