Re: Re[2]: NUMA aware allocator, PR review request

[Ivan Daschinsky]

You are not wrong, it is built from source, every night. And every TC run.
I don't understand why numa allocator cannot be treated the same. Moreover,
it is built using maven, with maven plugin and just needs gcc and
libnuma-dev. All of theese are already on TC agents and build are ready. I
didn't see any difficulties in building.

But I still don't understand how to organize Anton's proposal. It seems
that if we follow this way, we cannot release allocator in 2.13

пн, 6 дек. 2021 г., 23:18 Ilya Kasnacheev :

> Hello!
>
> Maybe I am wrong, but ODBC installer is built from source and may be
> improved from release to release.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 6 дек. 2021 г. в 20:41, Ivan Daschinsky :
>
> > Only one reason -- nowadays amost all hardware platforms uses NUMA
> >
> > Another reason -- there is no any release process of extensions.
> >
> >
> > BTW, apache ignite release is shipped with odbc binary installer for
> > windows. And nobody complains about it.
> >
> > But may be listen to others?
> >
> > пн, 6 дек. 2021 г., 19:49 Anton Vinogradov :
> >
> > > Any reason to release the same cpp sources for each release?
> > > Any reason to increase the requirements amount for each new release?
> > > Any reason to increase release complexity and duration?
> > > All answers are "definitely no"
> > >
> > > What we should do is to release cpp part once and use it as a
> dependency.
> > > Extensions are a good location.
> > >
> > > On Mon, Dec 6, 2021 at 3:11 PM Zhenya Stanilovsky
> > >  wrote:
> > >
> > > >
> > > >
> > > > +1 with Ivan, let`s store it in core product just because it looks
> > > > like inalienable functionality and release cycle of extensions a
> little
> > > bit
> > > > different.
> > > >
> > > >
> > > >
> > > > >Anton, I disagree.
> > > > >
> > > > >1. This should be released with main distro.
> > > > >2. This should not be abandoned.
> > > > >3. There is not any release process in ignite-extensions.
> > > > >4. Everything is working now and working good.
> > > > >
> > > > >
> > > > >So lets do not do this :)
> > > > >
> > > > >пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov < a...@apache.org >:
> > > > >
> > > > >> Let's move all GCC-related parts to ignite-extensions, release,
> and
> > > use
> > > > >> them as a maven dependency.
> > > > >>
> > > > >>
> > > > >> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky <
> > ivanda...@gmail.com
> > > >
> > > > >> wrote:
> > > > >>
> > > > >> > Ok, TC suite is ready [1].
> > > > >> > If there is no objections, I will merge it soon.
> > > > >> >
> > > > >> > Possible concerns -- now it is required to install
> > build-essentials
> > > > and
> > > > >> > libnuma-dev in order to build ignite on 64 bit linux.
> > > > >> > I suppose that this is not a big deal, but maybe someone will
> > > > contradict?
> > > > >> >
> > > > >> >
> > > > >> > [1] --
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
> > > > >> >
> > > > >> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky <
> ivanda...@gmail.com
> > > >:
> > > > >> >
> > > > >> > > >> Our runs show about 7-10 speedup,
> > > > >> > > Sorry, typo 7-10% speedup
> > > > >> > >
> > > > >> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky <
> > ivanda...@gmail.com
> > > > >:
> > > > >> > >
> > > > >> > >> Andrey, thanks!
> > > > >> > >>
> > > > >> > >> This allocator can be tested on every NUMA system.
> > > > >> > >> Our runs show about 7-10 speedup, if we use allocattor with
> > > > >> interleaved
> > > > >> > >> strategy + -XX:+UseNUMA.
> > > > >> > >> But unfortunately our yardstick benches doesn't use offheap a
> > > lot,
> > > > >> > >> usually above one Gb.
> > > > >> > >> We trying to do more benches with real data and share them,
> > > > possibly
> > > > >> in
> > > > >> > >> meetup.
> > > > >> > >>
> > > > >> > >> AFAIK, GG lab servers are two-sockets machines, aren't they?
> So
> > > it
> > > > is
> > > > >> > >> worth to run benches with a lot data on them, using
> > > > >> > >> allocator with interleaved strategy (you can skip specifying
> > numa
> > > > >> nodes,
> > > > >> > >> by default it will use all available) and use -XX:+UseNUMA
> jvm
> > > > >> > >> flag.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> > > > >> >  andrey.mashen...@gmail.com
> > > > >> > >> >:
> > > > >> > >>
> > > > >> > >>> Ivan,
> > > > >> > >>>
> > > > >> > >>> Great job. PR looks good.
> > > > >> > >>>
> > > > >> > >>> This allocator in interleaved mode and passing
> `-XX:+UseNUMA`
> > > > flag to
> > > > >> > jvm
> > > > >> > >>> > show promising results on yardstick benches. Technically,
> G1
> > > is
> > > > >> not a
> > > > >> > >>> numa
> > > > >> > >>> > aware collector for java versions less than 14, but
> > allocation
> > > > of
> > > > >> > heap
> > > > >> > >>> in
> > > > >> > >>> > interleaved mode shows good results even on java 11.
> > > 

Re: Re[2]: NUMA aware allocator, PR review request

[Ilya Kasnacheev]

Hello!

Maybe I am wrong, but ODBC installer is built from source and may be
improved from release to release.

Regards,
-- 
Ilya Kasnacheev


пн, 6 дек. 2021 г. в 20:41, Ivan Daschinsky :

> Only one reason -- nowadays amost all hardware platforms uses NUMA
>
> Another reason -- there is no any release process of extensions.
>
>
> BTW, apache ignite release is shipped with odbc binary installer for
> windows. And nobody complains about it.
>
> But may be listen to others?
>
> пн, 6 дек. 2021 г., 19:49 Anton Vinogradov :
>
> > Any reason to release the same cpp sources for each release?
> > Any reason to increase the requirements amount for each new release?
> > Any reason to increase release complexity and duration?
> > All answers are "definitely no"
> >
> > What we should do is to release cpp part once and use it as a dependency.
> > Extensions are a good location.
> >
> > On Mon, Dec 6, 2021 at 3:11 PM Zhenya Stanilovsky
> >  wrote:
> >
> > >
> > >
> > > +1 with Ivan, let`s store it in core product just because it looks
> > > like inalienable functionality and release cycle of extensions a little
> > bit
> > > different.
> > >
> > >
> > >
> > > >Anton, I disagree.
> > > >
> > > >1. This should be released with main distro.
> > > >2. This should not be abandoned.
> > > >3. There is not any release process in ignite-extensions.
> > > >4. Everything is working now and working good.
> > > >
> > > >
> > > >So lets do not do this :)
> > > >
> > > >пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov < a...@apache.org >:
> > > >
> > > >> Let's move all GCC-related parts to ignite-extensions, release, and
> > use
> > > >> them as a maven dependency.
> > > >>
> > > >>
> > > >> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky <
> ivanda...@gmail.com
> > >
> > > >> wrote:
> > > >>
> > > >> > Ok, TC suite is ready [1].
> > > >> > If there is no objections, I will merge it soon.
> > > >> >
> > > >> > Possible concerns -- now it is required to install
> build-essentials
> > > and
> > > >> > libnuma-dev in order to build ignite on 64 bit linux.
> > > >> > I suppose that this is not a big deal, but maybe someone will
> > > contradict?
> > > >> >
> > > >> >
> > > >> > [1] --
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
> > > >> >
> > > >> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky < ivanda...@gmail.com
> > >:
> > > >> >
> > > >> > > >> Our runs show about 7-10 speedup,
> > > >> > > Sorry, typo 7-10% speedup
> > > >> > >
> > > >> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky <
> ivanda...@gmail.com
> > > >:
> > > >> > >
> > > >> > >> Andrey, thanks!
> > > >> > >>
> > > >> > >> This allocator can be tested on every NUMA system.
> > > >> > >> Our runs show about 7-10 speedup, if we use allocattor with
> > > >> interleaved
> > > >> > >> strategy + -XX:+UseNUMA.
> > > >> > >> But unfortunately our yardstick benches doesn't use offheap a
> > lot,
> > > >> > >> usually above one Gb.
> > > >> > >> We trying to do more benches with real data and share them,
> > > possibly
> > > >> in
> > > >> > >> meetup.
> > > >> > >>
> > > >> > >> AFAIK, GG lab servers are two-sockets machines, aren't they? So
> > it
> > > is
> > > >> > >> worth to run benches with a lot data on them, using
> > > >> > >> allocator with interleaved strategy (you can skip specifying
> numa
> > > >> nodes,
> > > >> > >> by default it will use all available) and use -XX:+UseNUMA jvm
> > > >> > >> flag.
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> > > >> >  andrey.mashen...@gmail.com
> > > >> > >> >:
> > > >> > >>
> > > >> > >>> Ivan,
> > > >> > >>>
> > > >> > >>> Great job. PR looks good.
> > > >> > >>>
> > > >> > >>> This allocator in interleaved mode and passing `-XX:+UseNUMA`
> > > flag to
> > > >> > jvm
> > > >> > >>> > show promising results on yardstick benches. Technically, G1
> > is
> > > >> not a
> > > >> > >>> numa
> > > >> > >>> > aware collector for java versions less than 14, but
> allocation
> > > of
> > > >> > heap
> > > >> > >>> in
> > > >> > >>> > interleaved mode shows good results even on java 11.
> > > >> > >>>
> > > >> > >>> Can you share benchmark results?
> > > >> > >>> I'm not sure I'll have an Optane on my notebook in a
> reasonable
> > > time
> > > >> ;)
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky <
> > > ivanda...@gmail.com
> > > >> >
> > > >> > >>> wrote:
> > > >> > >>>
> > > >> > >>> > Semyon D. and Maks T. -- thanks a lot for review.
> > > >> > >>> >
> > > >> > >>> > BTW, Igniters, I will appreciate all opinions and feedback.
> > > >> > >>> >
> > > >> > >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky <
> > > >>  ivanda...@apache.org
> > > >> > >:
> > > >> > >>> >
> > > >> > >>> > > Hi, igniters!
> > > >> > >>> > >
> > > >> > >>> > > There is not a big secret that nowadays NUMA is quite
> common
> > > in
> > > >> > >>> > > multiprocessor 

Re: Re[2]: NUMA aware allocator, PR review request

[Ivan Daschinsky]

Only one reason -- nowadays amost all hardware platforms uses NUMA

Another reason -- there is no any release process of extensions.


BTW, apache ignite release is shipped with odbc binary installer for
windows. And nobody complains about it.

But may be listen to others?

пн, 6 дек. 2021 г., 19:49 Anton Vinogradov :

> Any reason to release the same cpp sources for each release?
> Any reason to increase the requirements amount for each new release?
> Any reason to increase release complexity and duration?
> All answers are "definitely no"
>
> What we should do is to release cpp part once and use it as a dependency.
> Extensions are a good location.
>
> On Mon, Dec 6, 2021 at 3:11 PM Zhenya Stanilovsky
>  wrote:
>
> >
> >
> > +1 with Ivan, let`s store it in core product just because it looks
> > like inalienable functionality and release cycle of extensions a little
> bit
> > different.
> >
> >
> >
> > >Anton, I disagree.
> > >
> > >1. This should be released with main distro.
> > >2. This should not be abandoned.
> > >3. There is not any release process in ignite-extensions.
> > >4. Everything is working now and working good.
> > >
> > >
> > >So lets do not do this :)
> > >
> > >пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov < a...@apache.org >:
> > >
> > >> Let's move all GCC-related parts to ignite-extensions, release, and
> use
> > >> them as a maven dependency.
> > >>
> > >>
> > >> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky < ivanda...@gmail.com
> >
> > >> wrote:
> > >>
> > >> > Ok, TC suite is ready [1].
> > >> > If there is no objections, I will merge it soon.
> > >> >
> > >> > Possible concerns -- now it is required to install build-essentials
> > and
> > >> > libnuma-dev in order to build ignite on 64 bit linux.
> > >> > I suppose that this is not a big deal, but maybe someone will
> > contradict?
> > >> >
> > >> >
> > >> > [1] --
> > >> >
> > >> >
> > >>
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
> > >> >
> > >> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky < ivanda...@gmail.com
> >:
> > >> >
> > >> > > >> Our runs show about 7-10 speedup,
> > >> > > Sorry, typo 7-10% speedup
> > >> > >
> > >> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky < ivanda...@gmail.com
> > >:
> > >> > >
> > >> > >> Andrey, thanks!
> > >> > >>
> > >> > >> This allocator can be tested on every NUMA system.
> > >> > >> Our runs show about 7-10 speedup, if we use allocattor with
> > >> interleaved
> > >> > >> strategy + -XX:+UseNUMA.
> > >> > >> But unfortunately our yardstick benches doesn't use offheap a
> lot,
> > >> > >> usually above one Gb.
> > >> > >> We trying to do more benches with real data and share them,
> > possibly
> > >> in
> > >> > >> meetup.
> > >> > >>
> > >> > >> AFAIK, GG lab servers are two-sockets machines, aren't they? So
> it
> > is
> > >> > >> worth to run benches with a lot data on them, using
> > >> > >> allocator with interleaved strategy (you can skip specifying numa
> > >> nodes,
> > >> > >> by default it will use all available) and use -XX:+UseNUMA jvm
> > >> > >> flag.
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> > >> >  andrey.mashen...@gmail.com
> > >> > >> >:
> > >> > >>
> > >> > >>> Ivan,
> > >> > >>>
> > >> > >>> Great job. PR looks good.
> > >> > >>>
> > >> > >>> This allocator in interleaved mode and passing `-XX:+UseNUMA`
> > flag to
> > >> > jvm
> > >> > >>> > show promising results on yardstick benches. Technically, G1
> is
> > >> not a
> > >> > >>> numa
> > >> > >>> > aware collector for java versions less than 14, but allocation
> > of
> > >> > heap
> > >> > >>> in
> > >> > >>> > interleaved mode shows good results even on java 11.
> > >> > >>>
> > >> > >>> Can you share benchmark results?
> > >> > >>> I'm not sure I'll have an Optane on my notebook in a reasonable
> > time
> > >> ;)
> > >> > >>>
> > >> > >>>
> > >> > >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky <
> > ivanda...@gmail.com
> > >> >
> > >> > >>> wrote:
> > >> > >>>
> > >> > >>> > Semyon D. and Maks T. -- thanks a lot for review.
> > >> > >>> >
> > >> > >>> > BTW, Igniters, I will appreciate all opinions and feedback.
> > >> > >>> >
> > >> > >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky <
> > >>  ivanda...@apache.org
> > >> > >:
> > >> > >>> >
> > >> > >>> > > Hi, igniters!
> > >> > >>> > >
> > >> > >>> > > There is not a big secret that nowadays NUMA is quite common
> > in
> > >> > >>> > > multiprocessor systems.
> > >> > >>> > > And this memory architecture should be treated in specific
> > ways.
> > >> > >>> > >
> > >> > >>> > > Support for NUMA is present in many commercial and
> open-source
> > >> > >>> products.
> > >> > >>> > >
> > >> > >>> > > I've implemented a NUMA aware allocator for Apache Ignite
> [1]
> > >> > >>> > > It is a JNI wrapper around `libnuma` and supports different
> > >> > >>> allocation
> > >> > >>> > > options.
> > >> > >>> > > I.e. interleaved, local, 

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Maxim Muzafarov]

Val,

The plan should be more precise. So at the very high level:

1. Deprecate the system cache in 2.13.
2. Remove the system cache in 2.14.

2.14 should happen in the mid of the next year I suppose.

I don't think we should write guides for the system cache >
metastorage migration process. This is a completely internal API and
we can change it. Any plugin can create its own internal cache for any
needs and if there are any hooks required for it (e.g. like
PartitionsExchangeAware interface) it might be added prior to the
removal.


After we agreed on this plan we can send a notification for dev, user
lists about these changes, so all the plugin developers will be up to
date. But I think that everyone has already known everything, so let's
move on :-)

On Mon, 6 Dec 2021 at 20:22, Nikolay Izhikov  wrote:
>
> Valentin,
>
> > However, changes like system cache removal are much more critical, because 
> > a plugin might rely on it.
>
> I’m still don’t understand - what is the difference between system cache and 
> any other Ignite cache except the name?
> Do we have some special guarantees for system cache?
>
> > Any objections to the plan I've suggested earlier?
> > 1. Write down the differences between the system cache and the metastorage, 
> > and provide a transition guide for plugin developers.
>
> Don’t think we need any transition guide.
>
> > I don't think it's reasonable to do this earlier than mid next year
>
> This date are questionable, also.
>
> Other points of your plan makes sense.
> +1 to follow it.
>
> > 6 дек. 2021 г., в 20:16, Valentin Kulichenko 
> >  написал(а):
> >
> > That's correct.
> >
> > Folks, can we agree on how we want to approach the removal of the system
> > cache? Any objections to the plan I've suggested earlier? As a reminder,
> > here it is:
> > 1. Write down the differences between the system cache and the metastorage,
> > and provide a transition guide for plugin developers.
> > 2. Deprecate the system cache in 2.13.
> > 3. Remove the system cache in one of the further releases. I don't think
> > it's reasonable to do this earlier than mid next year (even that is
> > potentially too early).
> >
> > As for general compatibility requirements related to plugins, I think they
> > obviously should not be as strict as for the public API. It's
> > understandable that a method signature can be updated, or another similar
> > change can be made in internal APIs. However, changes like system cache
> > removal are much more critical, because a plugin might rely on it. It's our
> > responsibility as a good friendly community to provide a reasonable
> > alternative and a reasonable timeline for such a case.
> >
> > -Val
> >
> > On Mon, Dec 6, 2021 at 8:56 AM Вячеслав Коптилин 
> > wrote:
> >
> >> Hi,
> >>
> >>> Plugins have access to different internal Ignite components, such as
> >> security processor and others, and can extend the programmatic API of
> >> Ignite.
> >>
> >>> Where docs say that we, as a community, take responsibility to keep
> >> internals in the way plugin expect?
> >> Nikolay, it seems to me, that quoted text clearly states about that.
> >> Plugin has access to internal APIs and so it depends on it. If we want to
> >> be a friendly community then we should discuss such changes
> >> (removing/changing internal APIs) and provide a reasonable time in order to
> >> update such dependencies.
> >>
> >> I think no one in this topic is against removing sys-cache. The question
> >> is: is it suitable for the community to deprecate using system cache in
> >> 2.13 and removing it in 2.14 || 2.15?
> >> Am I missing something? Am I correct?
> >>
> >> Thanks,
> >> Slava.
> >>
> >>
> >> пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov :
> >>
> >>> Slava, I don’t get it.
> >>>
>  Plugins have access to different internal Ignite components, such as
> >>> security processor and others, and can extend the programmatic API of
> >>> Ignite.
> >>>
> >>> Where docs say that we, as a community, take responsibility to keep
> >>> internals in the way plugin expect?
> >>>
>  6 дек. 2021 г., в 14:48, Вячеслав Коптилин 
> >>> написал(а):
> 
>  Hello Nikolay,
> 
> >> plugin framework allows to implement internal components and use the
>  internal API.
> > Can you please, point out to documentation or place in Ignite code
> >> that
>  describe this behaviour?
> 
>  Looks like it states here
> >> https://ignite.apache.org/docs/latest/plugins
> 
> > The Ignite plugin system allows you to extend the core functionality
> >> of
> > Ignite. Plugins have access to different internal Ignite components,
> >>> such
> > as security processor and others, and can extend the programmatic API
> >> of
> > Ignite.
> 
> 
>  Thanks,
>  S.
> 
> 
>  сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :
> 
> > Valentin
> >
> >> plugin framework allows to implement internal components and use the
> > internal API.
> 

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Nikolay Izhikov]

Valentin,

> However, changes like system cache removal are much more critical, because a 
> plugin might rely on it. 

I’m still don’t understand - what is the difference between system cache and 
any other Ignite cache except the name?
Do we have some special guarantees for system cache?

> Any objections to the plan I've suggested earlier?
> 1. Write down the differences between the system cache and the metastorage, 
> and provide a transition guide for plugin developers.

Don’t think we need any transition guide.

> I don't think it's reasonable to do this earlier than mid next year

This date are questionable, also.

Other points of your plan makes sense.
+1 to follow it.

> 6 дек. 2021 г., в 20:16, Valentin Kulichenko  
> написал(а):
> 
> That's correct.
> 
> Folks, can we agree on how we want to approach the removal of the system
> cache? Any objections to the plan I've suggested earlier? As a reminder,
> here it is:
> 1. Write down the differences between the system cache and the metastorage,
> and provide a transition guide for plugin developers.
> 2. Deprecate the system cache in 2.13.
> 3. Remove the system cache in one of the further releases. I don't think
> it's reasonable to do this earlier than mid next year (even that is
> potentially too early).
> 
> As for general compatibility requirements related to plugins, I think they
> obviously should not be as strict as for the public API. It's
> understandable that a method signature can be updated, or another similar
> change can be made in internal APIs. However, changes like system cache
> removal are much more critical, because a plugin might rely on it. It's our
> responsibility as a good friendly community to provide a reasonable
> alternative and a reasonable timeline for such a case.
> 
> -Val
> 
> On Mon, Dec 6, 2021 at 8:56 AM Вячеслав Коптилин 
> wrote:
> 
>> Hi,
>> 
>>> Plugins have access to different internal Ignite components, such as
>> security processor and others, and can extend the programmatic API of
>> Ignite.
>> 
>>> Where docs say that we, as a community, take responsibility to keep
>> internals in the way plugin expect?
>> Nikolay, it seems to me, that quoted text clearly states about that.
>> Plugin has access to internal APIs and so it depends on it. If we want to
>> be a friendly community then we should discuss such changes
>> (removing/changing internal APIs) and provide a reasonable time in order to
>> update such dependencies.
>> 
>> I think no one in this topic is against removing sys-cache. The question
>> is: is it suitable for the community to deprecate using system cache in
>> 2.13 and removing it in 2.14 || 2.15?
>> Am I missing something? Am I correct?
>> 
>> Thanks,
>> Slava.
>> 
>> 
>> пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov :
>> 
>>> Slava, I don’t get it.
>>> 
 Plugins have access to different internal Ignite components, such as
>>> security processor and others, and can extend the programmatic API of
>>> Ignite.
>>> 
>>> Where docs say that we, as a community, take responsibility to keep
>>> internals in the way plugin expect?
>>> 
 6 дек. 2021 г., в 14:48, Вячеслав Коптилин 
>>> написал(а):
 
 Hello Nikolay,
 
>> plugin framework allows to implement internal components and use the
 internal API.
> Can you please, point out to documentation or place in Ignite code
>> that
 describe this behaviour?
 
 Looks like it states here
>> https://ignite.apache.org/docs/latest/plugins
 
> The Ignite plugin system allows you to extend the core functionality
>> of
> Ignite. Plugins have access to different internal Ignite components,
>>> such
> as security processor and others, and can extend the programmatic API
>> of
> Ignite.
 
 
 Thanks,
 S.
 
 
 сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :
 
> Valentin
> 
>> plugin framework allows to implement internal components and use the
> internal API.
> 
> Can you please, point out to documentation or place in Ignite code
>> that
> describe this behaviour?
> AFAIK plugin can only use public API, internal API can be changed any
>>> time
> we want.
> 
>> Folks, can anyone explain the rush?
> 
> No rush from my side.
> 
> Just want to understand your vision of integration points between
>> Ignite
> and plugins.
> 
>> Is there any specific reason for it?
> 
> Intention of IEP-80 is to improve Ignite codebase by removing
>> abandoned
> features.
> 
>> But the fact is that there are users that can depend on the system
>>> cache
> via the plugin framework.
> 
> Why this dependency can’t be changed to any regular cache?
> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s
>> it.
> 
> Do we have some special guarantees or logic besides system cache?
> 
> 
>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko <
> 

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Valentin Kulichenko]

That's correct.

Folks, can we agree on how we want to approach the removal of the system
cache? Any objections to the plan I've suggested earlier? As a reminder,
here it is:
1. Write down the differences between the system cache and the metastorage,
and provide a transition guide for plugin developers.
2. Deprecate the system cache in 2.13.
3. Remove the system cache in one of the further releases. I don't think
it's reasonable to do this earlier than mid next year (even that is
potentially too early).

As for general compatibility requirements related to plugins, I think they
obviously should not be as strict as for the public API. It's
understandable that a method signature can be updated, or another similar
change can be made in internal APIs. However, changes like system cache
removal are much more critical, because a plugin might rely on it. It's our
responsibility as a good friendly community to provide a reasonable
alternative and a reasonable timeline for such a case.

-Val

On Mon, Dec 6, 2021 at 8:56 AM Вячеслав Коптилин 
wrote:

> Hi,
>
> > Plugins have access to different internal Ignite components, such as
> security processor and others, and can extend the programmatic API of
> Ignite.
>
> > Where docs say that we, as a community, take responsibility to keep
> internals in the way plugin expect?
> Nikolay, it seems to me, that quoted text clearly states about that.
> Plugin has access to internal APIs and so it depends on it. If we want to
> be a friendly community then we should discuss such changes
> (removing/changing internal APIs) and provide a reasonable time in order to
> update such dependencies.
>
> I think no one in this topic is against removing sys-cache. The question
> is: is it suitable for the community to deprecate using system cache in
> 2.13 and removing it in 2.14 || 2.15?
> Am I missing something? Am I correct?
>
> Thanks,
> Slava.
>
>
> пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov :
>
> > Slava, I don’t get it.
> >
> > > Plugins have access to different internal Ignite components, such as
> > security processor and others, and can extend the programmatic API of
> > Ignite.
> >
> > Where docs say that we, as a community, take responsibility to keep
> > internals in the way plugin expect?
> >
> > > 6 дек. 2021 г., в 14:48, Вячеслав Коптилин 
> > написал(а):
> > >
> > > Hello Nikolay,
> > >
> > >>> plugin framework allows to implement internal components and use the
> > > internal API.
> > >> Can you please, point out to documentation or place in Ignite code
> that
> > > describe this behaviour?
> > >
> > > Looks like it states here
> https://ignite.apache.org/docs/latest/plugins
> > >
> > >> The Ignite plugin system allows you to extend the core functionality
> of
> > >> Ignite. Plugins have access to different internal Ignite components,
> > such
> > >> as security processor and others, and can extend the programmatic API
> of
> > >> Ignite.
> > >
> > >
> > > Thanks,
> > > S.
> > >
> > >
> > > сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :
> > >
> > >> Valentin
> > >>
> > >>> plugin framework allows to implement internal components and use the
> > >> internal API.
> > >>
> > >> Can you please, point out to documentation or place in Ignite code
> that
> > >> describe this behaviour?
> > >> AFAIK plugin can only use public API, internal API can be changed any
> > time
> > >> we want.
> > >>
> > >>> Folks, can anyone explain the rush?
> > >>
> > >> No rush from my side.
> > >>
> > >> Just want to understand your vision of integration points between
> Ignite
> > >> and plugins.
> > >>
> > >>> Is there any specific reason for it?
> > >>
> > >> Intention of IEP-80 is to improve Ignite codebase by removing
> abandoned
> > >> features.
> > >>
> > >>> But the fact is that there are users that can depend on the system
> > cache
> > >> via the plugin framework.
> > >>
> > >> Why this dependency can’t be changed to any regular cache?
> > >> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s
> it.
> > >>
> > >> Do we have some special guarantees or logic besides system cache?
> > >>
> > >>
> > >>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com> написал(а):
> > >>>
> > >>> Nikolay, that's right, plugin framework allows to implement internal
> > >>> components and use the internal API. There is a difference between a
> > >> plugin
> > >>> and an extension that uses only public API
> > >>>
> > >>> Folks, can anyone explain the rush? Is there any specific reason for
> > it?
> > >>>
> > >>> I think we all agree that this is a good change - system cache has to
> > >> go. I
> > >>> guess technically it's not even a breaking change, because system
> cache
> > >> is
> > >>> not a public API feature. But the fact is that there are users that
> can
> > >>> depend on the system cache via the plugin framework. Let's be
> > respectful
> > >> to
> > >>> those users, provide a reasonable documented alternative and give
> time.
> > >>>
> > >>> -Val

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Вячеслав Коптилин]

Hi,

> Plugins have access to different internal Ignite components, such as
security processor and others, and can extend the programmatic API of
Ignite.

> Where docs say that we, as a community, take responsibility to keep
internals in the way plugin expect?
Nikolay, it seems to me, that quoted text clearly states about that.
Plugin has access to internal APIs and so it depends on it. If we want to
be a friendly community then we should discuss such changes
(removing/changing internal APIs) and provide a reasonable time in order to
update such dependencies.

I think no one in this topic is against removing sys-cache. The question
is: is it suitable for the community to deprecate using system cache in
2.13 and removing it in 2.14 || 2.15?
Am I missing something? Am I correct?

Thanks,
Slava.


пн, 6 дек. 2021 г. в 15:00, Nikolay Izhikov :

> Slava, I don’t get it.
>
> > Plugins have access to different internal Ignite components, such as
> security processor and others, and can extend the programmatic API of
> Ignite.
>
> Where docs say that we, as a community, take responsibility to keep
> internals in the way plugin expect?
>
> > 6 дек. 2021 г., в 14:48, Вячеслав Коптилин 
> написал(а):
> >
> > Hello Nikolay,
> >
> >>> plugin framework allows to implement internal components and use the
> > internal API.
> >> Can you please, point out to documentation or place in Ignite code that
> > describe this behaviour?
> >
> > Looks like it states here https://ignite.apache.org/docs/latest/plugins
> >
> >> The Ignite plugin system allows you to extend the core functionality of
> >> Ignite. Plugins have access to different internal Ignite components,
> such
> >> as security processor and others, and can extend the programmatic API of
> >> Ignite.
> >
> >
> > Thanks,
> > S.
> >
> >
> > сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :
> >
> >> Valentin
> >>
> >>> plugin framework allows to implement internal components and use the
> >> internal API.
> >>
> >> Can you please, point out to documentation or place in Ignite code that
> >> describe this behaviour?
> >> AFAIK plugin can only use public API, internal API can be changed any
> time
> >> we want.
> >>
> >>> Folks, can anyone explain the rush?
> >>
> >> No rush from my side.
> >>
> >> Just want to understand your vision of integration points between Ignite
> >> and plugins.
> >>
> >>> Is there any specific reason for it?
> >>
> >> Intention of IEP-80 is to improve Ignite codebase by removing abandoned
> >> features.
> >>
> >>> But the fact is that there are users that can depend on the system
> cache
> >> via the plugin framework.
> >>
> >> Why this dependency can’t be changed to any regular cache?
> >> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s it.
> >>
> >> Do we have some special guarantees or logic besides system cache?
> >>
> >>
> >>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> написал(а):
> >>>
> >>> Nikolay, that's right, plugin framework allows to implement internal
> >>> components and use the internal API. There is a difference between a
> >> plugin
> >>> and an extension that uses only public API
> >>>
> >>> Folks, can anyone explain the rush? Is there any specific reason for
> it?
> >>>
> >>> I think we all agree that this is a good change - system cache has to
> >> go. I
> >>> guess technically it's not even a breaking change, because system cache
> >> is
> >>> not a public API feature. But the fact is that there are users that can
> >>> depend on the system cache via the plugin framework. Let's be
> respectful
> >> to
> >>> those users, provide a reasonable documented alternative and give time.
> >>>
> >>> -Val
> >>>
> >>> On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov 
> >> wrote:
> >>>
>  I don’t understand how it possible.
> 
>  Are you talking about plugin that uses some kind of internal API?
> 
> > 3 дек. 2021 г., в 18:50, Вячеслав Коптилин  >
>  написал(а):
> >
> > Hello Nikolay,
> >
> > If I am not mistaken, the method you mentioned, allows to create a
> >> "user"
> > cache that is available through public api for the user. This does
> not
> > cover the case when the plugin developer wants to hide such cache and
> > protect it form the end user (at least, via public api).
> >
> > Thanks,
> > S.
> >
> > пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov :
> >
> >> Vyacheslav, Val, can you please clarify - What is the issue if
>  third-party
> >> plugins will create «ignite-sys-cache» from the code?
> >>
> >> Like just replacing `Ignite#cache` with the
> `Ignite#getOrCreateCache`.
> >>
> >>> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин <
> slava.kopti...@gmail.com
> >>>
> >> написал(а):
> >>>
> >>> Hello Maxim,
> >>>
>  I don't understand why you are using *backwards compatibility* for
> >>> completely internal things.
>  Why you are thinking in terms of 

Re: Re[2]: NUMA aware allocator, PR review request

[Anton Vinogradov]

Any reason to release the same cpp sources for each release?
Any reason to increase the requirements amount for each new release?
Any reason to increase release complexity and duration?
All answers are "definitely no"

What we should do is to release cpp part once and use it as a dependency.
Extensions are a good location.

On Mon, Dec 6, 2021 at 3:11 PM Zhenya Stanilovsky
 wrote:

>
>
> +1 with Ivan, let`s store it in core product just because it looks
> like inalienable functionality and release cycle of extensions a little bit
> different.
>
>
>
> >Anton, I disagree.
> >
> >1. This should be released with main distro.
> >2. This should not be abandoned.
> >3. There is not any release process in ignite-extensions.
> >4. Everything is working now and working good.
> >
> >
> >So lets do not do this :)
> >
> >пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov < a...@apache.org >:
> >
> >> Let's move all GCC-related parts to ignite-extensions, release, and use
> >> them as a maven dependency.
> >>
> >>
> >> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky < ivanda...@gmail.com >
> >> wrote:
> >>
> >> > Ok, TC suite is ready [1].
> >> > If there is no objections, I will merge it soon.
> >> >
> >> > Possible concerns -- now it is required to install build-essentials
> and
> >> > libnuma-dev in order to build ignite on 64 bit linux.
> >> > I suppose that this is not a big deal, but maybe someone will
> contradict?
> >> >
> >> >
> >> > [1] --
> >> >
> >> >
> >>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
> >> >
> >> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky < ivanda...@gmail.com >:
> >> >
> >> > > >> Our runs show about 7-10 speedup,
> >> > > Sorry, typo 7-10% speedup
> >> > >
> >> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky < ivanda...@gmail.com
> >:
> >> > >
> >> > >> Andrey, thanks!
> >> > >>
> >> > >> This allocator can be tested on every NUMA system.
> >> > >> Our runs show about 7-10 speedup, if we use allocattor with
> >> interleaved
> >> > >> strategy + -XX:+UseNUMA.
> >> > >> But unfortunately our yardstick benches doesn't use offheap a lot,
> >> > >> usually above one Gb.
> >> > >> We trying to do more benches with real data and share them,
> possibly
> >> in
> >> > >> meetup.
> >> > >>
> >> > >> AFAIK, GG lab servers are two-sockets machines, aren't they? So it
> is
> >> > >> worth to run benches with a lot data on them, using
> >> > >> allocator with interleaved strategy (you can skip specifying numa
> >> nodes,
> >> > >> by default it will use all available) and use -XX:+UseNUMA jvm
> >> > >> flag.
> >> > >>
> >> > >>
> >> > >>
> >> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> >> >  andrey.mashen...@gmail.com
> >> > >> >:
> >> > >>
> >> > >>> Ivan,
> >> > >>>
> >> > >>> Great job. PR looks good.
> >> > >>>
> >> > >>> This allocator in interleaved mode and passing `-XX:+UseNUMA`
> flag to
> >> > jvm
> >> > >>> > show promising results on yardstick benches. Technically, G1 is
> >> not a
> >> > >>> numa
> >> > >>> > aware collector for java versions less than 14, but allocation
> of
> >> > heap
> >> > >>> in
> >> > >>> > interleaved mode shows good results even on java 11.
> >> > >>>
> >> > >>> Can you share benchmark results?
> >> > >>> I'm not sure I'll have an Optane on my notebook in a reasonable
> time
> >> ;)
> >> > >>>
> >> > >>>
> >> > >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky <
> ivanda...@gmail.com
> >> >
> >> > >>> wrote:
> >> > >>>
> >> > >>> > Semyon D. and Maks T. -- thanks a lot for review.
> >> > >>> >
> >> > >>> > BTW, Igniters, I will appreciate all opinions and feedback.
> >> > >>> >
> >> > >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky <
> >>  ivanda...@apache.org
> >> > >:
> >> > >>> >
> >> > >>> > > Hi, igniters!
> >> > >>> > >
> >> > >>> > > There is not a big secret that nowadays NUMA is quite common
> in
> >> > >>> > > multiprocessor systems.
> >> > >>> > > And this memory architecture should be treated in specific
> ways.
> >> > >>> > >
> >> > >>> > > Support for NUMA is present in many commercial and open-source
> >> > >>> products.
> >> > >>> > >
> >> > >>> > > I've implemented a NUMA aware allocator for Apache Ignite [1]
> >> > >>> > > It is a JNI wrapper around `libnuma` and supports different
> >> > >>> allocation
> >> > >>> > > options.
> >> > >>> > > I.e. interleaved, local, interleved_mask and so on. For more
> >> > >>> information,
> >> > >>> > > see
> >> > >>> > > [2], [3].
> >> > >>> > > This allocator in interleaved mode and passing `-XX:+UseNUMA`
> >> flag
> >> > >>> to jvm
> >> > >>> > > show promising results on yardstick benches. Technically, G1
> is
> >> > not a
> >> > >>> > numa
> >> > >>> > > aware collector for java versions less than 14, but
> allocation of
> >> > >>> heap in
> >> > >>> > > interleaved mode shows good results even on java 11.
> >> > >>> > >
> >> > >>> > > Currently, all needed libraries and tools for building this
> >> module
> >> > >>> are
> >> > >>> > > 

Query related to Apache Ignite

[TAMBE Medha]

Hello,

I am working on a requirement wherein I want to use Apache Ignite.

Queries-


1.  Whether Ignite Server Node is started in synchronous or asynchronous 
mode

2.  Sometimes warning org.apache.ignite.logger.java.JavaLogger.warning 
Possible too long JVM pause is coming.  Not able to understand it.

I have gone through documentation Distributed Database - Apache 
Ignite(r) . It is very helpful.

Could you please help me in resolving above queries.

Best Regards,

Medha TAMBE

Manager, Software Consulting 3DGS





Office: +91 20 6690 1213
medha.ta...@3ds.com

[3DS Logo]

3DS.COM/ENOVIA


3DPLM Global Services Priv Ltd | Sr. No. 154/6, Block-IT 9, 4th floor, Plot No 
2, Rajiv Gandhi Infotech Park, MIDC, Phase-I, Hinjewadi | 411057 Pune | India



This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Syst?mes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
at 3ds.compliance-priv...@3ds.com


For other languages, go to https://www.3ds.com/terms/email-disclaimer

Re[2]: NUMA aware allocator, PR review request

[Zhenya Stanilovsky]

+1 with Ivan, let`s store it in core product just because it looks like 
inalienable functionality and release cycle of extensions a little bit 
different.


 
>Anton, I disagree.
>
>1. This should be released with main distro.
>2. This should not be abandoned.
>3. There is not any release process in ignite-extensions.
>4. Everything is working now and working good.
>
>
>So lets do not do this :)
>
>пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov < a...@apache.org >:
> 
>> Let's move all GCC-related parts to ignite-extensions, release, and use
>> them as a maven dependency.
>>
>>
>> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky < ivanda...@gmail.com >
>> wrote:
>>
>> > Ok, TC suite is ready [1].
>> > If there is no objections, I will merge it soon.
>> >
>> > Possible concerns -- now it is required to install build-essentials and
>> > libnuma-dev in order to build ignite on 64 bit linux.
>> > I suppose that this is not a big deal, but maybe someone will contradict?
>> >
>> >
>> > [1] --
>> >
>> >
>>  
>> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
>> >
>> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky < ivanda...@gmail.com >:
>> >
>> > > >> Our runs show about 7-10 speedup,
>> > > Sorry, typo 7-10% speedup
>> > >
>> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky < ivanda...@gmail.com >:
>> > >
>> > >> Andrey, thanks!
>> > >>
>> > >> This allocator can be tested on every NUMA system.
>> > >> Our runs show about 7-10 speedup, if we use allocattor with
>> interleaved
>> > >> strategy + -XX:+UseNUMA.
>> > >> But unfortunately our yardstick benches doesn't use offheap a lot,
>> > >> usually above one Gb.
>> > >> We trying to do more benches with real data and share them, possibly
>> in
>> > >> meetup.
>> > >>
>> > >> AFAIK, GG lab servers are two-sockets machines, aren't they? So it is
>> > >> worth to run benches with a lot data on them, using
>> > >> allocator with interleaved strategy (you can skip specifying numa
>> nodes,
>> > >> by default it will use all available) and use -XX:+UseNUMA jvm
>> > >> flag.
>> > >>
>> > >>
>> > >>
>> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
>> >  andrey.mashen...@gmail.com
>> > >> >:
>> > >>
>> > >>> Ivan,
>> > >>>
>> > >>> Great job. PR looks good.
>> > >>>
>> > >>> This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to
>> > jvm
>> > >>> > show promising results on yardstick benches. Technically, G1 is
>> not a
>> > >>> numa
>> > >>> > aware collector for java versions less than 14, but allocation of
>> > heap
>> > >>> in
>> > >>> > interleaved mode shows good results even on java 11.
>> > >>>
>> > >>> Can you share benchmark results?
>> > >>> I'm not sure I'll have an Optane on my notebook in a reasonable time
>> ;)
>> > >>>
>> > >>>
>> > >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky < ivanda...@gmail.com
>> >
>> > >>> wrote:
>> > >>>
>> > >>> > Semyon D. and Maks T. -- thanks a lot for review.
>> > >>> >
>> > >>> > BTW, Igniters, I will appreciate all opinions and feedback.
>> > >>> >
>> > >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky <
>>  ivanda...@apache.org
>> > >:
>> > >>> >
>> > >>> > > Hi, igniters!
>> > >>> > >
>> > >>> > > There is not a big secret that nowadays NUMA is quite common in
>> > >>> > > multiprocessor systems.
>> > >>> > > And this memory architecture should be treated in specific ways.
>> > >>> > >
>> > >>> > > Support for NUMA is present in many commercial and open-source
>> > >>> products.
>> > >>> > >
>> > >>> > > I've implemented a NUMA aware allocator for Apache Ignite [1]
>> > >>> > > It is a JNI wrapper around `libnuma` and supports different
>> > >>> allocation
>> > >>> > > options.
>> > >>> > > I.e. interleaved, local, interleved_mask and so on. For more
>> > >>> information,
>> > >>> > > see
>> > >>> > > [2], [3].
>> > >>> > > This allocator in interleaved mode and passing `-XX:+UseNUMA`
>> flag
>> > >>> to jvm
>> > >>> > > show promising results on yardstick benches. Technically, G1 is
>> > not a
>> > >>> > numa
>> > >>> > > aware collector for java versions less than 14, but allocation of
>> > >>> heap in
>> > >>> > > interleaved mode shows good results even on java 11.
>> > >>> > >
>> > >>> > > Currently, all needed libraries and tools for building this
>> module
>> > >>> are
>> > >>> > > available on TC agents
>> > >>> > > setup of specific test suite is in progress [4]
>> > >>> > >
>> > >>> > > So I am asking for a review of my patch.
>> > >>> > >
>> > >>> > > [1] --  https://issues.apache.org/jira/browse/IGNITE-15922
>> > >>> > > [2] --  https://man7.org/linux/man-pages/man3/numa.3.html
>> > >>> > > [3] --  https://man7.org/linux/man-pages/man2/mbind.2.html
>> > >>> > > [4] --  https://issues.apache.org/jira/browse/IGNITE-15994
>> > >>> > >
>> > >>> >
>> > >>> >
>> > >>> > --
>> > >>> > Sincerely yours, Ivan Daschinskiy
>> > >>> >
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Best regards,
>> > >>> Andrey V. Mashenkov
>> > >>>
>> > >>
>> > >>
>> > >> --

Re: NUMA aware allocator, PR review request

[Ivan Daschinsky]

Anton, I disagree.

1. This should be released with main distro.
2. This should not be abandoned.
3. There is not any release process in ignite-extensions.
4. Everything is working now and working good.


So lets do not do this :)

пн, 6 дек. 2021 г. в 14:49, Anton Vinogradov :

> Let's move all GCC-related parts to ignite-extensions, release, and use
> them as a maven dependency.
>
>
> On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky 
> wrote:
>
> > Ok, TC suite is ready [1].
> > If there is no objections, I will merge it soon.
> >
> > Possible concerns -- now it is required to install build-essentials and
> > libnuma-dev in order to build ignite on 64 bit linux.
> > I suppose that this is not a big deal, but maybe someone will contradict?
> >
> >
> > [1] --
> >
> >
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
> >
> > чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky :
> >
> > > >> Our runs show about 7-10 speedup,
> > > Sorry, typo 7-10%  speedup
> > >
> > > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky :
> > >
> > >> Andrey, thanks!
> > >>
> > >> This allocator can be tested on every NUMA system.
> > >> Our runs show about 7-10 speedup, if we use allocattor with
> interleaved
> > >> strategy + -XX:+UseNUMA.
> > >> But unfortunately our yardstick benches doesn't use offheap a lot,
> > >> usually above one Gb.
> > >> We trying to do more benches with real data and share them, possibly
> in
> > >> meetup.
> > >>
> > >> AFAIK, GG lab servers are two-sockets machines, aren't they? So it is
> > >> worth to run benches with a lot data on them, using
> > >> allocator with interleaved strategy (you can skip specifying numa
> nodes,
> > >> by default it will use all available) and use -XX:+UseNUMA jvm
> > >> flag.
> > >>
> > >>
> > >>
> > >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> > andrey.mashen...@gmail.com
> > >> >:
> > >>
> > >>> Ivan,
> > >>>
> > >>> Great job. PR looks good.
> > >>>
> > >>> This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to
> > jvm
> > >>> > show promising results on yardstick benches. Technically, G1 is
> not a
> > >>> numa
> > >>> > aware collector for java versions less than 14, but allocation of
> > heap
> > >>> in
> > >>> > interleaved mode shows good results even on java 11.
> > >>>
> > >>> Can you share benchmark results?
> > >>> I'm not sure I'll have an Optane on my notebook in a reasonable time
> ;)
> > >>>
> > >>>
> > >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky  >
> > >>> wrote:
> > >>>
> > >>> > Semyon D. and Maks T. -- thanks a lot for review.
> > >>> >
> > >>> > BTW, Igniters, I will appreciate all opinions and feedback.
> > >>> >
> > >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky <
> ivanda...@apache.org
> > >:
> > >>> >
> > >>> > > Hi, igniters!
> > >>> > >
> > >>> > > There is not a big secret that nowadays NUMA is quite common in
> > >>> > > multiprocessor systems.
> > >>> > > And this memory architecture should be treated in specific ways.
> > >>> > >
> > >>> > > Support for NUMA is present in many commercial and open-source
> > >>> products.
> > >>> > >
> > >>> > > I've implemented a NUMA aware allocator for Apache Ignite [1]
> > >>> > > It is a JNI wrapper around `libnuma` and supports different
> > >>> allocation
> > >>> > > options.
> > >>> > > I.e. interleaved, local, interleved_mask and so on. For more
> > >>> information,
> > >>> > > see
> > >>> > > [2], [3].
> > >>> > > This allocator in interleaved mode and passing `-XX:+UseNUMA`
> flag
> > >>> to jvm
> > >>> > > show promising results on yardstick benches. Technically, G1 is
> > not a
> > >>> > numa
> > >>> > > aware collector for java versions less than 14, but allocation of
> > >>> heap in
> > >>> > > interleaved mode shows good results even on java 11.
> > >>> > >
> > >>> > > Currently, all needed libraries and tools for building this
> module
> > >>> are
> > >>> > > available on TC agents
> > >>> > > setup of specific test suite is in progress [4]
> > >>> > >
> > >>> > > So I am asking for a review of my patch.
> > >>> > >
> > >>> > > [1] --  https://issues.apache.org/jira/browse/IGNITE-15922
> > >>> > > [2] -- https://man7.org/linux/man-pages/man3/numa.3.html
> > >>> > > [3] -- https://man7.org/linux/man-pages/man2/mbind.2.html
> > >>> > > [4] -- https://issues.apache.org/jira/browse/IGNITE-15994
> > >>> > >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Sincerely yours, Ivan Daschinskiy
> > >>> >
> > >>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>> Andrey V. Mashenkov
> > >>>
> > >>
> > >>
> > >> --
> > >> Sincerely yours, Ivan Daschinskiy
> > >>
> > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> > >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>


-- 
Sincerely yours, Ivan Daschinskiy

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Nikolay Izhikov]

Slava, I don’t get it.

> Plugins have access to different internal Ignite components, such as security 
> processor and others, and can extend the programmatic API of Ignite.

Where docs say that we, as a community, take responsibility to keep internals 
in the way plugin expect?

> 6 дек. 2021 г., в 14:48, Вячеслав Коптилин  
> написал(а):
> 
> Hello Nikolay,
> 
>>> plugin framework allows to implement internal components and use the
> internal API.
>> Can you please, point out to documentation or place in Ignite code that
> describe this behaviour?
> 
> Looks like it states here https://ignite.apache.org/docs/latest/plugins
> 
>> The Ignite plugin system allows you to extend the core functionality of
>> Ignite. Plugins have access to different internal Ignite components, such
>> as security processor and others, and can extend the programmatic API of
>> Ignite.
> 
> 
> Thanks,
> S.
> 
> 
> сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :
> 
>> Valentin
>> 
>>> plugin framework allows to implement internal components and use the
>> internal API.
>> 
>> Can you please, point out to documentation or place in Ignite code that
>> describe this behaviour?
>> AFAIK plugin can only use public API, internal API can be changed any time
>> we want.
>> 
>>> Folks, can anyone explain the rush?
>> 
>> No rush from my side.
>> 
>> Just want to understand your vision of integration points between Ignite
>> and plugins.
>> 
>>> Is there any specific reason for it?
>> 
>> Intention of IEP-80 is to improve Ignite codebase by removing abandoned
>> features.
>> 
>>> But the fact is that there are users that can depend on the system cache
>> via the plugin framework.
>> 
>> Why this dependency can’t be changed to any regular cache?
>> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s it.
>> 
>> Do we have some special guarantees or logic besides system cache?
>> 
>> 
>>> 4 дек. 2021 г., в 02:14, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> написал(а):
>>> 
>>> Nikolay, that's right, plugin framework allows to implement internal
>>> components and use the internal API. There is a difference between a
>> plugin
>>> and an extension that uses only public API
>>> 
>>> Folks, can anyone explain the rush? Is there any specific reason for it?
>>> 
>>> I think we all agree that this is a good change - system cache has to
>> go. I
>>> guess technically it's not even a breaking change, because system cache
>> is
>>> not a public API feature. But the fact is that there are users that can
>>> depend on the system cache via the plugin framework. Let's be respectful
>> to
>>> those users, provide a reasonable documented alternative and give time.
>>> 
>>> -Val
>>> 
>>> On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov 
>> wrote:
>>> 
 I don’t understand how it possible.
 
 Are you talking about plugin that uses some kind of internal API?
 
> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин 
 написал(а):
> 
> Hello Nikolay,
> 
> If I am not mistaken, the method you mentioned, allows to create a
>> "user"
> cache that is available through public api for the user. This does not
> cover the case when the plugin developer wants to hide such cache and
> protect it form the end user (at least, via public api).
> 
> Thanks,
> S.
> 
> пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov :
> 
>> Vyacheslav, Val, can you please clarify - What is the issue if
 third-party
>> plugins will create «ignite-sys-cache» from the code?
>> 
>> Like just replacing `Ignite#cache` with the `Ignite#getOrCreateCache`.
>> 
>>> 2 дек. 2021 г., в 16:13, Вячеслав Коптилин >> 
>> написал(а):
>>> 
>>> Hello Maxim,
>>> 
 I don't understand why you are using *backwards compatibility* for
>>> completely internal things.
 Why you are thinking in terms of users usage when are talking about
>>> ignite-sys-cache but not thinking when refactoring
>>> First of all, we are talking about all plugin developers. It does not
>>> matter it is open-source or proprietary plugins.
>>> Honestly, I don't have a list of all possible plugins that have
>> already
>>> been developed and available under the ASF license, for instance.
>>> Do you have such a list? Can you be sure that this change will not
 affect
>>> anyone?
>>> 
 I don't understand why you are using *backwards compatibility* for
>>> completely internal things.
 Why you are thinking in terms of users usage when are talking about
>>> ignite-sys-cache but not thinking when refactoring
>>> The system cache was the crucial thing in the architecture of Apache
>> Ignite
>>> 1.x and 2.x (at least 2.1 - 2.11?)
>>> 
 All the internals have been reworked and nobody even mentioned that
>> it
>>> may affect some of the plugin developers.
>>> Yep, perhaps, some internal parts of Apache Ignite were reworked 

Re: NUMA aware allocator, PR review request

[Anton Vinogradov]

Let's move all GCC-related parts to ignite-extensions, release, and use
them as a maven dependency.


On Fri, Dec 3, 2021 at 1:08 PM Ivan Daschinsky  wrote:

> Ok, TC suite is ready [1].
> If there is no objections, I will merge it soon.
>
> Possible concerns -- now it is required to install build-essentials and
> libnuma-dev in order to build ignite on 64 bit linux.
> I suppose that this is not a big deal, but maybe someone will contradict?
>
>
> [1] --
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_NumaAllocator/?mode=builds
>
> чт, 2 дек. 2021 г. в 12:03, Ivan Daschinsky :
>
> > >> Our runs show about 7-10 speedup,
> > Sorry, typo 7-10%  speedup
> >
> > чт, 2 дек. 2021 г. в 12:01, Ivan Daschinsky :
> >
> >> Andrey, thanks!
> >>
> >> This allocator can be tested on every NUMA system.
> >> Our runs show about 7-10 speedup, if we use allocattor with interleaved
> >> strategy + -XX:+UseNUMA.
> >> But unfortunately our yardstick benches doesn't use offheap a lot,
> >> usually above one Gb.
> >> We trying to do more benches with real data and share them, possibly in
> >> meetup.
> >>
> >> AFAIK, GG lab servers are two-sockets machines, aren't they? So it is
> >> worth to run benches with a lot data on them, using
> >> allocator with interleaved strategy (you can skip specifying numa nodes,
> >> by default it will use all available) and use -XX:+UseNUMA jvm
> >> flag.
> >>
> >>
> >>
> >> чт, 2 дек. 2021 г. в 11:48, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> >> >:
> >>
> >>> Ivan,
> >>>
> >>> Great job. PR looks good.
> >>>
> >>> This allocator in interleaved mode and passing `-XX:+UseNUMA` flag to
> jvm
> >>> > show promising results on yardstick benches. Technically, G1 is not a
> >>> numa
> >>> > aware collector for java versions less than 14, but allocation of
> heap
> >>> in
> >>> > interleaved mode shows good results even on java 11.
> >>>
> >>> Can you share benchmark results?
> >>> I'm not sure I'll have an Optane on my notebook in a reasonable time ;)
> >>>
> >>>
> >>> On Thu, Dec 2, 2021 at 10:41 AM Ivan Daschinsky 
> >>> wrote:
> >>>
> >>> > Semyon D. and Maks T. -- thanks a lot for review.
> >>> >
> >>> > BTW, Igniters, I will appreciate all opinions and feedback.
> >>> >
> >>> > пн, 29 нояб. 2021 г. в 10:13, Ivan Daschinsky  >:
> >>> >
> >>> > > Hi, igniters!
> >>> > >
> >>> > > There is not a big secret that nowadays NUMA is quite common in
> >>> > > multiprocessor systems.
> >>> > > And this memory architecture should be treated in specific ways.
> >>> > >
> >>> > > Support for NUMA is present in many commercial and open-source
> >>> products.
> >>> > >
> >>> > > I've implemented a NUMA aware allocator for Apache Ignite [1]
> >>> > > It is a JNI wrapper around `libnuma` and supports different
> >>> allocation
> >>> > > options.
> >>> > > I.e. interleaved, local, interleved_mask and so on. For more
> >>> information,
> >>> > > see
> >>> > > [2], [3].
> >>> > > This allocator in interleaved mode and passing `-XX:+UseNUMA` flag
> >>> to jvm
> >>> > > show promising results on yardstick benches. Technically, G1 is
> not a
> >>> > numa
> >>> > > aware collector for java versions less than 14, but allocation of
> >>> heap in
> >>> > > interleaved mode shows good results even on java 11.
> >>> > >
> >>> > > Currently, all needed libraries and tools for building this module
> >>> are
> >>> > > available on TC agents
> >>> > > setup of specific test suite is in progress [4]
> >>> > >
> >>> > > So I am asking for a review of my patch.
> >>> > >
> >>> > > [1] --  https://issues.apache.org/jira/browse/IGNITE-15922
> >>> > > [2] -- https://man7.org/linux/man-pages/man3/numa.3.html
> >>> > > [3] -- https://man7.org/linux/man-pages/man2/mbind.2.html
> >>> > > [4] -- https://issues.apache.org/jira/browse/IGNITE-15994
> >>> > >
> >>> >
> >>> >
> >>> > --
> >>> > Sincerely yours, Ivan Daschinskiy
> >>> >
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>> Andrey V. Mashenkov
> >>>
> >>
> >>
> >> --
> >> Sincerely yours, Ivan Daschinskiy
> >>
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>

Re: [DISCUSSION] Remove outdated ignite-sys-cache

[Вячеслав Коптилин]

Hello Nikolay,

>>  plugin framework allows to implement internal components and use the
internal API.
> Can you please, point out to documentation or place in Ignite code that
describe this behaviour?

Looks like it states here https://ignite.apache.org/docs/latest/plugins

> The Ignite plugin system allows you to extend the core functionality of
> Ignite. Plugins have access to different internal Ignite components, such
> as security processor and others, and can extend the programmatic API of
> Ignite.


Thanks,
S.


сб, 4 дек. 2021 г. в 14:54, Nikolay Izhikov :

> Valentin
>
> >  plugin framework allows to implement internal components and use the
> internal API.
>
> Can you please, point out to documentation or place in Ignite code that
> describe this behaviour?
> AFAIK plugin can only use public API, internal API can be changed any time
> we want.
>
> > Folks, can anyone explain the rush?
>
> No rush from my side.
>
> Just want to understand your vision of integration points between Ignite
> and plugins.
>
> > Is there any specific reason for it?
>
> Intention of IEP-80 is to improve Ignite codebase by removing abandoned
> features.
>
> > But the fact is that there are users that can depend on the system cache
> via the plugin framework.
>
> Why this dependency can’t be changed to any regular cache?
> Just replace `Ignite#cache` to `Ignite#getOrCreateCache` and that’s it.
>
> Do we have some special guarantees or logic besides system cache?
>
>
> > 4 дек. 2021 г., в 02:14, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> написал(а):
> >
> > Nikolay, that's right, plugin framework allows to implement internal
> > components and use the internal API. There is a difference between a
> plugin
> > and an extension that uses only public API
> >
> > Folks, can anyone explain the rush? Is there any specific reason for it?
> >
> > I think we all agree that this is a good change - system cache has to
> go. I
> > guess technically it's not even a breaking change, because system cache
> is
> > not a public API feature. But the fact is that there are users that can
> > depend on the system cache via the plugin framework. Let's be respectful
> to
> > those users, provide a reasonable documented alternative and give time.
> >
> > -Val
> >
> > On Fri, Dec 3, 2021 at 8:18 AM Nikolay Izhikov 
> wrote:
> >
> >> I don’t understand how it possible.
> >>
> >> Are you talking about plugin that uses some kind of internal API?
> >>
> >>> 3 дек. 2021 г., в 18:50, Вячеслав Коптилин 
> >> написал(а):
> >>>
> >>> Hello Nikolay,
> >>>
> >>> If I am not mistaken, the method you mentioned, allows to create a
> "user"
> >>> cache that is available through public api for the user. This does not
> >>> cover the case when the plugin developer wants to hide such cache and
> >>> protect it form the end user (at least, via public api).
> >>>
> >>> Thanks,
> >>> S.
> >>>
> >>> пт, 3 дек. 2021 г., 14:15 Nikolay Izhikov :
> >>>
>  Vyacheslav, Val, can you please clarify - What is the issue if
> >> third-party
>  plugins will create «ignite-sys-cache» from the code?
> 
>  Like just replacing `Ignite#cache` with the `Ignite#getOrCreateCache`.
> 
> > 2 дек. 2021 г., в 16:13, Вячеслав Коптилин  >
>  написал(а):
> >
> > Hello Maxim,
> >
> >> I don't understand why you are using *backwards compatibility* for
> > completely internal things.
> >> Why you are thinking in terms of users usage when are talking about
> > ignite-sys-cache but not thinking when refactoring
> > First of all, we are talking about all plugin developers. It does not
> > matter it is open-source or proprietary plugins.
> > Honestly, I don't have a list of all possible plugins that have
> already
> > been developed and available under the ASF license, for instance.
> > Do you have such a list? Can you be sure that this change will not
> >> affect
> > anyone?
> >
> >> I don't understand why you are using *backwards compatibility* for
> > completely internal things.
> >> Why you are thinking in terms of users usage when are talking about
> > ignite-sys-cache but not thinking when refactoring
> > The system cache was the crucial thing in the architecture of Apache
>  Ignite
> > 1.x and 2.x (at least 2.1 - 2.11?)
> >
> >> All the internals have been reworked and nobody even mentioned that
> it
> > may affect some of the plugin developers.
> > Yep, perhaps, some internal parts of Apache Ignite were reworked in
> >> order
> > to avoid using the system cache.
> > However, it is still a part of Ignite and it works and can be used in
> > plugins.
> > Honestly, the mentioned alternative, I mean the distributed
> >> metastorage,
>  is
> > the INTERNAL thing as well.
> > It means that plugin developer depends on INTERNAL entities. (it does
> >> not
> > matter system-cache/metastorage)
> > IMHO, such questions should be 

Re: Add ability to specify INLINE_SIZE for PK sorted index and key's schema validation [IGNITE-11402]

[Maksim Timonin]

Hi, Taras!

I get critical system failure when I tried to explicitly set inline size
with negative value. WDYT, if we restrict it with only positive numbers for
public API?

Also, I put some minor comments. Can you please have a look?

On Fri, Dec 3, 2021 at 6:09 PM Taras Ledkov  wrote:

> Hi Igniters,
>
> There is an issue to add ability to specify INLINE_SIZE for sorted index on
> the primary key and index on affinite fields [1].
> Please take a look at the last comment (proposal).
>
> I duplicate the proposal here.
>
> *Proposal:*
> add to the public QueryEntity properties:
> - Integer primaryKeyInlineSize - use wrapper object to compatibility (null
> value - default behavior);
> - Integer affinityFieldInlineSize - use wrapper object to compatibility
> (null value - default behavior);
>
> The approach has a contradiction with cache API behavior.
> Now there is no ability to specify PK sorted index with unwrapped PK fields
> by cache API + QueryEntity. This functionality is available only from SQL
> command 'CREATE TABLE' (see H2TableDescriptor#extractKeyColumns)
>
> So,
> - by SQL command we cannot create 'wrapped' PK sorted index for composite
> PK;
> - by cache API we cannot create 'unwrapped' PK sorted index for composite
> PK.
>
> I propose to add the public property:
> Boolean QueryEntity#unwrapPrimaryKeyFieldsForSortedIndex
> to make SQL & cache API symmetrical.
>
> *There is a pitfall here*
> User may specify the key class like below:
>
> class MyKey{
>   @QuerySqlField
>   int id0;
>
>   @QuerySqlField
>   int id1;
>
>   int hiddenId;
> }
>
> In this case two objects MyKey(0, 0, 0) & MyKey(0,0,1) are different and
> may be put into cache as a two different keys.
> But they are similar for SQL PK.
> But this scenario now may be produced by SQL command CREATE TABLE + cache
> API.
>
> I propose to add key schema validation to the
> QueryTypeDescriptorImpl#validateKeyAndValue.
> [1]. https://issues.apache.org/jira/browse/IGNITE-11402
>

Re: Glad to join the Ignite community

[Pavel Tupitsyn]

Hi Erlan,

Added you to the contributors role in JIRA.
Welcome to the Apache Ignite community!

Pavel


On Mon, Dec 6, 2021 at 9:36 AM Erlan Aytpaev  wrote:

> Hi, Igniters,
>
> My name is Erlan. I'm a seasoned full-stack developer (PHP/JS) with over 10
> years experience.
>
> I'd like to join the community and contribute to the Ignite website. Please
> grant me contributors' permissions in JIRA. My JIRA account/ID is "hoter" (
> aytp...@gmail.com).
>
> Best Regards,
> Erlan.
>