Messages getting stuck in Delivering status in AE

[Former Member]

Hi all,

Recently we are coming across messages that go into Delivering status. These messages mostly belong to File Sender/Receiver Adapter but not confined to them. Here is the audit log of one such message:

2011-03-21 10:01:55 Success Write to file "/usr/sap/ZX2/EXT/XI_INTERFACES/SCP2PIF016/NOT_PROCESSED/goodsReceiptPosting_InvalidRecords20110321-100155-650.xml" as binary, size 1949 bytes

2011-03-21 10:01:55 Success File processing complete

2011-03-21 10:01:55 Success MP: Leaving module processor

2011-03-21 10:01:55 Success The message was successfully delivered to the application using connection File_http://sap.com/xi/XI/System.

2011-03-21 10:01:55 Error Setting the message status to DLNG failed, due to: com.sap.aii.af.ra.ms.api.DeliveryException: Error updating status..

On searching in SDN I found one work around-- to restart Messaging Service in Visual Admin. This did work as the messages got processed after that. But, the problem seems to be recurring now(once in every two days).

Can any body shed some light on this to find the permanent fix?

Thanks a lot,

Gokul.

[former_member4985]

Hi,

Make sure you have set the MaxThreadCount parameter to 350 or higher depending of the case and of the resources available.

To increase the parameter, please follow the instructions below:

1. In the left frame choose Server -> Kernel -> ApplicationThreadManager

2. In the tab Display Configuration (right frame) choose Switch between view and edit mode to activate the edit mode.

3. The parameter MaxThreadCount must be set to 350.

4. You will then need to restart the J2ee

For reference see note #937159 - XI Adapter Engine is stuck

For specific setting to an adapter can be done by going to the Visual Administrator -> Services -> SAP XI AF Messaging

Look at the property 'Messaging connections' here you will see the following queues:

Send.maxConsumers (asynchronous sending - outbound)

Recv.maxConsumers (asynchronous receipt - inbound)

Call.maxConsumers (synchronous sending - outbound)

Rqst.maxConsumers (synchronous receipt - inbound)

Depending on where the bottleneck is occurring (i.e. too many entries in the Send.maxConsumers) you can increase these parameters.

Example of parameter value syntax (sample for FILE adapter):

(name=FILE_http://sap.com/xi/XI/System, Send.maxConsumers=10, Recv.maxConsumers=10, Call.maxConsumers=10, Rqst.maxConsumers=10)

For reference see note:

#791655 - Documentation of the XI Messaging System Service Properties

And see the link:

/people/kenny.scott/blog/2007/08/20/messaging-system-queue-properties-after-xi-30-sp19-xi-70sp11

Regards,

Caio Cagnani

[Former Member]

The maxThreadcount is 500 in our case. Also the

Send.maxConsumers--5

Recv.maxConsumers --5

Call.maxConsumers --10

Rqst.maxConsumers --10

Would the imbalance in the synchronous and asynchronous message handling threads affect the performance. all the mentioned interface which went into delivering did belong to only asynchronous scenario.

[Former Member]

I would try increasing the Send.maxConsumers and Recv.maxConsumers and let you know the outcome.

@Cagnani: Thanks for the info...

[former_member4985]

Hi Gokul,

Actually you can increase all the 4 properties to "15", as you have the MaxThreadCount

parameter as "500" (which is a high value).

This will ensure sufficient Worker threads to process the messages for the related scenario,

which, in this case, would be the FILE one.

Regards,

Caio Cagnani

[Former Member]

Hi,

Please check in the Queues smq1 and smq2.If u have any messages in the queue,restart the messages.

Thanks

Ravi

[Former Member]

I forgot to mention one thing. It is interesting to note that there are some messages that got processed successfully around the same time,for the same interface through File adapter which was delivered successfully.

[Former Member]

if your receiver cc have write mode in "Use Temporary File", see that note:

Note 1283325 - Receiver file adapter thread hanging

In a cluster node this issue could stop the process of messages in one of the servers and the other/s server/s could process successfully at the same time.

Regards,

CArme