Does SubmitOrder always return a non null IOrder?

[DaveE]

Looking at this reply it looks as though Brett is saying that EnterLongLimit() can sometimes return a null.

I need to know whether the same thing applies to SubmitOrder?

In my own tests it looks as though SubmitOrder blocks the thread until it returns a non-null IOrder object (eg one with OrderState==PendingSubmit). This is what I would expect.
So for instance if I call entryOrder=SubmitOrder(...) in OnBarUpdate then on the next line entryOrder will always be non-null.
I would assume that all order entry methods should always block their thread until they return a non-null IOrder, and only then become non-blocking (presumably by letting NT core threads handle the order progression).

If my assumption is correct its possible that users who have reported order entry methods returning null, on very fast timeframes such as single tick, could be really be experiencing something like this:

• Thread A (say in OnBarUpdate) : entryOrder=EnterLongLimit(...)
• Thread B: triggers OnExecution, say for a previous stop order, and user might have coded 'entryOrder=null', which gets executed although user may not be expecting it in this sequence.
• Thread A (next line in OnBarUpdate): sees entryOrder==null

[NinjaTrader_Brett]

Hi Dave,

The same would apply.

Wanted to take a second to make sure we are on the page with your statement here:

"In my own tests it looks as though SubmitOrder blocks the thread until it returns a non-null IOrder object (eg one with OrderState==PendingSubmit). This is what I would expect."

This is NOT what I would expect, any call to SubmitOrder would execute on the NT core and would NOT execute on the NS/UI thread so it would NOT block the thread.

Specifically what occurs is when you call SubmitOrder it returns a pointer to a location in memory that will hold the state of that order whatever that would be. If you read the state of that pointer before the NT Core has had a chance to process the order then it would return null.

Let me know if any followup question I could answer from that.

[DaveE]

Thanks for the quick reply Brett.

The reason I'm assuming that SubmitOrder blocks its thread, is because debug code records about a tenth of a second delay before SubmitOrder returns a populated IOrder object (and allows the next line of code to execute). This is while connected to IB. I assume the delay is caused by SubmitOrder waiting for a order token from IB.
On the other hand if SubmitOrder was simply sending a message to NT core before returning a pointer to an unpopulated object, then:

• I would not be likely to detect any elapsed time before next line executes.
• I would see entryOrder==null on the next line

I dont know what the NS thread is.

If someone does this:

#region Variables
private IOrder entryOrder;
#endregion

puts entryOrder=SubmitOrder(...) in OnBarUpdate, then I assume this is not executing on the UI thread. Lets say the first time it executes in a strategy its OnBarUpdate is called on thread A.
So SubmitOrder blocks thread A (in my understanding) until it gets an order token.
In the meantime, (if user has a very fast timeframe) another thread in NT core could trigger another OnBarUpdate (lets say on thread B). If the user's code in OnBarUpdate does not make allowance for this then both thread A and thread B could be trying to assign a different populated IOrder object to the same variable. This is in addition to the problem that NT core might have triggered say OnExecute on thread C, due to a previous order filling, where the user might have coded "entryOrder=null" (as per NT example code)

It looks like regardless of whether or not order entry methods block their thread until they return an IOrder object, the user needs to add some extra 'thread safe' code around them if using a fast timeframe.
For instance if you are correct in thinking that entryOrder==null is expected on the line after entryOrder=SubmitOrder, then the user cant use "if (entryOrder==null) entryOrder=SubmitOrder(...);" to prevent unexpected multiple orders (or 'overfill').

[NinjaTrader_Brett]

No problem.

The reason I'm assuming that SubmitOrder blocks its thread, is because debug code records about a tenth of a second delay before SubmitOrder returns a populated IOrder object (and allows the next line of code to execute).

When you do SubmitOrder call there is some code the runs such as "TraceOrders" and checking to make sure its valid to submit an order all inside this method we provide, etc. This shouldn't take very long at all before it ships it to the NT core to be submitted which is multi threaded. I'm not sure how your doing your debug code exactly or why you see such a large delay but can confirm that SubmitOrder will submit the order and will allow execution to continue will not wait for return of iOrder object.

It looks like regardless of whether or not order entry methods block their thread until they return an IOrder object, the user needs to add some extra 'thread safe' code around them if using a fast timeframe.
For instance if you are correct in thinking that entryOrder==null is expected on the line after entryOrder=SubmitOrder, then the user cant use "if (entryOrder==null) entryOrder=SubmitOrder(...);" to prevent unexpected multiple orders (or 'overfill').

Correct.


-Brett