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 Thu, 13 Apr 2017 13:15:45 GMT
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