Levels of Tracing, Part 6
The last article in the levels of tracing series covers the logging of messages at the transport level. Transport level logging generally occurs in the message encoder as that is where the message bytes are actually processed but in some rare cases there are times when the transport sends messages without using a message encoder. In these cases, it's the transport that logs the message rather than the message encoder. All of this behavior for transport level logging is controlled by setting the logMessagesAtTransportLevel option.
If you've missed one of the parts in this series so far, here's the complete list.
- Introduction to tracing and trace levels
- Configuration tracing and trace options
- Enabling message logging
- Message logging configuration options
- Logging for malformed and service level messages
A transport level message is one that is being processed by a message delivery component. Layered channels more often contribute their message (if they happen to have something interesting that neither the layer above or below has visibility into) at the service level. I'll use message delivery components in this case to mean just the network transport and message encoder.
The binary, text, MTOM, and JSON message encoders each trace messages at one of four different times:
- When receiving a buffered message, after the full message has been received
When receiving a streamed message, after the message headers have been received but before the message body is read
- When sending a buffered message, after the message has been converted into a series of bytes, using the outputted bytes that were generated
- When sending a streamed message, after the message has been dumped to the output stream, using the original copy of the message
The HTTP transport also has some special behavior for tracing messages at additional times:
- When receiving a message that arrived without the use of a WS-Addressing protocol
When sending a request message that doesn't have an entity body