Re: IgniteConfiguration.gridName is very confusing

2016-12-31 Thread Alexander Fedotov
Okay. From the all said above I suppose "instanceName" should work for IgniteConfiguration and "igniteInstanceName" in all other places. Regards, Alexander 31 дек. 2016 г. 3:43 AM пользователь "Dmitriy Setrakyan" < dsetrak...@apache.org> написал: It sounds like it must be unique then. I would pr

Re: PageMemory approach for Ignite 2.0

2016-12-31 Thread Vladimir Ozerov
So are you, guys, suggesting to accept page-memory as the right one by default, which: 1) Doesn't work with half of current cache features 2) Halved our performance 3) Goes against the whole Java ecosystem with it's "offheap-first" approach? Good try, but no :-) Let me clarify on p.3. Offheap-fir

Re: PageMemory approach for Ignite 2.0

2016-12-31 Thread Dmitriy Setrakyan
On Sat, Dec 31, 2016 at 7:07 AM, Vladimir Ozerov wrote: So my main concern is *what about current heap mode*? It must stay alive. > Page-memory approach should be abstracted out and implemented in addition > to current heap-approach, not instead of it. Have high-end machine and > suffer from GC?

Re: PageMemory approach for Ignite 2.0

2016-12-31 Thread Denis Magda
Here we need to define what’s meant under *fast enough*. Java is unmanageable in terms of memory and it’s unlikely that any custom memory manageable solution like the PageMemory will outperform it ever. Simply because the Java heap will still be an intermediate layer between an application and t

Re: PageMemory approach for Ignite 2.0

2016-12-31 Thread Denis Magda
Sorry, just recalled that Unsafe is not JNI based. However, my previous point of view still remains the same. > On Dec 31, 2016, at 11:39 PM, Denis Magda wrote: > > JNI-based Unsafe that also brings performance hit — Denis