Re: [DISCUSSION] Add additional 3rd party libraries to Ignite 3 Code style and practices

[Eduard Rakhmankulov]

Hi, Igniters!

I am really glad about the 140 symbol column limit.

But aside from possible vulnerabilities mentioned above I have other
concerns, which may affect some future users.

Micronaut is a rather popular framework. Are we planning some OSGI support
(or custom classloader magic) so users which have been already using
micronaut don't need to be bound to the version transitively inherited by
ignite dependencies?

On Thu, 19 May 2022 at 00:32, Andrey Gura  wrote:

> I personally don't support any additional 3rd party dependencies as
> well as I don't fully understand the value of autogenerated specs for
> REST endpoints. In my opinion we have another option: writing spec
> manually. This option doesn't require any of proposed dependencies and
> allow to avoid possible vulnerabilities. Of course at the cost of
> manual actions.
>
> I understand that my statement is arguable. So I'll just wait for
> opinions of other community members.
>
> On Mon, May 16, 2022 at 7:45 PM Aleksandr Pakhomov 
> wrote:
> >
> >
> > Hello, Igniters.
> >
> > I would like to start a discussion about Java Code Style Guide [1]
> changes that are going to be a part of IEP-87 [2] implementation. The set
> of libraries and frameworks that are going to be allowed to be used in
> production:
> > - Micronaut for REST Server [3]
> > - Swagger for Open API annotations [4]
> > - Micronaut serde for REST serialization [5]
> >
> > Any objections? Also, comments on IEP-87 are welcomed.
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> <
> https://cwiki.apache.org/confluence/display/IGNITE/Java+Code+Style+Guide#JavaCodeStyleGuide-2Using3rdpartylibraries
> >
> > [2]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> <
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Additionaldependencies
> >
> > [3] https://micronaut.io/docs /
> > [4] https://swagger.io 
> > [5]
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> <
> https://micronaut-projects.github.io/micronaut-serialization/snapshot/guide
> >/
>

Re: [DISCUSSION] @Nullable/@NotNull annotation usage in Ignite 3

[Eduard Rakhmankulov]

+1 for option No. 2.

On Fri, 17 Dec 2021 at 12:10, Maksim Timonin 
wrote:

> Hi!
>
> There is a pretty popular project NullAway [1] that checks code of a
> project in compile-time for possible NPE. AFAIK, it works only with the
> "@Nullable" annotation. I think we can try to add this check to Ignite2 and
> 3.
>
> But I wonder, whether smbd already tried to introduce this check? If not, I
> can try, WDYT?
>
> [1] https://github.com/uber/NullAway
>
> On Fri, Dec 17, 2021 at 9:04 AM ткаленко кирилл 
> wrote:
>
> > I'm for the second option.
> >
>

Re: [DISCUSSION] Add SystemRegionMetricsEnabled property on DataStorageConfiguration.

[Eduard Rakhmankulov]

Folks,

I have created a new ticket [1] for moving system-region-related-properties
to its own class.
I will be pleased with your feedback on this topic.

1. https://issues.apache.org/jira/browse/IGNITE-15998

On Tue, 2 Nov 2021 at 19:58, Eduard Rakhmankulov 
wrote:

> Hi, Andrey!
>
> Thank you for your reply.
>
> I had the same thought about special system-region-configuration-class,
> but then I discovered that we have 3 special regions:
> sysMemPlc, volatileDsMemPlc, metastoreMemPlc.
> *If we decide to provide a special type* for configuration, then should
> it be *one* type for all special regions but *different* instances, or
> should the user provide *one* instance of
> system-region-configuration-class, or maybe even *different* type for
> each special region?
>
> My heart aligns with the first option.
>
> Or maybe it is better to stick to the initial plan: only make new holes in
> *DataStorageConfiguration?*
>
> On Tue, 2 Nov 2021 at 17:40, Andrey Gura  wrote:
>
>> Hi,
>>
>> Your proposal is consistent with the current interface of
>> DataStorageConfiguration class, so I', okay with the proposed change.
>>
>> Alternatively, DataStorageConfiguration#systemDataRegionConfiguration
>> field could be introduced which could be DataRegionConfiguration type
>> or special SystemDataRegionConfiguration type in case if we want to
>> limit access to the system data region parameters.
>>
>> On Tue, Nov 2, 2021 at 2:42 PM Eduard Rakhmankulov 
>> wrote:
>> >
>> > Hello, Igniters!
>> >
>> > At the moment metrics on system region are disabled on node start.
>> > User-defined regions can be tuned to have enabled metrics via region
>> > configuration
>> >
>> (org.apache.ignite.configuration.DataRegionConfiguration#setMetricsEnabled)
>> > To enable metrics on system region users should use non-public API or
>> use
>> > deprecated JMX bean
>> > (org.apache.ignite.mxbean.DataRegionMetricsMXBean#enableMetrics) for it,
>> > which doesn't solve problem because it needs human attention when node
>> > restarts.
>> >
>> > I want to add a new property to
>> > *org.apache.ignite.configuration.DataStorageConfiguration* which
>> enables or
>> > disables collection of metrics on system region (aka sysMemPlc) on node
>> > start.
>> >
>> > API change
>> > add new public methods:
>> >
>> >1.
>> >
>> *org.apache.ignite.configuration.DataStorageConfiguration#isSystemRegionMetricsEnabled()*
>> >2.
>> >
>> *org.apache.ignite.configuration.DataStorageConfiguration#setSystemRegionMetricsEnabled(boolean)*
>> >
>> >
>> > WDYT?
>> > --
>> > Best regards, Eduard.
>>
>

Re: [DISCUSSION] Add SystemRegionMetricsEnabled property on DataStorageConfiguration.

[Eduard Rakhmankulov]

Hi, Andrey!

Thank you for your reply.

I had the same thought about special system-region-configuration-class, but
then I discovered that we have 3 special regions:
sysMemPlc, volatileDsMemPlc, metastoreMemPlc.
*If we decide to provide a special type* for configuration, then should it
be *one* type for all special regions but *different* instances, or should
the user provide *one* instance of system-region-configuration-class, or
maybe even *different* type for each special region?

My heart aligns with the first option.

Or maybe it is better to stick to the initial plan: only make new holes in
*DataStorageConfiguration?*

On Tue, 2 Nov 2021 at 17:40, Andrey Gura  wrote:

> Hi,
>
> Your proposal is consistent with the current interface of
> DataStorageConfiguration class, so I', okay with the proposed change.
>
> Alternatively, DataStorageConfiguration#systemDataRegionConfiguration
> field could be introduced which could be DataRegionConfiguration type
> or special SystemDataRegionConfiguration type in case if we want to
> limit access to the system data region parameters.
>
> On Tue, Nov 2, 2021 at 2:42 PM Eduard Rakhmankulov 
> wrote:
> >
> > Hello, Igniters!
> >
> > At the moment metrics on system region are disabled on node start.
> > User-defined regions can be tuned to have enabled metrics via region
> > configuration
> >
> (org.apache.ignite.configuration.DataRegionConfiguration#setMetricsEnabled)
> > To enable metrics on system region users should use non-public API or use
> > deprecated JMX bean
> > (org.apache.ignite.mxbean.DataRegionMetricsMXBean#enableMetrics) for it,
> > which doesn't solve problem because it needs human attention when node
> > restarts.
> >
> > I want to add a new property to
> > *org.apache.ignite.configuration.DataStorageConfiguration* which enables
> or
> > disables collection of metrics on system region (aka sysMemPlc) on node
> > start.
> >
> > API change
> > add new public methods:
> >
> >1.
> >
> *org.apache.ignite.configuration.DataStorageConfiguration#isSystemRegionMetricsEnabled()*
> >2.
> >
> *org.apache.ignite.configuration.DataStorageConfiguration#setSystemRegionMetricsEnabled(boolean)*
> >
> >
> > WDYT?
> > --
> > Best regards, Eduard.
>

[DISCUSSION] Add SystemRegionMetricsEnabled property on DataStorageConfiguration.

[Eduard Rakhmankulov]

Hello, Igniters!

At the moment metrics on system region are disabled on node start.
User-defined regions can be tuned to have enabled metrics via region
configuration
(org.apache.ignite.configuration.DataRegionConfiguration#setMetricsEnabled)
To enable metrics on system region users should use non-public API or use
deprecated JMX bean
(org.apache.ignite.mxbean.DataRegionMetricsMXBean#enableMetrics) for it,
which doesn't solve problem because it needs human attention when node
restarts.

I want to add a new property to
*org.apache.ignite.configuration.DataStorageConfiguration* which enables or
disables collection of metrics on system region (aka sysMemPlc) on node
start.

API change
add new public methods:

   1.
   
*org.apache.ignite.configuration.DataStorageConfiguration#isSystemRegionMetricsEnabled()*
   2.
   
*org.apache.ignite.configuration.DataStorageConfiguration#setSystemRegionMetricsEnabled(boolean)*


WDYT?
-- 
Best regards, Eduard.

IGNITE-15678

[Eduard Rakhmankulov]

Hello, Ivan!

You've committed https://issues.apache.org/jira/browse/IGNITE-15678
recently, but after that C++ suites on TC suffer constant timeout [1][2].
Could you investigate what can be done to optimize test execution time?


1.
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_WiPPlatformCCMakeWinX64Release?branch=%3Cdefault%3E&mode=builds
2.
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCWinX64Release?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds#all-projects
-- 
Best regards, Eduard.

Re: [DISCUSS] Custom service proxy context

[Eduard Rakhmankulov]

I am not aware .NET capabilities, but as I can see service must be
implemented in *java* and even if can't serialize other that Map on .NET
side, on java side we can wrap this map with provided TypedContext (context
should be convertible from map in this case).
That leads to a situation when Java can use TypedContext but other clients
can't. I believe that the majority of services users are using Java and it
should be taken in accordance.

P.S. I think it is possible to send plain objects from .NET context to
cluster.

Best regards, Ed

On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin  wrote:

> Hi, Eduard!
>
> Thanks for your feedback.
>
> The idea sounds very good, but don't forget about the platform services.
> For example, we may call Java service from .Net and vice-versa. I'm
> not sure if the context can be implemented as a custom class (instead
> of Map/Dictionary) in this case.
>
> пт, 8 окт. 2021 г. в 14:21, Eduard Rakhmankulov :
> >
> > Hi, Pavel
> >
> > Is it possible to provide type-safe API for ServiceProxyContext ?
> > I think constructions like int arg1 = ctx.attribute("arg1"); are error
> > prone.
> >
> > Can we make something like this :
> >
> > //Signature with two generic params which allow the compiler to check
> > if the service will be called with the wrong type context.
> >
> > public , CtxType> T
> > serviceProxyTyped(ClusterGroup prj, String name, Class
> > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> >
> > //new interface which services with scoped context should implement
> >
> > public interface ContextedWith {
> > T getCtx();
> > }
> >
> > // implementation can delegate to Map-like context or be POJO.
> > interface MyServiceContext {
> > int getArg1();
> > String getUserId();
> > }
> >
> > class MyService implements ContextedWith {
> > void doThings() {
> > MyServiceContext ctx = getCtx();
> >
> > System.out.println("ctx.getArg1() = " + ctx.getArg1());
> > }
> >
> > @Override public MyServiceContext getCtx() {
> > return ServiceProxyContext.current();
> > }
> > }
> >
> > WDYT?
> >
> > Best regards, Ed.
> >
> > On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin  wrote:
> >
> > > Hello Igniters!
> > >
> > > I want to implement a feature to support a custom "caller" context in
> > > ignite services (see example in ticket description [1]).
> > >
> > > Sometimes, when using Ignite services, it becomes necessary to pass
> > > custom parameters from the "request source" to the service. This is
> > > most commonly used to track the origin of a service call (user id,
> > > request id, session id eg see this user question [2]).
> > > At the moment, the only way to pass such parameters to a service is by
> > > adding argument(s) to all called methods of the service, which makes
> > > the code messy and also complicates development and maintenance.
> > >
> > > I propose letting the user set a custom context for the service proxy
> > > and implicitly pass that context to the methods being called. This
> > > function should not affect the execution of service methods in any way
> > > unless the user has specified a context.
> > >
> > > An example of using the proposed API [1].
> > > PoC (except thin clients) [3].
> > >
> > > WDYT?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-15572
> > > [2]
> > >
> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
> > > [3] https://github.com/apache/ignite/pull/9440
> > >
>

Re: [DISCUSS] Custom service proxy context

[Eduard Rakhmankulov]

Hi, Pavel

Is it possible to provide type-safe API for ServiceProxyContext ?
I think constructions like int arg1 = ctx.attribute("arg1"); are error
prone.

Can we make something like this :

//Signature with two generic params which allow the compiler to check
if the service will be called with the wrong type context.

public , CtxType> T
serviceProxyTyped(ClusterGroup prj, String name, Class
srvcCls, CtxType optCtx, boolean sticky, long timeout)

//new interface which services with scoped context should implement

public interface ContextedWith {
T getCtx();
}

// implementation can delegate to Map-like context or be POJO.
interface MyServiceContext {
int getArg1();
String getUserId();
}

class MyService implements ContextedWith {
void doThings() {
MyServiceContext ctx = getCtx();

System.out.println("ctx.getArg1() = " + ctx.getArg1());
}

@Override public MyServiceContext getCtx() {
return ServiceProxyContext.current();
}
}

WDYT?

Best regards, Ed.

On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin  wrote:

> Hello Igniters!
>
> I want to implement a feature to support a custom "caller" context in
> ignite services (see example in ticket description [1]).
>
> Sometimes, when using Ignite services, it becomes necessary to pass
> custom parameters from the "request source" to the service. This is
> most commonly used to track the origin of a service call (user id,
> request id, session id eg see this user question [2]).
> At the moment, the only way to pass such parameters to a service is by
> adding argument(s) to all called methods of the service, which makes
> the code messy and also complicates development and maintenance.
>
> I propose letting the user set a custom context for the service proxy
> and implicitly pass that context to the methods being called. This
> function should not affect the execution of service methods in any way
> unless the user has specified a context.
>
> An example of using the proposed API [1].
> PoC (except thin clients) [3].
>
> WDYT?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-15572
> [2]
> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
> [3] https://github.com/apache/ignite/pull/9440
>

Re: Running TCBot across a PR

[Eduard Rakhmankulov]

Hi Raymond!

Please try to `re-run possible blockers`, TCBot UI has that button on the
right top on your PR's page.

Usually one retry is enough, else need to investigate why tests are failing
(the ones TCBot has defined as possible blockers).
Check whether those tests are failing in master, in that case write about
it in JIRA ticket.

Best regards, Ed.

On Thu, 30 Sept 2021 at 00:45, Raymond Wilson 
wrote:

> Hi Pavel,
>
> Thanks for the direction.
>
> I created the account and have run the TCBot build and added the comment to
> the Jira ticket.
>
> There seem to be a lot of failing tests, though I suspect they are mostly
> flapping/unstable tests rather than failures due to the change in the PR,
> but the TCBot build has flagged four possible blockers. I'm not sure how to
> evaluate those in the context of the change...
>
> I have also noted you as a reviewer.
>
> Thanks,
> Raymond.
>
>
> On Wed, Sep 29, 2021 at 7:35 PM Pavel Tupitsyn 
> wrote:
>
> > Hi Raymond,
> >
> > 1. Please register an account on TeamCity (ci.ignite.apache.org), you'll
> > be
> > able to start builds right away.
> > 2. Login with the same credentials to
> https://mtcga.gridgain.com/prs.html
> > and schedule a build for your PR.
> >
> > See
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot
> > for more info.
> >
> > > I'm also not sure who to suggest for review in the Java K8s area.
> > I can do the review once the tests pass.
> >
> > Thanks,
> > Pavel
> >
> > On Wed, Sep 29, 2021 at 12:47 AM Raymond Wilson <
> > raymond_wil...@trimble.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I have created and actioned a Jira ticket (
> > > https://issues.apache.org/jira/browse/IGNITE-15602), and have a PR
> > raised
> > > from my fork to the main repo.
> > >
> > > I think I have checked all the boxes except for verifying TCBot is
> happy
> > > (per instruction below)
> > >
> > >  - [ ] The pull request has been checked by the Teamcity Bot and
> > >the `green visa` attached to the JIRA ticket (see [TC.Bot: Check
> PR](
> > > https://mtcga.gridgain.com/prs.html))
> > >
> > > However, I don't (think I have) access to TeamCity, so I'm not sure how
> > to
> > > complete that step.
> > >
> > > I'm also not sure who to suggest for review in the Java K8s area.
> > >
> > > Thanks,
> > > Raymond.
> > >
> > > --
> > > 
> > > Raymond Wilson
> > > Trimble Distinguished Engineer, Civil Construction Software (CCS)
> > > 11 Birmingham Drive | Christchurch, New Zealand
> > > raymond_wil...@trimble.com
> > >
> > > <
> > >
> >
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> > > >
> > >
> >
>
>
> --
> 
> Raymond Wilson
> Trimble Distinguished Engineer, Civil Construction Software (CCS)
> 11 Birmingham Drive | Christchurch, New Zealand
> raymond_wil...@trimble.com
>
> <
> https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch
> >
>

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Hello Stan!

Thank you for the discussion about this topic. I've created a new Jira
ticket and I am going to work on it.
Jira: https://issues.apache.org/jira/browse/IGNITE-14728.

On Fri, 14 May 2021 at 13:26, Stanislav Lukyanov 
wrote:

> Hi Eduard,
>
> I think IGNITE_PDS_WAL_REBALANCE_THRESHOLD needs to be kept for backwards
> compatibility.
>
> I suggest that it is used as a source of the default value for the new DMS
> property:
> 1. On node start (or perhaps on cluster activation?) the
> wal.rebalance.threshold DMS property is checked
> 2. If the wal.rebalance.threshold has no value,
> IGNITE_PDS_WAL_REBALANCE_THRESHOLD sys property is checked
> 3. If IGNITE_PDS_WAL_REBALANCE_THRESHOLD has a value, it is written to
> wal.rebalance.threshold
> 4. If IGNITE_PDS_WAL_REBALANCE_THRESHOLD, 500 is written to
> wal.rebalance.threshold
>
> IGNITE_PDS_WAL_REBALANCE_THRESHOLD should also be deprecated.
>
> Thanks,
> Stan
>
> > On 13 May 2021, at 14:43, Eduard Rakhmankulov 
> wrote:
> >
> > Hello!
> >
> > Further investigation has showed, that there is a boolean system property
> > which blocks mbean creation, therefore property management through JMX is
> > not a great idea.
> > I found control.sh utility feature that enables distributed property
> > management (--property (set | get | list) ).
> >
> > I propose adding a new distributed property `*wal.rebalance.threshold*`
> to
> > replace IGNITE_PDS_WAL_REBALANCE_THRESHOLD system property functionality
> > with the same default value (*500*).
> > Property management will be executed with control.sh.
> >
> > Please share your thoughts.
> >
> > On Wed, 12 May 2021 at 16:06, Eduard Rakhmankulov 
> > wrote:
> >
> >> Hi!
> >>
> >> I propose to add a new MBean linked to DMS that contains the property
> >> IGNITE_PDS_WAL_REBALANCE_THRESHOLD.
> >> That enables configuration through JMX.
> >>
> >> WDYT?
> >>
> >>
> >> On Tue, 11 May 2021 at 16:52, Eduard Rakhmankulov 
> >> wrote:
> >>
> >>> Hi Stanislav,
> >>>
> >>> I think this is an excellent idea to use distributed metastore.
> >>>
> >>> Should I leave system property for backward compatibility?
> >>>
> >>>
> >>> On Sun, 9 May 2021 at 19:04, Atri Sharma  wrote:
> >>>
> >>>> +1
> >>>>
> >>>> On Sun, 9 May 2021, 21:33 Stanislav Lukyanov,  >
> >>>> wrote:
> >>>>
> >>>>> Hi Eduard,
> >>>>>
> >>>>> I strongly believe that if a configuration option is cluster wide
> then
> >>>> it
> >>>>> belongs to distributed metastore and not to IgniteConfiguration.
> >>>>> This allows to get cluster-wide consistency guarantees and API for
> >>>> dynamic
> >>>>> change out of the box (need to teach the internals to re-read the
> >>>> property
> >>>>> from DMS every time of course).
> >>>>>
> >>>>> WDYT?
> >>>>>
> >>>>> Stan
> >>>>>
> >>>>>> On 6 May 2021, at 16:35, Eduard Rakhmankulov 
> >>>>> wrote:
> >>>>>>
> >>>>>> Some addition.
> >>>>>>
> >>>>>> I want to add configuration to
> >>>>>>
> >>>>>
> >>>>
> org.apache.ignite.configuration.DataStorageConfiguration#getDefaultWarmUpConfiguration#getP
> >>>>>> artitionWalRebalanceThreshold
> >>>>>> which will have same semantics as system property (number of entries
> >>>> in
> >>>>> WAL
> >>>>>> to trigger rebalance).
> >>>>>>
> >>>>>> On Thu, 6 May 2021 at 15:50, Eduard Rakhmankulov <
> >>>> erixon...@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hello, Igniters!
> >>>>>>>
> >>>>>>> I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
> >>>>>>> properties to IgniteConfiguration.
> >>>>>>> This configuration is effectively cluster-wide (because only the
> >>>>>>> coordinator's configuration matters when the heuristic with this
> >>>>> property
> >>>>>>> applies).
> >>>>>>>
> >>>>>>> It is easier to validate that we have the same configuration on all
> >>>>> nodes
> >>>>>>> than system property (in the case when another coordinator was
> >>>> elected).
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards, Eduard.
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> С уважением, Рахманкулов Э.Р.
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> С уважением, Рахманкулов Э.Р.
> >>>
> >>
> >>
> >> --
> >> Best regards, Eduard.
> >>
> >
> >
> > --
> > С уважением, Рахманкулов Э.Р.
>
>

-- 
С уважением, Рахманкулов Э.Р.

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Hello!

Further investigation has showed, that there is a boolean system property
which blocks mbean creation, therefore property management through JMX is
not a great idea.
I found control.sh utility feature that enables distributed property
management (--property (set | get | list) ).

I propose adding a new distributed property `*wal.rebalance.threshold*` to
replace IGNITE_PDS_WAL_REBALANCE_THRESHOLD system property functionality
with the same default value (*500*).
Property management will be executed with control.sh.

Please share your thoughts.

On Wed, 12 May 2021 at 16:06, Eduard Rakhmankulov 
wrote:

> Hi!
>
> I propose to add a new MBean linked to DMS that contains the property
> IGNITE_PDS_WAL_REBALANCE_THRESHOLD.
> That enables configuration through JMX.
>
> WDYT?
>
>
> On Tue, 11 May 2021 at 16:52, Eduard Rakhmankulov 
> wrote:
>
>> Hi Stanislav,
>>
>> I think this is an excellent idea to use distributed metastore.
>>
>> Should I leave system property for backward compatibility?
>>
>>
>> On Sun, 9 May 2021 at 19:04, Atri Sharma  wrote:
>>
>>> +1
>>>
>>> On Sun, 9 May 2021, 21:33 Stanislav Lukyanov, 
>>> wrote:
>>>
>>> > Hi Eduard,
>>> >
>>> > I strongly believe that if a configuration option is cluster wide then
>>> it
>>> > belongs to distributed metastore and not to IgniteConfiguration.
>>> > This allows to get cluster-wide consistency guarantees and API for
>>> dynamic
>>> > change out of the box (need to teach the internals to re-read the
>>> property
>>> > from DMS every time of course).
>>> >
>>> > WDYT?
>>> >
>>> > Stan
>>> >
>>> > > On 6 May 2021, at 16:35, Eduard Rakhmankulov 
>>> > wrote:
>>> > >
>>> > > Some addition.
>>> > >
>>> > > I want to add configuration to
>>> > >
>>> >
>>> org.apache.ignite.configuration.DataStorageConfiguration#getDefaultWarmUpConfiguration#getP
>>> > > artitionWalRebalanceThreshold
>>> > > which will have same semantics as system property (number of entries
>>> in
>>> > WAL
>>> > > to trigger rebalance).
>>> > >
>>> > > On Thu, 6 May 2021 at 15:50, Eduard Rakhmankulov <
>>> erixon...@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Hello, Igniters!
>>> > >>
>>> > >> I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
>>> > >> properties to IgniteConfiguration.
>>> > >> This configuration is effectively cluster-wide (because only the
>>> > >> coordinator's configuration matters when the heuristic with this
>>> > property
>>> > >> applies).
>>> > >>
>>> > >> It is easier to validate that we have the same configuration on all
>>> > nodes
>>> > >> than system property (in the case when another coordinator was
>>> elected).
>>> > >>
>>> > >> --
>>> > >> Best regards, Eduard.
>>> > >>
>>> > >
>>> > >
>>> > > --
>>> > > С уважением, Рахманкулов Э.Р.
>>> >
>>> >
>>>
>>
>>
>> --
>> С уважением, Рахманкулов Э.Р.
>>
>
>
> --
> Best regards, Eduard.
>


-- 
С уважением, Рахманкулов Э.Р.

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Hi!

I propose to add a new MBean linked to DMS that contains the property
IGNITE_PDS_WAL_REBALANCE_THRESHOLD.
That enables configuration through JMX.

WDYT?


On Tue, 11 May 2021 at 16:52, Eduard Rakhmankulov 
wrote:

> Hi Stanislav,
>
> I think this is an excellent idea to use distributed metastore.
>
> Should I leave system property for backward compatibility?
>
>
> On Sun, 9 May 2021 at 19:04, Atri Sharma  wrote:
>
>> +1
>>
>> On Sun, 9 May 2021, 21:33 Stanislav Lukyanov, 
>> wrote:
>>
>> > Hi Eduard,
>> >
>> > I strongly believe that if a configuration option is cluster wide then
>> it
>> > belongs to distributed metastore and not to IgniteConfiguration.
>> > This allows to get cluster-wide consistency guarantees and API for
>> dynamic
>> > change out of the box (need to teach the internals to re-read the
>> property
>> > from DMS every time of course).
>> >
>> > WDYT?
>> >
>> > Stan
>> >
>> > > On 6 May 2021, at 16:35, Eduard Rakhmankulov 
>> > wrote:
>> > >
>> > > Some addition.
>> > >
>> > > I want to add configuration to
>> > >
>> >
>> org.apache.ignite.configuration.DataStorageConfiguration#getDefaultWarmUpConfiguration#getP
>> > > artitionWalRebalanceThreshold
>> > > which will have same semantics as system property (number of entries
>> in
>> > WAL
>> > > to trigger rebalance).
>> > >
>> > > On Thu, 6 May 2021 at 15:50, Eduard Rakhmankulov > >
>> > > wrote:
>> > >
>> > >> Hello, Igniters!
>> > >>
>> > >> I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
>> > >> properties to IgniteConfiguration.
>> > >> This configuration is effectively cluster-wide (because only the
>> > >> coordinator's configuration matters when the heuristic with this
>> > property
>> > >> applies).
>> > >>
>> > >> It is easier to validate that we have the same configuration on all
>> > nodes
>> > >> than system property (in the case when another coordinator was
>> elected).
>> > >>
>> > >> --
>> > >> Best regards, Eduard.
>> > >>
>> > >
>> > >
>> > > --
>> > > С уважением, Рахманкулов Э.Р.
>> >
>> >
>>
>
>
> --
> С уважением, Рахманкулов Э.Р.
>


-- 
Best regards, Eduard.

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Hi Stanislav,

I think this is an excellent idea to use distributed metastore.

Should I leave system property for backward compatibility?


On Sun, 9 May 2021 at 19:04, Atri Sharma  wrote:

> +1
>
> On Sun, 9 May 2021, 21:33 Stanislav Lukyanov, 
> wrote:
>
> > Hi Eduard,
> >
> > I strongly believe that if a configuration option is cluster wide then it
> > belongs to distributed metastore and not to IgniteConfiguration.
> > This allows to get cluster-wide consistency guarantees and API for
> dynamic
> > change out of the box (need to teach the internals to re-read the
> property
> > from DMS every time of course).
> >
> > WDYT?
> >
> > Stan
> >
> > > On 6 May 2021, at 16:35, Eduard Rakhmankulov 
> > wrote:
> > >
> > > Some addition.
> > >
> > > I want to add configuration to
> > >
> >
> org.apache.ignite.configuration.DataStorageConfiguration#getDefaultWarmUpConfiguration#getP
> > > artitionWalRebalanceThreshold
> > > which will have same semantics as system property (number of entries in
> > WAL
> > > to trigger rebalance).
> > >
> > > On Thu, 6 May 2021 at 15:50, Eduard Rakhmankulov 
> > > wrote:
> > >
> > >> Hello, Igniters!
> > >>
> > >> I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
> > >> properties to IgniteConfiguration.
> > >> This configuration is effectively cluster-wide (because only the
> > >> coordinator's configuration matters when the heuristic with this
> > property
> > >> applies).
> > >>
> > >> It is easier to validate that we have the same configuration on all
> > nodes
> > >> than system property (in the case when another coordinator was
> elected).
> > >>
> > >> --
> > >> Best regards, Eduard.
> > >>
> > >
> > >
> > > --
> > > С уважением, Рахманкулов Э.Р.
> >
> >
>


-- 
С уважением, Рахманкулов Э.Р.

Re: Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Some addition.

I want to add configuration to
org.apache.ignite.configuration.DataStorageConfiguration#getDefaultWarmUpConfiguration#getP
artitionWalRebalanceThreshold
which will have same semantics as system property (number of entries in WAL
to trigger rebalance).

On Thu, 6 May 2021 at 15:50, Eduard Rakhmankulov 
wrote:

> Hello, Igniters!
>
> I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
> properties to IgniteConfiguration.
> This configuration is effectively cluster-wide (because only the
> coordinator's configuration matters when the heuristic with this property
> applies).
>
> It is easier to validate that we have the same configuration on all nodes
> than system property (in the case when another coordinator was elected).
>
> --
> Best regards, Eduard.
>


-- 
С уважением, Рахманкулов Э.Р.

Change IGNITE_PDS_WAL_REBALANCE_THRESHOLD from System property to Configuraton

[Eduard Rakhmankulov]

Hello, Igniters!

I suggest changing IGNITE_PDS_WAL_REBALANCE_THRESHOLD from system
properties to IgniteConfiguration.
This configuration is effectively cluster-wide (because only the
coordinator's configuration matters when the heuristic with this property
applies).

It is easier to validate that we have the same configuration on all nodes
than system property (in the case when another coordinator was elected).

-- 
Best regards, Eduard.

Re: Welcome letter

[Eduard Rakhmankulov]

Thank you so much!

On Fri, 16 Apr 2021, 18:15 Denis Magda,  wrote:

> Hi Eduard,
>
> Welcome to the community! I see that someone has already added you to the
> contributors' list in JIRA. Good luck, pick your ticket!
>
> -
> Denis
>
>
> On Thu, Apr 15, 2021 at 8:52 AM Eduard Rakhmankulov 
> wrote:
>
> > Hello Ignite Community!
> >
> > My name is Eduard. I want to contribute to Apache Ignite, my JIRA
> username
> > *erixon*.
> >
> > Thanks!
> >
> > --
> > Best regards, Eduard.
> >
>

welcome message

[Eduard Rakhmankulov]

Hello Ignite Community!

My name is Eduard. I want to contribute to Apache Ignite, my JIRA username
*erixon*.

Thanks!

-- 
Best regards, Eduard.

Welcome letter

[Eduard Rakhmankulov]

Hello Ignite Community!

My name is Eduard. I want to contribute to Apache Ignite, my JIRA username
*erixon*.

Thanks!

-- 
Best regards, Eduard.