jrpharis
jrpharis

Reputation: 121

How can I correlate SignalR Write() and WriteLine() trace messages

I am implementing a custom, server-side TraceListener to redirect SignalR traces to my logging service. While testing, I implemented a default TextWriterTraceListener via the web.config, using direction from the SignalR help page. Using traceOutputOptions="Datetime, ThreadId, ProcessId", I get a trace like:

SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(504a810d-4597-4dd7-9a93-eb49e76519d3)
    ProcessId=18508
    ThreadId=11
    DateTime=2016-01-20T15:51:05.7327980Z

Where the first part of the trace is like a topic and trace level, the second half of the trace is the actual message, and the traceOutputOptions are listed right below with an indent. I tested this with several clients connected, and the traces were always written to the file grouped correctly.

I implemented my custom TraceListener using the blog here. I successfully intercept the traces, but the problem is a single, typical message comes in from multiple Write() calls, with a final WriteLine() call. If I simply send the message to my logs with each Write() or WriteLine() call, they appear as completely separate log messages. Simply writing to a text file from my TraceListener, I get output as follows:

SignalR.Transports.LongPollingTransport Verbose: 0 : 
DrainWrites(be9bc850-1453-4c0a-b1e4-3c1ecb8b0359)
ProcessId=23604
ThreadId=7
DateTime=2016-01-20T17:04:51.3859180Z

The only way I can see to correlate these, is to track them by the thread Write() and WriteLine() are called on, via some sort of cache, and then send the full message to the log service on WriteLine(), but only if the WriteLine() message does not have one of the traceOutputOptions's names in it, because those are also written via WriteLine().

I don't want the topic and trace level to be one log line, and the message to be another. Is there any other means to make sure these would be output to the logging service together?

Upvotes: 0

Views: 259

Answers (1)

jrpharis
jrpharis

Reputation: 121

The solution was to overwrite all the TraceListener Trace*() methods, rather than the Write() and WriteLine() methods. This gave me access to more than just a single string.

Upvotes: 1

Related Questions