[Rhenus ICT Servi...]

When processing a file of 4.3 MB with approx. 24000 lines (records) using an object-mapping (FILEIN -> ORACLESP) the memory usage is quite high (around 700 MB) and the processing takes about 15 minutes (even on an fast Oracle-testserver that is not doing much besides receiving the data XIB delivers)

When the map is running I can see the memory usage going up 1 MB per second

Why is XIB (2.1.1) using so much memory in a ORACLESP-mapping and why is it taking so long. (a simple DB dump with the sqlloader is much, much faster) ?

I already placed a //DISPOSE directive at the input-container, but this is not having any effect.

Also the proc.engine is not returning the memory to the system after completing the mapping; it's only given back to the system after manually stopping the proc.engine.

[vidya]

give a try with the BEQUEATH_DETACH strategy

[Rhenus ICT Servi...]

give a try with the BEQUEATH_DETACH strategy

What is this 'BEQUEATH_DETACH strategy' and how do I configure this?

P.S. I have the strong impression that after installing a lot of patches recently (incl. SP3 + additional patches for SP3) there is something fundamentally wrong in the way a proc.engine ends processing a mapping; e.g. the DATABASE CLOSE command does NOT close the DB connection anymore. I already submitted a supportcase to Axway Support for this.

[Rhenus ICT Servi...]

I found the cause of the excessive memory usage with this particular FILEIN -> ORACLESP mapping.

This mapping uses a dedicated HME/Proc.Engine/OracleSP Connector combination. In the advanced settings I had to raise the 'Maximum string size' to 4096, because this OracleSP Connector is also used by another mapping that feeds large texts into an OracleDB. Now when processing this 'big' file of 4.3 MB it uses this 4096 stringsize and starts to use lots of memory.

I now configured a new HME/Proc.Engine/OracleSP combo with the default stringsize of 256 for processing the 'big' file of 4.3MB. The memory usage is a lot smaller (around 90MB) and the processing appears to be a bit faster, although still not very fast.

After processing the data, the memory is still not returned to the system...

What exactly does this 'Maximum string size' setting mean? Is it the maximum size of 1 IN-parameter of the called OracleSP or the TOTAL of all IN-parameters of the called OracleSP ?

[ptwyhk]

P.S. I have the strong impression that after installing a lot of patches recently (incl. SP3 + additional patches for SP3) there is something fundamentally wrong in the way a proc.engine ends processing a mapping; e.g. the DATABASE CLOSE command does NOT close the DB connection anymore. I already submitted a supportcase to Axway Support for this.

I also have your impression. Regarding the DB connection, in my case, there are a memory leakage. Finally, we doesn't depend on Integrator DB connector and make a java program to handle the case.

[Rhenus ICT Servi...]

P.S. I have the strong impression that after installing a lot of patches recently (incl. SP3 + additional patches for SP3) there is something fundamentally wrong in the way a proc.engine ends processing a mapping; e.g. the DATABASE CLOSE command does NOT close the DB connection anymore. I already submitted a supportcase to Axway Support for this.

This problem has been 'solved' by using a WORKAROUND; Axway apparently implemented something called 'oci-session-pooling', which was 'falsely' enabled by default after installing a certain patch. To turn this feature off you must set the environment-variable 'EDI_ORACLE_OCI_SESSION_POOL_ENABLE' to '0' (e.g. EDI_ORACLE_OCI_SESSION_POOL_ENABLE=0). Now the 'DATABASE CLOSE' will work as before.

The memory is still not cleared after ending an OracleSP-mapping, but I already opened a new supportcase for this.

[Rhenus ICT Servi...]

I finally traced down the root-cause of the excessive memory-usage; we were still using version 9.2.0.1 of the Oracle Client. After a fresh install of Oracle Client version 9.2.0.4 the memory-usage is MUCH lower.

In one of the patches I installed, the file $CORE_ROOT/4edi/dbload/oracle92.db was updated and did not work very well anymore with version 9.2.0.1 of the Oracle Client.

The memory used by the OracleSP mapping is still not fully cleared after map-ending...

[Tony]

Thanks for continuing to fill us in on the information you're uncovering. I'm sure others are following it as well and it's great to have the chronicling of information so that we can see the steps taken, what worked, what didn't, and what eventually resolves things with issues like this! It's great to have such valuable contributors to the Axway Customer's body of knowledge!

I finally traced down the root-cause of the excessive memory-usage; we were still using version 9.2.0.1 of the Oracle Client. After a fresh install of Oracle Client version 9.2.0.4 the memory-usage is MUCH lower.

In one of the patches I installed, the file $CORE_ROOT/4edi/dbload/oracle92.db was updated and did not work very well anymore with version 9.2.0.1 of the Oracle Client.

The memory used by the OracleSP mapping is still not fully cleared after map-ending...