WCF Receive Port Error: Attempted to access an unloaded AppDomain. Event ID: 5815,5802

We are running the performance test and endurance test. Our BizTalk application has multiple WCF Services in the back end and our BizTalk application has also been exposed as service for different client consumption. We have been observing the BizTalk box for quite some now and interestingly we receive lots of un common error. I just love getting these errors as the more of these errors we can identify the more safe we will be when we will move to production. The error which I receive was as below.
 
A response message sent to adapter "WCF-BasicHttp" on receive port "XXX _WCF_RP" with URI "/XXX/XXX.svc" is suspended.
 Error details: There was a failure executing the response(send) pipeline: "XXX.Common.XMLTransform.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=04305f779371fb00" Source: "Unknown " Receive Port: "XXX_WCF_RP" URI: "XXX/XXX.svc" Reason: Attempted to access an unloaded AppDomain. 
 MessageId: {FAE3BA3E-4516-421F-951B-44F2D7DE2978}
 InstanceID: {846BE511-789F-4BF9-A037-7FC5D3A682D3}
 
Cause:
The wcf runs out of  IIS process space. If more than one Web service exists in the IIS AppPool, then every Web service ends up having its own AppDomain. By default all messaging engine objects are created in the first AppDomain (that is,. the AppDomain corresponding to the first Web service). If the first Web service is inactive for an extended period of time for any reason, IIS unloads the first AppDomain. When this happens, all services in the hosting process become unusable.
 
Solution:
 
Please follow below steps to resolve this in BizTalk Server 2009 and 2006R2.
 
Reset the IIS.
Restart the host instances.
If you are not into PROD environment, terminate the existing suspended instances.
Although the above two steps should be good enough to resolve the problem.
 
If you are running the BizTalk Server 2010, please follow the below steps. You have a better resolution wherein you can explicitly assign the default application domain for isolated adapter. As per msdn the Deafault app domain never gets unloaded, so problem no longer exists.