[
https://issues.apache.org/jira/browse/LOGCXX-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950935#comment-14950935
]
Thorsten Schöning commented on LOGCXX-457:
------------------------------------------
Looks like I've misunderstood how the tests and rolling should work a bit: The
rolling file appender always rolls over BEFORE any data is written, that's way
"delayUntilNextSecond" was AFTER the file name generation, but BEFORE the
actual logging. A manual rollover should be triggered when trying to log the
first time in the new second. The rollover would then use the already present
empty file, rename that, create a new one and log into that one. Which file
name would the new file become? Looking at TimeBasedRollingPolicy::rollover it
should be the current date, shouldn't it?
So why did the tests fail? They did in the past, they do now and it even
depends on if they are executed in my IDE with an attached debugger or in the
shell. I just emptyed the output directory and only 1 test failed instead of
three. During the last hour of testing, sometimes test 4 and 5 failed,
sometimes test1... And test6 reproducibly failed and seems like the only one
reliably working now. I don't really understand what's going on there...
> timebasedrollingtest fails for seconds related filenames
> --------------------------------------------------------
>
> Key: LOGCXX-457
> URL: https://issues.apache.org/jira/browse/LOGCXX-457
> Project: Log4cxx
> Issue Type: Bug
> Components: Tests
> Affects Versions: 0.11.0
> Environment: Windows 8.1 x64, C++-Builder 10 Seattle
> Reporter: Thorsten Schöning
> Assignee: Thorsten Schöning
>
> I'm building 0.11.0 and except timebasedrollingtest all tests pass. Using
> process monitor I can see that in that test some files with timestamps in
> their name with seconds resolution are not available as expected and form
> looking at the code in my opinion this is a bug in the test and can't work at
> all.
> Looking at the history, problems with this test have been reported before in
> LOGCXX-206, where it first was simply disabled and enabled afterwards, but
> without any noticable changes or documentation to the problem. It just seemed
> to work now.
> But lets look at test 6: First, some filenames are build containing a
> timestamp starting with "now" and each new filename is expected to be one
> second in the future. But the important thing is that the names start with
> "now"!
> Afterwards the tests waits always(!) for at least the next second, is than
> writing to some files and checking the existence of the file names created
> before with the expected timestamp names. Process Monitor reveals that the
> first checked filename is always missing.
> But isn't that expected behavior, because the first fielname is created with
> "now" in mind, explicitly not in the future, and one second is waited
> afterwards, so the writes are in the future now? This looks like it can't
> ever work ever and it's always only the first file missing.
> Besides that, there some code reduncany in that file, so I decided to create
> this bug to document my findings, clean the code up a bit and deal with the
> failing test afterwards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
