2015-09-27 8 views
12

Ho un'applicazione server NodeJS. Ho questa riga di codice per la mia registrazione:fs.writeFileSync restituisce Error: UNKNOWN, modo corretto per scrivere file sincrono in nodejs

fs.writeFileSync(__dirname + "/../../logs/download.html.xml", doc.toString()); 

volte funziona correttamente, ma sotto carico pesante dà questa eccezione:

Error: UNKNOWN, unknown error 'download.html.xml' 

PS: ho trovato un link qui: http://www.daveeddy.com/2013/03/26/synchronous-file-io-in-nodejs/ Blogger descrive che writeFileSync non ha davvero finito di scrivere al reso. C'è un modo corretto per farlo in modo sincrono, cioè senza callback?

+0

Cosa consideri "corretto"? – Soren

+0

Inoltre, non è chiaro se si sta chiedendo quale sia la causa del proprio errore o come si effettuano le operazioni di sincronizzazione sul file system - è improbabile che siano correlate. – Soren

+1

Perché non vuoi utilizzare i callback? Effettuare un'operazione sincrona bloccherà il ciclo degli eventi e sarebbe particolarmente negativo dato che la tua app è sottoposta a un carico pesante. –

risposta

1

Per l'OP sembrava apprezzare il commento, l'ho messo in una risposta nella speranza che possa aiutare gli altri utenti.

Mi sembra che il problema sia dovuto al fatto che molti descrittori sono esauriti chiamando lo writeFileSync. Anche il link pubblicato nella domanda sembra confermare l'idea.

In realtà, sto ancora cercando di capire se esiste un modo per sapere quando la scrittura è effettivamente finita sotto il cofano, non solo dal punto di vista di nodejs. Forse il parametro this può essere d'aiuto, ma suppongo che soffra dello stesso problema.

In ogni caso, è possibile aggirare il problema implementando un pool di scrittori con una coda in cui inserire le proprie richieste di scrittura.

Il pro è che il numero di descrittori aperti può essere tenuto sotto controllo. Non esattamente, anzi, a causa del problema menzionato nel link pubblicato dall'OP, ma ovviamente si può evitare di utilizzare tutte le risorse di un sistema.

Dall'altro lato, sfortunatamente, c'è il problema che questa soluzione tende ad occupare molta più memoria (perché in effetti uno sta parcheggiando i suoi documenti mentre aspetta un lavoratore disponibile).

Ovviamente, potrebbe essere una soluzione adatta per scoppio di richieste separate nel tempo, ma forse non si adatta bene a carichi fissi costanti nel tempo.

1

Quando si esegue un writeFileSync si ottiene un descrittore di file nel file. Il sistema operativo limita il numero di descrittori di file che possono essere aperti in un dato momento. Quindi, con un uso intenso, potresti raggiungere il limite. Un modo per scoprirlo è che questo è il caso di utilizzare ulimit e impostarlo su illimitato.

Un'altra possibilità sono errori di I/O. Ad esempio, la chiusura di un descrittore di file avrà esito negativo se si verifica un errore IO.

+2

Da quello che ho visto, il raggiungimento del limite del descrittore produce un errore specifico ('EMFILE'), non uno sconosciuto - quindi probabilmente è non la causa qui. –

Problemi correlati