AW: Java Agent and Tomcat shutdown
Hello Peter, > -Ursprüngliche Nachricht- > Von: l...@kreuser.name > Gesendet: Donnerstag, 11. Mai 2023 16:16 > An: Tomcat Users List > Betreff: Re: Java Agent and Tomcat shutdown > > Hi Thomas > > > Am 11.05.2023 um 16:05 schrieb Thomas Hoffmann (Speed4Trade GmbH) > : > > > > Hello, > > > > we are using a java agent to start a listening process (JMX proxy). > > > > The systemd file for tomcat looks like (snippet): > > JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar > > -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001 > > > I do think that setting JAVA_OPTS is triggering this behavior: EVERY java > process contains this rmi server with this conflicting port. > > The way to go is using CATALINA_OPTS. The options go only into the start- > process... You are completely right. Everything makes sense now 😊 Thanks for the quick help! Much appreciated! > HTH > > Peter > > > ExecStart=/opt/apache-tomcat/bin/catalina.sh run > > ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60 > > > > When starting the service, everything works fine and the java agent is > accessible via the opened port 15000. > > > > However, when stopping tomcat, it seems that a java process is started and > tries to open the same port again: > > 2670]: Exception in thread "main" > > java.lang.reflect.InvocationTargetException > >at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > >at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethod > AccessorImpl.java:77) > >at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin > gMethodAccessorImpl.java:43) > >at java.base/java.lang.reflect.Method.invoke(Method.java:568) > >at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(In > strumentationImpl.java:493) > >at > > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPre > > main(InstrumentationImpl.java:503) > > Caused by: java.rmi.server.ExportException: Port already in use: 15000; > nested exception is: > >java.net.BindException: Address already in use > >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346) > >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:2 > 43) > >at > java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415 > ) > >at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) > >at > java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:2 > 35) > >at > > java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223) > >at > > java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:208) > >at > java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:20 > 3) > >at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33) > >... 6 more > > Caused by: java.net.BindException: Address already in use > >at java.base/sun.nio.ch.Net.bind0(Native Method) > >at java.base/sun.nio.ch.Net.bind(Net.java:555) > >at java.base/sun.nio.ch.Net.bind(Net.java:544) > >at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) > >at java.base/java.net.ServerSocket.bind(ServerSocket.java:388) > >at java.base/java.net.ServerSocket.(ServerSocket.java:274) > >at java.base/java.net.ServerSocket.(ServerSocket.java:167) > >at > java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCP > DirectSocketFactory.java:45) > >at > java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java > :673) > >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) > >... 14 more > > *** java.lang.instrument ASSERTION FAILED ***: "result" with message > > agent load/premain call failed at > > src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422 > > > > The premain method is entered again and of course the port is already used. > > Is there a way to stop tomcat without re-entering the java agent? > > Using shutdown.sh shows the same problem. > > > > Thanks in advance! > > Thomas > > > > - > > 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
Re: Java Agent and Tomcat shutdown
Hi Thomas > Am 11.05.2023 um 16:05 schrieb Thomas Hoffmann (Speed4Trade GmbH) > : > > Hello, > > we are using a java agent to start a listening process (JMX proxy). > > The systemd file for tomcat looks like (snippet): > JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar > -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001 I do think that setting JAVA_OPTS is triggering this behavior: EVERY java process contains this rmi server with this conflicting port. The way to go is using CATALINA_OPTS. The options go only into the start-process... HTH Peter > ExecStart=/opt/apache-tomcat/bin/catalina.sh run > ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60 > > When starting the service, everything works fine and the java agent is > accessible via the opened port 15000. > > However, when stopping tomcat, it seems that a java process is started and > tries to open the same port again: > 2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException >at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) >at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.base/java.lang.reflect.Method.invoke(Method.java:568) >at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:493) >at > java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503) > Caused by: java.rmi.server.ExportException: Port already in use: 15000; > nested exception is: >java.net.BindException: Address already in use >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346) >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243) >at > java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415) >at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) >at > java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:235) >at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223) >at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:208) >at > java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203) >at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33) >... 6 more > Caused by: java.net.BindException: Address already in use >at java.base/sun.nio.ch.Net.bind0(Native Method) >at java.base/sun.nio.ch.Net.bind(Net.java:555) >at java.base/sun.nio.ch.Net.bind(Net.java:544) >at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) >at java.base/java.net.ServerSocket.bind(ServerSocket.java:388) >at java.base/java.net.ServerSocket.(ServerSocket.java:274) >at java.base/java.net.ServerSocket.(ServerSocket.java:167) >at > java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) >at > java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:673) >at > java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) >... 14 more > *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent > load/premain call failed at > src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422 > > The premain method is entered again and of course the port is already used. > Is there a way to stop tomcat without re-entering the java agent? > Using shutdown.sh shows the same problem. > > Thanks in advance! > Thomas > > - > 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
Java Agent and Tomcat shutdown
Hello, we are using a java agent to start a listening process (JMX proxy). The systemd file for tomcat looks like (snippet): JAVA_OPTS=... -javaagent:/opt/runtime/jmxagent/jmxagent.jar -Dorg.goktay.rmiregistry.port=15000 -Dorg.goktay.rmiserver.port=15001 ExecStart=/opt/apache-tomcat/bin/catalina.sh run ExecStop=/opt/apache-tomcat/bin/catalina.sh stop 60 When starting the service, everything works fine and the java agent is accessible via the opened port 15000. However, when stopping tomcat, it seems that a java process is started and tries to open the same port again: 2670]: Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:493) at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:503) Caused by: java.rmi.server.ExportException: Port already in use: 15000; nested exception is: java.net.BindException: Address already in use at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346) at java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:415) at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) at java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:235) at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:223) at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:208) at java.rmi/java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:203) at org.goktay.jmx.JMXAgent.premain(JMXAgent.java:33) ... 6 more Caused by: java.net.BindException: Address already in use at java.base/sun.nio.ch.Net.bind0(Native Method) at java.base/sun.nio.ch.Net.bind(Net.java:555) at java.base/sun.nio.ch.Net.bind(Net.java:544) at java.base/sun.nio.ch.NioSocketImpl.bind(NioSocketImpl.java:643) at java.base/java.net.ServerSocket.bind(ServerSocket.java:388) at java.base/java.net.ServerSocket.(ServerSocket.java:274) at java.base/java.net.ServerSocket.(ServerSocket.java:167) at java.rmi/sun.rmi.transport.tcp.TCPDirectSocketFactory.createServerSocket(TCPDirectSocketFactory.java:45) at java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:673) at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335) ... 14 more *** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at src/java.instrument/share/native/libinstrument/JPLISAgent.c line: 422 The premain method is entered again and of course the port is already used. Is there a way to stop tomcat without re-entering the java agent? Using shutdown.sh shows the same problem. Thanks in advance! Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Ensuring clean Tomcat shutdown
Thank you Luis for the inputs. Yes, we do use the listeners and "contextDestroyed" and clean up the resources. But with many team members working, wanted to have some automated check to ensure cleaning up wasn't missed. Thanks, Amit -Original Message- From: Luis Rodríguez Fernández Sent: Monday, June 8, 2020 3:42 AM To: Tomcat Users List Subject: [EXTERNAL] Re: Ensuring clean Tomcat shutdown Hello Amit, Well, your approach will work. Personally, I do not like very much to parse logs. We, for instance, in our tomcat instances we provide an application that queries the status of the deployed apps, see below. If you have control in the code of "AAA" application I would suggest you to implement contextDestroyed [1] and make a clean up of your resources (db connections, etc.) The catalina stop works beautifully in linux. I must to confess that it is being a while since I do not have a look at the catalina.bat one :) Hope it helps, Luis [1] https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/ServletContextListener.html#contextDestroyed-javax.servlet.ServletContextEvent- // From Registry javadocs: It provides methods to create and // manipulate model mbeans and simplify their use.protected transient Registry registry;private static final String ALL_WEB_MODULES_QRY = "*:j2eeType=WebModule,*"; // Get all modules (contexts) // Retrieve the MBean serverregistry = Registry.getRegistry(null, null);mBeanServer = Registry.getRegistry(null, null).getMBeanServer();Set objectNames = mBeanServer.queryNames(new ObjectName(ALL_WEB_MODULES_QRY), null); El dom., 7 jun. 2020 a las 3:50, Amit Pande () escribió: > When the application does not clean up the resources, during shutdown, > we see WARNINGs in Catalina logs: > > "WARNING [Catalina-utility-21] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThread > s The web application [AAA] appears to have started a thread named > [BBB] but has failed to stop it. This is very likely to create a > memory leak. Stack trace of thread:" > > I wanted to ensure a clean Tomcat shutdown and thinking of an > automated > test: > > 1. Stop Tomcat > 2. Parse/grep Catalina logs for warnings like above > 3. If found, fail the test, if not pass > > Is there a better/elegant way to achieve this? E.g. using life cycle > listeners? > > Also, the catalina stop option (where a kill is attempted after n > seconds are passed) works for all platforms, is my understanding correct? > > Thanks, > Amit > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
Re: Ensuring clean Tomcat shutdown
Hello Amit, Well, your approach will work. Personally, I do not like very much to parse logs. We, for instance, in our tomcat instances we provide an application that queries the status of the deployed apps, see below. If you have control in the code of "AAA" application I would suggest you to implement contextDestroyed [1] and make a clean up of your resources (db connections, etc.) The catalina stop works beautifully in linux. I must to confess that it is being a while since I do not have a look at the catalina.bat one :) Hope it helps, Luis [1] https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/ServletContextListener.html#contextDestroyed-javax.servlet.ServletContextEvent- // From Registry javadocs: It provides methods to create and // manipulate model mbeans and simplify their use.protected transient Registry registry;private static final String ALL_WEB_MODULES_QRY = "*:j2eeType=WebModule,*"; // Get all modules (contexts) // Retrieve the MBean serverregistry = Registry.getRegistry(null, null);mBeanServer = Registry.getRegistry(null, null).getMBeanServer();Set objectNames = mBeanServer.queryNames(new ObjectName(ALL_WEB_MODULES_QRY), null); El dom., 7 jun. 2020 a las 3:50, Amit Pande () escribió: > When the application does not clean up the resources, during shutdown, we > see WARNINGs in Catalina logs: > > "WARNING [Catalina-utility-21] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The > web application [AAA] appears to have started a thread named [BBB] but has > failed to stop it. This is very likely to create a memory leak. Stack trace > of thread:" > > I wanted to ensure a clean Tomcat shutdown and thinking of an automated > test: > > 1. Stop Tomcat > 2. Parse/grep Catalina logs for warnings like above > 3. If found, fail the test, if not pass > > Is there a better/elegant way to achieve this? E.g. using life cycle > listeners? > > Also, the catalina stop option (where a kill is attempted after n > seconds are passed) works for all platforms, is my understanding correct? > > Thanks, > Amit > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
Ensuring clean Tomcat shutdown
When the application does not clean up the resources, during shutdown, we see WARNINGs in Catalina logs: "WARNING [Catalina-utility-21] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [AAA] appears to have started a thread named [BBB] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:" I wanted to ensure a clean Tomcat shutdown and thinking of an automated test: 1. Stop Tomcat 2. Parse/grep Catalina logs for warnings like above 3. If found, fail the test, if not pass Is there a better/elegant way to achieve this? E.g. using life cycle listeners? Also, the catalina stop option (where a kill is attempted after n seconds are passed) works for all platforms, is my understanding correct? Thanks, Amit
Re: Tomcat shutdown password complexity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roger, On 5/9/20 20:45, Roger Marquis wrote: > calder wrote: >> We've never had occasion to use the password, because we disable >> shutdown (the better option). > > Never did understand this Tomcat oddity. What other application > is configured by default to open a tcp socket just to receive a > shutdown command? Then there the default password, both of which, > IMO, warrant a CVE. > > Would be far better i.e. more standards-based and secure, if the > socket were an option and the default stop method was, like > everything else, to use rc/init/service/systemctl/whatever. > > OTOH, a quick look at the startup, shutdown, catalina, ... scripts, > much less their lack of reliability, makes a little clearer why > some devops might want to avoid the shipped daemon control > scripts. Would you care to be specific? I've been running Tomcat for nearly 20 years and never had any problems with the standard service-management scripts. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl65ndAACgkQHPApP6U8 pFi9yg/+PgGGkfEPTgkFOSGSQJlMRQITC4A6NN6ioxhm89tJz/r1RK6xLQOinW84 O3ZtKrSq2uvYzd5ZEMzlcCDP7NyRpS3xT1DlS15+n5kSI5xMhOkkHbOaaRkW+kd6 xqS7OmLH7TkgWkVEn/LsZp7haS5e9z9KSYF+Ychwye7DlpmC+td9N45egWHbV9VF iNYsNvElwNx7q1D7phst6Xcn1QC707EVajRRowpeOyMZyOXBfpczy8OzU6f3d+g7 yDbFSGW0GXBkvgorRXzYxzYHYzvB3fBHaLWeo+TzM75oibzu5hQs/wh6QU+sQ5Jd Fcp3pyRHP+h223GAwCzOQRFjCFinDlFHcDWkebvgUkmC/QyqWIWZUbWJOfbjMO/W 0l63NoFCSXuP3//XsUSLeER3dhP7aNxuyfXsSTiM4kTX7KnHlwXxS9/umd3JXJRS KKqcDhaRg9ItsJfY1HKPccEd/2A1wLWuJHZOPLfqBvQYUApBoN5gaK4qJleS3Dn1 xEYNdfpq+MO1J8GBtkb4leSA3ujPc1uW1oo1ziNnZsZ3AAJled4G+L1p+vid0ggc 7StgWbpalJHMp9t7RjP54OV00Pfm0kN/XcnGhvXVgeAJUFQ7wlD8nPLNjxZnpqaF JJLkDfgGbyohaTF48+miIWt/kDW0lw0AMy9ZYp6JMcFausKIvP4= =JAmR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
вс, 10 мая 2020 г. в 22:20, Mark Thomas :
>
> On May 10, 2020 11:31:02 AM UTC, calder wrote:
>
>
>
> >I asked the DevOps person about the error - turns out it was a
> >SAXParseException when using the & char in the string.
>
> That is standard XML. You have to escape reserved characters in the XML.
+1.
XML is a data format.
> > He vaguely
> >remembers a shell issue with the bang char.
>
> I think he is mistaken. There is no issue using ! in XML.
>
> There are no limitations on the characters for the shutdown password. You
> might need to encode some of them to define the password in XML but that is
> all.
Control characters (e.g. CR, LF:
and
) - anything with
code less than whitespace(32) and the character with code 127 cannot
be used. Anything else can be.
For reference, the await loop that waits for the shutdown command:
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/core/StandardServer.java#L596
Note lines 546-548:
if (ch < 32 || ch == 127) {
break;
}
command.append((char) ch);
The code that sends the command:
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/startup/Catalina.java#L538
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
On May 10, 2020 11:31:02 AM UTC, calder wrote: >I asked the DevOps person about the error - turns out it was a >SAXParseException when using the & char in the string. That is standard XML. You have to escape resevered characters in the XML. > He vaguely >remembers a shell issue with the bang char. I think he is mistaken. There is no issue using ! in XML. There are no limitations on the characters for the shutdown password. You might need to encode some of them to define the password in XML but that is all. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
On Sat, May 9, 2020 at 5:09 PM Christopher Schultz wrote: > On 5/9/20 00:36, calder wrote: > > On Fri, May 8, 2020 at 9:07 PM calder [snip] > > Keep in mind - some characters won't work like & or ( or ) - at > > least on Unix-style OSes as the shell may want to interpret them. > > What makes you say that? What does the shell have to do with anything? I asked the DevOps person about the error - turns out it was a SAXParseException when using the & char in the string. He vaguely remembers a shell issue with the bang char. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
calder wrote: We've never had occasion to use the password, because we disable shutdown (the better option). Never did understand this Tomcat oddity. What other application is configured by default to open a tcp socket just to receive a shutdown command? Then there the default password, both of which, IMO, warrant a CVE. Would be far better i.e. more standards-based and secure, if the socket were an option and the default stop method was, like everything else, to use rc/init/service/systemctl/whatever. OTOH, a quick look at the startup, shutdown, catalina, ... scripts, much less their lack of reliability, makes a little clearer why some devops might want to avoid the shipped daemon control scripts. Roger Marquis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Calder, On 5/9/20 00:36, calder wrote: > On Fri, May 8, 2020 at 9:07 PM calder > wrote: >> >> On Fri, May 8, 2020, 19:20 Robert Hicks >> wrote: >>> >>> I am trying to find what the password complexity can be. I've >>> looked at several hardening guides and they are all >>> "WordsLikeThis". Does the shutdown password take symbols and >>> numbers or at least hyphenated words? >> >> >> We've never had occasion to use the password, because we disable >> shutdown (the better option). >> >> However, my best guess one could use anything. One could check >> the source code, or better yet, set up a Dev instance and give it >> a quick test - a 15 minute exercise at most. > > Gave it a test. > > In server.xml, we have > > > and then fire it up > > user@stimpy:~/bin/apache-tomcat/bin> ./catalina.sh start > log.log > 2>&1 > > user@stimpy:~/bin/apache-tomcat/bin> ps aux | grep java user 7223 > 531 1.2 21006280 812812 pts/2 Sl 23:22 0:13 /home/ [ ... ] > > user@stimpy:~/bin/apache-tomcat/bin> ./shutdown.sh stop > > user@stimpy:~/bin/apache-tomcat/bin> ps aux | grep "bin/java" [ no > response ] > > If we start up TC and change server.xml entry to (removed one char > at end) TC won't shut > down. > > Keep in mind - some characters won't work like & or ( or ) - at > least on Unix-style OSes as the shell may want to interpret them. What makes you say that? What does the shell have to do with anything? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl63KfYACgkQHPApP6U8 pFh5yRAAmIInP54+INuiba2Hbjb/AxmqqNMrmP6noARMyPCuOL6ptjumqvebT1J8 tw7oIPJPT3qEFzg2TvXZ/QJ/sQ6or9/Q1PYZ8eZnEtv4Cw5LMSmgLV/69MAMhtfA o6X0V7ZdKwpnLhfIvV8we/kogmfD2h5gqHmqtL165pbBO5FzqywNUJoYIaOaiNtk 9ExWHWZ/+pRxwfS7OkrVLYn9UlIKebFJX1fAqjAMGFnAcI45L5ky6oRjpY359UfJ tQDXbmsu034TGnLdrnhiSGASWHGEPsTmaH2m2o24WW0Sf75ymEsWVkV9RGOYsyAG lBtX7Bj4fa0Ldr/S4ejXEBy7p+e+t+5BNw8yUZKSyE9zPwL77Yp23hL2w83hUQbq beNNIia7HaDpO3x9ZaRT53UALNVTnKdJNmTfIHHPm5m8WAeaaJz7vKHcRdWtkZSg 4GZ1TW5VXnwL27jxSnYlDTBM6o/xUAuVc8ZmpYt2U7fFKnQVE57mVn8BG+jFLPI4 19F6jjIL7bzqIhx4h26af5xeYeqXWLeWRzZWA+nS9GpoPkYFTfmGByGS54bKU0rE lMd/3nRKcjt+PMVM7wnu8b/S+hrSTwG1nE3ens9XPwpJCl0HsZzX5HR51SJegOXF O2xOeuy9as1+jAGtquiQpvOZePDbrGUjJaZebZ4fQE0+acJ1bo4= =JGZQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
On Fri, May 8, 2020 at 9:07 PM calder wrote: > > On Fri, May 8, 2020, 19:20 Robert Hicks wrote: >> >> I am trying to find what the password complexity can be. I've looked at >> several hardening guides and they are all "WordsLikeThis". Does the >> shutdown password take symbols and numbers or at least hyphenated words? > > > We've never had occasion to use the password, because we disable shutdown > (the better option). > > However, my best guess one could use anything. One could check the source > code, or better yet, set up a Dev instance and give it a quick test - a 15 > minute exercise at most. Gave it a test. In server.xml, we have and then fire it up user@stimpy:~/bin/apache-tomcat/bin> ./catalina.sh start > log.log 2>&1 user@stimpy:~/bin/apache-tomcat/bin> ps aux | grep java user 7223 531 1.2 21006280 812812 pts/2 Sl 23:22 0:13 /home/ [ ... ] user@stimpy:~/bin/apache-tomcat/bin> ./shutdown.sh stop user@stimpy:~/bin/apache-tomcat/bin> ps aux | grep "bin/java" [ no response ] If we start up TC and change server.xml entry to (removed one char at end) TC won't shut down. Keep in mind - some characters won't work like & or ( or ) - at least on Unix-style OSes as the shell may want to interpret them. Experiment with whatever chars you want. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown password complexity
On Fri, May 8, 2020, 19:20 Robert Hicks wrote: > I am trying to find what the password complexity can be. I've looked at > several hardening guides and they are all "WordsLikeThis". Does the > shutdown password take symbols and numbers or at least hyphenated words? > We've never had occasion to use the password, because we disable shutdown (the better option). However, my best guess one could use anything. One could check the source code, or better yet, set up a Dev instance and give it a quick test - a 15 minute exercise at most. >
Tomcat shutdown password complexity
I am trying to find what the password complexity can be. I've looked at several hardening guides and they are all "WordsLikeThis". Does the shutdown password take symbols and numbers or at least hyphenated words? Thanks, Bob
Re: Tomcat shutdown, webapp vs database pools
Thanks for the info. I'll investigate further into the listeners. On Sat, Mar 17, 2018 at 4:27 AM, Mark Thomas wrote: > On 16/03/18 22:42, Alex O'Ree wrote: > > I have a war file that defines a context.xml file, some cxf based web > > services and a few other background tasks using quartz that are > initialized > > in a servlet context listener. > > > > When tomcat shuts down, it appears that tomcat stops the database > > connection pool before the cxf services or the quartz tasks. This causes > > huge amounts of log output. I'm a bit unclear as to how to adjust/change > > the shutdown order of the database pool vs the servlet listeners. > > > > The web app's web.xml does declare a resource-ref element that points at > > the jndi lookup name, but perhaps the configuration is wrong. > > > > I have looked at https://tomcat.apache.org/ > tomcat-8.0-doc/jndi-resources- > > howto.html#JDBC_Data_Sources and my configuration appears to be correct, > > however something is still not quite right. > > > > What am I doing wrong? > > Don't know. > > The listeners are stopped before the JNDI resources so I'm not sure what > is going on. Is it possible the listener isn't waiting for the cxf > services or the quartz tasks to complete before it exits the > contextDestroyed() method? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat shutdown, webapp vs database pools
On 16/03/18 22:42, Alex O'Ree wrote: > I have a war file that defines a context.xml file, some cxf based web > services and a few other background tasks using quartz that are initialized > in a servlet context listener. > > When tomcat shuts down, it appears that tomcat stops the database > connection pool before the cxf services or the quartz tasks. This causes > huge amounts of log output. I'm a bit unclear as to how to adjust/change > the shutdown order of the database pool vs the servlet listeners. > > The web app's web.xml does declare a resource-ref element that points at > the jndi lookup name, but perhaps the configuration is wrong. > > I have looked at https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources- > howto.html#JDBC_Data_Sources and my configuration appears to be correct, > however something is still not quite right. > > What am I doing wrong? Don't know. The listeners are stopped before the JNDI resources so I'm not sure what is going on. Is it possible the listener isn't waiting for the cxf services or the quartz tasks to complete before it exits the contextDestroyed() method? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat shutdown, webapp vs database pools
I have a war file that defines a context.xml file, some cxf based web services and a few other background tasks using quartz that are initialized in a servlet context listener. When tomcat shuts down, it appears that tomcat stops the database connection pool before the cxf services or the quartz tasks. This causes huge amounts of log output. I'm a bit unclear as to how to adjust/change the shutdown order of the database pool vs the servlet listeners. The web app's web.xml does declare a resource-ref element that points at the jndi lookup name, but perhaps the configuration is wrong. I have looked at https://tomcat.apache.org/tomcat-8.0-doc/jndi-resources- howto.html#JDBC_Data_Sources and my configuration appears to be correct, however something is still not quite right. What am I doing wrong?
Re: Threadlocal leaks while Tomcat shutdown
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 9/17/16 9:41 AM, Amit Pande wrote: > This might not be the right forum to ask this question. Yet wanted > to if anyone faced this issue. > > Our application uses Jacorb library to talk to legacy daemons over > CORBA. > > However while stopping the Tomcat, observing following errors. They > are from the jacrob.jar ..but not sure how to prevent this. Any > thoughts ? > > > SEVERE: The web application [] created a ThreadLocal with key of > type [org.jacorb.orb.Delegate$1] (value > [org.jacorb.orb.Delegate$1@62305af6]) and a value of type > [java.lang.Boolean] (value [false]) but failed to remove it when > the web application was stopped. Threads are going to be renewed > over time to try and avoid a probable memory leak. Sep 17, 2016 > 7:04:53 PM org.apache.catalina.loader.WebappClassLoaderBase > checkThreadLocalMapForLeaks SEVERE: The web application [] created > a ThreadLocal with key of type [org.jacorb.orb.Delegate$1] (value > [org.jacorb.orb.Delegate$1@62305af6]) and a value of type > [java.lang.Boolean] (value [false]) but failed to remove it when > the web application was stopped. Threads are going to be renewed > over time to try and avoid a probable memory leak. Your best bet is to ask the Jacorb group how to clean their ThreadLocal values since you are using this library in a servlet-container context. The good news is that Tomcat will slowly retire all of the threads in the thread pool so that those ThreadLocals will eventually be GC'd and you won't have a ClassLoader leak. So it would be best to find out how to use Jacorb correctly (or, if they have a bug, get them to fix it), but in the meantime you should be safe from memory leaks -- at least from this particular kind of ThreadLocal leak. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJX3XLBAAoJEBzwKT+lPKRYcg0P/13NUKxmR3U6i0e7HcSAMDbL eBA5R+5SRGi0VAn9TnDOxLfedkjQnNaWk9k9lUrhm+pytJAb88r/Cbf2ijtrTK2H N3Lva5sIFjnFT0Qx7b0dRYBTjKmmeiWxpRbwYbgYgO8ktJxU7I/DnpCV6rejViT5 7aLj/UhiMeQo+xWunoW3JDh8f3xRm3hxglAvwg/ah+V99K8HNBaT1HzHYX4j2+3e uxPqouviZe1zJG4XCn737+MJaG7fVMROnSQEiccnB/W6Zyr8kIf1DsoUhtTi0N7O vYcSbUIGQYIDh8q6sxxHOvc/t5a5Hul2toNnB+SCHpXw5EwKkLzA5euG1j78BLcP R9ctvV1/1SIiyOew712T31bw563F6MdGOReXxvotz6veYCUiXVaTt7JPe2tGxl7p qy7RjJzWTrTSIIaKToLDBFgvkNUjkNrRSuNMs/Mupr5VOfIloFVw4dMRRVwA2BrX A0kKbAyZ0EcT5e9lTMHuD6wyqe0yuvZQd1r732WGsq+0ArlGcTGJgONuDOrKm8kl HPAz3jKx40kTfW7RHr6cZABu0QL0AbnVWghZMXL6hHrDNMBkQwJYXbISrToq+ujH 6HIDm7BqsPrI94+ETY2dLLkYQkSILr4PREzuKVlya762t92unT42k5CfgzXw5QpF LzCJjhDrRYICb3ETCIh7 =gwpo -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Threadlocal leaks while Tomcat shutdown
This might not be the right forum to ask this question. Yet wanted to if anyone faced this issue. Our application uses Jacorb library to talk to legacy daemons over CORBA. However while stopping the Tomcat, observing following errors. They are from the jacrob.jar ..but not sure how to prevent this. Any thoughts ? SEVERE: The web application [] created a ThreadLocal with key of type [org.jacorb.orb.Delegate$1] (value [org.jacorb.orb.Delegate$1@62305af6]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Sep 17, 2016 7:04:53 PM org.apache.catalina.loader.WebappClassLoaderBase checkThreadLocalMapForLeaks SEVERE: The web application [] created a ThreadLocal with key of type [org.jacorb.orb.Delegate$1] (value [org.jacorb.orb.Delegate$1@62305af6]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Thanks, Amit
Tomcat shutdown error
I'm receiving the following errors when shutting down tomcat7 and it may be a clue to my software that runs on tomcat. Any suggestions? Thanks in advance, Aug 24, 2016 12:34:12 PM org.apache.catalina.startup.Catalina stopServer SEVERE: Could not contact localhost:8005. Tomcat may not be running. Aug 24, 2016 12:34:12 PM org.apache.catalina.startup.Catalina stopServer SEVERE: Catalina.stop: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:344) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.(Socket.java:425) at java.net.Socket.(Socket.java:208) at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:498) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:343) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:430) Jeffrey Trimble, MLS William F. Maag Library Youngstown State University 330.941.2483 (Office) jatrim...@ysu.edu http://www.maag.ysu.edu http://digital.maag.ysu.edu
Re: Tomcat shutdown process
On 05/04/2016 21:48, Vinicius Carvalho wrote: > Thanks for the quick reply Mark, one final question, does tomcat return a > 503 error in that case? New connections will fail. Existing connections will be closed. Mark > > Regards > > On Tue, Apr 5, 2016 at 4:05 PM, Mark Thomas wrote: > >> On 05/04/2016 20:54, Vinicius Carvalho wrote: >>> Hi there, I googled this one around, but I found a big mix on exactly how >>> tomcat operates when a shutdown is initiated. What happens when a >> shutdown >>> is started in regards to: >>> >>> - Requests that are currently being processed (if a request is waiting on >>> an external resource such as a jdbc connection), does the container wait >>> for all responses to be committed or it will eventually kill any pending >>> request? >> >> Requests are given a configurable time to complete (default is 10s as >> far as I recall) and then Tomcat stops anyway. >> >>> - New requests that arrive after the shutdown. Does the container stop >>> accepting them? >> >> No new requests are accepted. >> >> Mark >> >> >> - >> 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
Re: Tomcat shutdown process
Thanks for the quick reply Mark, one final question, does tomcat return a 503 error in that case? Regards On Tue, Apr 5, 2016 at 4:05 PM, Mark Thomas wrote: > On 05/04/2016 20:54, Vinicius Carvalho wrote: > > Hi there, I googled this one around, but I found a big mix on exactly how > > tomcat operates when a shutdown is initiated. What happens when a > shutdown > > is started in regards to: > > > > - Requests that are currently being processed (if a request is waiting on > > an external resource such as a jdbc connection), does the container wait > > for all responses to be committed or it will eventually kill any pending > > request? > > Requests are given a configurable time to complete (default is 10s as > far as I recall) and then Tomcat stops anyway. > > > - New requests that arrive after the shutdown. Does the container stop > > accepting them? > > No new requests are accepted. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat shutdown process
On 05/04/2016 20:54, Vinicius Carvalho wrote: > Hi there, I googled this one around, but I found a big mix on exactly how > tomcat operates when a shutdown is initiated. What happens when a shutdown > is started in regards to: > > - Requests that are currently being processed (if a request is waiting on > an external resource such as a jdbc connection), does the container wait > for all responses to be committed or it will eventually kill any pending > request? Requests are given a configurable time to complete (default is 10s as far as I recall) and then Tomcat stops anyway. > - New requests that arrive after the shutdown. Does the container stop > accepting them? No new requests are accepted. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat shutdown process
Hi there, I googled this one around, but I found a big mix on exactly how tomcat operates when a shutdown is initiated. What happens when a shutdown is started in regards to: - Requests that are currently being processed (if a request is waiting on an external resource such as a jdbc connection), does the container wait for all responses to be committed or it will eventually kill any pending request? - New requests that arrive after the shutdown. Does the container stop accepting them? Regards
HTTP requests held up during Tomcat shutdown
Hello, I am having an issue with Tomcat shutdown. Requests arriving while the servlet container is shutting down seem to be held up by the connector until container shutdown finishes. The shutdown sequence appears to be: (1) pause connectors, (2) stop containers, (3) stop connectors. I have noticed via JMX that Connector.pause() accepts connections and holds them indefinitely - which I think is the case here. The problem is, our servlet can take up to a minute to shut down, meaning connections arriving during this period are held for up to a minute. Is this behavior correct/expected? We have an nginx load balancer in front of our Tomcat servers that re-routes connections upon error (refused, reset, etc.). But this doesn't work well during server restarts since requests are held for many seconds before being re-routed. The result is a flood of slow responses when a server shuts down. Wouldn't ideal Tomcat shutdown behavior be to (1) let existing requests finish (as it already does), but (2) reject new connections (instead of accepting and holding them)? Tested with: Tomcat 7.0.23 and 7.0.53 NIO connector JDK 1.7.0_07 (Windows) and 1.7.0_17 (Linux) Thanks in advance.
Re: Tomcat shutdown behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vimal, On 8/9/13 1:01 AM, Vimal Jain wrote: > I am using tomcat-6 on my Ubuntu 13.10 desktop. My question is :- > When i run shutdown script of tomcat , does tomcat wait for > currently running threads to complete before shutting down ? Do you mean "does Tomcat complete all in-progress requests before shutting down"? Honestly, I get horribly confused whenever I try to read the Connector/Processor/Protocol/Lifecycle/etc. code (as I just did, again), but it looks like Tomcat closes the ServerSocket (which will drop any request that hasn't yet been accepted -- those in the TCP accept queue) immediately. I have to imagine that any in-progress non-asynchronous requests that have been assigned threads will complete successfully, since they threads are being managed by a thread pool. I'm not sure what happens to asynchronous requests that are still in mid-flight. Note that running 'bin/catalina.sh stop' does not stop Tomcat before it exists. That command merely sends a "SHUTDOWN" command to Tomcat via a socket (under the default configuration) or sends a signal to the process (if you have changed the default). In the former case (SHUTDOWN command), your shutdown-request completes almost immediately, while the true server process goes through an orderly shutdown process as (lightly) described above. In the latter case (signal), a KILL signal is sent and your JVM might not shutdown in an orderly way -- and you may destroy in-process requests. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBO1YAAoJEBzwKT+lPKRYXMEQALpeFF12SE3Cm9DoVwtjlgKb MFef+u54uzRqyRufoamHnO6rbqLd4OPNQIiSbx/eJ2Xr3QQhhF5THRSfQY6hJpxN phxKRWoPVQiEGffo/qXFOmGM10tUbTe1BTD2ZKfUoqy6N4G1EDeUhuEBke2yaBga G5CUcjSYAPqRUMHcQi+EH+8oVGAB3TFXkQAl9a2zz4CqLi8fP/GVeMl8DAN91kCG 0IV6qSw8s6TdC5f3HXtOrp1fEhS15PPdF6gPfBFpKII2IFddGfDwghDhSaabWBrV Q1rMqngNKLArTcXOv4ahXsBAykNaUq2MLLFs2NW2Giy61q9LZ5W5Ip1sa7TqEAU6 hiZU7VDkbrjz3iMLe2UvfoiIi+6P5CAfTL1tKVdGkAo4bN1EwZDShD9hQjvLnJFU 9ScaHfsor0iTwu1UvKjOWER8jids3ntju8kXsGs+WA4SOn517q7Ni0/3DPYkTZQL idQHx8VC0GaENkPQfWRU+CCH73GuWuSKmgWrDnL3mxFNoCPZLFix7fwYBk+5OOSn PeIs0OYhWlMyWj+wNtp7hqx4Bk7XvNKxwpCID+keB8Ffj8JR5hKyKBbJBzCw3RRa YLSaqjCvsq0Ab7k9IyDntH9lVPLRvpxb/d16PZw11IvMlQsbg5KZRSXnXZNabkSf atnhsLEmjGu3fPs8+Ror =ZQGX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat shutdown behaviour
Hi, I am using tomcat-6 on my Ubuntu 13.10 desktop. My question is :- When i run shutdown script of tomcat , does tomcat wait for currently running threads to complete before shutting down ? -- Thanks and Regards, Vimal Jain
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
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 p
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
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 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 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/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)
2013/5/19 Nick Williams : > > 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)
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
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 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)
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=13661501&page=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
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.)
Re: tomcat shutdown clarification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 8/14/12 3:20 PM, Caldarale, Charles R wrote: >> From: Davis, Chad [mailto:chad.da...@emc.com] Subject: RE: tomcat >> shutdown clarification > >> And how does the -force option affect this? Will that kill the >> JVM regardless . . . > > Usually. The -force option will invoke kill -9 on the Tomcat pid > if Tomcat doesn't stop in the specified time, which defaults to > five seconds, but may be specified as an argument to the > shutdown.sh script. If the pid can't be determined, -force has no > effect. > >> what factors impact how much time might pass before it's actually >> dead? > > Lots of things, including connections to other processes (e.g., > database servers), flushing of unwritten buffers to disk, how busy > the system is, etc. I would say that the most likely thing(s) that would delay Tomcat's shutdown are ServletContextListeners that do a lot of work. If you (Chad) want to know what it happening to Tomcat while it's shutting down (and taking forever to do so), you can take a thread dump of the process and see what's going on. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqrDQACgkQ9CaO5/Lv0PCktgCfYaEetCtTeBZxQRxHrgH2Bigs 1ZkAn1xQKqIg34DjddpGKT2cbBdS4I6q =5zJD -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat shutdown clarification
> From: Davis, Chad [mailto:chad.da...@emc.com] > Subject: RE: tomcat shutdown clarification > And how does the -force option affect this? Will that kill the > JVM regardless . . . Usually. The -force option will invoke kill -9 on the Tomcat pid if Tomcat doesn't stop in the specified time, which defaults to five seconds, but may be specified as an argument to the shutdown.sh script. If the pid can't be determined, -force has no effect. > what factors impact how much time might pass before it's actually > dead? Lots of things, including connections to other processes (e.g., database servers), flushing of unwritten buffers to disk, how busy the system is, etc. - 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: tomcat shutdown clarification
> > When I use the shutdown.sh script to stop tomcat, what happens? > > I am tempted to say "Magic." That's good ;) > > > BUT the JVM won't go down if there are still other threads running > > > Am I missing anything important? > > Just one point: if the other threads are daemon threads, the JVM will stop. > It's only unmanaged non-daemon threads that are a problem. > And how does the -force option affect this? Will that kill the JVM regardless . . . what factors impact how much time might pass before it's actually dead? I'm on tomcat 7 if it matters. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat shutdown clarification
> From: Davis, Chad [mailto:chad.da...@emc.com] > Subject: tomcat shutdown clarification > When I use the shutdown.sh script to stop tomcat, what happens? I am tempted to say "Magic." > BUT the JVM won't go down if there are still other threads running > Am I missing anything important? Just one point: if the other threads are daemon threads, the JVM will stop. It's only unmanaged non-daemon threads that are a problem. - 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
tomcat shutdown clarification
When I use the shutdown.sh script to stop tomcat, what happens? My understanding is as follows, please correct where wrong. Each of the Servlet Context's, aka web apps, will have their stop lifecycle methods invoked. Tomcat itself will stop it's own mechanisms, such as port listeners, etc. BUT the JVM won't go down if there are still other threads running . . . in other words, the JVM won't go down if you started other threads that you don't close in one of the lifecycle methods. Am I missing anything important? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown
Thanks Chuck. Will try that. Appreciate your help. On Fri, Jan 6, 2012 at 4:51 PM, Caldarale, Charles R < chuck.caldar...@unisys.com> wrote: > > From: Kamal Sheikh [mailto:kama...@gmail.com] > > Subject: Re: Tomcat Shutdown > > > I'm pasting some information from the logs: > > > # A fatal error has been detected by the Java Runtime Environment: > > # Internal Error (safepoint.cpp:247), pid=306, tid=140562856904448 > > # guarantee(PageArmed == 0) failed: invariant > > Uh oh ... that's really ugly; you have a broken JVM. This can be caused > by malfunctioning native code inside the JVM process, or it may be a bug in > that particular JVM version. > > > # JRE version: 6.0_20-b20 > > # Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 > compressed oops) > > You might try turning off compressed OOPs, and see if that helps. > > > # Distribution: Ubuntu 10.04.1 LTS, package 6b20-1.9.9-0ubuntu1~10.04.2 > > # If you would like to submit a bug report, please include > > # instructions how to reproduce the bug and visit: > > # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ > > You should probably do the above. > > If there's a later JVM available (Oracle is up to 6u30), try that. > > - 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: Tomcat Shutdown
> From: Kamal Sheikh [mailto:kama...@gmail.com] > Subject: Re: Tomcat Shutdown > I'm pasting some information from the logs: > # A fatal error has been detected by the Java Runtime Environment: > # Internal Error (safepoint.cpp:247), pid=306, tid=140562856904448 > # guarantee(PageArmed == 0) failed: invariant Uh oh ... that's really ugly; you have a broken JVM. This can be caused by malfunctioning native code inside the JVM process, or it may be a bug in that particular JVM version. > # JRE version: 6.0_20-b20 > # Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 > compressed oops) You might try turning off compressed OOPs, and see if that helps. > # Distribution: Ubuntu 10.04.1 LTS, package 6b20-1.9.9-0ubuntu1~10.04.2 > # If you would like to submit a bug report, please include > # instructions how to reproduce the bug and visit: > # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ You should probably do the above. If there's a later JVM available (Oracle is up to 6u30), try that. - 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: Tomcat Shutdown
Thanks for the reply. I'm pasting some information from the logs: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (safepoint.cpp:247), pid=306, tid=140562856904448 # guarantee(PageArmed == 0) failed: invariant # # JRE version: 6.0_20-b20 # Java VM: OpenJDK 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 compressed oops) # Derivative: IcedTea6 1.9.9 # Distribution: Ubuntu 10.04.1 LTS, package 6b20-1.9.9-0ubuntu1~10.04.2 # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # --- T H R E A D --- Current thread (0x01635800): VMThread [stack: 0x7fd757178000,0x7fd757279000] [id=309] Stack: [0x7fd757178000,0x7fd757279000], sp=0x7fd757277990, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x72341c] V [libjvm.so+0x72363b] V [libjvm.so+0x32fc96] V [libjvm.so+0x657eff] V [libjvm.so+0x72984a] V [libjvm.so+0x729b52] V [libjvm.so+0x5e4242] VM_Operation (0x7fd75425a390): GenCollectForAllocation, mode: safepoint, requested by thread 0x02c5e800 /proc/meminfo: MemTotal:4060052 kB MemFree: 174276 kB Buffers: 203376 kB Cached: 2114228 kB SwapCached: 84 kB Active: 1892484 kB Inactive: 849440 kB Active(anon): 342896 kB Inactive(anon):83840 kB Active(file):1549588 kB Inactive(file): 765600 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2611192 kB SwapFree:2610212 kB Dirty:36 kB Writeback: 0 kB AnonPages:424216 kB Mapped:29344 kB Shmem: 2404 kB Slab:1029520 kB SReclaimable: 122988 kB SUnreclaim: 906532 kB KernelStack:1392 kB PageTables:12252 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit: 4641216 kB Committed_AS: 943912 kB VmallocTotal: 34359738367 kB VmallocUsed: 288308 kB VmallocChunk: 34359420524 kB HardwareCorrupted: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M: 4184064 kB CPU:total 1 (1 cores per cpu, 1 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt Memory: 4k page, physical 4060052k(174276k free), swap 2611192k(2610212k free) vm_info: OpenJDK 64-Bit Server VM (19.0-b09) for linux-amd64 JRE (1.6.0_20-b20), built on Jul 22 2011 01:26:54 by "buildd" with gcc 4.4.3 time: Fri Jan 6 08:48:10 2012 elapsed time: 81155 seconds Thanks much ! On Fri, Jan 6, 2012 at 4:09 PM, Konstantin Kolinko wrote: > 2012/1/7 Kamal Sheikh : > > Hi, I'm new to this but please direct me if I'm posting to the wrong > list. > > > > Our Tomcat has suddenly stopped working this morning and now wouldn't > start > > -- it responds simply by saying: "failed". > > What is in the logs? > > Maybe there is no free space on the harddrive? > > Maybe there is stale pid file from previous Tomcat run? > > > > > Is there anything going on with OpenJDK and Tomcat? > > > > Here's our configuration: > > > > Java: > > > > java version "1.6.0_20" > > OpenJDK Runtime Environment (IcedTea6 1.9.9) > (6b20-1.9.9-0ubuntu1~10.04.2) > > OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) > > > > Tomcat > > > > Server version: Apache Tomcat/6.0.24 > > Server built: March 24 2011 1829 > > 6.0.24 was officially released on 2010-01-21 which is more than a year > earlier than the above "build" date. > > There were a lot of important fixes since then, including some fixes > to the startup scripts as well. > > > Server number: ...0 > > OS Name:Linux > > OS Version: 2.6.32-32-server > > Architecture: amd64 > > JVM Version:1.6.0_20-b20 > > JVM Vendor: Sun Microsystems Inc. > > > > OS > > > > Ubuntu 10.04.2 LTS > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat Shutdown
2012/1/7 Kamal Sheikh : > Hi, I'm new to this but please direct me if I'm posting to the wrong list. > > Our Tomcat has suddenly stopped working this morning and now wouldn't start > -- it responds simply by saying: "failed". What is in the logs? Maybe there is no free space on the harddrive? Maybe there is stale pid file from previous Tomcat run? > > Is there anything going on with OpenJDK and Tomcat? > > Here's our configuration: > > Java: > > java version "1.6.0_20" > OpenJDK Runtime Environment (IcedTea6 1.9.9) (6b20-1.9.9-0ubuntu1~10.04.2) > OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) > > Tomcat > > Server version: Apache Tomcat/6.0.24 > Server built: March 24 2011 1829 6.0.24 was officially released on 2010-01-21 which is more than a year earlier than the above "build" date. There were a lot of important fixes since then, including some fixes to the startup scripts as well. > Server number: ...0 > OS Name: Linux > OS Version: 2.6.32-32-server > Architecture: amd64 > JVM Version: 1.6.0_20-b20 > JVM Vendor: Sun Microsystems Inc. > > OS > > Ubuntu 10.04.2 LTS Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Shutdown
Hi, I'm new to this but please direct me if I'm posting to the wrong list. Our Tomcat has suddenly stopped working this morning and now wouldn't start -- it responds simply by saying: "failed". Is there anything going on with OpenJDK and Tomcat? Here's our configuration: Java: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.9) (6b20-1.9.9-0ubuntu1~10.04.2) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) Tomcat Server version: Apache Tomcat/6.0.24 Server built: March 24 2011 1829 Server number: ...0 OS Name:Linux OS Version: 2.6.32-32-server Architecture: amd64 JVM Version:1.6.0_20-b20 JVM Vendor: Sun Microsystems Inc. OS Ubuntu 10.04.2 LTS
Re: Tomcat shutdown issues
On 10.06.2011 16:55, Caldarale, Charles R wrote: >> From: April Easton [mailto:aeas...@shawneecourt.org] >> Subject: Tomcat shutdown issues > >> I don't see any of my threads in there > > Look harder: > >> "Worker-JM" prio=3D10 tid=3D0x5d7a1800 nid=3D0x521f in Object.wait() >> at >> org.eclipse.core.internal.jobs.InternalWorker.run(InternalWorker.java:58) >> "Bundle File Closer" daemon prio=3D10 tid=3D0x5e223800 nid=3D0x521d >> in Object.wait() >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) >> "Start Level Event Dispatcher" daemon prio=3D10 tid=3D0x5d5fc000 >> nid=3D0x521b in Object.wait() >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) >> "Framework Event Dispatcher" daemon prio=3D10 tid=3D0x5d956800 >> nid=3D0x521a in Object.wait() >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) >> at >> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) > > Those aren't Tomcat's threads; ergo, they are yours. You're running Eclipse, > you're responsible for the chaos it creates. ... but AFAIK only the non-daemon threads are problematic. The JVM shouldn't care about existing daemon threads when trying to shut down. So the only one in the list to care about is "Worker-JM". Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat shutdown issues
Taking out what I did for the YourKit plug-in didn't help. Next, I shutdown my Eclipse and then started and stopped Tomcat on the server. The org.eclipse threads were still listed in the thread dump. I recently upgraded B.I.R.T. to version 2.2 on Tomcat and it uses osgi jar files. I'll look to see if there is an issue there or if I need to do something else so Tomcat will shutdown properly. Thanks, April, Systems - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat shutdown issues
I just installed a plug-in to try and get YourKit going to find the leaks. I didn't realize that I had started Tomcat from inside Eclipse. I'll take out what I did. Thanks, April - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat shutdown issues
> From: April Easton [mailto:aeas...@shawneecourt.org] > Subject: Tomcat shutdown issues > I don't see any of my threads in there Look harder: > "Worker-JM" prio=3D10 tid=3D0x5d7a1800 nid=3D0x521f in Object.wait() > at > org.eclipse.core.internal.jobs.InternalWorker.run(InternalWorker.java:58) > "Bundle File Closer" daemon prio=3D10 tid=3D0x5e223800 nid=3D0x521d > in Object.wait() > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) > "Start Level Event Dispatcher" daemon prio=3D10 tid=3D0x5d5fc000 > nid=3D0x521b in Object.wait() > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) > "Framework Event Dispatcher" daemon prio=3D10 tid=3D0x5d956800 > nid=3D0x521a in Object.wait() > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) > at > org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) Those aren't Tomcat's threads; ergo, they are yours. You're running Eclipse, you're responsible for the chaos it creates. - 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: Tomcat shutdown issues
On 10/06/2011 15:36, April Easton wrote: > Good day, > I've been working on closing all my threads in my applications that run > on Tomcat. I recently upgraded to 7.0.14 to get better messages concerning > why Tomcat wasn't shutting down properly. I have stopped all my servlets and > threads, but I'm still having trouble. Below is the thread dump of the most > recent shutdown and my catalina log. I don't see any of my threads in there, > so what is keeping Tomcat alive? Are you running Tomcat inside Eclipse? p signature.asc Description: OpenPGP digital signature
Tomcat shutdown issues
Good day, I've been working on closing all my threads in my applications that run on Tomcat. I recently upgraded to 7.0.14 to get better messages concerning why Tomcat wasn't shutting down properly. I have stopped all my servlets and threads, but I'm still having trouble. Below is the thread dump of the most recent shutdown and my catalina log. I don't see any of my threads in there, so what is keeping Tomcat alive? 2011-06-10 09:07:32 Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode): "DestroyJavaVM" prio=3D10 tid=3D0x5d1e9800 nid=3D0x5155 waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Worker-JM" prio=3D10 tid=3D0x5d7a1800 nid=3D0x521f in Object.wait() [0x42ce2000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb69c2050> (a java.util.ArrayList) at org.eclipse.core.internal.jobs.InternalWorker.run(InternalWorker.java:58) - locked <0xb69c2050> (a java.util.ArrayList) "Bundle File Closer" daemon prio=3D10 tid=3D0x5e223800 nid=3D0x521d in Object.wait() [0x42be1000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb6a67768> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) - locked <0xb6a67768> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) "Start Level Event Dispatcher" daemon prio=3D10 tid=3D0x5d5fc000 nid=3D0x521b in Object.wait() [0x42ae] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb68c5d38> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) - locked <0xb68c5d38> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) "Framework Event Dispatcher" daemon prio=3D10 tid=3D0x5d956800 nid=3D0x521a in Object.wait() [0x429df000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb68f7278> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:397) - locked <0xb68f7278> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:333) "GC Daemon" daemon prio=3D10 tid=3D0x5d299000 nid=3D0x5160 in Object.wait() [0x40dea000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb48180b8> (a sun.misc.GC$LatencyLock) at sun.misc.GC$Daemon.run(GC.java:100) - locked <0xb48180b8> (a sun.misc.GC$LatencyLock) "Low Memory Detector" daemon prio=3D10 tid=3D0x5ce8b000 nid=3D0x515e runnable [0x] java.lang.Thread.State: RUNNABLE "CompilerThread1" daemon prio=3D10 tid=3D0x5ce88800 nid=3D0x515d waiting on condition [0x] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=3D10 tid=3D0x5ce85000 nid=3D0x515c waiting on condition [0x] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=3D10 tid=3D0x5ce82800 nid=3D0x515b runnable [0x] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=3D10 tid=3D0x5ce5e000 nid=3D0x515a in Object.wait() [0x4136b000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb4818800> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118) - locked <0xb4818800> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=3D10 tid=3D0x5ce5c000 nid=3D0x5159 in Object.wait() [0x4126a000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00
Re: Getting the Tomcat shutdown port
On 3/1/2011 3:54 PM, Caldarale, Charles R wrote: Anything using an org.apache class is Tomcat-specific, and > therefore not portable. Oh, right. I had not picked up that LifecycleListener itself is a Catalina class. Still, the basic issue is not about the listener per se but how the app server reacts to an Error thrown during initialization. -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Getting the Tomcat shutdown port
> From: Olivier Lefevre [mailto:lefev...@yahoo.com] > Subject: Re: Getting the Tomcat shutdown port > Just to be 100% clear, this is a Tomcat thing, not a servlet > spec thing, right? Just wondering whether it's portable. Anything using an org.apache class is Tomcat-specific, and therefore not portable. - 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: Getting the Tomcat shutdown port
On 01/03/2011 14:46, Olivier Lefevre wrote: > On 3/1/2011 2:57 PM, Mark Thomas wrote: >> Providing you throw an Error, Tomcat is guaranteed not to start. > > OK! Just to be 100% clear, this is a Tomcat thing, not a servlet > spec thing, right? Just wondering whether it's portable. Yes, this is Tomcat specific. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 3/1/2011 2:57 PM, Mark Thomas wrote: Providing you throw an Error, Tomcat is guaranteed not to start. OK! Just to be 100% clear, this is a Tomcat thing, not a servlet spec thing, right? Just wondering whether it's portable. -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 01/03/2011 13:52, Olivier Lefevre wrote: > On 2/28/2011 8:18 PM, Mark Thomas wrote: >> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityListener.java?view=annotate >> > > This is brand new, isn't it? I can't find it in the 7.0.8 sources. Yes. > So it may throw a java.lang.Error at Lifecycle.BEFORE_INIT_EVENT > time but what happens then? I read §10.9 and §11.6 and it only > talks about the user-configurable exception handling: it does not > seem to specify what the application server may do internally. > Besides it is talking about errors that occur much later in the > life cycle. So, is the whole Tomcat supposed to die if you throw > at BEFORE_INIT_EVENT? Providing you throw an Error, Tomcat is guaranteed not to start. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 2/28/2011 8:18 PM, Mark Thomas wrote: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityListener.java?view=annotate This is brand new, isn't it? I can't find it in the 7.0.8 sources. So it may throw a java.lang.Error at Lifecycle.BEFORE_INIT_EVENT time but what happens then? I read §10.9 and §11.6 and it only talks about the user-configurable exception handling: it does not seem to specify what the application server may do internally. Besides it is talking about errors that occur much later in the life cycle. So, is the whole Tomcat supposed to die if you throw at BEFORE_INIT_EVENT? -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 2/28/2011 6:09 PM, Caldarale, Charles R wrote: The servlet, or the webapp? The webapp in this case: the servlet that might fail is the "worker" servlet, the others more in a supporting role (e.g., UI). So if it fails the whole webapp should shut down. Why don't you simply throw a ServletException in the init() > method of the servlets of interest? OK. But how to communicate to the other servlets of the webapp that they, too, should commit suicide? Are they guaranteed to be created in a certain order? In that case I'd put the worker servlet ahead and then maybe there is a way to leave a breadcrumb behind after its death as a sign to the others that they should not proceed. -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 28/02/2011 19:13, Olivier Lefevre wrote: > I know it's an interface I have to implement but without some > concrete class "close" to my problem to look at for guidance > LifecycleListener in and of itself does not help me much. Ah, OK. Try this: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/SecurityListener.java?view=annotate Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 2/28/2011 6:06 PM, Mark Thomas wrote: If you want to stop a single Servlet then Servlet.init() is the place to it. See section 2.3.2 of the Servlet 3.0 spec. I.e., the exception throwing approach suggested by C. Caldarale in the next answer. Yes, it's neat. So I was overcomplicating it. org.apache.catalina.LifecycleListener was what I meant I know it's an interface I have to implement but without some concrete class "close" to my problem to look at for guidance LifecycleListener in and of itself does not help me much. -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Getting the Tomcat shutdown port
> From: Olivier Lefevre [mailto:lefev...@yahoo.com] > Subject: Re: Getting the Tomcat shutdown port > > Your application may be on a shared Tomcat instance someday > > and System.exit is really bad in that case. > So let's kill the servlet instead. The servlet, or the webapp? > But it's still unclear how you'd do that because from the > ServletConfig you can get the ServletContext but from the > ServletContext you can no longer get the Servlet: There's no "the Servlet"; the ServletContext is for the webapp, which may be comprised of many servlets. Why don't you simply throw a ServletException in the init() method of the servlets of interest? - 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: Getting the Tomcat shutdown port
On 28/02/2011 16:59, Olivier Lefevre wrote: >> Your application may be on a shared Tomcat instance someday >> and System.exit is really bad in that case. > > True. So let's kill the servlet instead. If you want to stop a single Servlet then Servlet.init() is the place to it. See section 2.3.2 of the Servlet 3.0 spec. >> If you really do want to control Tomcat startup, a LifecycleListener >> is a better approach but Tomcat specific. > > There are plenty of LifecycleListener classes in the API; which > one would work best: ServerLifecycleListener? org.apache.catalina.LifecycleListener was what I meant Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
Your application may be on a shared Tomcat instance someday and System.exit is really bad in that case. True. So let's kill the servlet instead. But it's still unclear how you'd do that because from the ServletConfig you can get the ServletContext but from the ServletContext you can no longer get the Servlet: that has been deprecated and that getter now returns null. But perhaps I am looking in the wrong direction: the Servlet.destroy APIdoc says "Called by the servlet container to indicate to a servlet that the servlet is being taken out of service." which implies that the teardown is initiated elsewhere and that simply calling destroy wouldn't do anything useful. If you really do want to control Tomcat startup, a LifecycleListener > is a better approach but Tomcat specific. There are plenty of LifecycleListener classes in the API; which one would work best: ServerLifecycleListener? -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 28/02/2011 16:12, Olivier Lefevre wrote: >> Doing this from a servlet begs the question how you are going >> to restart it. > > Not an issue: I want to shut it down at startup if some needed > resources cannot be found. No pint restarting it then. Fair enough. I wouldn't do it in a Servlet.init() though. A ServletContextListener that stops the app starting is probably better. Your application may be on a shared Tomcat instance someday and System.exit is really bad in that case. If you really do want to control Tomcat startup, a LifecycleListener is a better approach but Tomcat specific. >> I'm also curious why you want tot do this but System.exit() will >> have exactly the same result as using the shutdown port. > > Does Tomcat set up appropriate shutdown hooks when it starts? > Otherwise tearing down the VM could cause damage to external > resources at least. Yes, which is why I wrote "System.exit() will have exactly the same result as using the shutdown port.". Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
Doing this from a servlet begs the question how you are going to restart it. Not an issue: I want to shut it down at startup if some needed resources cannot be found. No pint restarting it then. I'm also curious why you want tot do this but System.exit() will have exactly the same result as using the shutdown port. Does Tomcat set up appropriate shutdown hooks when it starts? Otherwise tearing down the VM could cause damage to external resources at least. -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Getting the Tomcat shutdown port
On 28/02/2011 15:34, Olivier Lefevre wrote: > Is there a programmatic way to retrieve it from within > a webapp, more exactly from within Servlet.init()? I > can't find one. Same question for the actual command. > > As you may have guessed, I want to shut down Tomcat by > opening a socket and sending it a SHUTDOWN or whatever. > Maybe there is a less low-level way to do it but I can't > find it either. Doing this from a servlet begs the question how you are going to restart it. I'm also curious why you want tot do this but System.exit() will have exactly the same result as using the shutdown port. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Getting the Tomcat shutdown port
Is there a programmatic way to retrieve it from within a webapp, more exactly from within Servlet.init()? I can't find one. Same question for the actual command. As you may have guessed, I want to shut down Tomcat by opening a socket and sending it a SHUTDOWN or whatever. Maybe there is a less low-level way to do it but I can't find it either. Thanks, -- O.L. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown
Hi Konstantin, I see... :-) Thanks a lot, János On Feb 1, 2011, at 11:39 AM, Konstantin Kolinko wrote: > 2011/2/1 János Löbb : >> It is Tomcat 6.0.29 on OSX 10.6.5. If I ssh to the machine and shutdown >> Tomcat and later boot it back again, all those components which are using >> AWT are not usable. However if I Apple Remote Desktop to the machine, open >> up Terminal there, shut down Tomcat and start it up, all AWT components will >> work just fine. >> >> Any good explanation ? >> > > Create $CATALINA_BASE/bin/setenv.sh with the following text > > CATALINA_OPTS="-Djava.awt.headless=true" > > Google for "java.awt.headless" for more info, > e.g. look here: > http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ > > Best regards, > Konstantin Kolinko > > - > 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
Re: Tomcat shutdown
2011/2/1 János Löbb : > It is Tomcat 6.0.29 on OSX 10.6.5. If I ssh to the machine and shutdown > Tomcat and later boot it back again, all those components which are using AWT > are not usable. However if I Apple Remote Desktop to the machine, open up > Terminal there, shut down Tomcat and start it up, all AWT components will > work just fine. > > Any good explanation ? > Create $CATALINA_BASE/bin/setenv.sh with the following text CATALINA_OPTS="-Djava.awt.headless=true" Google for "java.awt.headless" for more info, e.g. look here: http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat shutdown
Hi, It is Tomcat 6.0.29 on OSX 10.6.5. If I ssh to the machine and shutdown Tomcat and later boot it back again, all those components which are using AWT are not usable. However if I Apple Remote Desktop to the machine, open up Terminal there, shut down Tomcat and start it up, all AWT components will work just fine. Any good explanation ? Thanks ahead, János - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: Tomcat Shutdown suddenly / random
Carl wrote: ... Hi. Nothing to do with the subject, but I guess that either your workstation or your email forwarding system must be off by one hour, making your questions appear after the answer has already been given. This looks strange, and reminds me of a character in one of Terry Pratchett's novels. Either that, or else Mark has acquired Pid's gifts. Or else, we should investigate further, as I am sure there must be other uses for this phenomenon. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
Dear All, > I don't believe Tomcat has any System.exit calls in it, so you could > grep your code looking for such calls. Note that findbugs can be used for that. It will issue a warning for code that calls System.exit(). -- Kees Jan http://java-monitor.com/ kjkos...@kjkoster.org 06-51838192 Change is good. Granted, it is good in retrospect, but change is good. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
On 16/04/2010 23:43, Carl wrote: > I thought thta a System.exit call would kill the JVM and would therefore > not show the clean shutdown in the logs that the OP is seeing... am I > wrong about System.exit? Yes. It invokes the shutdown hook and that performs a clean shutdown. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
I thought thta a System.exit call would kill the JVM and would therefore not show the clean shutdown in the logs that the OP is seeing... am I wrong about System.exit? Thanks, Carl - Original Message - From: "Christopher Schultz" To: "Tomcat Users List" Sent: Friday, April 16, 2010 3:58 PM Subject: Re: Tomcat Shutdown suddenly / random -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry, On 4/16/2010 2:35 PM, Harry Metske wrote: could it be that something is sending your tomcat process a TERM signal, logfiles in /var/log might tell something ? or one of your applications issues a System.exit() under certain circumstances ? +1 I'm not sure what the best way is to catch TERM signals. I guess you could write some JNI code to install a signal handler that logs the signal and details (if available) about the process that sent the signal. I don't believe Tomcat has any System.exit calls in it, so you could grep your code looking for such calls. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIz4IACgkQ9CaO5/Lv0PAT4QCgtsZhK/DtHhS8KVjYUhCA2mdG dVwAn1DOyYGJLIfV5hBl1GWaTF8CZUO3 =ASpm -END PGP SIGNATURE- - 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
Re: Tomcat Shutdown suddenly / random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harry, On 4/16/2010 2:35 PM, Harry Metske wrote: > could it be that something is sending your tomcat process a TERM signal, > logfiles in /var/log might tell something ? > or one of your applications issues a System.exit() under certain > circumstances ? +1 I'm not sure what the best way is to catch TERM signals. I guess you could write some JNI code to install a signal handler that logs the signal and details (if available) about the process that sent the signal. I don't believe Tomcat has any System.exit calls in it, so you could grep your code looking for such calls. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvIz4IACgkQ9CaO5/Lv0PAT4QCgtsZhK/DtHhS8KVjYUhCA2mdG dVwAn1DOyYGJLIfV5hBl1GWaTF8CZUO3 =ASpm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Shutdown suddenly / random
Peter, could it be that something is sending your tomcat process a TERM signal, logfiles in /var/log might tell something ? or one of your applications issues a System.exit() under certain circumstances ? regards, Harry 2010/4/16 Peter Borkowski > Hi folks, > > we are facing a serious problem with our tomcat which shuts itself down > after some time of running. this problem first arises after we switched to > our new server. > we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x > versions). > the "old" server was a 32 bit red hat enterprise linux system. > the new server is a 64 bit debian 5 (also tried debian 6). > > the log always gives us the following message, so as if the tomcat has been > cleanly > shutdown, which is really strange. > > 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause > INFO: Pausing Coyote HTTP/1.1 on http-8080 > 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop > INFO: Stopping service Catalina > 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy > INFO: Stopping Coyote HTTP/1.1 on http-8080 > > we also tried to switch the shutdown-message and the shutdown-port, without > effect. > the tomcat process is started with a non-root-user. the server runs for 15 > minutes to 8 hours before it happens. > > any suggestions or help would be nice. > > cya, peter > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat Shutdown suddenly / random
On 16/04/2010 17:21, Peter Borkowski wrote: > Hi folks, > > we are facing a serious problem with our tomcat which shuts itself down > after some time of running. this problem first arises after we switched > to our new server. > we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x > versions). > the "old" server was a 32 bit red hat enterprise linux system. > the new server is a 64 bit debian 5 (also tried debian 6). > > the log always gives us the following message, so as if the tomcat has > been cleanly > shutdown, which is really strange. > > 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause > INFO: Pausing Coyote HTTP/1.1 on http-8080 > 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop > INFO: Stopping service Catalina > 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy > INFO: Stopping Coyote HTTP/1.1 on http-8080 That looks like a fairly orderly shutdown to me. What is immediately before it in this log and in the access logs at the time? > we also tried to switch the shutdown-message and the shutdown-port, > without effect. If something is calling an init.d/tomcat script then it won't matter. Tomcat only listens on the localhost address for that message anyway. > the tomcat process is started with a non-root-user. the server runs for > 15 minutes to 8 hours before it happens. To confirm: are you starting & stopping using a JSVC wrapper script? Are there any cron jobs (or similar) which might interfere with the server? Were there any users logged into the system at the time of shutdown? Is there anything in the .bash_history (or whatever shell you're using) of said user(s)? p > any suggestions or help would be nice. > > cya, peter > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > signature.asc Description: OpenPGP digital signature
Tomcat Shutdown suddenly / random
Hi folks, we are facing a serious problem with our tomcat which shuts itself down after some time of running. this problem first arises after we switched to our new server. we are using tomcat 6.0.26 (also tried different other 5.5.x, 6.0.x versions). the "old" server was a 32 bit red hat enterprise linux system. the new server is a 64 bit debian 5 (also tried debian 6). the log always gives us the following message, so as if the tomcat has been cleanly shutdown, which is really strange. 16.04.2010 11:52:42 org.apache.coyote.http11.Http11Protocol pause INFO: Pausing Coyote HTTP/1.1 on http-8080 16.04.2010 11:52:43 org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina 16.04.2010 11:52:43 org.apache.coyote.http11.Http11Protocol destroy INFO: Stopping Coyote HTTP/1.1 on http-8080 we also tried to switch the shutdown-message and the shutdown-port, without effect. the tomcat process is started with a non-root-user. the server runs for 15 minutes to 8 hours before it happens. any suggestions or help would be nice. cya, peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat shutdown: catalina.sh STOP vs SIGTERM
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: tomcat shutdown: catalina.sh STOP vs SIGTERM > > I'm not sure why it would take 20-30 seconds for you to see > the above message: it should be immediate. One possible cause is specifying a large heap size in JAVA_OPTS, which will be used by both the running Tomcat and the JVM launched by the shutdown script. Better to put such settings in CATALINA_OPTS, which is not used by the shutdown script. - 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. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: tomcat shutdown: catalina.sh STOP vs SIGTERM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ajay, On 3/8/2010 2:56 PM, Aggarwal, Ajay wrote: > When I send SIGTERM to tomcat, I actually do get > > 1) these messages in my catalina.out > > Mar 8, 2010 2:46:05 PM org.apache.catalina.core.StandardService stop > INFO: Stopping service Catalina That's good, but apparently not guaranteed to occur, since I didn't see them in my environment. It's possible that the JVM sends a notification and subsequently terminates all the threads, but may not wait for them to finish their work. I highly recommend an orderly shutdown (using "catalina.sh stop"). > As to why on a busy system, "catalina.sh stop" takes longer I really > don't have the details. This should be easy to determine: run "catalina.sh stop" which should return immediately. Run "jstack" on the still-running JVM several times a few seconds apart to see which threads are still alive. Perhaps some are request processing threads still doing work, in which case the response will not complete if you forceably kill the thread. There could be other threads running that should be daemon threads but aren't: that's usually a simple fix. > All I can say is that sometimes I don't even > see the above messages for first 20-25 seconds. Could it be because > "catalina.sh stop" has to start another JVM and then send a "stop" > message to tomcat process over a local loop interface and on a busy > system, both of these require resources which may not be available. Yes and no: "catalina.sh stop" does in fact start a second JVM and send a "stop" message to the other Tomcat, but its likely that Tomcat receives the message immediately. I'm not sure why it would take 20-30 seconds for you to see the above message: it should be immediate. Tomcat then does a whole bunch of things, including waiting for request processing threads to complete, notifying servlet context listeners that the webapp is coming down, then taking the servlets and filters out of service, shutting down various resource pools, etc. Only then does it take the connectors out of service. So, if something takes a long time to complete (maybe a filter or servlet taking a long time to shutdown) then you'll just have to wait for it to complete. I just checked, and my TC 6.0.20 install doesn't print anything after "Stopping Service Catalina" when I shut it down, so it's possible that message is printed when the service really is ready to go down. Thread dumps will certainly help you figure out what's taking so long. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuVhyIACgkQ9CaO5/Lv0PBZBACfY+kevbW9Y51JNMrghofh4aCj atwAn02La9O0OEY5bn3/9l+3NlHazxRG =LQwd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat shutdown: catalina.sh STOP vs SIGTERM
2010/3/8 Aggarwal, Ajay : > When I send SIGTERM to tomcat, I actually do get > Tomcat installs a shutdown hook into JVM so that it will shutdown gracefully. There is a problem though that if there are several shutdown hooks then they run in parallel. That is particularly visible in 6.0.24, because logging system shutdown was made more robust. This shutdown hooks race is already fixed in the current 6.0.x sources -- that will be 6.0.26. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: tomcat shutdown: catalina.sh STOP vs SIGTERM
When I send SIGTERM to tomcat, I actually do get 1) these messages in my catalina.out Mar 8, 2010 2:46:05 PM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina and, 2) my servlets destroy() methods do get called. That’s why I suspect that even SIGTERM seems to bring tomcat down in an orderly manner. I should mention that I am on a linux platform, running tomcat 6.0.20. As to why on a busy system, "catalina.sh stop" takes longer I really don't have the details. All I can say is that sometimes I don't even see the above messages for first 20-25 seconds. Could it be because "catalina.sh stop" has to start another JVM and then send a "stop" message to tomcat process over a local loop interface and on a busy system, both of these require resources which may not be available. -Ajay -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, March 08, 2010 1:33 PM To: Tomcat Users List Subject: Re: tomcat shutdown: catalina.sh STOP vs SIGTERM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ajay, On 3/8/2010 12:53 PM, Aggarwal, Ajay wrote: > Sometimes on a busy system I have seen that "catalina.sh stop" does take > a long time to shutdown tomcat. You might want to investigate why this is happening: my Tomcat instances (we have 4 in production) take only a few seconds to shut down completely. > We are running another "monitoring > service" on the system that monitors tomcat and few other system > services. After issuing "catalina.sh" and waiting for some time (up to > 25 seconds) it loses patience and gives a SIGTERM to tomcat process. > SIGTERM seems to bring tomcat down much faster. :) > What is the downside of using SIGTERM, if any? I tried issuing a SIGTERM to my JVM/Tomcat process running in development, and I got some messages in the app log file that indicated that the webapp was coming down. But, I didn't get any "shutting down" messages in catalina.out which leads me to believe that the shutdown wasn't entirely clean. > It does seem to bring > tomcat down in an orderly manner and much faster than "catalina.sh > stop". Well, definitely faster, but I'm not sure about orderly: you should check to see what things aren't stopping and determine if they are potentially disastrous it TERMinated. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuVQt8ACgkQ9CaO5/Lv0PD8LgCdFbaGLq1nfsqJJb4dbAsKY8hT lFEAoLUQHVzXZ9KnrQ79ExupS4cyKDfD =vn8E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat shutdown: catalina.sh STOP vs SIGTERM
On Mon, Mar 8, 2010 at 9:53 AM, Aggarwal, Ajay wrote: > What is the downside of using SIGTERM, if any? It does seem to bring > tomcat down in an orderly manner and much faster than "catalina.sh > stop". Yeah, "seem to" would be the operative phrase, I think. A leap off a tall structure might "seem to" be much like flying. Initially. :-) As Chris already said: check your app to see what's slow to exit, and what the consequences of an ungraceful stop might be. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat shutdown: catalina.sh STOP vs SIGTERM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ajay, On 3/8/2010 12:53 PM, Aggarwal, Ajay wrote: > Sometimes on a busy system I have seen that "catalina.sh stop" does take > a long time to shutdown tomcat. You might want to investigate why this is happening: my Tomcat instances (we have 4 in production) take only a few seconds to shut down completely. > We are running another "monitoring > service" on the system that monitors tomcat and few other system > services. After issuing "catalina.sh" and waiting for some time (up to > 25 seconds) it loses patience and gives a SIGTERM to tomcat process. > SIGTERM seems to bring tomcat down much faster. :) > What is the downside of using SIGTERM, if any? I tried issuing a SIGTERM to my JVM/Tomcat process running in development, and I got some messages in the app log file that indicated that the webapp was coming down. But, I didn't get any "shutting down" messages in catalina.out which leads me to believe that the shutdown wasn't entirely clean. > It does seem to bring > tomcat down in an orderly manner and much faster than "catalina.sh > stop". Well, definitely faster, but I'm not sure about orderly: you should check to see what things aren't stopping and determine if they are potentially disastrous it TERMinated. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuVQt8ACgkQ9CaO5/Lv0PD8LgCdFbaGLq1nfsqJJb4dbAsKY8hT lFEAoLUQHVzXZ9KnrQ79ExupS4cyKDfD =vn8E -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat shutdown: catalina.sh STOP vs SIGTERM
Sometimes on a busy system I have seen that "catalina.sh stop" does take a long time to shutdown tomcat. We are running another "monitoring service" on the system that monitors tomcat and few other system services. After issuing "catalina.sh" and waiting for some time (up to 25 seconds) it loses patience and gives a SIGTERM to tomcat process. SIGTERM seems to bring tomcat down much faster. What is the downside of using SIGTERM, if any? It does seem to bring tomcat down in an orderly manner and much faster than "catalina.sh stop".
Re: Tomcat shutdown issue
dBenjamin wrote: Can you please suggest how to scan the port and check the port is used by other application. On what kind of system are you ? Anyway, shut down Tomcat, then use the "netstat" command. Depending on the system on which you are, there are options to this command. Choose one that will show you either the process-id, or the name of the program which owns the sockets. Look for ports (on the "local" side) which have "LISTEN" around the end of the line. That should tell you the programs, apart from Tomcat, which are listening on various ports. Then turn on Tomcat, and enter the same command again. The differences between the first and second result should tell you which port Tomcat is listening on. I am using socket programming to check the port this is right? I do not understand this question. Explain what you are trying to do. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown issue
Can you please suggest how to scan the port and check the port is used by other application. I am using socket programming to check the port this is right? awarnier wrote: > > As I believe someone already told you, there is no need to repeat every > message twice. > > dBenjamin wrote: >> Tomcat not getting shutdown.. it shows the WARNING: StandardServer.await: >> Invalid command '' received >> can you pls find server.xml when I click shutdwon.bat server not >> listning >> it shows WARNING: StandardServer.await: Invalid command '' received >> >> can you please help me to solve this issues.. >> > Also, you were already given the answer before : > Probably (but we cannot tell that for sure just by your server.xml > file), it looks like /something/ is sending a normal HTTP request (*) > /to the shutdown port of the server/, instead of the normal HTTP port. > > Find which client is sending a HTTP request to his port : > > > instead of this port : > redirectPort="8757"/> > > and you will find the reason. > > (*) as a matter of fact, as per the logfile, it looks like this client > is making a connection to port 3006 and then just sending an empty > request. > If you have software doing some kind of port scanning, that may be the > culprit. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -- View this message in context: http://old.nabble.com/RE%3A-WARNING%3A-StandardServer.await%3A-Invalid-command-%27%27-received-tp27652985p27691253.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown issue
As I believe someone already told you, there is no need to repeat every message twice. dBenjamin wrote: Tomcat not getting shutdown.. it shows the WARNING: StandardServer.await: Invalid command '' received can you pls find server.xml when I click shutdwon.bat server not listning it shows WARNING: StandardServer.await: Invalid command '' received can you please help me to solve this issues.. Also, you were already given the answer before : Probably (but we cannot tell that for sure just by your server.xml file), it looks like /something/ is sending a normal HTTP request (*) /to the shutdown port of the server/, instead of the normal HTTP port. Find which client is sending a HTTP request to his port : instead of this port : and you will find the reason. (*) as a matter of fact, as per the logfile, it looks like this client is making a connection to port 3006 and then just sending an empty request. If you have software doing some kind of port scanning, that may be the culprit. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat shutdown issue
Tomcat not getting shutdown.. it shows the WARNING: StandardServer.await: Invalid command '' received can you pls find server.xml when I click shutdwon.bat server not listning it shows WARNING: StandardServer.await: Invalid command '' received can you please help me to solve this issues.. -- View this message in context: http://old.nabble.com/RE%3A-WARNING%3A-StandardServer.await%3A-Invalid-command-%27%27-received-tp27652985p27659380.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown automaticly after randomaly period of time
Tomcat1 wrote: hi, i have Tomcat 6.0.20. i config server.xml to work with SSL. the problem is that Tomcat shutdown after randomaly period of time and doesnt restart again. Hi. It is not very clear what your problem is. You have to be a bit more specific in your explanation. Also tell us on which platform this is running, and the JVM version The log which you included, shows a problem when Tomcat *starts*. The problem, when Tomcat starts, is that when it tries to create the Connector on port 8443, it finds that this port is already in use by another process. That is why it says : SEVERE: Error initializing endpoint java.net.BindException: Address already in use:8443 To see why that is, you need to : - stop Tomcat - find out if something else is using that port 8443. Under both Unix/Linux and Windows, you can use the "netstat" command for that. Look for a line that has ":8443" and "LISTEN" in it. - if nothing else is using it, it may be that when you believed that Tomcat was stopped, it was not. You have to resolve that first. Once that issue is sorted out, then maybe we can start looking why "Tomcat shutdown after a random period". That is not normal. Tomcat does not usually shutdown by itself. But that problem is not shown in the logfile that you copied here. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown automaticly after randomaly period of time
I think it happens when another process else uses port 8443 : java.net.BindException: Address already in use:8443 Regards, Zacheusz On Tue, Dec 22, 2009 at 7:18 AM, Tomcat1 wrote: > > hi, > i have Tomcat 6.0.20. i config server.xml to work with SSL. the problem is > that Tomcat shutdown after randomaly period of time and doesnt restart > again. > in server.xml i config: > > > > > > protocol="HTTP/1.1" > maxThreads="150" > scheme="https" > secure="true" > SSLEnabled="true" > keystoreFile="/certificate/.key" > keystorePass="changeit" > clientAuth="false" > sslProtocol="TLS" > URIEncoding="UTF-8" > compression="on" > > compressableMimeType="text/html,text/xml,text/css,text/plain,text/javascript,application/javascript,application/x-javascript" > /> > > > > > the log i get is: > Catalina.2009-12-21.log: > > Dec 21, 2009 3:13:45 AM org.apache.catalina.core.AprLifecycleListener init > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: /opt/cie > /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386 > Dec 21, 2009 3:13:46 AM org.apache.coyote.http11.Http11Protocol init > INFO: Initializing Coyote HTTP/1.1 on http-8443 > Dec 21, 2009 3:13:46 AM org.apache.catalina.startup.Catalina load > INFO: Initialization processed in 2784 ms > Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardService start > INFO: Starting service Catalina > Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardEngine start > INFO: Starting Servlet Engine: Apache Tomcat/6.0.20 > Dec 21, 2009 3:13:49 AM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deploying web application archive AdminManager.war > Dec 21, 2009 3:14:55 AM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deploying web application archive Publisher.war > Dec 21, 2009 3:15:36 AM org.apache.catalina.startup.HostConfig deployWAR > INFO: Deploying web application archive Advertiser.war > Dec 21, 2009 3:16:11 AM org.apache.coyote.http11.Http11Protocol start > INFO: Starting Coyote HTTP/1.1 on http-8443 > Dec 21, 2009 3:16:11 AM org.apache.jk.common.ChannelSocket init > INFO: JK: ajp13 listening on /0.0.0.0:8009 > Dec 21, 2009 3:16:12 AM org.apache.jk.server.JkMain start > INFO: Jk running ID=0 time=0/171 config=null > Dec 21, 2009 3:16:12 AM org.apache.catalina.startup.Catalina start > INFO: Server startup in 145986 ms > Dec 21, 2009 3:50:04 AM org.apache.catalina.core.AprLifecycleListener init > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: /opt/cie > /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386 > Dec 21, 2009 3:50:06 AM org.apache.coyote.http11.Http11Protocol init > SEVERE: Error initializing endpoint > java.net.BindException: Address already in use:8443 > at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:509) > at > org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176) > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1058) > at > org.apache.catalina.core.StandardService.initialize(StandardService.java:677) > at > org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795) > at org.apache.catalina.startup.Catalina.load(Catalina.java:535) > at org.apache.catalina.startup.Catalina.load(Catalina.java:555) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:592) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412) > Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load > SEVERE: Catalina.start > LifecycleException: Protocol handler initialization failed: > java.net.BindException: Address already in use:8443 > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1060) >
Tomcat shutdown automaticly after randomaly period of time
hi, i have Tomcat 6.0.20. i config server.xml to work with SSL. the problem is that Tomcat shutdown after randomaly period of time and doesnt restart again. in server.xml i config: the log i get is: Catalina.2009-12-21.log: Dec 21, 2009 3:13:45 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/cie /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386 Dec 21, 2009 3:13:46 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-8443 Dec 21, 2009 3:13:46 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 2784 ms Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.20 Dec 21, 2009 3:13:49 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive AdminManager.war Dec 21, 2009 3:14:55 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive Publisher.war Dec 21, 2009 3:15:36 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive Advertiser.war Dec 21, 2009 3:16:11 AM org.apache.coyote.http11.Http11Protocol start INFO: Starting Coyote HTTP/1.1 on http-8443 Dec 21, 2009 3:16:11 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 Dec 21, 2009 3:16:12 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/171 config=null Dec 21, 2009 3:16:12 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 145986 ms Dec 21, 2009 3:50:04 AM org.apache.catalina.core.AprLifecycleListener init INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/cie /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386 Dec 21, 2009 3:50:06 AM org.apache.coyote.http11.Http11Protocol init SEVERE: Error initializing endpoint java.net.BindException: Address already in use:8443 at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:509) at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176) at org.apache.catalina.connector.Connector.initialize(Connector.java:1058) at org.apache.catalina.core.StandardService.initialize(StandardService.java:677) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795) at org.apache.catalina.startup.Catalina.load(Catalina.java:535) at org.apache.catalina.startup.Catalina.load(Catalina.java:555) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412) Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load SEVERE: Catalina.start LifecycleException: Protocol handler initialization failed: java.net.BindException: Address already in use:8443 at org.apache.catalina.connector.Connector.initialize(Connector.java:1060) at org.apache.catalina.core.StandardService.initialize(StandardService.java:677) at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795) at org.apache.catalina.startup.Catalina.load(Catalina.java:535) at org.apache.catalina.startup.Catalina.load(Catalina.java:555) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412) Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load can you help me with that? thanks Ziv -- View this message in context: http://old.nabble.com/Tomcat-shutdown-automaticly-after-randomaly-period-of-time-tp26884442p26884442.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h
Re: Tomcat shutdown issues
2009/12/19 SRama : > > before starting the server I am checking both port address if any other > applicaion using the same port I am dynamicaly chaning the shutdown port and > http port. You won't be able to shutdown Tomcat using the shutdown script, if the script does not know what Shutdown port Tomcat listens to, and what "secret" it expects being written to that port. Those values are read from server.xml. If server.xml is wrong (is not the same one as was used to Start this Tomcat instance), you won't be able to use the shutdown script. Once again, http://tomcat.apache.org/tomcat-6.0-doc/config/server.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown issues
I have depolyed my application it's working fine. but I am not able to shutdown... Pejus M. Das wrote: > > Looks like your server started pretty quick. Are there any applications > deployed? What url are you hitting when you get the reset exception. Do > you > see the tomcat start page? > > > Pejus > > On Fri, Dec 18, 2009 at 8:10 PM, SRama wrote: > >> >> Hi >> I have some issues with tomcat, after starting the tomcat when I give >> request to my application tomcat console showing the following error >> message.. >> >> Dec 18, 2009 2:59:23 PM org.apache.catalina.startup.Catalina start >> INFO: Server startup in 3955 ms >> Dec 18, 2009 2:59:27 PM org.apache.catalina.core.StandardServer await >> WARNING: StandardServer.await: Invalid command 'GET /gdf2009 HTTP/1.1' >> received >> Dec 18, 2009 2:59:27 PM org.apache.catalina.core.StandardServer await >> WARNING: StandardServer.await: Invalid command 'GET /gdf2009 HTTP/1.1' >> received >> Dec 18, 2009 2:59:29 PM org.apache.catalina.core.StandardServer await >> WARNING: StandardServer.await: read: >> java.net.SocketException: Connection reset >>at java.net.SocketInputStream.read(Unknown Source) >>at java.net.SocketInputStream.read(Unknown Source) >>at >> org.apache.catalina.core.StandardServer.await(StandardServer.java:412 >> ) >>at org.apache.catalina.startup.Catalina.await(Catalina.java:630) >>at org.apache.catalina.startup.Catalina.start(Catalina.java:590) >>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >>at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >>at java.lang.reflect.Method.invoke(Unknown Source) >>at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) >>at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) >> Dec 18, 2009 2:59:29 PM org.apache.catalina.core.StandardServer await >> WARNING: StandardServer.await: Invalid command '' received >> I am not able to shutdown the server please let me know if you have any >> idea >> about this issue.. >> >> -- >> View this message in context: >> http://old.nabble.com/Tomcat-shutdown-issues-tp26849025p26849025.html >> Sent from the Tomcat - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > -- View this message in context: http://old.nabble.com/Tomcat-shutdown-issues-tp26849025p26850592.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
