@srijan @sujith @rakeshr
We have not asked for debugging support. Alright, I will exucute this plain 3 lines of code without any other code to place one order and see whether it reproduces or not.
i have explicitly mentioned earlier in this thre…
Hello @rakeshr @sujith @SRIJAN
We debugged the code and have below findings:
The code is:
pprint('placing order for qty: {0} at time {1}'.format(qty_placed, datetime.datetime.now()))
order_id = kite.place_order(tradingsymbol=trading_symbol,
…
hello @SRIJAN
Our code is not generating any stacktrace, we checked complete log. I assume by stacktrace you mean the python's standard way to pring error which starrts with "Traceback (most recent call last):"
To print stacktrace forcefully, we …
hello @rakeshr @sujith @SRIJAN
We had implemented fully multi-threaded ticker on 5th may and above issue vanished for around 20 days.
We are handling only two callbacks: on_tick() and on_order_update(). Both does NOT do anything apart from adding…
@rakeshr @sujith
We are observing this issue during times other than the market start also. It's occurring consistently, see below order id and it's log:
placing order for qty: 200 at time 2022-05-23 14:15:05.547956
Order id added to Q at time 2…
thx @sujith , the further order_ids can be seen in ON_ORDER_UPDATE callback, riight? if yes, is there any way to know the related orders (i.e. all orders 2nd leg onwards) based on parent order id (the main order id returned by place_order api) or so…
@rakeshr , what will be return type of the place_order() API when ICEBERG is sent? in normal order, we receive the order_id. Since here multiple orders can be placed, how can we know order_ids placed? FYI, we need to record order_id in our database …
@sujith ,
Yes, we saw order_timestamp in ON_ORDER_UPDATE is also 'order_timestamp': '2022-05-09 09:30:37' for order id 220509300395522.
But big question is, we have sent order at 9:30:01 and proof of it is we recieved the order_id.
@sujith ,
order type: MARKET
The delay i am observing in the order history, see the image attached:
The order id's were received from kite place order id are taken from the our logs:
09:30:00.412167 220509300395421
09:30:01.063204 2205093003…
This solves our problem (which is yet to occur in future ), we will use more apps when we hit the wall. Thanks all involved for clarification @SRIJAN @rakeshr @sujith
Hi @SRIJAN ,
Aah this breaks the heart. As an indvidual we are not allowed to setup multiple accounts per PAN.
I am OK if we have to pay to cross the per sec limit, but restricting to 10 orders per sec is a clear dealbreaker. We have genuine requi…
Hi @SRIJAN ,
Just wanted to double confirm: the 10 orders per sec limit is per api_key and not per user right?
This support article talks about "single user will not be able to place more than....." so I was led to believe rate limit is per user.
One more thing: we are not going to cross 200 orders per min and 2000 orders per day despite subscribing 300+ instruments. It's only per sec limit bothers us, causing us large impact cost as we are forced to put SLEEP function in our order place API…
@SRIJAN , i forgot to mention that all ticker instances are created for same app, same user. That means, all instances will receive all order updates, correct?
Please confirm, and then you can close the discussion.
Hi @rakeshr ,
Thanks for response. However one thing I would like to highight is we rarely see "peer did not finish the opening handshake in time". Checked last 7 days of log and we found only one isntance, that is posted here.
However, below this…
hi @sujith ,
I posted an inquiry yesterday and it went to approval, not sure why. The akismet spam protection seems to be overprotecting, filtering even genuine inquiries. Kindly help approve my post.
