Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.208 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "dev@felix.apache.org" <dev@felix.apache.org>
Date: Wed, 26 Oct 2011 17:46:20 +0100
Subject: Re: Optimization of classloading error cases
Thread-Topic: Optimization of classloading error cases
Thread-Index: AcyT/sgwGe5aG7nXTyGSPJGLqo3r4Q==
Message-ID: <2347D7C6-394A-4FFA-8947-AA29F7953F62@adobe.com>
References: 
 <CAG1yf3Nvs5Rhr3sMR4juAt-Y=q4VUx+jz8n5R=TCNRadt6t0DQ@mail.gmail.com>
 <4EA83476.6010107@ungoverned.org>
In-Reply-To: <4EA83476.6010107@ungoverned.org>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

We just have to make sure that such a cache would be bounded ...

Regards
Felix

Am 26.10.2011 um 18:25 schrieb Richard S. Hall:

> On 10/26/11 05:02 , Guillaume Sauthier (OW2) wrote:
>> Hi all
>>=20
>> In one of our project we spotted an intensive usage of ZipFile.getEntry(=
)
>> due to Felix trying to access the resource associated with a class when =
the
>> class is not defined yet. As the requested resource is not boot delegate=
d,
>> nor imported and neither inside of the bundle, getEntry() returns null a=
nd
>> Felix continue to follow its classloading algorithm. But trying to acces=
s
>> the resource is time consumming, and the impact is bigger on performance
>> when the same resource is requested for each of our request.
>>=20
>> I agree that we could fix this by being more smart in our usage to avoid
>> theses error cases, but do you think it could be valuable for Felix to k=
eep
>> a "cache" of failed resource request, so that, next time Felix try to
>> request the resource from the Bundle's content, we simply avoid this ste=
p
>> and move forward ?
>>=20
>> I feel that it should be quite easy to implement that behavior, but befo=
re
>> starting this task, I want to have your feedback.
>> So WDYT ?
>=20
> Actually, I thought we already implemented something like this, but I=20
> didn't see it in the code after a quick perusal. I know for a fact that=20
> we at least investigated it at one time, so if it is not in there=20
> already, we must have deemed that it didn't make much of a difference.
>=20
> If you want to open an issue and work on it, feel free to work on a=20
> patch, but please get some before and after performance numbers to show=20
> if it is worth it or not.
>=20
> Thanks.
>=20
> -> richard
>=20
>>=20
>> --G
>>=20