-
Notifications
You must be signed in to change notification settings - Fork 6
Known Issues
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.
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.
Add the TraceHub Website to Trusted sites of the Security tab.
When the PC or the devices had run into sleep, 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.
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.
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.
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
} );
};