Skip to Content
avatar image
Former Member

XI freezes

Dear experts,

we have a customer where our 'dress rehearshal' for go-live failed 3 times.

<b>Scenario</b>

1. IDocs are sent (for outbound deliveries) from backend to a BPM.

2. The BPM works as follows: synch call to an HTTP receiver. Depending on the reply:

a. If OK, process is completed

b. In case of application error an alert is thrown and a wait step starts. The BPM allows for a max 3 such 'retries', if 3 is reached then the process is terminated with error.

c. In case of unknown return code a termination occurs (no retries).

<b>Symptom</b>

No problems occured during our tests. However during the dress rehearshal (about 2000 Idocs fired within 30 minutes from the backend) after some minutes of normal operation the following happened:

1. Messages from SAP backend get stuck in status 'to be delivered' and remain there for days

2. The business process (SAP workflow) timeouts last hours rather than the prescribed 1 minute (we had this for testing, normally should be half a day)

3. It was impossible to launch the integration builder html pages. Java seemed totally 'down'.

4. Occasionally, we could not even log on to the ABAP stack.

5. The logs show an unreasobaly high number of 'rollbacks' being executed.

5. Despite all this:

• that the CPU works at very small percentage !!!

• No storage problem is detected...

<b>Actions taken</b>

WE could not remedy the situationm even after several restarts of XI. We managed to get it again running properly after restarting the <i>server</i>.

We then tried some parameter tuning (including dialog processes and queues) but again after some hours of being happy the same happened.

Our machine is a 4 CPU with 16 GB, should be OK for this.

IDEAS ARE WELCOME...

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Oct 31, 2006 at 04:47 PM

    Hi,

    I am sharing my thoughts.

    1 ) Might be due to couple of interfaces using BPM in Synchronous, More the BPM the system performance will be slow and more over you are using the calls in Synchronous, Hence it will occupy more memory and wait for the response. assume at particular time couple of interface are waiting for response from the other side... Obviously it will make the system Freeze.

    2) Status: TO_BE_DELIVERED

    Which means that the message was successfully delivered from Integration Server point of view and it states that the messages is initially handed over to the Messaging System.

    TO_BE_DELIVERED occurs while the message is put into the Messaging System receive queue.

    Solution:

    This is done via the Messaging System receive servlet:

    http://<Host>:<PORT>/MessagingSystem/receive/<CONNECTION>

    /<PROTOCOL>

    Only if this was executed successfully the Messaging System returns HTTP 200 to the Integration Server and the Status TO_BE_DELIVERED moves to DELIVERING

    1. Try logging into Sap GUI with two users: XIAPPLUSER & XIAFUSER

    to see if they are blocked

    2. We can check the messages:

    AdapterFramework

    com.sap.aii.adapterframework.serviceuser.language

    com.sap.aii.adapterframework.serviceuser.name = XIAFUSER

    com.sap.aii.adapterframework.serviceuser.pwd

    ApplicationSystem

    com.sap.aii.applicationsystem.serviceuser.language

    com.sap.aii.applicationsystem.serviceuser.name = XIAPPLUSER

    com.sap.aii.applicationsystem.serviceuser.pwd

    in the exchange profile to make sure the right passwords

    Regards

    Agasthuri Doss

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Oct 31, 2006 at 06:11 PM
    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Nov 08, 2006 at 11:27 AM

    Tanks for the input. After some tuning we have now two (maybe dependent) problems when we issue many messages (1000 as order of magnitude) within a small time interval.

    [1] Our synch HTTP call has TIMEOUT problems - this is understandable but nevertheless annoying.

    [2] We also have an 'internal' problem for which I have not found any notes: if we issue many messages and a high percentage of them has application errors then we have our BPM with the wait step performing <b>very badly</b>. Specifically, the retries do not occur every 1 minute as the BPM is designed because the deadline monitoring job SWWDHEX manages to restart only 15-20 messages at the time - one would hope that it should start all the 'waiting' tasks. To process 1000 messages with 3 retries each at this speed means 1 day runtime!!!

    Add comment
    10|10000 characters needed characters exceeded