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) < dev@uima.apache.org> 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) >
