uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: [jira] [Commented] (UIMA-5763) UIMA: need a way to lock a CAS to prevent user from releasing it prematurely
Date Thu, 19 Apr 2018 17:10:29 GMT
This all started when a user didn't realize, when using the uima-as
send-and-receive APIs, that they could not "release" the cas until that
operation asynchronously completed.

The original goal was to throw an exception when users accidentally did this. 
This goal was somewhat expanded when it was realized that any update by "users"
could conflict with the uima-as asynchronous update that would happen when the
"receive" part of the asynchronous send=and-receive happened.

So, the imagined impl is: uima-as sets the no-access mode bit, in it's ansynch.
send-and-receive, and then when it receives the reply, it updates the cas and
resets the bit.

There would need to be perhaps a 2 bit indicator: the prohibit-access bit
(set/not set), and another bit (privileged), where the setting of 'privileged'
would be an "internal" API in UIMA, and uima-as would set this when it needed to

This two bit approach avoids a race condition which could occur otherwise.

I just kind of made up this approach, right now; better ones welcome :-)


On 4/18/2018 3:05 PM, Richard Eckart de Castilho (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/UIMA-5763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443046#comment-16443046
> Richard Eckart de Castilho commented on UIMA-5763:
> --------------------------------------------------
> How would it update the CAS if access is prohibited? 
> So is it a write(access)-only-by-one-single-thread mode then? I.e. a mode where the CAS
is exclusively owned by a specific thread?
>> UIMA: need a way to lock a CAS to prevent user from releasing it prematurely
>> ----------------------------------------------------------------------------
>>                 Key: UIMA-5763
>>                 URL: https://issues.apache.org/jira/browse/UIMA-5763
>>             Project: UIMA
>>          Issue Type: New Feature
>>          Components: UIMA
>>            Reporter: Jerry Cwiklik
>>            Assignee: Marshall Schor
>>            Priority: Major
>>             Fix For: 3.0.1SDK, 2.10.3SDK
>> UIMA-AS client supports an async style of sending CASes for processing to a remote
service. When using sendCAS( CAS aCas), the code serializes CAS and dispatches it to the remote
but keeps the CAS in a cache. When a reply comes, the cached CAS is used to deserialize a
response. The contract is that the user code should not call CAS.release(). When a reply finally
comes, the CAS is handed over to an application callback and upon return from the callback,
the UIMA-AS releases the CAS. 
>> Problem: there is nothing to prevent user code to violate the contract. If CAS.release()
is called while UIMA-AS client awaits reply (or during reply deserialization), bad things
happen. In a specific use case, a NPE was thrown during deserialization and debugging was
quite painful.
>> Proposed solution: to protect integrity of a CAS need a way to lock/unlock it. Such
facility can be added to CASImpl class. When a user code tries to call release()  when a
CAS is locked,  the code should throw an exception (IllegalStateException or similar). 
>> WDYT?
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)

View raw message