[EMAIL PROTECTED]: Project logging-log4j-12-tests (in module logging-log4j-12) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project logging-log4j-12-tests has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 4 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - logging-log4j-12-tests : Fast and flexible logging package for Java Full details are available at: http://vmgump.apache.org/gump/public/logging-log4j-12/logging-log4j-12-tests/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Made directory [/srv/gump/public/workspace/logging-log4j-12/tests/classes] -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/logging-log4j-12/logging-log4j-12-tests/gump_work/build_logging-log4j-12_logging-log4j-12-tests.html Work Name: build_logging-log4j-12_logging-log4j-12-tests (Type: Build) Work ended in a state of : Failed Elapsed: 45 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only regression [Working Directory: /srv/gump/public/workspace/logging-log4j-12/tests] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/logging-log4j-12/dist/classes:/srv/gump/public/workspace/logging-log4j-12/tests/classes:/srv/gump/public/workspace/logging-log4j-12/tests/resources:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/junit3.8.1/junit.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-05112007.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-05112007.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jaf-1.1ea/activation.jar - [junit] - --- [junit] [junit] Testcase: combinedTest took 0.314 sec [delete] Deleting: /srv/gump/public/workspace/logging-log4j-12/tests/classes/log4j.xml [delete] Deleting: /srv/gump/public/workspace/logging-log4j-12/tests/classes/log4j.properties SocketServer: [junit] Running org.apache.log4j.net.SocketServerTestCase [junit] Testsuite: org.apache.log4j.net.SocketServerTestCase [junit] Tests run: 8, Failures: 0, Errors: 1, Time elapsed: 12.879 sec [junit] Tests run: 8, Failures: 0, Errors: 1, Time elapsed: 12.879 sec [junit] - Standard Output --- [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] Setting up test case. [junit] Tearing down test case. [junit] - --- [junit] [junit] Testcase: test1 took 1.436 sec [junit] Testcase: test2 took 1.104 sec [junit] Testcase: test3 took 1.059 sec [junit] Testcase: test4 took 1.077 sec [junit] Testcase: test5 took 2.057 sec [junit] Testcase: test6 took 2.037 sec [junit] Testcase: test7 took 2.026 sec [junit] Testcase: test8 took 2.039 sec [junit] Caused an ERROR [junit] [TRACE some7 T7 client-test7 MDC-TEST7 [main] SocketServerTestCase - Message 1] [junit] org.apache.log4j.util.UnexpectedFormatException: [TRACE some7 T7 client-test7 MDC-TEST7 [main] SocketServerTestCase - Message 1] [junit] at org.apache.log4j.util.ControlFilter.filter(ControlFilter.java:43) [junit] at org.apache.log4j.util.Transformer.transform(Transformer.java:42) [junit] at org.apache.log4j.net.SocketServerTestCase.test8(SocketServerTestCase.java:342) [junit] BUILD FAILED /srv/gump/public/workspace/logging-log4j-12/tests/build.xml:324: Test org.apache.log4j.net.SocketServerTestCase failed Total time: 44 seconds
Steps for making a code contribution?
Hi all, I have a layered configurator that I'd like to contribute to log4j, either as a companion or in the core code. I've read through the wiki on http://wiki.apache.org/logging-log4j/ContributingCode and a description and zip of the code is currently here: http://tersesystems.com/code/index?overview=layered_configurator http://tersesystems.com/code/layered-configurator/layered-configurator.zip It's not in patch format for clarity, since it's all new classes. I can package it as a patch easily enough. I'd like a response to tell me if this is of submittable quality, and if not, what changes need to be made? Will. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Alternative Asynchronous Appender
Hi Curt, Thanks for taking the time to reply. I'm afraid I don't fully understand the design decision to enable logging events to be discarded. If a piece of information is sufficiently expendable, then why bother logging it in the first place? I guess the community pressure to incorporate this feature must have been quite strong. Fair enough. On the end-of-lifecycle behaviour, I guess a well-behaved application should use the LogManager to close all appenders cleanly, so you're right, it isn't such an issue. I had been thinking that shutdown hooks might be easier to write with references available to appenders somewhat more readily than for the dispatcher, but again, the LogManager could conceivably be called from a shutdown hook. I have been doing some performance work to see how the AsyncAppender compares with my own implementation. On a single-processor, single-core machine, the AsyncAppender is about 15-20% faster for 10 threads doing nothing but logging (yeah, I know, slightly unrealistic, but I wanted to stress the appender code). I plan to test on a dual-processor, dual-core machine, although upon reflection I expect similar results. The brake is a heavily-contended lock on a home-brewed deque, backed by a LinkedList. Basically the many thrreads that are logging outnumber the single dispatch thread, the net effect being that the buffer fills up and never really empties, further worsening performance since a gate closes at this point to give the dispatch thread opportunity to clear at least one event from the buffer. The solution I'm going to look at is to use Doug Lea's WaitFreeQueue (http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/WaitFreeQueue.java), which should dramatically ease contention due to locks being on the head and tail nodes in the queue, rather than on the whole queue. Since Doug's code is compatible with Java 1.3, there should still be the good compatibility one has with Log4J 1.2.x. If you're interested, I'll let you know how I get on. Best Regards, Simon - Original Message From: Curt Arnold <[EMAIL PROTECTED]> To: Log4J Developers List Sent: Tuesday, 30 October, 2007 9:53:03 PM Subject: Re: Alternative Asynchronous Appender On Oct 30, 2007, at 3:01 PM, Simon Park wrote: > Hi, > > I've posted code (Apache license, Log4J coding standards) that I > hope will offer an alternative to the standard Log4J > AsyncAppender. The design intention is to facilitate reduced > blocking for logging operations, thereby allowing higher throughput > for heavily-threaded applications. More at http:// > simonsiteblog.blogspot.com/2007/10/ive-been-working-on-alternative- > to.html. > > Is this useful? I would welcome feedback. > > Simon > > Haven't looked at the code, but I see your point. The log4j 1.2.14 and later AsyncAppender does delay blocking relative to the prior AsyncAppender (and can skip blocking all together is blocking=false), but when it does block, it will block longer. The GC pause metaphor is pretty right on the mark. The earlier AsyncAppender did pull an event at a time off the buffer, but I found that difficult to do the non-blocking option with that approach. However, you could likely modify the loop at the end of Dispatcher.run to pull one event off the queue for each completed append when the appender is blocking=true and the appenders buffer is already full and blocking. AsyncAppender.close() will joins with the dispatcher thread, essentially blocking until all pending log requests are handled. So I don't think the more reliable logging at end of application is an issue. Obviously, any abnormal termination may result in lost logging requests, but that will be proportional to the buffer size. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
[PROPOSAL] SocketHubAppender change - allow auto port choice
I'd like to propose a change to SocketHubAppender code to allow it automatically choose a free port on the local host if the Port property is configured with 0.This will allow the Zeroconf module to be more useful, and allow simpler configuration for multiple applications on the same host. We have an open feature request (see [1]) to allow this, and the only simple way I can get this to work is to change SocketHubAppender (see attached patch).In summary, I've moved the ServerSocket initialisation from the ServerMonitor.run() method to the ServerMonitor constructor, and when Port=0, check what port is actually configured, and modify the parent SocketHubAppender instance port variable so that getPort() exposes the real port in use.Sub-classes can then inspect that property after the call to super.activateOptions(). This allows ZeroconfSocketHubAppender to broadcast the correct port in use (it would have broadcast 0 without this change; not very useful).This doesn't appear to break any of the log4j unit tests, and I've added unit tests to the Zeroconf module (see second patch) that confirm behaviour. I've also made the Zeroconf module aware of the fact that it might not be using an appropriate log4j version, given that this feature would/might only be present in log4j 1.2.16. Prior versions of log4j will work fine still, but the automatic port configuration won't work (it throws an UnsupportedOperationException if it detects this).cheers,Paul[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=43295 log4j_sockethubappender.patch Description: Binary data log4j_zeroconf.patch Description: Binary data
RE: [PROPOSAL] SocketHubAppender change - allow auto port choice
+1 Scott -Original Message- From: Paul Smith [mailto:[EMAIL PROTECTED] Sent: Mon 11/5/2007 4:55 PM To: Log4J Developers List Subject: [PROPOSAL] SocketHubAppender change - allow auto port choice I'd like to propose a change to SocketHubAppender code to allow it automatically choose a free port on the local host if the Port property is configured with 0. This will allow the Zeroconf module to be more useful, and allow simpler configuration for multiple applications on the same host. We have an open feature request (see [1]) to allow this, and the only simple way I can get this to work is to change SocketHubAppender (see attached patch). In summary, I've moved the ServerSocket initialisation from the ServerMonitor.run() method to the ServerMonitor constructor, and when Port=0, check what port is actually configured, and modify the parent SocketHubAppender instance port variable so that getPort() exposes the real port in use. Sub-classes can then inspect that property after the call to super.activateOptions(). This allows ZeroconfSocketHubAppender to broadcast the correct port in use (it would have broadcast 0 without this change; not very useful). This doesn't appear to break any of the log4j unit tests, and I've added unit tests to the Zeroconf module (see second patch) that confirm behaviour. I've also made the Zeroconf module aware of the fact that it might not be using an appropriate log4j version, given that this feature would/might only be present in log4j 1.2.16. Prior versions of log4j will work fine still, but the automatic port configuration won't work (it throws an UnsupportedOperationException if it detects this). cheers, Paul [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=43295 <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
