Java Mapping - Memory Use & Memory Recovery

[former_member193518]

Dear All,

XI 3.0 SP15

JVM changes:

server0: -xmx 1536 -maxperm 288 (standard +50%).

Our problem seems to be related to a high memory usage, but after following all available SAP tuning material and altering the JVM parameters accordingly we still can't work out what is wrong.

Our basic problem is that once a large message (16mb+) has been processed (and it does process successfully), the memory is not completely freed.

This allows three large messages to process (one at a time) before the fourth message blows the memory (permanent generation is full, no more heap to allocate).

Long running garbage collection is observed and eventually full GCs followed by an OutOfMemory error.

There is a strange phenomenon that if we leave the system for about 60 minutes after the last message processes, then re-send another message, significant memory is cleared with a full garbage collect.

We are using a custom Java mapping to translate a CSV flat file into XML, then the XML gets mapped through XSL and finally translated through XSL into an IDoc.

The initial CSV is uploaded into XI via the HTTP adapter and is about 2MB in size.

Through message tracing we can see that the resultant XML is generated in about 10 minutes and is 11Mb in size.

The Java developer has used the Spring framework to create a generic CSV to XML reader to perform the translation.

I know from the tuning guides that using XSL to perform translations on large XML files means that the memory used is about 20 x (message size). We can cope with that, but we think we have a memory problem with stuff not being cleared after.

I am about to undertake a long exercise with Sherlock to try and identify the problem.

Does anyone know off-hand, of any issues with memory clearance?

Are there any caches that get cleared after 60 minutes?

Has anyone had any issues with Spring classes in memory?

I am definately not interested in mapping in ABAP or anything like that.

The code is written and is what it is. I just want to try and understand what could be happening with the memory not being cleared in time.

Many thanks.

Darryl

[Former Member]

Hi

Also check your code, some times , many no of and many times objects may be used , may not be destroyed some unnecessary ones may occupy memory,

try to check loops..

if possible give code so that , easy to solve to any one.

Also

Check OSS Note 901080.

Symptom

When trying to create a Message-Mapping based on XSD that contains recursive structure definitions, the Integration Builder throws OutOfMemoryError or StackOverflowError.

Other terms

StackOverflowError, Message mapping, OutOfMemoryError

Reason and Prerequisites

Program error in XI 3.0

Solution

Install XITOOLS 3.0 SP 14 patch level 5, or later.

Also see some links

Regards

Chilla..

Message was edited by:

Chandra Sekhar Chilla

[Former Member]

Hi Darryl,

did you already try to change the parameters of the garbage collection?

You could even use one of the other GCs...

Kind regards,

Dennis

[former_member193518]

Hello Dennis,

I have left the standard GC parameters.

GC collections are output with timestamps to the std_server0.out file.

Do you have any other params I can use to get more class related info?

What other GCs could I use?

Thanks for your help.

Darryl

[Former Member]

Hi Darryl,

We are currently faced with the same 'Out of memory' problem. Can you please advise what you did to resolve this problem. Your assistance is much appreciated.

Kind regards

Nazlie

[former_member193518]

Nazlie,

Unfortunately we still get the same problem.

We haven't managed to solve this yet.

I am hoping that an upgrade to a later SP level will cure the problem.

When performing our analysis, it did seem that the Java code used to perform the mapping was the problem. All garbage collection analysis showed new classes being created (class sun.reflect.GeneratedSerializationConstructorAccessor) for each new large message. The previous classes didn't seem to get freed until a much later time.

We spent hours ensuring that all referenced objects were being set to null after use, and that all objects could be freed.

Still no solution.

We did find the following to OSS notes useful though:

NOTE: 520684 details the ESM buffer error.

NOTE: 932005 details the EG memory leak error.

Regards,

Darryl

[Former Member]

HI,

Try

You need to increase the Java Heap Memory size.

Just Check this SAP Note - 883444, 874123, 862405, 760721

Regards

Chilla..