ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladisav Jelisavcic <vladis...@gmail.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Wed, 12 Apr 2017 13:35:38 GMT
Hi Dmitry,

sure, I made a fix, take a look at the PR and the comments in the ticket.

Best regards,
Vladisav

On Tue, Apr 11, 2017 at 3:00 PM, Dmitry Karachentsev <
dkarachentsev@gridgain.com> wrote:

> Hi Vladislav,
>
> Thanks for your contribution! But it seems doesn't fix related tickets, in
> particular [1].
> Could you please take a look?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-4173
>
> Thanks!
>
> 06.04.2017 16:27, Vladisav Jelisavcic пишет:
>
> Hey Dmitry,
>
> sorry for the late reply, I'll try to bake a pr later during the day.
>
> Best regards,
> Vladisav
>
>
>
> On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev <
> dkarachentsev@gridgain.com> wrote:
>
>> Hi Vladislav,
>>
>> I see you're developing [1] for a while, did you have any chance to fix
>> it? If no, is there any estimate?
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-1977
>>
>> Thanks!
>>
>> -Dmitry.
>>
>>
>>
>> 20.03.2017 10:28, Alexey Goncharuk пишет:
>>
>> I think re-creation should be handled by a user who will make sure that
>>> nobody else is currently executing the guarded logic before the
>>> re-creation. This is exactly the same semantics as with
>>> BrokenBarrierException for j.u.c.CyclicBarrier.
>>>
>>> 2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com>:
>>>
>>> Hi everyone,
>>>>
>>>> I agree with Val, he's got a point; recreating the lock doesn't seem
>>>> possible
>>>> (at least not the with the transactional cache lock/semaphore we have).
>>>> Is this re-create behavior really needed?
>>>>
>>>> Best regards,
>>>> Vladisav
>>>>
>>>>
>>>>
>>>> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
>>>> valentin.kulichenko@gmail.com> wrote:
>>>>
>>>> Guys,
>>>>>
>>>>> How does recreation of the lock helps? My understanding is that
>>>>> scenario
>>>>>
>>>> is
>>>>
>>>>> the following:
>>>>>
>>>>> 1. Client A creates and acquires a lock, and then starts to execute
>>>>>
>>>> guarded
>>>>
>>>>> logic.
>>>>> 2. Client B tries to acquire the same lock and parks to wait.
>>>>> 3. Before client A unlocks, all affinity nodes for the lock fail, lock
>>>>> disappears from the cache.
>>>>> 4. Client B fails with exception, recreates the lock, acquires it, and
>>>>> starts to execute guarded logic concurrently with client A.
>>>>>
>>>>> In my view this is wrong anyway, regardless of whether this happens
>>>>> silently or with an exception handled in user's code. Because this code
>>>>> doesn't have any way to know if client A still holds the lock or not.
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> -Val
>>>>>
>>>>> On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
>>>>>
>>>> dsetrakyan@apache.org
>>>>
>>>>> wrote:
>>>>>
>>>>> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
>>>>>> alexey.goncharuk@gmail.com> wrote:
>>>>>>
>>>>>> Which user operation would result in exception? To my knowledge,
>>>>>>>>
>>>>>>> user
>>>>
>>>>> may
>>>>>>
>>>>>>> already be holding the lock and not invoking any Ignite APIs,
no?
>>>>>>>>
>>>>>>>> Yes, this is exactly my point.
>>>>>>>
>>>>>>> Imagine that a node already holds a lock and another node is
waiting
>>>>>>>
>>>>>> for
>>>>>
>>>>>> the lock. If all partition nodes leave the grid and the lock is
>>>>>>>
>>>>>> re-created,
>>>>>>
>>>>>>> this second node will immediately acquire the lock and we will
have
>>>>>>>
>>>>>> two
>>>>
>>>>> lock owners. I think in this case this second node (blocked on
>>>>>>>
>>>>>> lock())
>>>>
>>>>> should get an exception saying that the lock was lost (which is, by
>>>>>>>
>>>>>> the
>>>>
>>>>> way, the current behavior), and the first node should get an
>>>>>>>
>>>>>> exception
>>>>
>>>>> on
>>>>>
>>>>>> unlock.
>>>>>>>
>>>>>>> Makes sense.
>>>>>>
>>>>>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message