Sorry, I was confused and mixed something up... I *planned* to implement a thread-specific sequence number but never did so. I also considered logging the ThreadGroup-hierarchy but didn't do so, yet, because of the expected performance impact.
Which reminds me, completely off-topic, of another idea concerning a custom Message implementation: A ThreadDumpMessage that would not get any parameter at all and would consist of a ThreadDump if it is actually logged, including the ThreadGroup info etc.. This would have helped me immensely in the past. Instead, I had to trigger thread dumps via SIG_QUIT at a random points of execution. Such a Message wouldn't be used in production under normal circumstances but could be enabled in case of strange concurrency issues... Joern. On 18.09.2011, at 17:44, Scott Deboy wrote: > Chainsaw does a similar thing by adding event properties when the event is > received. It does this regardless of which Receiver received the event. > > > On Sep 18, 2011, at 4:54 AM, Joern Huxhorn <jhuxh...@googlemail.com> wrote: > >> >> On 17.09.2011, at 23:42, Ralph Goers wrote: >> >>> >>> On Sep 17, 2011, at 1:43 PM, Joern Huxhorn wrote: >>> >>>> >>>> On 17.09.2011, at 21:26, Ralph Goers wrote: >>>> >>>>> >>>>> On Sep 17, 2011, at 11:40 AM, Joern Huxhorn wrote: >>>>> >>>>>> >>>>>> On 17.09.2011, at 18:47, John Vasileff wrote: >>>>>> >>>>>>> >>>>>>> On Sep 17, 2011, at 8:53 AM, Joern Huxhorn wrote: >>>>>>> >>>>>>> Interesting point on serialization. When would you see serialization >>>>>>> happening? Is this primarily for appenders? >>>>>>> >>>>>> >>>>>> SocketAppender is using serialization. Since I'm the author of Lilith ( >>>>>> http://lilith.huxhorn.de/ ) I tend to focus on stuff like that. >>>>> >>>>> Actually, in Log4j 2.0 SocketAppender uses a Layout. The default Layout >>>>> is SerializedLayout. If you want to use a LillithLayout you would be free >>>>> to do so. >>>>> >>>>>> >>>>>> This is also the reason for the differentiation between the Message >>>>>> instance and the (laziliy) formatted message string. A SocketAppender >>>>>> does not have any need for a formatted message. It is perfectly valid to >>>>>> skip the formatting entirely and simply transmit the message pattern and >>>>>> the message parameters (as Strings) to safe some CPU in the logged >>>>>> application. >>>>> >>>>> I disagree. The SocketAppender should be able to interact with something >>>>> that accepts Thrift, Avro, Hession or other serialization protocols or >>>>> even the RFC 5424 format. However, in cases where the event is >>>>> serialized into a format where the LogEvent will be recreated on the >>>>> other side of the socket connection, I agree that formatting the message >>>>> on the sender's side is not required. >>>> >>>> Your SocketAppender is obviously much improved compared to the Logback >>>> one. Having the actual serialization mechanism pluggable is a very good >>>> idea. >>>> Nevertheless, I assume that simple serialization would be the "reference >>>> implementation". I'd, of course, hook in my protobuf implementation... >>> >>> If you provide a ProtobufLayout I'd happily include it - although I'd make >>> the protobuf artifacts optional dependencies as I did for Flume. >> >> Well, I could give you my protobuf but I'm not sure if it makes sense to add >> it to Log4J directly. >> >> It contains more (optional) fields than Log4J will provide, partially since >> populating those fields has a performance impact. JUL has an event id by >> Thread but providing them would require ThreadLocal handling of the counter, >> i.e. reduces performance for very little additional info. Who would really >> use this information? >> I keep those infos in Lilith so it can import/receive events lossless but I >> don't think that Log4J should support them. >> >> So it's probably best to keep this out of the Log4J codebase. If we add it >> then we'd have to coordinate future extension. If we leave it out as a >> third-party implementation of the SocketAppender layout then I can just >> change it as needed. >> >> Joern. >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
