Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 andy.seaborne.apache@gmail.com designates 74.125.82.175 as permitted sender)
Sender: Andy Seaborne <andy.seaborne.apache@gmail.com>
Message-ID: <4EC191EF.90303@apache.org>
Date: Mon, 14 Nov 2011 22:10:55 +0000
From: Andy Seaborne <andy@apache.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Simon Helsen <shelsen@ca.ibm.com>
CC: jena-dev@incubator.apache.org,
 Andy Seaborne <andy.seaborne.apache@gmail.com>
Subject: Re: IRIResolver cache not thread safe?
References: 
 <OFA2627390.583134C2-ON8525793A.005A425A-8525793A.005B0E6A@ca.ibm.com>
 <4EAF1C43.7030100@apache.org>
 <OF6DC44E02.9C3C2F21-ON8525793C.006DECA6-8525793C.006E72DF@ca.ibm.com>
 <4EB24D59.8060903@apache.org>
 <OFEBD1D97C.1C60BD55-ON85257948.006F33D6-85257948.006FBE94@ca.ibm.com>
In-Reply-To: 
 <OFEBD1D97C.1C60BD55-ON85257948.006F33D6-85257948.006FBE94@ca.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 14/11/11 20:20, Simon Helsen wrote:
> Andy,
>
> thanks, I was digging through the code paths both in the latest as well
> as the version we currently still have deployed (arq 2.8.5) and it seems
> that the only difference is that in 2.8.5, the readImpl of JenaReadRIOT
> calls the resolve here:
>
> *private**void*readImpl(Model model, Tokenizer tokenizer, String base)
> {
> // The reader has been checked, if possible, by now or
> // constructed correctly by code here.
> *if*( base != *null*)
> base = IRIResolver./resolveGlobalToString/(base) ;
> *try*{
> model.notifyEvent( GraphEvents./startRead/);
> readWorker(model, tokenizer, base) ;
> }
> ...
> whereas in the latest, there is no resolution of the base at all at that
> stage:
>
> *private**void*readImpl(Model model, Tokenizer tokenizer, String base)
> {
> *try*{
> model.notifyEvent( GraphEvents./startRead/);
> readWorker(model, tokenizer, base) ;
> }
> ...
>
> Now, deeper down, both create an IRIResolverNormal object, so I am
> guessing it is safe if I patch our current version to remove the call to
> resolveGlobalToString. Any comments? (and before you ask, this is
> because we are currently not yet upgrading the jena stack, but I need to
> fix this since it leads to concurrency errors during our indexing process)
>
> thanks
>
> Simon

Better would be to patch IRIresolver and add "synchronized" to every 
static function that uses "globalResolver".  Deleting the code from 
readImpl means that you've change the behaviour of reading when the base 
is provided.  Maybe your code always sets an absolute base ... but safer 
to fix IRIResolver IMO.  I don't think globalResolver isn't let out of 
IRIResolver in v2.8.5

	Andy