[
https://issues.apache.org/jira/browse/YOKO-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491984
]
Sergey Salishev commented on YOKO-258:
--------------------------------------
The fix resolves the problem. But I feel it's incorrect. The localMaps access
is unsynchronized which can lead to thread race and data corruption. The
synchronization protocol for standard maps should include both reading and
writing. So adding of the synchronization will lead to oversynchronization and
potential scalability problems.
The idea of the original code as I understand it is to use the private field of
java.lang.ClassLoader to avoid extensive synchronization on ClassLoader to
ClassLocalMap mapping.
I propose the changes to the fix for the issue by utilizing the ThreadLocal for
caching per thread ClassLocalMap object.
> Bad reference to ClassLoader.classes in
> org.apache.yoko.rmi.util.ClassLoaderLocal static initializer
> ----------------------------------------------------------------------------------------------------
>
> Key: YOKO-258
> URL: https://issues.apache.org/jira/browse/YOKO-258
> Project: Yoko - CORBA Server
> Issue Type: Bug
> Reporter: Vasily Zakharov
> Assigned To: Lars Kühne
> Fix For: v1.0.0
>
>
> org.apache.yoko.rmi.util.ClassLoaderLocal class contains the following line
> in its static initializer:
> classes_vector = ClassLoader.class.getDeclaredField("classes");
> This line references the 'classes' field in class java.lang.ClassLoader, and
> that field is not documented by API JavaDoc and may be absent in particular
> Java VM/classlib implementations, for example it's absent in Apache Harmony.
> As the result of this issue, the classes
> org.apache.yoko.rmi.util.ClassLoaderLocal and
> org.apache.yoko.rmi.impl.PortableRemoteObjectExtImpl fail to load with
> NoSuchFieldException, on those implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
