The test really does do what it is supposed to. If you add some code that causes a minor amount of overhead when logging is disabled this test will fail. It is there to detect that kind of serious problem.
Ralph On Jun 3, 2013, at 7:11 PM, Remko Popma wrote: > I agree with Gary that this test needs some work (or should not be part of > the build: a proper performance test needs 5-10 seconds warmup, so these kind > of tests end up taking too long to be run together with the functional JUnit > tests). > > I don't think this test does what it is trying to do. (It won't detect new > performance issues.) > > So I agree with Nick we don't need to treat this as a showstopper. > > Remko > > PS > FWIW, I cannot reproduce the issue on my PC at work. > > PS2 > Cut off lower half of this mail to prevent Apache mailer daemon from bouncing > my message. > > Sent from my iPhone > > On 2013/06/04, at 9:42, Gary Gregory <[email protected]> wrote: > >> Either there is a bug in the code, in the test, or the test should be >> excluded from running as part of the build, in which case, that should be >> documented in the test Javadoc. Something needs to be done IMO. >> >> Gary >> >> >> On Mon, Jun 3, 2013 at 8:32 PM, Nick Williams >> <[email protected]> wrote: >> The three failing tests are in SimplePerfTest, and the error on all of them >> is that the timer was exceeded. This should obviously be looked at either >> way, but it may be okay to release a beta with these tests failing IF they >> are truly only failing because a task took to long, and not because >> something is broken. >> >> That's my opinion, of course. >> >> Nick >> >> >> On Jun 3, 2013, at 6:58 PM, Gary Gregory wrote: >> >>> -1: I see unit test failures: >>> https://people.apache.org/~rgoers/log4j2/log4j-core/surefire-report.html >>> >>> Gary >>> >>> >>> On Sun, Jun 2, 2013 at 10:41 AM, Ralph Goers <[email protected]> >>> wrote: >>> This is a vote to release Log4j 2.0-beta7, the ninth release of Log4j 2.0. >>> >>> >>> >>>
