cancel
Showing results for 
Search instead for 
Did you mean: 

JDBC Adapter: J2EE server crashes while sending large messages

Former Member
0 Kudos

We want to use the following scenario to transfer data from a MS SQL Server to SAP BW via XI:

JDBC Sender Adapter – XI – SAP ABAP Proxy.

All works fine with a small amount of data. But if the select statement delivers too many record sets and the size of the transformed XML payload is greater then 50 MB the J2EE server crashes. A complete restart is necessary. It seems to be am memory problem.

Here are the entries from our log files:

dev_server0

[Thr 6151] Mon Jul 24 12:46:57 2006

[Thr 6151] JLaunchIExitJava: exit hook is called (rc=666)

[Thr 6151] **********************************************************************

      • ERROR => The Java VM terminated with a non-zero exit code.

      • Please see SAP Note 940893 , section 'J2EE Engine exit codes'

      • for additional information and trouble shooting.

**********************************************************************

[Thr 6151] SigISetIgnoreAction : SIG_IGN for signal 17

[Thr 6151] JLaunchCloseProgram: good bye (exitcode=666)

std_server0.out

FATAL: Caught OutOfMemoryError! Node will exit with exit code 666java.lang.OutOfMemoryError

Is this a general problem of the XI or a specific one of our configuration? Is it possible to transfer such large messages via XI? If not, is there a workaround for such scenarios?

(Memory heap size of the J2EE server is 1024 MB.)

Accepted Solutions (1)

Accepted Solutions (1)

thomas_jork
Explorer
0 Kudos

Hi Gil

Have you checked the 'MAX_MESSAGE_TRANSFER_SIZE' in

RWB->Component Monitoring->Integration Engine->

Settings->Runtime?

I have the same problem with very large messages. But in

my case just the process falls into sleep when the

message exceeds this limit. No restart is necessary.

BTW 100MB is the upper maximum for the message size.

Regards

Thomas

Former Member
0 Kudos

> Hi Gil

>

> Have you checked the 'MAX_MESSAGE_TRANSFER_SIZE' in

> RWB->Component Monitoring->Integration Engine->

> Settings->Runtime?

> I have the same problem with very large messages. But

> in

> my case just the process falls into sleep when the

> message exceeds this limit. No restart is necessary.

> BTW 100MB is the upper maximum for the message size.

>

> Regards

> Thomas

Hi Thomas

This parameter was not set. I've tested this but nothing has changed. Same problem as before. However your post is very interesting. If 100 MB is really the max size of a message we have to do some changes at the data source. Unfortunately the development at the MS SQL Server is not in our hand.

Answers (6)

Answers (6)

Former Member
0 Kudos

Hello Ritter,

Hope this helps you.

Activate XBTL Queue in SXMB_ADM-->Configure filter for Queue Prioritization with Message SIZE.

Messages greater than this size would go to Large Queues.

XBTL--Inbound

XBTM--Outbound for Large Messages.

There is a way to defer large messages from the rest and process them using a job in a specific queue.

Please check this configuration :

http://help.sap.com/saphelp_nw2004s/helpdata/en/14/80243b4a66ae0ce10000000a11402f/frameset.htmMessag... Selection Filter

in this path:

Under Runtime - > Integration engin ->

Prioritized Message Processing

Queues for Prioritized Message

With Regards,

Raju

Former Member
0 Kudos

Hello,

We have the same problem. No workaround found. We need to send 250 MB messages.

usign unix split before xi, and concatenate after xi of course solves the problem but that is a workaround.

Former Member
0 Kudos

Hi

I am having similar problem as out of memory error.

This is very serious because I am not able to start all Java services again. I can't use XI system now. Are there any settings required to start J2EE engine?

Appreciate help

Former Member
0 Kudos

Hi Gil,

look at sap note 759669

I. If you are running SP9 or higher of the J2EE Engine 6.40

proceed as follows:

1. Start the configtool in <J2EE_HOME>/configtool directory

2. Browse the tree in the left pane

cluster-data -> Global server configuration -> services -> classpath_resolver

3. In the right pane click on the key javac.Xmx

4. In the Value edit field on the bottom insert 256

5. press the Set button in the upper right corner

6. choose from the Menu File->Apply and confirm all windows popping up

7. restart the J2EE instance

8. restart the deployment process

cheers,

Prashanth

P.S: Please mark all helpful answers

Former Member
0 Kudos

Hi Prashanth

I checked the note you mentioned but I have no problem with the SDM tool. Anyway I have change my setting from 256 to the 512 MB as recommended but nothing has changed. I've still the same problem.

And I've marked the helpful answer already.

venkatesh_r
Employee
Employee
0 Kudos

Hi Gil,

We have faced a similar problem in our landscape on UNIX Systems. After days of analysis we found that the swap memory was not enough at the OS level which led to the crashing of J2EE Server.

Regards,

Venkatesh

former_member187587
Contributor
0 Kudos

Hi Gil,

This does sounds like a memory problem especially when it comes to 50M message with a minimum XI sys requierments...

To be sure you can check on the RWB for the componnent monitoring at the JDBC adapters and look for your adapter

look at the status of the adapter and the trace there...

My reccomendation to you is to set the poll intervall to a shorter period,this way you'll make sure you get less records...I hope you have remembered to add a status/flag column on the table to be set after selection so no duplicate records will be taken on the second pools.

And offcourse....if its for sure a memory problem ,add some more Megs to the host.

Good luck

Nimrod Gisis

Former Member
0 Kudos

> Hi Gil,

>

> i had nearly the same problems some times in praxis

> and the mapping was the reason. Just change your

> interface determination temporary, delete the mapping

> and test again to find out if the mapping is the

> reason.

>

> Regards,

> Udo

I have changed my interface determination so that no message mapping is used. The J2EE server still crashes.

> Hi Gil,

> This does sounds like a memory problem especially

> when it comes to 50M message with a minimum XI sys

> requierments...

> To be sure you can check on the RWB for the

> componnent monitoring at the JDBC adapters and look

> for your adapter

> look at the status of the adapter and the trace

> there...

Hi Nimrod

In case of such an error I have no entries in channel monitor. So I can't see anything there. I have also no entries in message monitor of the RWB in this case. So I don't get any information with standard XI tools.

> My reccomendation to you is to set the poll intervall

> to a shorter period,this way you'll make sure you get

> less records...I hope you have remembered to add a

> status/flag column on the table to be set after

> selection so no duplicate records will be taken on

> the second pools.

>

The problem is that the source of my data is not a simple SQL statement but a stored procedure. So I don't know exactly how many records will be delivered. A update command is not possible.

udo_martens
Active Contributor
0 Kudos

Hi Gil,

assumedly the mapping is the reason for the crash. May be you can write a more perfomant program or better, just avoid using a mapping and transfer the JDBC output structure to the ABAP inbound proxy, where you implement the task of mapping.

Regards,

Udo

Former Member
0 Kudos

Hi Udo,

I have no entry for such a message in ABAP message monitoring (SXMB_MONI). Message mapping is only fifth step in message processing of the central xi pipeline. Receiver determination, interface determination and so on are the steps before but I can't see them. So in my mind the message doesn't reach the central pipeline. The AF and the J2EE server respectively crashes before delivering the message. So I don't believe message mapping is the reason.

udo_martens
Active Contributor
0 Kudos

Hi Gil,

i had nearly the same problems some times in praxis and the mapping was the reason. Just change your interface determination temporary, delete the mapping and test again to find out if the mapping is the reason.

Regards,

Udo

Former Member
0 Kudos

Hi ,

just check thread ...this may help you...

sekhar