Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: uima-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: read/write resource sharing
Date: Wed, 29 Aug 2007 13:26:08 -0400
Message-ID: 
 <31923CD68FF05B42B1D3AC08F2D733B502A2998E@nybf01-mail01.ad.gd-ais.com>
In-Reply-To: <7.0.0.16.2.20070829112923.04b1f7e0@ncsa.uiuc.edu>
Thread-Topic: read/write resource sharing
Thread-Index: AcfqW4ZoBLvBAqlGRTCPIL08pLhRxgAAYqrw
References: <7.0.0.16.2.20070829102140.04b5dc60@ncsa.uiuc.edu>
 <46D59C49.3090408@gmx.de> <46D59E8E.4090207@michael-baessler.de>
 <7.0.0.16.2.20070829112923.04b1f7e0@ncsa.uiuc.edu>
From: "LeHouillier, Frank D." <Frank.LeHouillier@gd-ais.com>
To: <uima-user@incubator.apache.org>

Why is this a kludge?  You want the parameters associated with each CAS
right?  Would this still be a kludge in a networked/distributed setup
where presumably one analysis engine might have worked through lots of
documents while the next is still working on the first etc. and the
global variable would be out of date?  I'm actually not sure about the
implementation details of Apache-UIMA at the moment with Jvinci etc. but
this is a possibility according to the standard right? =20

On the other hand, Andrew might have a point about needing some global
variable space.  Is there some way that the CAS's coming through are
dependent on each other?  For example, we could imagine a pipeline that
has to deal with lots of duplicates and wants to somehow store the
annotations so that it doesn't have to repeat the work.  In this case
some sort of global memory would really be necessary.  Or is there a
smarter way to do this?

-----Original Message-----
From: Andrew Shirk [mailto:shirk@ncsa.uiuc.edu]=20
Sent: Wednesday, August 29, 2007 12:39 PM
To: uima-user@incubator.apache.org
Subject: Re: read/write resource sharing

Hi Michael,

Yes, that's the approach I started with, but the DataResource javadoc=20
indicates that if you directly access the resource, the benefits of=20
the ResourceManager  (caching and sharing) are lost. Furthermore, if=20
in my SharedResourceObject implementation I make modifications to the=20
resource, then it will be out of sync with the ResourceManager's=20
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=20
it's really a kludge.

Is there no global variable space, outside of the CAS, for the entire=20
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=20
>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=20
>UIMA reference guide at 2.4.1.10. External Resource Dependencies.
>You can also check the UIMA examples - tutorial ex6 use external=20
>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
>>>