Pregunta

Estamos viendo un problema intermitente en máquinas de desarrollo y producción mediante el cual nuestros archivos de registro no se están conectados a.

Cuando se ejecuta en el desarrollo y la depuración utilizando Visual Studio obtenemos los siguientes mensajes de error log4net en la ventana de salida VS:

log4net:ERROR [RollingFileAppender] Unable to acquire lock on file C:\folder\file.log.

El proceso no tiene acceso al archivo 'C: \ carpeta \ file.log'. Porque está siendo utilizado por otro proceso

log4net:ERROR XmlConfigurator: Failed to find configuration section 'log4net' in the application's .config file.
Check your .config file for the <log4net> and <configSections> elements.

La sección de configuración debe ser similar a:

<section
  name="log4net"
  type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />

Nuestra solución actual de la cuestión es cambiar el nombre del último archivo de registro. Nos gustaría, por supuesto, esperar que falle (debido al bloqueo de archivo antes mencionado), pero normalmente no lo hace. Una o dos veces el cambio de nombre ha fallado debido a un bloqueo de la Aspnet_wp.exe proceso.

Nuestra sección de configuración log4net se muestra a continuación:

<log4net>
  <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
    <file value="C:\folder\file.log"/>
    <appendToFile value="true" />
    <datePattern value="yyyyMMdd" />
    <rollingStyle value="Date" />
    <maximumFileSize value="10MB" />
    <maxSizeRollBackups value="100" />
    <layout type="log4net.Layout.PatternLayout">
      <header value="[Header]&#xA;"/>
      <footer value="[Footer]&#xA;"/>
      <conversionPattern value="%date %-5level %logger ${COMPUTERNAME} %property{UserHostAddress} [%property{SessionID}] - %message%newline"/>
    </layout>
  </appender>
  <root>
    <level value="INFO"/>
    <appender-ref ref="RollingLogFileAppender"/>
  </root>
</log4net>

Como se ha mencionado, estamos viendo esta forma intermitente en las máquinas, pero una vez que el problema ocurre persiste.

¿Fue útil?

Solución

Trate de añadir

<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />

a su elemento <appender />. Hay un cierto impacto en el rendimiento porque esto significa que log4net cierran el archivo, escribir en él, y desbloquearlo para cada operación de escritura (en comparación con el comportamiento por defecto, que adquiere y se agarra al bloqueo durante mucho tiempo).

Una de las consecuencias del comportamiento por defecto es que si se está usando en virtud de un sitio web que se ejecuta en varios procesos de trabajo que se ejecutan en la misma máquina, cada uno tratará de adquirir y mantener en esa cerradura indefinidamente, y dos de ellos sólo se va a perder. Cambiar el modelo de bloqueo de la cerradura funciona mínima alrededor de este problema.

(Al depurar, desgarbadas terminaciones y girando hasta un montón de nuevos procesos de trabajo es exactamente el tipo de cosa que es probable que suceda.)

Buena suerte!

Otros consejos

También ten en cuenta de la log4net FAQ :

  

¿Cómo consigo múltiples procesos se pueden registrar en el mismo archivo?

     

Antes de siquiera empezar a tratar cualquiera de las alternativas previstas, pregunte   a sí mismo si realmente necesita tener múltiples procesos de registro en el   mismo archivo, entonces no lo hagas; -).

     

FileAppender ofrece modelos de bloqueo enchufables para este caso de uso, pero todos   implementaciones existentes tienen problemas e inconvenientes.

     

Por defecto, el FileAppender mantiene un bloqueo exclusivo de escritura en el registro   archivo mientras se está registrando. Esto impide que otros procesos de escritura   en el fichero. Este modelo es conocido para romper con (al menos en algún   versiones de) Mono en Linux y los archivos de registro pueden corromperse tan pronto como sea   Otro proceso intenta acceder al archivo de registro.

     

MinimalLock sólo adquiere el bloqueo de escritura mientras que un registro se está escribiendo.    Esto permite que múltiples procesos a las escrituras de intercalación en el mismo archivo,   aunque con una pérdida considerable en el rendimiento.

     

InterProcessLock no bloquea el archivo en absoluto, sino sincroniza utilizando una   todo el sistema objeto mutex. Esto sólo funcionará si todos los procesos cooperan (y   utilizar el mismo modelo de bloqueo). La adquisición y liberación de un objeto mutex   para cada registro de entrada a ser escrito se traducirá en una pérdida de   rendimiento, pero el objeto mutex es preferible el uso de MinimalLock.

     

Si utiliza RollingFileAppender cosas se vuelven aún peor, ya que varios   proceso puede tratar de empezar a rodar el archivo de registro al mismo tiempo.   RollingFileAppender ignora por completo el modelo de bloqueo al rodar   archivos, poniendo los archivos simplemente no es compatible con este escenario.

     

Una alternativa mejor es tener sus procesos de registro a   RemotingAppenders. Uso de la RemoteLoggingServerPlugin (o   IRemoteLoggingSink) un proceso puede recibir todos los eventos y registrarlos   a un único archivo de registro. Uno de los ejemplos muestra cómo utilizar el   RemoteLoggingServerPlugin.

Si usted tiene

<staticLogFileName value="true" />
<rollingStyle value="Date" />
<datePattern value="yyyyMMdd" />

y añadir

<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />

entonces no será un error mientras el balanceo sucede. El primer proceso creará el nuevo archivo y el cambiar el nombre del archivo actual. Entonces próximos proces harán lo mismo y tomar el archivo recién creado y sobreescribir el archivo cuyo nombre ha cambiado. Dando como resultado la logfiel por ser vacía el último día.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top