RFR [9] 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader
Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader. http://cr.openjdk.java.net/~chegar/8156824/01/ https://bugs.openjdk.java.net/browse/JDK-8156824 It’s not clear to me why the construction was not always in a privileged block, maybe “modifyThread” was assumed. We now definitely need a privileged block as the context class loader is being set. -Chris.
On 28/07/2016 14:22, Chris Hegarty wrote:
Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader.
http://cr.openjdk.java.net/~chegar/8156824/01/ https://bugs.openjdk.java.net/browse/JDK-8156824
It’s not clear to me why the construction was not always in a privileged block, maybe “modifyThread” was assumed. We now definitely need a privileged block as the context class loader is being set.
This looks good to me. -Alan
On 28/07/16 14:22, Chris Hegarty wrote:
Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader.
http://cr.openjdk.java.net/~chegar/8156824/01/ https://bugs.openjdk.java.net/browse/JDK-8156824
Hi Chris, I was concerned that Pool.expire() might require permissions (it writes to the socket channel and closes the socket), but if I'm not mistaken you only need perms to create/bind a socket, right? best regards, -- daniel
It’s not clear to me why the construction was not always in a privileged block, maybe “modifyThread” was assumed. We now definitely need a privileged block as the context class loader is being set.
-Chris.
On 28 Jul 2016, at 14:52, Daniel Fuchs <daniel.fuchs@oracle.com> wrote:
On 28/07/16 14:22, Chris Hegarty wrote:
Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader.
http://cr.openjdk.java.net/~chegar/8156824/01/ https://bugs.openjdk.java.net/browse/JDK-8156824
Hi Chris,
I was concerned that Pool.expire() might require permissions (it writes to the socket channel and closes the socket), but if I'm not mistaken you only need perms to create/bind a socket, right?
Correct. -Chris.
On 28/07/16 15:11, Chris Hegarty wrote:
On 28 Jul 2016, at 14:52, Daniel Fuchs <daniel.fuchs@oracle.com> wrote:
On 28/07/16 14:22, Chris Hegarty wrote:
Another issue where an internal platform thread is unnecessarily retaining a reference to its creating thread’s context class loader. In this case, it appears to be safe to use an InnocuousThread, which will have a null context class loader.
http://cr.openjdk.java.net/~chegar/8156824/01/ https://bugs.openjdk.java.net/browse/JDK-8156824
Hi Chris,
I was concerned that Pool.expire() might require permissions (it writes to the socket channel and closes the socket), but if I'm not mistaken you only need perms to create/bind a socket, right?
Correct.
Then I guess this looks OK. best regards, -- daniel
participants (3)
-
Alan Bateman
-
Chris Hegarty
-
Daniel Fuchs