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:17:32 GMT
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) <
> 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)

View raw message