Hi Benjamin, UIMACPP is thread safe, as is the JNI interface. To confirm, I just created a UIMA-AS service with 10 instances of DaveDetector, and fed the service 800 CASes with up to 10 concurrent CASes at any time.
It is not the case with DaveDetector, but at annotator initialization some analytics will store info in thread local storage, and expect the same thread be used to call the annotator process method. UIMA-AS and DUCC guarantee that an instantiated AE is always called on the same thread. Eddie On Mon, Apr 4, 2016 at 10:56 AM, Benjamin De Boe < benjamin.de...@intersystems.com> wrote: > 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 > >
