see comment in jira about 2 bit approach. -Marshall
On 4/18/2018 6:42 PM, Jaroslaw Cwiklik wrote: > Yes, that is an open question. UIMA-AS needs to deserialize response into a > CAS that was previously locked. The thread doing the locking will be > different from the one doing deserialization. I guess I can invent a way to > dedicate an internal UIMA-AS thread for locking, deserializing and > unlocking of CASes. > So CASImpl would remember which thread id locked it and only allow > modifications to the CAS (deserialization) by that thread. For efficiency > sake there should > be a dedicated thread pool which would lock, deserialize, and unlock and a > way of matching replies with the right locking thread. > > > > On Wed, Apr 18, 2018 at 3:05 PM, Richard Eckart de Castilho (JIRA) < > [email protected]> 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) >>
