incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: IRIResolver cache not thread safe?
Date Mon, 31 Oct 2011 22:08:03 GMT
On 31/10/11 16:34, Simon Helsen wrote:
> Hi all,
> very sometimes (it is a rare and impossibly difficult to reproduce) we run
> into a problem which I can only explain by a concurrency violation. The
> stack trace we typically encounter is below. I know that the concrete NPE
> which comes as a result is specific to the IBM JDK because of the way they
> implement LinkedHashMap, but the bug is not theirs. That the Sun SDK does
> not immediately expose the issue is mere luck. Looking at the IRIResolver
> code, it seems to me that the cache inside the IRIResolveNormal (
> resolvedIRIs) ought to be using a concurrent linked hashMap since there is
> only one global cache which can be used by many threads.
> Any thoughts?

There is no such operation IRIResolver.resolveGlobalToString anymore. 
Which version are you using?

Use of private static "globalResolver" may need protecting (see the 
current system) which has one IRIResolverNormal - there may be others 
and the class itself IRIResolverNormal does not need it (it has no 
statics) and there are ways to create new ones.


> Thanks
> Simon
> java.lang.NullPointerException
>          at java.util.LinkedHashMap.get(
>          at org.openjena.atlas.lib.cache.CacheLRU.get(
>          at
> org.openjena.atlas.lib.cache.CacheWrapper.get(
>          at
> org.openjena.atlas.lib.cache.CacheWithGetter.get(
>          at
> org.openjena.riot.IRIResolver$IRIResolverNormal.resolveSilent(
>          at
> org.openjena.riot.IRIResolver$IRIResolverNormal.resolveToString(
>          at
> org.openjena.riot.IRIResolver.resolveGlobalToString(
>          at
> org.openjena.riot.JenaReaderRIOT.readImpl(
>          at
>          at

View raw message