[WCF] How reliable is one way with MSMQ?

At the moment I’m working with Gerben van Loon on a WCF project at a large insurance company in the Netherlands. One of the requirements of the project is to log all incoming and outgoing messages. Because we want to customize the way these messages are logged, we cannot use the standard tracing and message logging functionality.

To also be able to use the message logging functionality from within other applications, we decided to build a WCF behavior (message inspector) and a WCF service to log the messages to a database. Message logging is very important in this case so we came up with a very reliable, scalable and good performing solution: using MSMQ as a transport.

Our idea was that messages could be written into the queue very fast using a reliable one way operation call and the service could read from the queue and log the message. Messages would not be lost in case the service was overloaded and the consumer wouldn’t have to wait, the ideal situation!

However, while testing the behavior and service, Gerben found out messages were lost somehow. He called the service twice and one operation was registered and the other was not. What was going on? After turning on the WCF trace and messagelog it was clear what went wrong. The log showed this message:

There was an error deserializing the object of type Service.Operation. The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader.

The second operation contained a body of 10k and therefore couldn’t be processed. Ok, so far our understanding of why this happened.

But the thing that worries us is that if the trace and messagelog are switched off, you never know the error occurs because there is obviously no report to the consumer of the service (there never is with one way) and there is also no message in the eventlog. Of course the solution in this case is to increase the content length quota, but maybe there are other errors like this that can occur without knowing. And because we don’t know what the size of the messages will be, should we use Int32.MaxValue as value for MaxStringContentLength?

Please let me know if we overlook something of if you know a way to solve this.