Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Dmitry Karachentsev
It's not 100% reproducible, to get failed locally I've ran it many times in a loop (Intellij IDEA feature). N.B. This test was muted before the fix, so yes, it's could not be a cause. Thanks! 14.04.2017 17:23, Vladisav Jelisavcic пишет: Hmm, I cannot reproduce this behavior locally, my guess i

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Vladisav Jelisavcic
Hmm, I cannot reproduce this behavior locally, my guess is interrupt flag is not always cleared properly in #GridCacheSemaphore.acquire method (but it doesn't have anything to do with latest fix) Can you make it reproducible? On Fri, Apr 14, 2017 at 2:46 PM, Dmitry Karachentsev < dkarachent...@gr

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Dmitry Karachentsev
Vladislav, One more thing, This test [1] started failing on semaphore close when this fix [2] was introduced. Could you check it please? [1] http://ci.ignite.apache.org/viewLog.html?buildId=547151&tab=buildResultsDiv&buildTypeId=IgniteTests_IgniteDataStrucutures#testNameId-979977708202725050

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Dmitry Karachentsev
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 g

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread 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. W

Re: IgniteSemaphore and failoverSafe flag

2017-04-14 Thread Dmitry Karachentsev
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, Dmi

Re: IgniteSemaphore and failoverSafe flag

2017-04-13 Thread 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 mailto:dkarachent...@gridgain.com>> wrote: Hi Vladislav, Than

Re: IgniteSemaphore and failoverSafe flag

2017-04-12 Thread 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 >

Re: IgniteSemaphore and failoverSafe flag

2017-04-11 Thread Dmitry Karachentsev
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 t

Re: IgniteSemaphore and failoverSafe flag

2017-04-06 Thread 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?

Re: IgniteSemaphore and failoverSafe flag

2017-04-04 Thread Dmitry Karachentsev
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 wil

Re: IgniteSemaphore and failoverSafe flag

2017-03-20 Thread 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 : > Hi ever

Re: IgniteSemaphore and failoverSafe flag

2017-03-16 Thread Vladisav Jelisavcic
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.ku

Re: IgniteSemaphore and failoverSafe flag

2017-03-16 Thread Valentin Kulichenko
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

Re: IgniteSemaphore and failoverSafe flag

2017-03-14 Thread Dmitriy Setrakyan
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

Re: IgniteSemaphore and failoverSafe flag

2017-03-14 Thread Alexey Goncharuk
> > 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 gr

Re: IgniteSemaphore and failoverSafe flag

2017-03-07 Thread Dmitriy Setrakyan
On Tue, Mar 7, 2017 at 1:26 AM, Alexey Goncharuk wrote: > Guys, > > I was looking at this ticket and have a question related to the lock > semantics: > > Suppose I have a node which has already acquired the lock, and then all > affinity nodes related to the lock leave topology. In this case, if w

Re: IgniteSemaphore and failoverSafe flag

2017-03-07 Thread Alexey Goncharuk
Guys, I was looking at this ticket and have a question related to the lock semantics: Suppose I have a node which has already acquired the lock, and then all affinity nodes related to the lock leave topology. In this case, if we automatically re-created the lock, we would end up having two lock o

Re: IgniteSemaphore and failoverSafe flag

2016-11-02 Thread Andrey Gura
Vladisav, I've ran this test with partitioned cache and 1 backup and with replicated cache (4 nodes in topology). Behavior is the same. I think it is bug. But the first I wanted make sure that I understand failoverSafe flag correctly. Thank you for reply. I'll create ticket. On Tue, Nov 1, 2016

Re: IgniteSemaphore and failoverSafe flag

2016-11-01 Thread Vladisav Jelisavcic
Hi, when failoverSafe == true, semaphore should silently redistribute the permits acquired on the failing node. If failoverSafe is set to false, exception is thrown to every node attempting to acquire. It seems to me that when the first instance left topology, no backups were available (this is s

IgniteSemaphore and failoverSafe flag

2016-11-01 Thread Andrey Gura
Hi all! Guys, could somebody explain semantic of failoverSafe flag in IgniteSemaphore. From my point of view the test below should work but it fails: public void testFailoverReleasePermits() throws Exception { Ignite ignite = grid(0); IgniteSemaphore sem = ignite.semaphore("s