uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin De Boe <Benjamin.De...@intersystems.com>
Subject UIMACPP and multi-threading
Date Mon, 04 Apr 2016 14:56:14 GMT

We're working with a UIMACPP annotator (wrapping our existing NLP library) and are running
in what appears to be thread safety issues, which we can reproduce with the DaveDetector demo
When separate threads are accessing separate instances of the org.apache.uima.uimacpp.UimacppAnalysisComponent
wrapper class on the Java side, it appears they are invoking the same object on the C++ side,
which results in quite a mess (access violations and process crashes) when different threads
concurrently invoke resetJNI() and fillCASJNI() on the org.apache.uima.uimacpp.UimacppAnalysisComponent
object. When using a small CAS pool on the Java side, the problem does not seem to occur,
but it resurfaces if the CAS pool grows bigger and memory settings are not increased accordingly.
However, if this were a pure memory issue, we had hoped to see more telling errors and just
guessing how big memory should be for larger deployments isn't very appealing an option either.
Adding the synchronized keyword to the relevant method of the wrapper class on the Java side
also avoids the issue, at the obvious cost of performance. Moving to UIMA-AS is not an option
for us, currently.

Given that the documentation is not explicit about it, we're hoping to get an unambiguous
answer from this list: is UIMACPP actually supposed to be thread-safe? We saw old and resolved
JIRA's that addressed thread-safety issues for UIMACPP, so we assumed it was the case, but
reality seems to point in the opposite direction.

Thanks in advance for your feedback,


Benjamin De Boe | Product Manager
M: +32 495 19 19 27 | T: +32 2 464 97 33
InterSystems Corporation | http://www.intersystems.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message