On 02/01/17 11:22, George News wrote:
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.
It sounds like your OntModels include imports. These are implemented as
separate sub-models which are bound into a multi-union. If you close the
OntModel that will (I think) close all the imported models.
If some of those imported models are cached (which seems to be the case
with your setup) and thus shared with other OntModels then you will be
closing submodels of other concurrent OntModel instances. That would
explain your symptoms.
Since all your models seem to be in-memory then you could simply drop
the close(), it's not necessary here.
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.
FileManager doesn't say it is thread safe and from a quick look at the
code it doesn't seem to be. So if you have two different threads which
are concurrently importing models via the same FileManager then the
cache could become corrupted.
Possible ways round that would include:
- preloading your FileManager cache will all the relevant imported
models so there's no concurrent update to the cache
- build your own thread-safe filemanager (hmm, don't think the design
allows for that)
- perform all your local OntModel instantiation from within a suitably
protected critical section so that all the import processing is done by
a single thread
Dave
