Error while receiving by HTTP (error code: 110 , error text: HTTPIO_PLG_CANCELED)

[former_member223432]

Hi Guys,

I am working on PROXY-->File scenario...the message is succesfully sent from ECC side(proxy) and it is failing at the PI side with given error.

<SAP:Code area="INTERNAL">CLIENT_RECEIVE_FAILED</SAP:Code> 

<SAP:P1>110</SAP:P1>

<SAP:P2>HTTPIO_PLG_CANCELED</SAP:P2>

<SAP:P3 />

<SAP:P4 />

<SAP:AdditionalText />

<SAP:Stack>Error while receiving by HTTP (error code: 110 , error text: HTTPIO_PLG_CANCELED)</SAP:Stack>

<SAP:Retry>A</SAP:Retry>

I I have looked into many threads on the similar error and tried all the options but no luck. the above interface messages are getting stuck in SMQ2 and blocking the other messages procesing..i have checked the following.

11. RFC connection(H type): Active and working fine(all other proxy interfaces are working fine except this one)

  2. HTTP service is active in ICM

  3. nothing is locked in SM12.

The other thing is, i am unable to open the payload, but the  XML size  is not too big(88MB)..earlier, it was working fine.

Can someone please help me in resolving this issue.

regards

I

[former_member223432]

Hi guys,

Here are my observation in PI.

No errors i  ICM trace monitor.

the value what we have  in icm/HTTP/max_request_size_KB = 2097152.

And also, i see the the messages were retryed 20 times in MONI.

and

In transaction SMICM->Services, i have

Keep Alive =90 seconds

Processing Timeout =  600 seconds.

Is there anything else i need to change in this values?

thanks

[markangelo_dihiansan]

Hello,

Can you increase your keep alive to 300? If this does not work, try in increments of 100 until you reach 600.

Hope this helps,

Mark

[Former Member]

Hi!

In my opinion, Keep Alive wouldn't aid much here, since this parameter relates to keep the connection open even without any data transferred / for XX seconds until connection is back.

However, please increase the PROCTIMEOUT parameter. Increase it on SMICM and on RZ11 increase the Maximum Runtime for Work Process to the same amount of time. Try setting both to 1200 seconds.

BR,

Lucas Santos

[former_member223432]

Hi Mark,

I did go through the doc..but no luck.,

any valuable suggestion please

[iaki_vila]

Hi Smith,

I think you should eliminate problem possiblities. At first i will try to send a short XML, if this works you will have a performance problem, if it's fail you will have a configuration problem.

Regards.

[Former Member]

Also check if the instance profile setting on PI I've suggested here might be relevant for you:

http://scn.sap.com/thread/3238888

Although by default it's set to larger than 88 mb maybe someone changed it hence it was working earlier?

Regards, Trevor

[Former Member]

Hi,

Have you checked the ICM logs. If not please have a look a them and see if you find any relevant error messages. If yes, just try to restart the ICM. As immediate response you will see your queues in smq2 going down.

Regards,

Toni

[markangelo_dihiansan]

Hello,

It looks like a performance issue to me. Have you tried sending a payload in increments of 5mb e.g start with 5, then 10 and see when would your system stop the processing?

If you are on PI 7.11 or higher and your ABAP AS is 7.00 or higher, you can use Integrated Configuration to help your message processing.

Generally, the solution would be to split your payload into multiple messages of smaller sizes on the sender side.

Hope this helps,

Mark

[former_member223432]

Hi Mark,

Thanks for your reply.

if it is an issue due to size..then it should fail at the ECC side(proxy) right?

and as i mentiined before, there are many succesful messages witht the same size before...

any other suggestion please?

[markangelo_dihiansan]

Hello,

if it is an issue due to size..then it should fail at the ECC side(proxy) right?

Not necessarily Your PI system could still receive the message and then it would fail on the receiver.

Although your scenario is async, please try to see this how to guide and see if it helps:

http://scn.sap.com/docs/DOC-16238    

Go to page 21. XI log showing HTTP Code 110

Hope this helps,

Mark