I have delivered changes that save & restore the UimaContext so it now should always be valid. Let me know if it doesn't fix your type-system problem.
Burn On Mon, Feb 6, 2017 at 3:36 PM, Burn Lewis <[email protected]> wrote: > 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 >> >> >
