Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
2013/5/19 Nick Williams nicho...@nicholaswilliams.net: On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote: From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like) Log4j 1 never required a listener to be configured to be shut down properly when an application is undeployed. It did. E.g. this discussion is from March 2004: https://issues.apache.org/bugzilla/show_bug.cgi?id=26372#c2 What bearing does that have on a different logging mechanism? To be fair, Log4j 2 is not a different logging mechanism. It is a new version of Log4j 1. My point was mostly philosophical; it feels wrong to have to configure a listener just to support logging. You can configure the listener from within a library either a) by providing a javax.servlet.ServletContainerInitializer (starting with Servlet 3.0) or b) by configuring it in a TLD file of a tag library (starting with JSP 1.2). It should be possible to do this without a listener. Not easily. Could a `finalize` method be used instead of a shutdown hook/listener? Finalizers should be avoided like the plague. The gyrations the JVM has to go through to handle them result in continual run time impacts, and require at least two GC passes to actually get rid of the objects. The extra performance impact is bad, yes, when you're talking about an object who has many short-lived instances in memory that could be garbage collected regularly. However, when you're talking about a lone singleton instance that is created when the application starts and garbage collected when the application shuts down, I would argue this is not a problem at all. Of course, I'm open to the idea that I could be proven wrong. What I don't know is if it is guaranteed to be called in non-web applications when the JVM just shuts down. Finalizers are not called at JVM termination, since the process exit is expected to release resources automatically. You cannot actually count on a finalizer ever being invoked; it's one of those seemed like a good idea at the time things that is now widely regretted by JVM implementers. After some experimentation, it would appear that it's not so much that finalizers are not called at JVM termination as it is that finalizers are not called if the garbage collector never runs, and the garbage collector isn't guaranteed to run at JVM shutdown. There exists such API as JVM shutdown hooks. An issue with them though is that if there are several hooks, then all of them are started at the same time and run in parallel. When Tomcat is run with JULI it takes care of JULI shutdown (a) disables JULI's own shutdown hook via ClassLoaderLogManager.setUseShutdownHook(false), b) shuts down JULI from its own shutdown hook thread). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRmkekAAoJEBzwKT+lPKRY6uMP/3P72gxh2/wg3Jw5fNllv5PS MX2gow3Fr+RnBXELnD/Mdtlq95j87tzKSiRIMT99FMXXHWXUWW9iHvA7ojye+SGd mKaXJlPQsTGrLH7rRJzXX6CXH7xW2mQ3DEYCLQ/97pktn8SgO324BWz2MvJGGtDx FwVB+rny0HS1JROADLFgzkLfNRRpnR7uvdUqE6G/vY85sbFBq7tWo6k9s6FdWvev TqSo0WxbN7goHPcJH5mwcq8MATztRunOTMev6XrG7myqjs/wD5FGOcVyAM01j9qW QgAwdAVd8z9Gkpw1c8FLb5BXKd6YwfjaS2DxDsojbd0MLHIgaVG8jqL8C4/Tdyxv 8IN9fubTKfWIKzj7uQCNGcXZWuAhAj1GWiK1GADZiuMm9Xj9Pdo1z1gqewoOPYqQ tJnH69+62AcAU9dr/78Y7NvVqtor+fF49o1qzMqkEzT14x2S0fjhk79SmS3gDlyo GBInETKqKBLycKpwKplcOoFRlXopXwSCsnpZmcuJQP2j2DuZHzwqoWYK5UgZaidu xFRdTKmvGdX3UcksUDgxTjUQrtKUsqK1XxlOlHnbLYYuob2K21d6KTnLkDj3Sr+p I5ZErRUX36j25jafGtDHZUv7dDA0QKA7ygrn4xqh1rSiewfz85NcxvZGCIi6XKV8 OxLz5ev4cxVMBGq4x2MC =uLGt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 12:48 PM, Nick Williams wrote: On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. It's different, but it's the same. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Right. What I'm saying is that you should take full control over the initialization (and destruction) of the logging system. Your ServletContextListeners should be invoked before your servlet classes are loader. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... You act like a ServletContextListener is some evil hack that should be avoided at all costs. Instead, it's exactly the right mechanism to do what you are trying to do: configure something at webapp launch and de-configure it when the webapp is stopped. Some things just aren't appropriate to do with @Annotations. Sorry. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRmoCoAAoJEBzwKT+lPKRYEkgQALHbPr3SPqsDmIdYWa4Cb2VF gZubG1MRsupGK2Kqlsq4HDTQMYjM5Twyig8McaVaxmqeUn9pWnSm2VgJCqeP0D8n kGAsu9LZFoyEqkpO8+6xHwtvkPNCbj3qMrMRuqgXuV11VrlUL4N1q8pMYK3m0c5l 8iytqXUHk7R5MPjwZS4e3zC2jGnMhiIENWwfZa/ulNhmWCpLcC5tIU3Ka1s4VoFT 7S92vWG0CoveGkfVbtl9G9LPrdEYig0PFXeCvALFVE4Ff4rWP/jJiN+fE3GeTBSI rR4eWpgvHM5BwvgFvSB6dzkaSQJaqX0GV1CJUdR3lvzh6jtRkeAlMzdA7DFFfQD3 pY/J/B+0ZeJzHDLrlYa528NaufA46vbhIr3l/fQqdMO5nHJePzv6bQIUOFu9zcHO chwXohDvF9rQDAQE1H/DeVuDy7izQqn1k25PbsKDa/Ju86yk4V+ak/AcSzqKIm9o zPLvHN4v3qPJ5QXElrX8aeXi7HUZEHjsVzvQmWpqpWd1aelNkn6FMSbrF59XpYkh hTGXYz91gIbpshnwxpE5GQVv/1GwOFICi/HsT54ru0rEKmIDmTu9lu7ByzKp3Idv U5dxMRUVzx+pJ2hfq2Mcqdy/LbYr9SX1uC3njtwdu2yuWWkbgC/Vnrns1hlDdpw/ +X1XT/+ZnfqzAQ66rger =w+w1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On May 20, 2013, at 2:59 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 12:48 PM, Nick Williams wrote: On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. It's different, but it's the same. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Right. What I'm saying is that you should take full control over the initialization (and destruction) of the logging system. Your ServletContextListeners should be invoked before your servlet classes are loader. And I'm saying you shouldn't /have/ to. It should just work without you having to do much thinking. See below. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... You act like a ServletContextListener is some evil hack that should be avoided at all costs. Instead, it's exactly the right mechanism to do what you are trying to do: configure something at webapp launch and de-configure it when the webapp is stopped. Not what I'm saying at all. I love listeners. They are extremely helpful, and I use them all the time. What I'm saying is that the concept of logging, philosophically, is supposed to be as unobtrusive as possible. Something you don't really have to think about how exactly it works; you just know to get a logger and put logging statements in your code and things just work. The act of having to set up a listener to initialize and deinitialize logging, to me, seems like more than Log4j users should have to worry about. Perhaps just as importantly, Log4j 1 worked without a listener to initialize/deinitialize, so this is yet again one more thing users are going to have to do to switch from Log4j 1 to Log4j 2. Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the listener behind-the-scenes without the user even knowing. That's much more acceptable in my book. Users of Servlet 2.5 will still have to declare them manually, but I think they will probably be the minority users. So with a little more polishing of the Log4j 2 source code we can make this a little better. I just wish there was a solution that would work for both standalone applications /and/ web applications to initialize and deinitialize Log4j correctly without any users (including Servlet 2.5 users) having to think about it. Nick - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 4:10 PM, Nick Williams wrote: On May 20, 2013, at 2:59 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 12:48 PM, Nick Williams wrote: On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. It's different, but it's the same. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Right. What I'm saying is that you should take full control over the initialization (and destruction) of the logging system. Your ServletContextListeners should be invoked before your servlet classes are loader. And I'm saying you shouldn't /have/ to. It should just work without you having to do much thinking. See below. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... You act like a ServletContextListener is some evil hack that should be avoided at all costs. Instead, it's exactly the right mechanism to do what you are trying to do: configure something at webapp launch and de-configure it when the webapp is stopped. Not what I'm saying at all. I love listeners. They are extremely helpful, and I use them all the time. What I'm saying is that the concept of logging, philosophically, is supposed to be as unobtrusive as possible. Something you don't really have to think about how exactly it works; you just know to get a logger and put logging statements in your code and things just work. The act of having to set up a listener to initialize and deinitialize logging, to me, seems like more than Log4j users should have to worry about. Perhaps just as importantly, Log4j 1 worked without a listener to initialize/deinitialize, so this is yet again one more thing users are going to have to do to switch from Log4j 1 to Log4j 2. That's like saying that aspect-oriented programming should just work without having to run the AOP compiler against the code, first. This at least used to be a problem in log4j 1 as well: you had to call LogManager.shutdown in order to free all the resources, flush all the buffers, etc. when your webapp unloaded, otherwise you ran the risk of pinning the old webapp's ClassLoader, etc. in memory. The only way to run LogManager.shutdown() on webapp unload is to configure a ServletContextListener. Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the listener behind-the-scenes without the user even knowing. That's much more acceptable in my book. While I agree, it increases the amount of magic that I generally prefer to keep to a minimum. I know I'm apparently an old guy who just doesn't get it, but I honestly prefer explicit configuration to auto-configuration. You can diagnose problems much more easily with explicit configuration than by attaching a debugger and stepping-through the entire bootstrap process to figure out wtf is going on. Users of Servlet 2.5 will still have to declare them manually, but I think they will probably be the minority users. Ha ha ha. Don't you see the posts from people trying to figure out how to move their Tomcat 3.x installations to a new Windows 2000 server? Again, I'm a apparently a dinosaur, but I don't have a single servlet-3.0 webapp deployed in production anywhere. Not even in testing. So with a little more polishing of the Log4j 2 source code we can make this a little better. I just wish there was a solution that would work for both standalone applications /and/ web applications to initialize and deinitialize Log4j correctly without any users (including Servlet 2.5 users) having to think about it. The solution is to have a magic annotation-processor running all the time in the JVM, right? Isn't that what OSGi is for? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools -
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On May 20, 2013, at 4:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 4:10 PM, Nick Williams wrote: On May 20, 2013, at 2:59 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 12:48 PM, Nick Williams wrote: On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. It's different, but it's the same. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Right. What I'm saying is that you should take full control over the initialization (and destruction) of the logging system. Your ServletContextListeners should be invoked before your servlet classes are loader. And I'm saying you shouldn't /have/ to. It should just work without you having to do much thinking. See below. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... You act like a ServletContextListener is some evil hack that should be avoided at all costs. Instead, it's exactly the right mechanism to do what you are trying to do: configure something at webapp launch and de-configure it when the webapp is stopped. Not what I'm saying at all. I love listeners. They are extremely helpful, and I use them all the time. What I'm saying is that the concept of logging, philosophically, is supposed to be as unobtrusive as possible. Something you don't really have to think about how exactly it works; you just know to get a logger and put logging statements in your code and things just work. The act of having to set up a listener to initialize and deinitialize logging, to me, seems like more than Log4j users should have to worry about. Perhaps just as importantly, Log4j 1 worked without a listener to initialize/deinitialize, so this is yet again one more thing users are going to have to do to switch from Log4j 1 to Log4j 2. That's like saying that aspect-oriented programming should just work without having to run the AOP compiler against the code, first. This at least used to be a problem in log4j 1 as well: you had to call LogManager.shutdown in order to free all the resources, flush all the buffers, etc. when your webapp unloaded, otherwise you ran the risk of pinning the old webapp's ClassLoader, etc. in memory. The only way to run LogManager.shutdown() on webapp unload is to configure a ServletContextListener. Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the listener behind-the-scenes without the user even knowing. That's much more acceptable in my book. While I agree, it increases the amount of magic that I generally prefer to keep to a minimum. I know I'm apparently an old guy who just doesn't get it, but I honestly prefer explicit configuration to auto-configuration. You can diagnose problems much more easily with explicit configuration than by attaching a debugger and stepping-through the entire bootstrap process to figure out wtf is going on. Users of Servlet 2.5 will still have to declare them manually, but I think they will probably be the minority users. Ha ha ha. Don't you see the posts from people trying to figure out how to move their Tomcat 3.x installations to a new Windows 2000 server? Again, I'm a apparently a dinosaur, but I don't have a single servlet-3.0 webapp deployed in production anywhere. Not even in testing. Oh, I see the posts. I just figure if they're that far behind they won't be using Log4j 2 for at least another 10 years. Nick So with a little more polishing of the Log4j 2 source code we can make this a little better. I just wish there was a solution that would work for both standalone applications /and/ web applications to initialize and deinitialize Log4j correctly without any users (including Servlet 2.5 users) having to think about it. The
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On 5/20/2013 2:45 PM, Nick Williams wrote: On May 20, 2013, at 4:39 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 4:10 PM, Nick Williams wrote: On May 20, 2013, at 2:59 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/20/13 12:48 PM, Nick Williams wrote: On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nick, On 5/19/13 11:25 AM, Nick Williams wrote: Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... Do you initialize your logging system in a ServletContextListener (or similar)? If so, then you should destroy it at the same level. If you aren't initializing your logging system in a ServletContextListener... then how are you initializing it? Long ago, I abandoned log4j's auto-initialization primarily because it sometimes guesses wrong. First, remember that this is Log4j 2, so things are obviously different. It's different, but it's the same. Log4j initializes with the first call to LogManager#getLogger(), whenever that occurs. In my case loggers are static, so it happens when the classes are initialized. In the specific case of the replication project attached to the issue, it happens on the first request to the only Servlet in the application. Right. What I'm saying is that you should take full control over the initialization (and destruction) of the logging system. Your ServletContextListeners should be invoked before your servlet classes are loader. And I'm saying you shouldn't /have/ to. It should just work without you having to do much thinking. See below. Unfortunately, I've just about given up on it being possible to make logging work right without a ServletContextListener. Man oh man did I want to avoid that... You act like a ServletContextListener is some evil hack that should be avoided at all costs. Instead, it's exactly the right mechanism to do what you are trying to do: configure something at webapp launch and de-configure it when the webapp is stopped. Not what I'm saying at all. I love listeners. They are extremely helpful, and I use them all the time. What I'm saying is that the concept of logging, philosophically, is supposed to be as unobtrusive as possible. Something you don't really have to think about how exactly it works; you just know to get a logger and put logging statements in your code and things just work. The act of having to set up a listener to initialize and deinitialize logging, to me, seems like more than Log4j users should have to worry about. Perhaps just as importantly, Log4j 1 worked without a listener to initialize/deinitialize, so this is yet again one more thing users are going to have to do to switch from Log4j 1 to Log4j 2. That's like saying that aspect-oriented programming should just work without having to run the AOP compiler against the code, first. This at least used to be a problem in log4j 1 as well: you had to call LogManager.shutdown in order to free all the resources, flush all the buffers, etc. when your webapp unloaded, otherwise you ran the risk of pinning the old webapp's ClassLoader, etc. in memory. The only way to run LogManager.shutdown() on webapp unload is to configure a ServletContextListener. Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the listener behind-the-scenes without the user even knowing. That's much more acceptable in my book. While I agree, it increases the amount of magic that I generally prefer to keep to a minimum. I know I'm apparently an old guy who just doesn't get it, but I honestly prefer explicit configuration to auto-configuration. You can diagnose problems much more easily with explicit configuration than by attaching a debugger and stepping-through the entire bootstrap process to figure out wtf is going on. Users of Servlet 2.5 will still have to declare them manually, but I think they will probably be the minority users. Ha ha ha. Don't you see the posts from people trying to figure out how to move their Tomcat 3.x installations to a new Windows 2000 server? Again, I'm a apparently a dinosaur, but I don't have a single servlet-3.0 webapp deployed in production anywhere. Not even in testing. Oh, I see the posts. I just figure if they're that far behind they won't be using Log4j 2 for at least another 10 years. Nick Hopefully sometime this year (currently porting one of those types of applications). I do have a Maven artifact with some utility listeners that I make use of (including a log4j listener). I just add the dependency, modify the web.xml accordingly, and I'm good to go. Yes, annotations would make things a little less cumbersome. However, I still like seeing everything. Maybe once I get a
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On 19/05/2013 05:57, Nick Williams wrote: Can one of the very knowledgeable developers that have been discussing memory leaks in the last few days (re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug [1]? Log4j 2 appears to be registering a shutdown hook that, I believe, will result in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect it (which might be a separate Tomcat bug, assuming I'm right that it's a memory leak). I don't know nearly as much about class loaders and memory leaks in a web application as some of the guys I've read talking on here the last few days, and it would be helpful for us to get the knowledgeable opinion of one or more Tomcat developers about how to solve this. It looks like Ralph has already answered this [2]. If log4j2 is initialised by the webapp, it needs to be shutdown by the webapp. (Note: I don't normally post to both lists, but since the memory leak topic was occurring on the user's list, and I also wanted to get the attention of as many developers as possible, I made an exception this time.) No matter how important you think your issue is, please do not cross post. As a general guide, if you aren't sure, use the users list. The committers are all active or lurking here so they will all see it and will move the discussion to the dev list of necessary. Mark [1] https://issues.apache.org/jira/browse/LOG4J2-223 [2] https://issues.apache.org/jira/browse/LOG4J2-223?focusedCommentId=13661501page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13661501 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On May 19, 2013, at 3:33 AM, Mark Thomas wrote: On 19/05/2013 05:57, Nick Williams wrote: Can one of the very knowledgeable developers that have been discussing memory leaks in the last few days (re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug [1]? Log4j 2 appears to be registering a shutdown hook that, I believe, will result in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect it (which might be a separate Tomcat bug, assuming I'm right that it's a memory leak). I don't know nearly as much about class loaders and memory leaks in a web application as some of the guys I've read talking on here the last few days, and it would be helpful for us to get the knowledgeable opinion of one or more Tomcat developers about how to solve this. It looks like Ralph has already answered this [2]. If log4j2 is initialised by the webapp, it needs to be shutdown by the webapp. Ralph may have responded, but I don't believe it's the right answer. Log4j 1 never required a listener to be configured to be shut down properly when an application is undeployed. It should be possible to do this without a listener. Just a thought, is there a way to detect if a ClassLoader is being shut down/unloaded? Could a `finalize` method be used instead of a shutdown hook/listener? I'm fairly confident the finalize method would always be called when the application is undeployed (though I could be wrong). What I don't know is if it is guaranteed to be called in non-web applications when the JVM just shuts down. (Note: I don't normally post to both lists, but since the memory leak topic was occurring on the user's list, and I also wanted to get the attention of as many developers as possible, I made an exception this time.) No matter how important you think your issue is, please do not cross post. As a general guide, if you aren't sure, use the users list. The committers are all active or lurking here so they will all see it and will move the discussion to the dev list of necessary. My apologies. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like) Log4j 1 never required a listener to be configured to be shut down properly when an application is undeployed. What bearing does that have on a different logging mechanism? It should be possible to do this without a listener. Not easily. Could a `finalize` method be used instead of a shutdown hook/listener? Finalizers should be avoided like the plague. The gyrations the JVM has to go through to handle them result in continual run time impacts, and require at least two GC passes to actually get rid of the objects. What I don't know is if it is guaranteed to be called in non-web applications when the JVM just shuts down. Finalizers are not called at JVM termination, since the process exit is expected to release resources automatically. You cannot actually count on a finalizer ever being invoked; it's one of those seemed like a good idea at the time things that is now widely regretted by JVM implementers. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote: From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like) Log4j 1 never required a listener to be configured to be shut down properly when an application is undeployed. What bearing does that have on a different logging mechanism? To be fair, Log4j 2 is not a different logging mechanism. It is a new version of Log4j 1. My point was mostly philosophical; it feels wrong to have to configure a listener just to support logging. It should be possible to do this without a listener. Not easily. Could a `finalize` method be used instead of a shutdown hook/listener? Finalizers should be avoided like the plague. The gyrations the JVM has to go through to handle them result in continual run time impacts, and require at least two GC passes to actually get rid of the objects. The extra performance impact is bad, yes, when you're talking about an object who has many short-lived instances in memory that could be garbage collected regularly. However, when you're talking about a lone singleton instance that is created when the application starts and garbage collected when the application shuts down, I would argue this is not a problem at all. Of course, I'm open to the idea that I could be proven wrong. What I don't know is if it is guaranteed to be called in non-web applications when the JVM just shuts down. Finalizers are not called at JVM termination, since the process exit is expected to release resources automatically. You cannot actually count on a finalizer ever being invoked; it's one of those seemed like a good idea at the time things that is now widely regretted by JVM implementers. After some experimentation, it would appear that it's not so much that finalizers are not called at JVM termination as it is that finalizers are not called if the garbage collector never runs, and the garbage collector isn't guaranteed to run at JVM shutdown. However, if you call System.gc() right before the JVM shuts down, finalizers appear to run every time. Unfortunately, requiring users to call System.gc() before shutdown for logging to work properly is no better than requiring users to register a listener in a web application for logging to work properly. Surely there's a better way... While I do not disagree that finalizers are very often misused, they are not without their uses. I find it hard to believe that the Sun JRE 6 source code would contain 50 uses of finalizers if they should never be used. You'd think if they regretted creating the method so much they would deprecate it and/or document clearly that it's best to never implement a finalizer, but the documentation for finalizers makes no such assertion, even in the latest Java 8. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)
Can one of the very knowledgeable developers that have been discussing memory leaks in the last few days (re: Possible false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug [1]? Log4j 2 appears to be registering a shutdown hook that, I believe, will result in a memory leak in Tomcat. The JreMemoryLeakPreventionListener does not detect it (which might be a separate Tomcat bug, assuming I'm right that it's a memory leak). I don't know nearly as much about class loaders and memory leaks in a web application as some of the guys I've read talking on here the last few days, and it would be helpful for us to get the knowledgeable opinion of one or more Tomcat developers about how to solve this. Thanks, Nick [1] https://issues.apache.org/jira/browse/LOG4J2-223 (Note: I don't normally post to both lists, but since the memory leak topic was occurring on the user's list, and I also wanted to get the attention of as many developers as possible, I made an exception this time.)
