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 stops displaying new traces after the device or the browser wakes up

If the PC or the devices had run into sleep and then woke up, the browser won't display new traces.

In iPad or iPhone, a browser may stop displaying new traces after you switching to other apps.

Solutions or Workarounds

Just reload or refresh the Web page, things will then be fine.

And this may not need to be fixed, since in many scenarios, this is desired by users.

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();//but this won't be called if the process is terminated disgracefully.
};

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
	} );
};