Hi, I'd like to know how best to cleanly close the websocket connection when it is connected in threaded mode.
I am using the pykiteconnect SDK and the KiteTicker class for my websocket operations.
I tried using the close() method by passing in 1000 as code and a random reason string whenever I want to manually close the socket from my main application thread and this seems to work most times but occasionally I get an error stating "1006 - connection was closed uncleanly (WebSocket closing handshake timeout (peer did not finish the opening handshake in time))" I can confirm the socket was in connected state before I attempted to close it, I even have an explicit check for this. I assume the stop() method is more intended for the blocking use case but I just tried using it anyway and observed same behavior as calling close() method. Are there more things to be checked from the main thread before attempting to close the socket client? Can someone help share what has worked for them to not face this 1006 error when closing the socket?
One has even raised a PR with an attempted fix. Most apps will try to run the ticker as a separate thread and it will be great if we can have more control over it. If threaded is set to False then we can't have signal handlers with current setup and if it is set to True we spawn a new thread within the app's ticker thread which will not work as the connect call isn't blocking anymore so no ticks are received.
If possible can you share a more detailed example of how an app manages the ticker thread? The main app is continually running, when the market opens we stream tick data and do processing and when market closes we stop processing - Ideally it would be great if we can stop the websocket and restart it on the next market open time. We don't want to kill off the main app and restart it here.
Ideally it would be great if we can stop the websocket and restart it on the next market open time. We don't want to kill off the main app and restart it here.
No, you can't restart the reactor that was stopped. That's Twisted's limitation. This thread explains in detail.
So what is the suggestion for long running apps that make use of the ticker? It is not realistic to have us close and restart the main application every day or to leave the ticker running even after market hours & holidays. I see that this limitation has been pointed out since many years ago so what have you guys planned in terms of fixing it? Has any analysis happened from your side to identify a fix or a long term solution?
And I see that at least two devs have raised the issue of allowing more control over the spawned thread when threaded is set to True for the KiteTicker
See https://github.com/zerodha/pykiteconnect/issues/191 and https://github.com/zerodha/pykiteconnect/issues/41
One has even raised a PR with an attempted fix. Most apps will try to run the ticker as a separate thread and it will be great if we can have more control over it. If threaded is set to False then we can't have signal handlers with current setup and if it is set to True we spawn a new thread within the app's ticker thread which will not work as the connect call isn't blocking anymore so no ticks are received.
If possible can you share a more detailed example of how an app manages the ticker thread? The main app is continually running, when the market opens we stream tick data and do processing and when market closes we stop processing - Ideally it would be great if we can stop the websocket and restart it on the next market open time. We don't want to kill off the main app and restart it here.