Hi Ceki, I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
You could create your own Appender that extends UnsynchronizedAppenderBase. In the Appender write the events to a Queue, taking care that the Queue is thread-safe (for example, by using one of the Queues in java.util.concurrent). You could then have a separate thread that then does the real work of removing the logging events from the queue and processing them. With this, the only locking that would occur in the application thread would be in adding the LoggingEvent to the queue. However, it would also have to retrieve the caller data and the thread name prior to adding the LoggingEvent to the queue. Actually, now that I think about it, this seems like it would be a great AsynchronousAppender class. It would just need to be configured with the Appender that writes the data. Ralph On May 11, 2009, at 4:54 PM, Greg Flex wrote:
Hi Ceki, I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Great, This looks like it would work for me. The only question I have is what's the "UnsynchronizedAppenderBase" and where can I find some info about it. Thanks Greg. On Mon, May 11, 2009 at 10:48 PM, Ralph Goers <rgoers@apache.org> wrote:
You could create your own Appender that extends UnsynchronizedAppenderBase. In the Appender write the events to a Queue, taking care that the Queue is thread-safe (for example, by using one of the Queues in java.util.concurrent). You could then have a separate thread that then does the real work of removing the logging events from the queue and processing them. With this, the only locking that would occur in the application thread would be in adding the LoggingEvent to the queue. However, it would also have to retrieve the caller data and the thread name prior to adding the LoggingEvent to the queue.
Actually, now that I think about it, this seems like it would be a great AsynchronousAppender class. It would just need to be configured with the Appender that writes the data.
Ralph
On May 11, 2009, at 4:54 PM, Greg Flex wrote:
Hi Ceki,
I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Just for fun I started working on this last night. I hope to have something I can submit in a couple of days. I guess I'll have to create a Jira and attach a patch to it since I don't have commit rights :-( Ralph On May 12, 2009, at 9:32 AM, Greg Flex wrote:
Great, This looks like it would work for me. The only question I have is what's the "UnsynchronizedAppenderBase" and where can I find some info about it. Thanks Greg.
On Mon, May 11, 2009 at 10:48 PM, Ralph Goers <rgoers@apache.org> wrote: You could create your own Appender that extends UnsynchronizedAppenderBase. In the Appender write the events to a Queue, taking care that the Queue is thread-safe (for example, by using one of the Queues in java.util.concurrent). You could then have a separate thread that then does the real work of removing the logging events from the queue and processing them. With this, the only locking that would occur in the application thread would be in adding the LoggingEvent to the queue. However, it would also have to retrieve the caller data and the thread name prior to adding the LoggingEvent to the queue.
Actually, now that I think about it, this seems like it would be a great AsynchronousAppender class. It would just need to be configured with the Appender that writes the data.
Ralph
On May 11, 2009, at 4:54 PM, Greg Flex wrote:
Hi Ceki, I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
If reactivity is what you are looking for, I would suggest that you wrap SocketAppender in an appender which contains a queue (see AsyncAppender in log4j). Place logging events in a queue, and if the queue becomes full, drop new events. Code for computing location information and everything else can be done by invoking methods on LoggingEvent. You don't need to store the logger. Holler if the above is not clear. Greg Flex wrote:
Hi Ceki, I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
------------------------------------------------------------------------
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Hi Ceki, It is (kind of) clear. The only part I have problems with is: "...Place logging events in a queue, and if the queue becomes full, drop new events..." How exactly I'd do this? Do I have to implement some method that "drops new events if the queue becomes full" or there's already something built-in. I know that (From the Log4j Manual: "...If however the queue is full, then AsyncAppender.append() will not return until free space becomes available." ) So if the queue becomes full the dispatcher thread will try to free the space by removing the oldest events from the queue and dispatch them to each attached appender but if the only appender is the SocketAppender that can't process anything at the moment, since there's no comunication to the server, what's going to happend? Some additional explanation and maybe a few lines of code would help. Thanks a lot. Greg. On Wed, May 13, 2009 at 4:52 AM, Ceki Gulcu <ceki@qos.ch> wrote:
If reactivity is what you are looking for, I would suggest that you wrap SocketAppender in an appender which contains a queue (see AsyncAppender in log4j). Place logging events in a queue, and if the queue becomes full, drop new events.
Code for computing location information and everything else can be done by invoking methods on LoggingEvent. You don't need to store the logger.
Holler if the above is not clear.
Greg Flex wrote:
Hi Ceki, I (again) have some questions about log4j. (I guess Logback works the same way....) I was wondering if there's a way to save a "logger object" to a data structure like a queue or something before sending it to some appender. For example: The socket appender will cause the log4j client to lock/freeze if there's no link to the server. I verified it and it does lock the client. I need to deal with this issue so I'd like to store "logger objects" (or something) before they go to the socket or some other appender first. At the moment I have a wrapper around the log4j that when the debug method is called I'm just calling the log4j debug method passing some args etc. so I have: logger.debug("some stuff"); The configuration file does the trick and outputs to the console (at the moment) all the info: the class name, the method name, the line number etc. I'd like to save this info somehow to some object that I can store in a queue or something. How do I retrieve this information programmatically? Is there a way? I know about LoggingEvent object, could I use it and pass the above stated information to its constructor then store it in a queue? Logger gets me for free (like method name etc.) Any suggestion? Thanks a lot. Greg.
------------------------------------------------------------------------
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
Greg Flex wrote:
Hi Ceki, It is (kind of) clear. The only part I have problems with is: "...Place logging events in a queue, and if the queue becomes full, drop new events..." How exactly I'd do this? Do I have to implement some method that "drops new events if the queue becomes full" or there's already something built-in.
You would need to modify AsyncAppender so that instead of blocking, it drops events. I would think that it would be a fairly easy modification to make.
I know that (From the Log4j Manual: "...If however the queue is full, then AsyncAppender.append() will not return until free space becomes available." ) So if the queue becomes full the dispatcher thread will try to free the space by removing the oldest events from the queue and dispatch them to each attached appender but if the only appender is the SocketAppender that can't process anything at the moment, since there's no comunication to the server, what's going to happend?
Events will be dropped. (You can't have your cake and eat it too.) -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Thanks Ceki, This works for me. I tested and asyncAppender does what I wanted. Thanks. I'd like to ask you, however, if there's a way to add at the end of a Throwable information a semicolon or something. I have my file appender configure with PatternLayout as follow: <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d; [%t]; %-5p; %c; %m;%n"/> </layout> As you can see everything is separated by a semicolon. This works for me because I use MS Excel to open my log files. Most of the columns are aligned except for the "exception" one. How can I add a semicolon to the end of exception string so I can use it as a delimiter........ Can this even be done? Thanks Greg. On Wed, May 13, 2009 at 10:37 AM, Ceki Gulcu <ceki@qos.ch> wrote:
Greg Flex wrote:
Hi Ceki, It is (kind of) clear. The only part I have problems with is: "...Place logging events in a queue, and if the queue becomes full, drop new events..." How exactly I'd do this? Do I have to implement some method that "drops new events if the queue becomes full" or there's already something built-in.
You would need to modify AsyncAppender so that instead of blocking, it drops events. I would think that it would be a fairly easy modification to make.
I know that (From the Log4j Manual: "...If however the queue is full, then
AsyncAppender.append() will not return until free space becomes available." ) So if the queue becomes full the dispatcher thread will try to free the space by removing the oldest events from the queue and dispatch them to each attached appender but if the only appender is the SocketAppender that can't process anything at the moment, since there's no comunication to the server, what's going to happend?
Events will be dropped. (You can't have your cake and eat it too.)
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
participants (3)
-
Ceki Gulcu -
Greg Flex -
Ralph Goers