so i have changed my tail implementation to use watchFile and createReadStream combination instead of tail -f child process and it seems to be working pretty good .. even though in this case I am opening up the file read stream every time there is a change in the file .. i m just curious how is that supposed to be more efficient than the tail process .. i havent tried the fs-ext option yet
On Tuesday, July 3, 2012 12:49:11 PM UTC-5, mscdex wrote: > On Jul 3, 1:08 pm, Adeel Qureshi <[email protected]> wrote: > > yeah thats a good point .. i did noticed that for long response requests > it > > tends to disconnect the client and then the response never completes .. > > however i am using socket.io so isnt that supposed to use websockets > for > > chrome and it still ends up disconnecting the client > > Well, for socket.io I believe there is a config option to send an > application-level heartbeat message at some configurable interval. > > > infact another thing I noticed is that if the application is monitoring > > logs by tailing a file and receiving log file updates and at the same > time > > if i trigger a heavy search which sends a bunch of data back then then > tail > > process gets stuck as well .. after doing some search the only thing i > came > > across was to utilize process.nextTick in the search process to let the > > tail processes continue .. havent incorporated that yet to see if that > > improves things.. > > You should be able to avoid executing 'tail -f' by simply using a > combination of fs.watchFile, fs.createReadStream, and keeping track of > the last file size to use as the 'start' value option to > fs.createReadStream. An example is [1] (you can substitute 'on' for > 'addListener'). > > Another option is to use the fs-ext module [2]. Here you'd simply use > fs.open once and fs-ext.seek multiple times instead of > fs.createReadStream with a 'start' value option every time the file > changes. The advantage of this option is that you only open the file > once and you can do a relative seek instead of an absolute seek, which > is probably more efficient and also allows you to process files larger > than what a JavaScript integer can represent. > > [1] https://github.com/netroy/Lockets/blob/master/server.js#L62 > [2] https://github.com/baudehlo/node-fs-ext/ -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
