PI 7.1 Messages stuck into the Queue of the Adapter Engine

[Former Member]

Hi Gurus,

we run SAP PI 7.1. We have the problem that 6115 Entrys stuck into the Queue of the Adapter Engine.

We find the situation in -> mdt/Systatus -> Engine Status -> Queue Information -> DispatchDisp

How can we bring them to run?

Does anybody have a idea?

Best regards,

Sven

[kenny_scott · Accepted solution]

Hi Sven,

I would require more information in oder to provide advice, e.g., are the stuck messages EOIO?

The PI Troubleshooting Guide has extensive help on unblocking AE queues

[#1060264 PI Troubleshooting Guide 7.1 |http://service.sap.com/sap/support/notes/1060264]

Regards

Kenny

[Former Member · Accepted solution]

Hi Kenny,

no, the Message are from the QoS "EO".

You can find them under:

Runtime Workbench -> Component Monitoring -> select the Adapter

Engine -> Button 'Engine-status' -> Tab 'Additional datau2019 -> Queues -> DispatchDisp

They have the status "To be delivered"

[kenny_scott · Accepted solution]

Hi Sven,

the following blogs may help :

[XI/PI File and JDBC Receiver Adapter performance and availability improvements|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12338] [original link is broken] [original link is broken] [original link is broken];

[Messaging System queue properties after XI 3.0 SP19 / XI 7.0SP11|https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/7141] [original link is broken] [original link is broken] [original link is broken];

Regards

Kenny

[Former Member · Accepted solution]

Hi Sven,

did you try to find out why they are stuck there? Probably they run into some kind of error. Did you analyze the details of those messages in the Message Monitoring of the RWB? All EO messages are restartable in the RWB, so once the error is resolved, this would be the easiest way to clear your queues. If this doesn't help you can still just cancel the messages.

Regards,

Jörg

[Former Member · Accepted solution]

Hi Jörg,

heute vormittag habe ich mit einem Kollegen genau das gemacht! Über die Message ID habe ich mir das Audit Protokoll angesehen und festgestellt das der Tablespace der Zielapplikation voll ist!

Das ärgerliche ist nur, das ich in dem betroffenen KK einen Retry von 3 Versuchen eingestellt habe, der KK aber seit zwei Tagen versucht die Nachrichten zu übertragen. Aufgrund dessen wird der Status nicht auf "Systemfehler" gesetzt und der KK bleibt im Status "grün"! Normalerweise würde er nach drei fehlerhaften Fehlern auf "rot" gehen und mir genau den Fehler werfen.

Wahrscheinlich ein Bug. Ich werde dazu eine OSS Meldung bei der SAP aufmachen. Trotzdem danke für die Hilfe oder hast Du eine Idee was das Problem mit dem Retry des KK sein könnte?

Grüße,

Sven

[Former Member · Accepted solution]

Hi Sven,

I think communication language here should be English so that all others having the same problem may benefit, even if both of us speak German.

If it's a queue issue you need to find the first message in the queue. Did you filter the messages in the RWB for messages in error status? Maybe you find the first message in error status and can restart this manually.

By "KK" you mean Communication Channel? Usually the number of retries is not configured there, but as a general parameter in the Visual Admin (or now NWA). The status of the communication channel doesn't mean anything, it's the messages that count. What status do they have? If they're on "Hold" (or something similar) then it's a queue issue and you should find the first messages of those queues in error status. You can always restart them manually, no matter how many retries you scheduled (I think, max is 999 retries).

Hope that helps you a bit.

Regards,

Jörg

Edited by: Joerg Thiesmann on Mar 27, 2009 12:13 PM

[Former Member · Accepted solution]

Hi Jörg,

allright; english rules!

Since SAP PI 7.1 you have the opportunity in the RWB -> Communication Channel Monitoring -> Settings (specific selected channel) to adjust the max. retrys to deliver a message.

Best regards,

Sven

[Former Member · Accepted solution]

Today I faced with similar problem, ~800 messages in backlog (DispatchDisp uhu). The reason was very painful -- deadlocks at receiver's side (JDBC receiver, oracle DBMS). It is very unexpected surprise for me that external system acting as asynchronous receiver without any EOIO can DDOS whole JDBC connectivity for many other JDBC receivers which don't have any deadlocks.

[Former Member · Accepted solution]

Hi Sven, (nice name by the way)

you should ask your basis team, wether a restart job for all messages exist, which are "to be delivered". The configuration in the CC is only used directly after the message failed. A retry job will start all failed messages again and process those as often as the setting is set to (Retries = 3 and 5 minutes tiem between).

If the reason for the delivery failure is clear, you should enlarge the table space if possible. Afterwards, all you have to do is wait, because all messages should be processed in time.

If you can't enlarge the table space it might be necessary to manually stop all stuck messages in message monitoring. This migth be quite a job to do with >1500 messages. The sending application has to resend all the data that would be lost this way.

Best Regards

Sven

[JoelTrinidade]

Hi Sven,

How to Analyze Stopped Queues in XI ccBPM

/people/henrike.kaiser/blog/2009/02/03/how-to-analyze-stopped-queues-in-xi-ccbpm

XI Asynchronous Message Processing: Understanding XI Queues -Part I

/people/sap.india5/blog/2006/01/03/xi-asynchronous-message-processing-understanding-xi-queues-part-i

Go to SMQ1 and SMQ2 and delete if there are any jobs in the queue.

Regards

joel

Edited by: joel trinidade on Mar 26, 2009 1:49 PM

[Former Member]

Hi Joel,

it's not a problem which you can see on the ABAP Stack! It's only visible in the mdt, like i wrote!