ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Semaphore blocking on tryAcquire() while holding a cache-lock
Date Sun, 06 Mar 2016 09:21:05 GMT
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>:

> 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.
>> >
>>
>
>

Mime
View raw message