uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burn Lewis <burnle...@gmail.com>
Subject Re: Implications of the UimaContextHolder
Date Mon, 06 Feb 2017 20:36:16 GMT
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 <rec@apache.org>
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 <rec@apache.org>
> 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
>
>

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