You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2018/03/27 21:34:31 UTC

[Bug 62224] New: SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

            Bug ID: 62224
           Summary: SafeForkJoinWorkerThreadFactory breaks class loading
                    on org.apache.naming.java.javaURLContextFactory
           Product: Tomcat 8
           Version: 8.5.x-trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: nobeh5@gmail.com
  Target Milestone: ----

Tomcat 8.0.42 introduces a change to install a different
ForkJoinWorkerThreadFactory into Java using a System property in an
unconditional way.

Link to the change from 8.0.42:
https://github.com/apache/tomcat80/compare/TOMCAT_8_0_41...TOMCAT_8_0_42#diff-738f0383c5c3a3e5bbd162aa59a114c6R470

We have tried to bisect Tomcat versions from 9.0.6 to 8.0.42 and all version
upgrades have yielded to the following exception:

javax.naming.NoInitialContextException: Cannot instantiate class:
org.apache.naming.java.javaURLContextFactory [Root exception is
java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory]
        at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)
        at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
        at javax.naming.InitialContext.init(InitialContext.java:244)
        at javax.naming.InitialContext.<init>(InitialContext.java:192)

When trying Tomcat 8.0.41, the exception does not appear anymore.

When trying Tomcat 8.0.42, when we remove the following Listener from
server.xml, the exception does not occur any more:

<Listener
className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Mark Thomas <ma...@apache.org> ---
Protection disabled in Java 9 onwards in:
- trunk for 9.0.7 onwards
- 8.5.x for 8.5.30 onwards
- 8.0.x for 8.0.51 onwards
- 7.0.x for 7.0.86 onwards

FYI:
Useful test cases for exploring memory leaks:
https://github.com/markt-asf/memory-leaks

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

--- Comment #4 from Mark Thomas <ma...@apache.org> ---
The JNDI lookup must be happening on the ForkJoin Thread.

The JNDI depends on the TCCL being set and it is no longer set on a ForkJoin
thread (to avoid the memory leak).

I'll confirm the Java 9 fix and then disable the protection for Java 9 onwards.

Note that with the memory leak protection in place or when running on Java 9
onwards, the TCCL will have to be set on a ForkJoin thread.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

--- Comment #1 from Behrooz Nobakht <no...@gmail.com> ---
Adding more context into this: The reason for this change seems to be this JDK
bug: https://bugs.java.com/view_bug.do?bug_id=JDK-8172726

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

soheil rahsaz <so...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #6 from soheil rahsaz <so...@gmail.com> ---
I'm experiencing the same issue on Tomcat 9.0.21 and JDK 14.0.1.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Behrooz Nobakht <no...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |NEW

--- Comment #3 from Behrooz Nobakht <no...@gmail.com> ---
Extracting a minimal reproducible example is quite difficult for me. I will
explain the current situation as is.

Tomcat is used with a custom server.xml:

<?xml version='1.0' encoding='utf-8'?>
<Server port="${shutdown.port}" shutdown="SHUTDOWN">
    <Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
    <Listener className="org.apache.catalina.core.AprLifecycleListener"
SSLEngine="on"/>
    <Listener
className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
    <Listener
className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
    <Listener
className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
    <Service name="Catalina">
        <Connector port="${port}" protocol="HTTP/1.1"
                   maxHttpHeaderSize="8192" maxThreads="150"
minSpareThreads="25" useBodyEncodingForURI="true"
                   enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000"
                   disableUploadTimeout="true"/>
        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true">
                <Context
containerSciFilter="org.apache.tomcat.websocket.server.WsSci"
path="${app.context}"
                         docBase="${app.docbase}" workDir="${tomcat.workdir}"
reloadable="false" useHttpOnly="true">
                    <Resource name="UserTransaction" auth="Container"
type="javax.transaction.UserTransaction"
                             
factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60"/>
                    <Manager pathname=""/>
                </Context>
                <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs"
                       prefix="localhost_access_log." suffix=".txt"
                       pattern="%h %l %u %t &quot;%r&quot; %s %b %D"/>
            </Host>
        </Engine>
    </Service>
</Server>


Please note the definition of `Resource` in above.

When accessing one of the HTTP endpoints on the app, a business objects wants
for the first time to gain access to the JNDI resource
`java:env/comp/UserTransaction`. 

Because there's no custom definition of NamingContext provider API, the default
is picked by javax.naming.InitialContext. 

This is L313 of javax.naming.InitialContext in Java 1.8.0_172:

defaultInitCtx = NamingManager.getInitialContext(myProps);

`myProps` is filled by Catalina bootstrap to point to Apache Naming
implementation.

Going further down the stack, you will reach
com.sun.naming.internal.VersionHelper12 at L61:

return loadClass(className, getContextClassLoader());

The fix for ForkJoinWorkerThreadFactory means that there will be no context
class loader, which means it will be "system" class loader and eventually leads
to ClassNotFoundException.


Hope this clarifies further the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Behrooz Nobakht <no...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nobeh5@gmail.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Remy Maucherat <re...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #2 from Remy Maucherat <re...@apache.org> ---
Ok so the revision is here: http://svn.apache.org/viewvc?rev=1778061&view=rev
It is supposedly no longer needed on Java 9+, so a subsequent revision could be
made to avoid it in that case. Note that you also have a setting on
JreMemoryLeakPreventionListener to disable it.

I don't get how this, by itself, then causes the naming context factory
failure. Please explain how to reproduce it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62224] SafeForkJoinWorkerThreadFactory breaks class loading on org.apache.naming.java.javaURLContextFactory

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62224

Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #7 from Mark Thomas <ma...@apache.org> ---
This issue is fixed.

As per comment #4:

Note that with the memory leak protection in place or when running on Java 9
onwards, the TCCL will have to be set on a ForkJoin thread.

Please follow up on the users mailing list and include the simplest possible
test case that demonstrates the problem you are seeing. If that discussion
determines that you have found a bug then this issue can be re-opened or a new
issue created as appropriate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org