uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Shirk <sh...@ncsa.uiuc.edu>
Subject Re: read/write resource sharing
Date Wed, 29 Aug 2007 16:39:06 GMT
Hi Michael,

Yes, that's the approach I started with, but the DataResource javadoc 
indicates that if you directly access the resource, the benefits of 
the ResourceManager  (caching and sharing) are lost. Furthermore, if 
in my SharedResourceObject implementation I make modifications to the 
resource, then it will be out of sync with the ResourceManager's 
cache. The next annotator very well may get the stale version of the resource.

Thilo, I'm afraid that's the approach I may end up having to use, but 
it's really a kludge.

Is there no global variable space, outside of the CAS, for the entire 
aggregate? If there were, that would be the best solution I think...

Thanks for the suggestions.

Andrew

At 11:27 AM 8/29/2007, you wrote:
>Another possibility are external resources. When defining external 
>resources one or more annotators can share the same resource.
>The UIMA framework take care of the resource's life cycle.
>You will find some documentation about external resources in the 
>UIMA reference guide at 2.4.1.10. External Resource Dependencies.
>You can also check the UIMA examples - tutorial ex6 use external 
>resources. (apache-uima/examples/descriptors/tutorial/ex6)
>
>-- Michael
>
>Thilo Goetz wrote:
>>If this happens often, one idea might be just to
>>stick the information in the CAS.  That way you
>>can even run several instances of this pipeline
>>and it will still work ;-)  Of course you're not
>>persisting the info that way, not sure if this is
>>a requirement or not.
>>
>>--Thilo
>>
>>Andrew Shirk wrote:
>>
>>>What is the best practice for sharing read/write resources amongst
>>>analysis engines in an aggregate? For example, say you have an annotator
>>>early in a flow that reads a configuration file off disk in order
>>>determine its behavior. Then, the next annotator does something, and
>>>needs to write changes to the configuration file so that another
>>>annotator downstream, whose behavior is also determined by the contents
>>>of the configuration file, can read in the resource that contains the
>>>changes.
>>>
>>>Does this make sense?
>>>
>>>Any help or ideas would be appreciated. I can think of some ugly hacks,
>>>but it would be nice to know if I'm missing some portion of the API that
>>>supports this type of scenario.
>>>
>>>Thanks, Andrew
>>>


Mime
View raw message