AW: Java Agent and Tomcat shutdown

2023-05-11 Thread 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

2023-05-11 Thread 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

2023-05-11 Thread 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

2020-06-08 Thread 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

2020-06-08 Thread 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

2020-06-06 Thread 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

2020-05-11 Thread 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

2020-05-10 Thread 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

2020-05-10 Thread 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

2020-05-10 Thread 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

2020-05-09 Thread 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

2020-05-09 Thread 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

2020-05-08 Thread 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

2020-05-08 Thread 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

2020-05-08 Thread 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

2018-03-17 Thread 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

2018-03-17 Thread 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

2018-03-16 Thread 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

2016-09-17 Thread 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

2016-09-17 Thread 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

2016-08-24 Thread 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

2016-04-05 Thread 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

2016-04-05 Thread 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

2016-04-05 Thread 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

2016-04-05 Thread 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

2014-04-11 Thread 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

2013-08-09 Thread 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

2013-08-08 Thread 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)

2013-05-20 Thread 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 

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

2013-05-20 Thread 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 p

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

2013-05-20 Thread 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

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

2013-05-20 Thread 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)

2013-05-20 Thread 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)

2013-05-20 Thread 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)

2013-05-20 Thread 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)

2013-05-20 Thread Konstantin Kolinko
2013/5/19 Nick Williams :
>
> On May 19, 2013, at 10:01 AM, Caldarale, Charles R wrote:
>
>>> From: Nick Williams [mailto:nicho...@nicholaswilliams.net]
>>> Subject: Re: LOG4J2-223: IllegalStateException thrown during Tomcat 
>>> shutdown (memory leak, it looks like)
>>
>>> Log4j 1 never required a listener to be configured to be shut down
>>> properly when an application is undeployed.

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

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


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


>>
>>> It should be possible to do this without a listener.
>>
>> Not easily.
>>
>>> Could a `finalize` method be used instead of a shutdown hook/listener?
>>
>> Finalizers should be avoided like the plague.  The gyrations the JVM has to 
>> go through to handle them result in continual run time impacts, and require 
>> at least two GC passes to actually get rid of the objects.
>
> The extra performance impact is bad, yes, when you're talking about an object 
> who has many short-lived instances in memory that could be garbage collected 
> regularly. However, when you're talking about a lone singleton instance that 
> is created when the application starts and garbage collected when the 
> application shuts down, I would argue this is not a problem at all. Of 
> course, I'm open to the idea that I could be proven wrong.
>
>>
>>> What I don't know is if it is guaranteed to be called in non-web 
>>> applications
>>> when the JVM just shuts down.
>>
>> Finalizers are not called at JVM termination, since the process exit is 
>> expected to release resources automatically.  You cannot actually count on a 
>> finalizer ever being invoked; it's one of those "seemed like a good idea at 
>> the time" things that is now widely regretted by JVM implementers.
>
> After some experimentation, it would appear that it's not so much that 
> finalizers are not called at JVM termination as it is that finalizers are not 
> called if the garbage collector never runs, and the garbage collector isn't 
> guaranteed to run at JVM shutdown.

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

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

Best regards,
Konstantin Kolinko

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



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

2013-05-19 Thread 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



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

2013-05-19 Thread 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)

2013-05-19 Thread 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)

2013-05-19 Thread 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=13661501&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13661501

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



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

2013-05-18 Thread 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.)

Re: tomcat shutdown clarification

2012-08-14 Thread 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



RE: tomcat shutdown clarification

2012-08-14 Thread 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

2012-08-14 Thread 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

2012-08-14 Thread 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



tomcat shutdown clarification

2012-08-14 Thread 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

2012-01-06 Thread 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

2012-01-06 Thread 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

2012-01-06 Thread 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
wrote:

> 2012/1/7 Kamal Sheikh :
> > Hi, I'm new to this but please direct me if I'm posting to the wrong
> list.
> >
> > Our Tomcat has suddenly stopped working this morning and now wouldn't
> start
> > -- it responds simply by saying: "failed".
>
> What is in the logs?
>
> Maybe there is no free space on the harddrive?
>
> Maybe there is stale pid file from previous Tomcat run?
>
> >
> > Is there anything going on with OpenJDK and Tomcat?
> >
> > Here's our configuration:
> >
> > Java:
> >
> >  java version "1.6.0_20"
> > OpenJDK Runtime Environment (IcedTea6 1.9.9)
> (6b20-1.9.9-0ubuntu1~10.04.2)
> > OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
> >
> > Tomcat
> >
> > Server version: Apache Tomcat/6.0.24
> > Server built:   March 24 2011 1829
>
> 6.0.24 was officially released on 2010-01-21 which is more than a year
> earlier than the above "build" date.
>
> There were a lot of important fixes since then, including some fixes
> to the startup scripts as well.
>
> > Server number:  ...0
> > OS Name:Linux
> > OS Version: 2.6.32-32-server
> > Architecture:   amd64
> > JVM Version:1.6.0_20-b20
> > JVM Vendor: Sun Microsystems Inc.
> >
> > OS
> >
> > Ubuntu 10.04.2 LTS
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Tomcat Shutdown

2012-01-06 Thread Konstantin Kolinko
2012/1/7 Kamal Sheikh :
> Hi, I'm new to this but please direct me if I'm posting to the wrong list.
>
> Our Tomcat has suddenly stopped working this morning and now wouldn't start
> -- it responds simply by saying: "failed".

What is in the logs?

Maybe there is no free space on the harddrive?

Maybe there is stale pid file from previous Tomcat run?

>
> Is there anything going on with OpenJDK and Tomcat?
>
> Here's our configuration:
>
> Java:
>
>  java version "1.6.0_20"
> OpenJDK Runtime Environment (IcedTea6 1.9.9) (6b20-1.9.9-0ubuntu1~10.04.2)
> OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)
>
> Tomcat
>
> Server version: Apache Tomcat/6.0.24
> Server built:   March 24 2011 1829

6.0.24 was officially released on 2010-01-21 which is more than a year
earlier than the above "build" date.

There were a lot of important fixes since then, including some fixes
to the startup scripts as well.

> Server number:  ...0
> OS Name:        Linux
> OS Version:     2.6.32-32-server
> Architecture:   amd64
> JVM Version:    1.6.0_20-b20
> JVM Vendor:     Sun Microsystems Inc.
>
> OS
>
> Ubuntu 10.04.2 LTS

Best regards,
Konstantin Kolinko

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



Tomcat Shutdown

2012-01-06 Thread 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 issues

2011-06-11 Thread 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



RE: Tomcat shutdown issues

2011-06-10 Thread 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: Tomcat shutdown issues

2011-06-10 Thread 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

2011-06-10 Thread 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

2011-06-10 Thread 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


Tomcat shutdown issues

2011-06-10 Thread 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 <0x00

Re: Getting the Tomcat shutdown port

2011-03-01 Thread 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



RE: Getting the Tomcat shutdown port

2011-03-01 Thread 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

2011-03-01 Thread 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

2011-03-01 Thread 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

2011-03-01 Thread 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

2011-03-01 Thread 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

2011-02-28 Thread 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



Re: Getting the Tomcat shutdown port

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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

2011-02-28 Thread 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



Getting the Tomcat shutdown port

2011-02-28 Thread 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: Tomcat shutdown

2011-02-01 Thread 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 :
>> It is Tomcat 6.0.29 on OSX 10.6.5.  If I ssh to the machine and shutdown 
>> Tomcat and later boot it back again, all those components which are using 
>> AWT are not usable.  However if I Apple Remote Desktop to the machine, open 
>> up Terminal there, shut down Tomcat and start it up, all AWT components will 
>> work just fine.
>> 
>> Any good explanation ?
>> 
> 
> Create $CATALINA_BASE/bin/setenv.sh with the following text
> 
> CATALINA_OPTS="-Djava.awt.headless=true"
> 
> Google for "java.awt.headless" for more info,
> e.g. look here:
> http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/
> 
> Best regards,
> Konstantin Kolinko
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org


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



Re: Tomcat shutdown

2011-02-01 Thread Konstantin Kolinko
2011/2/1 János Löbb :
> It is Tomcat 6.0.29 on OSX 10.6.5.  If I ssh to the machine and shutdown 
> Tomcat and later boot it back again, all those components which are using AWT 
> are not usable.  However if I Apple Remote Desktop to the machine, open up 
> Terminal there, shut down Tomcat and start it up, all AWT components will 
> work just fine.
>
> Any good explanation ?
>

Create $CATALINA_BASE/bin/setenv.sh with the following text

CATALINA_OPTS="-Djava.awt.headless=true"

Google for "java.awt.headless" for more info,
e.g. look here:
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/

Best regards,
Konstantin Kolinko

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



Tomcat shutdown

2011-02-01 Thread 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



[OT] Re: Tomcat Shutdown suddenly / random

2010-04-18 Thread 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

2010-04-17 Thread 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



Re: Tomcat Shutdown suddenly / random

2010-04-16 Thread 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



Re: Tomcat Shutdown suddenly / random

2010-04-16 Thread 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" 

To: "Tomcat Users List" 
Sent: Friday, April 16, 2010 3:58 PM
Subject: Re: Tomcat Shutdown suddenly / random



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Harry,

On 4/16/2010 2:35 PM, Harry Metske wrote:

could it be that something is sending your tomcat process a TERM signal,
logfiles in /var/log might tell something ?
or one of your applications issues a System.exit() under certain
circumstances ?


+1

I'm not sure what the best way is to catch TERM signals. I guess you
could write some JNI code to install a signal handler that logs the
signal and details (if available) about the process that sent the signal.

I don't believe Tomcat has any System.exit calls in it, so you could
grep your code looking for such calls.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvIz4IACgkQ9CaO5/Lv0PAT4QCgtsZhK/DtHhS8KVjYUhCA2mdG
dVwAn1DOyYGJLIfV5hBl1GWaTF8CZUO3
=ASpm
-END PGP SIGNATURE-

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





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



Re: Tomcat Shutdown suddenly / random

2010-04-16 Thread 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

2010-04-16 Thread 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 

> 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

2010-04-16 Thread 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


Tomcat Shutdown suddenly / random

2010-04-16 Thread 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: catalina.sh STOP vs SIGTERM

2010-03-08 Thread 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: catalina.sh STOP vs SIGTERM

2010-03-08 Thread 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

2010-03-08 Thread Konstantin Kolinko
2010/3/8 Aggarwal, Ajay :
> When I send SIGTERM to tomcat, I actually do get
>

Tomcat installs a shutdown hook into JVM so that it will shutdown gracefully.

There is a problem though that if there are several shutdown hooks
then they run in parallel. That is particularly visible in 6.0.24,
because logging system shutdown was made more robust.

This shutdown hooks race is already fixed in the current 6.0.x sources
-- that will be 6.0.26.

Best regards,
Konstantin Kolinko

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



RE: tomcat shutdown: catalina.sh STOP vs SIGTERM

2010-03-08 Thread 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

2010-03-08 Thread Hassan Schroeder
On Mon, Mar 8, 2010 at 9:53 AM, Aggarwal, Ajay
 wrote:

> What is  the downside of using SIGTERM, if any? It does seem to bring
> tomcat down in an orderly manner and much faster than "catalina.sh
> stop".

Yeah, "seem to" would be the operative phrase, I think.

A leap off a tall structure might "seem to" be much like flying. Initially. :-)

As Chris already said: check your app to see what's slow to exit, and
what the consequences of an ungraceful stop might be.

-- 
Hassan Schroeder  hassan.schroe...@gmail.com
twitter: @hassan

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



Re: tomcat shutdown: catalina.sh STOP vs SIGTERM

2010-03-08 Thread 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



tomcat shutdown: catalina.sh STOP vs SIGTERM

2010-03-08 Thread 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 issue

2010-02-22 Thread 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

2010-02-22 Thread 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 :
>   
> 
> instead of this port :
>   redirectPort="8757"/>
> 
> and you will find the reason.
> 
> (*) as a matter of fact, as per the logfile, it looks like this client 
> is making a connection to port 3006 and then just sending an empty
> request.
> If you have software doing some kind of port scanning, that may be the 
> culprit.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/RE%3A-WARNING%3A-StandardServer.await%3A-Invalid-command-%27%27-received-tp27652985p27691253.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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



Re: Tomcat shutdown issue

2010-02-20 Thread 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 :
 

instead of this port :


and you will find the reason.

(*) as a matter of fact, as per the logfile, it looks like this client 
is making a connection to port 3006 and then just sending an empty request.
If you have software doing some kind of port scanning, that may be the 
culprit.


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



RE: Tomcat shutdown issue

2010-02-19 Thread 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..

 
 
 

   
   
   
   
   
   
   

   
   
 
 
   

   
   
  
  
 





 

 
 

  

   
   

   

   


 

  
 
   
 


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

2009-12-22 Thread 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 use:8443


To see why that is, you need to :
- stop Tomcat
- find out if something else is using that port 8443.
Under both Unix/Linux and Windows, you can use the "netstat" command for 
that.  Look for a line that has ":8443" and "LISTEN" in it.
- if nothing else is using it, it may be that when you believed that 
Tomcat was stopped, it was not.


You have to resolve that first.

Once that issue is sorted out, then maybe we can start looking why 
"Tomcat shutdown after a random period".

That is not normal.  Tomcat does not usually shutdown by itself.
But that problem is not shown in the logfile that you copied here.



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



Re: Tomcat shutdown automaticly after randomaly period of time

2009-12-21 Thread Zacheusz Siedlecki
I think it happens when another process else uses port 8443 :
java.net.BindException: Address already in use:8443
Regards,
  Zacheusz

On Tue, Dec 22, 2009 at 7:18 AM, Tomcat1  wrote:
>
> hi,
> i have Tomcat 6.0.20. i config server.xml to work with SSL. the problem is
> that Tomcat shutdown after randomaly period of time and doesnt restart
> again.
> in server.xml i config:
> 
>    
>    
>    
>
>                   protocol="HTTP/1.1"
>           maxThreads="150"
>           scheme="https"
>           secure="true"
>           SSLEnabled="true"
>           keystoreFile="/certificate/.key"
>           keystorePass="changeit"
>           clientAuth="false"
>           sslProtocol="TLS"
>           URIEncoding="UTF-8"
>           compression="on"
>
> compressableMimeType="text/html,text/xml,text/css,text/plain,text/javascript,application/javascript,application/x-javascript"
> />
>
>    
>    
>
> the log i get is:
> Catalina.2009-12-21.log:
>
> Dec 21, 2009 3:13:45 AM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal
> performance in production environments was not found on the
> java.library.path: /opt/cie
> /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386
> Dec 21, 2009 3:13:46 AM org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8443
> Dec 21, 2009 3:13:46 AM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 2784 ms
> Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardService start
> INFO: Starting service Catalina
> Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.20
> Dec 21, 2009 3:13:49 AM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deploying web application archive AdminManager.war
> Dec 21, 2009 3:14:55 AM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deploying web application archive Publisher.war
> Dec 21, 2009 3:15:36 AM org.apache.catalina.startup.HostConfig deployWAR
> INFO: Deploying web application archive Advertiser.war
> Dec 21, 2009 3:16:11 AM org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8443
> Dec 21, 2009 3:16:11 AM org.apache.jk.common.ChannelSocket init
> INFO: JK: ajp13 listening on /0.0.0.0:8009
> Dec 21, 2009 3:16:12 AM org.apache.jk.server.JkMain start
> INFO: Jk running ID=0 time=0/171  config=null
> Dec 21, 2009 3:16:12 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 145986 ms
> Dec 21, 2009 3:50:04 AM org.apache.catalina.core.AprLifecycleListener init
> INFO: The APR based Apache Tomcat Native library which allows optimal
> performance in production environments was not found on the
> java.library.path: /opt/cie
> /java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386
> Dec 21, 2009 3:50:06 AM org.apache.coyote.http11.Http11Protocol init
> SEVERE: Error initializing endpoint
> java.net.BindException: Address already in use:8443
>        at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:509)
>        at
> org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
>        at
> org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
>        at
> org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
>        at
> org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
>        at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
>        at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:592)
>        at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
>        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
> Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load
> SEVERE: Catalina.start
> LifecycleException:  Protocol handler initialization failed:
> java.net.BindException: Address already in use:8443
>        at
> org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
>        

Tomcat shutdown automaticly after randomaly period of time

2009-12-21 Thread 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:


   







the log i get is:
Catalina.2009-12-21.log:

Dec 21, 2009 3:13:45 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: /opt/cie
/java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386
Dec 21, 2009 3:13:46 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8443
Dec 21, 2009 3:13:46 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2784 ms
Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Dec 21, 2009 3:13:46 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.20
Dec 21, 2009 3:13:49 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive AdminManager.war
Dec 21, 2009 3:14:55 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive Publisher.war
Dec 21, 2009 3:15:36 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive Advertiser.war
Dec 21, 2009 3:16:11 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8443
Dec 21, 2009 3:16:11 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Dec 21, 2009 3:16:12 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/171  config=null
Dec 21, 2009 3:16:12 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 145986 ms
Dec 21, 2009 3:50:04 AM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: /opt/cie
/java/jdk1.5.0_21/jre/lib/i386/server:/opt/cie/java/jdk1.5.0_21/jre/lib/i386:/opt/cie/java/jdk1.5.0_21/jre/../lib/i386
Dec 21, 2009 3:50:06 AM org.apache.coyote.http11.Http11Protocol init
SEVERE: Error initializing endpoint
java.net.BindException: Address already in use:8443
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:509)
at
org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1058)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load
SEVERE: Catalina.start
LifecycleException:  Protocol handler initialization failed:
java.net.BindException: Address already in use:8443
at
org.apache.catalina.connector.Connector.initialize(Connector.java:1060)
at
org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at
org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:535)
at org.apache.catalina.startup.Catalina.load(Catalina.java:555)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
Dec 21, 2009 3:50:06 AM org.apache.catalina.startup.Catalina load

can you help me with that?
thanks
Ziv
-- 
View this message in context: 
http://old.nabble.com/Tomcat-shutdown-automaticly-after-randomaly-period-of-time-tp26884442p26884442.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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

Re: Tomcat shutdown issues

2009-12-18 Thread Konstantin Kolinko
2009/12/19 SRama :
>
> before starting the server I am checking both port address if any other
> applicaion using the same port I am dynamicaly chaning the shutdown port and
> http port.

You won't be able to shutdown Tomcat using the shutdown script, if the
script does not know what Shutdown port Tomcat listens to, and what
"secret" it expects being written to that port.

Those values are read from server.xml. If server.xml is wrong (is not
the same one as was used to Start this Tomcat instance), you won't be
able to use the shutdown script.

Once again,  http://tomcat.apache.org/tomcat-6.0-doc/config/server.html

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



Re: Tomcat shutdown issues

2009-12-18 Thread SRama

I have depolyed my application it's working fine. but I am not able to
shutdown...


Pejus M. Das wrote:
> 
> Looks like your server started pretty quick. Are there any applications
> deployed? What url are you hitting when you get the reset exception. Do
> you
> see the tomcat start page?
> 
> 
> Pejus
> 
> On Fri, Dec 18, 2009 at 8:10 PM, SRama  wrote:
> 
>>
>> Hi
>> I have some issues  with tomcat, after starting the tomcat when I give
>> request to my application tomcat console showing the following error
>> message..
>>
>> Dec 18, 2009 2:59:23 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 3955 ms
>> Dec 18, 2009 2:59:27 PM org.apache.catalina.core.StandardServer await
>> WARNING: StandardServer.await: Invalid command 'GET /gdf2009 HTTP/1.1'
>> received
>> Dec 18, 2009 2:59:27 PM org.apache.catalina.core.StandardServer await
>> WARNING: StandardServer.await: Invalid command 'GET /gdf2009 HTTP/1.1'
>> received
>> Dec 18, 2009 2:59:29 PM org.apache.catalina.core.StandardServer await
>> WARNING: StandardServer.await: read:
>> java.net.SocketException: Connection reset
>>at java.net.SocketInputStream.read(Unknown Source)
>>at java.net.SocketInputStream.read(Unknown Source)
>>at
>> org.apache.catalina.core.StandardServer.await(StandardServer.java:412
>> )
>>at org.apache.catalina.startup.Catalina.await(Catalina.java:630)
>>at org.apache.catalina.startup.Catalina.start(Catalina.java:590)
>>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>at java.lang.reflect.Method.invoke(Unknown Source)
>>at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
>>at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
>> Dec 18, 2009 2:59:29 PM org.apache.catalina.core.StandardServer await
>> WARNING: StandardServer.await: Invalid command '' received
>> I am not able to shutdown the server please let me know if you have any
>> idea
>> about this issue..
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Tomcat-shutdown-issues-tp26849025p26849025.html
>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Tomcat-shutdown-issues-tp26849025p26850592.html
Sent from the Tomcat - User mailing list archive at Nabble.com.


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



  1   2   3   >