HTTPIO_PLG_CANCELED error

[Former Member]

Hello All,

I have a program that I am calling a web service to an outside 3rd party company.

I can run the program through 1 account - it works fine.

When I start running it for many accounts - it will randomly get the error HTTPIO_PLG_CANCELED.

I say randomly because sometimes it will go through 10,000 before it has an error.

Sometimes 5,000.

Sometimes as low as 300.

I cannot figure out any pattern to it.

I searched OSS and SDN.

We do have the note 1674357 (which described the error exatly) - but it is already installed in our machine.

I read other SDN messages that have this same error - but it appears it happens all of the time in those threads.

Not at seemingly random intervals like I am getting.

I was wondering if anyone else had the same problem and what they did to solve it.

Thanks for the help.

Scott Overmeyer

[Former Member]

Hi,

I might not be able to solve the issue, but have you considered scaling out to use some load balancing to relieve the pressure?

It's possible that the ICM is saturated.

You could also look to try and change the timeout for closing an inactive HTTP session or something.

Anything to try and reduce the number of connections hanging around.

Maybe it might provoke some thoughts...

[Former Member]

Hello Darryl,

Thanks for your response.

I checked with our basis people - and that had tried the things you listed.

They watched the ICM - and there are only a couple of connections.

Nothing anywhere near the limit on the connections.

The timeout for closing an inactive HTTP session - they bumped that up as well.

We are asking the 3rd party company the web service is calling to see what their parameters are - but we have not heard back from them yet.

What is odd about it is - if it was a connections problem or time out problem on either side - I would think the amount of calls I could make before it quicks would be roughly the same.  But it varies wildly.  From 10,000 one time to 300 the next. 

We know nothing else is running on the SAP side (we are doing this in our development box). 

It is a very strange problem to me.

Thanks again for the help.

Scott

[Former Member]

Hi Scott,

Are you able to monitor at the O/S level the number of TCP connections that are in state CLOSE_WAIT ?

It's possible that the O/S is not freeing up the TCP sockets fast enough.

Also, are you going out to the 3rd party via a proxy server, or something else that could be causing grief for you?

Regards,

Darryl

[Former Member]

Hello Darryl,

Our systems people looked at the O/S level today while the program is running - and they do not see anything in a CLOSE_WAIT state.

To your other question - this was their response:

We are not using any proxy server to call the 3^rd party Webservices. We are calling the 3^rd party Webservices directly from our ERP 6.0 EHP6.0(NW 7.31) system.

I really appreciate all of these ideas.

Hopefully we will eventually get it figured out.

Thanks.

Scott

[Former Member]

Hi Scott,

Thanks for the update.

You seem to be running a recent version of the ABAP stack.

There are a couple of areas that can affect the ICM, so I've got a couple of SAP notes that you need to check through.

I don't know your setup, current patch level (of the Kernel), the O/S, the third-party or any other details, so you'll have to excuse the generic-ness of the approach.

Note 715400 - Max. number of memory pipes (MPI) restricted to 4,000

Check the ICM trace file.  You may need to increase the trace level to 2 (beware that this creates a rather large file if you are running thousands of connections through the ICM).

Note 737625 - Parameter recommendations for the ICM

Check the parameters you have in your system.  The section on 7.20 parameter settings in the note should be observed for your Kernel (even if you're using 7.21_EXT).

[For some reason the "link" option stopped working here, so I can't add the actual link to the notes anymore.  Weird....]

Note 1921986 - Wrong value is used when the configured cache size exceeds 2047

There doesn't appear to be a fix for this yet...

Note 1815995 - ICM chunked encoding error with size larger than MPI

This looks interesting.  If your message sizes are slightly different.  Note the later patch release for the Kernel 7.21_EXT is required.

Note 1838490 - SYSTEM_CORE_DUMPED in HTTP

This also looks interesting.  You may only see this in the ICM logs with trace level 2.

Again, the solution is a Kernel upgrade to 7.21_EXT sp115.

Note 1834381 - HTTP plug-in sessions for sapsys are not closed

OK, this one could also be relevant.

Again, the solution is a Kernel upgrade to 7.21_EXT sp115.

Based on the above, I'm tempted to suggest a Kernel upgrade.

I don't know what you're on now, but it's more than likely you've done the right thing and applied 7.21_EXT as requested by SAP.

So, if you've done this, then just apply the latest Kernel for 7.21_EXT and retry the test case.

Looking through the bugs fixed in the latest disp+work kernel update zip, I can see that around sp115 a lot of ICM related niggles were fixed.

Also, you should note that the software component for the ICM is: BC-CST-IC.

In case you need to raise a message to SAP  .

If you get any juicy info from the ICM trace file, then paste it here.  It might help someone else.

Regards,

Darryl

[Former Member]

Hello Darryl,

Our systems people have been working the last few days to try all of these things.

They created a new system - upgraded the Kernel - etc.... and try it gain.

Unfortunately same problem.

We do have an OSS message that we have opened.

Thanks for all of the help and ideas.

Scott