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
INFO Upstox - Upstox ticker Connected for 127656
Connection closed by us. Info: The connection was closed because the other endpoint did not respond with a pong in time. For more information check: Lost connection detection · TooTallNate/Java-WebSocket Wiki · GitHub
INFO Upstox - Upstox Connection closed by us. Info: The connection was closed because the other endpoint did not respond with a pong in time. For more information check: Lost connection detection · TooTallNate/Java-WebSocket Wiki · GitHub and code 1006 for 127656
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 your response!
My user id is 127656
Today the issue was seen once when ticker was first connected at 8:46 AM.
Ticker got connected.
Ticker then gave below error and disconnected.
DEBUG: Upstox Connection closed by remote peer. Info: and code 1000 for 127656
Upon connection close above, my reconnect logic was called by the program.
Then onwards, ticker connected and no toggling happened.
Can you please continue the investigation from your side and help together to identify the root cause of this issue.
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.
I understand that the analysis needs time.
I am just commenting here now as the issue is happening right now 9:14 am (from 8:46 am)
Perhaps it may help you investigate easily: User id 127656.
Kindly look into this issue
We are facing this every day morning and I have tried many options from my side to avoid this but to no avail.
Any feedback would help.
@shanmu and @Pradeep_Jaiswar
Ticker is totally blocked today from morning.
This has become unusable.
Please treat this as urgent!!
We are literally blocked.
Need your attention pls.
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.
Yes I can invoke the reconnect myself.
Also, I have written my own reconnect logic which will be invoked when the onClose listener is called by the websocket.
Inside the reconnect logic, I am simply performing the connection call to originally created websocket object and sending the subscription data.
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.
ApiClient authenticatedClient = Configuration.getDefaultApiClient();
OAuth oAuth = (OAuth) authenticatedClient.getAuthentication(“OAUTH2”);
WebsocketApi websocketApi = new WebsocketApi(authenticatedClient);
WebsocketAuthRedirectResponse response = websocketApi.getMarketDataFeedAuthorize(API_VERSION);
URI serverUri = URI.create(response.getData().getAuthorizedRedirectUri());
WebSocketClient upstoxTicker = createWebSocketClient(serverUri);
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.