Disabling on connection loss

[Francis]

Hello,

Last night there was a connection loss on both my order and price feeds. I have set some rules how to act in such a situation and all worked as supposed: after 14 minutes of disconnetion strategies should be disable if there is no reconnection in the 15th minute after 30 attempts (every two seconds).

But last night five of my 19 strategies stayed enabled (green), where the other 14 disabled as supposed. When this morning the connection re-established (it was a quite serious problem with my ISP) the 14 enabled fine.

My question is where to look first at why five strategies did not disable. I have a code running which override OnTermination(), which disposes the mytimer. But other strategies which disabled have this same part of code. Does the disabling act sequencially, starting with the first strategy to go to the last one? Because all the last five except the very last strategy were still enabled after 15 minutes of being diconnected. Any ideas?

Thanks in advance,
Francis

[NinjaTrader_Bertrand]

Francis, sorry to hear about the connection issues - first thing I would look into are the logs / traces, do you see any issues noted besides the reporting of the connection loss event?

[Francis]

Hello Bertrand,

Thanks for replying.

I looked into the log and trace files, but could not find any specific information why some strategies disabled properly while others did not. First there was a disconnection (it is clear where that came from: ISP)) and then some errors are logged regarding the mailserver which could not be reached to send a warning message (total Internet connection was lost). Furthermore a lot of errors regarding the IQFeed Adapter MessageLoopFeed and after the 14 minuted of disconnection and one minute trials to reconnect the diabling of 14 strategies instead of 19. No specific sign says why some were not disabled.

Kind regards,
Francis

[NinjaTrader_Bertrand]

Thanks Francis, would the best out of ideas unfortunately as well - could only assume the trigger would have not evaluated as expected in the scripts that were left running. I think you could look into simulating for example the connection loss event through a firewall block and see if you're able to reproduce the anomaly.