Our python program stops capturing the stream very frequently. 8 times since this morning (in 1.5 hours). The problem is that we don't catch an exception and program stops receiving ticks.
Is there a way to catch an exception specific to your API?
@sujith Sayandeep is sending in a snippet of the garbage values that are being received. His post is under approval, maybe because we are sending some of the garbage values and methods to reproduce the error. Please check
@sujith@Shaj on_tick is fine. We do get the tick data as a python dict. But the problem is that the ticks stop coming very frequently and currently without providing an exception, so we are unable to restart the program internally to continue receiving ticks (without daemonizing or any helper script).
Our question is still the same - is there a way that we can catch an exception when the ticks stop abruptly from within the program? Or do we have to use an external daemonize/ helper script to restart the program when it stops?
I was having same issue in the past days. websocket gets interrupted . What you guys can do is simply put websocket connection in while loop. So after disconnect it start all over again. Its simple hack but pretty effective
@kivijoshi@sujith Yeah sure, the only problem is that it has to restart the connection which takes time (~30-40 seconds). So maybe if there was a way to catch an exception, it could reconnect faster (<5-10 seconds)
@joy Checking interval between 2 heart beat is the better approach here because when the client is not aware of the network disconnection it could take several seconds before onClose or onError method will be triggered.
To simulate this you can run the WebSocket client and manually disconnect your network. So the better approach is checking two heartbeat interval since its guaranteed that you will get atleast one heartbeat per second if client is connected.
Can you let us know what client are you using?
Can you set on_error, on_close, on_error and add some logs and check?
For more information check out python documentation here.
Tick data you get is binary. It is parsed and sent back to users.
You can use on_tick callback as mentioned by @Shaj.
Our question is still the same - is there a way that we can catch an exception when the ticks stop abruptly from within the program? Or do we have to use an external daemonize/ helper script to restart the program when it stops?
Is on_error callback not getting called?
Is on_close callback getting called every time ticker disconnected?
Both are getting called, see two typical variants of errors. Even after executing the callbacks, we're unable to do or followed by . They respectively return the exception messages: connection is already open, and closed respectively, and our thread dies subsequently.
Please advise.
What you guys can do is simply put websocket connection in while loop. So after disconnect it start all over again. Its simple hack but pretty effective
Yeah sure, the only problem is that it has to restart the connection which takes time (~30-40 seconds). So maybe if there was a way to catch an exception, it could reconnect faster (<5-10 seconds)
We don't have this for Python client yet but you can try implementing on your own. Here is the code snippet which handles it - https://github.com/rainmattertech/kiteconnectjs/blob/master/lib/ticker.js#L278
1. check interval between 2 hear beats (like u said) or
2. when socket OnClosed/OnError method is called.
I have implemented the later. what u folks recommend.
onCloseoronErrormethod will be triggered.To simulate this you can run the WebSocket client and manually disconnect your network. So the better approach is checking two heartbeat interval since its guaranteed that you will get atleast one heartbeat per second if client is connected.
Yes, I have already tested it by manually switching off the router etc. and there is a lag.
Since there is a heartbeat in every second, it makes sense to check that. Will modify the code accordingly.
Yes, I have already tested it by manually switching off the router etc. and there is a lag.
Since there is a heartbeat in every second, it makes sense to check that. Will modify the code accordingly.