Объединительная плата SignalR не работает с конфигурацией NLog (клиенты не могут переподключиться)

Мы создали сервер с объединительной платой SQL. В последнее время мы обнаружили эту проблему, которая вызвала большое количество потоков использования w3wp.exe. Изучив всю кодовую базу, мы смогли определить причину, связанную с NLog.

Мы настроили NLog, выполнив следующие настройки в файле веб-конфигурации.

<configuration>
  <configSections>
    <section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog" />
  </configSections>
  <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd">
    <targets async="true">

      <target name="file" xsi:type="File" fileName="${basedir}/Logs/${shortdate}_printcloud.log" archiveFileName="${basedir}/Logs/ArchiveAuto/{#}_printcloud.log" archiveDateFormat="yyyy-MM-dd" archiveAboveSize="50000000" archiveEvery="Day" archiveNumbering="DateAndSequence" maxArchiveFiles="14" archiveOldFileOnStartup="false" createDirs="true" layout="${longdate} ${uppercase:${level}}  ${logger} ${message} (${callsite:includSourcePath=true}) ${exception:format=tostring}" />

    </targets>
    <rules>
     <logger name="PrintCloud.*" minlevel="Trace" maxlevel="Error" writeTo="file" />-->

    </rules>
  </nlog>
<configuration>

Внутри хаба мы использовали регистратор, как показано ниже.

public class ConnectorHub : Hub
{
    private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

    public void Connect(string message)
    {
        logger.Debug("Connection Recieved");
        (new SignalRHubHelper()).SendConnectRecieved(Context.ConnectionId);
    }
}

Когда мы запускаем объединительную плату с включенными этими конфигурациями, мы сталкиваемся с проблемой большого количества потоков, когда клиенты пытаются повторно подключиться. Но если мы закомментируем код конфигурации NLog из файла веб-конфигурации, объединительная плата будет работать отлично. Кто-нибудь испытывал подобное поведение при использовании объединительной платы? Что может быть причиной такого поведения?

Версия SignalR - версия 2.2.2 NLog - 4.4.9

РЕДАКТИРОВАТЬ 1

Кажется, проблема не возникает, когда мы отключаем ведение журнала трассировки сигналов из веб-конфигурации. Мы использовали NLog.NLogTraceListener регистрировать следы сигнализатора.

  <system.diagnostics>
    <sources>
      <source name="SignalR.SqlMessageBus">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.ServiceBusMessageBus">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.RedisMessageBus">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.ScaleoutMessageBus">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.Transports.WebSocketTransport">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.Transports.ServerSentEventsTransport">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.Transports.ForeverFrameTransport">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.Transports.LongPollingTransport">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.Transports.TransportHeartBeat">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
      <source name="SignalR.ReflectedHubDescriptorProvider">
        <listeners>
          <add name="traces" />
        </listeners>
      </source>
    </sources>
     <!--Sets the trace verbosity level--> 
    <switches>
      <add name="SignalRSwitch" value="Verbose" />
    </switches>
    <sharedListeners>

     <add name="traces" type="NLog.NLogTraceListener, NLog" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Вместо того, чтобы использовать NLog.NLogTraceListener и используя System.Diagnostics.TextWriterTraceListener вместо этого также, кажется, не дает никаких проблем.

1 ответ

Думаю, проблема в следующем:

autoflush=true

Это приводит к тому, что NLogTraceListener перестает работать и выполняет сброс для каждого события трассировки. Используя потоки пула потоков, чтобы очистить все зарегистрированные NLog-цели.

Если вам нужно autoflush = true, рассмотрите возможность отключения очистки пула потоков, добавив атрибут disableFlush к слушателю:

<add name="traces" type="NLog.NLogTraceListener, NLog" disableFlush="true" />

Любопытно, почему NLog Wiki рекомендует включить autoflush = true, не добавляя этот важный атрибут:

https://github.com/NLog/NLog/wiki/Send-System-Diagnostic-(Trace)-to-NLog

Другие вопросы по тегам