Poolsize maximum reached : SAP Business Connector
Business Connector reads EDI file from VAN. Before reading from VAN it gets the details of VAN from SAP system.and converts them into idoc and post them into SAP.
When SAP system is down the files from VAN are not read. They have to be read when connection is reset again.
Initially connection to SAP is down. Now after some time connection to SAP is up. File is not processed even after connection to SAP has been reset.
We have got an system error message " Number of Connections in pool exceeds limit of 10". Also,Sometimes the number of iDocs generated are more than the expected number of Idocs.
In this scenario, Business Connector tries to hit the SAP system, which has been shut down. Business Connector keeps trying for every 300 secs as was defined in our scheduler. Since the connection to SAP is not there,it keeps trying and the pool size in the Business Connector increases. Once this poll size reaches maximum limit (here default value is 10), no new physical connections are created and pool size has to be reset again in the bussiness connector . Then the files are processed and idocs are created in SAP system. Now I have reset the poolsize manually, then the files are processed but strangely I observed that the number of iDOcs generated is more than expected.
Duplicate IDocs got generated.
Can we know why bussiness connector is unable to post idocs to SAP unless the pool settings are reset. How to reset the poolsize without manual intervention? Can we change the poolsize to some number so that this error does not occur.
Also, why the number of Idocs generated is more after resetting the poolsize.
Could anyone please help us out with this issue.
Thanks & Regards
Markus Tolksdorf replied
the cause of the exceeded pool can be different. Very likely is a pure Business Connector release without any CoreFix and Service Releases. There has been a bug within an early JCo 2.1 that was fixed a long time ago that showed exactly that symptom.
The duplicate IDocs are very probably caused by your custom client logic not following the rules of tRFC: If you associated an IDoc with a TID, you always need to use this TID again when sending this IDoc to the target system repeatedly because of errors during previous attempts. The error might have happened after a successful processing in the backend and therefore using the same TID will avoid a duplicate processing afterwards.