Ok, I have seen this error a couple of times on the internet. They all have to do with the same issue. And in my current project i stumbled upon this problem. I found a solution and thought it would be nice to share this with the community
- You have created an adapter with the AdapterWizard on codeplex.
- You stress test the newly developed adapter and you get some pretty strange eventLog messages.
Some sample Eventlog messages you could encounter:
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5796
Date: 2/10/2009
Time: 2:48:45 PM
User: N/A
Description:
The transport proxy method DeleteMessage() failed for adapter AAA: Reason: "Messaging engine has no record of delivering the message to the adapter. This could happen if DeleteMessage() is called multiple times for the same message by the adapter or if it is called for a message which was never delivered to the adapter by the messaging engine". Contact the adapter vendor.
Or you could get
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5673
Date: 2/10/2009
Time: 2:48:44 PM
User: N/A
Description:
The Messaging Engine received an error from transport adapter "AAA" when notifying the adapter with the BatchComplete event. Reason "Object reference not set to an instance of an object.".
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Or
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5675
Date: 2/10/2009
Time: 2:48:44 PM
User: N/A
Description:
The Messaging Engine encountered an error while deleting one or more messages.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
And even :
Event Type: Error
Event Source: BizTalk DW Reporting
Event Category: None
Event ID: 1000
Date: 2/10/2009
Time: 2:48:45 PM
User: N/A
Description:
Faulting application btsntsvc.exe, version 3.6.1404.0, stamp 4674b0a4, faulting module btsmsgcore.dll, version 3.6.1404.0, stamp 4674b091, debug? 0, fault address 0x0008fb84.
They all have to do with the same issue.
I compared the code generated by the Adapter Wizard with the code from the HTTP.NET adapter that comes with the samples.....
I found one BIG difference. Here is the code as it is generated by the adapter wizard....
private IBaseMessage BuildResponseMessage(Stream response,IBaseMessageContext context)
{
IBaseMessage btsResponse = null;
// Get the response stream, create a new message attaching
// the response stream...
using (Stream s = response)
{
// NOTE:
// Copy the network stream into a virtual stream stream. If we were
// to use a forward only stream (as in the response stream) we would
// not be able to suspend the response data on failure. The virtual
// stream will overflow to disc when it reaches a given threshold
VirtualStream vs = new VirtualStream();
int bytesRead = 0;
byte[] buff = new byte[8 * 1024];
while ((bytesRead = s.Read(buff, 0, buff.Length)) > 0)
vs.Write(buff, 0, bytesRead);
response.Seek(0, SeekOrigin.Begin);
response.Close();
// Seek the stream back to the start...
vs.Position = 0;
// Build BTS message from the stream
IBaseMessageFactory mf = transportProxy.GetMessageFactory();
btsResponse = mf.CreateMessage();
IBaseMessagePart body = mf.CreateMessagePart();
body.Data = vs;
btsResponse.AddPart("Body", body, true);
btsResponse.Context = context;
}
return btsResponse;
}
And the code from the HTTP.NET adapter from the BizTalk SDK looks like this :
private IBaseMessage BuildResponseMessage(WebResponse webResponse)
{
IBaseMessage btsResponse = null;
// Get the response stream, create a new message attaching
// the response stream...
using (Stream s = webResponse.GetResponseStream())
{
// NOTE:
// Copy the network stream into a virtual stream stream. If we were
// to use a forward only stream (as in the response stream) we would
// not be able to suspend the response data on failure. The virtual
// stream will overflow to disc when it reaches a given threshold
VirtualStream vs = new VirtualStream();
int bytesRead = 0;
byte[] buff = new byte[8 * 1024];
while ((bytesRead = s.Read(buff, 0, buff.Length)) > 0)
vs.Write(buff, 0, bytesRead);
webResponse.Close();
// Seek the stream back to the start...
vs.Position = 0;
// Build BTS message from the stream
IBaseMessageFactory mf = transportProxy.GetMessageFactory();
btsResponse = mf.CreateMessage();
IBaseMessagePart body = mf.CreateMessagePart();
body.Data = vs;
btsResponse.AddPart("Body", body, true);
}
return btsResponse;
}
After I removed the context copy part of the code things started to look much better. No host restarts anymore and no more strange exceptions. It's logical that copying the entire context from one request message to a response message can cause these problems.
So if you created an adapter yourself with the adapter wizard, check your code to see if the offending line of code is still there. If so, do a stress test on it and see the eventlog messages pop up !.