Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
In testing and using NinjaTrader, there have been many times that it has crashed on me. If I'm running a strategy live and NT or the computer crash, I'm concerned that I'll have to manually close open positions and then restart the strategy. Have any of you had experiences like this? Is there a way to allow the strategy to keep going where it left off?
I've been thinking, if I could reload the IOrders during "protected override void OnStart()" (only called right before the strategy goes live, after it does the quick backtest on the Days2Load), the strategy could continue where it left off. It wouldn't be hard to have all "!= null" IOrders printed into an XML file every 5 minutes using the code attached, or to read the file if "bool recoverPastTrades == true" but... IOrders are a read only interface, and not a class. That's where my programming ability ends - does this sound like a good idea? How could I create a new IOrder without actually sending it from "EnterOrder()"?
Oh, and it would want to check that the sum of all IOrders.Filled in the file == Account current quantity - in case an order was generated that didn't make it into the file and handle it if one didn't.
- DJB
Do or do not, there is no try. - Yoda
Can you help answer these questions from other members on NexusFi?
Thank you for your input. That helps in terms of keeping it going, but what I'm talking about is restoring it if the worst happens - NT completely crashes. We'll see.
Are you on NT7? FWIW I'm finding the following is good to help prevent a crash:
- If I'm doing a lot of coding/compiling through the day memory usage increases and is not released. A fresh restart of Ninja is a Best Practice before going live. The same would apply for Backtesting (ie if you have been backtesting all day its worth a restart before going live).
- If I'm live and for some reason I have to do a lot of disable/enable with Strats, memory usage increases and is not released. I may restart Ninja at an appropriate time during the trading session.
- A daily or weekly reboot of the host PC is a Best Practice.
I'm considering adding some code to a Strat that will monitor memory usage every n time period and alert me if a threshold is crossed. That would allow me to flatten/restart to prevent a crash while I'm live.
I haven't had to do this yet (luckily!), but if I had a crash and I had any positions on that were not long term, I'd call the broker and direct them to flatten everything.
Memory usage in NT7 is my pet project this week . I'm trying both forced Garbage Collection and looking at which methods have a Dispose() thing going and how to take advantge of that. Also starting to wonder if its time to move to a 64 bit platform...
Typically, for a crash such as you describe, you would have the exchange send over the orders, with their current state. You'd then have the correct state of each, etc. This is similar to a reconciliation. Re-loading anything on the client side w/o access to the destination (i.e. w/o consulting the exchange of record) does not reflect the current state of the orders.
MXASJ, please do share with what you come up with for the memory freeing functions - I use all 64 bit and NT still does the same in terms of accumulating memory being used.
kandlekid, I'm looking into getting the orders from the broker that are active through NT - it's not official supported, supposedly.
Update: I have successfully accessed from within the strategy the global values that are listed in the Executions, Positions, and Accounts tabs using this code:
It seems that the current status of the broker isn't kept into separate orders that the strategy placed but rather is the running sum. So, I'll have to have the strategy infer based on the current quantity and direction (long/short) where it is at then it will know for sure. Since it uses multiple orders of fixed sizes, it won't be hard to infer how many it has active to match the broker position.
It still doesn't solve how to recreate the IOrder... but I suppose the strategy doesn't need to, it could keep track at that point by something else instead of IOrder == null...... more updates to come.