log4cpp-devel

RE: [Log4cpp-devel] Log4cpp on OpenVMS

[Steve O. <s.o...@pe...>]

I am not exactly sure how the OpenVMS file system works, but most file
systems cache writes in memory before flushing them to disk. This greatly
increases write performance. I would not (at least in the default case), put
a fflush or fsync in the code.

Perhaps an additional method which would allow the application to flush
write to the disk.

Steve Ostlind
PentaSafe Security Technologies
713.860.9664

> -----Original Message-----
> From:	Tony Cheung [SMTP:dra...@as...]
> Sent:	Friday, February 01, 2002 4:08 AM
> To:	log...@li...
> Subject:	[Log4cpp-devel] Log4cpp on OpenVMS
> 
> Hi All,
> 
> I'm not sure how many are using the OpenVMS platform here, but I am
> responsible for the OpenVMS support in log4cpp. (I'm rather new to
> OpenVMS myself, but I am now building a C/C++ project on it)
> 
> I've just found out that in current log4cpp, while the application is
> logging to a file, other users are not able to see the log file.
> 
> After some investigations, I've found we could open the log file in
> shared mode and in the record mode file format (both OpenVMS specific),
> so that other users could "tail" on the log file.
> 
> fsync() should also be called after evey write, so that other users
> could see the real-time changes.
> 
> Please let me know if it's a good idea to make the changes into CVS, so
> that I would go ahead and do so.
> 
> Tony
> 
> P.S. I have subscribed to this mailing list, but somehow I am not
> receiving anything from it. Hope I am the only one having this problem.
> 
> _______________________________________________
> Log4cpp-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

[Log4cpp-devel] RE: Log4cpp on OpenVMS

[Tony C. <dra...@as...>]

Hi Steve and others,

First, the changes (if made) will be applied to OpenVMS compilations
only. I am not sure if other platforms require the changes.

For the disk caching, in order allow other users to "tail -f" on the
application log real-time. The OS needs to flush the changes to the disk
after each line of the logging. The caching should only be applicable to
within a single line of logging, otherwise there would be a delay for
the last few lines of logging to show up. BTW, the fsync() returns
before the I/O completes. 

I agree it's a tradeoff between real-time feedback or better disk
performance.

Ideas?

Tony

> I am not exactly sure how the OpenVMS file system works, but most file
> systems cache writes in memory before flushing them to disk. This greatly
> increases write performance. I would not (at least in the default case), put
> a fflush or fsync in the code.
> 
> Perhaps an additional method which would allow the application to flush
> write to the disk.
> 
> Steve Ostlind
> PentaSafe Security Technologies
> 713.860.9664
> 
> > -----Original Message-----
> > From:	Tony Cheung [SMTP:dra...@as...]
> > Sent:	Friday, February 01, 2002 4:08 AM
> > To:	log...@li...
> > Subject:	[Log4cpp-devel] Log4cpp on OpenVMS
> > 
> > Hi All,
> > 
> > I'm not sure how many are using the OpenVMS platform here, but I am
> > responsible for the OpenVMS support in log4cpp. (I'm rather new to
> > OpenVMS myself, but I am now building a C/C++ project on it)
> > 
> > I've just found out that in current log4cpp, while the application is
> > logging to a file, other users are not able to see the log file.
> > 
> > After some investigations, I've found we could open the log file in
> > shared mode and in the record mode file format (both OpenVMS specific),
> > so that other users could "tail" on the log file.
> > 
> > fsync() should also be called after evey write, so that other users
> > could see the real-time changes.
> > 
> > Please let me know if it's a good idea to make the changes into CVS, so
> > that I would go ahead and do so.
> > 
> > Tony
> > 
> > P.S. I have subscribed to this mailing list, but somehow I am not
> > receiving anything from it. Hope I am the only one having this problem.
> > 
> > _______________________________________________
> > Log4cpp-devel mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/log4cpp-devel

Re: [Log4cpp-devel] RE: Log4cpp on OpenVMS

[Bastiaan B. <bas...@li...>]

Tony Cheung wrote:

>Hi Steve and others,
>
>First, the changes (if made) will be applied to OpenVMS compilations
>only. I am not sure if other platforms require the changes.
>
>For the disk caching, in order allow other users to "tail -f" on the
>application log real-time. The OS needs to flush the changes to the disk
>after each line of the logging. The caching should only be applicable to
>within a single line of logging, otherwise there would be a delay for
>the last few lines of logging to show up. BTW, the fsync() returns
>before the I/O completes. 
>
>I agree it's a tradeoff between real-time feedback or better disk
>performance.
>
>Ideas?
>
>Tony
>

This feature may be more generally useful as well. In combination with a 
write cache disabled disk it can provide 'extra safe' logging. Of course 
log4j/log4cpp are still 'non reliable, best effort'  loggers, but this 
may help a bit.
So I  suggest to add this as a runtime option to FileAppender. Now for 
the implementation,  doe anyone have a good opion on whether to use 
fdatasync() or the O_SYNC open flag?
 
Bastiaan

Re: [Log4cpp-devel] RE: Log4cpp on OpenVMS

[Tony C. <dra...@as...>]

Hi,

A correction to my earlier's posting.

fsync() actually returns only after the I/O completes.
There's an alternative sync() which returns before the I/O completes.

I think O_SYNC and fsync() should be pretty much the same, with fsync()
doing the file I/O synchronization explicitely.

Tony

Bastiaan Bakker wrote:
> 
> Tony Cheung wrote:
> 
> >Hi Steve and others,
> >
> >First, the changes (if made) will be applied to OpenVMS compilations
> >only. I am not sure if other platforms require the changes.
> >
> >For the disk caching, in order allow other users to "tail -f" on the
> >application log real-time. The OS needs to flush the changes to the disk
> >after each line of the logging. The caching should only be applicable to
> >within a single line of logging, otherwise there would be a delay for
> >the last few lines of logging to show up. BTW, the fsync() returns
> >before the I/O completes.
> >
> >I agree it's a tradeoff between real-time feedback or better disk
> >performance.
> >
> >Ideas?
> >
> >Tony
> >
> 
> This feature may be more generally useful as well. In combination with a
> write cache disabled disk it can provide 'extra safe' logging. Of course
> log4j/log4cpp are still 'non reliable, best effort'  loggers, but this
> may help a bit.
> So I  suggest to add this as a runtime option to FileAppender. Now for
> the implementation,  doe anyone have a good opion on whether to use
> fdatasync() or the O_SYNC open flag?
> 
> Bastiaan