You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2016/02/17 08:13:00 UTC
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Cross-posting to the dev-list.
Hi Mario,
Thank you for source code. I was able to reproduce the issue and deduced it
to simpler example when two nodes start in a single JVM and one of the
holds key lock. See https://issues.apache.org/jira/browse/IGNITE-2671
Igniters,
I think someone with experience with cache/preload should throw a glance at
this ticket. Looks pretty nasty to me. Essentially, new node cannot join
topology when a single cache key lock is held.
Vladimir.
On Tue, Feb 16, 2016 at 8:33 PM, nyname00 <ma...@panagenda.com> wrote:
> Yakov,
>
> please see the code below. Simply start one node (in my case I started it
> directly from eclipse using 1.8u45) and wait for a few cycles, then start
> up
> the second node. You should see one more "sem created" message and then ...
> silence. If you kill the first node, the code processes normal again - but
> not when you kill the second one.
>
> Also note that on the second node no "Topology snapshot" message appears
> which, I guess, is not a good sign.
>
> I'm still testing, but if you replace the "sched" map-lock with a
> semaphore,
> everything seems to work ... until you kill one of the nodes. Then an
> exception is thrown every time the worker tries to get a new semaphore.
>
> Thanks for investigating,
> Mario
>
>
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(new IgniteConfiguration());
>
> Lock lock = ignite
> .getOrCreateCache(
> new CacheConfiguration<String,
> Boolean>("sched").setAtomicityMode(TRANSACTIONAL))
> .lock("sched-lock");
>
> if (lock.tryLock()) {
> try {
> System.out.println("pre start sched");
>
> ScheduledExecutorService es =
> Executors.newSingleThreadScheduledExecutor();
> ScheduledFuture<?> f = es.scheduleAtFixedRate(new
> Worker(ignite), 0, 2000,
> TimeUnit.MILLISECONDS);
>
> System.out.println("post start sched");
> try {
> f.get();
> } catch (Exception e) {
> e.printStackTrace();
> } finally {
> es.shutdownNow();
> }
> } finally {
> lock.unlock();
> }
> }
> }
>
> private static class Worker implements Runnable {
> private final Ignite ignite;
>
> public Worker(Ignite ignite) {
> this.ignite = ignite;
> }
>
> @Override
> public void run() {
> IgniteSemaphore sem = ignite.semaphore("sem-worker-1", 1,
> true, true);
>
> System.out.println("sem created");
> if (sem.tryAcquire()) {
> try {
> System.out.println("sem aquired");
> } finally {
> sem.release();
> System.out.println("sem released");
> }
> } else {
> System.out.println("sem not aquired");
> }
> }
> }
>
>
> yakov wrote
> > Hi Mario!
> >
> > Can you please share the code somehow? Reproducible example will be very
> > helpful.
> >
> > --Yakov
> >
> > 2016-02-16 16:57 GMT+03:00 nyname00 <
>
> > mario.stark@
>
> > >:
> >
> >> Hi Igniters,
> >>
> >> I'm getting some strange behavior when I try to call
> >> IgniteSemaphore#tryAquire() while holding a lock on a cache element -
> the
> >> method seems block forever.
> >>
> >> Here's the details:
> >> - create a cache (default, transactional) and get a lock using
> >> Lock#tryLock()
> >> - start a Executors.newSingleThreadScheduledExecutor() and schedule a
> >> worker to run every n seconds
> >> - in the worker, get a semaphore and call IgniteSemaphore#tryAcquire()
> >> - do some work and call IgniteSemaphore#release()
> >> (except for the cache/lock and semaphore no Ignite API calls are made)
> >>
> >> The whole thing works for a single node, but as soon as I start up an
> new
> >> node (with the same code) the IgniteSemaphore#tryAcquire() call starts
> >> blocking.
> >>
> >> Is this this a known limitation/issue or am I doing something wrong
> here?
> >>
> >> Thanks in advance,
> >> Mario
> >>
> >> ps: when I replace the cache-lock with an other semaphore, it works
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031.html
> >> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
> >>
>
>
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031p3034.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by nyname00 <ma...@panagenda.com>.
Thanks Val,
I just thought the "failoverSafe" flag on semaphore creation would take care
of this.
Tested it again with REPLICATED mode, and it works like a charm. With
default mode and 2 backups configured, i get a
"ClusterTopologyCheckedException: Failed to acquire lock for keys (primary
node left grid, retry transaction if possible)" on both remaining nodes, but
one of them manages to acquire the semaphore. So I guess that's ok.
Thanks again to all of you guys helping me out.
Mario
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031p3097.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by vkulichenko <va...@gmail.com>.
Hi Mario,
Semaphores are stored in the dedicated internal cache, which is used for all
atomics and sync primitives. Parameters of this cache are set in
AtomicConfiguration (provided in
IgniteConfiguration.setAtomicConfiguration). By default it's a partitioned
cache with zero backups. If you didn't change this, you don't have any
backups which can be the reason of the issue. Can you try to configure 1 or
2 backups or switch to REPLICATED mode and check if it works this way?
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031p3088.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by nyname00 <ma...@panagenda.com>.
Alexey,
could you please help me understand, how do the DS backups affect a
semaphore? Shouldn't the semaphore be replicated to all nodes?
I've re-tested the code with 2 backups configured, and three nodes started
but to no avail.
For three nodes it's even easier to reproduce: just start three nodes, and
kill the one with the "acquired" message on the console. The "Failed to find
..." message will appear on the remaining nodes.
Regards,
Mario
alexey.goncharuk wrote
> As for the "Failed to find semaphore with the given name" message, my
> first
> guess is that DataStructures were configured with 1 backups which led to
> the data loss when two nodes were stopped. Mario, can you please re-test
> your semaphore scenario with 2 backups configured for data structures?
> From my side, I can also take a look at the semaphore issue when I'm done
> with IGNITE-2610.
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031p3079.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Christos Erotocritou <ch...@gridgain.com>.
Ah, I realise now that this FAQ you are talking about is probably more of a dev one where as the one I’ve created is more product focused.
Christos
> On 11 Mar 2016, at 18:20, Christos Erotocritou <ch...@gridgain.com> wrote:
>
> We already have a basic FAQ page which I am populating:
> http://apacheignite.gridgain.org/docs/faq <http://apacheignite.gridgain.org/docs/faq>
>
> Please feel free to add to it.
>
> Not sure if we want to migrate this to the wiki?
>
> Christos
>
>> On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <dsetrakyan@apache.org <ma...@apache.org>> wrote:
>>
>> +1 on FAQ
>>
>> Can we just create a page, and start populating it?
>>
>> D.
>>
>> On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <avinogradov@gridgain.com <ma...@gridgain.com>>
>> wrote:
>>
>>> Yakov,
>>>
>>> I've answered.
>>> Seems we have to have special FAQ section at Ignite wiki to publish same
>>> things.
>>>
>>> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yzhdanov@apache.org <ma...@apache.org>>
>>> wrote:
>>>
>>>> Vlad and all (esp Val and Anton V.),
>>>>
>>>> I reviewed the PR. My comments are in the ticket.
>>>>
>>>> Anton V. there is a question regarding optimized-classnames.properties.
>>>> Can you please respond in ticket?
>>>>
>>>>
>>>> --Yakov
>>>>
>>>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yzhdanov@apache.org <ma...@apache.org>>:
>>>>
>>>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>>>> myself.
>>>>>
>>>>> --Yakov
>>>>>
>>>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com <ma...@gmail.com>>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>>>> i made a pull request, so hopefully this could be added to the next
>>>>>> release.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladisav
>>>>>>
>>>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>>>> alexey.goncharuk@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> The current implementation of IgniteCache.lock(key).lock() has the
>>>>>> same
>>>>>>> semantics as the transactional locks - cache topology cannot be
>>>>>> changed
>>>>>>> while there exists an ongoing transaction or an explicit lock is
>>>>>> held. The
>>>>>>> restriction for transactions is quite fundamental, the lock() issue
>>>>>> can be
>>>>>>> fixed if we re-implement locking the same way IgniteSemaphore
>>>>>> currently
>>>>>>> works.
>>>>>>>
>>>>>>> As for the "Failed to find semaphore with the given name" message, my
>>>>>> first
>>>>>>> guess is that DataStructures were configured with 1 backups which led
>>>>>> to
>>>>>>> the data loss when two nodes were stopped. Mario, can you please
>>>>>> re-test
>>>>>>> your semaphore scenario with 2 backups configured for data structures?
>>>>>>> From my side, I can also take a look at the semaphore issue when I'm
>>>>>> done
>>>>>>> with IGNITE-2610.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Anton Vinogradov <av...@gridgain.com>.
I've populated FAQ
https://cwiki.apache.org/confluence/display/IGNITE/FAQ
On Fri, Mar 11, 2016 at 9:58 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Fri, Mar 11, 2016 at 10:20 AM, Christos Erotocritou <
> christos@gridgain.com> wrote:
>
> > We already have a basic FAQ page which I am populating:
> > http://apacheignite.gridgain.org/docs/faq <
> > http://apacheignite.gridgain.org/docs/faq>
> >
> > Please feel free to add to it.
> >
>
> Thanks Christos! Here is the correct link (your link is just an alias):
> https://apacheignite.readme.io/docs/faq
>
> I think we should add a TOC up top as well, whenever you are done.
>
>
> > Not sure if we want to migrate this to the wiki?
> >
>
> I don’t think we need to.
>
>
> >
> > Christos
> >
> > > On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> > >
> > > +1 on FAQ
> > >
> > > Can we just create a page, and start populating it?
> > >
> > > D.
> > >
> > > On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <
> > avinogradov@gridgain.com>
> > > wrote:
> > >
> > >> Yakov,
> > >>
> > >> I've answered.
> > >> Seems we have to have special FAQ section at Ignite wiki to publish
> same
> > >> things.
> > >>
> > >> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> > >> wrote:
> > >>
> > >>> Vlad and all (esp Val and Anton V.),
> > >>>
> > >>> I reviewed the PR. My comments are in the ticket.
> > >>>
> > >>> Anton V. there is a question regarding
> optimized-classnames.properties.
> > >>> Can you please respond in ticket?
> > >>>
> > >>>
> > >>> --Yakov
> > >>>
> > >>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >>>
> > >>>> Vlad, that's great! I will take a look this week. Reassigning ticket
> > to
> > >>>> myself.
> > >>>>
> > >>>> --Yakov
> > >>>>
> > >>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com
> >:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>>>> i made a pull request, so hopefully this could be added to the next
> > >>>>> release.
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Vladisav
> > >>>>>
> > >>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>>>> alexey.goncharuk@gmail.com> wrote:
> > >>>>>
> > >>>>>> Folks,
> > >>>>>>
> > >>>>>> The current implementation of IgniteCache.lock(key).lock() has the
> > >>>>> same
> > >>>>>> semantics as the transactional locks - cache topology cannot be
> > >>>>> changed
> > >>>>>> while there exists an ongoing transaction or an explicit lock is
> > >>>>> held. The
> > >>>>>> restriction for transactions is quite fundamental, the lock()
> issue
> > >>>>> can be
> > >>>>>> fixed if we re-implement locking the same way IgniteSemaphore
> > >>>>> currently
> > >>>>>> works.
> > >>>>>>
> > >>>>>> As for the "Failed to find semaphore with the given name" message,
> > my
> > >>>>> first
> > >>>>>> guess is that DataStructures were configured with 1 backups which
> > led
> > >>>>> to
> > >>>>>> the data loss when two nodes were stopped. Mario, can you please
> > >>>>> re-test
> > >>>>>> your semaphore scenario with 2 backups configured for data
> > structures?
> > >>>>>> From my side, I can also take a look at the semaphore issue when
> I'm
> > >>>>> done
> > >>>>>> with IGNITE-2610.
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Anton Vinogradov <av...@gridgain.com>.
I've populated FAQ
https://cwiki.apache.org/confluence/display/IGNITE/FAQ
On Fri, Mar 11, 2016 at 9:58 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Fri, Mar 11, 2016 at 10:20 AM, Christos Erotocritou <
> christos@gridgain.com> wrote:
>
> > We already have a basic FAQ page which I am populating:
> > http://apacheignite.gridgain.org/docs/faq <
> > http://apacheignite.gridgain.org/docs/faq>
> >
> > Please feel free to add to it.
> >
>
> Thanks Christos! Here is the correct link (your link is just an alias):
> https://apacheignite.readme.io/docs/faq
>
> I think we should add a TOC up top as well, whenever you are done.
>
>
> > Not sure if we want to migrate this to the wiki?
> >
>
> I don’t think we need to.
>
>
> >
> > Christos
> >
> > > On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> > >
> > > +1 on FAQ
> > >
> > > Can we just create a page, and start populating it?
> > >
> > > D.
> > >
> > > On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <
> > avinogradov@gridgain.com>
> > > wrote:
> > >
> > >> Yakov,
> > >>
> > >> I've answered.
> > >> Seems we have to have special FAQ section at Ignite wiki to publish
> same
> > >> things.
> > >>
> > >> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> > >> wrote:
> > >>
> > >>> Vlad and all (esp Val and Anton V.),
> > >>>
> > >>> I reviewed the PR. My comments are in the ticket.
> > >>>
> > >>> Anton V. there is a question regarding
> optimized-classnames.properties.
> > >>> Can you please respond in ticket?
> > >>>
> > >>>
> > >>> --Yakov
> > >>>
> > >>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >>>
> > >>>> Vlad, that's great! I will take a look this week. Reassigning ticket
> > to
> > >>>> myself.
> > >>>>
> > >>>> --Yakov
> > >>>>
> > >>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com
> >:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>>>> i made a pull request, so hopefully this could be added to the next
> > >>>>> release.
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Vladisav
> > >>>>>
> > >>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>>>> alexey.goncharuk@gmail.com> wrote:
> > >>>>>
> > >>>>>> Folks,
> > >>>>>>
> > >>>>>> The current implementation of IgniteCache.lock(key).lock() has the
> > >>>>> same
> > >>>>>> semantics as the transactional locks - cache topology cannot be
> > >>>>> changed
> > >>>>>> while there exists an ongoing transaction or an explicit lock is
> > >>>>> held. The
> > >>>>>> restriction for transactions is quite fundamental, the lock()
> issue
> > >>>>> can be
> > >>>>>> fixed if we re-implement locking the same way IgniteSemaphore
> > >>>>> currently
> > >>>>>> works.
> > >>>>>>
> > >>>>>> As for the "Failed to find semaphore with the given name" message,
> > my
> > >>>>> first
> > >>>>>> guess is that DataStructures were configured with 1 backups which
> > led
> > >>>>> to
> > >>>>>> the data loss when two nodes were stopped. Mario, can you please
> > >>>>> re-test
> > >>>>>> your semaphore scenario with 2 backups configured for data
> > structures?
> > >>>>>> From my side, I can also take a look at the semaphore issue when
> I'm
> > >>>>> done
> > >>>>>> with IGNITE-2610.
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Mar 11, 2016 at 10:20 AM, Christos Erotocritou <
christos@gridgain.com> wrote:
> We already have a basic FAQ page which I am populating:
> http://apacheignite.gridgain.org/docs/faq <
> http://apacheignite.gridgain.org/docs/faq>
>
> Please feel free to add to it.
>
Thanks Christos! Here is the correct link (your link is just an alias):
https://apacheignite.readme.io/docs/faq
I think we should add a TOC up top as well, whenever you are done.
> Not sure if we want to migrate this to the wiki?
>
I don’t think we need to.
>
> Christos
>
> > On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
> >
> > +1 on FAQ
> >
> > Can we just create a page, and start populating it?
> >
> > D.
> >
> > On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <
> avinogradov@gridgain.com>
> > wrote:
> >
> >> Yakov,
> >>
> >> I've answered.
> >> Seems we have to have special FAQ section at Ignite wiki to publish same
> >> things.
> >>
> >> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> >> wrote:
> >>
> >>> Vlad and all (esp Val and Anton V.),
> >>>
> >>> I reviewed the PR. My comments are in the ticket.
> >>>
> >>> Anton V. there is a question regarding optimized-classnames.properties.
> >>> Can you please respond in ticket?
> >>>
> >>>
> >>> --Yakov
> >>>
> >>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> >>>
> >>>> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> >>>> myself.
> >>>>
> >>>> --Yakov
> >>>>
> >>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
> >>>>> i made a pull request, so hopefully this could be added to the next
> >>>>> release.
> >>>>>
> >>>>> Best regards,
> >>>>> Vladisav
> >>>>>
> >>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> >>>>> alexey.goncharuk@gmail.com> wrote:
> >>>>>
> >>>>>> Folks,
> >>>>>>
> >>>>>> The current implementation of IgniteCache.lock(key).lock() has the
> >>>>> same
> >>>>>> semantics as the transactional locks - cache topology cannot be
> >>>>> changed
> >>>>>> while there exists an ongoing transaction or an explicit lock is
> >>>>> held. The
> >>>>>> restriction for transactions is quite fundamental, the lock() issue
> >>>>> can be
> >>>>>> fixed if we re-implement locking the same way IgniteSemaphore
> >>>>> currently
> >>>>>> works.
> >>>>>>
> >>>>>> As for the "Failed to find semaphore with the given name" message,
> my
> >>>>> first
> >>>>>> guess is that DataStructures were configured with 1 backups which
> led
> >>>>> to
> >>>>>> the data loss when two nodes were stopped. Mario, can you please
> >>>>> re-test
> >>>>>> your semaphore scenario with 2 backups configured for data
> structures?
> >>>>>> From my side, I can also take a look at the semaphore issue when I'm
> >>>>> done
> >>>>>> with IGNITE-2610.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Mar 11, 2016 at 10:20 AM, Christos Erotocritou <
christos@gridgain.com> wrote:
> We already have a basic FAQ page which I am populating:
> http://apacheignite.gridgain.org/docs/faq <
> http://apacheignite.gridgain.org/docs/faq>
>
> Please feel free to add to it.
>
Thanks Christos! Here is the correct link (your link is just an alias):
https://apacheignite.readme.io/docs/faq
I think we should add a TOC up top as well, whenever you are done.
> Not sure if we want to migrate this to the wiki?
>
I don’t think we need to.
>
> Christos
>
> > On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
> >
> > +1 on FAQ
> >
> > Can we just create a page, and start populating it?
> >
> > D.
> >
> > On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <
> avinogradov@gridgain.com>
> > wrote:
> >
> >> Yakov,
> >>
> >> I've answered.
> >> Seems we have to have special FAQ section at Ignite wiki to publish same
> >> things.
> >>
> >> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> >> wrote:
> >>
> >>> Vlad and all (esp Val and Anton V.),
> >>>
> >>> I reviewed the PR. My comments are in the ticket.
> >>>
> >>> Anton V. there is a question regarding optimized-classnames.properties.
> >>> Can you please respond in ticket?
> >>>
> >>>
> >>> --Yakov
> >>>
> >>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> >>>
> >>>> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> >>>> myself.
> >>>>
> >>>> --Yakov
> >>>>
> >>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
> >>>>> i made a pull request, so hopefully this could be added to the next
> >>>>> release.
> >>>>>
> >>>>> Best regards,
> >>>>> Vladisav
> >>>>>
> >>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> >>>>> alexey.goncharuk@gmail.com> wrote:
> >>>>>
> >>>>>> Folks,
> >>>>>>
> >>>>>> The current implementation of IgniteCache.lock(key).lock() has the
> >>>>> same
> >>>>>> semantics as the transactional locks - cache topology cannot be
> >>>>> changed
> >>>>>> while there exists an ongoing transaction or an explicit lock is
> >>>>> held. The
> >>>>>> restriction for transactions is quite fundamental, the lock() issue
> >>>>> can be
> >>>>>> fixed if we re-implement locking the same way IgniteSemaphore
> >>>>> currently
> >>>>>> works.
> >>>>>>
> >>>>>> As for the "Failed to find semaphore with the given name" message,
> my
> >>>>> first
> >>>>>> guess is that DataStructures were configured with 1 backups which
> led
> >>>>> to
> >>>>>> the data loss when two nodes were stopped. Mario, can you please
> >>>>> re-test
> >>>>>> your semaphore scenario with 2 backups configured for data
> structures?
> >>>>>> From my side, I can also take a look at the semaphore issue when I'm
> >>>>> done
> >>>>>> with IGNITE-2610.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Christos Erotocritou <ch...@gridgain.com>.
Ah, I realise now that this FAQ you are talking about is probably more of a dev one where as the one I’ve created is more product focused.
Christos
> On 11 Mar 2016, at 18:20, Christos Erotocritou <ch...@gridgain.com> wrote:
>
> We already have a basic FAQ page which I am populating:
> http://apacheignite.gridgain.org/docs/faq <http://apacheignite.gridgain.org/docs/faq>
>
> Please feel free to add to it.
>
> Not sure if we want to migrate this to the wiki?
>
> Christos
>
>> On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <dsetrakyan@apache.org <ma...@apache.org>> wrote:
>>
>> +1 on FAQ
>>
>> Can we just create a page, and start populating it?
>>
>> D.
>>
>> On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <avinogradov@gridgain.com <ma...@gridgain.com>>
>> wrote:
>>
>>> Yakov,
>>>
>>> I've answered.
>>> Seems we have to have special FAQ section at Ignite wiki to publish same
>>> things.
>>>
>>> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yzhdanov@apache.org <ma...@apache.org>>
>>> wrote:
>>>
>>>> Vlad and all (esp Val and Anton V.),
>>>>
>>>> I reviewed the PR. My comments are in the ticket.
>>>>
>>>> Anton V. there is a question regarding optimized-classnames.properties.
>>>> Can you please respond in ticket?
>>>>
>>>>
>>>> --Yakov
>>>>
>>>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yzhdanov@apache.org <ma...@apache.org>>:
>>>>
>>>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>>>> myself.
>>>>>
>>>>> --Yakov
>>>>>
>>>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com <ma...@gmail.com>>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>>>> i made a pull request, so hopefully this could be added to the next
>>>>>> release.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladisav
>>>>>>
>>>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>>>> alexey.goncharuk@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> The current implementation of IgniteCache.lock(key).lock() has the
>>>>>> same
>>>>>>> semantics as the transactional locks - cache topology cannot be
>>>>>> changed
>>>>>>> while there exists an ongoing transaction or an explicit lock is
>>>>>> held. The
>>>>>>> restriction for transactions is quite fundamental, the lock() issue
>>>>>> can be
>>>>>>> fixed if we re-implement locking the same way IgniteSemaphore
>>>>>> currently
>>>>>>> works.
>>>>>>>
>>>>>>> As for the "Failed to find semaphore with the given name" message, my
>>>>>> first
>>>>>>> guess is that DataStructures were configured with 1 backups which led
>>>>>> to
>>>>>>> the data loss when two nodes were stopped. Mario, can you please
>>>>>> re-test
>>>>>>> your semaphore scenario with 2 backups configured for data structures?
>>>>>>> From my side, I can also take a look at the semaphore issue when I'm
>>>>>> done
>>>>>>> with IGNITE-2610.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Christos Erotocritou <ch...@gridgain.com>.
We already have a basic FAQ page which I am populating:
http://apacheignite.gridgain.org/docs/faq <http://apacheignite.gridgain.org/docs/faq>
Please feel free to add to it.
Not sure if we want to migrate this to the wiki?
Christos
> On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> +1 on FAQ
>
> Can we just create a page, and start populating it?
>
> D.
>
> On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <av...@gridgain.com>
> wrote:
>
>> Yakov,
>>
>> I've answered.
>> Seems we have to have special FAQ section at Ignite wiki to publish same
>> things.
>>
>> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
>> wrote:
>>
>>> Vlad and all (esp Val and Anton V.),
>>>
>>> I reviewed the PR. My comments are in the ticket.
>>>
>>> Anton V. there is a question regarding optimized-classnames.properties.
>>> Can you please respond in ticket?
>>>
>>>
>>> --Yakov
>>>
>>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>>>
>>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>>> myself.
>>>>
>>>> --Yakov
>>>>
>>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>>> i made a pull request, so hopefully this could be added to the next
>>>>> release.
>>>>>
>>>>> Best regards,
>>>>> Vladisav
>>>>>
>>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>>> alexey.goncharuk@gmail.com> wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> The current implementation of IgniteCache.lock(key).lock() has the
>>>>> same
>>>>>> semantics as the transactional locks - cache topology cannot be
>>>>> changed
>>>>>> while there exists an ongoing transaction or an explicit lock is
>>>>> held. The
>>>>>> restriction for transactions is quite fundamental, the lock() issue
>>>>> can be
>>>>>> fixed if we re-implement locking the same way IgniteSemaphore
>>>>> currently
>>>>>> works.
>>>>>>
>>>>>> As for the "Failed to find semaphore with the given name" message, my
>>>>> first
>>>>>> guess is that DataStructures were configured with 1 backups which led
>>>>> to
>>>>>> the data loss when two nodes were stopped. Mario, can you please
>>>>> re-test
>>>>>> your semaphore scenario with 2 backups configured for data structures?
>>>>>> From my side, I can also take a look at the semaphore issue when I'm
>>>>> done
>>>>>> with IGNITE-2610.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Christos Erotocritou <ch...@gridgain.com>.
We already have a basic FAQ page which I am populating:
http://apacheignite.gridgain.org/docs/faq <http://apacheignite.gridgain.org/docs/faq>
Please feel free to add to it.
Not sure if we want to migrate this to the wiki?
Christos
> On 11 Mar 2016, at 17:35, Dmitriy Setrakyan <ds...@apache.org> wrote:
>
> +1 on FAQ
>
> Can we just create a page, and start populating it?
>
> D.
>
> On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <av...@gridgain.com>
> wrote:
>
>> Yakov,
>>
>> I've answered.
>> Seems we have to have special FAQ section at Ignite wiki to publish same
>> things.
>>
>> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
>> wrote:
>>
>>> Vlad and all (esp Val and Anton V.),
>>>
>>> I reviewed the PR. My comments are in the ticket.
>>>
>>> Anton V. there is a question regarding optimized-classnames.properties.
>>> Can you please respond in ticket?
>>>
>>>
>>> --Yakov
>>>
>>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>>>
>>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>>> myself.
>>>>
>>>> --Yakov
>>>>
>>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>>> i made a pull request, so hopefully this could be added to the next
>>>>> release.
>>>>>
>>>>> Best regards,
>>>>> Vladisav
>>>>>
>>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>>> alexey.goncharuk@gmail.com> wrote:
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> The current implementation of IgniteCache.lock(key).lock() has the
>>>>> same
>>>>>> semantics as the transactional locks - cache topology cannot be
>>>>> changed
>>>>>> while there exists an ongoing transaction or an explicit lock is
>>>>> held. The
>>>>>> restriction for transactions is quite fundamental, the lock() issue
>>>>> can be
>>>>>> fixed if we re-implement locking the same way IgniteSemaphore
>>>>> currently
>>>>>> works.
>>>>>>
>>>>>> As for the "Failed to find semaphore with the given name" message, my
>>>>> first
>>>>>> guess is that DataStructures were configured with 1 backups which led
>>>>> to
>>>>>> the data loss when two nodes were stopped. Mario, can you please
>>>>> re-test
>>>>>> your semaphore scenario with 2 backups configured for data structures?
>>>>>> From my side, I can also take a look at the semaphore issue when I'm
>>>>> done
>>>>>> with IGNITE-2610.
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@apache.org>.
+1 on FAQ
Can we just create a page, and start populating it?
D.
On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <av...@gridgain.com>
wrote:
> Yakov,
>
> I've answered.
> Seems we have to have special FAQ section at Ignite wiki to publish same
> things.
>
> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
>> Vlad and all (esp Val and Anton V.),
>>
>> I reviewed the PR. My comments are in the ticket.
>>
>> Anton V. there is a question regarding optimized-classnames.properties.
>> Can you please respond in ticket?
>>
>>
>> --Yakov
>>
>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>>
>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>> myself.
>>>
>>> --Yakov
>>>
>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>> i made a pull request, so hopefully this could be added to the next
>>>> release.
>>>>
>>>> Best regards,
>>>> Vladisav
>>>>
>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>> alexey.goncharuk@gmail.com> wrote:
>>>>
>>>> > Folks,
>>>> >
>>>> > The current implementation of IgniteCache.lock(key).lock() has the
>>>> same
>>>> > semantics as the transactional locks - cache topology cannot be
>>>> changed
>>>> > while there exists an ongoing transaction or an explicit lock is
>>>> held. The
>>>> > restriction for transactions is quite fundamental, the lock() issue
>>>> can be
>>>> > fixed if we re-implement locking the same way IgniteSemaphore
>>>> currently
>>>> > works.
>>>> >
>>>> > As for the "Failed to find semaphore with the given name" message, my
>>>> first
>>>> > guess is that DataStructures were configured with 1 backups which led
>>>> to
>>>> > the data loss when two nodes were stopped. Mario, can you please
>>>> re-test
>>>> > your semaphore scenario with 2 backups configured for data structures?
>>>> > From my side, I can also take a look at the semaphore issue when I'm
>>>> done
>>>> > with IGNITE-2610.
>>>> >
>>>>
>>>
>>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@apache.org>.
+1 on FAQ
Can we just create a page, and start populating it?
D.
On Fri, Mar 11, 2016 at 3:25 AM, Anton Vinogradov <av...@gridgain.com>
wrote:
> Yakov,
>
> I've answered.
> Seems we have to have special FAQ section at Ignite wiki to publish same
> things.
>
> On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
>> Vlad and all (esp Val and Anton V.),
>>
>> I reviewed the PR. My comments are in the ticket.
>>
>> Anton V. there is a question regarding optimized-classnames.properties.
>> Can you please respond in ticket?
>>
>>
>> --Yakov
>>
>> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>>
>>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>>> myself.
>>>
>>> --Yakov
>>>
>>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>>> i made a pull request, so hopefully this could be added to the next
>>>> release.
>>>>
>>>> Best regards,
>>>> Vladisav
>>>>
>>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>>> alexey.goncharuk@gmail.com> wrote:
>>>>
>>>> > Folks,
>>>> >
>>>> > The current implementation of IgniteCache.lock(key).lock() has the
>>>> same
>>>> > semantics as the transactional locks - cache topology cannot be
>>>> changed
>>>> > while there exists an ongoing transaction or an explicit lock is
>>>> held. The
>>>> > restriction for transactions is quite fundamental, the lock() issue
>>>> can be
>>>> > fixed if we re-implement locking the same way IgniteSemaphore
>>>> currently
>>>> > works.
>>>> >
>>>> > As for the "Failed to find semaphore with the given name" message, my
>>>> first
>>>> > guess is that DataStructures were configured with 1 backups which led
>>>> to
>>>> > the data loss when two nodes were stopped. Mario, can you please
>>>> re-test
>>>> > your semaphore scenario with 2 backups configured for data structures?
>>>> > From my side, I can also take a look at the semaphore issue when I'm
>>>> done
>>>> > with IGNITE-2610.
>>>> >
>>>>
>>>
>>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Anton Vinogradov <av...@gridgain.com>.
Yakov,
I've answered.
Seems we have to have special FAQ section at Ignite wiki to publish same
things.
On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Vlad and all (esp Val and Anton V.),
>
> I reviewed the PR. My comments are in the ticket.
>
> Anton V. there is a question regarding optimized-classnames.properties.
> Can you please respond in ticket?
>
>
> --Yakov
>
> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>
>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>> myself.
>>
>> --Yakov
>>
>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>>> Hi,
>>>
>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>> i made a pull request, so hopefully this could be added to the next
>>> release.
>>>
>>> Best regards,
>>> Vladisav
>>>
>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>> alexey.goncharuk@gmail.com> wrote:
>>>
>>> > Folks,
>>> >
>>> > The current implementation of IgniteCache.lock(key).lock() has the same
>>> > semantics as the transactional locks - cache topology cannot be changed
>>> > while there exists an ongoing transaction or an explicit lock is held.
>>> The
>>> > restriction for transactions is quite fundamental, the lock() issue
>>> can be
>>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>>> > works.
>>> >
>>> > As for the "Failed to find semaphore with the given name" message, my
>>> first
>>> > guess is that DataStructures were configured with 1 backups which led
>>> to
>>> > the data loss when two nodes were stopped. Mario, can you please
>>> re-test
>>> > your semaphore scenario with 2 backups configured for data structures?
>>> > From my side, I can also take a look at the semaphore issue when I'm
>>> done
>>> > with IGNITE-2610.
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Anton Vinogradov <av...@gridgain.com>.
Yakov,
I've answered.
Seems we have to have special FAQ section at Ignite wiki to publish same
things.
On Sun, Mar 6, 2016 at 12:21 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Vlad and all (esp Val and Anton V.),
>
> I reviewed the PR. My comments are in the ticket.
>
> Anton V. there is a question regarding optimized-classnames.properties.
> Can you please respond in ticket?
>
>
> --Yakov
>
> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>
>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>> myself.
>>
>> --Yakov
>>
>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>>> Hi,
>>>
>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>> i made a pull request, so hopefully this could be added to the next
>>> release.
>>>
>>> Best regards,
>>> Vladisav
>>>
>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>> alexey.goncharuk@gmail.com> wrote:
>>>
>>> > Folks,
>>> >
>>> > The current implementation of IgniteCache.lock(key).lock() has the same
>>> > semantics as the transactional locks - cache topology cannot be changed
>>> > while there exists an ongoing transaction or an explicit lock is held.
>>> The
>>> > restriction for transactions is quite fundamental, the lock() issue
>>> can be
>>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>>> > works.
>>> >
>>> > As for the "Failed to find semaphore with the given name" message, my
>>> first
>>> > guess is that DataStructures were configured with 1 backups which led
>>> to
>>> > the data loss when two nodes were stopped. Mario, can you please
>>> re-test
>>> > your semaphore scenario with 2 backups configured for data structures?
>>> > From my side, I can also take a look at the semaphore issue when I'm
>>> done
>>> > with IGNITE-2610.
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad and All!
I have reviewed and merged ignite-642 (
https://issues.apache.org/jira/browse/IGNITE-642 Implement
IgniteReentrantLock data structure) to master. I will send separate email
to user- and dev-list on this.
--Yakov
2016-04-27 13:07 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad, not yet, unfortunately. I will try to do today.
>
> --Yakov
>
> 2016-04-27 11:40 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>
>> Yakov,
>>
>> did you had time to do another review round of ignite-642?
>>
>> Thanks!
>>
>> On Fri, Apr 15, 2016 at 3:53 PM, Vladisav Jelisavcic <vladisavj@gmail.com
>> >
>> wrote:
>>
>> > Yakov,
>> >
>> > I've finished the initialization tests for ignite-642 (and moved
>> > serialization test from GridCacheLockAbstractTest to
>> > IgniteLockAbstractSelfTest).
>> > Please check the commit and let me know if you spot anything else.
>> > Thanks!
>> >
>> > On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <
>> vladisavj@gmail.com
>> > > wrote:
>> >
>> >> Yakov,
>> >>
>> >> I reviewed the changes in ignite-642 and it looks good to me, but I
>> have
>> >> one question.
>> >> Can you please look at my comment in ignite-642 ticket?
>> >>
>> >> Thanks!
>> >> Vladisav
>> >>
>> >> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <
>> vladisavj@gmail.com
>> >> > wrote:
>> >>
>> >>> Sure, I'll look into it later today, or tomorrow at the latest
>> >>>
>> >>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org>
>> >>> wrote:
>> >>>
>> >>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>> >>>>
>> >>>> Alex, can you please take a look at my latest commit as well and
>> provide
>> >>>> comments?
>> >>>>
>> >>>> --Yakov
>> >>>>
>> >>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>> >>>>
>> >>>> > Very good points, Alexey. I will look at this tomorrow and finalize
>> >>>> the
>> >>>> > changes.
>> >>>> >
>> >>>> > --Yakov
>> >>>> >
>> >>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
>> >>>> alexey.goncharuk@gmail.com>:
>> >>>> >
>> >>>> >> Guys,
>> >>>> >>
>> >>>> >> I fixed code style a bit and pushed my changes to the branch.
>> >>>> >>
>> >>>> >> Couple of questions:
>> >>>> >> - I see that some of the Errors caught do not get re-thrown
>> (e.g. if
>> >>>> >> interruptAll flag is set). I believe we should at least re-throw
>> >>>> OOME in
>> >>>> >> any case.
>> >>>> >> - readResolve method is missing for CacheLockImpl. The current
>> >>>> >> readExternal/writeExternal code uses static stash field. I looked
>> >>>> around
>> >>>> >> in
>> >>>> >> the code and found that IgniteKernal uses localIgnite, while
>> >>>> >> GridCacheAdapter uses stash. Which way is the correct one?
>> >>>> >>
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, not yet, unfortunately. I will try to do today.
--Yakov
2016-04-27 11:40 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Yakov,
>
> did you had time to do another review round of ignite-642?
>
> Thanks!
>
> On Fri, Apr 15, 2016 at 3:53 PM, Vladisav Jelisavcic <vl...@gmail.com>
> wrote:
>
> > Yakov,
> >
> > I've finished the initialization tests for ignite-642 (and moved
> > serialization test from GridCacheLockAbstractTest to
> > IgniteLockAbstractSelfTest).
> > Please check the commit and let me know if you spot anything else.
> > Thanks!
> >
> > On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <
> vladisavj@gmail.com
> > > wrote:
> >
> >> Yakov,
> >>
> >> I reviewed the changes in ignite-642 and it looks good to me, but I have
> >> one question.
> >> Can you please look at my comment in ignite-642 ticket?
> >>
> >> Thanks!
> >> Vladisav
> >>
> >> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <
> vladisavj@gmail.com
> >> > wrote:
> >>
> >>> Sure, I'll look into it later today, or tomorrow at the latest
> >>>
> >>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org>
> >>> wrote:
> >>>
> >>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
> >>>>
> >>>> Alex, can you please take a look at my latest commit as well and
> provide
> >>>> comments?
> >>>>
> >>>> --Yakov
> >>>>
> >>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >>>>
> >>>> > Very good points, Alexey. I will look at this tomorrow and finalize
> >>>> the
> >>>> > changes.
> >>>> >
> >>>> > --Yakov
> >>>> >
> >>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
> >>>> alexey.goncharuk@gmail.com>:
> >>>> >
> >>>> >> Guys,
> >>>> >>
> >>>> >> I fixed code style a bit and pushed my changes to the branch.
> >>>> >>
> >>>> >> Couple of questions:
> >>>> >> - I see that some of the Errors caught do not get re-thrown (e.g.
> if
> >>>> >> interruptAll flag is set). I believe we should at least re-throw
> >>>> OOME in
> >>>> >> any case.
> >>>> >> - readResolve method is missing for CacheLockImpl. The current
> >>>> >> readExternal/writeExternal code uses static stash field. I looked
> >>>> around
> >>>> >> in
> >>>> >> the code and found that IgniteKernal uses localIgnite, while
> >>>> >> GridCacheAdapter uses stash. Which way is the correct one?
> >>>> >>
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>
> >>>
> >>
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Yakov,
did you had time to do another review round of ignite-642?
Thanks!
On Fri, Apr 15, 2016 at 3:53 PM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Yakov,
>
> I've finished the initialization tests for ignite-642 (and moved
> serialization test from GridCacheLockAbstractTest to
> IgniteLockAbstractSelfTest).
> Please check the commit and let me know if you spot anything else.
> Thanks!
>
> On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <vladisavj@gmail.com
> > wrote:
>
>> Yakov,
>>
>> I reviewed the changes in ignite-642 and it looks good to me, but I have
>> one question.
>> Can you please look at my comment in ignite-642 ticket?
>>
>> Thanks!
>> Vladisav
>>
>> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vladisavj@gmail.com
>> > wrote:
>>
>>> Sure, I'll look into it later today, or tomorrow at the latest
>>>
>>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org>
>>> wrote:
>>>
>>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>>>
>>>> Alex, can you please take a look at my latest commit as well and provide
>>>> comments?
>>>>
>>>> --Yakov
>>>>
>>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>>>>
>>>> > Very good points, Alexey. I will look at this tomorrow and finalize
>>>> the
>>>> > changes.
>>>> >
>>>> > --Yakov
>>>> >
>>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
>>>> alexey.goncharuk@gmail.com>:
>>>> >
>>>> >> Guys,
>>>> >>
>>>> >> I fixed code style a bit and pushed my changes to the branch.
>>>> >>
>>>> >> Couple of questions:
>>>> >> - I see that some of the Errors caught do not get re-thrown (e.g. if
>>>> >> interruptAll flag is set). I believe we should at least re-throw
>>>> OOME in
>>>> >> any case.
>>>> >> - readResolve method is missing for CacheLockImpl. The current
>>>> >> readExternal/writeExternal code uses static stash field. I looked
>>>> around
>>>> >> in
>>>> >> the code and found that IgniteKernal uses localIgnite, while
>>>> >> GridCacheAdapter uses stash. Which way is the correct one?
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Yakov,
I've finished the initialization tests for ignite-642 (and moved
serialization test from GridCacheLockAbstractTest to
IgniteLockAbstractSelfTest).
Please check the commit and let me know if you spot anything else.
Thanks!
On Fri, Apr 15, 2016 at 10:11 AM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Yakov,
>
> I reviewed the changes in ignite-642 and it looks good to me, but I have
> one question.
> Can you please look at my comment in ignite-642 ticket?
>
> Thanks!
> Vladisav
>
> On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vl...@gmail.com>
> wrote:
>
>> Sure, I'll look into it later today, or tomorrow at the latest
>>
>> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org>
>> wrote:
>>
>>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>>
>>> Alex, can you please take a look at my latest commit as well and provide
>>> comments?
>>>
>>> --Yakov
>>>
>>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>>>
>>> > Very good points, Alexey. I will look at this tomorrow and finalize the
>>> > changes.
>>> >
>>> > --Yakov
>>> >
>>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <
>>> alexey.goncharuk@gmail.com>:
>>> >
>>> >> Guys,
>>> >>
>>> >> I fixed code style a bit and pushed my changes to the branch.
>>> >>
>>> >> Couple of questions:
>>> >> - I see that some of the Errors caught do not get re-thrown (e.g. if
>>> >> interruptAll flag is set). I believe we should at least re-throw OOME
>>> in
>>> >> any case.
>>> >> - readResolve method is missing for CacheLockImpl. The current
>>> >> readExternal/writeExternal code uses static stash field. I looked
>>> around
>>> >> in
>>> >> the code and found that IgniteKernal uses localIgnite, while
>>> >> GridCacheAdapter uses stash. Which way is the correct one?
>>> >>
>>> >>
>>> >
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Yakov,
I reviewed the changes in ignite-642 and it looks good to me, but I have
one question.
Can you please look at my comment in ignite-642 ticket?
Thanks!
Vladisav
On Thu, Apr 14, 2016 at 7:51 PM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Sure, I'll look into it later today, or tomorrow at the latest
>
> On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
>> Vlad, please see my changes in ignite-642 and comment in the ticket.
>>
>> Alex, can you please take a look at my latest commit as well and provide
>> comments?
>>
>> --Yakov
>>
>> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>>
>> > Very good points, Alexey. I will look at this tomorrow and finalize the
>> > changes.
>> >
>> > --Yakov
>> >
>> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <alexey.goncharuk@gmail.com
>> >:
>> >
>> >> Guys,
>> >>
>> >> I fixed code style a bit and pushed my changes to the branch.
>> >>
>> >> Couple of questions:
>> >> - I see that some of the Errors caught do not get re-thrown (e.g. if
>> >> interruptAll flag is set). I believe we should at least re-throw OOME
>> in
>> >> any case.
>> >> - readResolve method is missing for CacheLockImpl. The current
>> >> readExternal/writeExternal code uses static stash field. I looked
>> around
>> >> in
>> >> the code and found that IgniteKernal uses localIgnite, while
>> >> GridCacheAdapter uses stash. Which way is the correct one?
>> >>
>> >>
>> >
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Sure, I'll look into it later today, or tomorrow at the latest
On Thu, Apr 14, 2016 at 5:53 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Vlad, please see my changes in ignite-642 and comment in the ticket.
>
> Alex, can you please take a look at my latest commit as well and provide
> comments?
>
> --Yakov
>
> 2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>
> > Very good points, Alexey. I will look at this tomorrow and finalize the
> > changes.
> >
> > --Yakov
> >
> > 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <alexey.goncharuk@gmail.com
> >:
> >
> >> Guys,
> >>
> >> I fixed code style a bit and pushed my changes to the branch.
> >>
> >> Couple of questions:
> >> - I see that some of the Errors caught do not get re-thrown (e.g. if
> >> interruptAll flag is set). I believe we should at least re-throw OOME in
> >> any case.
> >> - readResolve method is missing for CacheLockImpl. The current
> >> readExternal/writeExternal code uses static stash field. I looked around
> >> in
> >> the code and found that IgniteKernal uses localIgnite, while
> >> GridCacheAdapter uses stash. Which way is the correct one?
> >>
> >>
> >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, please see my changes in ignite-642 and comment in the ticket.
Alex, can you please take a look at my latest commit as well and provide
comments?
--Yakov
2016-04-12 23:47 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Very good points, Alexey. I will look at this tomorrow and finalize the
> changes.
>
> --Yakov
>
> 2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
>
>> Guys,
>>
>> I fixed code style a bit and pushed my changes to the branch.
>>
>> Couple of questions:
>> - I see that some of the Errors caught do not get re-thrown (e.g. if
>> interruptAll flag is set). I believe we should at least re-throw OOME in
>> any case.
>> - readResolve method is missing for CacheLockImpl. The current
>> readExternal/writeExternal code uses static stash field. I looked around
>> in
>> the code and found that IgniteKernal uses localIgnite, while
>> GridCacheAdapter uses stash. Which way is the correct one?
>>
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Very good points, Alexey. I will look at this tomorrow and finalize the
changes.
--Yakov
2016-04-12 23:41 GMT+03:00 Alexey Goncharuk <al...@gmail.com>:
> Guys,
>
> I fixed code style a bit and pushed my changes to the branch.
>
> Couple of questions:
> - I see that some of the Errors caught do not get re-thrown (e.g. if
> interruptAll flag is set). I believe we should at least re-throw OOME in
> any case.
> - readResolve method is missing for CacheLockImpl. The current
> readExternal/writeExternal code uses static stash field. I looked around in
> the code and found that IgniteKernal uses localIgnite, while
> GridCacheAdapter uses stash. Which way is the correct one?
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Alexey Goncharuk <al...@gmail.com>.
Guys,
I fixed code style a bit and pushed my changes to the branch.
Couple of questions:
- I see that some of the Errors caught do not get re-thrown (e.g. if
interruptAll flag is set). I believe we should at least re-throw OOME in
any case.
- readResolve method is missing for CacheLockImpl. The current
readExternal/writeExternal code uses static stash field. I looked around in
the code and found that IgniteKernal uses localIgnite, while
GridCacheAdapter uses stash. Which way is the correct one?
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, I reviewed the code and committed it to ignite-642 branch (after some
minor style changes + I added new tests to suites).
Alex G & Sam can you please review (see diff with our current master) and
provide comments here. I think we are very close to finish with this issue.
Thanks for contributing this!
--Yakov
2016-04-11 18:22 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad, I did not have time today. Will review tomorrow.
>
> --Yakov
>
> 2016-04-08 13:51 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>
>> Very good news, Vlad! I will take a look over weekend or on Monday.
>>
>> --Yakov
>>
>> 2016-04-08 12:58 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>>> Yakov,
>>>
>>> sorry for the long delay, I added another commit to the PR,
>>> can you please do the review again?
>>>
>>> Thanks!
>>> Vladisav
>>>
>>> On Sun, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic <
>>> vladisavj@gmail.com>
>>> wrote:
>>>
>>> > Yakov, I've seen your comments, can you please check the jira again?
>>> >
>>> >
>>> > On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yz...@apache.org>
>>> > wrote:
>>> >
>>> >> Vlad, can you please check my comments again?
>>> >>
>>> >> --Yakov
>>> >>
>>> >> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>> >>
>>> >> > Hi Yakov,
>>> >> >
>>> >> > yes, thanks for the comments, I think everything should be ok now,
>>> >> > please review the PR and tell me if you think anything else is
>>> needed.
>>> >> >
>>> >> > Once ignite-642 is merged into master,
>>> >> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
>>> >> > release).
>>> >> >
>>> >> > Best regrads,
>>> >> > Vladisav
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <
>>> yzhdanov@gridgain.com>
>>> >> > wrote:
>>> >> >
>>> >> > > Vlad, did you have a chance to review my latest comments?
>>> >> > >
>>> >> > > Thanks!
>>> >> > > --
>>> >> > > Yakov Zhdanov, Director R&D
>>> >> > > *GridGain Systems*
>>> >> > > www.gridgain.com
>>> >> > >
>>> >> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>>> >> > >
>>> >> > > > Vlad and all (esp Val and Anton V.),
>>> >> > > >
>>> >> > > > I reviewed the PR. My comments are in the ticket.
>>> >> > > >
>>> >> > > > Anton V. there is a question regarding
>>> >> optimized-classnames.properties.
>>> >> > > > Can you please respond in ticket?
>>> >> > > >
>>> >> > > >
>>> >> > > > --Yakov
>>> >> > > >
>>> >> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>>> >> > > >
>>> >> > > >> Vlad, that's great! I will take a look this week. Reassigning
>>> >> ticket
>>> >> > to
>>> >> > > >> myself.
>>> >> > > >>
>>> >> > > >> --Yakov
>>> >> > > >>
>>> >> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <
>>> >> vladisavj@gmail.com>:
>>> >> > > >>
>>> >> > > >>> Hi,
>>> >> > > >>>
>>> >> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>> >> > > >>> i made a pull request, so hopefully this could be added to the
>>> >> next
>>> >> > > >>> release.
>>> >> > > >>>
>>> >> > > >>> Best regards,
>>> >> > > >>> Vladisav
>>> >> > > >>>
>>> >> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>> >> > > >>> alexey.goncharuk@gmail.com> wrote:
>>> >> > > >>>
>>> >> > > >>> > Folks,
>>> >> > > >>> >
>>> >> > > >>> > The current implementation of IgniteCache.lock(key).lock()
>>> has
>>> >> the
>>> >> > > same
>>> >> > > >>> > semantics as the transactional locks - cache topology
>>> cannot be
>>> >> > > changed
>>> >> > > >>> > while there exists an ongoing transaction or an explicit
>>> lock is
>>> >> > > held.
>>> >> > > >>> The
>>> >> > > >>> > restriction for transactions is quite fundamental, the
>>> lock()
>>> >> issue
>>> >> > > >>> can be
>>> >> > > >>> > fixed if we re-implement locking the same way
>>> IgniteSemaphore
>>> >> > > currently
>>> >> > > >>> > works.
>>> >> > > >>> >
>>> >> > > >>> > As for the "Failed to find semaphore with the given name"
>>> >> message,
>>> >> > my
>>> >> > > >>> first
>>> >> > > >>> > guess is that DataStructures were configured with 1 backups
>>> >> which
>>> >> > led
>>> >> > > >>> to
>>> >> > > >>> > the data loss when two nodes were stopped. Mario, can you
>>> please
>>> >> > > >>> re-test
>>> >> > > >>> > your semaphore scenario with 2 backups configured for data
>>> >> > > structures?
>>> >> > > >>> > From my side, I can also take a look at the semaphore issue
>>> when
>>> >> > I'm
>>> >> > > >>> done
>>> >> > > >>> > with IGNITE-2610.
>>> >> > > >>> >
>>> >> > > >>>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >
>>> >> > >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, I did not have time today. Will review tomorrow.
--Yakov
2016-04-08 13:51 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Very good news, Vlad! I will take a look over weekend or on Monday.
>
> --Yakov
>
> 2016-04-08 12:58 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>
>> Yakov,
>>
>> sorry for the long delay, I added another commit to the PR,
>> can you please do the review again?
>>
>> Thanks!
>> Vladisav
>>
>> On Sun, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic <
>> vladisavj@gmail.com>
>> wrote:
>>
>> > Yakov, I've seen your comments, can you please check the jira again?
>> >
>> >
>> > On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yz...@apache.org>
>> > wrote:
>> >
>> >> Vlad, can you please check my comments again?
>> >>
>> >> --Yakov
>> >>
>> >> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>> >>
>> >> > Hi Yakov,
>> >> >
>> >> > yes, thanks for the comments, I think everything should be ok now,
>> >> > please review the PR and tell me if you think anything else is
>> needed.
>> >> >
>> >> > Once ignite-642 is merged into master,
>> >> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
>> >> > release).
>> >> >
>> >> > Best regrads,
>> >> > Vladisav
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <
>> yzhdanov@gridgain.com>
>> >> > wrote:
>> >> >
>> >> > > Vlad, did you have a chance to review my latest comments?
>> >> > >
>> >> > > Thanks!
>> >> > > --
>> >> > > Yakov Zhdanov, Director R&D
>> >> > > *GridGain Systems*
>> >> > > www.gridgain.com
>> >> > >
>> >> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>> >> > >
>> >> > > > Vlad and all (esp Val and Anton V.),
>> >> > > >
>> >> > > > I reviewed the PR. My comments are in the ticket.
>> >> > > >
>> >> > > > Anton V. there is a question regarding
>> >> optimized-classnames.properties.
>> >> > > > Can you please respond in ticket?
>> >> > > >
>> >> > > >
>> >> > > > --Yakov
>> >> > > >
>> >> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>> >> > > >
>> >> > > >> Vlad, that's great! I will take a look this week. Reassigning
>> >> ticket
>> >> > to
>> >> > > >> myself.
>> >> > > >>
>> >> > > >> --Yakov
>> >> > > >>
>> >> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <
>> >> vladisavj@gmail.com>:
>> >> > > >>
>> >> > > >>> Hi,
>> >> > > >>>
>> >> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
>> >> > > >>> i made a pull request, so hopefully this could be added to the
>> >> next
>> >> > > >>> release.
>> >> > > >>>
>> >> > > >>> Best regards,
>> >> > > >>> Vladisav
>> >> > > >>>
>> >> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>> >> > > >>> alexey.goncharuk@gmail.com> wrote:
>> >> > > >>>
>> >> > > >>> > Folks,
>> >> > > >>> >
>> >> > > >>> > The current implementation of IgniteCache.lock(key).lock()
>> has
>> >> the
>> >> > > same
>> >> > > >>> > semantics as the transactional locks - cache topology cannot
>> be
>> >> > > changed
>> >> > > >>> > while there exists an ongoing transaction or an explicit
>> lock is
>> >> > > held.
>> >> > > >>> The
>> >> > > >>> > restriction for transactions is quite fundamental, the lock()
>> >> issue
>> >> > > >>> can be
>> >> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
>> >> > > currently
>> >> > > >>> > works.
>> >> > > >>> >
>> >> > > >>> > As for the "Failed to find semaphore with the given name"
>> >> message,
>> >> > my
>> >> > > >>> first
>> >> > > >>> > guess is that DataStructures were configured with 1 backups
>> >> which
>> >> > led
>> >> > > >>> to
>> >> > > >>> > the data loss when two nodes were stopped. Mario, can you
>> please
>> >> > > >>> re-test
>> >> > > >>> > your semaphore scenario with 2 backups configured for data
>> >> > > structures?
>> >> > > >>> > From my side, I can also take a look at the semaphore issue
>> when
>> >> > I'm
>> >> > > >>> done
>> >> > > >>> > with IGNITE-2610.
>> >> > > >>> >
>> >> > > >>>
>> >> > > >>
>> >> > > >>
>> >> > > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Very good news, Vlad! I will take a look over weekend or on Monday.
--Yakov
2016-04-08 12:58 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Yakov,
>
> sorry for the long delay, I added another commit to the PR,
> can you please do the review again?
>
> Thanks!
> Vladisav
>
> On Sun, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic <vladisavj@gmail.com
> >
> wrote:
>
> > Yakov, I've seen your comments, can you please check the jira again?
> >
> >
> > On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yz...@apache.org>
> > wrote:
> >
> >> Vlad, can you please check my comments again?
> >>
> >> --Yakov
> >>
> >> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> >>
> >> > Hi Yakov,
> >> >
> >> > yes, thanks for the comments, I think everything should be ok now,
> >> > please review the PR and tell me if you think anything else is needed.
> >> >
> >> > Once ignite-642 is merged into master,
> >> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> >> > release).
> >> >
> >> > Best regrads,
> >> > Vladisav
> >> >
> >> >
> >> >
> >> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <
> yzhdanov@gridgain.com>
> >> > wrote:
> >> >
> >> > > Vlad, did you have a chance to review my latest comments?
> >> > >
> >> > > Thanks!
> >> > > --
> >> > > Yakov Zhdanov, Director R&D
> >> > > *GridGain Systems*
> >> > > www.gridgain.com
> >> > >
> >> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >> > >
> >> > > > Vlad and all (esp Val and Anton V.),
> >> > > >
> >> > > > I reviewed the PR. My comments are in the ticket.
> >> > > >
> >> > > > Anton V. there is a question regarding
> >> optimized-classnames.properties.
> >> > > > Can you please respond in ticket?
> >> > > >
> >> > > >
> >> > > > --Yakov
> >> > > >
> >> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> >> > > >
> >> > > >> Vlad, that's great! I will take a look this week. Reassigning
> >> ticket
> >> > to
> >> > > >> myself.
> >> > > >>
> >> > > >> --Yakov
> >> > > >>
> >> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <
> >> vladisavj@gmail.com>:
> >> > > >>
> >> > > >>> Hi,
> >> > > >>>
> >> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> >> > > >>> i made a pull request, so hopefully this could be added to the
> >> next
> >> > > >>> release.
> >> > > >>>
> >> > > >>> Best regards,
> >> > > >>> Vladisav
> >> > > >>>
> >> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> >> > > >>> alexey.goncharuk@gmail.com> wrote:
> >> > > >>>
> >> > > >>> > Folks,
> >> > > >>> >
> >> > > >>> > The current implementation of IgniteCache.lock(key).lock() has
> >> the
> >> > > same
> >> > > >>> > semantics as the transactional locks - cache topology cannot
> be
> >> > > changed
> >> > > >>> > while there exists an ongoing transaction or an explicit lock
> is
> >> > > held.
> >> > > >>> The
> >> > > >>> > restriction for transactions is quite fundamental, the lock()
> >> issue
> >> > > >>> can be
> >> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> >> > > currently
> >> > > >>> > works.
> >> > > >>> >
> >> > > >>> > As for the "Failed to find semaphore with the given name"
> >> message,
> >> > my
> >> > > >>> first
> >> > > >>> > guess is that DataStructures were configured with 1 backups
> >> which
> >> > led
> >> > > >>> to
> >> > > >>> > the data loss when two nodes were stopped. Mario, can you
> please
> >> > > >>> re-test
> >> > > >>> > your semaphore scenario with 2 backups configured for data
> >> > > structures?
> >> > > >>> > From my side, I can also take a look at the semaphore issue
> when
> >> > I'm
> >> > > >>> done
> >> > > >>> > with IGNITE-2610.
> >> > > >>> >
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Yakov,
sorry for the long delay, I added another commit to the PR,
can you please do the review again?
Thanks!
Vladisav
On Sun, Mar 27, 2016 at 11:30 AM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Yakov, I've seen your comments, can you please check the jira again?
>
>
> On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yz...@apache.org>
> wrote:
>
>> Vlad, can you please check my comments again?
>>
>> --Yakov
>>
>> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>> > Hi Yakov,
>> >
>> > yes, thanks for the comments, I think everything should be ok now,
>> > please review the PR and tell me if you think anything else is needed.
>> >
>> > Once ignite-642 is merged into master,
>> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
>> > release).
>> >
>> > Best regrads,
>> > Vladisav
>> >
>> >
>> >
>> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
>> > wrote:
>> >
>> > > Vlad, did you have a chance to review my latest comments?
>> > >
>> > > Thanks!
>> > > --
>> > > Yakov Zhdanov, Director R&D
>> > > *GridGain Systems*
>> > > www.gridgain.com
>> > >
>> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>> > >
>> > > > Vlad and all (esp Val and Anton V.),
>> > > >
>> > > > I reviewed the PR. My comments are in the ticket.
>> > > >
>> > > > Anton V. there is a question regarding
>> optimized-classnames.properties.
>> > > > Can you please respond in ticket?
>> > > >
>> > > >
>> > > > --Yakov
>> > > >
>> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>> > > >
>> > > >> Vlad, that's great! I will take a look this week. Reassigning
>> ticket
>> > to
>> > > >> myself.
>> > > >>
>> > > >> --Yakov
>> > > >>
>> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <
>> vladisavj@gmail.com>:
>> > > >>
>> > > >>> Hi,
>> > > >>>
>> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
>> > > >>> i made a pull request, so hopefully this could be added to the
>> next
>> > > >>> release.
>> > > >>>
>> > > >>> Best regards,
>> > > >>> Vladisav
>> > > >>>
>> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>> > > >>> alexey.goncharuk@gmail.com> wrote:
>> > > >>>
>> > > >>> > Folks,
>> > > >>> >
>> > > >>> > The current implementation of IgniteCache.lock(key).lock() has
>> the
>> > > same
>> > > >>> > semantics as the transactional locks - cache topology cannot be
>> > > changed
>> > > >>> > while there exists an ongoing transaction or an explicit lock is
>> > > held.
>> > > >>> The
>> > > >>> > restriction for transactions is quite fundamental, the lock()
>> issue
>> > > >>> can be
>> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
>> > > currently
>> > > >>> > works.
>> > > >>> >
>> > > >>> > As for the "Failed to find semaphore with the given name"
>> message,
>> > my
>> > > >>> first
>> > > >>> > guess is that DataStructures were configured with 1 backups
>> which
>> > led
>> > > >>> to
>> > > >>> > the data loss when two nodes were stopped. Mario, can you please
>> > > >>> re-test
>> > > >>> > your semaphore scenario with 2 backups configured for data
>> > > structures?
>> > > >>> > From my side, I can also take a look at the semaphore issue when
>> > I'm
>> > > >>> done
>> > > >>> > with IGNITE-2610.
>> > > >>> >
>> > > >>>
>> > > >>
>> > > >>
>> > > >
>> > >
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Yakov, I've seen your comments, can you please check the jira again?
On Wed, Mar 23, 2016 at 4:46 PM, Yakov Zhdanov <yz...@apache.org> wrote:
> Vlad, can you please check my comments again?
>
> --Yakov
>
> 2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>
> > Hi Yakov,
> >
> > yes, thanks for the comments, I think everything should be ok now,
> > please review the PR and tell me if you think anything else is needed.
> >
> > Once ignite-642 is merged into master,
> > I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> > release).
> >
> > Best regrads,
> > Vladisav
> >
> >
> >
> > On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
> > wrote:
> >
> > > Vlad, did you have a chance to review my latest comments?
> > >
> > > Thanks!
> > > --
> > > Yakov Zhdanov, Director R&D
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> > > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> > >
> > > > Vlad and all (esp Val and Anton V.),
> > > >
> > > > I reviewed the PR. My comments are in the ticket.
> > > >
> > > > Anton V. there is a question regarding
> optimized-classnames.properties.
> > > > Can you please respond in ticket?
> > > >
> > > >
> > > > --Yakov
> > > >
> > > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > > >
> > > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> > to
> > > >> myself.
> > > >>
> > > >> --Yakov
> > > >>
> > > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com
> >:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > > >>> i made a pull request, so hopefully this could be added to the next
> > > >>> release.
> > > >>>
> > > >>> Best regards,
> > > >>> Vladisav
> > > >>>
> > > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > > >>> alexey.goncharuk@gmail.com> wrote:
> > > >>>
> > > >>> > Folks,
> > > >>> >
> > > >>> > The current implementation of IgniteCache.lock(key).lock() has
> the
> > > same
> > > >>> > semantics as the transactional locks - cache topology cannot be
> > > changed
> > > >>> > while there exists an ongoing transaction or an explicit lock is
> > > held.
> > > >>> The
> > > >>> > restriction for transactions is quite fundamental, the lock()
> issue
> > > >>> can be
> > > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > > currently
> > > >>> > works.
> > > >>> >
> > > >>> > As for the "Failed to find semaphore with the given name"
> message,
> > my
> > > >>> first
> > > >>> > guess is that DataStructures were configured with 1 backups which
> > led
> > > >>> to
> > > >>> > the data loss when two nodes were stopped. Mario, can you please
> > > >>> re-test
> > > >>> > your semaphore scenario with 2 backups configured for data
> > > structures?
> > > >>> > From my side, I can also take a look at the semaphore issue when
> > I'm
> > > >>> done
> > > >>> > with IGNITE-2610.
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, can you please check my comments again?
--Yakov
2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Hi Yakov,
>
> yes, thanks for the comments, I think everything should be ok now,
> please review the PR and tell me if you think anything else is needed.
>
> Once ignite-642 is merged into master,
> I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> release).
>
> Best regrads,
> Vladisav
>
>
>
> On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > Vlad, did you have a chance to review my latest comments?
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >
> > > Vlad and all (esp Val and Anton V.),
> > >
> > > I reviewed the PR. My comments are in the ticket.
> > >
> > > Anton V. there is a question regarding optimized-classnames.properties.
> > > Can you please respond in ticket?
> > >
> > >
> > > --Yakov
> > >
> > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >
> > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> > >> myself.
> > >>
> > >> --Yakov
> > >>
> > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> > >>
> > >>> Hi,
> > >>>
> > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>> i made a pull request, so hopefully this could be added to the next
> > >>> release.
> > >>>
> > >>> Best regards,
> > >>> Vladisav
> > >>>
> > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>> alexey.goncharuk@gmail.com> wrote:
> > >>>
> > >>> > Folks,
> > >>> >
> > >>> > The current implementation of IgniteCache.lock(key).lock() has the
> > same
> > >>> > semantics as the transactional locks - cache topology cannot be
> > changed
> > >>> > while there exists an ongoing transaction or an explicit lock is
> > held.
> > >>> The
> > >>> > restriction for transactions is quite fundamental, the lock() issue
> > >>> can be
> > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > currently
> > >>> > works.
> > >>> >
> > >>> > As for the "Failed to find semaphore with the given name" message,
> my
> > >>> first
> > >>> > guess is that DataStructures were configured with 1 backups which
> led
> > >>> to
> > >>> > the data loss when two nodes were stopped. Mario, can you please
> > >>> re-test
> > >>> > your semaphore scenario with 2 backups configured for data
> > structures?
> > >>> > From my side, I can also take a look at the semaphore issue when
> I'm
> > >>> done
> > >>> > with IGNITE-2610.
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@gridgain.com>.
On Fri, Mar 18, 2016 at 7:57 AM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Hi Yakov,
>
> yes, thanks for the comments, I think everything should be ok now,
> please review the PR and tell me if you think anything else is needed.
>
> Once ignite-642 is merged into master,
> I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> release).
>
This would be awesome :)
>
> Best regrads,
> Vladisav
>
>
>
> On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > Vlad, did you have a chance to review my latest comments?
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >
> > > Vlad and all (esp Val and Anton V.),
> > >
> > > I reviewed the PR. My comments are in the ticket.
> > >
> > > Anton V. there is a question regarding optimized-classnames.properties.
> > > Can you please respond in ticket?
> > >
> > >
> > > --Yakov
> > >
> > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >
> > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> > >> myself.
> > >>
> > >> --Yakov
> > >>
> > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> > >>
> > >>> Hi,
> > >>>
> > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>> i made a pull request, so hopefully this could be added to the next
> > >>> release.
> > >>>
> > >>> Best regards,
> > >>> Vladisav
> > >>>
> > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>> alexey.goncharuk@gmail.com> wrote:
> > >>>
> > >>> > Folks,
> > >>> >
> > >>> > The current implementation of IgniteCache.lock(key).lock() has the
> > same
> > >>> > semantics as the transactional locks - cache topology cannot be
> > changed
> > >>> > while there exists an ongoing transaction or an explicit lock is
> > held.
> > >>> The
> > >>> > restriction for transactions is quite fundamental, the lock() issue
> > >>> can be
> > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > currently
> > >>> > works.
> > >>> >
> > >>> > As for the "Failed to find semaphore with the given name" message,
> my
> > >>> first
> > >>> > guess is that DataStructures were configured with 1 backups which
> led
> > >>> to
> > >>> > the data loss when two nodes were stopped. Mario, can you please
> > >>> re-test
> > >>> > your semaphore scenario with 2 backups configured for data
> > structures?
> > >>> > From my side, I can also take a look at the semaphore issue when
> I'm
> > >>> done
> > >>> > with IGNITE-2610.
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Dmitriy Setrakyan <ds...@gridgain.com>.
On Fri, Mar 18, 2016 at 7:57 AM, Vladisav Jelisavcic <vl...@gmail.com>
wrote:
> Hi Yakov,
>
> yes, thanks for the comments, I think everything should be ok now,
> please review the PR and tell me if you think anything else is needed.
>
> Once ignite-642 is merged into master,
> I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> release).
>
This would be awesome :)
>
> Best regrads,
> Vladisav
>
>
>
> On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > Vlad, did you have a chance to review my latest comments?
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >
> > > Vlad and all (esp Val and Anton V.),
> > >
> > > I reviewed the PR. My comments are in the ticket.
> > >
> > > Anton V. there is a question regarding optimized-classnames.properties.
> > > Can you please respond in ticket?
> > >
> > >
> > > --Yakov
> > >
> > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >
> > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> > >> myself.
> > >>
> > >> --Yakov
> > >>
> > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> > >>
> > >>> Hi,
> > >>>
> > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>> i made a pull request, so hopefully this could be added to the next
> > >>> release.
> > >>>
> > >>> Best regards,
> > >>> Vladisav
> > >>>
> > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>> alexey.goncharuk@gmail.com> wrote:
> > >>>
> > >>> > Folks,
> > >>> >
> > >>> > The current implementation of IgniteCache.lock(key).lock() has the
> > same
> > >>> > semantics as the transactional locks - cache topology cannot be
> > changed
> > >>> > while there exists an ongoing transaction or an explicit lock is
> > held.
> > >>> The
> > >>> > restriction for transactions is quite fundamental, the lock() issue
> > >>> can be
> > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > currently
> > >>> > works.
> > >>> >
> > >>> > As for the "Failed to find semaphore with the given name" message,
> my
> > >>> first
> > >>> > guess is that DataStructures were configured with 1 backups which
> led
> > >>> to
> > >>> > the data loss when two nodes were stopped. Mario, can you please
> > >>> re-test
> > >>> > your semaphore scenario with 2 backups configured for data
> > structures?
> > >>> > From my side, I can also take a look at the semaphore issue when
> I'm
> > >>> done
> > >>> > with IGNITE-2610.
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, can you please check my comments again?
--Yakov
2016-03-18 17:57 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Hi Yakov,
>
> yes, thanks for the comments, I think everything should be ok now,
> please review the PR and tell me if you think anything else is needed.
>
> Once ignite-642 is merged into master,
> I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
> release).
>
> Best regrads,
> Vladisav
>
>
>
> On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
> wrote:
>
> > Vlad, did you have a chance to review my latest comments?
> >
> > Thanks!
> > --
> > Yakov Zhdanov, Director R&D
> > *GridGain Systems*
> > www.gridgain.com
> >
> > 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> >
> > > Vlad and all (esp Val and Anton V.),
> > >
> > > I reviewed the PR. My comments are in the ticket.
> > >
> > > Anton V. there is a question regarding optimized-classnames.properties.
> > > Can you please respond in ticket?
> > >
> > >
> > > --Yakov
> > >
> > > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> > >
> > >> Vlad, that's great! I will take a look this week. Reassigning ticket
> to
> > >> myself.
> > >>
> > >> --Yakov
> > >>
> > >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> > >>
> > >>> Hi,
> > >>>
> > >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> > >>> i made a pull request, so hopefully this could be added to the next
> > >>> release.
> > >>>
> > >>> Best regards,
> > >>> Vladisav
> > >>>
> > >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> > >>> alexey.goncharuk@gmail.com> wrote:
> > >>>
> > >>> > Folks,
> > >>> >
> > >>> > The current implementation of IgniteCache.lock(key).lock() has the
> > same
> > >>> > semantics as the transactional locks - cache topology cannot be
> > changed
> > >>> > while there exists an ongoing transaction or an explicit lock is
> > held.
> > >>> The
> > >>> > restriction for transactions is quite fundamental, the lock() issue
> > >>> can be
> > >>> > fixed if we re-implement locking the same way IgniteSemaphore
> > currently
> > >>> > works.
> > >>> >
> > >>> > As for the "Failed to find semaphore with the given name" message,
> my
> > >>> first
> > >>> > guess is that DataStructures were configured with 1 backups which
> led
> > >>> to
> > >>> > the data loss when two nodes were stopped. Mario, can you please
> > >>> re-test
> > >>> > your semaphore scenario with 2 backups configured for data
> > structures?
> > >>> > From my side, I can also take a look at the semaphore issue when
> I'm
> > >>> done
> > >>> > with IGNITE-2610.
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Hi Yakov,
yes, thanks for the comments, I think everything should be ok now,
please review the PR and tell me if you think anything else is needed.
Once ignite-642 is merged into master,
I'll submit a PR for IgniteReadWriteLock (hopefully on time for 1.6.
release).
Best regrads,
Vladisav
On Fri, Mar 18, 2016 at 11:56 AM, Yakov Zhdanov <yz...@gridgain.com>
wrote:
> Vlad, did you have a chance to review my latest comments?
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
>
> > Vlad and all (esp Val and Anton V.),
> >
> > I reviewed the PR. My comments are in the ticket.
> >
> > Anton V. there is a question regarding optimized-classnames.properties.
> > Can you please respond in ticket?
> >
> >
> > --Yakov
> >
> > 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> >
> >> Vlad, that's great! I will take a look this week. Reassigning ticket to
> >> myself.
> >>
> >> --Yakov
> >>
> >> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> >>
> >>> Hi,
> >>>
> >>> i recently implemented distributed ReentrantLock - IGNITE-642,
> >>> i made a pull request, so hopefully this could be added to the next
> >>> release.
> >>>
> >>> Best regards,
> >>> Vladisav
> >>>
> >>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> >>> alexey.goncharuk@gmail.com> wrote:
> >>>
> >>> > Folks,
> >>> >
> >>> > The current implementation of IgniteCache.lock(key).lock() has the
> same
> >>> > semantics as the transactional locks - cache topology cannot be
> changed
> >>> > while there exists an ongoing transaction or an explicit lock is
> held.
> >>> The
> >>> > restriction for transactions is quite fundamental, the lock() issue
> >>> can be
> >>> > fixed if we re-implement locking the same way IgniteSemaphore
> currently
> >>> > works.
> >>> >
> >>> > As for the "Failed to find semaphore with the given name" message, my
> >>> first
> >>> > guess is that DataStructures were configured with 1 backups which led
> >>> to
> >>> > the data loss when two nodes were stopped. Mario, can you please
> >>> re-test
> >>> > your semaphore scenario with 2 backups configured for data
> structures?
> >>> > From my side, I can also take a look at the semaphore issue when I'm
> >>> done
> >>> > with IGNITE-2610.
> >>> >
> >>>
> >>
> >>
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@gridgain.com>.
Vlad, did you have a chance to review my latest comments?
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad and all (esp Val and Anton V.),
>
> I reviewed the PR. My comments are in the ticket.
>
> Anton V. there is a question regarding optimized-classnames.properties.
> Can you please respond in ticket?
>
>
> --Yakov
>
> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>
>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>> myself.
>>
>> --Yakov
>>
>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>>> Hi,
>>>
>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>> i made a pull request, so hopefully this could be added to the next
>>> release.
>>>
>>> Best regards,
>>> Vladisav
>>>
>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>> alexey.goncharuk@gmail.com> wrote:
>>>
>>> > Folks,
>>> >
>>> > The current implementation of IgniteCache.lock(key).lock() has the same
>>> > semantics as the transactional locks - cache topology cannot be changed
>>> > while there exists an ongoing transaction or an explicit lock is held.
>>> The
>>> > restriction for transactions is quite fundamental, the lock() issue
>>> can be
>>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>>> > works.
>>> >
>>> > As for the "Failed to find semaphore with the given name" message, my
>>> first
>>> > guess is that DataStructures were configured with 1 backups which led
>>> to
>>> > the data loss when two nodes were stopped. Mario, can you please
>>> re-test
>>> > your semaphore scenario with 2 backups configured for data structures?
>>> > From my side, I can also take a look at the semaphore issue when I'm
>>> done
>>> > with IGNITE-2610.
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@gridgain.com>.
Vlad, did you have a chance to review my latest comments?
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2016-03-06 12:21 GMT+03:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad and all (esp Val and Anton V.),
>
> I reviewed the PR. My comments are in the ticket.
>
> Anton V. there is a question regarding optimized-classnames.properties.
> Can you please respond in ticket?
>
>
> --Yakov
>
> 2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
>
>> Vlad, that's great! I will take a look this week. Reassigning ticket to
>> myself.
>>
>> --Yakov
>>
>> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>>
>>> Hi,
>>>
>>> i recently implemented distributed ReentrantLock - IGNITE-642,
>>> i made a pull request, so hopefully this could be added to the next
>>> release.
>>>
>>> Best regards,
>>> Vladisav
>>>
>>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>>> alexey.goncharuk@gmail.com> wrote:
>>>
>>> > Folks,
>>> >
>>> > The current implementation of IgniteCache.lock(key).lock() has the same
>>> > semantics as the transactional locks - cache topology cannot be changed
>>> > while there exists an ongoing transaction or an explicit lock is held.
>>> The
>>> > restriction for transactions is quite fundamental, the lock() issue
>>> can be
>>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>>> > works.
>>> >
>>> > As for the "Failed to find semaphore with the given name" message, my
>>> first
>>> > guess is that DataStructures were configured with 1 backups which led
>>> to
>>> > the data loss when two nodes were stopped. Mario, can you please
>>> re-test
>>> > your semaphore scenario with 2 backups configured for data structures?
>>> > From my side, I can also take a look at the semaphore issue when I'm
>>> done
>>> > with IGNITE-2610.
>>> >
>>>
>>
>>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad and all (esp Val and Anton V.),
I reviewed the PR. My comments are in the ticket.
Anton V. there is a question regarding optimized-classnames.properties. Can
you please respond in ticket?
--Yakov
2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad, that's great! I will take a look this week. Reassigning ticket to
> myself.
>
> --Yakov
>
> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>
>> Hi,
>>
>> i recently implemented distributed ReentrantLock - IGNITE-642,
>> i made a pull request, so hopefully this could be added to the next
>> release.
>>
>> Best regards,
>> Vladisav
>>
>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>> alexey.goncharuk@gmail.com> wrote:
>>
>> > Folks,
>> >
>> > The current implementation of IgniteCache.lock(key).lock() has the same
>> > semantics as the transactional locks - cache topology cannot be changed
>> > while there exists an ongoing transaction or an explicit lock is held.
>> The
>> > restriction for transactions is quite fundamental, the lock() issue can
>> be
>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>> > works.
>> >
>> > As for the "Failed to find semaphore with the given name" message, my
>> first
>> > guess is that DataStructures were configured with 1 backups which led to
>> > the data loss when two nodes were stopped. Mario, can you please re-test
>> > your semaphore scenario with 2 backups configured for data structures?
>> > From my side, I can also take a look at the semaphore issue when I'm
>> done
>> > with IGNITE-2610.
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad and all (esp Val and Anton V.),
I reviewed the PR. My comments are in the ticket.
Anton V. there is a question regarding optimized-classnames.properties. Can
you please respond in ticket?
--Yakov
2016-02-29 16:00 GMT+06:00 Yakov Zhdanov <yz...@apache.org>:
> Vlad, that's great! I will take a look this week. Reassigning ticket to
> myself.
>
> --Yakov
>
> 2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
>
>> Hi,
>>
>> i recently implemented distributed ReentrantLock - IGNITE-642,
>> i made a pull request, so hopefully this could be added to the next
>> release.
>>
>> Best regards,
>> Vladisav
>>
>> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
>> alexey.goncharuk@gmail.com> wrote:
>>
>> > Folks,
>> >
>> > The current implementation of IgniteCache.lock(key).lock() has the same
>> > semantics as the transactional locks - cache topology cannot be changed
>> > while there exists an ongoing transaction or an explicit lock is held.
>> The
>> > restriction for transactions is quite fundamental, the lock() issue can
>> be
>> > fixed if we re-implement locking the same way IgniteSemaphore currently
>> > works.
>> >
>> > As for the "Failed to find semaphore with the given name" message, my
>> first
>> > guess is that DataStructures were configured with 1 backups which led to
>> > the data loss when two nodes were stopped. Mario, can you please re-test
>> > your semaphore scenario with 2 backups configured for data structures?
>> > From my side, I can also take a look at the semaphore issue when I'm
>> done
>> > with IGNITE-2610.
>> >
>>
>
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, that's great! I will take a look this week. Reassigning ticket to
myself.
--Yakov
2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Hi,
>
> i recently implemented distributed ReentrantLock - IGNITE-642,
> i made a pull request, so hopefully this could be added to the next
> release.
>
> Best regards,
> Vladisav
>
> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Folks,
> >
> > The current implementation of IgniteCache.lock(key).lock() has the same
> > semantics as the transactional locks - cache topology cannot be changed
> > while there exists an ongoing transaction or an explicit lock is held.
> The
> > restriction for transactions is quite fundamental, the lock() issue can
> be
> > fixed if we re-implement locking the same way IgniteSemaphore currently
> > works.
> >
> > As for the "Failed to find semaphore with the given name" message, my
> first
> > guess is that DataStructures were configured with 1 backups which led to
> > the data loss when two nodes were stopped. Mario, can you please re-test
> > your semaphore scenario with 2 backups configured for data structures?
> > From my side, I can also take a look at the semaphore issue when I'm done
> > with IGNITE-2610.
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Yakov Zhdanov <yz...@apache.org>.
Vlad, that's great! I will take a look this week. Reassigning ticket to
myself.
--Yakov
2016-02-26 18:37 GMT+03:00 Vladisav Jelisavcic <vl...@gmail.com>:
> Hi,
>
> i recently implemented distributed ReentrantLock - IGNITE-642,
> i made a pull request, so hopefully this could be added to the next
> release.
>
> Best regards,
> Vladisav
>
> On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Folks,
> >
> > The current implementation of IgniteCache.lock(key).lock() has the same
> > semantics as the transactional locks - cache topology cannot be changed
> > while there exists an ongoing transaction or an explicit lock is held.
> The
> > restriction for transactions is quite fundamental, the lock() issue can
> be
> > fixed if we re-implement locking the same way IgniteSemaphore currently
> > works.
> >
> > As for the "Failed to find semaphore with the given name" message, my
> first
> > guess is that DataStructures were configured with 1 backups which led to
> > the data loss when two nodes were stopped. Mario, can you please re-test
> > your semaphore scenario with 2 backups configured for data structures?
> > From my side, I can also take a look at the semaphore issue when I'm done
> > with IGNITE-2610.
> >
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Vladisav Jelisavcic <vl...@gmail.com>.
Hi,
i recently implemented distributed ReentrantLock - IGNITE-642,
i made a pull request, so hopefully this could be added to the next release.
Best regards,
Vladisav
On Thu, Feb 18, 2016 at 10:49 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:
> Folks,
>
> The current implementation of IgniteCache.lock(key).lock() has the same
> semantics as the transactional locks - cache topology cannot be changed
> while there exists an ongoing transaction or an explicit lock is held. The
> restriction for transactions is quite fundamental, the lock() issue can be
> fixed if we re-implement locking the same way IgniteSemaphore currently
> works.
>
> As for the "Failed to find semaphore with the given name" message, my first
> guess is that DataStructures were configured with 1 backups which led to
> the data loss when two nodes were stopped. Mario, can you please re-test
> your semaphore scenario with 2 backups configured for data structures?
> From my side, I can also take a look at the semaphore issue when I'm done
> with IGNITE-2610.
>
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Alexey Goncharuk <al...@gmail.com>.
Folks,
The current implementation of IgniteCache.lock(key).lock() has the same
semantics as the transactional locks - cache topology cannot be changed
while there exists an ongoing transaction or an explicit lock is held. The
restriction for transactions is quite fundamental, the lock() issue can be
fixed if we re-implement locking the same way IgniteSemaphore currently
works.
As for the "Failed to find semaphore with the given name" message, my first
guess is that DataStructures were configured with 1 backups which led to
the data loss when two nodes were stopped. Mario, can you please re-test
your semaphore scenario with 2 backups configured for data structures?
>From my side, I can also take a look at the semaphore issue when I'm done
with IGNITE-2610.
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by Alexey Goncharuk <al...@gmail.com>.
Folks,
The current implementation of IgniteCache.lock(key).lock() has the same
semantics as the transactional locks - cache topology cannot be changed
while there exists an ongoing transaction or an explicit lock is held. The
restriction for transactions is quite fundamental, the lock() issue can be
fixed if we re-implement locking the same way IgniteSemaphore currently
works.
As for the "Failed to find semaphore with the given name" message, my first
guess is that DataStructures were configured with 1 backups which led to
the data loss when two nodes were stopped. Mario, can you please re-test
your semaphore scenario with 2 backups configured for data structures?
>From my side, I can also take a look at the semaphore issue when I'm done
with IGNITE-2610.
Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Posted by nyname00 <ma...@panagenda.com>.
Vladimir,
thanks for your efforts. Do you see any way around this problem? It feels
like I'm running out of options (see below).
I'm not sure this is related, but I tried to replace the cache lock with a
semaphore but things get even weirder.
To reproduce
(1) start a new node (see code below) and wait for the "acquired" message
(2) start another node and wait until it joins the cluster
(3) kill the node created in (1) - the node created in (2) will take over
and print "acquired"
(4) start yet another node and wait until it joins the cluster
(5) kill the node created in (3) - when this node is trying to acquire the
semaphore the following ex is thrown:
SEVERE: <ignite-atomics-sys-cache> Failed to compare and set:
o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$2@b7b3649
class org.apache.ignite.IgniteCheckedException: Failed to find semaphore
with given name: sem1
at
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync$2.call(GridCacheSemaphoreImpl.java:333)
at
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync$2.call(GridCacheSemaphoreImpl.java:323)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils$24.call(GridCacheUtils.java:1776)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.outTx(GridCacheUtils.java:982)
at
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync.releaseFailedNode(GridCacheSemaphoreImpl.java:322)
at
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.onNodeRemoved(GridCacheSemaphoreImpl.java:504)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$1$1.call(DataStructuresProcessor.java:191)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6397)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:929)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
There seems to be no way to retry acquiring the semaphore - Ignite just
hangs ...
Note that, in a more complex test scenario I can reproduce this behavior
with just two nodes.
Regards,
Mario
public static void main(String[] args) {
try {
Ignite ignite = Ignition.start(new
IgniteConfiguration().setGridName("1"));
System.out.println("started");
IgniteSemaphore sem = ignite.semaphore("sem1", 1, true, true);
System.out.println("created");
sem.acquire();
System.out.println("acquired");
} catch (Exception e) {
System.out.println("oh no");
}
}
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Semaphore-blocking-on-tryAcquire-while-holding-a-cache-lock-tp3031p3061.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.