Mailing-List: contact harmony-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <5696270.1161671178423.JavaMail.root@brutus>
Date: Mon, 23 Oct 2006 23:26:18 -0700 (PDT)
From: "Mikhail Markov (JIRA)" <jira@apache.org>
To: harmony-commits@incubator.apache.org
Subject: [jira] Updated: (HARMONY-1936) [classlib][rmi] improper class
 loader creation in DefaultRMIClassLoaderSpi due to race condition
In-Reply-To: <25800977.1161370355095.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/HARMONY-1936?page=all ]

Mikhail Markov updated HARMONY-1936:
------------------------------------

    Attachment: DefaultRMIClassLoaderSpi.1.patch

Thanks, Nathan! Yes - your approach is better, but i'd like to improve it a bit :-). Checking permissions on found/created URLLoader is potentially rather heavy operation so i'd like to remove it from synchronized block. Find the proposed patch attached. Except this everything is OK - the problem is solved as expected.

> [classlib][rmi] improper class loader creation in DefaultRMIClassLoaderSpi due to race condition
> ------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-1936
>                 URL: http://issues.apache.org/jira/browse/HARMONY-1936
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: IA32, WinXP
>            Reporter: Mikhail Markov
>         Assigned To: Nathan Beyer
>         Attachments: DefaultRMIClassLoaderSpi.1.patch, DefaultRMIClassLoaderSpi.patch
>
>
> I've identified that DefaultRMIClassLoaderSpi sometimes creates 2 different URLClassLoaders (inside the class) for the same codebase. This is due to the gap between the moments of checking of inner hashtable with created loaders and table updating with new created loaders when 2 threads could enter at the same time.
> Unfortunately, i was not able to provide a stand-alone simple reproducer for this bug, but it is reproducible on heavy multi-threading application.
> The patch will come... It is easy understandable so i hope it demonstrates the problem by itself. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira