Skip to Content
Author's profile photo Robert Warde

Single Sender Comms Channel with multiple receivers – the problems

We have a synchronous ICO scenario running on SAp PI 7.11 EHP1 EP6. A single SOAP sender adapter and 3 RFC receiver adapters. Routing is performed based upon the document payloads.

23-07-2013 4-48-14-PM.jpg

An R/3 system was running very slowly.In this scenario I would expect problems with users of one receiver but not all receivers as their R/3 systems were operating normally. Messages started to queue on the receiver because of the slow response. The interface utilises an ICO (Integrated Configuration Object) and the thread used by the sender adapter is retained until a response is returned. The SOAP comms channel used all available threads on all nodes. This resulted all inbound calls timing out

The following screen shot from Wily for the period in question and shows that the thread limit was reached on several occasions. This would indicate that timeouts were intermittent rather than continuous. Therefore, performance of the receiver system must have improved from time to time OR there were fewer requests being submitted.

23-07-2013 4-48-55-PM.jpg

Normal thread activity is as follows:

23-07-2013 4-49-21-PM.jpg

I checked the following notes to ensure that we don’t block all interfaces for a specific adapter type.

Note 1493502 – Max Receiver Parameter for Integrated Configurations

Note 1136790 – Blocking receiver channel may affect the whole adapter type

Note 1557036 – Integrated Configuration Objects (ICO) scenarios use Messaging System Sender Queues only

Although these parameters have been set they only apply to receiver adapters and not sender adapters. In our scenario if each receiver channel is limited to two threads per node and we have three receivers then it would still be possible for the sender channel to attempt to consume more than the 5 threads per node thus causing timeouts.

23-07-2013 4-50-08-PM.jpg

Reference should be made to the document, ‘Analyzing Performance, Problems and Possible Solution Strategies. V2.0 ’ Section 6.4.2 ‘Only one thread is used to process the message and will not be available to other messages during the execution. ‘Section 6.2 ‘A bottleneck can usually be closely connected with a performance problem with the receiving system.’ Note 1593920 ‘For synchronous SOAP calls, the transmitter thread blocks until all the processing completes and returns a reply or the timeout value is reached’

I have created customer message and asked SAP to investigate why there is no control over the threads consumed by the sender channel. My concern, as I stated earlier, is not that this particular scenario will fail, we already know that will happen, but that all the threads for a particular adapter type; in this case the soap adapter could be consumed.


a) Ensure that individual sender communications channels cannot consume all the available threads for a particular adapter type. Awaiting feedback from SAP.

b) Individual scenarios with more than one receiver should have more than one sender adapter. This will ensure that any performance issues on a single receiver only impact the users of that receiver rather than all users.

23-07-2013 4-50-56-PM.jpg

Any comments?

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Alejandro Maldonado
      Alejandro Maldonado

      Hi Robert,

      I think that the restriction of number of threads could be related to Stagging and Logging configuration. Please take a look at SAP  Note 1760915 - FAQ: Staging and Logging in PI 7.3 and higher. Go to question Q11 --> A11.2

      Please let me know.


      Author's profile photo Robert Warde
      Robert Warde
      Blog Post Author

      I probably should have mentioned we are running 7.11 EHP1 SP6 and not 7.3x


      Rob Warde