I've checked the code and indeed this is a bug in uima-as client when
running with a CR. As soon as the CR
returns false from hasNext() the uima-as client process() method calls
collectionProcessComplete().
The fix for this is to wait until all outstanding CASes are processed
before calling collectionProcessComplete().
I will fix the trunk in a day or two.
To deal with this problem, you can run the CR outside of uima-as client and
call either send() or sendAndReceive()
methods to process your CASes. Alternatively, if you want to patch 2.3.1,
you can modify process() method to:
while (initialized && running ) {
try {
if ( (hasNext = collectionReader.hasNext()) == true) {
cas = getCAS();
collectionReader.getNext(cas);
sendCAS(cas);
} else {
break;
}
} catch (Exception e) {
e.printStackTrace();
}
}
Object waitMonitor = new Object();
if (hasNext == false ) {
while( running && clientCache.size() > 0 ) {
try {
// polling loop waiting for outstanding CASes to come back
from the service
synchronized(waitMonitor) {
waitMonitor.wait(100);
}
} catch( Exception exx ) { }
}
collectionProcessingComplete();
}
Jerry
On Thu, Jun 14, 2012 at 9:29 PM, Thomas Ginter <thomas.gin...@utah.edu>wrote:
> My UIMA-AS 2.3.1 service is returning the CollectionProcessComplete event
> while there are still CAS objects outstanding. The client log shows:
>
> INFO: Client in CollecitonProcessComplete - OutstandingCasCount=2
> TotalCasRequestsSentBetweenCpCs=NNNN
>
> I always seem to end up losing 2 CAS objects becuase the
> UimaAsynchronousEngine object stops blocking the process() method when the
> CollectionProcessComplete event is returned. My program then called the
> stop() method assuming the entire collection is finished processing. This
> is a problem because the stop() method appears to be disconnecting from the
> service before the listener can process the last two CAS objects.
>
> Is there a setting I am missing to give the client more time to handle
> entityProcessComplete events? What I have found in the documentation so
> far refers to input queues for remote delegates only.
>
> Thanks,
>
> Thomas Ginter
> 801-448-7676
> thomas.gin...@utah.edu
>
>
>
>
>
