"Unexpected End of file" using GetReaderAtBodyContents in WCF Service

Question

I'm running a web service which accepts SOAP messages over a custom binding.

The messages get dispatched correctly and most of them get processed fine. While working off a Message, the message is being read to a XmlDocument using:

XmlDocument doc = new XmlDocument();
try {
    doc.Load(msg.GetReaderAtBodyContents());
} catch (XmlException x) {
    e = x;
} catch (IOException x) {
    e = x;
}

However, when load on the service increases (maybe a threading problem? Cannot imagine, since a message isn't accessed anywhere else after my custom transport channel used the WebMessageEncoder to create the message,) an XmlException gets thrown rarely although the input Message was okay.

Unexpected end of file. Following elements are not closed: A, B, Body, Envelope. Line 28, position 9.

Since I've put a breakpoint in the code at this line, I can look at the current value of msg.ToString() which gives me an XML file which validates well in a validator like http://www.validome.org/xml/validate/

Note that calling msg.ToString() does not always have to work properly since the body could also be in a stream form which can only be read once using the reader at msg.GetReaderAtBodyContents().

The reason for this strange behavior seems to be in my custom binding, since it works fine over 25000 requests with the WebHttpBinding.

In my transport channel, I use this code after extracting the message from the input source to the byte[] body.

Message message = encoder.ReadMessage(
new ArraySegment<byte>(body, 0, contentLength), bufferManager, contentType);

Headers get applied afterwards, and then the message gets put directly into the RequestContext's RequestMessage property. There has to be something I have forgotten in the error. But what?

Answer 1

The problem was, that I called encoder.ReadMessage twice, to have one message for debug output and one to pass to the RequestContext. Unfortunately, ReadMessage returns the byte[] buffer to the pool. If load was increased, another thread could acquire the buffer between the two ReadMessage calls and overwrite it with something own. Since the second message was forwarded to the ServiceModel, it was possible that it could have been corrupted through this process.