I guess these should be posted as Jira comments, I'll copy the one below, there
-Marshall On 4/19/2018 1:10 PM, Marshall Schor wrote: > 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 > update. > > 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 :-) > > -Marshall > > 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) >> >
