"Not enough quota is available..." followed by "Write lock..." error

[backtester831]

Thank you for this. This issue has bugged me endlessly, but I have never been able to reproduce it with a simple indicator. It always shows up only when I am running many copies of a complex indicator that is performing statistical analysis on multiple instruments.

Unfortunately, NT8, I am reasonably sure is entirely generated by Visual Studio without hand optimization, so there may be little that any of us can do. It turns out that this message about quota exhaustion is almost entirely due to a Windows Messaging Queue limitation of 10k messages. That looks like a lot, until you meet an application (framework) which is flooding the queue with messages. Remember how you are inducing it by moving charts around somewhat rapidly?

There is a registry key, USERPostMessageLimit, that can be used to adjust this limit. Somehow I doubt this is a viable workaround. WPF rendering just sends a whole lot of messages. Add all the stuff we (too ambitiously?) try to do with NT8, and we all have problems. I would not even blame it on NT8. This looks more like a Windows issue.

ref: https://docs.microsoft.com/en-us/win...threadmessagea

I know this is an old thread, but did you have any luck with this? I'm having the same problem, and the workaround for changing USERPostMessageLimit, USERProcessHandleQuota, or GDIProcessHandleQuota doesn't help. Increasing Virtual Memory doesn't help either because the message quota is still reached because the underlying issue with the indicator, .Net Framework, or whatever is causing the problem, is still there.

My trace file from today, and can easily consistently replicate:

2022-05-25 15:44:27:072 *************** unhandled exception trapped ***************
2022-05-25 15:44:27:072 Not enough quota is available to process this command
2022-05-25 15:44:27:075 System.ComponentModel.Win32Exception (0x80004005): Not enough quota is available to process this command
at System.Windows.Interop.HwndTarget.UpdateWindowSett ings(Boolean enableRenderTarget, Nullable`1 channelSet)
at System.Windows.Interop.HwndTarget.UpdateWindowPos( IntPtr lParam)
at System.Windows.Interop.HwndTarget.HandleMessage(Wi ndowMessage msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Interop.HwndSource.HwndTargetFilter Message(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation( Object o)
at System.Windows.Threading.ExceptionWrapper.Internal RealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatch When(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

Unfortunately in my case it is a vendor indicator, so I don't have access to the NinjaScript code.

Anyone know of a way to further analyze the problem?

I've also noticed that after this error occurs, shutting down NinjaTrader doesn't end the process. In task manager, NinjaTrader moves from active apps category to Background Processes, but is still consuming the full amount of RAM it did prior to shutting NinjaTrader down.

Back to the original post that created this thread, I suspect the indicator is locking something, and fails to unlock, which then generates a many errors and exceeds the Windows Messaging Queue.

Any ideas how to see the contents of the message?

[NinjaTrader_Jim]

Hello backtester831,

Thanks for your post.

While adjusting Virtual Memory or registry settings may give some temporary relief, it may "kick the can down the road" and prevent a real solution from coming forward. It is something you can try, but we would not recommend these solutions and would prefer getting down to specific cases where the behavior can be reproduced so the developer can work with us.

By your description, I agree, it sounds like something is locked if you see the platform still running in Task Manager after attempting to close. It could very well be as you describe where the Messaging Queue gets overloaded from this fact, and the Quota error would be a symptom rather than a cause.

I can say that these errors have become far less frequent, and we see setups operate for long periods of time with stability, without hitting these issues.

That being said, we cannot say for certain where the issue lies. This would need to be reviewed by the developer of the AddOn to show how the issue is encountered, and how their code is involved. I would focus on reproducing the freeze in a way where the AddOn involved is isolated.

If you have identified that an AddOn is involved, it will be necessary to work with the developer to see if the issue can be reproduced the same way you are testing.

I can see different computers making it more difficult to test and keep things apples to apples. If you are tech savvy, you could maybe illustrate the symptom in a Virtual Machine so the vendor can do the same and then work with us on any specific code that causes this to happen.

From there, we would be able to advise a solution, or if there is an issue with the platform, it will be clear how to analyze and address it.

Regarding the quota errors, if the AddOn follows best practices, and we have a way to reproduce the issue, we may uncover something platform side that can be improved to tame and avoid hitting quota limits.

[backtester831]

Hello backtester831,

Thanks for your post.

While adjusting Virtual Memory or registry settings may give some temporary relief, it may "kick the can down the road" and prevent a real solution from coming forward. It is something you can try, but we would not recommend these solutions and would prefer getting down to specific cases where the behavior can be reproduced so the developer can work with us.

By your description, I agree, it sounds like something is locked if you see the platform still running in Task Manager after attempting to close. It could very well be as you describe where the Messaging Queue gets overloaded from this fact, and the Quota error would be a symptom rather than a cause.

I can say that these errors have become far less frequent, and we see setups operate for long periods of time with stability, without hitting these issues.

That being said, we cannot say for certain where the issue lies. This would need to be reviewed by the developer of the AddOn to show how the issue is encountered, and how their code is involved. I would focus on reproducing the freeze in a way where the AddOn involved is isolated.

If you have identified that an AddOn is involved, it will be necessary to work with the developer to see if the issue can be reproduced the same way you are testing.

I can see different computers making it more difficult to test and keep things apples to apples. If you are tech savvy, you could maybe illustrate the symptom in a Virtual Machine so the vendor can do the same and then work with us on any specific code that causes this to happen.

From there, we would be able to advise a solution, or if there is an issue with the platform, it will be clear how to analyze and address it.

Regarding the quota errors, if the AddOn follows best practices, and we have a way to reproduce the issue, we may uncover something platform side that can be improved to tame and avoid hitting quota limits.

Hi Jim,

Is there a way in NinjaTrader, perhaps undocumented config setting, that can reduce GUI updates or set a limit?

This other user speculates it might be an error caused by rapid chart updates: https://ninjatrader.com/support/foru...t-enough-quota

For me, it only happens with Tick Replay on in Data Series, many charts, and the indicators paint over large regions of the chart, with thousands of Drawing Object across all charts.

[NinjaTrader_Jim]

Hello backtester831,

I don't have any undocumented settings to recommend.

We also have to remember that the older thread you linked is from 2015. There have been many internal changes to NinjaTrader, and we do not know the code involved that creates the issue for your specific case.

We would need to know what code is involved with the indicator when you reproduce the issue. The developer will need to get involved to see what they are doing in their code where the issue comes up.

If you cannot provide the developer a means to reproduce the issue, they could provide you smaller test scripts that can narrow things down.

If it comes down to the way they are using Drawing objects, we would then be able to give our insight for solutions or may be able to report something to our Development team.

[backtester831]

Hello backtester831,

I don't have any undocumented settings to recommend.

We also have to remember that the older thread you linked is from 2015. There have been many internal changes to NinjaTrader, and we do not know the code involved that creates the issue for your specific case.

We would need to know what code is involved with the indicator when you reproduce the issue. The developer will need to get involved to see what they are doing in their code where the issue comes up.

If you cannot provide the developer a means to reproduce the issue, they could provide you smaller test scripts that can narrow things down.

If it comes down to the way they are using Drawing objects, we would then be able to give our insight for solutions or may be able to report something to our Development team.

Hi Jim,

Wondering if you could help me with something related. For my setup, I'm using:

• Rithmic for NinjaTrader Brokerage connection (not using plugin mode)
• R Trader Pro running in the background (w/ market data off)
• Tick Replay enabled on multiple charts

I've noticed in the trace files, there's always an automatic connection line just before the Not enough quota is available error. Below is a snippet of the trace file from this morning:

2022-05-27 06:40:24:543 Cbi.Instrument.RequestBars (to Provider): instrument='ES 06-22' from='5/27/2022 6:00:00 AM' to='5/27/2022 11:59:59 PM' period='1 Tick'

2022-05-27 06:40:24:578 Cbi.Instrument.RequestBars (to Provider): instrument='YM 06-22' from='5/27/2022 6:00:00 AM' to='5/27/2022 11:59:59 PM' period='1 Tick'

2022-05-27 07:39:38:896 Server.HdsClient.Connect: type=IS server='is-us-nt-001.ninjatrader.com' port=31658 system='NT' useSsl=True

2022-05-27 07:39:39:171 Server.HdsClient.ProcessStartupInfo.Info0: Commissions=0 InstrumentLists=0 MasterInstruments=0 Messages=3 Risks=0 RolloverCollection=0 TradingHours=0
2022-05-27 07:39:39:173 Server.HdsClient.ProcessStartupInfo.Info1: Commissions=0.00ms InstrumentLists=0.00ms MasterInstruments=0.00ms Messages=3.25ms Risks=0.00ms RolloverCollection=0.00ms TradingHours=0.00ms

2022-05-27 07:47:48:338 *************** unhandled exception trapped ***************
2022-05-27 07:47:48:339 Not enough quota is available to process this command
2022-05-27 07:47:48:345 System.ComponentModel.Win32Exception (0x80004005): Not enough quota is available to process this command
at System.Windows.Interop.HwndTarget.UpdateWindowSett ings(Boolean enableRenderTarget, Nullable`1 channelSet)
at System.Windows.Interop.HwndTarget.UpdateWindowPos( IntPtr lParam)
at System.Windows.Interop.HwndTarget.HandleMessage(Wi ndowMessage msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Interop.HwndSource.HwndTargetFilter Message(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation( Object o)
at System.Windows.Threading.ExceptionWrapper.Internal RealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatch When(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

I've also noticed that the trace file doesn't timestamp the 'unhandled exception trapped' at the time when the chart freezes. What happens is the chart freezes, and then manually closing the frozen chart brings up the error dialog box. So the timestamp of the error is when the chart is closed, but I strongly suspect the freeze actually happens at or closer to the time of Server.HdsClient.Connect line.

Market data was continuously flowing for about an hour before this line: Server.HdsClient.Connect: type=IS server='is-us-nt-001.ninjatrader.com' port=31658 system='NT' useSsl=True

What does that line mean? There's nothing else about a connection disconnecting.

I know for a fact it's not on my internet's side, is it a Rithmic connection / R Trader Pro thing?

[NinjaTrader_Jim]

Hello backtester831,

Unfortunately, this really does not tell us anything.

The line you mentioned has to do with reaching NinjaTrader information servers for DB updates. It would not be related to this issue.

With this issue, we don't know what specifically is included in the workspace that is causing the quota to be consumed, and we don't know the steps involved to reproduce the issue. Quite likely, some other issue is happening and then you see the symptoms and then the quota message.

The first step is isolating the components involved to point out what is causing the quota to be consumed.

This can be done by repeating your test to reproduce the issue, and to test removing charts, and then specific components from charts.

If you can reproduce with just NinjaTrader out-of-box components, share a workspace file here and tell us how to reproduce the issue.

If this happens with a specific 3rd party components, you have to involve the developer.

[backtester831]

Hello backtester831,

Unfortunately, this really does not tell us anything.

The line you mentioned has to do with reaching NinjaTrader information servers for DB updates. It would not be related to this issue.

With this issue, we don't know what specifically is included in the workspace that is causing the quota to be consumed, and we don't know the steps involved to reproduce the issue. Quite likely, some other issue is happening and then you see the symptoms and then the quota message.

The first step is isolating the components involved to point out what is causing the quota to be consumed.

This can be done by repeating your test to reproduce the issue, and to test removing charts, and then specific components from charts.

If you can reproduce with just NinjaTrader out-of-box components, share a workspace file here and tell us how to reproduce the issue.

If this happens with a specific 3rd party components, you have to involve the developer.

Hi Jim, I'm certain it is due to the 3rd party indicator. Is there anything else I can do to narrow down the problem? Any other .Net logs, or anything I can look at for more clues?

[NinjaTrader_Jim]

Hello backtester831,

Unfortunately, this information won't help.

The specific component(s) involved need to be isolated, and then the related code would need to be looked into.

[backtester831]

Hello backtester831,
The line you mentioned has to do with reaching NinjaTrader information servers for DB updates. It would not be related to this issue.

I just replicated again and the chart consistently freezes right after 2022-05-27 09:03:42:094 Server.HdsClient.Connect: type=IS server='is-us-nt-001.ninjatrader.com' port=31658 system='NT' useSsl=True

Looking back through the logs from the last couple of days, I am convinced the error is related to the DB updates.

I'm guessing the 3rd party indicator has a problem after NinjaTrader gets DB updates.

But my question to you is what would cause NinjaTrader to request DB updates? The only other time there is a Server.HdsClient.Connect in the trace files is when NinjaTrader first launches (before connecting to any data/account connections).

My only connection is Rithmic for live market data, so what's NinjaTrader updating from is-us-nt-001.ninjatrader.com after it's already been running for a while, and what happens as part of the update? Perhaps there's some sort of refresh after the DB update that the indicator is having problems with?

[NinjaTrader_Jim]

Hello backtester831,

NinjaTrader does this on start up and daily. It is to make sure instrument definitions (rollover dates etc.) are updated.

I would not continue with guesses, as they will not lead anywhere.

What is needed to analyze the issue is to know the specific components involved, reproduce the issue, and examine the code involved.

Without this detail, and without involvement of the developer, we cannot help address the issue.

[backtester831]

Hello backtester831,

NinjaTrader does this on start up and daily. It is to make sure instrument definitions (rollover dates etc.) are updated.

Thank you Jim, I understand what you're saying. I'm not so much looking for a solution from NinjaTrader support, just discussing.

I've now consistently isolated the problem to the chart freezes every time on the 2nd time NT calls out to update instrument definitions (rollover dates etc.)

My problem is that the developer hasn't been very helpful, so I'm trying to figure out workarounds like if it's possible to stop NinjaTrader from making that update mid-session? That is to say, only update as part of NinjaTrader startup, but disable it from updating again mid-session? Is it possible there's a setting to overwrite this update behavior in the config files?

[NinjaTrader_Jim]

Hello backtester831,

I think you are getting distracted by the Information server update. This should not have anything to do with a script or chart causing freezing issues. (You may test with third party components excluded to see if the issue is related to the Information Server updates instead of the external component.)

Getting the issue reproducible is the first step.

The next step is getting the developer involved so they can test the same and see the. If they can't reproduce the issue, but you can verify you see the issue only when that script is in use, they can provide smaller test scripts that you can test so they can pinpoint what in there script is contributing to the issue.

If the developer has questions on how this can be narrows down, please have them chime in here, or have them email me at scriptingsupport [at] ninjatrader [dot] com.

There really is no other path forward I can suggest.

[neoikon]

karlmac I know this is an old thread, but did you ever find a definitive solution?

I have a custom Drawing Tool, that I keep simplifying as much as I can and putting try/catches everywhere I can, but I can't seem to get anything to catch or output anything to the debug window before the chart just freezes.

I've simplified my workspace to a single chart with nothing else running. As you mention, it seems to only be a problem when there is a live data feed.

As I mention, it's a Drawing Tool and I need to do actions when price changes. Perhaps that is what I'm doing wrong? Where should I perform the below?

// Defined globally
private MarketData marketData;

if (marketData == null)
{​
   marketData = new NinjaTrader.Data.MarketData(GetAttachedToChartBars ().Bars.Instrument);
   marketData.Update += OnMarketData;[/I]​
}

I'm not completely positive that my "Not enough quota is available to process this command" is real or just a side effect of the chart being in a frozen state. Sometimes the chart freezes, but I don't actually get any kind of error.

Is it better to use "GetAttachedToChartBars().Bars" or "AttachedTo" within a Drawing Tool?

When should we attach the OnMarketData()? I would love to do it within OnStateChange(), but "AttachedTo" is always null (in ALL calls to OnStateChange()) unless you refresh the chart or enter the properties... or Terminate). It seems that OnStateChange() is called before we place the object on the chart (so it's not officially "attached" yet).

So, I'm forced to do the above code in OnRender(), which doesn't feel right.

In any case, I have to force close NT from Task Manager, since it's in a broken state.

I've been developing on NT for over 10 years, just to put things in context.

Any help is greatly appreciated!

[NinjaTrader_Jesse]

Hello neoikon,

The code you are showing should not be used from OnRender, you would need to find a different location in your script if you absolutely need to use that. There are not any specific suggestions for that code in a drawing object, that codes intended use is from an addon so there may be no valid use case in a drawing object for that. Generally drawing objects would not subscribe to their own data because that could become very resource intensive. Drawing objects are instead intended to use the data from the chart its attached to.

You can see a sample of how to correctly subscribe to the market data here: https://ninjatrader.com/support/help...sub=MarketData

Your code is missing the invoke async so that could end up causing a threading issue depending on where it was called from.

GetAttachedToChartBars and AttachedTo serve different purposes so there is no suggestion about which is better because those are two different concepts. You can see the existing drawing tools that the platform comes with for some general guidelines on how to make a drawing tool and where each of those items are used commonly.

If you need to use live market data I would suggest to avoid using a drawing object and instead use an Indicator which natively has a OnMarketData override that can be used, they also have OnRender for custom rendering.

[neoikon]

Thank you for the reply. I will look deeper into your suggestions/link.

I'm confused by "there isn't a use case". A simple example is you draw a line and you want to know if price hits that line. So, the drawing object needs to know the current price. Ultimately, what is the best way for a drawing object to know the current price?

Perhaps I should've asked "GetAttachedToChartBars().Bars.Instrument" versus "AttachedTo.Instrument". If there is one that is preferred.

I'm thinking this is what I want and it would make sense that my lack of "InvokeAsync()" would be problematic:

if (!bAttachedListener)
{
   Cbi.Instrument instrument = Cbi.Instrument.GetInstrument(GetAttachedToChartBars().Bars.Instrument.ToString());
   if (!instrument.Dispatcher.HasShutdownStarted)
      instrument.Dispatcher.InvokeAsync(() => instrument.MarketData.Update += OnMarketData);

   bAttachedListener = true;
}