hi, still getting the following: error=[Errno 104] Connection reset by peer even after using kws.enable_reconnect(reconnect_interval=5, reconnect_tries=50)
hi, did increased reconnect_tries from 50 to 300 kws.enable_reconnect(reconnect_interval=5, reconnect_tries=300). 1.what will happen when the reconnect_tries counter reduces to ZERO without getting connected? does the program exit() or will it reload with 300 and try again?
With this now am facing another problem 2. on_tick() handler: am directly calling another function to analyze the tick data. But somehow stack_overflow fatal error is encountered and the program quits. 'Fatal Python error: Cannot recover from stack overflow' 2.1 Can we have some sort of control over the on_tick(). Like disable before calling another function and re-enable once the handle returns?
Any good and quick suggestions to overcome this will be helpful Thanks
@divyakumar If you are calling the function from on_tick() which does an intensive calculation or something then it's advisable to queue the processes by celery or running it in a different thread and not blocking the current one.
Also you can check in enable_reconnect method that if you send zero value for reconnect tries and interval we take the default one. But if you set reconnect interval very low then you will get stack overflow.
hi, further on on_tick(). I will move the overhead out of on_tick() itself. But before that, I saw that its being called in _on_data(): code snippet is below:
def _on_data(self, ws, data, resp_type, data_continue): """Receive raw data from WebSocket.""" self._last_read_time = int(time.time())
if self.on_tick: # If the message is binary, parse it and send it to the callback. if resp_type != 1 and len(data) > 4: self.on_tick(self._parse_binary(data), self)
So can I manipulate resp_type to halt recursive calls to on_tick() and see that my simple algo is working . Also if you can please elaborate on each of the arguments passed "data, resp_type, data_continue" would be helpful. Why len(data) is compared to 4? those type of elaborations
hi, amd getting following repeated error for the code positions=kite.positions()['net'];
Error is File "/usr/local/bin/python3/kiteconnect/__init__.py", line 364, in positions return self._get("portfolio.positions") File "/usr/local/bin/python3/kiteconnect/__init__.py", line 464, in _get return self._request(route, "GET", params) File "/usr/local/bin/python3/kiteconnect/__init__.py", line 555, in _request raise(exp(data["message"], code=r.status_code)) kiteconnect.exceptions.GeneralException: An internal server error occurred
its my opinion that the technical queries need to be answered/acknowledged fairly quickly in this forum. 08040402020 support personnel never answer these queries and support@zerodha just gives ticket number and not the response/solution.
I think its fair to seek a certain level of quality and commitment from you guys for the price am paying for the server side access . Sadly am finding out the hard way that it doesnt seem to work as well as been claimed by you guys and you are also having laid back approach.
Remember that I can delay my responses as a client/customer, but not you people (being the service provider by claim).
Sent mail a month back to talk at rainmatter dot com.
I am yet to get any reply.
You guys are saying revamping core API for months. How much more it will take give us clear date. You can not survive open-ended project schedule in the era of high speed change in technology.
By the time you complete your project you will be using obsolete technology.
Also abolish Monthly subscription for trades which are making more than ten trades a day.
Hi @haribabu,
Revamp of core APIs is a bigger than any of our projects. It has a lot of external dependencies. It has to be rigorously tested. If anything goes wrong then you may end up loosing order placed, an order might be placed but positions might never be updated, you may loose holdings so on.
In general, it is easy to repair a machine which has stopped but it is difficult to repair or replace a live machine without disturbing or stopping it.
We have put in a lot of effort to make every module more reliable and scalable.
The reason we can't give the timeline is that it has a lot of external dependencies and every time we are near to our objective, we come across a new scenario which has to be gracefully handled. We have completed almost 80% of the job. We are hoping to release it in a couple of weeks.
hi, please dont release for the sake of releasing. I believe you do rigorous testing with the mock trading opportunities given by exchanges every month. In the last month I faced problems where my orders were not executed, unable to cancel and your backend just wont accept any state change. I couldnt do anything and I suffered an accumulated losses to the tune of 1.3 lakhs. Now I have to think twice before placing any order as it can hang any time. SO FAR NO RESPONSE FROM customer care in 2 weeks. They wont reply, reimburse . This is the JUGAAD mentality and am having to live with. Please please test it thoroughly.
Can you paste your code?
did increased reconnect_tries from 50 to 300
kws.enable_reconnect(reconnect_interval=5, reconnect_tries=300).
1.what will happen when the reconnect_tries counter reduces to ZERO without getting connected? does the program exit() or will it reload with 300 and try again?
With this now am facing another problem
2. on_tick() handler: am directly calling another function to analyze the tick data.
But somehow stack_overflow fatal error is encountered and the program quits.
'Fatal Python error: Cannot recover from stack overflow'
2.1 Can we have some sort of control over the on_tick(). Like disable before calling another function and re-enable once the handle returns?
Any good and quick suggestions to overcome this will be helpful
Thanks
on_tick()which does an intensive calculation or something then it's advisable to queue the processes by celery or running it in a different thread and not blocking the current one.Also you can check in
enable_reconnectmethod that if you send zero value for reconnect tries and interval we take the default one. But if you set reconnect interval very low then you will get stack overflow.further on on_tick(). I will move the overhead out of on_tick() itself. But before that, I saw that its being called in _on_data(): code snippet is below:
def _on_data(self, ws, data, resp_type, data_continue):
"""Receive raw data from WebSocket."""
self._last_read_time = int(time.time())
if self.on_tick:
# If the message is binary, parse it and send it to the callback.
if resp_type != 1 and len(data) > 4:
self.on_tick(self._parse_binary(data), self)
So can I manipulate resp_type to halt recursive calls to on_tick() and see that my simple algo is working . Also if you can please elaborate on each of the arguments passed "data, resp_type, data_continue" would be helpful. Why len(data) is compared to 4? those type of elaborations
Response is much appreciated
positions=kite.positions()['net'];
Error is
File "/usr/local/bin/python3/kiteconnect/__init__.py", line 364, in positions
return self._get("portfolio.positions")
File "/usr/local/bin/python3/kiteconnect/__init__.py", line 464, in _get
return self._request(route, "GET", params)
File "/usr/local/bin/python3/kiteconnect/__init__.py", line 555, in _request
raise(exp(data["message"], code=r.status_code))
kiteconnect.exceptions.GeneralException: An internal server error occurred
Please help
its my opinion that the technical queries need to be answered/acknowledged fairly quickly in this forum. 08040402020 support personnel never answer these queries and support@zerodha just gives ticket number and not the response/solution.
I think its fair to seek a certain level of quality and commitment from you guys for the price am paying for the server side access . Sadly am finding out the hard way that it doesnt seem to work as well as been claimed by you guys and you are also having laid back approach.
Remember that I can delay my responses as a client/customer, but not you people (being the service provider by claim).
Please take notice
I am yet to get any reply.
You guys are saying revamping core API for months. How much more it will take give us clear date. You can not survive open-ended project schedule in the era of high speed change in technology.
By the time you complete your project you will be using obsolete technology.
Also abolish Monthly subscription for trades which are making more than ten trades a day.
Revamp of core APIs is a bigger than any of our projects. It has a lot of external dependencies. It has to be rigorously tested. If anything goes wrong then you may end up loosing order placed, an order might be placed but positions might never be updated, you may loose holdings so on.
In general, it is easy to repair a machine which has stopped but it is difficult to repair or replace a live machine without disturbing or stopping it.
We have put in a lot of effort to make every module more reliable and scalable.
The reason we can't give the timeline is that it has a lot of external dependencies and every time we are near to our objective, we come across a new scenario which has to be gracefully handled. We have completed almost 80% of the job. We are hoping to release it in a couple of weeks.
please dont release for the sake of releasing. I believe you do rigorous testing with the mock trading opportunities given by exchanges every month. In the last month I faced problems where my orders were not executed, unable to cancel and your backend just wont accept any state change. I couldnt do anything and I suffered an accumulated losses to the tune of 1.3 lakhs. Now I have to think twice before placing any order as it can hang any time. SO FAR NO RESPONSE FROM customer care in 2 weeks. They wont reply, reimburse . This is the JUGAAD mentality and am having to live with.
Please please test it thoroughly.