[
https://issues.apache.org/jira/browse/UIMA-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851985#action_12851985
]
Jerry Cwiklik commented on UIMA-1754:
-
Modified description of getCAS() to read:
CAS getCAS(): Requests a new CAS instance from the 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 asychronous sendCAS() and getCAS() must not call CAS.release() nor
CAS.reset(). The UIMA AS client releases each CAS at the end of processing. If
a callback listener object is registered with UIMA AS client, the CAS.release()
is
called after a call to the 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
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.
