Parallelizing UIMA

Hi Charles,

Glad to hear of your progress. The problem you are describing was
anticipated not long before the first release, and although we added
a mechanism to retrieve the CAS, it was not adequately documented.

The sendCAS method returns a string which is a unique CAS reference ID.
This reference ID is then available from the status object returned to
entityProcessComplete(). The user must save an association from CAS
reference IDs to each CAS given to sendCAS.

Here is code that Jerry Cwiklik gave me to extract the reference ID
from the status object:

public synchronized void entityProcessComplete(CAS aCAS,
EntityProcessStatus aProcessStatus)
{
String casReferenceId="";
if ( aProcessStatus instanceof UimaASProcessStatus )
{
casReferenceId =
((UimaASProcessStatus)aProcessStatus).getCasRefere nceId();
}

The object returned should always be an instance of UimaASProcessStatus,
so the check should not be necessary, but the casting is.

***Note***
While researching this reply, we've found a framework bug (Jira 1216):
on an error condition, the UimaAsynchronousEngine does not release
the CAS given to sendCAS. As a workaround, on errors the listener
should do CAS.release(). Unfortunately, when using the next version
with this bug fixed, the handler code must not do the release.

Regards,
Eddie

On Sun, Oct 26, 2008 at 9:34 PM, Charles Proefrock <chas.pro-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:
>
> We've made progress on our transition and now have an app and a configuration that we believe should meet our needs. We have an application derived from the RunRemoteAsyncAE with the CR and 1 deployed Aggregate. The deployed aggregate uses a mixture of numInstances and remoteAsyncEngines to achieve the objectives outlined in my original message. Not too much different than originally described, but a better understanding of the AS approach to scale-up, surpassing what we had achieved with the processingUnitThreadCount in the CPE application.
>
> We are experiencing one problem at this point which I didn't expect. Null CAS returned on error conditions.
>
> In our CPE implementation we manage a database queue by accessing the queue with a Collection Reader and then completing the queue update via the StatusCallbackListener::entityProcessComplete() call. Independent of whether the call ends with success or error, the CAS reference is valid, so we can access specific information about the CAS and properly update the database status.
>
> Our first attempt at error detection in our AS implementation results in a null CAS passed into the entityProcessComplete() call. This occurs on a remote delegate timeout exception. I did not test other error scenarios to determine if the CAS is valid.
>
> Please let me know how to configure the system to return a valid CAS reference on error to the StatusCallbackListener.
>
> Thanks,
>
> Charles
>
>

On Sun, Oct 26, 2008 at 9:34 PM, Charles Proefrock <chas.pro-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Our first attempt at error detection in our AS implementation results in a null CAS passed into the entityProcessComplete() call.

One might wonder why the CAS would ever be null for the method
entityProcessComplete(CAS aCas, EntityProcessStatus aStatus). During
initial development, the UIMA AS client released outgoing CASes after
sendCAS, and therefore a CAS was only available when received back
from the service. However, on error services do not return a CAS.
Later the client was changed to cache outgoing CASes.

Given the cache, the original outgoing CAS should be returned to the
handler on errors. See UIMA-1217.

Thanks for alerting us of this problem,
Eddie

Eddie, I agree that this needs to be patched in the 2.2.2 code. Insteadof
passing null for a CAS while
handling an exception we can extract the CAS from the cache and pass it
along to the listener's
entityProcessComplete() in the first arg. There is really no need for the
client code to maintain
the Map to manage CASes via CAS Ids.

I will fix the code early next week.


++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++
Jerry Cwiklik
UIMA Extensions
IBM T.J. Watson Research Center
Hawtorne, NY, 10532
Tel: 914-784-7665, T/L: 863-7665
Email: cwiklik-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org




"Eddie Epstein"
<eaepstein@gmail.
com>, To
uima-user-d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b@public.gmane.org
10/28/2008 05:48 cc
PM
Subject
Re: CPE to AS Transition ...
Please respond to Porting processingUnitThreadCount
uima-user@incubat
or.apache.org








On Sun, Oct 26, 2008 at 9:34 PM, Charles Proefrock <chas.pro-PkbjNfxxIASIwRZHo2/mJg@public.gmane.orgm>
wrote:
>
> Our first attempt at error detection in our AS implementation resultsin
a null CAS passed into the entityProcessComplete() call.

One might wonder why the CAS would ever be null for the method
entityProcessComplete(CAS aCas, EntityProcessStatus aStatus). During
initial development, the UIMA AS client released outgoing CASes after
sendCAS, and therefore a CAS was only available when received back
from the service. However, on error services do not return a CAS.
Later the client was changed to cache outgoing CASes.

Given the cache, the original outgoing CAS should be returned to the
handler on errors. See UIMA-1217.

Thanks for alerting us of this problem,
Eddie