On 02/01/2017 11:03, Dave Reynolds wrote:
> On 02/01/17 09:23, George News wrote:
>>
>> On 31/12/2016 16:42, Andy Seaborne wrote:
>>>
>>>> sometime when concurrently calling the webservice
>>>
>>> Having code fragment does not help here - could it be that one
>>> request is doing
>>>
>>> Individual.isClass()
>>>
>>> while another is closing the model?
>>>
>>> if so, why is one request closing a shared object? Either keep the
>>> object open, or make a fresh object per request.
>>>
>>> Andy
>>>
>>
>> I know it's difficult.
>
> Hmmm.
>
>> But could you please have a look at the way I'm
>> creating the MyOntModelSpec. Is it correct? If yes, then is the model
>> correctly created that spec?
>
> Insufficient information to tell.
Sorry for that, but it's difficult to send all as I cannot disclose the
full code.
>
> Does your "etc/my.owl" switch on model caching?
Yes it does. I want to speedup things, as ontologies are not changing.
<DocumentManagerPolicy>
<!-- policy for controlling the document manager's behaviour -->
<processImports rdf:datatype="&xsd;boolean">true</processImports>
<cacheModels rdf:datatype="&xsd;boolean">true</cacheModels>
</DocumentManagerPolicy>
> Does the code you haven't shown us close your OntModels somewhere?
I call OntModel close on local models vars. But each time I'm creating a
new model, so don't understand why it's being closed.
> There's no explicit close in the fragments you've posted but the
> exception suggests you are doing close somewhere - directly or indirectly.
>
> Your MyOntModelSpec.getInstance is sharing a global singleton instance
> which in turn is sharing the FileManager clone that you set up. If you
> have caching switched on in your config then the cached imports will be
> shared across your models. If you close() one of those OntModels I think
> that will close all the imported submodels including those in the shared
> FileManager cache which could lead to the problem you see.
Umm... maybe that's the issue. I was using caching as otherwise it's
taking longer to create the model, and I want to speed up things.
But, if I run the same webservice and things are done sequentially there
is no problem. The cache is created at the very beginning and if close I
might be getting the same problem.
> None of your code fragments have any sign of locking or synchronization
> so there is at least a race condition in MyOntModelSpec.getInstance
> which might result in your having multiple MyOntModelSpec instances but
> that seems unlikely to be the problem.
I initialize this at the very beginning so don't think is the problem,
as after initialization every Spec should be the same.
>
> However, since FileManager caching doesn't look particularly thread-safe
> to me then unless you are doing your own synchronization around all the
> operations that touch it that could also cause problems.
Could you further explain that? I don't fully understand. What operation
are touch what? The local ontology files are there just in case the
remote ones are not accessible.
> Dave
>
>
>
