When is OnPositionUpdate called?

[westofpluto]

Is OnPositionUpdate called in a separate thread from OnBarUpdate? In other words, is it possible for OnPositionUpdate to be called in the middle of execution of OnBarUpdate? Or are these synchronized so that this never happens?

[bltdavid]

Is OnPositionUpdate called in a separate thread from OnBarUpdate? In other words, is it possible for OnPositionUpdate to be called in the middle of execution of OnBarUpdate? Or are these synchronized so that this never happens?

No, that is not possible.

[EDIT: My bad, apparently in NT8, that scenario is possible.]

[hedgeplay]

This thread is now 2 years old but still the best detail discussion I can remember on exact sequencing ...
OnMarketData vs. OnBarUpdate Price Level Question
https://ninjatrader.com/support/foru...d=1#post828394

Also another quote from iantg comes to mind.... "OnPositionUpdate lags OnOrderUpdate by a few seconds some times and (can just be redundancy) if you know how to track your position with OnOrderUpdate..."

HedgePlay

[NinjaTrader_Jim]

Hello everyone,

OnOrderUpdate, OnExecutionUpdate, and OnPositionUpdate come from non-instrument threads. When trading live, this would come from a Connection Adapter thread. This is asynchronous to Instrument threads which drive realtime market data updates to OnBarUpdate, OnMarketData, etc. It is possible to have a position update "in the middle" of an OnBarUpdate iteration.

It will be rare to encounter issues when simply using OnBarUpdate and the strategy's Position object to track your position. However, if you want extra security to have your position managed by the order/execution/position events instead of just processing in data processing events like OnBarUpdate, OnOrderUpdate, OnExecutionUpdate and OnPositionUpdate are there to use.

To give some clarity on event ordering: most API's follow 1. Order 2. Execution 3. Position ordering. Strategy positions (the Position object) are updated as early as OnExecutionUpdate. The Account position (the PositionAccount object) is updated with Position updates. Rithmic and Interactive Brokers do not follow this event ordering through NinjaTrader, so for those connections, it is recommended to use OnOrderUpdate alone. This also means that if you want to track a Position object, you will have to create and manage your own strategy Position through Filled and Partial Filled OrderUpdates, and use the Unmanaged Approach since the strategy position is updated in ExecutionUpdates. (The Managed Approach is internally tied to the strategy position.) I have attached an example that can shed some light on building an OnOrderUpdate only Unmanaged strategy.

To give some clarity on OnMarketData, OnBarUpdate, and GetCurrentBid/GetCurrentAsk, OnBarUpdate always comes before OnMarketData (indicators like BuySellPressure/BuySellVolume are built around this ordering.) GetCurrentBid/GetCurrentAsk skip ahead of the data processing methods and fetch the most recent Bid/Ask from the level 1 data feed. This is ideal to be used to offset orders from the current market price so the order is not placed to the other side of the market.

Please let us know if you have any additional questions.

[hedgeplay]

Thanks Jim, This is a great post.

With an eye toward hoping to see NinjaTrader success continue to grow over time I think this content would be a great addition to the NT8 Guide.

The attached ZIP file made my short list of key samples .. to use when NinjaTrader is not the order’s execution broker.


----------------

Following the NT guidance to consolidate multiple strategies impacting an instrument into one strategy has raised a few new complexities to work through. This page in the NT8 Guide is very good but still leaves a few questions unanswered https://ninjatrader.com/support/help...-threading.htm

So I have a few follow-up questions to further clarify the threading approach.

OnBarUpdate() : Will OnBarUpdate() events always process one at a time to completion before starting to process the next incoming OBU() event?

1. My assumption is OBU() will process events for the same instrument to completion before starting to process the next OBU() for that instrument. Please correct me if this is wrong.

1. However, if we use AddDataSeries() in OSC Configure to add an additional four completely different instruments all using period types different than a chart’s primary data series does each OBU() event need to process to full conclusion before the next queued OBU() event starts processing or might we see OnOrderUpdate() events processing in parallel or at least with some overlap?

OnOrderUpdate(): 1) When we have many active concurrent orders for the same instrument changing states within the same second or two will we ever see OnOrderUpdate() events processing with at least some at least with some overlap in time?
2) What about when a strategy has active concurrent orders for multiple instruments changing states within the same second or two?


What about for OnExecutionUpdate() OnPositionUpdate() OnOrderTrace() and OnAccountItemUpdate()?

1. When we have many active concurrent orders for the same instrument changing states within the same second or two will we ever see these methods processing events with at least some at least with some overlap in time?
2. What about when a strategy has active concurrent orders for multiple instruments changing states within the same second or two?

Thanks Much!

[NinjaTrader_Jim]

Hello hedgeplay,

I'm glad the info was helpful.

OnBarUpdate processes bars historically in chronological order from bar timestamps and then will process bars in the same order as developed from the BarsType. (We can note that historical processing may have discrepancies where ticks have the same timestamp get unrolled in a chronological order from timestamps, but may not be in the same order given from the data provider.)

Each update will process the OnBarUpdate iteration before the next update is processed.

The next OBU will require the last OBU to be completed, and this is the same for Multi Time Frame scripts.

OnOrderUpdate (adapter thread) is on a separate thread than OnBarUpdate (instrument thread) so this can happen mid-bar. We can have order updates for other orders come in OnOrderUpdate when these order updates are received at the same time (I.E. Order1, Order1, Order2, Order1, Order2, etc.), but you can expect that each order will follow the same OrderState ordering. I.E. Submitted, Accepted, Working, Filled. (We would not expect a Submitted OrderState for an order to come after a Filled OrderState.) OrderUpdates are also processed sequentially so OnOrderUpdate will be processed for one OrderUpdate before processing the next.

As for the other events listed (which would be adapter related threads) these will also wait for one update to be processed before processing the next. We can also expect this from strategies.

In a nutshell, separate threads may overlap eachother, but operations on the same thread will not run-ahead of eachother.

Let us know if there is anything else we can do to help.

[Trader17]

Is OnPositionUpdate called in a separate thread from OnBarUpdate? In other words, is it possible for OnPositionUpdate to be called in the middle of execution of OnBarUpdate? Or are these synchronized so that this never happens?

I could not figure that one out either. All this is happening in a fraction of a second on each upcoming tick. So as soon as a bar is updated how can NT8 be absolutely sure that this happens in an orderly fashion is beyond me.

[NinjaTrader_Jim]

Hello Trader17,

OnBarUpdate is on a different thread than OrderUpdate ExecutionUpdate and PositionUpdate events. Please see my response in post #4 for more details.