race condition atm strats

[ATI user]

I have been chasing a race condition bug (in my code) for more hours/days than I care to admit

solution was to change the basic SampleAtmStrategy code to include the code below in " "

I am placing Buy/Sell stops with the code....which need to trigger, then fill....the reason you need to wait/check atm strat is actually filled (before setting the order string to empty) is to avoid the race condition of flat status while atm fills.




// Check for a pending entry order
if (orderId.Length > 0)
{
string[] status = GetAtmStrategyEntryOrderStatus(orderId);

if (status.GetLength(0) > 0 // added code here

"
&& atmStrategyId != null && atmStrategyId .Length > 0
&& GetAtmStrategyMarketPosition(atmStrategyId ) != Cbi.MarketPosition.Flat
"
)
{
Print("The entry order filled amount is: " + status[1]);
Print("The entry order order state is: " + status[2]);

// If the order state is terminal, reset the order id value
if (status[2] == "Filled" || status[2] == "Cancelled" || status[2] == "Rejected")

orderId = string.Empty; // want to wait for actual fill before setting this empty

}
} // If the strategy has terminated reset the strategy id
else if (atmStrategyId.Length > 0 && GetAtmStrategyMarketPosition(atmStrategyId) == Cbi.MarketPosition.Flat)
atmStrategyId = string.Empty;

[NinjaTrader_JoshP]

Glad you got it working in the end.

[KBJ]

I am placing Buy/Sell stops with the code....which need to trigger, then fill....the reason you need to wait/check atm strat is actually filled (before setting the order string to empty) is to avoid the race condition of flat status while atm fills.

// Check for a pending entry order
if (orderId.Length > 0)
{
  string[] status = GetAtmStrategyEntryOrderStatus(orderId);
                
  if (status.GetLength(0) > 0
   && atmStrategyId != null            // added code
   && atmStrategyId > 0                // added code
   && GetAtmStrategyMarketPosition(atmStrategyId) // added code
       != Cbi.MarketPosition.Flat )    // added code
  {
    Print("The entry order order state is: " + status[2]);
    Print("The entry order filled amount is: " + status[1]);
    Print("The entry order order state is: " + status[2]);

    // If the order state is terminal, reset the order id value
    if (status[2] == "Filled" || status[2] == "Cancelled" || status[2] == "Rejected")

       orderId = string.Empty;  // want to wait for actual fill before setting this empty
  }
} // If the strategy has terminated reset the strategy id
else if (atmStrategyId.Length > 0
      && GetAtmStrategyMarketPosition(atmStrategyId) == Cbi.MarketPosition.Flat)
         atmStrategyId = string.Empty;

ATI: Thanks for the info. It sounds as if this is vital data, but I'm having trouble with this.

Does this mean that status[2] can be returned as "Filled" when GetAtmStrategyMarketPosition() still returns flat?

[ATI user]

absolutely....that is the race condition

run the basic code and look at the prints in the Output Window....you will get a few ticks of Filled with Flat/0 until the atmid catches up ...then you get not Flat....however, if you set orderID while waiting, and do other things like I do assuming your are filled ....you will have problems

finally added the code so nothing would happen (i.e. code would not change the orderID until confirmed filled in the atmI).....until filled all round

I do not think the basic code is reliable without the added code for that reason

[KBJ]

ATI: Thanks again. This is good to know.

I think I get the general idea, and this will help on an ATM strategy that I've been playing with.

Another couple of questions...

1) In your last message, by "atmid" were you referring to "atmStrategyId", and what is "atmI"?

2) In one place your code refers to "atmStrategyId" and in other places it refers to "atmStrategyIdLONG[i]". Was this intentional, or just a typo?

[ATI user]

ATI: Thanks again. This is good to know.

I think I get the general idea, and this will help on an ATM strategy that I've been playing with.

Another couple of questions...

1) In your last message, by "atmid" were you referring to "atmStrategyId", and what is "atmI"?

2) In one place your code refers to "atmStrategyId" and in other places it refers to "atmStrategyIdLONG[i]". Was this intentional, or just a typo?

yes...lazy typist....in all instances, atmID refers to atmStrategyId

sorry,...I tend to cut corners then confuse people

[aslane]

I am seeing this race condition as well.

Using the code structure from SampleAtmStrategy, I occasionally see the strategyId get reset when it is still active. This causes problems because now a new order can be submitted while a current strategy is still active.

As previously explained, this happens because the order status comes back as "Filled", but the market position for the strategy is still Flat. This causes the orderId to be reset (thats ok), and the next time thru the code the strategyId can be reset if the strategy position is still flat.

How is it possible for an order to come back in "Filled" state, but a call to GetAtmStrategyMarketPosition(strategyId) comes back as Flat?

How is it possible for an open strategy position to come back flat even after two more ticks arrive?

I can work around this issue, but this race condition between order status and strategy market position seems like an obvious bug to me, perhaps Ninja can explain why it is not a bug.

[NinjaTrader_JoshP]

aslane,

Just because the order is filled, does not imply the position has changed yet. Similar to using things like OnOrderUpdate(), just because your order is filled, the position is not updated till OnPositionUpdate().

From our tests we have never ran into any situations where you would have several ticks pass after receiving the position update event and still have the mismatch on the OnBarUpdate() prints. You can see when you receive the event by looking at your trace/logs. Please clarify, thank you.

[aslane]

Well AtmStrategies are not event driven, though I have asked you for that feature. If they were, then this whole nonsense goes away because the code would not get executed in OnBarUpdate().

I thought I saw two ticks this AM, but I may be mistaken, will monitor and report back if I see.

Regardless, if you think your design is "ok", then you should change your sample strategy to explain what can happen. This may be the same as 6.5, but it should still be addressed so future users are not confused.

Update: In fast markets, you can see multiple ticks go by. In this AMs CL market, I saw 4 ticks go by before the marketPosition was updated!

[NinjaTrader_JoshP]

aslane,

Please provide trace, logs, and output of your scenario for analysis. Thank you.

[aslane]

I am going to pass on debugging your code, but the scenario is really quite easy to see. Using the sample strategy, in the leg of code that checks the order status, do not reset the orderId until filled and the marketPosition is not flat, then just count the number of ticks you see in that leg of code until you see the market position change and then reset the orderId. I have seen values up to 4 this morning, all during fast moves in the CL. A value of zero or one is the normal case. This is using B6.

Reproducing this could be rather difficult, given that it is data dependent, but I am confident that you do have an issue.

[NinjaTrader_JoshP]

aslane,

After clarifying with development, it has been brought to my attention that it can indeed be expected to have several OnBarUpdate() events pass through before receiving a position update. This means that the check of simply going by GetAtmStrategyMarketPosition() is insufficient for more advanced models of trade logic which may be employed within a NinjaScript Strategy. What you will want to look for is the filled order status followed by the change in position and only when these two are seen can you use the check.

[ATI user]

exactly...do not reset orderID when it is hit..wait until atm is filled...per my post above

...
finally added the code so nothing would happen (i.e. code would not change the orderID until confirmed filled in the atm).....until filled all round

I do not think the basic code is reliable without the added code for that reason