Transient File Analysis

[Macgyver2]

Hi,

I've been searching for memory leaks in our Web Services using the Transient Database File Analysis in the Jade Monitor. I noticed that some of the objects listed there have (RootSchema - system) next to them.

I was wondering if these are transient objects created by Jade and if I can do anything about them?

Any help would be greatly appreciated.

Kind regards,
Tony

[murray]

It depends what classes they are and whether your own logic is instantiating them. It is possible that your own code can be leaking RootSchema objects, e.g. Iterators were a particular problem for us, especially as they are pretty large. There are always "a few" objects used by the underlying system that should be there and left alone. I have done a lot of work in the past rooting out undeleted transient objects and it is best to start with the worst offenders. Typically I found there would be "one of these" and "a few of those" and THOUSANDS of one particular class. The worst offender will be the one filling up the transient overflow file. By using the Jade IDE "References" to cross check usage I could pretty quickly find some culprits. Basically, if you know which app and which class you can track it down. Of course, with Jade 7 you now have a static analysis tool to help.
Anything that creates an object, whether it be Jade, RootSchema, or user schema, should have a responsibility or strategy to delete it when it's not needed. I'm a great fan of symmetry, e.g. creating objects in the constructor, balanced by deletion in the destructor.

[mjagers]

FYI, if you have CardSchema schema loaded then there is a simple method that can be invoked (regardless of whether JADECare managed or not) which will provide the number of transient objects by class remaining.

If CardSchema is a super-schema then by simply invoking app.cnCheckForTransients, this will log the details into the cn_log (defined in ini file in CardLog section).

You can also add logic into re-implemented methods on Application sub-class titled:
- zCnUser_TransientsToIgnore - where you can define which, if any, transient objects to ignore from this list
- zCnUser_ViewTransientObjects - where you can define logic to act on any transients ie list them and when the object was created, the creation time perhaps giving a clue as to what logic may have done the creation.

If your JADE applications invoke app.cnActivateKarmaCntrl then all you need do is set [CardLog] CheckTransientsOnShutDown=true and this will be automatically performed in your application finalize.

If your JADE applications do NOT invoke app.cnActivateKarmaCntrl and CardSchema is a super-schema then the following logic will effect the logging:
create app.myCnCntrl transient; // provides the logging singleton CnCntrl
app.cnCheckForTransients();
....
epilog
delete app.myCnCntrl;

Refer to the CardSchema user guide which accompanies each release.

The JADECare Start package (contains CardSchema schema and documentation) is freeware and can be downloaded from https://www.jadeworld.com/developer-cen ... jade-care/

[BeeJay]

It looks like there are times where it displays the (RootSchema - system) after classes that have very little connection with RootSchema and are instances that were definitely not created by any Jade internals code.

The following screen shot shows a class called BeeJayTransientClass. This is defined in my test schema and I deliberately leaked several thousand instances of it from a test application before running the transient file analysis and found that it had the (RootSchema - system) annotation even for instances of this class.

Cheers,
BeeJay.

Transient file analysis.png (23.48 KiB) Viewed 12501 times

[Macgyver2]

Hi everyone,

Thank you very much for all your help. Unfortunately we don't have the CardSchema installed on our system.

I was just investigating some transient instances of the DictIterator class (RootSchema - system) that were being created hundreds of times on our system. I reimplemented the createIterator method on the MemberKeyDictionary and DynaDictionary classes and wrote out the method that was calling it from the Process Stack.

This helped me to find an iterator that was being created hundreds of times inside a while loop but was never actually being deleted

Thanks again!

Regards,
Tony

[JohnP]

As Murray mentioned, JADE provides a static analysis tool to help find leaks. It can be accessed from the Schema menu on the Schema Browser.

[Macgyver2]

Hi JohnP and Murray,

Thank you very much for telling me about the Transient Leaks tool. I've just started using it and I think it's going to be very useful.

Regards,
Tony