uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry Cwiklik (JIRA)" <...@uima.apache.org>
Subject [jira] Closed: (UIMA-1754) Incorrect description of getCAS() method in UIMA AS documentation
Date Tue, 04 Jan 2011 19:05:45 GMT

     [ https://issues.apache.org/jira/browse/UIMA-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jerry Cwiklik closed UIMA-1754.

       Resolution: Fixed
    Fix Version/s: 2.3.1AS
         Assignee: Jerry Cwiklik

Modified to read:

CAS getCAS(): Requests a new CAS instance from a CAS pool. This method blocks until
a free instance of CAS is available in the CAS pool. Applications that use synchronous
sendAndReceive() and getCAS() need to call CAS.reset() before reusing the CAS,
or CAS.release() to return it to the CAS pool. Applications that use asynchronous
sendCAS() and getCAS() must not call CAS.release() nor CAS.reset() unless
sendCAS() throws an exception. If sendCAS() call is successful, the UIMA AS framework
code releases each CAS automatically when a reply is received. The framework releases a
CAS right after a callback listener entityProcessComplete() completes.

> Incorrect description of getCAS() method in UIMA AS documentation
> -----------------------------------------------------------------
>                 Key: UIMA-1754
>                 URL: https://issues.apache.org/jira/browse/UIMA-1754
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.3AS
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: 2.3.1AS
> Chapter 4.2 The UimaAsynchronousEngine Interface describes UIMA AS client interface.
Its description of getCAS() tells the reader to call reset() or release() on the CAS before
calling getCAS() again. This is wrong when the client application uses an async style of sending
CASes using sendCAS() method. When using async calls, the framework actually releases a CAS
*after* the user's listener callback completes. The code calls release() if the user callback
is *not* provided. The only time when the user's code must call release() or reset() is when
the *synchronous* calls are made via sendAndReceive(). In this style of invocation, the framework
does not call release() nor reset() and it *is* user's responsibility to do so. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message