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 Wed, 08 Feb 2017 14:44:31 GMT
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 <burnlewis@gmail.com> 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 <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