Known Issues

Known Issues

HubTraceListener memory buildup temporarily

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.

Solutions or Workarounds

In short, this is not a problem.

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.

Internet Explorer in Windows Server 2012 with high security level of Internet Options could not display trace messages

By default, the level is high, and there's no simple way to adjust it, nor it is worthy to decrease the level.

Solutions or Workarounds

Add the TraceHub Website to Trusted sites of the Security tab.

Browser does not display new traces after the device or the browser wakes up for up to 20 seconds

When the PC or the devices had run into sleep/standby/hibernation, the connection with the TraceHub server is obviously terminated. After waking up, TraceHub client in the browser may try to reconnect after 20 seconds.

In Apple iPad or Android devices, if the browser app is deactivated after switching to the other app, the connection is also terminated. TraceHub client in the browser behaves the same, and tries to reconnect after 20 seconds.

Hints:

TraceHub Console has similar behaviors.

A client such as a HubTraceListener instance is still showing up in the Clients list after the client is shut down.

SignalR will keep the reference to the client for around 30 seconds if the client is shutdown without calling stop. Then SignalR will disconnect "officially" from the client, and the client won't appear in the list. Both HubTraceListner and TraceHub Console have the following codes:

AppDomain.CurrentDomain.ProcessExit += (sender, e) =>
{
        hubConnection.Dispose();
};

So if the host process is terminated gracefully, TraceHub will get notification of "stop> immediately. Otherwise, the 30 second timeout will be in play.

Known Browser/JS Issues

In Firefox's development mode, the F12 Console reports "no element found"

According to https://bugzilla.mozilla.org/show_bug.cgi?id=884693, this is a bug in FF, but no affecting the correct running of AJAX. Apparently the problem still exists in FF v 48.0.2. IE and Chrome won't make similar complains.

All browsers reports "Synchronous XMLHttpRequest on the main thread is deprecated"

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/1jquery-3.1.0.min.js:4:15668

According to this http://stackoverflow.com/questions/28322636/synchronous-xmlhttprequest-warning-and-script, this is nothing significant so far. And in jQuery lib, there's still such block, probably causing this warning.

jQuery._evalUrl = function( url ) {
	return jQuery.ajax( {
		url: url,

		// Make this explicit, since user can override this through ajaxSetup (#11264)
		type: "GET",
		dataType: "script",
		cache: true,
		async: false,
		global: false,
		"throws": true
	} );
};