In UIMA-5043 I added set/clear calls around all methods that passed control to user code, in primitive AEs & flow controllers. Recently in UIMA-5274 I added a set call in Resource_ImplBase.initialize so that all flavors of produceResource could use settings in parts of their descriptors. I should have added a clear call in a finally clause to be consistent. But I don't understand how this might have caused your problem, since the set calls always replace, and leaving a possibly stale context associated with the thread should not give you the wrong context.
But I see there is a problem if engines are nested, e.g. if an annotator uses produceAnalysisEngine to create a 2nd pipeline with an unrelated context and runs it during its process call. I should save and restore any existing context entry around the calls to user code, as well as around the resource initialize call. Could this be the cause of your problem? I'll try to get a fix out tomorrow. Burn On Mon, Feb 6, 2017 at 7:04 AM, Richard Eckart de Castilho <[email protected]> wrote: > Currently, setContext() is called in Resource_ImplBase.initialize(...). > > However, as illustrated below, there may be multiple calls to > "initialize()" > as part of a program and they may not even be in the same order as calls > to "destroy()". > > Now I wonder - would it be more sensible to call setContext() and > clearContext() > before and after passing control over to client code, e.g. before UIMA > calls > process() and thus keeping the UIMA context on the thread for shorter > periods of > time to reduce the risk of overriding it unintentionally / to more > reliably re-use > it if it is set? E.g. If already a context is set in the thread when > Resource_ImplBase.initialize(...), then maybe we should re-use it instead > of overriding it? > > Cheers, > > -- Richard > > > On 06.02.2017, at 12:11, Richard Eckart de Castilho <[email protected]> > wrote: > > > > Hi all, > > > > triggered by changes in UIMA-5058, I have looked again at how the > UimaContextHolder works > > and is being used right now. > > > > In particular, I think the following case is not uncommon but now > potentially problematic: > > > > ---- > > // 1) instantiate reader > > CollectionReader reader = UIMAFramework.produceCollectionReader(readerDesc, > resMgr, null); > > > > // 2) instantiate analysis engine > > AnalysisEngine aae = UIMAFramework.produceAnalysisEngine(aaeDesc, > resMgr, null); > > > > // 3) create a CAS > > CAS cas = CasCreationUtils.createCas(asList(reader.getMetaData(), > aae.getMetaData()), > > null, resMgr); > > > > // 4) inform the reader about the type system > > reader.typeSystemInit(cas.getTypeSystem()); > > > > // 5) iterate over the reader using the given CAS and process it using > the AE > > --- > > > > The potential problem in this setup is that 1) and 2) both call > UimaContextHolder.setContext(). > > > > Do you see that as a problem? > > > > Best, > > > > -- Richard > >
