All Ninja users know the more used native procedures for handling connection loss with Strategies and orders, basically Strategies are temporarily stopped as well as submitting orders until have again a connection re-established. Another important native NT procedure is dealing with orders rejections, where Strategy are fully stopped, orders are cancelled and positions are flattened.
Here a situation that involves all of above but in an unexpected manner. I have 3 Strategies running "live simulations", real-time action but for account Sim101. Here the facts:
- 12:54:47 am happens a connection loss, price-server and order-server, as programmed NT says: connection-loss but Strategies will keep running. Despite the connection loss, price data kept coming, therefore the Strategies worked as normal and triggered some orders.
- 12:54:50 Orders from two Strategies are submitted but obviously with order-server down in IB ( interactivebrokers ) , these orders are rejected, and in consequence this kicked the "RealTimeErrorHandling", these two Strategies are stopped, cancelled all of their orders and flattened all of their positions.
- 12:55:23 Connection is re-established, but obviously just one Strategy are running, the Strategy that didn't submit any order during the weird connection loss time.
I've attached an extract of log file so you can see the register of facts.
Here my question:
1. How come during a registered price and order connection loss, if some price data sparks, the Algos are able to submit orders?
This is obvious a big problem, cause if you have set that your Strategy will keep running or recalculate, they will continue to work and should submit any order as new data comes, this will kick "RealTimeErrorHandling" , thus you can expect Strategies full stopped for all session.
Due to this condition I'll add a simple logic in my Strategies: "if not price and data connected, orders are stopped".
My suggestion to NT developers: During a connection loss, if both : price and server data aren't fully connected, submitting orders should be stopped in order to avoid the "RealTimeErrorHandling; otherwise there will be always a potential sudden fully stop of strategies for all session.
Comment