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 <garydgregory@gmail.com> 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 <nicholas@nicholaswilliams.net> 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:



On Sun, Jun 2, 2013 at 10:41 AM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
This is a vote to release Log4j 2.0-beta7, the ninth release of Log4j 2.0.