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.
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.
Normal thread activity is as follows:
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.
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.