tomcat7.exe windows service crash

[Jan Vávra]

Hello,
 I'm facing a problem of tomcat7.exe crash (from win64 Tomcat 7.0.54 
distribution)  installed as a Windows service on Windows 2012 x64, x64 
jdk 1.7.0.65.
In the Widows event log is message (translated from Czech) :Windows 
service Apache Tomcat 7 was unexpectedly ended.
Interresting is that in my webapp in registered context listener the 
contextDestroyed method was called and my log command in 
contextDestroyed (.) was succesfully written. So it seems that my app is 
gracefully going to shutdown. But why?

In the tomcat log I do not see any error messages that leads tomcat to stop.
The tomcat7.exe process exited.

In my app we transfer through a windows pipe a 300 MB big file to newly 
created subprocess written in c for an analysis.

jvm opts changed: Xmx=6116MB.

Eg. in one case was the server started at 10:34:55  and crashed at 
10:43:13 (according the Windows event log)

---
tomcat7-stderr.log:
---
VII 29, 2014 10:34:55 DOP. org.apache.catalina.startup.Catalina start
INFO: Server startup in 6323 ms
VII 29, 2014 10:43:07 DOP. org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [http-apr-8080]
VII 29, 2014 10:43:07 DOP. org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [ajp-apr-8009]
VII 29, 2014 10:43:07 DOP. org.apache.catalina.core.StandardService 
stopInternal

INFO: Stopping service Catalina
VII 29, 2014 10:43:11 DOP. org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/jasw] is still processing a request that 
has yet to finish. This is very likely to create a memory leak. You can 
control the time allowed for requests to finish by using the unloadDelay 
attribute of the standard Context implementation.
VII 29, 2014 10:43:11 DOP. org.apache.catalina.loader.WebappClassLoader 
clearReferencesThreads
SEVERE: The web application [/jasw] is still processing a request that 
has yet to finish. This is very likely to create a memory leak. You can 
control the time allowed for requests to finish by using the unloadDelay 
attribute of the standard Context implementation.
VII 29, 2014 10:43:11 DOP. org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/jasw] created a ThreadLocal with key of 
type [com.sun.xml.bind.v2.ClassFactory$1] (value 
[com.sun.xml.bind.v2.ClassFactory$1@6be8e70]) and a value of type 
[java.util.WeakHashMap] (value [{class 
cz.software602.sdar.tsl.CertTypeResponseItem=java.lang.ref.WeakReference@48795e85, 
class 
cz.software602.sdar.tsl.GetCertPathResponse=java.lang.ref.WeakReference@182c92ef, 
class 
cz.software602.sdar.tsl.CertPathResponse=java.lang.ref.WeakReference@1662954f, 
class cz.software602.sdar.tsl.Cert=java.lang.ref.WeakReference@22388104, 
class 
javax.xml.bind.annotation.W3CDomHandler=java.lang.ref.WeakReference@2b9e3f29, 
class 
cz.software602.sdar.pdf.TRevocations=java.lang.ref.WeakReference@2244b31e, 
class 
cz.software602.sdar.tsl.CertPath=java.lang.ref.WeakReference@4c4b8825, 
class 
cz.software602.sdar.pdf.TCmsInfo=java.lang.ref.WeakReference@72d75c44, 
class cz.software602.sdar.tsl.Crl=java.lang.ref.WeakReference@18eaaf43, 
class 
cz.software602.sdar.pdf.TPdfInfo=java.lang.ref.WeakReference@5798647c, 
class java.util.ArrayList=java.lang.ref.WeakReference@55ed35d1, class 
cz.software602.sdar.tsl.CertRevocation=java.lang.ref.WeakReference@48685869, 
class 
cz.software602.sdar.tsl.Status=java.lang.ref.WeakReference@3a847aa2, 
class 
cz.software602.sdar.pdf.TCertificates=java.lang.ref.WeakReference@4f8f3fb1, 
class 
cz.software602.sdar.tsl.GetCertTypeResponse=java.lang.ref.WeakReference@459ea645, 
class 
cz.software602.sdar.tsl.CertTypeResponseList=java.lang.ref.WeakReference@32b61fb8, 
class 
cz.software602.sdar.tsl.CertTypeResponse=java.lang.ref.WeakReference@52dc830a}]) 
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.
VII 29, 2014 10:43:11 DOP. org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/jasw] created a ThreadLocal with key of 
type [com.sun.xml.ws.api.client.ServiceInterceptorFactory$1] (value 
[com.sun.xml.ws.api.client.ServiceInterceptorFactory$1@b1f3006]) and a 
value of type [java.util.HashSet] (value [[]]) 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.
VII 29, 2014 10:43:11 DOP. org.apache.catalina.loader.WebappClassLoader 
checkThreadLocalMapForLeaks
SEVERE: The web application [/jasw] created a ThreadLocal with key of 
type [com.sun.xml.bind.v2.ClassFactory$1] (value 
[com.sun.xml.bind.v2.ClassFactory$1@6be8e70]) and a value of type 
[java.util.WeakHashMap] (value [{class 
cz.software602.sdar.tsl.CertTypeResponseItem=java.lang.ref.WeakReference@2c89df9e, 
class java.util.ArrayList=java.lang.ref.WeakReference@fb814ea, class 

[ANN] Apache Tomcat 7.0.55 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.55.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.54.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Note: This version has 4 zip binaries: a generic one and
  three bundled with Tomcat native binaries for Windows operating
  systems running on different CPU architectures.

Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7.

Note: If you use the APR/native AJP or HTTP connector you *must* upgrade
  to version 1.1.31 or later of the APR/native library.

Downloads:
http://tomcat.apache.org/download-70.cgi

Migration guides from Apache Tomcat 5.5.x and 6.0.x:
http://tomcat.apache.org/migration.html

Junit unit test setup for testing an authentication realm

[John Gary Geiglein]

Currently working on Tomcat 7.0.53 on 32 bit Windows Server, Testing on same 
Tomcat on windows 7.

Java JDK 1.7.0_60 in both environments.



We have been using a custom realm, and had a need to update it.

All of the old unit tests fail when trying to lookup the realm configuration 
from the JNDI environment.



I would like to know if there is something that could be done in the setup for 
the tests to make this work.



We currently load the JNDI context form copies of the server.xml and 
context.xml and this works fine for testing applications.

But the realm uses a combination of org.apache.naming.ContextBindings and 
org.apache.naming.SelectorContext that are not picking up the environment.



I have gone so far adding the following code after the environment is built:



ContextBindings.bindContext(Acentia-Jndi-UnitTests, ctx);
ContextBindings.bindClassLoader(Acentia-Jndi-UnitTests, null, 
Thread.currentThread().getContextClassLoader());

This seems to make it available as far as the call to 
ContextBindings.getClassLoader(), this returns a context containing the 
environment that was setup.

But when I try context.lookup(jndiName) It ends up returning a new 
SelectorContext with the environment instead of returning the object.



The code works correctly inside tomcat so I am assuming that there needs to be 
something else setup prior to trying to instanciate the realm from the JNDI 
environment.



The information in this electronic mail message is confidential and may be 
legally privileged. It is intended solely for the addressee. Access to this 
electronic mail message by anyone else is unauthorized. If you are not the 
intended recipient, please notify the sender and delete this message 
immediately. Any disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on information in this message by unauthorized 
recipients is prohibited and may be unlawful.