Some messages are stuck in adapter engine with To Be Delivered status

[markbernabe]

Hi Experts,

I have a proxy-file scenario. The problem is that not all files are getting sent to the file directory and it's intermittent. Some messages are successful while some are getting stuck with To be Delivered status. The audit logs for the stuck messages only say that the message is successfully put into the queue. Any idea on this problem?

[Former Member · Accepted solution]

Hi Mark

If the messages lying in ToBeDelivered status for a long time , then the only possible solution to clear them will be make a java restart.

Normally messages goes to adapter engine and then stay inside queue 'DispatchDisp' . If you check that queue you will see that its depth is not 0 some messages will be there already.

You can check the queue as

RWB-> Adapter Engine-> Adapter engine status->Additional Data-> queue name

[markbernabe · Accepted solution]

Hi Indrajit,

Thanks for this. I found a lot of entries in DispatchDisp. Is there a guide on how to perform Java restart?

[markangelo_dihiansan · Accepted solution]

Hello Mark,

You can perform a restart by going to SMICM -> AS Java -> (Select Local or Global) -> Restart.

Also, please consult SAP Note 1623356 - "To be delivered" messages in the Adapter Engine.

Hope this helps,

Mark

[markbernabe]

Hi Everyone,

The Basis has finally cooperated and restarted the whole PI instance and reset all queues. After that, the interface started to work again. Stuck messages and other backlogs are getting processed as well. Thanks again for all your insights! They're very helpful.

Mark

[markbernabe]

Hi Mark, Abhi,

Thanks for the info. I'm not authorized to execute SMICM so I guess I have no choice but to ask Basis . I have mentioned note 1623356 to them, but they insisted that it's a misconfiguration in the channel that I created. I don't even know if threads can ever be configured in the channel.

Btw, it also happens (stuck messages) for other file interface.

[markangelo_dihiansan]

Hello Mark,

In that note it states that the max thread count parameter should be greater than 350 (depends on the resource). In the receiver communication channel, try increasing the Maximum Concurrency (5 would be okay), but ultimately this still depends on how it is configured in the config tool.

Here is the excerpt from the note 1623356:

Reproducing the Issue
Go to Runtime Workbench (http://<host>:<port>/rwb)
In Message Monitoring, display messages for the Adapter Engine side
Filter the messages according to your needs (last hours, today, week, …)
Observe that you have messages with hanging status, such as “To be delivered”
Another way to check it is by going to the same Runtime Workbench -> Component Monitoring -> click on Adapter Engine -> Engine Status.
There, click on the "Additional Data" tab and look for the specific adapter related to the scenario.
You’ll see that for the “Maximum Number Of Threads”, it’s using all the assigned threads, as per the “Threads Assigned/Working” information.
Cause
Insufficient number of resources (threads) to process the current demand of messages
Resolution
First, make sure you have set the MaxThreadCount parameter to 350 or higher depending on the case and of the resources available.
To increase the parameter, follow the instructions below:
In the left frame choose Server -> Kernel -> ApplicationThreadManager
In the tab Display Configuration (right frame) choose Switch between view and edit mode to activate the edit mode
The parameter MaxThreadCount must be set to 350
You will then need to restart the J2ee. For reference, see SAP note 937159 - XI Adapter Engine is stuck
For specific setting to an adapter can be done by going to:
For 3.0 and 7.0x releases: Visual Administrator -> Services -> SAP XI AF Messaging -> "messaging.connections" property
For 7.1x releases change it by using the ConfigTool ->  service 'com.sap.aii.af.svc' -> "messaging.connectionDefinition" property (for ISPeak  adapters it is in service 'com.sap.aii.af.ms.svc') 

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 (e.g. 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)

Hope this helps,

Mark

[Former Member]

Hi Mark,

Before restaring please do this check:-

• Is this issue is happening for only one particular interface or all interface.Already Anupam Ghosh had explained this.
• Take all neccessary approval before restarting java stack.Better approach inform your customer that you are taking downtime and once java stack is started,you can process all the stuck messages.

Basis team is right group,they are responsible to do the stop and restart of any stack.You can ask them to restart the stack also.

If you have authorisation to check the sap notes,please check below notes otherwise basis team will definetly have sap notes acccess.You can check with them also.

https://service.sap.com/sap/support/notes/870864

Regards,

Abhi

[santosh_k3]

Hi Mark,

Also check if there are any error messgaes which got stuck earlier , check with specific period of time

resolve the error messages or cancel  those messages and then resend the messages which have To be Delivered status.

Regards

Sai

[markbernabe]

Hi Sai,

QoS is EO. It should not get stuck when there are error messages right? Anyway, I've checked and there are no other messages with different status. Only To Be Delivered.

[anupam_ghosh2]

Hi Mark,

                  Is this problem for only one scenario or other scenarios are also affected? If this is only for this scenario then please check the mapping involved, sometimes it might take a longer time to execute. If this is affecting multiple scenarios there might be issues with PI server, need to consult the Operating system team and BASIS team.

Regards

Anupam