2010-04-06 20 views

risposta

10

Possono, ma se un'applicazione sta scrivendo il file, l'altra applicazione probabilmente avrà un errore se ha bisogno di scrivere nel log anche perché la prima applicazione manterrà il file aperto per la scrittura . È sempre consigliabile disporre di fonti di registrazione dedicate per le applicazioni: se è necessario condividere un registro, utilizzare un database poiché è progettato per gestire scritture concorrenti.

Questa è una di quelle cose che funzioneranno molto bene sulla macchina quando si sta sviluppando poiché non è probabile che crei una quantità sufficiente di scritture simultanee nel file di registro per rilevare eventuali problemi. Una volta che la tua applicazione inizia a sperimentare più carico, il problema inizierà a mostrarsi e in quel momento potrebbe manifestarsi in modi strani. Sicuramente proverei un'altra soluzione.

10

Dipende dallo LockingModelFileAppender. Se è ExclusiveLock, un altro processo non può aprire il file per la scrittura. L'alternativa è MinimalLock, ma non è destinata a questo scopo. È progettato per consentire a un altro processo di spostare o eliminare il file.

+0

Qualcuno ha un'esperienza da condividere su questo metodo? – SandRock

17

MinimalLock risolve parzialmente il problema (come indicato da @Mark), ma se utilizzi RollingFileAppender, ti imbatterai in altri problemi. Quando il file scorre, potresti trovarti in una condizione di competizione in cui un processo sovrascrive il file di registro appena creato da un altro processo.

Altre opzioni includono RemoteLogger, in cui è stato configurato un semplice server per ricevere e registrare eventi di registrazione inviati da altri processi. Allo stesso modo, è possibile accedere a un database SQL. Ho scritto una semplice aggiunta che registra su Redis; avresti bisogno di una semplice applicazione per leggere da Redis e registrare su un file. Il problema con questi approcci è che tutti introducono un punto di fallimento. Quando qualcosa non funziona correttamente è spesso quando hai più bisogno dei log, e quindi potrebbero non essere disponibili.

Quindi la mia soluzione era di evitare del tutto il problema facendo registrare ciascun processo sul proprio file. Questo è stato facile da fare con un cambio di configurazione. Nella configurazione (Rolling)FileAppender, utilizzare:

<file type="log4net.Util.PatternString" value="c:\mylog-[%processid].txt" /> 

ID Il processo diventa parte del nome del file. Sì, questo significa che ora hai diversi file di registro da utilizzare, ma un aggregatore di file di registro come Graylog, Splunk o Logscape può essere d'aiuto.

1

Oppure è possibile utilizzare Mutex per bloccare la risorsa comune e quindi sincronizzare l'accesso a un file di registro comune da processi diversi.

0

Sì, è possibile, come indicato sopra, ma ora ho eseguito alcuni test di stress di questo scenario.

L'installazione è molto semplice:

  1. progetto Web 1 impostato con una pagina che registra una singola voce + un pulsante che scatena 1000 richieste alla stessa pagina, con un contatore nell'URL (rilevato dalla dichiarazione di registrazione).
  2. Progetto Web 2 impostato identicamente, sullo stesso file di registro.

Quando si fa clic su entrambi i pulsanti contemporaneamente, le voci del registro vengono intervallate nell'intero registro. MA, e questo è il grande GOTCHA, a giudicare dal contatore delle richieste di accompagnamento, è chiaro che ci sono condizioni di gara. Quasi ogni volta che un progetto web riesce a registrare la sua voce, l'altro fallisce (la voce viene saltata).

Quindi, con un traffico decente rispetto a questo registro comune, in pratica non si ha alcuna garanzia di quali istruzioni di registro effettivamente finiscono nel registro. La conclusione è di avere sempre file di log specifici del progetto, a quanto pare.

Il test è stato eseguito con il valore predefinito di "MinimalLock". Ho anche rifatto il test con "ExclusiveLock", solo per scoprire che il primo progetto web per configurare il logger "ha vinto", praticamente bloccando TUTTE le altre richieste di log. Quindi ovviamente, questo è un no-go pure.

Problemi correlati