Hi, 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 AE. 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 -- Benjamin De Boe | Product Manager M: +32 495 19 19 27 | T: +32 2 464 97 33 InterSystems Corporation | http://www.intersystems.com
