ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Karachentsev <dkarachent...@gridgain.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Fri, 14 Apr 2017 09:27:25 GMT
Hi Vladislav,

It looks like after fix was merged these tests [1] started failing. 
Could you please take a look?

[1] 
http://ci.ignite.apache.org/viewLog.html?buildId=544238&tab=buildResultsDiv&buildTypeId=IgniteTests_IgniteBinaryObjectsDataStrucutures

Thanks!

-Dmitry.

13.04.2017 16:15, Dmitry Karachentsev пишет:
> Thanks a lot!
>
> 12.04.2017 16:35, Vladisav Jelisavcic пишет:
>> 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 <mailto: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
>>     <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 <mailto: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
>>>         <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 <mailto: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
>>>                 <mailto: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 <mailto:dsetrakyan@apache.org>
>>>
>>>                     wrote:
>>>
>>>                         On Tue, Mar 14, 2017 at 12:46 AM, Alexey
>>>                         Goncharuk <
>>>                         alexey.goncharuk@gmail.com
>>>                         <mailto: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