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 < dkarachent...@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_IgniteBinaryObjectsDataStrucut > ures > > 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 < > dkarachent...@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 < >> dkarachent...@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 <vladis...@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.kuliche...@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 < >>>>>> >>>>> dsetrak...@apache.org >>>>> >>>>>> wrote: >>>>>> >>>>>> On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk < >>>>>>> alexey.goncha...@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. >>>>>>> >>>>>>> >>> >> >> > > >
