I’m using the KiteTicker WebSocket API in a Java-based trading system to stream live tick data and manage open orders. For the past 2–3 days, I’ve been frequently receiving the log message:
KiteTicker disconnected unexpectedly.
This happens multiple times during the trading session, even though my internet connection remains stable. The disconnections are usually followed by automatic reconnections, but I’d like to confirm the correct and safe way to handle these events in production.
Below is the key part of my current implementation:
if (count > MAX_DISCONNECT_RETRIES) { LOGGER.error("???? Too many disconnects! Manual intervention required."); notifyManualIntervention(); closeExecutedOrders(); // re-validate open orders after repeated failures return; }
new Thread(() -> { try { Thread.sleep(3000); if (!tickerProvider.isConnectionOpen()) { LOGGER.info("???? Attempting to reconnect KiteTicker..."); tickerProvider.connect(); } } catch (Exception e) { LOGGER.error("Error while trying to reconnect KiteTicker: ", e); } }).start(); });
I’m currently:
Not calling closeExecutedOrders() for normal or short disconnects.
Only calling it after multiple failed reconnections (more than 5 attempts).
Using setTryReconnection(true) with limited retries and retry intervals.
Could you please confirm the following:
Are there any known issues or maintenance activities in the past few days that could cause frequent KiteTicker disconnected unexpectedly messages?
Is the above reconnect handling approach recommended for production use, or should I explicitly call connect() after each disconnect instead of relying solely on setTryReconnection(true)?
Is there a callback or flag that indicates a permanent failure after all internal retries are exhausted?
Any best-practice guidance or insight into the current stability of the ticker service would be highly appreciated.
1. There have been no known issues or maintenance activities in the past few days. 2. The KiteTicker library supports automatic reconnection when setTryReconnection(true) is enabled, so you don’t need to manually call connect() after every disconnect. The internal mechanism will attempt retries automatically. For more details, please refer to the official GitHub repo. 3. Currently, there is no dedicated callback or flag that indicates a permanent failure or that all retries have been exhausted. You may, however, maintain your own counter to track disconnections and compare it against the maximum retry limit, then take appropriate action when that threshold is reached.
2. The KiteTicker library supports automatic reconnection when setTryReconnection(true) is enabled, so you don’t need to manually call connect() after every disconnect. The internal mechanism will attempt retries automatically. For more details, please refer to the official GitHub repo.
3. Currently, there is no dedicated callback or flag that indicates a permanent failure or that all retries have been exhausted. You may, however, maintain your own counter to track disconnections and compare it against the maximum retry limit, then take appropriate action when that threshold is reached.