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 12:27:22 GMT
Vladislav,

Yep, you're right. I'll fix it.

Thanks!

14.04.2017 15:18, Vladisav Jelisavcic пишет:
> Hi Dmitry,
>
> it looks to me that this test is not valid - after the semaphore 2 
> fails the permits are redistributed
> so the expected number of permits should really be 20 not 10. Do you 
> agree?
>
> I guess before latest fix this test was (incorrectly) passing because 
> permits weren't released properly.
>
> What do you think?
>
> On Fri, Apr 14, 2017 at 11:27 AM, Dmitry Karachentsev 
> <dkarachentsev@gridgain.com <mailto:dkarachentsev@gridgain.com>> wrote:
>
>     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
>     <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