Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Congrats, Slava! ср, 19 февр. 2020 г. в 08:38, Ivan Pavlukhin : > > Hooray! > > Best regards, > Ivan Pavlukhin > > ср, 19 февр. 2020 г. в 00:28, Dmitriy Govorukhin > : > > > > My congratulations, Slava! > > > > On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote: > > > > > Congratulations, Slava! > > > > > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > > > > > Hello Ignite Community, > > > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > > Vyacheslav Koptilin to become a committer and we are pleased to announce > > > > that he has accepted. > > > > > > > > Vyacheslav investigated and fixed a number of non-trivial issues in the > > > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > > > Consistency Check). > > > > > > > > Being a committer enables easier contribution to the project since there > > > is > > > > no need to go via the patch submission process. This should enable > > > > better > > > > productivity. > > > > > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > > > > > Best Regards, > > > > Dmitriy Pavlov > > > > on behalf of Apache Ignite PMC > > > > > > > > > > > > > -- > > > Best regards, > > > Andrey Kuznetsov. > > > -- Best wishes, Amelchev Nikita
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Congratulations, Slava! вт, 18 февр. 2020 г., 22:20 Dmitriy Pavlov : > Hello Ignite Community, > > The Project Management Committee (PMC) for Apache Ignite has invited > Vyacheslav Koptilin to become a committer and we are pleased to announce > that he has accepted. > > Vyacheslav investigated and fixed a number of non-trivial issues in the > Ignite Native persistent store, was a reviewer of Read Repair (ex. > Consistency Check). > > Being a committer enables easier contribution to the project since there is > no need to go via the patch submission process. This should enable better > productivity. > > Vyacheslav, thanks for supporting the community and keep the pace! > > Best Regards, > Dmitriy Pavlov > on behalf of Apache Ignite PMC >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Hooray! Best regards, Ivan Pavlukhin ср, 19 февр. 2020 г. в 00:28, Dmitriy Govorukhin : > > My congratulations, Slava! > > On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote: > > > Congratulations, Slava! > > > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > > > Hello Ignite Community, > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > Vyacheslav Koptilin to become a committer and we are pleased to announce > > > that he has accepted. > > > > > > Vyacheslav investigated and fixed a number of non-trivial issues in the > > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > > Consistency Check). > > > > > > Being a committer enables easier contribution to the project since there > > is > > > no need to go via the patch submission process. This should enable better > > > productivity. > > > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > > > Best Regards, > > > Dmitriy Pavlov > > > on behalf of Apache Ignite PMC > > > > > > > > > -- > > Best regards, > > Andrey Kuznetsov. > >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
My congratulations, Slava! On Tue, Feb 18, 2020 at 11:33 PM Andrey Kuznetsov wrote: > Congratulations, Slava! > > вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > > > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Vyacheslav Koptilin to become a committer and we are pleased to announce > > that he has accepted. > > > > Vyacheslav investigated and fixed a number of non-trivial issues in the > > Ignite Native persistent store, was a reviewer of Read Repair (ex. > > Consistency Check). > > > > Being a committer enables easier contribution to the project since there > is > > no need to go via the patch submission process. This should enable better > > productivity. > > > > Vyacheslav, thanks for supporting the community and keep the pace! > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC > > > > > -- > Best regards, > Andrey Kuznetsov. >
Re: [ANNOUNCE] New committer: Vyacheslav Koptilin
Congratulations, Slava! вт, 18 февр. 2020 г. в 22:20, Dmitriy Pavlov : > Hello Ignite Community, > > The Project Management Committee (PMC) for Apache Ignite has invited > Vyacheslav Koptilin to become a committer and we are pleased to announce > that he has accepted. > > Vyacheslav investigated and fixed a number of non-trivial issues in the > Ignite Native persistent store, was a reviewer of Read Repair (ex. > Consistency Check). > > Being a committer enables easier contribution to the project since there is > no need to go via the patch submission process. This should enable better > productivity. > > Vyacheslav, thanks for supporting the community and keep the pace! > > Best Regards, > Dmitriy Pavlov > on behalf of Apache Ignite PMC > -- Best regards, Andrey Kuznetsov.
[jira] [Created] (IGNITE-12698) Configurable application name for yarn
Valerii Shinkevich created IGNITE-12698: --- Summary: Configurable application name for yarn Key: IGNITE-12698 URL: https://issues.apache.org/jira/browse/IGNITE-12698 Project: Ignite Issue Type: Improvement Components: yarn Affects Versions: 2.7.6 Reporter: Valerii Shinkevich An ability to specify an application name on the YARN needed to be able to visually distinguish between jobs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[ANNOUNCE] New committer: Vyacheslav Koptilin
Hello Ignite Community, The Project Management Committee (PMC) for Apache Ignite has invited Vyacheslav Koptilin to become a committer and we are pleased to announce that he has accepted. Vyacheslav investigated and fixed a number of non-trivial issues in the Ignite Native persistent store, was a reviewer of Read Repair (ex. Consistency Check). Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. Vyacheslav, thanks for supporting the community and keep the pace! Best Regards, Dmitriy Pavlov on behalf of Apache Ignite PMC
[jira] [Created] (IGNITE-12697) Ignite YARN containers don't start properly for no apparent reason.
Valerii Shinkevich created IGNITE-12697: --- Summary: Ignite YARN containers don't start properly for no apparent reason. Key: IGNITE-12697 URL: https://issues.apache.org/jira/browse/IGNITE-12697 Project: Ignite Issue Type: Improvement Components: yarn Affects Versions: 2.7.6 Reporter: Valerii Shinkevich When the container was checked, the result of only one of the three checks was output to the log. In addition, by default, the FINE level is not output to the log. This led to a misunderstanding of the reason for allocating and immediately completing the container. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Ilya, looks like there is a misunderstanding.
We don't start near cache on a subset of server nodes. Let me explain again.
Consider the following code, executed on any node (client or server - does
not matter):
ignite.createCache(new CacheConfiguration("c").setNearConfiguration(new
NearCacheConfiguration()));
As a result, cache "c" is started on all server nodes, and corresponding
near cache is started on all server nodes,
with the same config, eviction policy, and so on.
Now, what do we do with .NET near cache in this situation?
1. Start .NET near cache as well on server nodes, always.
2. Introduce a config flag, and start .NET near cache only when the flag is
set
The problem with option (1) is that it changes the behavior of existing
applications,
increasing overhead for cache operations and increasing memory usage.
As a user, I don't want some new features to be force-enabled on me
silently in a new product version.
That is why an opt-in config flag is required.
Does this make sense?
On Tue, Feb 18, 2020 at 6:42 PM Ilya Kasnacheev
wrote:
> Hello!
>
> I'm not sure that we can/want to create near cache on a subset of server
> nodes.
>
> If this is indeed possible, I would decouple that from .Net and introduce
> as a separate feature.
>
> Ideally we should be able to start or stop near cache on any node, server
> or client, and this should be the same cache for all platforms (including
> Java). WDYT?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 18 февр. 2020 г. в 17:31, Pavel Tupitsyn :
>
> > Ilya, as noted above:
> >
> > > There are 2 kinds of Near Caches:
> > > - On client nodes: created per-node by calling ignite.CreateNearCache
> > > - On server nodes: created on all server nodes if
> > CacheConfiguration.NearCacheConfiguration is not null
> > >
> > > When user says ignite.CreateCache(new CacheConfiguration
> > {NearCacheConfiguration = ...}),
> > > the whole config is sent to all server nodes, and .NET-specific flag
> has
> > to be included somehow.
> >
> >
> >
> > On Tue, Feb 18, 2020 at 5:10 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > Why would it waste additional memory? All nodes are also Java nodes so
> > they
> > > will start near caches all right.
> > >
> > > Don't we have near cache start-up on per-node basis for clients,
> anyway?
> > >
> > > I'm not convinced why we need this flag. I have to admit my
> understanding
> > > of near caches is limited.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 18 февр. 2020 г. в 16:56, Pavel Tupitsyn :
> > >
> > > > Ilya, Aleksandr,
> > > >
> > > > The flag is called platformNearCacheEnabled, my idea is to have just
> > one
> > > > flag for all platforms.
> > > >
> > > > If some platform is present on the given node (.NET, C++) and it
> > supports
> > > > native near caching,
> > > > then the flag is honored, otherwise it is ignored. We should not
> throw
> > > > exceptions,
> > > > because mixed clusters are possible (.NET nodes along with Java
> nodes).
> > > >
> > > > > Why would enabling it affect mixed`clusters?
> > > > Initially the idea was to enable .NET near cache whenever
> > > > NearCacheConfiguration is present.
> > > > If we assume .NET-only clusters, it makes sense: existing code will
> > work
> > > > faster automatically.
> > > >
> > > > Mixed cluster is just one of the possible use cases when this may be
> a
> > > bad
> > > > idea,
> > > > e.g. users have enabled near caching to speed up their Java-based
> > > > computations,
> > > > and .NET nodes are used for something else, wasting memory on near
> > > caching
> > > > unnecessarily.
> > > >
> > > > On ue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin >
> > > > wrote:
> > > >
> > > > > Pavel,
> > > > >
> > > > >
> > > > >
> > > > > I think it’s ok to add a new flag.
> > > > >
> > > > > Though we may change a name to something like
> > > > #usePlatformCacheIfAvailable
> > > > >
> > > > >
> > > > >
> > > > > But it may vary depending on the implementation, i.e.
> > > > >
> > > > > should we throw an error if there is no native cache
> > > > >
> > > > > available for a platform or just ignore the configuration.
> > > > >
> > > > > вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn >:
> > > > >
> > > > > > Igor,
> > > > > >
> > > > > > The problem is - we need to pass this flag around the cluster`for
> > > > Server
> > > > > > Near Caches,
> > > > > > so that .NET near caches are started accordingly.
> > > > > >
> > > > > > There are 2 kinds of Near Caches:
> > > > > > - On client nodes: created on every client node separately by
> > calling
> > > > > > ignite.CreateNearCache
> > > > > > - On server nodes: created on all server nodes if
> > > > > > CacheConfiguration.NearCacheConfiguration is set
> > > > > >
> > > > > > When user says ignite.CreateCache(new CacheConfiguration
> > > > > > {NearCacheConfiguration = ...}),
> > > > > > the whole config is sent 4o all server nodes, and .NET-specific
> > flag
> > > >
Re: Let's fix number of essential thread pools' threads in tests!
Hello! I have ran nightlies, it runs OK (with exception of MVCC Cache 7 which seem to always hang on master) but there's virtually no speed difference in this run. Still, I think it makes sense to fix number of threads used. WDYT? I would be glad to have a formal review. Regards, -- Ilya Kasnacheev вт, 18 февр. 2020 г. в 14:53, Ilya Kasnacheev : > Hello! > > A single runAll of this code was 5h faster than regular master, in net > time, but this might as well be measurement artifact. I will compare Run > All Nightly which I have already started. > > Regards, > -- > Ilya Kasnacheev > > > пн, 17 февр. 2020 г. в 18:04, Ivan Pavlukhin : > >> Ilya, >> >> > 5 is smallest viable number, I hope that TC suites will run slightly >> > faster, produce less logs, and will be easier to debug (smaller batches >> of >> > threads to scroll) >> >> It would be quite interesting for me to measure this positive effect. >> Is it possible? >> >> From a practical standpoint I suppose it is necessary to ensure that >> everything is ok with nightly tests as well. >> >> Best regards, >> Ivan Pavlukhin >> >> пн, 17 февр. 2020 г. в 15:00, Ilya Kasnacheev > >: >> > >> > Hello! >> > >> > I have created the following ticket: >> > >> > https://issues.apache.org/jira/browse/IGNITE-12663 >> > >> > Our current number of threads in pools is max(8, NCPU), this means, we >> will >> > see different behavior depending on hardware. >> > >> > I have adjusted GridAbstractTest so the default for most pools is 5, >> > excluding striped, which is 8. >> > >> > 5 is smallest viable number, I hope that TC suites will run slightly >> > faster, produce less logs, and will be easier to debug (smaller batches >> of >> > threads to scroll) >> > >> > Tests pass after fixing a single test. WDYT? >> > >> > Regards, >> > -- >> > Ilya Kasnacheev >> >
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Hello!
I'm not sure that we can/want to create near cache on a subset of server
nodes.
If this is indeed possible, I would decouple that from .Net and introduce
as a separate feature.
Ideally we should be able to start or stop near cache on any node, server
or client, and this should be the same cache for all platforms (including
Java). WDYT?
Regards,
--
Ilya Kasnacheev
вт, 18 февр. 2020 г. в 17:31, Pavel Tupitsyn :
> Ilya, as noted above:
>
> > There are 2 kinds of Near Caches:
> > - On client nodes: created per-node by calling ignite.CreateNearCache
> > - On server nodes: created on all server nodes if
> CacheConfiguration.NearCacheConfiguration is not null
> >
> > When user says ignite.CreateCache(new CacheConfiguration
> {NearCacheConfiguration = ...}),
> > the whole config is sent to all server nodes, and .NET-specific flag has
> to be included somehow.
>
>
>
> On Tue, Feb 18, 2020 at 5:10 PM Ilya Kasnacheev >
> wrote:
>
> > Hello!
> >
> > Why would it waste additional memory? All nodes are also Java nodes so
> they
> > will start near caches all right.
> >
> > Don't we have near cache start-up on per-node basis for clients, anyway?
> >
> > I'm not convinced why we need this flag. I have to admit my understanding
> > of near caches is limited.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 18 февр. 2020 г. в 16:56, Pavel Tupitsyn :
> >
> > > Ilya, Aleksandr,
> > >
> > > The flag is called platformNearCacheEnabled, my idea is to have just
> one
> > > flag for all platforms.
> > >
> > > If some platform is present on the given node (.NET, C++) and it
> supports
> > > native near caching,
> > > then the flag is honored, otherwise it is ignored. We should not throw
> > > exceptions,
> > > because mixed clusters are possible (.NET nodes along with Java nodes).
> > >
> > > > Why would enabling it affect mixed`clusters?
> > > Initially the idea was to enable .NET near cache whenever
> > > NearCacheConfiguration is present.
> > > If we assume .NET-only clusters, it makes sense: existing code will
> work
> > > faster automatically.
> > >
> > > Mixed cluster is just one of the possible use cases when this may be a
> > bad
> > > idea,
> > > e.g. users have enabled near caching to speed up their Java-based
> > > computations,
> > > and .NET nodes are used for something else, wasting memory on near
> > caching
> > > unnecessarily.
> > >
> > > On ue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin
> > > wrote:
> > >
> > > > Pavel,
> > > >
> > > >
> > > >
> > > > I think it’s ok to add a new flag.
> > > >
> > > > Though we may change a name to something like
> > > #usePlatformCacheIfAvailable
> > > >
> > > >
> > > >
> > > > But it may vary depending on the implementation, i.e.
> > > >
> > > > should we throw an error if there is no native cache
> > > >
> > > > available for a platform or just ignore the configuration.
> > > >
> > > > вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
> > > >
> > > > > Igor,
> > > > >
> > > > > The problem is - we need to pass this flag around the cluster`for
> > > Server
> > > > > Near Caches,
> > > > > so that .NET near caches are started accordingly.
> > > > >
> > > > > There are 2 kinds of Near Caches:
> > > > > - On client nodes: created on every client node separately by
> calling
> > > > > ignite.CreateNearCache
> > > > > - On server nodes: created on all server nodes if
> > > > > CacheConfiguration.NearCacheConfiguration is set
> > > > >
> > > > > When user says ignite.CreateCache(new CacheConfiguration
> > > > > {NearCacheConfiguration = ...}),
> > > > > the whole config is sent 4o all server nodes, and .NET-specific
> flag
> > > has
> > > > to
> > > > > be included somehow.
> > > > >
> > > > > On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego
> > > wrote:
> > > > >
> > > > > > Do you suggest to introduce it in general configuration? Why not
> > > > > introduce
> > > > > > it only on platform side? Is there any .NET-specific
> configuration?
> > > > > >
> > > > > > Best Regards,
> > > > > > Igo2
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I'm working on .NET Near Cache feature [1]
> > > > > > > (storing deserialized cache entries in CLR memory to improve
> > > > > > performance).
> > > > > > >
> > > > > > > Implementation is based on Java near cache, with some callbacks
> > to
> > > > .NET
> > > > > > > side
> > > > > > > for updating and invalidating cached entries.
~ > > > > > >
> > > > > > > However, I'd like to make this feature optional: enabling Java
> > near
> > > > > cache
> > > > > > > should not
> > > > > > > always enable .NET near cache - some users may have mixed
> > clusters,
> > > > > etc.
> > > > > > >
> > > > > > > Therefore I'm adding
> > > NearCacheConfiguration#platformNearCacheEnabled
> > > > > > > boolean flag.
> > > > > > > Are there any objections or better ideas to configure this
> > >
[jira] [Created] (IGNITE-12696) Remove deprecated @MXBeanParametersNames and @MXBeanParametersDescriptions annotations
Andrey N. Gura created IGNITE-12696:
---
Summary: Remove deprecated @MXBeanParametersNames and
@MXBeanParametersDescriptions annotations
Key: IGNITE-12696
URL: https://issues.apache.org/jira/browse/IGNITE-12696
Project: Ignite
Issue Type: Improvement
Reporter: Andrey N. Gura
Fix For: 3.0
{{@MXBeanParametersNames}} and {{@MXBeanParametersDescriptions}} annotations
are deprecated due to the change IGNITE-10698.
Mentioned annotations must be removed in Apache Ignite 3.0 release, **but not
earlier**.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Ilya, as noted above:
> There are 2 kinds of Near Caches:
> - On client nodes: created per-node by calling ignite.CreateNearCache
> - On server nodes: created on all server nodes if
CacheConfiguration.NearCacheConfiguration is not null
>
> When user says ignite.CreateCache(new CacheConfiguration
{NearCacheConfiguration = ...}),
> the whole config is sent to all server nodes, and .NET-specific flag has
to be included somehow.
On Tue, Feb 18, 2020 at 5:10 PM Ilya Kasnacheev
wrote:
> Hello!
>
> Why would it waste additional memory? All nodes are also Java nodes so they
> will start near caches all right.
>
> Don't we have near cache start-up on per-node basis for clients, anyway?
>
> I'm not convinced why we need this flag. I have to admit my understanding
> of near caches is limited.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 18 февр. 2020 г. в 16:56, Pavel Tupitsyn :
>
> > Ilya, Aleksandr,
> >
> > The flag is called platformNearCacheEnabled, my idea is to have just one
> > flag for all platforms.
> >
> > If some platform is present on the given node (.NET, C++) and it supports
> > native near caching,
> > then the flag is honored, otherwise it is ignored. We should not throw
> > exceptions,
> > because mixed clusters are possible (.NET nodes along with Java nodes).
> >
> > > Why would enabling it affect mixed clusters?
> > Initially the idea was to enable .NET near cache whenever
> > NearCacheConfiguration is present.
> > If we assume .NET-only clusters, it makes sense: existing code will work
> > faster automatically.
> >
> > Mixed cluster is just one of the possible use cases when this may be a
> bad
> > idea,
> > e.g. users have enabled near caching to speed up their Java-based
> > computations,
> > and .NET nodes are used for something else, wasting memory on near
> caching
> > unnecessarily.
> >
> > On Tue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin
> > wrote:
> >
> > > Pavel,
> > >
> > >
> > >
> > > I think it’s ok to add a new flag.
> > >
> > > Though we may change a name to something like
> > #usePlatformCacheIfAvailable
> > >
> > >
> > >
> > > But it may vary depending on the implementation, i.e.
> > >
> > > should we throw an error if there is no native cache
> > >
> > > available for a platform or just ignore the configuration.
> > >
> > > вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
> > >
> > > > Igor,
> > > >
> > > > The problem is - we need to pass this flag around the cluster for
> > Server
> > > > Near Caches,
> > > > so that .NET near caches are started accordingly.
> > > >
> > > > There are 2 kinds of Near Caches:
> > > > - On client nodes: created on every client node separately by calling
> > > > ignite.CreateNearCache
> > > > - On server nodes: created on all server nodes if
> > > > CacheConfiguration.NearCacheConfiguration is set
> > > >
> > > > When user says ignite.CreateCache(new CacheConfiguration
> > > > {NearCacheConfiguration = ...}),
> > > > the whole config is sent to all server nodes, and .NET-specific flag
> > has
> > > to
> > > > be included somehow.
> > > >
> > > > On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego
> > wrote:
> > > >
> > > > > Do you suggest to introduce it in general configuration? Why not
> > > > introduce
> > > > > it only on platform side? Is there any .NET-specific configuration?
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn <
> ptupit...@apache.org
> > >
> > > > > wrote:
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > I'm working on .NET Near Cache feature [1]
> > > > > > (storing deserialized cache entries in CLR memory to improve
> > > > > performance).
> > > > > >
> > > > > > Implementation is based on Java near cache, with some callbacks
> to
> > > .NET
> > > > > > side
> > > > > > for updating and invalidating cached entries.
> > > > > >
> > > > > > However, I'd like to make this feature optional: enabling Java
> near
> > > > cache
> > > > > > should not
> > > > > > always enable .NET near cache - some users may have mixed
> clusters,
> > > > etc.
> > > > > >
> > > > > > Therefore I'm adding
> > NearCacheConfiguration#platformNearCacheEnabled
> > > > > > boolean flag.
> > > > > > Are there any objections or better ideas to configure this
> > behavior?
> > > > > >
> > > > > > Thanks,
> > > > > > Pavel
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Alex.
> > >
> >
>
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Hello!
Why would it waste additional memory? All nodes are also Java nodes so they
will start near caches all right.
Don't we have near cache start-up on per-node basis for clients, anyway?
I'm not convinced why we need this flag. I have to admit my understanding
of near caches is limited.
Regards,
--
Ilya Kasnacheev
вт, 18 февр. 2020 г. в 16:56, Pavel Tupitsyn :
> Ilya, Aleksandr,
>
> The flag is called platformNearCacheEnabled, my idea is to have just one
> flag for all platforms.
>
> If some platform is present on the given node (.NET, C++) and it supports
> native near caching,
> then the flag is honored, otherwise it is ignored. We should not throw
> exceptions,
> because mixed clusters are possible (.NET nodes along with Java nodes).
>
> > Why would enabling it affect mixed clusters?
> Initially the idea was to enable .NET near cache whenever
> NearCacheConfiguration is present.
> If we assume .NET-only clusters, it makes sense: existing code will work
> faster automatically.
>
> Mixed cluster is just one of the possible use cases when this may be a bad
> idea,
> e.g. users have enabled near caching to speed up their Java-based
> computations,
> and .NET nodes are used for something else, wasting memory on near caching
> unnecessarily.
>
> On Tue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin
> wrote:
>
> > Pavel,
> >
> >
> >
> > I think it’s ok to add a new flag.
> >
> > Though we may change a name to something like
> #usePlatformCacheIfAvailable
> >
> >
> >
> > But it may vary depending on the implementation, i.e.
> >
> > should we throw an error if there is no native cache
> >
> > available for a platform or just ignore the configuration.
> >
> > вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
> >
> > > Igor,
> > >
> > > The problem is - we need to pass this flag around the cluster for
> Server
> > > Near Caches,
> > > so that .NET near caches are started accordingly.
> > >
> > > There are 2 kinds of Near Caches:
> > > - On client nodes: created on every client node separately by calling
> > > ignite.CreateNearCache
> > > - On server nodes: created on all server nodes if
> > > CacheConfiguration.NearCacheConfiguration is set
> > >
> > > When user says ignite.CreateCache(new CacheConfiguration
> > > {NearCacheConfiguration = ...}),
> > > the whole config is sent to all server nodes, and .NET-specific flag
> has
> > to
> > > be included somehow.
> > >
> > > On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego
> wrote:
> > >
> > > > Do you suggest to introduce it in general configuration? Why not
> > > introduce
> > > > it only on platform side? Is there any .NET-specific configuration?
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn >
> > > > wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I'm working on .NET Near Cache feature [1]
> > > > > (storing deserialized cache entries in CLR memory to improve
> > > > performance).
> > > > >
> > > > > Implementation is based on Java near cache, with some callbacks to
> > .NET
> > > > > side
> > > > > for updating and invalidating cached entries.
> > > > >
> > > > > However, I'd like to make this feature optional: enabling Java near
> > > cache
> > > > > should not
> > > > > always enable .NET near cache - some users may have mixed clusters,
> > > etc.
> > > > >
> > > > > Therefore I'm adding
> NearCacheConfiguration#platformNearCacheEnabled
> > > > > boolean flag.
> > > > > Are there any objections or better ideas to configure this
> behavior?
> > > > >
> > > > > Thanks,
> > > > > Pavel
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> > > > >
> > > >
> > >
> >
> >
> > --
> > Alex.
> >
>
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Ilya, Aleksandr,
The flag is called platformNearCacheEnabled, my idea is to have just one
flag for all platforms.
If some platform is present on the given node (.NET, C++) and it supports
native near caching,
then the flag is honored, otherwise it is ignored. We should not throw
exceptions,
because mixed clusters are possible (.NET nodes along with Java nodes).
> Why would enabling it affect mixed clusters?
Initially the idea was to enable .NET near cache whenever
NearCacheConfiguration is present.
If we assume .NET-only clusters, it makes sense: existing code will work
faster automatically.
Mixed cluster is just one of the possible use cases when this may be a bad
idea,
e.g. users have enabled near caching to speed up their Java-based
computations,
and .NET nodes are used for something else, wasting memory on near caching
unnecessarily.
On Tue, Feb 18, 2020 at 4:30 PM Aleksandr Shapkin wrote:
> Pavel,
>
>
>
> I think it’s ok to add a new flag.
>
> Though we may change a name to something like #usePlatformCacheIfAvailable
>
>
>
> But it may vary depending on the implementation, i.e.
>
> should we throw an error if there is no native cache
>
> available for a platform or just ignore the configuration.
>
> вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
>
> > Igor,
> >
> > The problem is - we need to pass this flag around the cluster for Server
> > Near Caches,
> > so that .NET near caches are started accordingly.
> >
> > There are 2 kinds of Near Caches:
> > - On client nodes: created on every client node separately by calling
> > ignite.CreateNearCache
> > - On server nodes: created on all server nodes if
> > CacheConfiguration.NearCacheConfiguration is set
> >
> > When user says ignite.CreateCache(new CacheConfiguration
> > {NearCacheConfiguration = ...}),
> > the whole config is sent to all server nodes, and .NET-specific flag has
> to
> > be included somehow.
> >
> > On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego wrote:
> >
> > > Do you suggest to introduce it in general configuration? Why not
> > introduce
> > > it only on platform side? Is there any .NET-specific configuration?
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > I'm working on .NET Near Cache feature [1]
> > > > (storing deserialized cache entries in CLR memory to improve
> > > performance).
> > > >
> > > > Implementation is based on Java near cache, with some callbacks to
> .NET
> > > > side
> > > > for updating and invalidating cached entries.
> > > >
> > > > However, I'd like to make this feature optional: enabling Java near
> > cache
> > > > should not
> > > > always enable .NET near cache - some users may have mixed clusters,
> > etc.
> > > >
> > > > Therefore I'm adding NearCacheConfiguration#platformNearCacheEnabled
> > > > boolean flag.
> > > > Are there any objections or better ideas to configure this behavior?
> > > >
> > > > Thanks,
> > > > Pavel
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> > > >
> > >
> >
>
>
> --
> Alex.
>
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Pavel,
I think it’s ok to add a new flag.
Though we may change a name to something like #usePlatformCacheIfAvailable
But it may vary depending on the implementation, i.e.
should we throw an error if there is no native cache
available for a platform or just ignore the configuration.
вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
> Igor,
>
> The problem is - we need to pass this flag around the cluster for Server
> Near Caches,
> so that .NET near caches are started accordingly.
>
> There are 2 kinds of Near Caches:
> - On client nodes: created on every client node separately by calling
> ignite.CreateNearCache
> - On server nodes: created on all server nodes if
> CacheConfiguration.NearCacheConfiguration is set
>
> When user says ignite.CreateCache(new CacheConfiguration
> {NearCacheConfiguration = ...}),
> the whole config is sent to all server nodes, and .NET-specific flag has to
> be included somehow.
>
> On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego wrote:
>
> > Do you suggest to introduce it in general configuration? Why not
> introduce
> > it only on platform side? Is there any .NET-specific configuration?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn
> > wrote:
> >
> > > Igniters,
> > >
> > > I'm working on .NET Near Cache feature [1]
> > > (storing deserialized cache entries in CLR memory to improve
> > performance).
> > >
> > > Implementation is based on Java near cache, with some callbacks to .NET
> > > side
> > > for updating and invalidating cached entries.
> > >
> > > However, I'd like to make this feature optional: enabling Java near
> cache
> > > should not
> > > always enable .NET near cache - some users may have mixed clusters,
> etc.
> > >
> > > Therefore I'm adding NearCacheConfiguration#platformNearCacheEnabled
> > > boolean flag.
> > > Are there any objections or better ideas to configure this behavior?
> > >
> > > Thanks,
> > > Pavel
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> > >
> >
>
--
Alex.
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Hello!
I suggest parametrizing it with platformId, to make it possible to
implement in e.g. C++ later without creating yet another parameter. Maybe
we can migrate Java near caches to same mechanism in the future.
Why would enabling it affect mixed clusters?
Regards,
--
Ilya Kasnacheev
вт, 18 февр. 2020 г. в 15:05, Pavel Tupitsyn :
> Igor,
>
> The problem is - we need to pass this flag around the cluster for Server
> Near Caches,
> so that .NET near caches are started accordingly.
>
> There are 2 kinds of Near Caches:
> - On client nodes: created on every client node separately by calling
> ignite.CreateNearCache
> - On server nodes: created on all server nodes if
> CacheConfiguration.NearCacheConfiguration is set
>
> When user says ignite.CreateCache(new CacheConfiguration
> {NearCacheConfiguration = ...}),
> the whole config is sent to all server nodes, and .NET-specific flag has to
> be included somehow.
>
> On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego wrote:
>
> > Do you suggest to introduce it in general configuration? Why not
> introduce
> > it only on platform side? Is there any .NET-specific configuration?
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn
> > wrote:
> >
> > > Igniters,
> > >
> > > I'm working on .NET Near Cache feature [1]
> > > (storing deserialized cache entries in CLR memory to improve
> > performance).
> > >
> > > Implementation is based on Java near cache, with some callbacks to .NET
> > > side
> > > for updating and invalidating cached entries.
> > >
> > > However, I'd like to make this feature optional: enabling Java near
> cache
> > > should not
> > > always enable .NET near cache - some users may have mixed clusters,
> etc.
> > >
> > > Therefore I'm adding NearCacheConfiguration#platformNearCacheEnabled
> > > boolean flag.
> > > Are there any objections or better ideas to configure this behavior?
> > >
> > > Thanks,
> > > Pavel
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> > >
> >
>
Re: Hello all
Hello! I have added you, so you may proceed assigning tickets to yourself. Please read https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute Regards, -- Ilya Kasnacheev вт, 18 февр. 2020 г. в 14:20, Алексей Высотин : > Hello Ignite Community, > > My name is Alexey and I'm a Java and Scala developer with a current focus > on Big Data stack like Spark and Hadoop. > I would like to take part in the Apache Ignite project and make a > contribution to it. > > I'm thinking to start with some easy fix or bugfix to get more > acquainted with the code. > > Could someone give me access to Jira, please? So that I will be able to > book a ticket. > > > My Jira Username is Tesio. > > Thank you in advance. > > Best Regards, > > Alex Vysotin >
[jira] [Created] (IGNITE-12695) Calcite integration. DML support. MERGE support
Igor Seliverstov created IGNITE-12695: - Summary: Calcite integration. DML support. MERGE support Key: IGNITE-12695 URL: https://issues.apache.org/jira/browse/IGNITE-12695 Project: Ignite Issue Type: New Feature Reporter: Igor Seliverstov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Igor,
The problem is - we need to pass this flag around the cluster for Server
Near Caches,
so that .NET near caches are started accordingly.
There are 2 kinds of Near Caches:
- On client nodes: created on every client node separately by calling
ignite.CreateNearCache
- On server nodes: created on all server nodes if
CacheConfiguration.NearCacheConfiguration is set
When user says ignite.CreateCache(new CacheConfiguration
{NearCacheConfiguration = ...}),
the whole config is sent to all server nodes, and .NET-specific flag has to
be included somehow.
On Tue, Feb 18, 2020 at 2:59 PM Igor Sapego wrote:
> Do you suggest to introduce it in general configuration? Why not introduce
> it only on platform side? Is there any .NET-specific configuration?
>
> Best Regards,
> Igor
>
>
> On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn
> wrote:
>
> > Igniters,
> >
> > I'm working on .NET Near Cache feature [1]
> > (storing deserialized cache entries in CLR memory to improve
> performance).
> >
> > Implementation is based on Java near cache, with some callbacks to .NET
> > side
> > for updating and invalidating cached entries.
> >
> > However, I'd like to make this feature optional: enabling Java near cache
> > should not
> > always enable .NET near cache - some users may have mixed clusters, etc.
> >
> > Therefore I'm adding NearCacheConfiguration#platformNearCacheEnabled
> > boolean flag.
> > Are there any objections or better ideas to configure this behavior?
> >
> > Thanks,
> > Pavel
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12691
> >
>
Re: [MTCGA]: new failures in builds [4974714] needs to be handled
By the way, some ODBC tests became flaky about the same time as well. May it be there is one root cause somewhere in SQL? Best Regards, Igor On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn wrote: > I did a quick look some time ago, no idea what is going on, honestly. Tests > became flaky for no apparent reason. > I have this on my list, will investigate more. > > On Mon, Feb 17, 2020 at 8:43 PM Ivan Pavlukhin > wrote: > > > Looks like something broke .NET NuGet tests [1] in the end of January. > > Is anyone working on it? > > > > [1] > > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E=builds > > > > Best regards, > > Ivan Pavlukhin > > > > пт, 31 янв. 2020 г. в 21:56, : > > > > > > Hi Igniters, > > > > > > I've detected some new issue on TeamCity to be handled. You are more > > than welcomed to help. > > > > > > If your changes can lead to this failure(s): We're grateful that you > > were a volunteer to make the contribution to this project, but things > > change and you may no longer be able to finalize your contribution. > > > Could you respond to this email and indicate if you wish to continue > > and fix test failures or step down and some committer may revert you > commit. > > > > > > *Recently contributed test failed in master NuGet.ComputeTest > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3754909490222985251=%3Cdefault%3E=testDetails > > > > > > *New test failure in master NLogTest.TestIgniteStartup > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-557824718061284584=%3Cdefault%3E=testDetails > > > > > > *Recently contributed test failed in master NuGet.AspNetTest > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4468304894809184645=%3Cdefault%3E=testDetails > > > > > > *New test failure in master StartupTest.TestApacheIgniteExe > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5187257231705167662=%3Cdefault%3E=testDetails > > > > > > *New test failure in master > > EntityFrameworkCacheTest.TestStartupPutGet > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4190667585576620977=%3Cdefault%3E=testDetails > > > > > > *New test failure in master StartupTest.TestSpringConfig > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6904015716462020548=%3Cdefault%3E=testDetails > > > > > > *New test failure in master StartupTest.TestCodeConfig > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-702135655943708515=%3Cdefault%3E=testDetails > > > > > > *Recently contributed test failed in master NuGet.CacheTest > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6551101028080942383=%3Cdefault%3E=testDetails > > > > > > *New test failure in master Log4NetTest.TestIgniteStartup > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4358661632507505081=%3Cdefault%3E=testDetails > > > Changes may lead to failure were done by > > > - aleksei scherbakov > > https://ci.ignite.apache.org/viewModification.html?modId=897229 > > > - denis garus > > https://ci.ignite.apache.org/viewModification.html?modId=897244 > > > - sergey chugunov > > https://ci.ignite.apache.org/viewModification.html?modId=897253 > > > - anton kalashnikov > > https://ci.ignite.apache.org/viewModification.html?modId=897254 > > > - ivan bessonov > > https://ci.ignite.apache.org/viewModification.html?modId=897233 > > > - d.garus > > https://ci.ignite.apache.org/viewModification.html?modId=897266 > > > > > > - Here's a reminder of what contributors were agreed to do > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > > > - Should you have any questions please contact > > dev@ignite.apache.org > > > > > > Best Regards, > > > Apache Ignite TeamCity Bot > > > https://github.com/apache/ignite-teamcity-bot > > > Notification generated at 21:56:42 31-01-2020 > > >
Re: .NET Near Cache - new flag in NearCacheConfiguration.java?
Do you suggest to introduce it in general configuration? Why not introduce it only on platform side? Is there any .NET-specific configuration? Best Regards, Igor On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn wrote: > Igniters, > > I'm working on .NET Near Cache feature [1] > (storing deserialized cache entries in CLR memory to improve performance). > > Implementation is based on Java near cache, with some callbacks to .NET > side > for updating and invalidating cached entries. > > However, I'd like to make this feature optional: enabling Java near cache > should not > always enable .NET near cache - some users may have mixed clusters, etc. > > Therefore I'm adding NearCacheConfiguration#platformNearCacheEnabled > boolean flag. > Are there any objections or better ideas to configure this behavior? > > Thanks, > Pavel > > [1] https://issues.apache.org/jira/browse/IGNITE-12691 >
Re: Let's fix number of essential thread pools' threads in tests!
Hello! A single runAll of this code was 5h faster than regular master, in net time, but this might as well be measurement artifact. I will compare Run All Nightly which I have already started. Regards, -- Ilya Kasnacheev пн, 17 февр. 2020 г. в 18:04, Ivan Pavlukhin : > Ilya, > > > 5 is smallest viable number, I hope that TC suites will run slightly > > faster, produce less logs, and will be easier to debug (smaller batches > of > > threads to scroll) > > It would be quite interesting for me to measure this positive effect. > Is it possible? > > From a practical standpoint I suppose it is necessary to ensure that > everything is ok with nightly tests as well. > > Best regards, > Ivan Pavlukhin > > пн, 17 февр. 2020 г. в 15:00, Ilya Kasnacheev : > > > > Hello! > > > > I have created the following ticket: > > > > https://issues.apache.org/jira/browse/IGNITE-12663 > > > > Our current number of threads in pools is max(8, NCPU), this means, we > will > > see different behavior depending on hardware. > > > > I have adjusted GridAbstractTest so the default for most pools is 5, > > excluding striped, which is 8. > > > > 5 is smallest viable number, I hope that TC suites will run slightly > > faster, produce less logs, and will be easier to debug (smaller batches > of > > threads to scroll) > > > > Tests pass after fixing a single test. WDYT? > > > > Regards, > > -- > > Ilya Kasnacheev >
Re: Hello all
Hi, Alex, do you have any experience with Ignite itself? if no, I could suggest you to run cluster on a few nodes before development and run examples. What kind of Ignite tickets are you looking for? Core/SQL/ML/Tests/Docs/anything else? вт, 18 февр. 2020 г. в 14:20, Алексей Высотин : > Hello Ignite Community, > > My name is Alexey and I'm a Java and Scala developer with a current focus > on Big Data stack like Spark and Hadoop. > I would like to take part in the Apache Ignite project and make a > contribution to it. > > I'm thinking to start with some easy fix or bugfix to get more > acquainted with the code. > > Could someone give me access to Jira, please? So that I will be able to > book a ticket. > > > My Jira Username is Tesio. > > Thank you in advance. > > Best Regards, > > Alex Vysotin >
Hello all
Hello Ignite Community, My name is Alexey and I'm a Java and Scala developer with a current focus on Big Data stack like Spark and Hadoop. I would like to take part in the Apache Ignite project and make a contribution to it. I'm thinking to start with some easy fix or bugfix to get more acquainted with the code. Could someone give me access to Jira, please? So that I will be able to book a ticket. My Jira Username is Tesio. Thank you in advance. Best Regards, Alex Vysotin
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Igniters, I've prepared the issue [1] and PR [2] with removing @deprecate annotation on DataRegionMetrics and adding @IgniteExperimental to the new metrics API. Can anyone review my changes? [1] https://issues.apache.org/jira/browse/IGNITE-12690 [2] https://github.com/apache/ignite/pull/7440 On Tue, 18 Feb 2020 at 13:42, Ilya Kasnacheev wrote: > > Hello! > > I have just merged a fix for embarrassing issue where you could UPDATE > entries with Spring Data, but not "Update" or "update" them. > > I suggest adding this fix to the scope of 2.8, since Spring Data is popular > and it does not in any way affect code outside of its modules. > > https://issues.apache.org/jira/browse/IGNITE-12672 > > WDYT? > > Regards, > -- > Ilya Kasnacheev > > > пн, 17 февр. 2020 г. в 12:44, Maxim Muzafarov : > > > Alexey, > > > > > > Yes. I will remove @deprecation according to the vote results and will > > go further with the release steps [1] since there no blockers left. > > > > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > > > On Mon, 17 Feb 2020 at 11:48, Alexey Goncharuk > > wrote: > > > > > > Folks, > > > > > > I have merged IGNITE-12650 (mark MVCC as experimental) to master and > > > ignite-2.8. What's left? Should we remove deprecation from the old > > metrics > > > and start the vote? > >
[jira] [Created] (IGNITE-12694) A possible partition desync if last supplier has left and returned later.
Alexey Scherbakov created IGNITE-12694: -- Summary: A possible partition desync if last supplier has left and returned later. Key: IGNITE-12694 URL: https://issues.apache.org/jira/browse/IGNITE-12694 Project: Ignite Issue Type: Bug Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 2.9 Consider the scenario: Two nodes A and B in the grid. 1. B is rebalancing from A. 2. Before rebalancing is finished A has left, partitions on B have stale data. 3. A returns to the topology. Rebalancing will not start without manual intervention, because update counters for partitions will be same. This happens because LWM is assigned during PME before actual updates are loaded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello! I have just merged a fix for embarrassing issue where you could UPDATE entries with Spring Data, but not "Update" or "update" them. I suggest adding this fix to the scope of 2.8, since Spring Data is popular and it does not in any way affect code outside of its modules. https://issues.apache.org/jira/browse/IGNITE-12672 WDYT? Regards, -- Ilya Kasnacheev пн, 17 февр. 2020 г. в 12:44, Maxim Muzafarov : > Alexey, > > > Yes. I will remove @deprecation according to the vote results and will > go further with the release steps [1] since there no blockers left. > > > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Process > > On Mon, 17 Feb 2020 at 11:48, Alexey Goncharuk > wrote: > > > > Folks, > > > > I have merged IGNITE-12650 (mark MVCC as experimental) to master and > > ignite-2.8. What's left? Should we remove deprecation from the old > metrics > > and start the vote? >
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Hello, Alexey. > We need to agree whether IgniteMxBean#active(boolean) and > Ignite#active(boolean) behaving differently is ok from the user side. I think it’s not OK. We should provide consistent behavior for all management APIs: jmx, control.sh, REST, Java API. The primary use-case I keep in mind - third party management console written in java. It will use Java API and should have an ability to execute «safe»(without data vanish) and «unsafe» deactivation. > 18 февр. 2020 г., в 12:28, Alexey Goncharuk > написал(а): > > I do not think the change size can even be an argument for not doing a > proper improvement. We need to agree whether IgniteMxBean#active(boolean) > and Ignite#active(boolean) behaving differently is ok from the user side.
Re: Data vanished from cluster after INACTIVE/ACTIVE switch
I do not think the change size can even be an argument for not doing a proper improvement. We need to agree whether IgniteMxBean#active(boolean) and Ignite#active(boolean) behaving differently is ok from the user side.
Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Folks, Looks like we came to an agreement - rebalanceDelay and rebalanceOrder should be deprecated. Anyone else has objections ? чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov < alexey.scherbak...@gmail.com>: > But in combination with BLT it will work as intended - no rebalancing > under the cover. > > чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> Of course, stable topology will be just a hint. >> >> Any node can leave at any moment. >> >> чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov < >> alexey.scherbak...@gmail.com>: >> >>> 1. Yes >>> >>> 2. This is right but doesn't sound like a bug. The rebalancing will be >>> finished before releasing syncFut and partitions will contain all necessary >>> data (but are still in moving state). >>> >>> 3. No, local node doesn't wait the rebalancing on all grid nodes. >>> >>> Actually, I think SYNC mode should be dropped as well. Instead we must >>> provide the convenient public API to wait for "stable" topology. >>> >>> >>> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov : >>> Pavel, It's still a big question regarding SYNC rebalance mode. Here is my thoughts. 1. Yes, we must rebalance such caches prior to ASYNC one (if the rebalanceOrder configuration will be removed). 2. When persistence is enabled and when WAL is disabled (on the first rebalance start), I think we should finish syncFuture only on checkpoint like we are enabling the WAL state for cache group and simultaneously owning all MOVING partitions. But currently, I've seen that syncFuture finishes when there are no remaining partitions left [1]. Is it correct? Seems like a bug. 3. In my understanding, a new local node can start only when ALL SYNC cache groups have been fully rebalanced on ALL nodes, right? But how about late affinity assignment here? It seems that SYNC caches will be rebalanced locally on the node, the node will start, but other nodes still think this node is not operational (late affinity assignment not occurred yet). [1] https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1561 On Thu, 13 Feb 2020 at 12:57, Pavel Pereslegin wrote: > > > +1 to deprecate rebalanceOrder and remove related functionality, > Meant to "rework related functionality" not "remove". > > чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin : > > > > Hello, > > > > +1 to deprecate rebalanceOrder and remove related functionality, > > should we create a separate ticket for this? > > > > Btw, as I understand, SYNC mode is only useful for in-memory caches, > > because when persistence is enabled (and WAL is disabled during > > rebalancing), even "ignite-sys-cache" owns partitions only after all > > cache groups are rebalanced. Thus, even utility cache is still > > inoperable after node startup when persistence is enabled. Do we > > really need to wait for SYNC caches when a node starts with enabled > > persistence or should we enabled WAL for SYNC-caches? > > > > чт, 13 февр. 2020 г. в 11:13, Ivan Rakov : > > > > > > Hello, > > > > > > +1 from me for rebalance delay deprecation. > > > I can imagine only one actual case for this option: prevent excessive load > > > on the cluster in case of temporary short-term topology changes (e.g. node > > > is stopped for a while and then returned back). > > > Now it's handled by baseline auto adjustment in a much more correct way: > > > partitions are not reassigned within a maintenance interval (unlike with > > > the rebalance delay). > > > I also don't think that ability to configure rebalance delay per cache is > > > crucial. > > > > > > > rebalanceOrder is also useless, agreed. > > > +1 > > > Except for one case: we may want to rebalance caches with > > > CacheRebalanceMode.SYNC first. But anyway, this behavior doesn't require a > > > separate property to be enabled. > > > > > > On Wed, Feb 12, 2020 at 4:54 PM Alexei Scherbakov < > > > alexey.scherbak...@gmail.com> wrote: > > > > > > > Maxim, > > > > > > > > rebalanceDelay was introduced before the BLT appear in the product to solve > > > > scenarios which are now solved by BLT. > > > > > > > > It's pointless for me having it in the product since BLT was introduced. > > > > > > > > I do not think delaying rebalancing per cache group has any meaning. I > > > > cannot image any reason for it. > > > > > > > > rebalanceOrder is also useless, agreed. > > > > > > > > > > > > > > > > > > > > ср, 12 февр.
[jira] [Created] (IGNITE-12693) Incorrect operation of the eviction policy internal counter
Nikolai Kulagin created IGNITE-12693:
Summary: Incorrect operation of the eviction policy internal
counter
Key: IGNITE-12693
URL: https://issues.apache.org/jira/browse/IGNITE-12693
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Nikolai Kulagin
Attachments: EvictionPoliciesReproducer.java
When an entry is added to the cache, its size is added to the internal policy
counter. When the size of the internal counter exceeds the max, entries begin
to evict until the internal size is less than the maximum.
When deleting, the size of the entry is subtracted from the internal counter,
but since when deleting an element, only its key is most often indicated, only
the key size is subtracted. This way you can get the moment when the cache is
empty, but the size of the internal counter is not.
{code:java}
@Override public void onEntryAccessed(boolean rmv, EvictableEntry
entry) {
if (!rmv) {
...
else {
Object node = entry.removeMeta();
if (node != null) {
removeMeta(node);
memSize.add(-entry.size());
}
}
}
{code}
In the worst case, a situation is possible when an object added to an empty
cache is evicted, although it is much smaller than the maximum size.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
