Re: Serialization performance
Hi all, This is one of the forgotten gems. Note that the messages dates to back to March 2002! Is anyone interested in integrating this enhancement? If not, I'll do it in the next few days. Here is a reference to Ole Dalgaard's message in the archives: http://marc.theaimsgroup.com/?l=log4j-dev&m=101713440819704&w=2 At 10:19 AM 3/26/2002 +0100, Ole Dalgaard wrote: Hi, I was performance testing the SocketAppender and found it too slow and CPU intensive.So I made some changes to LoggingEvent. LoggingEvent is now Externalizable instead of Serializable. This should be compatible with JDK 1.1 as well. My performance measurements give me 30-50% more throughput. BR Ole Dalgaard -- Ceki Gülcü For log4j documentation consider "The complete log4j manual" ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Serialization performance
Howdy, I'd like to see and reproduce the benchmarks themselves before we commit this change. The reason is that implementing Externalizable places additional responsibility on us not to forget to change this persistence code as the class changes. For everything I use, the normal default serialization is plenty fast enough, so I want to be sure this additional code and burden is worth the effort. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Ceki Gülcü [mailto:[EMAIL PROTECTED] >Sent: Monday, January 05, 2004 12:26 PM >To: Log4J Developers List >Subject: Re: Serialization performance > > >Hi all, > >This is one of the forgotten gems. Note that the messages dates to >back to March 2002! Is anyone interested in integrating this >enhancement? If not, I'll do it in the next few days. > >Here is a reference to Ole Dalgaard's message in the archives: > >http://marc.theaimsgroup.com/?l=log4j-dev&m=101713440819704&w=2 > >At 10:19 AM 3/26/2002 +0100, Ole Dalgaard wrote: >>Hi, >> >>I was performance testing the SocketAppender and found it too slow and >>CPU intensive.So I made some changes to LoggingEvent. >>LoggingEvent is now Externalizable instead of Serializable. This should >>be compatible with JDK 1.1 as well. >>My performance measurements give me 30-50% more throughput. >> >>BR >>Ole Dalgaard > >-- >Ceki Gülcü > > For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Socket & Buffer-based appender
What I would love to have with 1.3 is a SocketHubAppender that has a cyclic buffer of events that are sent to a newly connected client. If there is a problem with an application, connecting to it via, say, Chainsaw, you don't get the context of what WAS going on, just what is happening after connection. It would be nice to be able to connect and receive immediately all the events within the cyclic buffer so you have some context. Does anyone else think this might be useful, or does anyone have another suggestion for how they manage this sort of issue (obviously other than ssh'ing to the app server and greping file logs). cheers, Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Optional Appender Layouts
I have an Appender that can produce serialized logging events or formatted logging events. I wanted to support an optional Layout to determine which output to produce. If a Layout was supplied it would be called to format the event, otherwise the log event would be serialized. However, support for optional layouts seems rather counter intuitive. That is, if an Appender returns false to requiresLayout() a Layout is never passed to the Appender even if one if supplied. On the other hand, if I return true from requiresLayout and the user omits the layout, log4j spits out an error. That's confusing for end users and requires documentation to cover the behaviour. Returning false from requiresLayout() implies that the Appender does not require a layout, not that it doesn't ever use one. I believe it would be more logical for log4j configuration to set an Appender's layout if one is specified, regardless of the response from requiresLayout(). That way, an Appender that doesn't use a Layout won't call it, an Appender that uses an optional Layout can test for it's existence, and an Appender that requires a Layout will continue to function as before. This kind of operation would also apply to other Appenders (like the JMSAppender). That has the capability of handling serialized log events and formatted textual events (in XML, for example). Regards Mark Durman MQ Solutions LLC
