Message Stuck in To Be Delivered Status(EOIO)

[rasjoshi]

Hi All,

we have 3 messages stuck in to be delivered status. All three are in 3 different server nodes. As 3 messages are in 3 different nodes we dont want to restart these server nodes.... We have SAP PI7.31 single stack...

I tried with resatrting communication channel... But still messages are in to be delivered status...

Threads are also not completely occupied.

What is the best possible ans you can suggest here?

Regards,

Rashmi Joshi

[rasjoshi]

Thank you all for your help... I could not find any specific reason for this error... Why the messages got locked in AE.... Finally we had only option to restart java nodes.

Thanks & Regards,

Rashmi Joshi

[Former Member]

Hi Rashmi,

In messages that are in "To be Delivered" status, try to find out the EOIO queue name. Then use the EOIO queue name to filter for error messages residing in the queue.

In case if there are any error messages, clear those messages based on the sequence.

Regards

Ram

[rasjoshi]

Hi Rama.. Thanks for you reply.. PLease find my comments below -

One more thing... These 3 messages are stuck in To Be delivered status for 10th June.. For the same interface I can see messages processed successfully for the same interface.. How can this be possible?? This is EOIO scenario.... Any idea?

[Former Member]

Hi Rashmi,

This is due to the package size set per queue. Remaining messages must have got processed through different queue.

As far as your messages in "To be delivered state" is concerned, please show me the audit log from RWB where we will be able to get a trace of the error status.

Regards,

Souvik

[rasjoshi]

Hi Souvik,

PFA screen shot -

[former_member208396]

Hi Rashmi,

As per the screenshot, The original message had already been transferred to target system since it shows "DiplicateMessageException" and since it is EOIO then same message can't be transferred to target again. Please check with your target team by providing them the payload & time stamp, they must have got the messages before.

P.S: As of now nothing is stuck in your end-to-end scenario.

Regards,

Vishnu

[Former Member]

Hi Rashmi,

The message which is fetched from SQL database via JDBC connector has turned out to be duplicate one, so since they are duplicate ones, therefore, these messages have been previously supplied to the target system. The target system might not be accepting duplicates.

So, you can simply cancel these messages as these have already got posted. However, as a cross-check you can check the file with the target system owner whether they have received this message or not and then cancel the same message.

Regards,

Souvik

[rasjoshi]

Hi Vishnu.

I checked in SXMB_MONI of taget system... I do not see this message.

😕

Regards,

Rashmi Joshi

[Former Member]

Rashmi,

Is this single stack ? then you won't find the message in SXMB_MONI t-code. Instead, please check in in Adapter Engine under Database with the interface namespace and with date range previous to that of error ones.

Hope this works...

Regards,

Souvik

[former_member208396]

Hi Rashmi,

May be these messages had been transferred to target system before few weeks and due to some archival mechanism you are not able to see successful messages in target system.

If the target system in ECC then you can compare the files in AL11 location of target system with the files in outgoing payload of PI 7.3 system. They should match.

Also one more thing you can do is you can replicate the same scenario in Qa environment. Once the messages is successful from end to end then yo can try to send same files again in Qa. I am sure you will get above error only which will proof that we are on correct path.

Please have a look.

Regards,

Vishnu Srivastava

[former_member208396]

Hi Rashim,

What is the QOS of your scenario, is it EOIO?. Which adapter you are using to do end to end connectivity?

Regards,

Vishnu Srivastava

[rasjoshi]

yes its EOIO... Its Proxy to Proxy...

[former_member208396]

Ok then in that case please check for earlier messages[way from last 3-4 months]. One message must be stuck, just cancel that one and try to process other messages once again.

Regards,

Vishnu Srivastava

[pvishnuvardan_reddy]

Hi Rashmi,

If QOS is EOIO, can you look in to below blog written by stefan:

/people/stefan.grube/blog/2006/04/27/how-to-deal-with-stuck-eoio-messages-in-the-xi-30-adapter-framework

Regards

Vishnu

[rasjoshi]

HI Vishnu... I already checked it... No messages in pending since last 1 year...

[former_member208396]

Ok, Have you check both IE & AE?

[pvishnuvardan_reddy]

Hi Rashmi,

Can you try Restart sequence option for the first message, so that it would ask you to cancel the predecessor message which was there in the queue to cancel.

By this way, the predecessor message gets canceled(if you select cancel), which makes the successor messages to start processing.

Regards

Vishnu

[rasjoshi]

Its a single stack.. Yes I checked in AE

[rasjoshi]

But this is production environment.. I cant better loss of any message

[rasjoshi]

Plus I can not see this option also...

[pvishnuvardan_reddy]

Hi Rashmi,

AFAIK, some blockage might be there for this interface in the queue which causing this issue.

You can try for java restart to clear these backlog messages.

Please check the below blog for any more information:

Regards

Vishnu

[rasjoshi]

Yes we can try the option to restart java stack.. But we dont want to do that for sake of 3 messages

[rasjoshi]

One more thing... These 3 messages are stuck in To Be delivered status for 10th June.. For the same interface I can see messages processed successfully for the same interface.. How can this be possible?? This is EOIO scenario.... Any idea?

[pvishnuvardan_reddy]

Rashmi,

Yes, I agree that in a EOIO, if there is a blockage then the successor messages should go to either holding/Waiting state.

But we could see the messages remains in to be delivered state due to some unknown reasons. Normally we see these type of issues in file/jdbc scenarios.

Normally when this message system tried to deliver these messages to the receiver system, either there might be some issue with the receiver system at that time or due to the non-availability of thread in the pool.

In your case, its weird that it happened in a soap adapter..

Regards

Vishnu

[rasjoshi]

Yes and new messages are getting processed also... Any idea what should I do?

[Former Member]

Hi,

You can check the relevant answer to your ques. in one of my replies to your comment.

BTW, if you say that the scenario is proxy to proxy, how is it possible for you to set the QoS as EOIO ???

In my opinion it is not possible. Hence this could be a reason why remaining messages are getting processed.

[rasjoshi]

Yes Souvik,

This is proxy to proxy for standard PO.... I can see messages stuck in queue DisplayDisc queue of Adapter Engine. It shows number of threads 1 and message in process also 1..

Any idea how to process this stuck message now?

[Former Member]

Hi,

Can you share with me the Audit log for the messages, so that I can analyze why they are stuck ?

Regards,

Souvik