Re: contention on DataStructure creation/removing

Hi all, Yakov pointed me that I didn't remove Reenrtrant Lock after it use. Data Structures' are stored in HashMap, so serialization and deserialization time depends on HashMap size and becomes very expensive without removing unused data structures. I added removing for unused Reenrtrant Locks

Re: contention on DataStructure creation/removing

https://github.com/apache/ignite/pull/2053/files I'm checking TC, now, I'll send it for review as soon as pull request passes TC. On Fri, Jun 2, 2017 at 6:41 PM, Dmitriy Setrakyan wrote: > Wow, what was patched? Can you provide the code sample being benchmarked? > > On

Re: contention on DataStructure creation/removing

Wow, what was patched? Can you provide the code sample being benchmarked? On Fri, Jun 2, 2017 at 8:00 AM, Mikhail Cherkasov wrote: > Looks like dev list doesn't allow to include pictures in emails, so there > are links to plots: > > Throughput plot without any changes:

Re: contention on DataStructure creation/removing

Looks like dev list doesn't allow to include pictures in emails, so there are links to plots: Throughput plot without any changes: https://www.dropbox.com/s/mc3v5m49u4i2be3/no-changes.png?dl=0 the same plot with patched ignite: https://www.dropbox.com/s/cyojw9nz4smew87/with-chages.png?dl=0

Re: contention on DataStructure creation/removing

Hi all, I prepared a benchmark for ignite reentrant lock, the benchmark updates cache values under the reentrant lock. The benchmark is based on s real case, when user can't use regular cache locks, because they prevent partition map exchange and as result don't allow new nodes join cluster.

Re: contention on DataStructure creation/removing

Alexey, I think, that from user's perspective data structures look more like a library that works on top of caches, not something completely separate and independent. Most properties from CacheConfiguration make sense for Atomics and Collections (for example, properties related to rebalancing).

Re: contention on DataStructure creation/removing

This is how I see API to create data structures in user-defined caches: https://github.com/apache/ignite/pull/2058 On Thu, Jun 1, 2017 at 2:56 PM, Ilya Lantukh wrote: > Hi all, > > There are other problems with current data structures implementation, > which are related

Re: contention on DataStructure creation/removing

Hi all, There are other problems with current data structures implementation, which are related to new persistence mechanics. For example, take a look at this ticket: https://issues.apache.org/jira/browse/IGNITE-5324 I think the best approach is to store data structures not in special system

Re: contention on DataStructure creation/removing

On Thu, Jun 1, 2017 at 1:29 AM, Dmitriy Setrakyan wrote: > Won't it be confusing from a user stand point to have multiple data > structures with the same name? > I won't change this, optionally I can allow to have the same name for different data structures' types, but

Re: contention on DataStructure creation/removing

Won't it be confusing from a user stand point to have multiple data structures with the same name? Also, what is the performance impact of this change? D. On Wed, May 31, 2017 at 8:23 AM, Semyon Boikov wrote: > Hi Mikhail, > > As far as I remember for some reason we

Re: contention on DataStructure creation/removing

Hi Mikhail, As far as I remember for some reason we wanted to guarantee that all data structures have unique names. But now I don't see why this can be needed and it seems we do not need this data structures map at all, if nobody have objection I think you can implement suggested change. Thanks!

Re: contention on DataStructure creation/removing

Mikhail, Seems, This can solve "slow reentrantLock" issue, at least at creation stage. On Wed, May 31, 2017 at 3:04 PM, Mikhail Cherkasov wrote: > Hi all, > > All DataStructures are stored in one Map which itself is stored in > utilityCache, this makes high contention

contention on DataStructure creation/removing

Hi all, All DataStructures are stored in one Map which itself is stored in utilityCache, this makes high contention on DS creation or removing, it requires to acquire Map's lock and manipulation with the Map under the lock. So all threads in cluster should wait for this lock to create or remove