I am subscribing to live feed (Mode: full) via websocket & have 2 websockets open at any given moment for load distribution.
I have observed that today the live feed of symbol (NIFTY 28-APR-2026 CALL 24350) got stuck. We do not save ticking data to database due to it's size, so I do not have exact times.
My code looked at the price at 2:00:28 pm and it was shown as 246.75 however looking at the charts on kite the price was around 272 at that time.
If I go back on the timeseries the price was around 246 at around 1:54 pm, so my conclusion is it seems to have got stuck from 1:54 pm or even a bit earlier than that.
I am running my servers on Google Cloud Mumbai Data Center & the connectivity has been rock solid for so many years.
I understand there could be several factors affecting this issue. My questions are:
1. If you could check for any issues on your side. 2. Have you observed similar reports in the past. If yes, what solutions, precautions or work arounds were advised.
We use the same tick data to form OHLCV candle as you see on the kite charts, so until you are blocking the ticker(which leads to missing ticks) or not storing/dumping tick data properly in file or DB.
Could you clarify what you mean by "blocking the ticker"? To provide some context on our end:
No Unsubscriptions: We have verified that we did not accidentally unsubscribe from the symbol.
No Heavy Processing: We do not write the timeseries data to a file or database. Our system only caches the most recent tick in memory to access the latest LTP, so there is minimal local processing overhead that could block the thread.
I understand that reproducing this issue requires simulating an external client environment, and the root cause could potentially lie on either the broker's or the consumer's side. I have thoroughly reviewed our implementation and found no obvious bugs or bottlenecks that would cause this localized lag.
My primary question moving forward relates to bandwidth and payload size: We currently subscribe to 2,000–3,000 symbols, load-distributed across two websocket connections (approximately 1,000–1,500 symbols per socket). While this is well below the maximum allowed limit of 3,000 symbols per socket, we are subscribing in `FULL` mode.
Given the larger payload size of `FULL` mode, could pushing data for 1,500 symbols through a single websocket cause the buffer to overflow, resulting in dropped ticks or stuck feeds for specific symbols?
I am sharing this primarily as feedback for your technical team. I realize a deep-dive investigation might not be immediately feasible for a single occurrence, but I wanted to ensure this is on your radar. If similar issues are reported by other users, hopefully, this data point will be useful for a broader investigation.
Thank you for getting back to me.
Could you clarify what you mean by "blocking the ticker"? To provide some context on our end:
- No Unsubscriptions: We have verified that we did not accidentally unsubscribe from the symbol.
- No Heavy Processing: We do not write the timeseries data to a file or database. Our system only caches the most recent tick in memory to access the latest LTP, so there is minimal local processing overhead that could block the thread.
I understand that reproducing this issue requires simulating an external client environment, and the root cause could potentially lie on either the broker's or the consumer's side. I have thoroughly reviewed our implementation and found no obvious bugs or bottlenecks that would cause this localized lag.My primary question moving forward relates to bandwidth and payload size:
We currently subscribe to 2,000–3,000 symbols, load-distributed across two websocket connections (approximately 1,000–1,500 symbols per socket). While this is well below the maximum allowed limit of 3,000 symbols per socket, we are subscribing in `FULL` mode.
Given the larger payload size of `FULL` mode, could pushing data for 1,500 symbols through a single websocket cause the buffer to overflow, resulting in dropped ticks or stuck feeds for specific symbols?
I am sharing this primarily as feedback for your technical team. I realize a deep-dive investigation might not be immediately feasible for a single occurrence, but I wanted to ensure this is on your radar. If similar issues are reported by other users, hopefully, this data point will be useful for a broader investigation.
Thank you for your time and support.