that sleep level should be a receiver configurable setting too. A
default of 5 seconds is good, and perhaps we should have per-remote
resource type defaults. that is, perhaps 1 second is ok as a default
for files, but 5 seconds seems a nice default for other classes of
remote protocols (http, sftp etc).
Not sure what the overhead is in VFS for gaining access to the
RandomAccessContent object. Be interesting to profile that. Do you
have access to a Profiler tool like Yourkit ?
cheers,
Paul
On 29/05/2007, at 10:25 AM, Scott Deboy wrote:
Looks good..I'd suggest doing a file.exists on the 1st line of the
do loop & reset the pointer to zero if it's false, sleep for 5
secs, and continue..
Will help folks like me who use apps which truncate a log file on
app start.
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax: 503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
-----Original Message-----
From: Isuru Suriarachchi [mailto:[EMAIL PROTECTED]
Sent: Mon 5/28/2007 7:00 AM
To: Log4J Developers List
Subject: GSoC Project : Enhancing Chainsaw
Hi Scott and Paul,
I have been working on my first task to fix the tailing capability
of VFS
log receiver, for last few days. First of all I would like to
describe why
tailing is not working in the current implementation as I
understand and
then I will suggest my solution.
Current Implementation
In the current implementation, in VFSLogFilePatternReceiver, VFSReader
creates a FileSystemManager and makes a FileObject by giving the
file URL
using the created FileSysemManager. After that it creates an
InputStreamReader to read the log file and passes it to the process
(reader)
method in the LogFilePatternReceiver in log4j. In this process()
method, a
BufferedReader is created using the reader passed and this
BufferedReader is
checked for new lines (new logs in the log file), until 'tailing'
is kept
true.
This works for URLs in the local file system (Eg: file:///foo/
bar.log ) as
the BufferedReader is updated whenever a new line is written to the
file.
But when the log file is accessed through some other protocol, say
http,
this Buffered reader is not updated through the protocol when new
lines are
added to the log file. That's why tailing is not working with such a
protocol.
My Solution
As I can see, keeping only the InputStreamReader of the file in the
method
we run the while loop (the loop which runs until 'tailiing' is kept
true) is
not going to work. And also we can't pass a FileObject to the
process()
method as it is a method in a standardized interface. So I think
the above
while loop should run inside VFSReader (in
VFSLogFilePatternReceiver) in
which we have the access to the FileObject of the log file. Then we
can get
this working by getting the randomAccessContent of the log file,
inside the
while loop and seeking for the line pointed by the file pointer.
According to the method proposed by Mario on the VFS team, this can
be done
in the following manner.
//This part comes inside the VFSReader class...
long lastFilePointer = 0;
do
{
RadomAccessContent rac = FileObject.getRandomAccessContent()
rac.seek(lastFilePointer)
reader = new InputStreamReader(rac.getInputStream());
process(reader);
lastFilePointer = rac.getFilePointer();
rac.close();
}while (isTailing());
Here, as the while loop is taken out of the process() method,
activateOptions() method in the LogFilePatternReceiver should also be
changed as it calls the process() method.
If this method is okay, I can send the patch with the modifications
mentioned above. Your comments are welcome..
Thanks,
~Isuru
<winmail.dat>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED] www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
