RFC Client Exception

[Former Member]

Hi All ,

Have encounter an issue , wherein  sender is SOAP and receiver is RFC .

Its like two interfaces using the same RFC receiver channel and both the interfaces failed and says :

Error messages says  :

For 1st interface : 

Error Delivering the message to the application using connection RFC_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.MessageExpiredException: Sync application request expired.. Setting message to status failed

For 2nd interface : 

Error Delivering the message to the application using connection RFC_http://sap.com/xi/XI/System failed, due to:

com.sap.engine.interfaces.messaging.api.exception.MessagingException: com.sap.aii.adapter.rfc.afcommunication.RfcAFWException: error while processing message to remote system:com.sap.aii.adapter.rfc.core.client.RfcClientException: resource error: could not get a client from JCO.Pool: com.sap.mw.jco.JCO$Exception:(106) JCO_ERROR_RESOURCE: Connection pool RfcClient[CC_XXXXXXX]  is exhausted. The current pool size limit(max connections) is 1 connections.. Setting message to status failed.

Can any one suggest , how to resolve this issue ?

Currently the Max connection is 1 , if we increase the value for Max Connection  to 2 or 5 in the receiver adapter , will this solves the issue ? Please suggest.

-Shweta

[Former Member]

Hi Shweta, Please check if the If the 1st RFC is getting executed successfully in SAP system. If the RFC is not closing properly, increasing the number of threads may not help as it might still max out the connections.

Thanks,
Sathya

[Former Member]

Hi Satya ,

Have checked it , RFC connection is fine.  Now , if i increase the RFC maximum connection value to 2 , will this  be solved ?

[Former Member]

increase max connections to 15 or 20 - as you may have more rfc scenarios coming up later.

or define a new receiver rfc comm channel with all connection details maintained in it for the second scenario and have max connection as 1 - though this is not a good approach.

[Former Member]

Hi,

If your two scenarios are not EOIO, you might have more simultaneous connections then scenarios. Simply think of several requests from each interface being processed at the same time - they will still fail if you set max connections to 2. It is much safer to set the paramter to a higher value, so that there was a chance for PI to "roll" the available connections dynamically, according to the current usage. Moreover - setting max connections to 10 doesn't mean PI maintains 10 permanent connections to the receiver. It is just a limit of connections that you globally want to allow.

Hope this helps,

Greg

[Former Member]

Greg ,

Can you please specify which parameter  you are talking about ?

[baskar_gopalakrishnan2]

RFC receiver channel.

Go to RFC client parameter  and see for "maximum connections" and set value  to higher value example 15

[Former Member]

Hi Greg ,

Could you please tell me where should I go and increase the parameter .

Kindly let me know the exact path (I am working in 7.1 version)

Thanks

Shweta

[Former Member]

Hi,

Simply set it in the receiver RFC communication channel, in the field I marked with green below:

Hope this helps,

Greg

[Former Member]

Greg ,

Apart from this, people are suggesting to  increase the parameter at the admin level for the time out exception via SXMB_ADM. I understand this is the BASIS activity , but just wanted to know  what is the exact path to change the settings for the same in SXMB_ADM . Pl advise.

Shweta

[Former Member]

shweta,

you can set the parameters as mentioned in above reply..

Thank You,

Madhav

[Former Member]

Hi,

Frankly speaking - it might turn out unnecessary. Most probably the timeouts were caused by the messages being "queued" at the receiver adapter level, because of only a single instance of the outgoing connection. In my opinion, it might be worth testing with only the communication channel paramter changed. Only if you still encounter problems, will you have to do further adjustments.

Regards,

Greg

[Former Member]

Thanks for the info Greg.  Thanks everybody .