Fixing Undisposed Operations (trace / coding)

Epicor ERP 10
,
1

I recently enabled appserver.config trace flag: <add uri="trace://ice/fw/disposable" /> in an attempt to see any failures to properly dispose of objects in customizations and BPMs.

What I found was a number of warnings where I’m not sure I have any direct influence on the design or possible failures to dispose of the mentioned objects.

For instance I am seeing some warnings for BOReader (GetList) or the GenXData (ChgLogHandler) where I am not calling these directly within custom code.

Can I safely ignore these warnings as base code problems?

With respect to custom code: consider the following warning message provided by the trace:
<Warning msg="Found 1 undisposed operation bound object(s) found after Ice:BO:X/XContract/DoMethod. IDs: XSvcFacade" />

Consider this the customization call to the X BO.

using(xadapter = new XAdapter(this.oTrans))
{
    xadapter.BOConnect();
    xadapter.DoMethod();
}

Is there something missed that generates this warning, or can I also assume there is a base failure to dispose XSvcFacade within the service or underlying architecture?

2

It appears you’ve previously declared xadapter. Maybe that’s why it isn’t being disposed?

try and see if this makes a difference, it should force a new instance:

using(XAdapter xadapter = new XAdapter(this.oTrans))
{
    xadapter.BOConnect();
    xadapter.DoMethod();
}
3

As long as you are not causing the issue in a BPM then its a base issue. We might still have a couple running around and open SCRs. We did a pretty thorough scrub a few releases ago because the memory usage was too high for some long running tasks (e.g. MRP and the like). Open a ticket on these any time you see one. If you are behind a release or two hopefully it’s already fixed.

One note - that is a warning meaning the framework cleaned up after the ‘unoptimized’ code :wink:
There is another trace for ‘ERROR’ on the disposing meaning the framework could not clean it up and is a real memory leak.
This warning means that memory/resources are not being freed up as efficiently as could be done. My real concern is db connections that get left held open. The first time we checked MRP back in the beta days we were holding open 1000’s of db connections. MRPO was not to blame, the libraries and services it called were not freeing resources fast enough so we did a significant cleanup. This is a concern whenever you have any long running task (Process or Report).

4

Okay this is great news! Prioritize any explicitly called out errors (haven’t seen any yet). I’ve seen generic implementations of IDisposable garbage collected warnings and figured this was the sort of thing that was strapped on here.

5

From a pure geek point of view I enjoy the whole garbage collection area so love geekng on this. I may have been on a dispose handling soapbox a few dozen times. I love the topic every since Chris Sells did his challenge in Rotor back in the day.
When we went to Microsoft in one of the early POC trips we hit 30% cpu spent in gc so have been all over the topic ever since. When you get some of the BCL devs coming in one on one for a week, you appreciate a few things

1 Like
6

Does anyone know if I need to recycle the IIS pool to see this trace and if enabling this trace flag has any impact on performance?

7

No, for both questions

2 Likes
8

Olga, may I just add it to the app.config and then we are good to go? No need to recycle or anything?

9

you mean AppServer.config? Same place where all other trace flags are

10

Yeah I got it, been a minute. Thanks Olga.

Can you tell me what Bart meant by this, “There is another trace for ‘ERROR’ on the disposing meaning the framework could not clean it up and is a real memory leak.”

Do I need to turn on a different trace flag to see Errors?

11

no, only one flag for this, it should show both.

12

Okay, thank you so much. We have been getting some CPU spikes where it gets stuck at 99% on the app server. No task agent running there.

I have been trying to find some type of pattern using the PDT tool to go through the server logs, but I can’t seem to find anything.

I am hoping this trace flag will help.

Do you have any other recommendations to troubleshoot this?

13

This flag is more for development and memiry cleaning. Not sure how it will help you. you need to figure out what operation is running on server at the moment of spike

14

Olga, from what I have researched in order to find what operation is running on the server I could look at the system monitor. But sometimes there is nothing running there.

So then what do I do? I have read others post that I need to query database tables as well and potentially something will be in there.

I have also read in the tech ref guides for sys admin to use the PDT tool.

Is there any other tool I am missing?

Here’s my issue, the w3 iis process is spiking CPU, how can I find the process that is consuming the memory at the time of the spike. There are thousands in the server logs. And the server logs don’t log how much memory each process is consuming, does it? Is there any way to log that?

Thanks so much for your time Olga.