That looks pretty easy to do. However, I'd prefer that the stack trace also show locks held just as the JVM stack trace does. I don't know how to do that. Do you?
Ralph On Sep 18, 2011, at 3:01 PM, Joern Huxhorn wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
