We've been receiving hundreds of errors on BizTalk 2013R2 recently (running CU 8);
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
I suspect these are being caused by Connection Leaks, but I'm not sure how to pin down the exact source.
I've tried querying with SP_WHO2 to see how many/which connections are open, and can see a LOT of sleeping connections to our Biz server, but again, can't quite isolate them.
I can see which send port the issues occurring on, and I can see which called Stored Procedure via WCF-SQL is being rejected by the above error, but I'm now at a loss as where to go next.
As far as I'm aware, there's no unorthodox connections or adapters being used to call connections to the Biz server. The only thing I can think of might be that the connections behind Typed Polling calls isn't being closed.
Should BizTalk be closing any WCF-SQL/WCF-Custom adaptor connections once its attempted connection?
Any suggestions on where to go next to isolate the source?
This issue was supposedly fixed in CU 7 for BizTalk Server 2013 R2, see FIX: WCF-SQL adapter fails intermittently if AmbientTransaction is True or if ReceiveTimeout is not more than polling time plus time to query data from SQL Server.
The workarounds implied in that article used to work to some degree before CU 7, e.g. set the ReceiveTimeout to a really large number. So try that.