You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Isuru Suriarachchi <is...@gmail.com> on 2007/05/28 16:00:29 UTC
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
RE: GSoC Project : Enhancing Chainsaw
Posted by Scott Deboy <sd...@comotivsystems.com>.
You need VFS and its dependencies in Chainsaw's classpath - see http://jakarta.apache.org/commons/vfs/download.html (all + any specific VFS file system types you want to test, for example Jsch to use sftp file system, which allows you to read files over ssh)
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
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Isuru Suriarachchi [mailto:isurues@gmail.com]
Sent: Wed 5/30/2007 1:05 AM
To: Log4J Developers List
Subject: Re: GSoC Project : Enhancing Chainsaw
Hi,
I have come up with a problem of loading a VFSLogFilePatternReceiver in
Chainsaw. Even though it is added to the 'known.receivers' file it is not
shown on the list of receivers in the Receivers panel. I tried it through an
external configuration file too. But in that case also, a separate tab is
not stared on the log panel. Is that a bug in Chainsaw or something wrong in
my local settings?
Thanks,
~Isuru
On 5/29/07, Isuru Suriarachchi <is...@gmail.com> wrote:
>
> Hi,
>
> Okay then ill send you the patch with those improvements and we can do any
> further modifications if needed.
>
> On 5/29/07, Paul Smith < psmith@aconex.com> wrote:
> >
> > 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 ?
> >
>
> I downloaded this YourKit tool and ill try to use it and check the
> overheads of RandomAccessContent...
>
> Thanks,
> ~Isuru
>
> 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
> >
> > sdeboy@comotivsystems.com
> >
> > www.comotivsystems.com
> >
> >
> >
> > -----Original Message-----
> > From: Isuru Suriarachchi [mailto:isurues@gmail.com <is...@gmail.com>]
> > 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: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > * 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: psmith@aconex.com * 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. * *
> >
> >
> >
>
Re: GSoC Project : Enhancing Chainsaw
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi,
I have come up with a problem of loading a VFSLogFilePatternReceiver in
Chainsaw. Even though it is added to the 'known.receivers' file it is not
shown on the list of receivers in the Receivers panel. I tried it through an
external configuration file too. But in that case also, a separate tab is
not stared on the log panel. Is that a bug in Chainsaw or something wrong in
my local settings?
Thanks,
~Isuru
On 5/29/07, Isuru Suriarachchi <is...@gmail.com> wrote:
>
> Hi,
>
> Okay then ill send you the patch with those improvements and we can do any
> further modifications if needed.
>
> On 5/29/07, Paul Smith < psmith@aconex.com> wrote:
> >
> > 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 ?
> >
>
> I downloaded this YourKit tool and ill try to use it and check the
> overheads of RandomAccessContent...
>
> Thanks,
> ~Isuru
>
> 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
> >
> > sdeboy@comotivsystems.com
> >
> > www.comotivsystems.com
> >
> >
> >
> > -----Original Message-----
> > From: Isuru Suriarachchi [mailto:isurues@gmail.com <is...@gmail.com>]
> > 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: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > * 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: psmith@aconex.com * 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. * *
> >
> >
> >
>
Re: GSoC Project : Enhancing Chainsaw
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi,
Okay then ill send you the patch with those improvements and we can do any
further modifications if needed.
On 5/29/07, Paul Smith <ps...@aconex.com> wrote:
>
> 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 ?
>
I downloaded this YourKit tool and ill try to use it and check the overheads
of RandomAccessContent...
Thanks,
~Isuru
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
>
> sdeboy@comotivsystems.com
>
> www.comotivsystems.com
>
>
>
> -----Original Message-----
> From: Isuru Suriarachchi [mailto:isurues@gmail.com <is...@gmail.com>]
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> *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: psmith@aconex.com * 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.**
>
>
>
Re: GSoC Project : Enhancing Chainsaw
Posted by Paul Smith <ps...@aconex.com>.
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
>
> sdeboy@comotivsystems.com
>
> www.comotivsystems.com
>
>
>
> -----Original Message-----
> From: Isuru Suriarachchi [mailto:isurues@gmail.com]
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
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: psmith@aconex.com 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.
RE: GSoC Project : Enhancing Chainsaw
Posted by Scott Deboy <sd...@comotivsystems.com>.
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
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Isuru Suriarachchi [mailto:isurues@gmail.com]
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