Problem with Position.Quantity after OnExectionUpdate on TWS

[tanas.eduard]

Good afternoon. We have a question about the update of Position. We know that when working with IB we need to use method OnExectuionUpdate for processing of orders. But we faced with the fact that after OnExectuionUpdate we check the Position.Quantity and there is 0. But the position was executed. Please tell us in what order the Position variable is updated. The weird thing is that it happens once for 50-100 orders, in general, the Position parameter is always filled out correctly.

The trace of the section we are interested in is in the attachment.
According to our logs, the OnExecutionUpdate method was called on 2023.04.17 16.32.36.423.
After processing the logic in the method, we check the position at 2023.04.17 16.32.36.441 and at this point Quantity=0 and MarketPosition=Flat

[QuantKey_Bruce]

Have you read the help on this function yet? https://ninjatrader.com/support/help...tionupdate.htm

You shouldn't be referencing Position.Quantity at all - you should be using the parameters that are passed into the function such as quantity because this can execute in a different thread and depending on the sequence of events Position might not be updated yet.

If what you want is to monitor position changes, you should perhaps using OnPositionUpdate https://ninjatrader.com/support/help...tionupdate.htm.

Be sure to read both of these pages fully before you write the code - you need to understand what these parameters represent relative to the Position etc. objects accessible in OnBarUpdate.

[QuantKey_Bruce]

Basically, the assumption implied in your question is that this is a single-threaded application and everything will happen in a strict sequence. That is not the way the platform is designed - it is multithreaded and several events can be processed simultaneously.

[tanas.eduard]

Thank you very much for your answer. We do everything in multi-threads as well, but just when developing we expected that initially Position is updated and then OnExecution is called. Thank you very much for the clarification. We will rewrite this piece of code with different logic. It simply appears that when setting a protective order, we can never rely on the Position variable since it is in a separate thread and it makes no sense to focus on it for processing the position. We have already encountered similar problems when there was SL processing in TWS and the position was updated incorrectly in Ninja. We will then rewrite the code and read the position in a separate variable ourselves.


Then help me to understand one more question. In the onBarUpdate method we call some updates to the UI elements we create in the Chart. We do the update with InvokeAsync. For the test we were outputting Close[0] value and it didn't match.
Example code:

     protected override void OnBarUpdate()
        {
            Print(Close[0]);
            ChartControl.Dispatcher.InvokeAsync(new Action(() =>
            {
                lbConfirmationClose.Content = Close[0].ToString();
            }));
        }​

[QuantKey_Bruce]

Well, by the time the dispatcher has time to get a UI thread going, Close[0] might have moved on. Why don't you set that value into a variable e.g. double MyClose = Close[0]; and then do the same thing (print it, and invoke the chart control's UI thread and print it) but this time reference your saved copy MyClose... what does that do in this case?

[tanas.eduard]

We did so, all the necessary data before processing all threads are written into a variable, but I have a question about the fact that Close, which in dispatcher, outputs a price that was not on the market that day. And I'm trying to understand how the price that wasn't there even after milliseconds of synchronization. An example of today's SPY. The Hi price was 413.99 at the moment we analyzed, but the Close[0] of the dispatcher showed 414.17. We want to understand why it happened this way. In our calculations we rely on the data in the variables, but in the UI part of the user displays a lot of additional information and sometimes we look directly into the data stream, but with synchronization, and noticed this strange situation.

[QuantKey_Bruce]

I don't think Close is defined in the UI thread the way you are using it - that's why I suggested you buffer the value over - for instance, by passing it as an argument into that lambda action. Remember, the ChartControl thread could be on various other instruments etc. or on the same instrument but at a different index - it's part of a shared thread pool and is not specific to this instance so it doesn't know what the bar number is or what bar series you are processing - the invoke has lost all of that.

[tanas.eduard]

Okay, thank you very much for the super prompt and quality clarification. Have a nice day.

[NinjaTrader_BrandonH]

Hello tanas.eduard,

Thanks for your post.

IB and Rithmic's order, execution, and position events do not have a guaranteed order as noted in the 5th bullet point in the Notes section of the OnExecutionUpdate() help guide page.

OnExecutionUpdate(): https://ninjatrader.com/support/help...tionupdate.htm

Since these overrides (OnOrderUpdate/OnExecutionUpdate/OnPositionUpdate) can trigger in any sequence, the object (like the order or execution) is only guaranteed to be updated in the override from the passed parameter.

As QuantKey_Bruce stated, "you should be using the parameters that are passed into the function such as quantity because this can execute in a different thread and depending on the sequence of events Position might not be updated yet." This is noted in the help guide page linked above.

From the help guide: Its best practice to only work with the passed by value parameters and not reference parameters. This insures that you process each change of the underlying state.

I have attached some reference samples that are IB/Rithmic friendly that you might find helpful.