Known Issues

Known Issues

HubTraceListener

When a program using HubTraceListener is started and the TraceHub is not on, the listener will buffer the traces in a ConcurrentQueue, so the memory usage may climb up over times. In demo, around 800 KB memory every 5000 traces, depending on the size of each trace. After connecting to the TraceHub, all traces will be sent to TraceHub and the queue will become empty, however, the memory usage won't go down immediately, even though subsequent traces will not make the program use more memory as they are sent to TraceHub and dequeued promptly. According to this article https://blogs.msdn.microsoft.com/pfxteam/2012/05/08/concurrentqueuet-holding-on-to-a-few-dequeued-elements/ , this seems to be by design. In my tests, around 5 minutes after the large queue holding 30,000 traces become empty, the memory usage will be dropped. Apparently GC is rather lazy for ConcurrentQueue, probably by design as well.

However, after all, such memory build up won't really consume a lot memory, since 100,000 traces buffered may consume 20 MB, and a capacity of the queue is set to 100,000. If the TraceHub is unavailable for long time and the application keep running, when the capacity is reached, no more trace could be buffered.

Firefox

Firefox could not display trace messages from Trace.