AW: Java Agent and Tomcat shutdown

[Thomas Hoffmann (Speed4Trade GmbH)]

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

[logo]

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

[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
  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

[Amit Pande]

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

[Luis Rodríguez Fernández]

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

[Amit Pande]

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

[Christopher Schultz]

-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

[Konstantin Kolinko]

вс, 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

[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 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

[calder]

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

[Roger Marquis]

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

[Christopher Schultz]

-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

[calder]

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

[calder]

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

[Robert Hicks]

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

[Alex O'Ree]

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

[Mark Thomas]

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

[Alex O'Ree]

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

[Christopher Schultz]

-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

[Amit Pande]

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

[Jeffrey A Trimble]

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

[Mark Thomas]

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

[Vinicius Carvalho]

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

[Mark Thomas]

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

[Vinicius Carvalho]

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

[andrey eng]

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

[Christopher Schultz]

-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

[Vimal Jain]

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)

[Konstantin Kolinko]

2013/5/19 Nick Williams nicho...@nicholaswilliams.net:

 On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote:

 From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
 Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat 
 shutdown (memory leak, it looks like)

 Log4j 1 never required a listener to be configured to be shut down
 properly when an application is undeployed.

It did.
E.g. this discussion is from March 2004:
https://issues.apache.org/bugzilla/show_bug.cgi?id=26372#c2


 What bearing does that have on a different logging mechanism?

 To be fair, Log4j 2 is not a different logging mechanism. It is a new version 
 of Log4j 1. My point was mostly philosophical; it feels wrong to have to 
 configure a listener just to support logging.


You can configure the listener from within a library either
a) by providing a javax.servlet.ServletContainerInitializer (starting
with Servlet 3.0) or
b) by configuring it in a TLD file of a tag library (starting with JSP 1.2).



 It should be possible to do this without a listener.

 Not easily.

 Could a `finalize` method be used instead of a shutdown hook/listener?

 Finalizers should be avoided like the plague.  The gyrations the JVM has to 
 go through to handle them result in continual run time impacts, and require 
 at least two GC passes to actually get rid of the objects.

 The extra performance impact is bad, yes, when you're talking about an object 
 who has many short-lived instances in memory that could be garbage collected 
 regularly. However, when you're talking about a lone singleton instance that 
 is created when the application starts and garbage collected when the 
 application shuts down, I would argue this is not a problem at all. Of 
 course, I'm open to the idea that I could be proven wrong.


 What I don't know is if it is guaranteed to be called in non-web 
 applications
 when the JVM just shuts down.

 Finalizers are not called at JVM termination, since the process exit is 
 expected to release resources automatically.  You cannot actually count on a 
 finalizer ever being invoked; it's one of those seemed like a good idea at 
 the time things that is now widely regretted by JVM implementers.

 After some experimentation, it would appear that it's not so much that 
 finalizers are not called at JVM termination as it is that finalizers are not 
 called if the garbage collector never runs, and the garbage collector isn't 
 guaranteed to run at JVM shutdown.

There exists such API as JVM shutdown hooks. An issue with them though
is that if there are several hooks, then all of them are started at
the same time and run in parallel.

When Tomcat is run with JULI it takes care of JULI shutdown (a)
disables JULI's own shutdown hook via
ClassLoaderLogManager.setUseShutdownHook(false), b) shuts down JULI
from its own shutdown hook thread).

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Christopher Schultz]

-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)

[Nick Williams]

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)

[Christopher Schultz]

-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)

[Nick Williams]

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)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nick,

On 5/20/13 4:10 PM, Nick Williams wrote:
 
 On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Nick,
 
 On 5/20/13 12:48 PM, Nick Williams wrote:
 
 On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Nick,
 
 On 5/19/13 11:25 AM, Nick Williams wrote:
 Unfortunately, requiring users to call System.gc() before 
 shutdown for logging to work properly is no better than 
 requiring users to register a listener in a web
 application for logging to work properly. Surely there's a
 better way...
 
 Do you initialize your logging system in a 
 ServletContextListener (or similar)? If so, then you should 
 destroy it at the same level.
 
 If you aren't initializing your logging system in a 
 ServletContextListener... then how are you initializing it?
 
 Long ago, I abandoned log4j's auto-initialization primarily 
 because it sometimes guesses wrong.
 
 First, remember that this is Log4j 2, so things are obviously 
 different.
 
 It's different, but it's the same.
 
 Log4j initializes with the first call to
 LogManager#getLogger(), whenever that occurs. In my case
 loggers are static, so it happens when the classes are
 initialized. In the specific case of the replication project
 attached to the issue, it happens on the first request to the
 only Servlet in the application.
 
 Right. What I'm saying is that you should take full control over 
 the initialization (and destruction) of the logging system. Your
  ServletContextListeners should be invoked before your servlet 
 classes are loader.
 
 And I'm saying you shouldn't /have/ to. It should just work
 without you having to do much thinking. See below.
 
 
 Unfortunately, I've just about given up on it being possible to
  make logging work right without a ServletContextListener.
 Man oh man did I want to avoid that...
 
 You act like a ServletContextListener is some evil hack that
 should be avoided at all costs. Instead, it's exactly the right
 mechanism to do what you are trying to do: configure something at
 webapp launch and de-configure it when the webapp is stopped.
 
 Not what I'm saying at all. I love listeners. They are extremely 
 helpful, and I use them all the time.
 
 What I'm saying is that the concept of logging, philosophically,
 is supposed to be as unobtrusive as possible. Something you don't
 really have to think about how exactly it works; you just know to
 get a logger and put logging statements in your code and things
 just work. The act of having to set up a listener to initialize
 and deinitialize logging, to me, seems like more than Log4j users
 should have to worry about. Perhaps just as importantly, Log4j 1
 worked without a listener to initialize/deinitialize, so this is
 yet again one more thing users are going to have to do to switch
 from Log4j 1 to Log4j 2.

That's like saying that aspect-oriented programming should just work
without having to run the AOP compiler against the code, first.

This at least used to be a problem in log4j 1 as well: you had to call
LogManager.shutdown in order to free all the resources, flush all the
buffers, etc. when your webapp unloaded, otherwise you ran the risk of
pinning the old webapp's ClassLoader, etc. in memory. The only way to
run LogManager.shutdown() on webapp unload is to configure a
ServletContextListener.

 Thankfully, we can use web-fragments in Servlet 3.0 and higher to 
 configure the listener behind-the-scenes without the user even 
 knowing. That's much more acceptable in my book.

While I agree, it increases the amount of magic that I generally
prefer to keep to a minimum. I know I'm apparently an old guy who just
doesn't get it, but I honestly prefer explicit configuration to
auto-configuration. You can diagnose problems much more easily with
explicit configuration than by attaching a debugger and
stepping-through the entire bootstrap process to figure out wtf is
going on.

 Users of Servlet 2.5 will still have to declare them manually, but
 I think they will probably be the minority users.

Ha ha ha. Don't you see the posts from people trying to figure out how
to move their Tomcat 3.x installations to a new Windows 2000 server?
Again, I'm a apparently a dinosaur, but I don't have a single
servlet-3.0 webapp deployed in production anywhere. Not even in testing.

 So with a little more polishing of the Log4j 2 source code we can 
 make this a little better. I just wish there was a solution that 
 would work for both standalone applications /and/ web applications
 to initialize and deinitialize Log4j correctly without any users 
 (including Servlet 2.5 users) having to think about it.

The solution is to have a magic annotation-processor running all the
time in the JVM, right? Isn't that what OSGi is for?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - 

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

On May 20, 2013, at 4:39 PM, Christopher Schultz wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Nick,
 
 On 5/20/13 4:10 PM, Nick Williams wrote:
 
 On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Nick,
 
 On 5/20/13 12:48 PM, Nick Williams wrote:
 
 On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:
 
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
 
 Nick,
 
 On 5/19/13 11:25 AM, Nick Williams wrote:
 Unfortunately, requiring users to call System.gc() before 
 shutdown for logging to work properly is no better than 
 requiring users to register a listener in a web
 application for logging to work properly. Surely there's a
 better way...
 
 Do you initialize your logging system in a 
 ServletContextListener (or similar)? If so, then you should 
 destroy it at the same level.
 
 If you aren't initializing your logging system in a 
 ServletContextListener... then how are you initializing it?
 
 Long ago, I abandoned log4j's auto-initialization primarily 
 because it sometimes guesses wrong.
 
 First, remember that this is Log4j 2, so things are obviously 
 different.
 
 It's different, but it's the same.
 
 Log4j initializes with the first call to
 LogManager#getLogger(), whenever that occurs. In my case
 loggers are static, so it happens when the classes are
 initialized. In the specific case of the replication project
 attached to the issue, it happens on the first request to the
 only Servlet in the application.
 
 Right. What I'm saying is that you should take full control over 
 the initialization (and destruction) of the logging system. Your
 ServletContextListeners should be invoked before your servlet 
 classes are loader.
 
 And I'm saying you shouldn't /have/ to. It should just work
 without you having to do much thinking. See below.
 
 
 Unfortunately, I've just about given up on it being possible to
 make logging work right without a ServletContextListener.
 Man oh man did I want to avoid that...
 
 You act like a ServletContextListener is some evil hack that
 should be avoided at all costs. Instead, it's exactly the right
 mechanism to do what you are trying to do: configure something at
 webapp launch and de-configure it when the webapp is stopped.
 
 Not what I'm saying at all. I love listeners. They are extremely 
 helpful, and I use them all the time.
 
 What I'm saying is that the concept of logging, philosophically,
 is supposed to be as unobtrusive as possible. Something you don't
 really have to think about how exactly it works; you just know to
 get a logger and put logging statements in your code and things
 just work. The act of having to set up a listener to initialize
 and deinitialize logging, to me, seems like more than Log4j users
 should have to worry about. Perhaps just as importantly, Log4j 1
 worked without a listener to initialize/deinitialize, so this is
 yet again one more thing users are going to have to do to switch
 from Log4j 1 to Log4j 2.
 
 That's like saying that aspect-oriented programming should just work
 without having to run the AOP compiler against the code, first.
 
 This at least used to be a problem in log4j 1 as well: you had to call
 LogManager.shutdown in order to free all the resources, flush all the
 buffers, etc. when your webapp unloaded, otherwise you ran the risk of
 pinning the old webapp's ClassLoader, etc. in memory. The only way to
 run LogManager.shutdown() on webapp unload is to configure a
 ServletContextListener.
 
 Thankfully, we can use web-fragments in Servlet 3.0 and higher to 
 configure the listener behind-the-scenes without the user even 
 knowing. That's much more acceptable in my book.
 
 While I agree, it increases the amount of magic that I generally
 prefer to keep to a minimum. I know I'm apparently an old guy who just
 doesn't get it, but I honestly prefer explicit configuration to
 auto-configuration. You can diagnose problems much more easily with
 explicit configuration than by attaching a debugger and
 stepping-through the entire bootstrap process to figure out wtf is
 going on.
 
 Users of Servlet 2.5 will still have to declare them manually, but
 I think they will probably be the minority users.
 
 Ha ha ha. Don't you see the posts from people trying to figure out how
 to move their Tomcat 3.x installations to a new Windows 2000 server?
 Again, I'm a apparently a dinosaur, but I don't have a single
 servlet-3.0 webapp deployed in production anywhere. Not even in testing.

Oh, I see the posts. I just figure if they're that far behind they won't be 
using Log4j 2 for at least another 10 years.

Nick

 
 So with a little more polishing of the Log4j 2 source code we can 
 make this a little better. I just wish there was a solution that 
 would work for both standalone applications /and/ web applications
 to initialize and deinitialize Log4j correctly without any users 
 (including Servlet 2.5 users) having to think about it.
 
 The 

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Mark Eggers]

On 5/20/2013 2:45 PM, Nick Williams wrote:


On May 20, 2013, at 4:39 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Nick,

On 5/20/13 4:10 PM, Nick Williams wrote:


On May 20, 2013, at 2:59 PM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Nick,

On 5/20/13 12:48 PM, Nick Williams wrote:


On May 20, 2013, at 10:56 AM, Christopher Schultz wrote:


-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Nick,

On 5/19/13 11:25 AM, Nick Williams wrote:

Unfortunately, requiring users to call System.gc()
before shutdown for logging to work properly is no better
than requiring users to register a listener in a web
application for logging to work properly. Surely there's
a better way...


Do you initialize your logging system in a
ServletContextListener (or similar)? If so, then you
should destroy it at the same level.

If you aren't initializing your logging system in a
ServletContextListener... then how are you initializing
it?

Long ago, I abandoned log4j's auto-initialization
primarily because it sometimes guesses wrong.


First, remember that this is Log4j 2, so things are
obviously different.


It's different, but it's the same.


Log4j initializes with the first call to
LogManager#getLogger(), whenever that occurs. In my case
loggers are static, so it happens when the classes are
initialized. In the specific case of the replication project
attached to the issue, it happens on the first request to
the only Servlet in the application.


Right. What I'm saying is that you should take full control
over the initialization (and destruction) of the logging
system. Your ServletContextListeners should be invoked before
your servlet classes are loader.


And I'm saying you shouldn't /have/ to. It should just work
without you having to do much thinking. See below.




Unfortunately, I've just about given up on it being possible
to make logging work right without a
ServletContextListener. Man oh man did I want to avoid
that...


You act like a ServletContextListener is some evil hack that
should be avoided at all costs. Instead, it's exactly the
right mechanism to do what you are trying to do: configure
something at webapp launch and de-configure it when the webapp
is stopped.


Not what I'm saying at all. I love listeners. They are extremely
helpful, and I use them all the time.

What I'm saying is that the concept of logging, philosophically,
is supposed to be as unobtrusive as possible. Something you
don't really have to think about how exactly it works; you just
know to get a logger and put logging statements in your code and
things just work. The act of having to set up a listener to
initialize and deinitialize logging, to me, seems like more than
Log4j users should have to worry about. Perhaps just as
importantly, Log4j 1 worked without a listener to
initialize/deinitialize, so this is yet again one more thing
users are going to have to do to switch from Log4j 1 to Log4j 2.


That's like saying that aspect-oriented programming should just
work without having to run the AOP compiler against the code,
first.

This at least used to be a problem in log4j 1 as well: you had to
call LogManager.shutdown in order to free all the resources, flush
all the buffers, etc. when your webapp unloaded, otherwise you ran
the risk of pinning the old webapp's ClassLoader, etc. in memory.
The only way to run LogManager.shutdown() on webapp unload is to
configure a ServletContextListener.


Thankfully, we can use web-fragments in Servlet 3.0 and higher
to configure the listener behind-the-scenes without the user
even knowing. That's much more acceptable in my book.


While I agree, it increases the amount of magic that I generally
prefer to keep to a minimum. I know I'm apparently an old guy who
just doesn't get it, but I honestly prefer explicit configuration
to auto-configuration. You can diagnose problems much more easily
with explicit configuration than by attaching a debugger and
stepping-through the entire bootstrap process to figure out wtf is
going on.


Users of Servlet 2.5 will still have to declare them manually,
but I think they will probably be the minority users.


Ha ha ha. Don't you see the posts from people trying to figure out
how to move their Tomcat 3.x installations to a new Windows 2000
server? Again, I'm a apparently a dinosaur, but I don't have a
single servlet-3.0 webapp deployed in production anywhere. Not even
in testing.


Oh, I see the posts. I just figure if they're that far behind they
won't be using Log4j 2 for at least another 10 years.

Nick



Hopefully sometime this year (currently porting one of those types of 
applications).


I do have a Maven artifact with some utility listeners that I make use 
of (including a log4j listener). I just add the dependency, modify the 
web.xml accordingly, and I'm good to go.


Yes, annotations would make things a little less cumbersome. However, I 
still like seeing everything. Maybe once I get a 

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Mark Thomas]

On 19/05/2013 05:57, Nick Williams wrote:
 Can one of the very knowledgeable developers that have been
 discussing memory leaks in the last few days (re: Possible
 false-postive with JreMemoryLeakPreventionListener and Tomcat's JDBC
 Pool and OracleTimeoutPollingThread) chime in on this Log4j 2 bug
 [1]?
 
 Log4j 2 appears to be registering a shutdown hook that, I believe,
 will result in a memory leak in Tomcat. The
 JreMemoryLeakPreventionListener does not detect it (which might be a
 separate Tomcat bug, assuming I'm right that it's a memory leak). I
 don't know nearly as much about class loaders and memory leaks in a
 web application as some of the guys I've read talking on here the
 last few days, and it would be helpful for us to get the
 knowledgeable opinion of one or more Tomcat developers about how to
 solve this.

It looks like Ralph has already answered this [2].

If log4j2 is initialised by the webapp, it needs to be shutdown by the
webapp.

 (Note: I don't normally post to both lists, but since the memory leak
 topic was occurring on the user's list, and I also wanted to get the
 attention of as many developers as possible, I made an exception this
 time.)

No matter how important you think your issue is, please do not cross
post. As a general guide, if you aren't sure, use the users list. The
committers are all active or lurking here so they will all see it and
will move the discussion to the dev list of necessary.

Mark

[1] https://issues.apache.org/jira/browse/LOG4J2-223

[2]
https://issues.apache.org/jira/browse/LOG4J2-223?focusedCommentId=13661501page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13661501

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

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)

[Caldarale, Charles R]

 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)

[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.
 
 What bearing does that have on a different logging mechanism?

To be fair, Log4j 2 is not a different logging mechanism. It is a new version 
of Log4j 1. My point was mostly philosophical; it feels wrong to have to 
configure a listener just to support logging.

 
 It should be possible to do this without a listener.
 
 Not easily.
 
 Could a `finalize` method be used instead of a shutdown hook/listener?
 
 Finalizers should be avoided like the plague.  The gyrations the JVM has to 
 go through to handle them result in continual run time impacts, and require 
 at least two GC passes to actually get rid of the objects.

The extra performance impact is bad, yes, when you're talking about an object 
who has many short-lived instances in memory that could be garbage collected 
regularly. However, when you're talking about a lone singleton instance that is 
created when the application starts and garbage collected when the application 
shuts down, I would argue this is not a problem at all. Of course, I'm open to 
the idea that I could be proven wrong.

 
 What I don't know is if it is guaranteed to be called in non-web 
 applications 
 when the JVM just shuts down.
 
 Finalizers are not called at JVM termination, since the process exit is 
 expected to release resources automatically.  You cannot actually count on a 
 finalizer ever being invoked; it's one of those seemed like a good idea at 
 the time things that is now widely regretted by JVM implementers.

After some experimentation, it would appear that it's not so much that 
finalizers are not called at JVM termination as it is that finalizers are not 
called if the garbage collector never runs, and the garbage collector isn't 
guaranteed to run at JVM shutdown. However, if you call System.gc() right 
before the JVM shuts down, finalizers appear to run every time. Unfortunately, 
requiring users to call System.gc() before shutdown for logging to work 
properly is no better than requiring users to register a listener in a web 
application for logging to work properly. Surely there's a better way...

While I do not disagree that finalizers are very often misused, they are not 
without their uses. I find it hard to believe that the Sun JRE 6 source code 
would contain 50 uses of finalizers if they should never be used. You'd think 
if they regretted creating the method so much they would deprecate it and/or 
document clearly that it's best to never implement a finalizer, but the 
documentation for finalizers makes no such assertion, even in the latest Java 8.

 
 - Chuck
 
 
 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
 MATERIAL and is thus for use only by the intended recipient. If you received 
 this in error, please contact the sender and delete the e-mail and its 
 attachments from all computers.
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

LOG4J2-223: IllegalStateException thrown during Tomcat shutdown (memory leak, it looks like)

[Nick Williams]

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.)

tomcat shutdown clarification

[Davis, Chad]

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 clarification

[Caldarale, Charles R]

 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

RE: tomcat shutdown clarification

[Davis, Chad]

  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

[Caldarale, Charles R]

 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

[Christopher Schultz]

-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

Tomcat Shutdown

[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.

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

[Konstantin Kolinko]

2012/1/7 Kamal Sheikh kama...@gmail.com:
 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

[Kamal Sheikh]

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
knst.koli...@gmail.comwrote:

 2012/1/7 Kamal Sheikh kama...@gmail.com:
  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

[Caldarale, Charles R]

 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

[Kamal Sheikh]

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 issues

[Rainer Jung]

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

Tomcat shutdown issues

[April Easton]

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 0xb48180a8 (a java.lang.ref.Reference$Lock)
 

Re: Tomcat shutdown issues

[Pid]

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

RE: Tomcat shutdown issues

[Caldarale, Charles R]

 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

[April Easton]

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

[April Easton]

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: Getting the Tomcat shutdown port

[Olivier Lefevre]

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

[Mark Thomas]

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

[Olivier Lefevre]

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

[Mark Thomas]

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

[Caldarale, Charles R]

 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

[Olivier Lefevre]

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

Getting the Tomcat shutdown port

[Olivier Lefevre]

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: Getting the Tomcat shutdown port

[Mark Thomas]

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

Re: Getting the Tomcat shutdown port

[Olivier Lefevre]

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

[Mark Thomas]

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

[Olivier Lefevre]

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

[Mark Thomas]

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

[Caldarale, Charles R]

 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

[Olivier Lefevre]

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

[Mark Thomas]

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

[Olivier Lefevre]

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

Tomcat shutdown

[János Löbb]

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

Re: Tomcat shutdown

[Konstantin Kolinko]

2011/2/1 János Löbb janos.l...@yale.edu:
 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

Re: Tomcat shutdown

[János Löbb]

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 janos.l...@yale.edu:
 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

[OT] Re: Tomcat Shutdown suddenly / random

[André Warnier]

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

[Kees Jan Koster]

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

Tomcat Shutdown suddenly / random

[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

[Pid]

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

Re: Tomcat Shutdown suddenly / random

[Harry Metske]

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 apocalyps...@gmx.de

 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

[Christopher Schultz]

-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

[Carl]

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 ch...@christopherschultz.net

To: Tomcat Users List users@tomcat.apache.org
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

[Mark Thomas]

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

tomcat shutdown: catalina.sh STOP vs SIGTERM

[Aggarwal, Ajay]

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: catalina.sh STOP vs SIGTERM

[Christopher Schultz]

-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

[Hassan Schroeder]

On Mon, Mar 8, 2010 at 9:53 AM, Aggarwal, Ajay
ajay.aggar...@stratus.com 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

[Aggarwal, Ajay]

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

[Konstantin Kolinko]

2010/3/8 Aggarwal, Ajay ajay.aggar...@stratus.com:
 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

[Christopher Schultz]

-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

[Caldarale, Charles R]

 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 issue

[dBenjamin]

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 :
   Server port=3006 shutdown=SHUTDOWN
 
 instead of this port :
  Connector connectionTimeout=3 port=6876 protocol=HTTP/1.1
 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

[André Warnier]

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

[André Warnier]

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 :
 Server port=3006 shutdown=SHUTDOWN

instead of this port :
Connector connectionTimeout=3 port=6876 protocol=HTTP/1.1
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

RE: Tomcat shutdown issue

[dBenjamin]

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..

 
?xml version=1.0 encoding=UTF-8? 
Server port=3006 shutdown=SHUTDOWN 

  !--APR library loader. Documentation at /docs/apr.html -- 
  Listener SSLEngine=on
className=org.apache.catalina.core.AprLifecycleListener/ 
  !--Initialize Jasper prior to webapps are loaded. Documentation at
/docs/jasper-howto.html -- 
  Listener className=org.apache.catalina.core.JasperListener/ 
  !-- JMX Support for the Tomcat server. Documentation at
/docs/non-existent.html -- 
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener/ 
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener/ 

  !-- Global JNDI resources 
   Documentation at /docs/jndi-resources-howto.html 
  -- 
  GlobalNamingResources 
!-- Editable user database that can also be used by 
 UserDatabaseRealm to authenticate users 
-- 
Resource auth=Container description=User database that can be
updated and saved
factory=org.apache.catalina.users.MemoryUserDatabaseFactory
name=UserDatabase pathname=conf/tomcat-users.xml
type=org.apache.catalina.UserDatabase/ 
  /GlobalNamingResources 

  !-- A Service is a collection of one or more Connectors that share 
   a single Container Note:  A Service is not itself a Container, 
   so you may not define subcomponents such as Valves at this level. 
   Documentation at /docs/config/service.html 
   -- 
  Service name=Catalina 
  
  
Connector connectionTimeout=3 port=6876 protocol=HTTP/1.1
redirectPort=8757/ 





!-- An Engine represents the entry point (within Catalina) that
processes 
 every request.  The Engine implementation for Tomcat stand alone 
 analyzes the HTTP headers included with the request, and passes
them 
 on to the appropriate Host (virtual host). 
 Documentation at /docs/config/engine.html -- 

!-- You should set jvmRoute to support load-balancing via AJP ie : 
Engine name=Standalone defaultHost=localhost jvmRoute=jvm1 
-- 
Engine defaultHost=localhost name=Catalina 

  

  !-- This Realm uses the UserDatabase configured in the global JNDI 
   resources under the key UserDatabase.  Any edits 
   that are performed against this UserDatabase are immediately 
   available for use by the Realm.  -- 
  Realm className=org.apache.catalina.realm.UserDatabaseRealm
resourceName=UserDatabase/ 

  !-- Define the default virtual host 
   Note: XML Schema validation will not work with Xerces 2.2. 
   -- 
  Host appBase=webapps autoDeploy=true name=localhost
unpackWARs=true xmlNamespaceAware=false xmlValidation=false  
   


/Host 

  
/Engine 
  /Service 
/Server 


-- 
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

[André Warnier]

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 usenull: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

Tomcat shutdown automaticly after randomaly period of time

[Tomcat1]

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:
!--Connector port=8080 protocol=HTTP/1.1 
   connectionTimeout=2 
   redirectPort=8443 /--
!-- A Connector using the shared thread pool--
!--
Connector executor=tomcatThreadPool
   port=8080 protocol=HTTP/1.1 
   connectionTimeout=2 
   redirectPort=443 /
--   
!-- Define a SSL HTTP/1.1 Connector on port 8443
 This connector uses the JSSE configuration, when using APR, the 
 connector should be using the OpenSSL style configuration
 described in the APR documentation --

Connector port=8443
   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
/

!-- Define an AJP 1.3 Connector on port 8009 --
Connector port=8009 protocol=AJP/1.3 redirectPort=443 /

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 usenull: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 usenull:8443
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:677

Re: Tomcat shutdown automaticly after randomaly period of time

[Zacheusz Siedlecki]

I think it happens when another process else uses port 8443 :
java.net.BindException: Address already in usenull:8443
Regards,
  Zacheusz

On Tue, Dec 22, 2009 at 7:18 AM, Tomcat1 z...@amdocs.com 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:
 !--Connector port=8080 protocol=HTTP/1.1
               connectionTimeout=2
               redirectPort=8443 /--
    !-- A Connector using the shared thread pool--
    !--
    Connector executor=tomcatThreadPool
               port=8080 protocol=HTTP/1.1
               connectionTimeout=2
               redirectPort=443 /
    --
    !-- Define a SSL HTTP/1.1 Connector on port 8443
         This connector uses the JSSE configuration, when using APR, the
         connector should be using the OpenSSL style configuration
         described in the APR documentation --

        Connector port=8443
           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
 /

    !-- Define an AJP 1.3 Connector on port 8009 --
    Connector port=8009 protocol=AJP/1.3 redirectPort=443 /

 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 usenull: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

Tomcat shutdown issues

[SRama]

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

Re: Tomcat shutdown issues

[Pejus M. Das]

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 su...@techie.com 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