Cache not getting refreshed/ Out of memory error

[Former Member]

We are in the process of refreshing the CPA cache of XI. After

refreshing, we are getting a message "No channel Registered for this

message". We are getting this message in run time workbench

communication chanel monitoring.

Despite CPA cache refresh twice, we are getting the same message.

During one of our earlier testing, we encounter "out of memory" problem.

As these issue are beccomg the repeatative, we are not able to carry

out the testing. As the planned go-live date is 1 st July, we would

request you to look in to the matter and provide the support.

Thanks & Regards,

[former_member529475]

Hi Vimal

try these;

1. make sure all your developed objects are saved and activated without errors.

2. try a complete cache refresh in SXI_CACHE.

3. run SAI_CACHE_REFRESH report in SE38.

Do revert back in case the problem persisits !!!

Cheers..

Vasu

<i>** Reward Points if found useful **</i>

[Former Member]

Hi Vimal ,

Please do the SXI_CACHE full mode refresh . Also to deal with Out of Memory exception you might have to increase the java heap size and also you should check the kind of mapping your are using becuase Resource consumption for the mapping depends on the complexity of the mappings and the source document sizes. In general, XSLT mappings require more memory than mapping classes generated by the XI Mapping Toolkit.

Since mappings are processed by the J2EE Engine, the maximum available Java heap may be a limit-ing factor for the maximum document size the XI mapping service is able to process. Tests have shown that processing of XSLT mappings consumes up to 20 times the source document size (using identity mapping). The maximum available Java heap for 32bit JVMs is platform-dependent. Using 64bit JVM platforms is an option here.

Current maximum heap sizes – 32bit

OS

Maximum heap (GB)

Linux

2

Windows

1.2 – 1.4

The Java heap is limited by the heap limit of the process (may be limited by address space because operating system code or libraries may also be loaded within the same address space). Also, Java internal memory areas such as the permanent space for loading Java classes must fit into the same address space.

Java VM tuning is one of the most crucial tuning steps, especially for more complex scenarios. For information about setting baseline JVM parameters, see SAP Note 723909. You must also take plat-form-specific parameters into account (for example, JIT compiler settings). The impact of Garbage Collection (GC) behavior especially may become a critical issue. Overall GC times for the J2EE appli-cation should be well below 5%. For more information about GC behavior and settings, see also SAP Note 552522.

Specific to XI is the fact that you sometimes need to process large documents for mapping or when using signatures. This can lead to excessive memory usage on the Java side. Therefore, you must observe Garbage Collection and the available Java heap in order to evaluate performance and pre-vent OutOfMemory exceptions. Since XI mapping is processed by stateless session beans that are called using a JCo interface, this may lead to a reduction of parallel JCo server threads within the JCo RFC Provider service of a J2EE server node (you can compensate for this by adding J2EE server nodes).

Thanks ,

Suvana

Award pts if it helps .