On Sat, Jul 14, 2018 at 9:13 AM Gary Gregory <garydgreg...@gmail.com> wrote:
> > > On Fri, Jul 13, 2018 at 7:53 PM Remko Popma <remko.po...@gmail.com> wrote: > >> >> > On Jul 14, 2018, at 10:49, Remko Popma <remko.po...@gmail.com> wrote: >> > >> > Be careful in this area. I remember this was quite tricky! >> > >> > Please step through the code in a debugger to make sure it does what >> you think it does before making changes. >> >> Also maybe start with a failing test case. >> Is there an actual problem or did you just notice that the code looks >> like it won’t work? >> > > Hm, the RollingRandomAccessFileManager is probably correct as is but the > RollingFileManager > needs careful inspection which I will do. > > I had a RollingFileAppender that was not behaving as I expected and > that's when I debugged the code and noticed that immeditateFlush was not > passed along. > Never mind, it's the locking attribute that is not passed along to the RollingFileManager and instead is hard-coded to false. Gary > > Gary > >> >> > >> > Remko >> > >> >>> On Jul 14, 2018, at 9: 27, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >>> >> >>> On Fri, Jul 13, 2018 at 6:22 PM Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >>> >> >>> Hi All: >> >>> >> >>> Looks like a bug and not by design in: >> >>> >> >>> >> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.RollingFileManager(LoggerContext, >> >>> String, String, OutputStream, boolean, boolean, long, long, >> >>> TriggeringPolicy, RolloverStrategy, String, Layout<? extends >> Serializable>, >> >>> String, String, String, boolean, ByteBuffer) >> >>> >> >>> Note the hard coded false. >> >>> >> >>> Which I will fix unless someone can convince me otherwise. >> >>> >> >> >> >> Same for RollingRandomAccessFileManager. >> >> >> >> Gary >> >> >> >> >> >>> >> >>> Gary >> >>> >> >
