EnterLongLimit() and Null

[AAATradingSolutions]

The code has 2 parameters. AccelerationSize and AccelerationReturn

For example AccelerationSize = 6 and Return = 2.

It puts a EnterLongLimit at 6 ticks behind the price...
while you don't have a return of 2 tick , the order stays...

If you have a two tick returns , it moves the order.

the line that calculate the value for the LimitPrice is here :

double limitPriceLong = Instrument.MasterInstrument.Round2TickSize(Close[0] - ((accelerationSize - ACC.Acceleration[0]) * TickSize)) ;

So I don't cancel the order as normaly in managed order , you can simply move it by resubmit it.

The other part of code cancel the order when it reachs a zone near the DayHigh or day low

But that case doesn't come often. There is no cancellation in the output I gave to you

Regards

[NinjaTrader_Brett]

So I don't cancel the order as normaly in managed order , you can simply move it by resubmit it.

Understood, what I'm trying to get at is how are you resubmitting it.

This code segment here would not allow resubmit as entryOrder would never be == null. Am I missing a code segment? I feel that the constant resubmitting of the order at different prices is key to duplicating this race condition item.

double limitPriceLong = Instrument.MasterInstrument.Round2TickSize(Close[0] - ((accelerationSize - ACC.Acceleration[0]) * TickSize)) ;
if (CheckDayOHLOk(limitPriceLong))
{
// Cas ou on est dans les limites tradables
if (entryOrder == null)
{
entryOrder = EnterLongLimit(0, true, contractLots, limitPriceLong, "Entry"); PrintDebug("INITIALISATION EnterLongLimit , at limit : " + limitPriceLong);
}
else if (entryOrder.LimitPrice != limitPriceLong){
PrintDebug("DEPLACEMENT EnterLongLimit , at limit : " + limitPriceLong);
}
}
else
{
// Cas ou on est hors des limites Day OHL => on cancel
if (entryOrder != null)
{
CancelOrder(entryOrder);
PrintDebug("CANCEL ORDER Cause Limit Day OHL : " + limitPriceLong);
}
}

[AAATradingSolutions]

Brett ,

This code segment here would not allow resubmit as entryOrder would never be == null. Am I missing a code segment?

There is a Else on the condition if (entryOrder == null)

So in two words:

If entryOrder is null , it create the order and print "INITIALISATION"

else

it check if the value of LimitPrice must change
if yes , it resubmits the order and print "DEPLACEMENT"

So , thera are of course a lot of resubmit , and on very liquid market , it can occurs several times in the same second.

I feel that the constant resubmitting of the order at different prices is key to duplicating this race condition item.

Do you mean that Managed Orders are not able to work at that speed ?
If it is the case , you need to inform customers , and developers.

Do you think a correction is possible or is the system reach is limit in that case ?

Do you think an "unmanaged order" version of the strategy should run better ?

Regards

[NinjaTrader_Brett]

Hello,

Do you mean that Managed Orders are not able to work at that speed ?
If it is the case , you need to inform customers , and developers.

To clarify here the NT core is operating correctly. Its your code that runs so fast and submits orders so fast that it now needs to be coded to wait for order state changes. Currently you have race conditions when submitting that fast. I would recommend that you change your code to wait for the order to finish being submitted before taking new order action is what needs to be done here.

Do you think a correction is possible or is the system reach is limit in that case ?

Code needs to be corrected to wait for the order to have been accepted by the exchange before you try to modify it again. It is bad practice to submit several order modifications before the order is even accepted by the exchange. Which takes milliseconds in live scenario's since orders do not instantly get accepted once submitted.

Do you think an "unmanaged order" version of the strategy should run better ?

Unmanaged it would be the same, you would have to implement the same code then I mention above.

Basically, its never good practice to change orders until the change has completed at the exchange otherwise you run into race conditions which is a reality that needs to be dealt with in mulch-threaded applications. The managed approach would not SHIELD you from this.

FYI -> Never occurs in market replay as orders are always processed without delay.

-Brett

[AAATradingSolutions]

Thanks for the answer...

About the entryOrder = null because the other thread is not finish...

It is just a point of view. I also wrote multi-thread application and some thread must finish before answering to the other...

Of course , it will create lack in the onBarUpdate...

There are no bad solution.
The important thing is to have the good informations about how it works !

So as I understand , I need to test the OrderState of my entryOrder before resubmitting.

Is is correct :

                                case MarketPosition.Long:
                                    
                                    double limitPriceLong = Instrument.MasterInstrument.Round2TickSize(Close[0] - ((accelerationSize - ACC.Acceleration[0]) * TickSize)) ;
                                    if (CheckDayOHLOk(limitPriceLong)) 
                                    {
                                        // Cas ou on est dans les limites tradables
                                        if (entryOrder == null) 
                                        {
                                            entryOrder = EnterLongLimit(0, true, contractLots, limitPriceLong, "Entry");                    
                                            PrintDebug("INITIALISATION EnterLongLimit , at limit : " + limitPriceLong);
                                        }
                                        // On check si le entryOrder est ok
                                        else if (entryOrder.OrderState == OrderState.Working) 
                                        {
                                            if (entryOrder.LimitPrice != limitPriceLong)
                                            {
                                                entryOrder = EnterLongLimit(0, true, contractLots, limitPriceLong, "Entry");                    
                                                PrintDebug("DEPLACEMENT EnterLongLimit , at limit : " + limitPriceLong);
                                            }
                                        }
                                    }
                                    else
                                    {        
                                        // Cas ou on est hors des limites Day OHL => on cancel
                                        if (entryOrder != null) 
                                        {
                                            CancelOrder(entryOrder);                    
                                            PrintDebug("CANCEL ORDER Cause Limit Day OHL : " + limitPriceLong);
                                        }
                                    }
                                    break;

I added the test :

// On check si le entryOrder est ok
                                        else if (entryOrder.OrderState == OrderState.Working)

Must I test other OrderState ? May I test OrderState.Accepted to loose less time ?

Thanks for the support

Regards

[NinjaTrader_Brett]

On first glance I believe that should do the trick.

-Brett