Re: Joining in

[Ilya Kasnacheev]

Hello!

I have added you to contributors role.

Please make sure to read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 1 апр. 2021 г. в 16:27, Игорь Гусев :

>
> Hi all!
> I am Igor Gusev, and I am an experienced technical writer. I am learning
> in-memory processing technologies and would be glad to contribute to the
> community. Please give me access to Apache Ignite Jira.
> My JIRA ID is  igusev.
>
> Thanks in advance!
> Igor

Joining in

[Игорь Гусев]

Hi all!
I am Igor Gusev, and I am an experienced technical writer. I am learning 
in-memory processing technologies and would be glad to contribute to the 
community. Please give me access to Apache Ignite Jira.
My JIRA ID is  igusev.
 
Thanks in advance!
Igor

Re: Joining the community

[Denis Magda]

Hi Nikita,

Welcome to the community! We've been waiting for professionals like you for
a while ;)

Sharing extra resources:

   - Our documentation contribution process, you're welcome to suggest
   changes:
   https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
   - Our Slack channel, you can reach out to most of the contributors there
   if need to talk out any ticket 101:
   
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Collaborate#HowtoCollaborate-IgniteSlack


Please join in me and Maksim here, we already need your help:
https://issues.apache.org/jira/browse/IGNITE-13796

-
Denis


On Thu, Dec 3, 2020 at 11:22 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi Nikita,
>
> Welcome to the community! Any help with the documentation is extremely
> valuable.
>
> I've added you to the Contributors group in Jira - you should be able to
> assign tickets to yourself now.
>
> -Val
>
> On Thu, Dec 3, 2020 at 7:46 AM Никита Сафонов 
> wrote:
>
> > Hi everyone!
> > My name is Nikita Safonov, I am a professional technical writer. Since I
> am
> > familiar with in-memory processing technology and deeply interested in
> its
> > emerging nature, I would be glad to contribute to the community. I kindly
> > request to grant me access to the Apache Ignite JIRA.
> >
> > My JIRA ID is: nsafonov
> >
> >
> > Best regards,
> >
> > Nikita
> >
>

Re: Joining the community

[Valentin Kulichenko]

Hi Nikita,

Welcome to the community! Any help with the documentation is extremely
valuable.

I've added you to the Contributors group in Jira - you should be able to
assign tickets to yourself now.

-Val

On Thu, Dec 3, 2020 at 7:46 AM Никита Сафонов 
wrote:

> Hi everyone!
> My name is Nikita Safonov, I am a professional technical writer. Since I am
> familiar with in-memory processing technology and deeply interested in its
> emerging nature, I would be glad to contribute to the community. I kindly
> request to grant me access to the Apache Ignite JIRA.
>
> My JIRA ID is: nsafonov
>
>
> Best regards,
>
> Nikita
>

Joining the community

[Никита Сафонов]

Hi everyone!
My name is Nikita Safonov, I am a professional technical writer. Since I am
familiar with in-memory processing technology and deeply interested in its
emerging nature, I would be glad to contribute to the community. I kindly
request to grant me access to the Apache Ignite JIRA.

My JIRA ID is: nsafonov


Best regards,

Nikita

[jira] [Created] (IGNITE-13567) TcpDiscoverySpi: incorrect value of the joiningNodeClient flag for the joining client

[Amelchev Nikita (Jira)]

Amelchev Nikita created IGNITE-13567:


 Summary: TcpDiscoverySpi: incorrect value of the joiningNodeClient 
flag for the joining client
 Key: IGNITE-13567
 URL: https://issues.apache.org/jira/browse/IGNITE-13567
 Project: Ignite
  Issue Type: Bug
Reporter: Amelchev Nikita


The TcpDiscoverySpi sets incorrect value of the {{joiningNodeClient}} flag for 
the joining client:
- local client node on join gets {{false}}
- all nodes gets {{true}}

See {{DiscoverySpiDataExchange}} and {{DiscoveryDataBag#isJoiningNodeClient()}}.

In the ZookepeerSpi the flag is correct.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13346) “Joining persistence node to in-memory cluster couldn't be allowed” Verification is too strict

[YuJue Li (Jira)]

YuJue Li created IGNITE-13346:
-

 Summary: “Joining persistence node to in-memory cluster couldn't 
be allowed” Verification is too strict
 Key: IGNITE-13346
 URL: https://issues.apache.org/jira/browse/IGNITE-13346
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.8.1
Reporter: YuJue Li
 Fix For: 2.10


1.Start a node that turns on persistence and then activate

2.Start visor and connect to cluster

3.Stop the node and restart the node

4.the node start failer and the exception are as folloews:

Caused by: class org.apache.ignite.spi.IgniteSpiException: Joining persistence 
node to in-memory cluster couldn't be allowed due to baseline auto-adjust is 
enabled and timeout equal to 0

I think there may be problems with the verification logic here. There are two 
possible solutions:

1.Relax the restrictions and exclude the client nodes.

2.Point out the IP address corresponding to the in-memory cluster node, which 
is convenient for troubleshooting.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: i'm joining the community for contribution

[Ilya Kasnacheev]

Hello!

I have added you to contributors, You should now be able to assign that
issue to yourself.

Regards,
-- 
Ilya Kasnacheev


пн, 8 июн. 2020 г. в 18:43, Aleksey Kurinov :

> Hey, just wanted to add to my previous email
>
> could you please assign
> https://issues.apache.org/jira/browse/IGNITE-13040 task
> to me or advise some another task for beginners
> i can work with SQL, Spring related tasks
>
> -- Forwarded message -
> From: Aleksey Kurinov 
> Date: Mon, Jun 8, 2020 at 8:35 AM
> Subject: i'm joining the community for contribution
> To: 
>
>
> Hello
>
> I'm Aleksei Kurinov,
> Software Developer from Epam Systems company.
> I'd like to contribute to the Ignite project.
> I'm a java developer but never contributed to open source projects.
> I'd like to familiar with the process so for starting I'd prefer to work on
> some trivial task for beginners
> my Jira ID : Kurinov
> email: aleksey.kuri...@gmail.com
>
> thank you
> Aleksey
>

Fwd: i'm joining the community for contribution

[Aleksey Kurinov]

Hey, just wanted to add to my previous email

could you please assign
https://issues.apache.org/jira/browse/IGNITE-13040 task
to me or advise some another task for beginners
i can work with SQL, Spring related tasks

-- Forwarded message -
From: Aleksey Kurinov 
Date: Mon, Jun 8, 2020 at 8:35 AM
Subject: i'm joining the community for contribution
To: 


Hello

I'm Aleksei Kurinov,
Software Developer from Epam Systems company.
I'd like to contribute to the Ignite project.
I'm a java developer but never contributed to open source projects.
I'd like to familiar with the process so for starting I'd prefer to work on
some trivial task for beginners
my Jira ID : Kurinov
email: aleksey.kuri...@gmail.com

thank you
Aleksey

i'm joining the community for contribution

[Aleksey Kurinov]

Hello

I'm Aleksei Kurinov,
Software Developer from Epam Systems company.
I'd like to contribute to the Ignite project.
I'm a java developer but never contributed to open source projects.
I'd like to familiar with the process so for starting I'd prefer to work on
some trivial task for beginners
my Jira ID : Kurinov
email: aleksey.kuri...@gmail.com

thank you
Aleksey

[jira] [Created] (IGNITE-13054) Prevent nodes with stale data joining the active topology.

[Alexey Scherbakov (Jira)]

Alexey Scherbakov created IGNITE-13054:
--

 Summary: Prevent nodes with stale data joining the active topology.
 Key: IGNITE-13054
 URL: https://issues.apache.org/jira/browse/IGNITE-13054
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Scherbakov
 Fix For: 2.9


After IGNITE-13003 LOST state is preserved then nodes with lost data are 
retuned to topology after failure.

If resetting is performed on lesser topology, it's possible to get into 
sutiation where a node with most recent data is returned to active topology 
where some key already could be modified.

This should not be allowed because brings conflicting data into grid. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Joining Ignite ASF

[Ivan Pavlukhin]

Hello Semyon,

Welcome to Apache Ignite Community!

I added your account to the contributors list. Now you can assign
tickets to yourself. Do not hesitate to ask if you need any
assistance.

Please check this page out for commonly asked questions pertaining to
the contribution process https://ignite.apache.org/community/contribute.html
Consult "Pick a ticket" section if you have no ticket to start with.

Best regards,
Ivan Pavlukhin

пн, 6 апр. 2020 г. в 21:07, Данилов Семён :
>
> Hello!
> I would like to start contributing, could you please add me to contributors 
> list? My login for https://issues.apache.org/ is sdanilov.
>
> Kind regards,
> Semyon Danilov.

Joining Ignite ASF

[Данилов Семён]

Hello!
I would like to start contributing, could you please add me to contributors 
list? My login for https://issues.apache.org/ is sdanilov.
 
Kind regards,
Semyon Danilov.

Re: joining

[Prashant Rahulkar]

Hello Denis,
We are planning to migrate to Apache Ignite, we have created POC for our
system with Ignite and working well so want to contribute in development.

Thanks,
Prashant Rahulkar.

On Tue, 17 Dec 2019 at 01:25, Denis Magda  wrote:

> Prashant,
>
> What brought you to Ignite folks? Do you already use it internally and
> would like to improve contributing?
>
> -
> Denis
>
>
> On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar <
> prashantrahul...@gmail.com> wrote:
>
> > Hello  Dmitriy ,
> >
> > Thanks for your clarification, definitely our employee will contribute
> with
> > riEquaiton.com official mail id.
> >
> >
> > Thanks,
> > Prashant Rahulkar.
> >
> > On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:
> >
> > > Hi Prashant,
> > >
> > > Thank you for your interest in Apache Ignite. And I hope the Ignite
> > > community would be glad to work with new contributors.
> > >
> > > Just one note: A company can not contribute to an Apache project, but
> > your
> > > employee(s) can contribute as an individual. Similar is true for
> > > management, an employee can be a member of PMC, but the project is
> > managed
> > > not by companies but only by the project management committee.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar <
> > prashantrahul...@gmail.com
> > > >:
> > >
> > > > Hello Everyone,
> > > > I have started software firm in India, with complete motivation to
> > focus
> > > on
> > > > open source technologies, so as a part of company policy we will star
> > to
> > > > contribute in this project with our company name.
> > > >
> > > >
> > > > Thanks,
> > > > PrashantR.
> > > >
> > >
> >
> >
> > --
> > ~ Rahul
> >
>


-- 
~ Rahul

Re: joining

[Denis Magda]

Prashant,

What brought you to Ignite folks? Do you already use it internally and
would like to improve contributing?

-
Denis


On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar <
prashantrahul...@gmail.com> wrote:

> Hello  Dmitriy ,
>
> Thanks for your clarification, definitely our employee will contribute with
> riEquaiton.com official mail id.
>
>
> Thanks,
> Prashant Rahulkar.
>
> On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:
>
> > Hi Prashant,
> >
> > Thank you for your interest in Apache Ignite. And I hope the Ignite
> > community would be glad to work with new contributors.
> >
> > Just one note: A company can not contribute to an Apache project, but
> your
> > employee(s) can contribute as an individual. Similar is true for
> > management, an employee can be a member of PMC, but the project is
> managed
> > not by companies but only by the project management committee.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar <
> prashantrahul...@gmail.com
> > >:
> >
> > > Hello Everyone,
> > > I have started software firm in India, with complete motivation to
> focus
> > on
> > > open source technologies, so as a part of company policy we will star
> to
> > > contribute in this project with our company name.
> > >
> > >
> > > Thanks,
> > > PrashantR.
> > >
> >
>
>
> --
> ~ Rahul
>

Re: joining

[Prashant Rahulkar]

Hello  Dmitriy ,

Thanks for your clarification, definitely our employee will contribute with
riEquaiton.com official mail id.


Thanks,
Prashant Rahulkar.

On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov  wrote:

> Hi Prashant,
>
> Thank you for your interest in Apache Ignite. And I hope the Ignite
> community would be glad to work with new contributors.
>
> Just one note: A company can not contribute to an Apache project, but your
> employee(s) can contribute as an individual. Similar is true for
> management, an employee can be a member of PMC, but the project is managed
> not by companies but only by the project management committee.
>
> Sincerely,
> Dmitriy Pavlov
>
> сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar  >:
>
> > Hello Everyone,
> > I have started software firm in India, with complete motivation to focus
> on
> > open source technologies, so as a part of company policy we will star to
> > contribute in this project with our company name.
> >
> >
> > Thanks,
> > PrashantR.
> >
>


-- 
~ Rahul

Re: joining

[Dmitriy Pavlov]

Hi Prashant,

Thank you for your interest in Apache Ignite. And I hope the Ignite
community would be glad to work with new contributors.

Just one note: A company can not contribute to an Apache project, but your
employee(s) can contribute as an individual. Similar is true for
management, an employee can be a member of PMC, but the project is managed
not by companies but only by the project management committee.

Sincerely,
Dmitriy Pavlov

сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar :

> Hello Everyone,
> I have started software firm in India, with complete motivation to focus on
> open source technologies, so as a part of company policy we will star to
> contribute in this project with our company name.
>
>
> Thanks,
> PrashantR.
>

Re: joining

[Prashant Rahulkar]

Hello Everyone,
I have started software firm in India, with complete motivation to focus on
open source technologies, so as a part of company policy we will star to
contribute in this project with our company name.


Thanks,
PrashantR.

Re: joining

[Ilya Kasnacheev]

Hello again!

I have added you to Contributors, you may now assign tickets to yourself.

Please read
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 18:34, Ilya Kasnacheev :

> Hello!
>
> You will need to register on https://issues.apache.org/jira/ first.
>
> Please tell me when you do.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 12 дек. 2019 г. в 18:09, :
>
>> Hi Ilya,
>>
>> it’d be nice if it were rkoriakov
>>
>>
>>
>> Best regards,
>>
>> T-Systems RUS
>> Point of Production
>> Roman Koriakov
>> Software Developer
>> Kirova 11, Voronezh, Russia
>> Tel: + 7 473 200 15 30
>> E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
>> http://www.t-systems.com<http://www.t-systems.ru/>
>>
>>
>>
>> -Original Message-
>> From: Ilya Kasnacheev 
>> Sent: Thursday, December 12, 2019 5:25 PM
>> To: dev 
>> Subject: Re: joining
>>
>>
>>
>> Hello!
>>
>>
>>
>> I will need an Apache JIRA username to add you to contributors. Can you
>> provide it?
>>
>>
>>
>> Regards,
>>
>> --
>>
>> Ilya Kasnacheev
>>
>>
>>
>>
>>
>> чт, 12 дек. 2019 г. в 17:20, > roman.koria...@t-systems.com>>:
>>
>>
>>
>> > Hi everyone,
>>
>> > I'd like to participate in this  project!
>>
>> >
>>
>> > Best regards,
>>
>> >
>>
>> > T-Systems RUS
>>
>> > Point of Production
>>
>> > Roman Koriakov
>>
>> > Software Developer
>>
>> > Kirova 11, Voronezh, Russia
>>
>> > Tel: + 7 473 200 15 30
>>
>> > E-mail: roman.koria...@t-systems.com> roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com%
>> 3cmailto:roman.koria...@t-systems.com>>
>>
>> > http://www.t-systems.com<http://www.t-systems.ru/<
>> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>>
>> >
>>
>> >
>>
>

Re: joining

[Ilya Kasnacheev]

Hello!

You will need to register on https://issues.apache.org/jira/ first.

Please tell me when you do.

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 18:09, :

> Hi Ilya,
>
> it’d be nice if it were rkoriakov
>
>
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
> http://www.t-systems.com<http://www.t-systems.ru/>
>
>
>
> -Original Message-
> From: Ilya Kasnacheev 
> Sent: Thursday, December 12, 2019 5:25 PM
> To: dev 
> Subject: Re: joining
>
>
>
> Hello!
>
>
>
> I will need an Apache JIRA username to add you to contributors. Can you
> provide it?
>
>
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
>
>
>
>
> чт, 12 дек. 2019 г. в 17:20,  roman.koria...@t-systems.com>>:
>
>
>
> > Hi everyone,
>
> > I'd like to participate in this  project!
>
> >
>
> > Best regards,
>
> >
>
> > T-Systems RUS
>
> > Point of Production
>
> > Roman Koriakov
>
> > Software Developer
>
> > Kirova 11, Voronezh, Russia
>
> > Tel: + 7 473 200 15 30
>
> > E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com
> <mailto:roman.koria...@t-systems.com%3cmailto:roman.koria...@t-systems.com
> >>
>
> > http://www.t-systems.com<http://www.t-systems.ru/<
> http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>
> >
>
> >
>

RE: joining

[Roman.Koriakov]

Hi Ilya,

it’d be nice if it were rkoriakov



Best regards,

T-Systems RUS
Point of Production
Roman Koriakov
Software Developer
Kirova 11, Voronezh, Russia
Tel: + 7 473 200 15 30
E-mail: roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com>
http://www.t-systems.com<http://www.t-systems.ru/>



-Original Message-
From: Ilya Kasnacheev 
Sent: Thursday, December 12, 2019 5:25 PM
To: dev 
Subject: Re: joining



Hello!



I will need an Apache JIRA username to add you to contributors. Can you provide 
it?



Regards,

--

Ilya Kasnacheev





чт, 12 дек. 2019 г. в 17:20, 
mailto:roman.koria...@t-systems.com>>:



> Hi everyone,

> I'd like to participate in this  project!

>

> Best regards,

>

> T-Systems RUS

> Point of Production

> Roman Koriakov

> Software Developer

> Kirova 11, Voronezh, Russia

> Tel: + 7 473 200 15 30

> E-mail: 
> roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com<mailto:roman.koria...@t-systems.com%3cmailto:roman.koria...@t-systems.com>>

> http://www.t-systems.com<http://www.t-systems.ru/<http://www.t-systems.com%3chttp:/www.t-systems.ru/>>

>

>

Re: joining

[Ilya Kasnacheev]

Hello!

I will need an Apache JIRA username to add you to contributors. Can you
provide it?

Regards,
-- 
Ilya Kasnacheev


чт, 12 дек. 2019 г. в 17:20, :

> Hi everyone,
> I'd like to participate in this  project!
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com
> http://www.t-systems.com
>
>

joining

[Roman.Koriakov]

Hi everyone,
I'd like to participate in this  project!

Best regards,

T-Systems RUS
Point of Production
Roman Koriakov
Software Developer
Kirova 11, Voronezh, Russia
Tel: + 7 473 200 15 30
E-mail: roman.koria...@t-systems.com
http://www.t-systems.com

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail,

I looked into PR [1] and left a couple of minor comments on GitHub.
But actually a real thing where I do not have enough expertise is a
notification firing strategy. From the first glance looks fine, but
there might be concerns I missed.

[1] https://github.com/apache/ignite/pull/7057

ср, 4 дек. 2019 г. в 23:02, Mikhail Petrov :
>
> Ivan, Andrey, Nikolay,
>
> Thanks for your answers!
>
> Igniters, if there are no objections, could anyone take a look at
> implementation [1] of described above event, please?
>
> [1] https://github.com/apache/ignite/pull/7057
>
> Regards,
> Mikhail.
>
> On 04.12.2019 21:54, Ivan Pavlukhin wrote:
> > Mikhail,
> >
> > Yes I am fine with the approach.
> >
> > ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov :
> >> Ivan,
> >>
> >> Am I right, that current approach to solving this problem looks good for
> >> you?
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 03.12.2019 15:12, Ivan Pavlukhin wrote:
> >>> Mikhail,
> >>>
> >>> Yep, I see IgniteNodeValidationResult in new event in PR [1].
> >>>
> >>>> Discovery events such as (join/left/failed) are connected with a
> >>>> topology version change. In my case that not happens and may be
> >>>> misleading. That's why the new event type was chosen.
> >>> I did not mean that one of those events should be used. I meant that
> >>> it sounds natural to me to have an additional "unsuccessful node join"
> >>> event (like is done in PR[1]).
> >>>
> >>> https://github.com/apache/ignite/pull/7057/files
> >>>
> >>> вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov :
> >>>> Nikolay, Ivan,
> >>>>
> >>>> I understood the possible problem. It seems that it can be solved using
> >>>> EventStorageSpi which starts before DiscoveryManager.
> >>>>
> >>>> As for me, ClusterNode is enough. It contains all info about joining
> >>>> node including its attributes.
> >>>>
> >>>> Discovery events such as (join/left/failed) are connected with a
> >>>> topology version change. In my case that not happens and may be
> >>>> misleading. That's why the new event type was chosen.
> >>>>
> >>>> The cause of the failure is also presented in the event.
> >>>>
> >>>> Regards,
> >>>> Mikhail.
> >>>>
> >>>> On 03.12.2019 13:19, Николай Ижиков wrote:
> >>>>> Exception(s) from component(s) that don’t want node joined.
> >>>>>
> >>>>>> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin  
> >>>>>> написал(а):
> >>>>>>
> >>>>>> How that reason will look like? Actually, I mostly thinking about
> >>>>>> general API here. What I would like to avoid is exposing something not
> >>>>>> general but needed only for a particular extension (plugin).
> >>>>>>
> >>>>>> вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
> >>>>>>> I think we also should provide the reason why join failed.
> >>>>>>>
> >>>>>>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  
> >>>>>>>> написал(а):
> >>>>>>>>
> >>>>>>>> Mikhail,
> >>>>>>>>
> >>>>>>>> So, I suppose there should be ordering guarantees that listener is
> >>>>>>>> registered before first validation failure can occur. Hope
> >>>>>>>> GridComponent#onKernalStart is the right place. Is it enough to pass
> >>>>>>>> only problematic node id (or ClusterNode) with an event? Actually 
> >>>>>>>> such
> >>>>>>>> event seems to fit naturally node join/left/failed events.
> >>>>>>>>
> >>>>>>>> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
> >>>>>>>>> Hi Ivan.
> >>>>>>>>>
> >>>>>>>>> No other lifecycle events are needed in my case.
> >>>>>>>>>
> >>>>>>>>> We can register a listener in the security component's
> >>>>>>>>> GridComponent#onKernalStart method and listen locally to every 
> >>>>>>>

Re: Joining node validation failure event.

[Mikhail Petrov]

Ivan, Andrey, Nikolay,

Thanks for your answers!

Igniters, if there are no objections, could anyone take a look at 
implementation [1] of described above event, please?


[1] https://github.com/apache/ignite/pull/7057

Regards,
Mikhail.

On 04.12.2019 21:54, Ivan Pavlukhin wrote:

Mikhail,

Yes I am fine with the approach.

ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov :

Ivan,

Am I right, that current approach to solving this problem looks good for
you?

Regards,
Mikhail.

On 03.12.2019 15:12, Ivan Pavlukhin wrote:

Mikhail,

Yep, I see IgniteNodeValidationResult in new event in PR [1].


Discovery events such as (join/left/failed) are connected with a
topology version change. In my case that not happens and may be
misleading. That's why the new event type was chosen.

I did not mean that one of those events should be used. I meant that
it sounds natural to me to have an additional "unsuccessful node join"
event (like is done in PR[1]).

https://github.com/apache/ignite/pull/7057/files

вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov :

Nikolay, Ivan,

I understood the possible problem. It seems that it can be solved using
EventStorageSpi which starts before DiscoveryManager.

As for me, ClusterNode is enough. It contains all info about joining
node including its attributes.

Discovery events such as (join/left/failed) are connected with a
topology version change. In my case that not happens and may be
misleading. That's why the new event type was chosen.

The cause of the failure is also presented in the event.

Regards,
Mikhail.

On 03.12.2019 13:19, Николай Ижиков wrote:

Exception(s) from component(s) that don’t want node joined.


3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):

How that reason will look like? Actually, I mostly thinking about
general API here. What I would like to avoid is exposing something not
general but needed only for a particular extension (plugin).

вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :

I think we also should provide the reason why join failed.


3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):

Mikhail,

So, I suppose there should be ordering guarantees that listener is
registered before first validation failure can occur. Hope
GridComponent#onKernalStart is the right place. Is it enough to pass
only problematic node id (or ClusterNode) with an event? Actually such
event seems to fit naturally node join/left/failed events.

вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :

Hi Ivan.

No other lifecycle events are needed in my case.

We can register a listener in the security component's
GridComponent#onKernalStart method and listen locally to every failed
joining attempt. Am I missing something?

Regards,
Mikhail.

On 03.12.2019 8:48, Ivan Pavlukhin wrote:

Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :

Hi, Andrey.

It doesn't influence on authentication or authorization process. There
is a security requirement that demands to notify some outer security
subsystems in a specific way when joining node validation failed in any
Ignite component (e.g. GridCacheProcessor) not only in
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
acceptable for me.

Regards,
Mikhail.

On 02.12.2019 16:35, Andrey Gura wrote:

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
discovery components. I have no idea how to solve this problem without
publishing a new event too. But I'm concerned about the acceptance of
that solution. Maybe it can be solved some other way? I will appreciate
any suggestion or review PR [1] with event implementation.


[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 20

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail,

Yes I am fine with the approach.

ср, 4 дек. 2019 г. в 20:30, Mikhail Petrov :
>
> Ivan,
>
> Am I right, that current approach to solving this problem looks good for
> you?
>
> Regards,
> Mikhail.
>
> On 03.12.2019 15:12, Ivan Pavlukhin wrote:
> > Mikhail,
> >
> > Yep, I see IgniteNodeValidationResult in new event in PR [1].
> >
> >> Discovery events such as (join/left/failed) are connected with a
> >> topology version change. In my case that not happens and may be
> >> misleading. That's why the new event type was chosen.
> > I did not mean that one of those events should be used. I meant that
> > it sounds natural to me to have an additional "unsuccessful node join"
> > event (like is done in PR[1]).
> >
> > https://github.com/apache/ignite/pull/7057/files
> >
> > вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov :
> >> Nikolay, Ivan,
> >>
> >> I understood the possible problem. It seems that it can be solved using
> >> EventStorageSpi which starts before DiscoveryManager.
> >>
> >> As for me, ClusterNode is enough. It contains all info about joining
> >> node including its attributes.
> >>
> >> Discovery events such as (join/left/failed) are connected with a
> >> topology version change. In my case that not happens and may be
> >> misleading. That's why the new event type was chosen.
> >>
> >> The cause of the failure is also presented in the event.
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 03.12.2019 13:19, Николай Ижиков wrote:
> >>> Exception(s) from component(s) that don’t want node joined.
> >>>
> >>>> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):
> >>>>
> >>>> How that reason will look like? Actually, I mostly thinking about
> >>>> general API here. What I would like to avoid is exposing something not
> >>>> general but needed only for a particular extension (plugin).
> >>>>
> >>>> вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
> >>>>> I think we also should provide the reason why join failed.
> >>>>>
> >>>>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  
> >>>>>> написал(а):
> >>>>>>
> >>>>>> Mikhail,
> >>>>>>
> >>>>>> So, I suppose there should be ordering guarantees that listener is
> >>>>>> registered before first validation failure can occur. Hope
> >>>>>> GridComponent#onKernalStart is the right place. Is it enough to pass
> >>>>>> only problematic node id (or ClusterNode) with an event? Actually such
> >>>>>> event seems to fit naturally node join/left/failed events.
> >>>>>>
> >>>>>> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
> >>>>>>> Hi Ivan.
> >>>>>>>
> >>>>>>> No other lifecycle events are needed in my case.
> >>>>>>>
> >>>>>>> We can register a listener in the security component's
> >>>>>>> GridComponent#onKernalStart method and listen locally to every failed
> >>>>>>> joining attempt. Am I missing something?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Mikhail.
> >>>>>>>
> >>>>>>> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
> >>>>>>>> Mikhail,
> >>>>>>>>
> >>>>>>>> Do you need some ordering guarantees among node lifecycle events and
> >>>>>>>> listener notifications. For example, I can imagine that it is good to
> >>>>>>>> notify security component about every node failed validation. How can
> >>>>>>>> we achieve it with events (I assume dynamic listener registration)?
> >>>>>>>>
> >>>>>>>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
> >>>>>>>>> Hi, Andrey.
> >>>>>>>>>
> >>>>>>>>> It doesn't influence on authentication or authorization process. 
> >>>>>>>>> There
> >>>>>>>>> is a security requirement that demands to notify some outer security
> >>>>>>>>> subsystems in a specific wa

Re: Joining node validation failure event.

[Mikhail Petrov]

Ivan,

Am I right, that current approach to solving this problem looks good for 
you?


Regards,
Mikhail.

On 03.12.2019 15:12, Ivan Pavlukhin wrote:

Mikhail,

Yep, I see IgniteNodeValidationResult in new event in PR [1].


Discovery events such as (join/left/failed) are connected with a
topology version change. In my case that not happens and may be
misleading. That's why the new event type was chosen.

I did not mean that one of those events should be used. I meant that
it sounds natural to me to have an additional "unsuccessful node join"
event (like is done in PR[1]).

https://github.com/apache/ignite/pull/7057/files

вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov :

Nikolay, Ivan,

I understood the possible problem. It seems that it can be solved using
EventStorageSpi which starts before DiscoveryManager.

As for me, ClusterNode is enough. It contains all info about joining
node including its attributes.

Discovery events such as (join/left/failed) are connected with a
topology version change. In my case that not happens and may be
misleading. That's why the new event type was chosen.

The cause of the failure is also presented in the event.

Regards,
Mikhail.

On 03.12.2019 13:19, Николай Ижиков wrote:

Exception(s) from component(s) that don’t want node joined.


3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):

How that reason will look like? Actually, I mostly thinking about
general API here. What I would like to avoid is exposing something not
general but needed only for a particular extension (plugin).

вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :

I think we also should provide the reason why join failed.


3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):

Mikhail,

So, I suppose there should be ordering guarantees that listener is
registered before first validation failure can occur. Hope
GridComponent#onKernalStart is the right place. Is it enough to pass
only problematic node id (or ClusterNode) with an event? Actually such
event seems to fit naturally node join/left/failed events.

вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :

Hi Ivan.

No other lifecycle events are needed in my case.

We can register a listener in the security component's
GridComponent#onKernalStart method and listen locally to every failed
joining attempt. Am I missing something?

Regards,
Mikhail.

On 03.12.2019 8:48, Ivan Pavlukhin wrote:

Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :

Hi, Andrey.

It doesn't influence on authentication or authorization process. There
is a security requirement that demands to notify some outer security
subsystems in a specific way when joining node validation failed in any
Ignite component (e.g. GridCacheProcessor) not only in
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
acceptable for me.

Regards,
Mikhail.

On 02.12.2019 16:35, Andrey Gura wrote:

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
discovery components. I have no idea how to solve this problem without
publishing a new event too. But I'm concerned about the acceptance of
that solution. Maybe it can be solved some other way? I will appreciate
any suggestion or review PR [1] with event implementation.


[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem
I'm trying to solve is described below in the thread. The security
plugin in my case stores and analyzesinfo about a node that failed to join.


Regards,

Mikhail.



 Forwarded Message 
Subject:    Re: Joining node validation failure e

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail,

Yep, I see IgniteNodeValidationResult in new event in PR [1].

> Discovery events such as (join/left/failed) are connected with a
> topology version change. In my case that not happens and may be
> misleading. That's why the new event type was chosen.

I did not mean that one of those events should be used. I meant that
it sounds natural to me to have an additional "unsuccessful node join"
event (like is done in PR[1]).

https://github.com/apache/ignite/pull/7057/files

вт, 3 дек. 2019 г. в 14:32, Mikhail Petrov :
>
> Nikolay, Ivan,
>
> I understood the possible problem. It seems that it can be solved using
> EventStorageSpi which starts before DiscoveryManager.
>
> As for me, ClusterNode is enough. It contains all info about joining
> node including its attributes.
>
> Discovery events such as (join/left/failed) are connected with a
> topology version change. In my case that not happens and may be
> misleading. That's why the new event type was chosen.
>
> The cause of the failure is also presented in the event.
>
> Regards,
> Mikhail.
>
> On 03.12.2019 13:19, Николай Ижиков wrote:
> > Exception(s) from component(s) that don’t want node joined.
> >
> >> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):
> >>
> >> How that reason will look like? Actually, I mostly thinking about
> >> general API here. What I would like to avoid is exposing something not
> >> general but needed only for a particular extension (plugin).
> >>
> >> вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
> >>> I think we also should provide the reason why join failed.
> >>>
> >>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
> >>>>
> >>>> Mikhail,
> >>>>
> >>>> So, I suppose there should be ordering guarantees that listener is
> >>>> registered before first validation failure can occur. Hope
> >>>> GridComponent#onKernalStart is the right place. Is it enough to pass
> >>>> only problematic node id (or ClusterNode) with an event? Actually such
> >>>> event seems to fit naturally node join/left/failed events.
> >>>>
> >>>> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
> >>>>> Hi Ivan.
> >>>>>
> >>>>> No other lifecycle events are needed in my case.
> >>>>>
> >>>>> We can register a listener in the security component's
> >>>>> GridComponent#onKernalStart method and listen locally to every failed
> >>>>> joining attempt. Am I missing something?
> >>>>>
> >>>>> Regards,
> >>>>> Mikhail.
> >>>>>
> >>>>> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
> >>>>>> Mikhail,
> >>>>>>
> >>>>>> Do you need some ordering guarantees among node lifecycle events and
> >>>>>> listener notifications. For example, I can imagine that it is good to
> >>>>>> notify security component about every node failed validation. How can
> >>>>>> we achieve it with events (I assume dynamic listener registration)?
> >>>>>>
> >>>>>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
> >>>>>>> Hi, Andrey.
> >>>>>>>
> >>>>>>> It doesn't influence on authentication or authorization process. There
> >>>>>>> is a security requirement that demands to notify some outer security
> >>>>>>> subsystems in a specific way when joining node validation failed in 
> >>>>>>> any
> >>>>>>> Ignite component (e.g. GridCacheProcessor) not only in
> >>>>>>> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
> >>>>>>> acceptable for me.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Mikhail.
> >>>>>>>
> >>>>>>> On 02.12.2019 16:35, Andrey Gura wrote:
> >>>>>>>> Mikhail,
> >>>>>>>>
> >>>>>>>> I don't understand how node validation on join affects security. But
> >>>>>>>> it seems that you can use
> >>>>>>>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
> >>>>>>>> java.io.Serializable) method. Does it fit for your needs?
> >>>>>>>>

Re: Joining node validation failure event.

[Mikhail Petrov]

Nikolay, Ivan,

I understood the possible problem. It seems that it can be solved using 
EventStorageSpi which starts before DiscoveryManager.


As for me, ClusterNode is enough. It contains all info about joining 
node including its attributes.


Discovery events such as (join/left/failed) are connected with a 
topology version change. In my case that not happens and may be 
misleading. That's why the new event type was chosen.


The cause of the failure is also presented in the event.

Regards,
Mikhail.

On 03.12.2019 13:19, Николай Ижиков wrote:

Exception(s) from component(s) that don’t want node joined.


3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):

How that reason will look like? Actually, I mostly thinking about
general API here. What I would like to avoid is exposing something not
general but needed only for a particular extension (plugin).

вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :

I think we also should provide the reason why join failed.


3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):

Mikhail,

So, I suppose there should be ordering guarantees that listener is
registered before first validation failure can occur. Hope
GridComponent#onKernalStart is the right place. Is it enough to pass
only problematic node id (or ClusterNode) with an event? Actually such
event seems to fit naturally node join/left/failed events.

вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :

Hi Ivan.

No other lifecycle events are needed in my case.

We can register a listener in the security component's
GridComponent#onKernalStart method and listen locally to every failed
joining attempt. Am I missing something?

Regards,
Mikhail.

On 03.12.2019 8:48, Ivan Pavlukhin wrote:

Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :

Hi, Andrey.

It doesn't influence on authentication or authorization process. There
is a security requirement that demands to notify some outer security
subsystems in a specific way when joining node validation failed in any
Ignite component (e.g. GridCacheProcessor) not only in
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
acceptable for me.

Regards,
Mikhail.

On 02.12.2019 16:35, Andrey Gura wrote:

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
discovery components. I have no idea how to solve this problem without
publishing a new event too. But I'm concerned about the acceptance of
that solution. Maybe it can be solved some other way? I will appreciate
any suggestion or review PR [1] with event implementation.


[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem
I'm trying to solve is described below in the thread. The security
plugin in my case stores and analyzesinfo about a node that failed to join.


Regards,

Mikhail.



 Forwarded Message 
Subject:Re: Joining node validation failure event.
Date:   Thu, 21 Nov 2019 21:43:33 +0300
From:   Mikhail Petrov 
To: Andrey Gura 



Hi, Andrey.

In my task security plugin running on the coordinator must locally
handle the situation when some node is trying to join the topology with
the invalid configuration. I can't handle the response on a node that
failed to connect because it's untrusted.

Actually I'm only concerned about one validation -- when all Ignite
components validate new node.

In my case plugin must be able to obtain general and security subject
information from joining TcpDiscoveryNode attributes. But I have no idea
how to share information between the security and discovery components
without

Re: Joining node validation failure event.

[Николай Ижиков]

Exception(s) from component(s) that don’t want node joined.

> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin  написал(а):
> 
> How that reason will look like? Actually, I mostly thinking about
> general API here. What I would like to avoid is exposing something not
> general but needed only for a particular extension (plugin).
> 
> вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
>> 
>> I think we also should provide the reason why join failed.
>> 
>>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
>>> 
>>> Mikhail,
>>> 
>>> So, I suppose there should be ordering guarantees that listener is
>>> registered before first validation failure can occur. Hope
>>> GridComponent#onKernalStart is the right place. Is it enough to pass
>>> only problematic node id (or ClusterNode) with an event? Actually such
>>> event seems to fit naturally node join/left/failed events.
>>> 
>>> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
>>>> 
>>>> Hi Ivan.
>>>> 
>>>> No other lifecycle events are needed in my case.
>>>> 
>>>> We can register a listener in the security component's
>>>> GridComponent#onKernalStart method and listen locally to every failed
>>>> joining attempt. Am I missing something?
>>>> 
>>>> Regards,
>>>> Mikhail.
>>>> 
>>>> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
>>>>> Mikhail,
>>>>> 
>>>>> Do you need some ordering guarantees among node lifecycle events and
>>>>> listener notifications. For example, I can imagine that it is good to
>>>>> notify security component about every node failed validation. How can
>>>>> we achieve it with events (I assume dynamic listener registration)?
>>>>> 
>>>>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
>>>>>> Hi, Andrey.
>>>>>> 
>>>>>> It doesn't influence on authentication or authorization process. There
>>>>>> is a security requirement that demands to notify some outer security
>>>>>> subsystems in a specific way when joining node validation failed in any
>>>>>> Ignite component (e.g. GridCacheProcessor) not only in
>>>>>> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
>>>>>> acceptable for me.
>>>>>> 
>>>>>> Regards,
>>>>>> Mikhail.
>>>>>> 
>>>>>> On 02.12.2019 16:35, Andrey Gura wrote:
>>>>>>> Mikhail,
>>>>>>> 
>>>>>>> I don't understand how node validation on join affects security. But
>>>>>>> it seems that you can use
>>>>>>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
>>>>>>> java.io.Serializable) method. Does it fit for your needs?
>>>>>>> 
>>>>>>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  
>>>>>>> wrote:
>>>>>>>> Hi, Ivan.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Unfortunately, we came to no decision yet. As I mentioned above this
>>>>>>>> event is disabled by default and no node will receive this event 
>>>>>>>> without
>>>>>>>> an explicit subscription. In my case, that event is assumed to be used
>>>>>>>> on node locally to share joining node info between security and
>>>>>>>> discovery components. I have no idea how to solve this problem without
>>>>>>>> publishing a new event too. But I'm concerned about the acceptance of
>>>>>>>> that solution. Maybe it can be solved some other way? I will appreciate
>>>>>>>> any suggestion or review PR [1] with event implementation.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [1] https://github.com/apache/ignite/pull/7057
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> 
>>>>>>>> Mikhail.
>>>>>>>> 
>>>>>>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
>>>>>>>>> Mikhail, Andrey,
>>>>>>>>> 
>>>>>>>>> Have you come to a common decision here? As for me, it sounds useful
>

Re: Joining node validation failure event.

[Ivan Pavlukhin]

How that reason will look like? Actually, I mostly thinking about
general API here. What I would like to avoid is exposing something not
general but needed only for a particular extension (plugin).

вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
>
> I think we also should provide the reason why join failed.
>
> > 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
> >
> > Mikhail,
> >
> > So, I suppose there should be ordering guarantees that listener is
> > registered before first validation failure can occur. Hope
> > GridComponent#onKernalStart is the right place. Is it enough to pass
> > only problematic node id (or ClusterNode) with an event? Actually such
> > event seems to fit naturally node join/left/failed events.
> >
> > вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
> >>
> >> Hi Ivan.
> >>
> >> No other lifecycle events are needed in my case.
> >>
> >> We can register a listener in the security component's
> >> GridComponent#onKernalStart method and listen locally to every failed
> >> joining attempt. Am I missing something?
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
> >>> Mikhail,
> >>>
> >>> Do you need some ordering guarantees among node lifecycle events and
> >>> listener notifications. For example, I can imagine that it is good to
> >>> notify security component about every node failed validation. How can
> >>> we achieve it with events (I assume dynamic listener registration)?
> >>>
> >>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
> >>>> Hi, Andrey.
> >>>>
> >>>> It doesn't influence on authentication or authorization process. There
> >>>> is a security requirement that demands to notify some outer security
> >>>> subsystems in a specific way when joining node validation failed in any
> >>>> Ignite component (e.g. GridCacheProcessor) not only in
> >>>> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
> >>>> acceptable for me.
> >>>>
> >>>> Regards,
> >>>> Mikhail.
> >>>>
> >>>> On 02.12.2019 16:35, Andrey Gura wrote:
> >>>>> Mikhail,
> >>>>>
> >>>>> I don't understand how node validation on join affects security. But
> >>>>> it seems that you can use
> >>>>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
> >>>>> java.io.Serializable) method. Does it fit for your needs?
> >>>>>
> >>>>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  
> >>>>> wrote:
> >>>>>> Hi, Ivan.
> >>>>>>
> >>>>>>
> >>>>>> Unfortunately, we came to no decision yet. As I mentioned above this
> >>>>>> event is disabled by default and no node will receive this event 
> >>>>>> without
> >>>>>> an explicit subscription. In my case, that event is assumed to be used
> >>>>>> on node locally to share joining node info between security and
> >>>>>> discovery components. I have no idea how to solve this problem without
> >>>>>> publishing a new event too. But I'm concerned about the acceptance of
> >>>>>> that solution. Maybe it can be solved some other way? I will appreciate
> >>>>>> any suggestion or review PR [1] with event implementation.
> >>>>>>
> >>>>>>
> >>>>>> [1] https://github.com/apache/ignite/pull/7057
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Mikhail.
> >>>>>>
> >>>>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
> >>>>>>> Mikhail, Andrey,
> >>>>>>>
> >>>>>>> Have you come to a common decision here? As for me, it sounds useful
> >>>>>>> to expose node join failure details somehow. The thing to decide on is
> >>>>>>> a mechanism to expose it. Unfortunately, immediately have no idea
> >>>>>>> better than using events.
> >>>>>>>
> >>>>>>>> What is purpose of the special cluster wide event? Node is not joined
> >>>>>>>> to 

Re: Joining node validation failure event.

[Николай Ижиков]

I think we also should provide the reason why join failed.

> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin  написал(а):
> 
> Mikhail,
> 
> So, I suppose there should be ordering guarantees that listener is
> registered before first validation failure can occur. Hope
> GridComponent#onKernalStart is the right place. Is it enough to pass
> only problematic node id (or ClusterNode) with an event? Actually such
> event seems to fit naturally node join/left/failed events.
> 
> вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
>> 
>> Hi Ivan.
>> 
>> No other lifecycle events are needed in my case.
>> 
>> We can register a listener in the security component's
>> GridComponent#onKernalStart method and listen locally to every failed
>> joining attempt. Am I missing something?
>> 
>> Regards,
>> Mikhail.
>> 
>> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
>>> Mikhail,
>>> 
>>> Do you need some ordering guarantees among node lifecycle events and
>>> listener notifications. For example, I can imagine that it is good to
>>> notify security component about every node failed validation. How can
>>> we achieve it with events (I assume dynamic listener registration)?
>>> 
>>> пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
>>>> Hi, Andrey.
>>>> 
>>>> It doesn't influence on authentication or authorization process. There
>>>> is a security requirement that demands to notify some outer security
>>>> subsystems in a specific way when joining node validation failed in any
>>>> Ignite component (e.g. GridCacheProcessor) not only in
>>>> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
>>>> acceptable for me.
>>>> 
>>>> Regards,
>>>> Mikhail.
>>>> 
>>>> On 02.12.2019 16:35, Andrey Gura wrote:
>>>>> Mikhail,
>>>>> 
>>>>> I don't understand how node validation on join affects security. But
>>>>> it seems that you can use
>>>>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
>>>>> java.io.Serializable) method. Does it fit for your needs?
>>>>> 
>>>>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  
>>>>> wrote:
>>>>>> Hi, Ivan.
>>>>>> 
>>>>>> 
>>>>>> Unfortunately, we came to no decision yet. As I mentioned above this
>>>>>> event is disabled by default and no node will receive this event without
>>>>>> an explicit subscription. In my case, that event is assumed to be used
>>>>>> on node locally to share joining node info between security and
>>>>>> discovery components. I have no idea how to solve this problem without
>>>>>> publishing a new event too. But I'm concerned about the acceptance of
>>>>>> that solution. Maybe it can be solved some other way? I will appreciate
>>>>>> any suggestion or review PR [1] with event implementation.
>>>>>> 
>>>>>> 
>>>>>> [1] https://github.com/apache/ignite/pull/7057
>>>>>> 
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Mikhail.
>>>>>> 
>>>>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
>>>>>>> Mikhail, Andrey,
>>>>>>> 
>>>>>>> Have you come to a common decision here? As for me, it sounds useful
>>>>>>> to expose node join failure details somehow. The thing to decide on is
>>>>>>> a mechanism to expose it. Unfortunately, immediately have no idea
>>>>>>> better than using events.
>>>>>>> 
>>>>>>>> What is purpose of the special cluster wide event? Node is not joined
>>>>>>>> to the topology. Why topology nodes should know something about this
>>>>>>>> node?
>>>>>>> Was this question answered? I suppose that at least coordinator will
>>>>>>> receive the event, will not it?
>>>>>>> 
>>>>>>> чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :
>>>>>>>> Hi, Ivan.
>>>>>>>> 
>>>>>>>> I'm sorry that the discussion was moved in private channel. The problem
>>>>>>>> I'm trying to solve is described below in the thread. The security
>>>>>>>> p

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail,

So, I suppose there should be ordering guarantees that listener is
registered before first validation failure can occur. Hope
GridComponent#onKernalStart is the right place. Is it enough to pass
only problematic node id (or ClusterNode) with an event? Actually such
event seems to fit naturally node join/left/failed events.

вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov :
>
> Hi Ivan.
>
> No other lifecycle events are needed in my case.
>
> We can register a listener in the security component's
> GridComponent#onKernalStart method and listen locally to every failed
> joining attempt. Am I missing something?
>
> Regards,
> Mikhail.
>
> On 03.12.2019 8:48, Ivan Pavlukhin wrote:
> > Mikhail,
> >
> > Do you need some ordering guarantees among node lifecycle events and
> > listener notifications. For example, I can imagine that it is good to
> > notify security component about every node failed validation. How can
> > we achieve it with events (I assume dynamic listener registration)?
> >
> > пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
> >> Hi, Andrey.
> >>
> >> It doesn't influence on authentication or authorization process. There
> >> is a security requirement that demands to notify some outer security
> >> subsystems in a specific way when joining node validation failed in any
> >> Ignite component (e.g. GridCacheProcessor) not only in
> >> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
> >> acceptable for me.
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 02.12.2019 16:35, Andrey Gura wrote:
> >>> Mikhail,
> >>>
> >>> I don't understand how node validation on join affects security. But
> >>> it seems that you can use
> >>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
> >>> java.io.Serializable) method. Does it fit for your needs?
> >>>
> >>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  
> >>> wrote:
> >>>> Hi, Ivan.
> >>>>
> >>>>
> >>>> Unfortunately, we came to no decision yet. As I mentioned above this
> >>>> event is disabled by default and no node will receive this event without
> >>>> an explicit subscription. In my case, that event is assumed to be used
> >>>> on node locally to share joining node info between security and
> >>>> discovery components. I have no idea how to solve this problem without
> >>>> publishing a new event too. But I'm concerned about the acceptance of
> >>>> that solution. Maybe it can be solved some other way? I will appreciate
> >>>> any suggestion or review PR [1] with event implementation.
> >>>>
> >>>>
> >>>> [1] https://github.com/apache/ignite/pull/7057
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Mikhail.
> >>>>
> >>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
> >>>>> Mikhail, Andrey,
> >>>>>
> >>>>> Have you come to a common decision here? As for me, it sounds useful
> >>>>> to expose node join failure details somehow. The thing to decide on is
> >>>>> a mechanism to expose it. Unfortunately, immediately have no idea
> >>>>> better than using events.
> >>>>>
> >>>>>> What is purpose of the special cluster wide event? Node is not joined
> >>>>>> to the topology. Why topology nodes should know something about this
> >>>>>> node?
> >>>>> Was this question answered? I suppose that at least coordinator will
> >>>>> receive the event, will not it?
> >>>>>
> >>>>> чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :
> >>>>>> Hi, Ivan.
> >>>>>>
> >>>>>> I'm sorry that the discussion was moved in private channel. The problem
> >>>>>> I'm trying to solve is described below in the thread. The security
> >>>>>> plugin in my case stores and analyzesinfo about a node that failed to 
> >>>>>> join.
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> Mikhail.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>  Forwarded Message 
> >>>>&

Re: Joining node validation failure event.

[Mikhail Petrov]

Hi Ivan.

No other lifecycle events are needed in my case.

We can register a listener in the security component's 
GridComponent#onKernalStart method and listen locally to every failed 
joining attempt. Am I missing something?


Regards,
Mikhail.

On 03.12.2019 8:48, Ivan Pavlukhin wrote:

Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :

Hi, Andrey.

It doesn't influence on authentication or authorization process. There
is a security requirement that demands to notify some outer security
subsystems in a specific way when joining node validation failed in any
Ignite component (e.g. GridCacheProcessor) not only in
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
acceptable for me.

Regards,
Mikhail.

On 02.12.2019 16:35, Andrey Gura wrote:

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
discovery components. I have no idea how to solve this problem without
publishing a new event too. But I'm concerned about the acceptance of
that solution. Maybe it can be solved some other way? I will appreciate
any suggestion or review PR [1] with event implementation.


[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem
I'm trying to solve is described below in the thread. The security
plugin in my case stores and analyzesinfo about a node that failed to join.


Regards,

Mikhail.



 Forwarded Message 
Subject:Re: Joining node validation failure event.
Date:   Thu, 21 Nov 2019 21:43:33 +0300
From:   Mikhail Petrov 
To: Andrey Gura 



Hi, Andrey.

In my task security plugin running on the coordinator must locally
handle the situation when some node is trying to join the topology with
the invalid configuration. I can't handle the response on a node that
failed to connect because it's untrusted.

Actually I'm only concerned about one validation -- when all Ignite
components validate new node.

In my case plugin must be able to obtain general and security subject
information from joining TcpDiscoveryNode attributes. But I have no idea
how to share information between the security and discovery components
without recording event and listening it locally.

This event is assumed to be disable by default and in my case used only
on local node so it's not look like "cluster wide event".

Also I propose to record this event in dedicated utilityPool so it can't
stuck discovery thread.

I will appreciate any thoughts on this problem.

Regards,
Mikhail.

On 21.11.2019 19:40, Andrey Gura wrote:

Mikhail,

It is still not enough details to me. What is expected behavior if the
plugin?

There are a different validations during node join. Many of them
placed in RingMessageWorker#processJoinRequestMessage method. If
validation will fail then corresponding message will be sent to the
joining node (including TcpDiscoveryAuthFailedMessage) and node will
not joined to topology.

What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov 
wrote:

Hi, Andrey.

I take part in the development of a custom security plugin for Apache
Ignite. There is an information security requirement for which node
joining failures due to invalid configuration must be handled by the
plugin.

This is where my case comes from. Are there any objections to the
proposed approach?

Regards,
Mikhail.

On 20.11.2019 19:38, Andrey Gura wrote:

Hi, Mikhail!

Could you please describe the case for this

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail,

Do you need some ordering guarantees among node lifecycle events and
listener notifications. For example, I can imagine that it is good to
notify security component about every node failed validation. How can
we achieve it with events (I assume dynamic listener registration)?

пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov :
>
> Hi, Andrey.
>
> It doesn't influence on authentication or authorization process. There
> is a security requirement that demands to notify some outer security
> subsystems in a specific way when joining node validation failed in any
> Ignite component (e.g. GridCacheProcessor) not only in
> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not
> acceptable for me.
>
> Regards,
> Mikhail.
>
> On 02.12.2019 16:35, Andrey Gura wrote:
> > Mikhail,
> >
> > I don't understand how node validation on join affects security. But
> > it seems that you can use
> > PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
> > java.io.Serializable) method. Does it fit for your needs?
> >
> > On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  
> > wrote:
> >> Hi, Ivan.
> >>
> >>
> >> Unfortunately, we came to no decision yet. As I mentioned above this
> >> event is disabled by default and no node will receive this event without
> >> an explicit subscription. In my case, that event is assumed to be used
> >> on node locally to share joining node info between security and
> >> discovery components. I have no idea how to solve this problem without
> >> publishing a new event too. But I'm concerned about the acceptance of
> >> that solution. Maybe it can be solved some other way? I will appreciate
> >> any suggestion or review PR [1] with event implementation.
> >>
> >>
> >> [1] https://github.com/apache/ignite/pull/7057
> >>
> >>
> >> Regards,
> >>
> >> Mikhail.
> >>
> >> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
> >>> Mikhail, Andrey,
> >>>
> >>> Have you come to a common decision here? As for me, it sounds useful
> >>> to expose node join failure details somehow. The thing to decide on is
> >>> a mechanism to expose it. Unfortunately, immediately have no idea
> >>> better than using events.
> >>>
> >>>> What is purpose of the special cluster wide event? Node is not joined
> >>>> to the topology. Why topology nodes should know something about this
> >>>> node?
> >>> Was this question answered? I suppose that at least coordinator will
> >>> receive the event, will not it?
> >>>
> >>> чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :
> >>>> Hi, Ivan.
> >>>>
> >>>> I'm sorry that the discussion was moved in private channel. The problem
> >>>> I'm trying to solve is described below in the thread. The security
> >>>> plugin in my case stores and analyzesinfo about a node that failed to 
> >>>> join.
> >>>>
> >>>>
> >>>> Regards,
> >>>>
> >>>> Mikhail.
> >>>>
> >>>>
> >>>>
> >>>>  Forwarded Message 
> >>>> Subject:Re: Joining node validation failure event.
> >>>> Date:   Thu, 21 Nov 2019 21:43:33 +0300
> >>>> From:   Mikhail Petrov 
> >>>> To: Andrey Gura 
> >>>>
> >>>>
> >>>>
> >>>> Hi, Andrey.
> >>>>
> >>>> In my task security plugin running on the coordinator must locally
> >>>> handle the situation when some node is trying to join the topology with
> >>>> the invalid configuration. I can't handle the response on a node that
> >>>> failed to connect because it's untrusted.
> >>>>
> >>>> Actually I'm only concerned about one validation -- when all Ignite
> >>>> components validate new node.
> >>>>
> >>>> In my case plugin must be able to obtain general and security subject
> >>>> information from joining TcpDiscoveryNode attributes. But I have no idea
> >>>> how to share information between the security and discovery components
> >>>> without recording event and listening it locally.
> >>>>
> >>>> This event is assumed to be disable by default and in my case used only
> >>>> on local node so it's not look like "cluster

Re: Joining node validation failure event.

[Mikhail Petrov]

Hi, Andrey.

It doesn't influence on authentication or authorization process. There 
is a security requirement that demands to notify some outer security 
subsystems in a specific way when joining node validation failed in any 
Ignite component (e.g. GridCacheProcessor) not only in 
IgniteSecurityProcessor. So PluginProvider#validateNewNode is not 
acceptable for me.


Regards,
Mikhail.

On 02.12.2019 16:35, Andrey Gura wrote:

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this
event is disabled by default and no node will receive this event without
an explicit subscription. In my case, that event is assumed to be used
on node locally to share joining node info between security and
discovery components. I have no idea how to solve this problem without
publishing a new event too. But I'm concerned about the acceptance of
that solution. Maybe it can be solved some other way? I will appreciate
any suggestion or review PR [1] with event implementation.


[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem
I'm trying to solve is described below in the thread. The security
plugin in my case stores and analyzesinfo about a node that failed to join.


Regards,

Mikhail.



 Forwarded Message 
Subject:Re: Joining node validation failure event.
Date:   Thu, 21 Nov 2019 21:43:33 +0300
From:   Mikhail Petrov 
To: Andrey Gura 



Hi, Andrey.

In my task security plugin running on the coordinator must locally
handle the situation when some node is trying to join the topology with
the invalid configuration. I can't handle the response on a node that
failed to connect because it's untrusted.

Actually I'm only concerned about one validation -- when all Ignite
components validate new node.

In my case plugin must be able to obtain general and security subject
information from joining TcpDiscoveryNode attributes. But I have no idea
how to share information between the security and discovery components
without recording event and listening it locally.

This event is assumed to be disable by default and in my case used only
on local node so it's not look like "cluster wide event".

Also I propose to record this event in dedicated utilityPool so it can't
stuck discovery thread.

I will appreciate any thoughts on this problem.

Regards,
Mikhail.

On 21.11.2019 19:40, Andrey Gura wrote:

Mikhail,

It is still not enough details to me. What is expected behavior if the
plugin?

There are a different validations during node join. Many of them
placed in RingMessageWorker#processJoinRequestMessage method. If
validation will fail then corresponding message will be sent to the
joining node (including TcpDiscoveryAuthFailedMessage) and node will
not joined to topology.

What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov 
wrote:

Hi, Andrey.

I take part in the development of a custom security plugin for Apache
Ignite. There is an information security requirement for which node
joining failures due to invalid configuration must be handled by the
plugin.

This is where my case comes from. Are there any objections to the
proposed approach?

Regards,
Mikhail.

On 20.11.2019 19:38, Andrey Gura wrote:

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov
 wrote:

Hello, Igniters.

There is a case which requires to handle joining node validation
failure
in Ignite components and obtain information of the node that tried to
join and the reason for the failure. Now, as I see, there is no way to
do it. I propose to implement a new event -- NodeValidationFailedEvent
-- and record it in case the validation fails. I have created Tiket [1]
and PR [2], which shows an example of implementation. Could anyone take
a look at it, please?

[1] https://issues.apache.org/jira/browse/IGNITE-12380

[2] https://github.com/apa

Re: Joining node validation failure event.

[Andrey Gura]

Mikhail,

I don't understand how node validation on join affects security. But
it seems that you can use
PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode,
java.io.Serializable) method. Does it fit for your needs?

On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov  wrote:
>
> Hi, Ivan.
>
>
> Unfortunately, we came to no decision yet. As I mentioned above this
> event is disabled by default and no node will receive this event without
> an explicit subscription. In my case, that event is assumed to be used
> on node locally to share joining node info between security and
> discovery components. I have no idea how to solve this problem without
> publishing a new event too. But I'm concerned about the acceptance of
> that solution. Maybe it can be solved some other way? I will appreciate
> any suggestion or review PR [1] with event implementation.
>
>
> [1] https://github.com/apache/ignite/pull/7057
>
>
> Regards,
>
> Mikhail.
>
> On 02.12.2019 10:38, Ivan Pavlukhin wrote:
> > Mikhail, Andrey,
> >
> > Have you come to a common decision here? As for me, it sounds useful
> > to expose node join failure details somehow. The thing to decide on is
> > a mechanism to expose it. Unfortunately, immediately have no idea
> > better than using events.
> >
> >> What is purpose of the special cluster wide event? Node is not joined
> >> to the topology. Why topology nodes should know something about this
> >> node?
> > Was this question answered? I suppose that at least coordinator will
> > receive the event, will not it?
> >
> > чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :
> >> Hi, Ivan.
> >>
> >> I'm sorry that the discussion was moved in private channel. The problem
> >> I'm trying to solve is described below in the thread. The security
> >> plugin in my case stores and analyzesinfo about a node that failed to join.
> >>
> >>
> >> Regards,
> >>
> >> Mikhail.
> >>
> >>
> >>
> >>  Forwarded Message 
> >> Subject:Re: Joining node validation failure event.
> >> Date:   Thu, 21 Nov 2019 21:43:33 +0300
> >> From:   Mikhail Petrov 
> >> To: Andrey Gura 
> >>
> >>
> >>
> >> Hi, Andrey.
> >>
> >> In my task security plugin running on the coordinator must locally
> >> handle the situation when some node is trying to join the topology with
> >> the invalid configuration. I can't handle the response on a node that
> >> failed to connect because it's untrusted.
> >>
> >> Actually I'm only concerned about one validation -- when all Ignite
> >> components validate new node.
> >>
> >> In my case plugin must be able to obtain general and security subject
> >> information from joining TcpDiscoveryNode attributes. But I have no idea
> >> how to share information between the security and discovery components
> >> without recording event and listening it locally.
> >>
> >> This event is assumed to be disable by default and in my case used only
> >> on local node so it's not look like "cluster wide event".
> >>
> >> Also I propose to record this event in dedicated utilityPool so it can't
> >> stuck discovery thread.
> >>
> >> I will appreciate any thoughts on this problem.
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 21.11.2019 19:40, Andrey Gura wrote:
> >>> Mikhail,
> >>>
> >>> It is still not enough details to me. What is expected behavior if the
> >>> plugin?
> >>>
> >>> There are a different validations during node join. Many of them
> >>> placed in RingMessageWorker#processJoinRequestMessage method. If
> >>> validation will fail then corresponding message will be sent to the
> >>> joining node (including TcpDiscoveryAuthFailedMessage) and node will
> >>> not joined to topology.
> >>>
> >>> What is purpose of the special cluster wide event? Node is not joined
> >>> to the topology. Why topology nodes should know something about this
> >>> node?
> >>>
> >>> On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov 
> >>> wrote:
> >>>> Hi, Andrey.
> >>>>
> >>>> I take part in the development of a custom security plugin for Apache
> >>>> Ignite. There is an information security requirement for which node
> >>>> joining failures du

Re: Joining node validation failure event.

[Mikhail Petrov]

Hi, Ivan.


Unfortunately, we came to no decision yet. As I mentioned above this 
event is disabled by default and no node will receive this event without 
an explicit subscription. In my case, that event is assumed to be used 
on node locally to share joining node info between security and 
discovery components. I have no idea how to solve this problem without 
publishing a new event too. But I'm concerned about the acceptance of 
that solution. Maybe it can be solved some other way? I will appreciate 
any suggestion or review PR [1] with event implementation.



[1] https://github.com/apache/ignite/pull/7057


Regards,

Mikhail.

On 02.12.2019 10:38, Ivan Pavlukhin wrote:

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.


What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem
I'm trying to solve is described below in the thread. The security
plugin in my case stores and analyzesinfo about a node that failed to join.


Regards,

Mikhail.



 Forwarded Message 
Subject:Re: Joining node validation failure event.
Date:   Thu, 21 Nov 2019 21:43:33 +0300
From:   Mikhail Petrov 
To: Andrey Gura 



Hi, Andrey.

In my task security plugin running on the coordinator must locally
handle the situation when some node is trying to join the topology with
the invalid configuration. I can't handle the response on a node that
failed to connect because it's untrusted.

Actually I'm only concerned about one validation -- when all Ignite
components validate new node.

In my case plugin must be able to obtain general and security subject
information from joining TcpDiscoveryNode attributes. But I have no idea
how to share information between the security and discovery components
without recording event and listening it locally.

This event is assumed to be disable by default and in my case used only
on local node so it's not look like "cluster wide event".

Also I propose to record this event in dedicated utilityPool so it can't
stuck discovery thread.

I will appreciate any thoughts on this problem.

Regards,
Mikhail.

On 21.11.2019 19:40, Andrey Gura wrote:

Mikhail,

It is still not enough details to me. What is expected behavior if the
plugin?

There are a different validations during node join. Many of them
placed in RingMessageWorker#processJoinRequestMessage method. If
validation will fail then corresponding message will be sent to the
joining node (including TcpDiscoveryAuthFailedMessage) and node will
not joined to topology.

What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov 
wrote:

Hi, Andrey.

I take part in the development of a custom security plugin for Apache
Ignite. There is an information security requirement for which node
joining failures due to invalid configuration must be handled by the
plugin.

This is where my case comes from. Are there any objections to the
proposed approach?

Regards,
Mikhail.

On 20.11.2019 19:38, Andrey Gura wrote:

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov
 wrote:

Hello, Igniters.

There is a case which requires to handle joining node validation
failure
in Ignite components and obtain information of the node that tried to
join and the reason for the failure. Now, as I see, there is no way to
do it. I propose to implement a new event -- NodeValidationFailedEvent
-- and record it in case the validation fails. I have created Tiket [1]
and PR [2], which shows an example of implementation. Could anyone take
a look at it, please?

[1] https://issues.apache.org/jira/browse/IGNITE-12380

[2] https://github.com/apache/ignite/pull/7057

Re: Re: Joining node validation failure event.

[Ivan Pavlukhin]

Mikhail, Andrey,

Have you come to a common decision here? As for me, it sounds useful
to expose node join failure details somehow. The thing to decide on is
a mechanism to expose it. Unfortunately, immediately have no idea
better than using events.

> What is purpose of the special cluster wide event? Node is not joined
> to the topology. Why topology nodes should know something about this
> node?

Was this question answered? I suppose that at least coordinator will
receive the event, will not it?

чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov :
>
> Hi, Ivan.
>
> I'm sorry that the discussion was moved in private channel. The problem
> I'm trying to solve is described below in the thread. The security
> plugin in my case stores and analyzesinfo about a node that failed to join.
>
>
> Regards,
>
> Mikhail.
>
>
>
>  Forwarded Message 
> Subject:Re: Joining node validation failure event.
> Date:   Thu, 21 Nov 2019 21:43:33 +0300
> From:   Mikhail Petrov 
> To: Andrey Gura 
>
>
>
> Hi, Andrey.
>
> In my task security plugin running on the coordinator must locally
> handle the situation when some node is trying to join the topology with
> the invalid configuration. I can't handle the response on a node that
> failed to connect because it's untrusted.
>
> Actually I'm only concerned about one validation -- when all Ignite
> components validate new node.
>
> In my case plugin must be able to obtain general and security subject
> information from joining TcpDiscoveryNode attributes. But I have no idea
> how to share information between the security and discovery components
> without recording event and listening it locally.
>
> This event is assumed to be disable by default and in my case used only
> on local node so it's not look like "cluster wide event".
>
> Also I propose to record this event in dedicated utilityPool so it can't
> stuck discovery thread.
>
> I will appreciate any thoughts on this problem.
>
> Regards,
> Mikhail.
>
> On 21.11.2019 19:40, Andrey Gura wrote:
> > Mikhail,
> >
> > It is still not enough details to me. What is expected behavior if the
> > plugin?
> >
> > There are a different validations during node join. Many of them
> > placed in RingMessageWorker#processJoinRequestMessage method. If
> > validation will fail then corresponding message will be sent to the
> > joining node (including TcpDiscoveryAuthFailedMessage) and node will
> > not joined to topology.
> >
> > What is purpose of the special cluster wide event? Node is not joined
> > to the topology. Why topology nodes should know something about this
> > node?
> >
> > On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov 
> > wrote:
> >> Hi, Andrey.
> >>
> >> I take part in the development of a custom security plugin for Apache
> >> Ignite. There is an information security requirement for which node
> >> joining failures due to invalid configuration must be handled by the
> >> plugin.
> >>
> >> This is where my case comes from. Are there any objections to the
> >> proposed approach?
> >>
> >> Regards,
> >> Mikhail.
> >>
> >> On 20.11.2019 19:38, Andrey Gura wrote:
> >>> Hi, Mikhail!
> >>>
> >>> Could you please describe the case for this new event?
> >>>
> >>> On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov
> >>>  wrote:
> >>>> Hello, Igniters.
> >>>>
> >>>> There is a case which requires to handle joining node validation
> >>>> failure
> >>>> in Ignite components and obtain information of the node that tried to
> >>>> join and the reason for the failure. Now, as I see, there is no way to
> >>>> do it. I propose to implement a new event -- NodeValidationFailedEvent
> >>>> -- and record it in case the validation fails. I have created Tiket [1]
> >>>> and PR [2], which shows an example of implementation. Could anyone take
> >>>> a look at it, please?
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/IGNITE-12380
> >>>>
> >>>> [2] https://github.com/apache/ignite/pull/7057
> >>>>



-- 
Best regards,
Ivan Pavlukhin

Fwd: Re: Joining node validation failure event.

[Mikhail Petrov]

Hi, Ivan.

I'm sorry that the discussion was moved in private channel. The problem 
I'm trying to solve is described below in the thread. The security 
plugin in my case stores and analyzesinfo about a node that failed to join.



Regards,

Mikhail.



 Forwarded Message 
Subject:Re: Joining node validation failure event.
Date:   Thu, 21 Nov 2019 21:43:33 +0300
From:   Mikhail Petrov 
To: Andrey Gura 



Hi, Andrey.

In my task security plugin running on the coordinator must locally 
handle the situation when some node is trying to join the topology with 
the invalid configuration. I can't handle the response on a node that 
failed to connect because it's untrusted.


Actually I'm only concerned about one validation -- when all Ignite 
components validate new node.


In my case plugin must be able to obtain general and security subject 
information from joining TcpDiscoveryNode attributes. But I have no idea 
how to share information between the security and discovery components 
without recording event and listening it locally.


This event is assumed to be disable by default and in my case used only 
on local node so it's not look like "cluster wide event".


Also I propose to record this event in dedicated utilityPool so it can't 
stuck discovery thread.


I will appreciate any thoughts on this problem.

Regards,
Mikhail.

On 21.11.2019 19:40, Andrey Gura wrote:

Mikhail,

It is still not enough details to me. What is expected behavior if the 
plugin?


There are a different validations during node join. Many of them
placed in RingMessageWorker#processJoinRequestMessage method. If
validation will fail then corresponding message will be sent to the
joining node (including TcpDiscoveryAuthFailedMessage) and node will
not joined to topology.

What is purpose of the special cluster wide event? Node is not joined
to the topology. Why topology nodes should know something about this
node?

On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov  
wrote:

Hi, Andrey.

I take part in the development of a custom security plugin for Apache
Ignite. There is an information security requirement for which node
joining failures due to invalid configuration must be handled by the
plugin.

This is where my case comes from. Are there any objections to the
proposed approach?

Regards,
Mikhail.

On 20.11.2019 19:38, Andrey Gura wrote:

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov 
 wrote:

Hello, Igniters.

There is a case which requires to handle joining node validation 
failure

in Ignite components and obtain information of the node that tried to
join and the reason for the failure. Now, as I see, there is no way to
do it. I propose to implement a new event -- NodeValidationFailedEvent
-- and record it in case the validation fails. I have created Tiket [1]
and PR [2], which shows an example of implementation. Could anyone take
a look at it, please?

[1] https://issues.apache.org/jira/browse/IGNITE-12380

[2] https://github.com/apache/ignite/pull/7057

Re: Joining node validation failure event.

[Ivan Pavlukhin]

Hi Mikhail,

Interesting topic. Could you please shed some light how a node
validation failure can be handled? Immediately cannot imagine how one
can handle it.

чт, 21 нояб. 2019 г. в 14:17, Mikhail Petrov :
>
> Hi, Andrey.
>
> I take part in the development of a custom security plugin for Apache
> Ignite. There is an information security requirement for which node
> joining failures due to invalid configuration must be handled by the
> plugin.
>
> This is where my case comes from. Are there any objections to the
> proposed approach?
>
> Regards,
> Mikhail.
>
> On 20.11.2019 19:38, Andrey Gura wrote:
> > Hi, Mikhail!
> >
> > Could you please describe the case for this new event?
> >
> > On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov  
> > wrote:
> >> Hello, Igniters.
> >>
> >> There is a case which requires to handle joining node validation failure
> >> in Ignite components and obtain information of the node that tried to
> >> join and the reason for the failure. Now, as I see, there is no way to
> >> do it. I propose to implement a new event -- NodeValidationFailedEvent
> >> -- and record it in case the validation fails. I have created Tiket [1]
> >> and PR [2], which shows an example of implementation. Could anyone take
> >> a look at it, please?
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12380
> >>
> >> [2] https://github.com/apache/ignite/pull/7057
> >>



-- 
Best regards,
Ivan Pavlukhin

Re: Joining node validation failure event.

[Mikhail Petrov]

Hi, Andrey.

I take part in the development of a custom security plugin for Apache 
Ignite. There is an information security requirement for which node 
joining failures due to invalid configuration must be handled by the 
plugin.


This is where my case comes from. Are there any objections to the 
proposed approach?


Regards,
Mikhail.

On 20.11.2019 19:38, Andrey Gura wrote:

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov  wrote:

Hello, Igniters.

There is a case which requires to handle joining node validation failure
in Ignite components and obtain information of the node that tried to
join and the reason for the failure. Now, as I see, there is no way to
do it. I propose to implement a new event -- NodeValidationFailedEvent
-- and record it in case the validation fails. I have created Tiket [1]
and PR [2], which shows an example of implementation. Could anyone take
a look at it, please?

[1] https://issues.apache.org/jira/browse/IGNITE-12380

[2] https://github.com/apache/ignite/pull/7057

Re: Joining node validation failure event.

[Andrey Gura]

Hi, Mikhail!

Could you please describe the case for this new event?

On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov  wrote:
>
> Hello, Igniters.
>
> There is a case which requires to handle joining node validation failure
> in Ignite components and obtain information of the node that tried to
> join and the reason for the failure. Now, as I see, there is no way to
> do it. I propose to implement a new event -- NodeValidationFailedEvent
> -- and record it in case the validation fails. I have created Tiket [1]
> and PR [2], which shows an example of implementation. Could anyone take
> a look at it, please?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12380
>
> [2] https://github.com/apache/ignite/pull/7057
>

Joining node validation failure event.

[Mikhail Petrov]

Hello, Igniters.

There is a case which requires to handle joining node validation failure 
in Ignite components and obtain information of the node that tried to 
join and the reason for the failure. Now, as I see, there is no way to 
do it. I propose to implement a new event -- NodeValidationFailedEvent 
-- and record it in case the validation fails. I have created Tiket [1] 
and PR [2], which shows an example of implementation. Could anyone take 
a look at it, please?


[1] https://issues.apache.org/jira/browse/IGNITE-12380

[2] https://github.com/apache/ignite/pull/7057

[jira] [Created] (IGNITE-11852) Assertion errors when changing PME coordinator to locally joining node

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-11852:


 Summary: Assertion errors when changing PME coordinator to locally 
joining node
 Key: IGNITE-11852
 URL: https://issues.apache.org/jira/browse/IGNITE-11852
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.7, 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.8


When PME coordinator changed to locally joining node several assertion errors 
may occur:
1. When some other joining nodes finished PME:

{noformat}
[13:49:58] (err) Failed to notify listener: 
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1...@27296181java.lang.AssertionError:
 AffinityTopologyVersion [topVer=2, minorTopVer=0]
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1546)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1535)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1281)
at 
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10929)
at 
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10831)
at 
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10811)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1280)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onLocalJoin(CacheAffinitySharedManager.java:1535)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4189)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onBecomeCoordinator(GridDhtPartitionsExchangeFuture.java:4731)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$3400(GridDhtPartitionsExchangeFuture.java:145)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4622)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4611)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:466)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:281)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:143)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:44)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:455)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2731)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1917)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1300(GridCachePartitionExchangeManager.java:162

[jira] [Created] (IGNITE-11678) Forbidding joining persistence node to in-memory cluster

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-11678:
--

 Summary: Forbidding joining persistence node to in-memory cluster
 Key: IGNITE-11678
 URL: https://issues.apache.org/jira/browse/IGNITE-11678
 Project: Ignite
  Issue Type: Improvement
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Forbidding joining persistence node to in-memory cluster when baseline 
auto-adjust enabled and timeout equal to 0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11662) Wrong classloader is used to unmarshal joining node data

[Oleksii Mohylin (JIRA)]

Oleksii Mohylin created IGNITE-11662:


 Summary: Wrong classloader is used to unmarshal joining node data
 Key: IGNITE-11662
 URL: https://issues.apache.org/jira/browse/IGNITE-11662
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
 Environment: Ignite 2.7
Karaf 4.2.0


Reporter: Oleksii Mohylin


When a cluster coordinator node is running in Karaf container it cannot accept 
joining requests from other nodes. Problem lies in unability to unmarshal 
joining node data in 
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode()

This line
{code:java}
joiningNodeState = marsh.unmarshal((byte[]) discoData.joiningNodeData(), 
Thread.currentThread().getContextClassLoader());{code}
fails with
{noformat}
Error on unmarshalling discovery data from node 
10.0.2.15,127.0.0.1,172.17.0.1:47501: Failed to find class with given class 
loader for unmarshalling (make sure same versions of all classes are available 
on all nodes or enable peer-class-loading) 
[clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@5c0369c4, 
cls=org.apache.ignite.internal.processors.cluster.DiscoveryDataClusterState]; 
node is not allowed to join{noformat}
Apparently problem is wrong classloader returned by
{code:java}
Thread.currentThread().getContextClassLoader()){code}
which is not the one created in IgniteAbstractOsgiContextActivator.start().

*Proposed fix:* 

use proper way of obtaining classloader:
{code:java}
 U.resolveClassLoader(ctx.config()){code}
Like in other places. i.e. in GridClusterStateProcessor.collectGridNodeData().

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11521) Register listeners before joining the cluster

[Lukas Polacek (JIRA)]

Lukas Polacek created IGNITE-11521:
--

 Summary: Register listeners before joining the cluster
 Key: IGNITE-11521
 URL: https://issues.apache.org/jira/browse/IGNITE-11521
 Project: Ignite
  Issue Type: New Feature
Reporter: Lukas Polacek


The documentation says to register local listeners through 
"ignite.events().localListen(...)", however that can only be done once e.g. 
"ignite = Ignition.start(cfg)" has been called. At that point, the node has 
already joined the cluster, so we might have missed events in the meantime.

See also the discussion [in 
apache-ignite-users|http://apache-ignite-users.70518.x6.nabble.com/Register-listeners-before-joining-the-cluster-td25944.html#none].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10912) Huge node join request discovery message slows down node joining and corresponding PME

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-10912:
--

 Summary: Huge node join request discovery message slows down node 
joining and corresponding PME
 Key: IGNITE-10912
 URL: https://issues.apache.org/jira/browse/IGNITE-10912
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexei Scherbakov
 Fix For: 2.8


WIth large topology and large number of caches/groups node join message can 
reach a size > 30M due to a large amount of transferred discovery data.

It adds overhead on ring traversal and slows down "node join" PME.

Possible solution:
 # introduce pre-join message with discovery data which doesn't increment 
topology version. After all nodes wil have corressponding discovery data start 
actual joining. Discovery data probably should be stored off-heap(or even on 
disk) to avoid heap usage bursts on joining of multiple nodes.
 # Add compression to discovery data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9501) Exclude newly joining nodes from exchange latch

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-9501:
---

 Summary: Exclude newly joining nodes from exchange latch 
 Key: IGNITE-9501
 URL: https://issues.apache.org/jira/browse/IGNITE-9501
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.7


Currently, we're waiting for latch completion from newly joining nodes. 
However, such nodes don't have any updates to be synced on wait partitions 
release. Newly joining nodes may start their caches before exchange latch 
creation and this can delay exchange process.

We should explicitly ignore such nodes and don't include them into latch 
participants.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8897) Node with longer BaselineHistory joining the cluster causes cluster stopping

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8897:
---

 Summary: Node with longer BaselineHistory joining the cluster 
causes cluster stopping
 Key: IGNITE-8897
 URL: https://issues.apache.org/jira/browse/IGNITE-8897
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.7


There is no array index boundary check in code verifying BaselineHistory on new 
node join so it may end up with ArrayIndexOutOfBoundsException.

We need to check bltHistory size and if node joins with incorrect bltHistory we 
should refuse the join.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8423) Control utility may block when joining node is watiting for partition map exchange

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8423:


 Summary: Control utility may block when joining node is watiting 
for partition map exchange
 Key: IGNITE-8423
 URL: https://issues.apache.org/jira/browse/IGNITE-8423
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8372) Cluster metrics are reported incorrectly on joining node with ZK-based discovery

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8372:
---

 Summary: Cluster metrics are reported incorrectly on joining node 
with ZK-based discovery
 Key: IGNITE-8372
 URL: https://issues.apache.org/jira/browse/IGNITE-8372
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.5


When new node joins with ZK discovery it sometimes reports negative number of 
CPUs and incorrect heap size.
Message in log looks like this:

{noformat}
[myid:] - INFO  [disco-event-worker-#61:Log4JLogger@495] - Topology snapshot 
[ver=100, servers=100, clients=0, CPUs=-6, heap=0.5GB]
{noformat}

There is a race though between this report and ClusterMetricsUpdateMessage: if 
the node receives and process this message first which happens in a separate 
thread correct values are printed to log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8364) Propagate deployed services to joining nodes

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-8364:


 Summary: Propagate deployed services to joining nodes
 Key: IGNITE-8364
 URL: https://issues.apache.org/jira/browse/IGNITE-8364
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Mekhanikov


Joining nodes should receive information about service configurations and 
assignments in discovery data, and deploy services, assigned to them, 
automatically.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8193) Joining node data should be cleaned in some cases

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8193:
---

 Summary: Joining node data should be cleaned in some cases
 Key: IGNITE-8193
 URL: https://issues.apache.org/jira/browse/IGNITE-8193
 Project: Ignite
  Issue Type: Improvement
  Components: zookeeper
Reporter: Sergey Chugunov


ZookeeperDiscoveryImpl#startJoin method implementation creates two zk nodes: 
one with joining node discovery data and another one with joining node id.

If joining node fails in between its joining node data will be kept by 
ZooKeeper until explicit removal.
For now there is no mechanism implementing such removal but it should be 
implemented to cover this corner case.
It may be implemented in form of timer which removes joining node data with 
some significant timeout to avoid deleting joining data of alive nodes that are 
in the middle of join procedure (and, for instance, got frozen before creating 
alive zk node).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8006) Starting multiple caches inhibits exchange process on joining node

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8006:
-

 Summary: Starting multiple caches inhibits exchange process on 
joining node
 Key: IGNITE-8006
 URL: https://issues.apache.org/jira/browse/IGNITE-8006
 Project: Ignite
  Issue Type: Improvement
Reporter: Vladislav Pyatkov


In some cases when we starts multiple caches (over 2K caches), we can to got a 
stop on exchange when new node joining to the cluster.

Coordinator-node wait to receive a single message from all other nodes, but 
last node (which want to joining to the cluster) stopped on starting caches:

 

{noformat}

Stack trace
 at java.lang.Thread.dumpStack(Thread.java:1329)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1159)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1900)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1764)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:740)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:622)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2329)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:745)

{noformat}

 

that inhibits cluster exchange process, until all caches started on the last 
node.

 

We should to start caches in parallel threads or exclude the action from 
exchange init process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-7794:


 Summary: Marshaller mappings are not saved to disk on joining nodes
 Key: IGNITE-7794
 URL: https://issues.apache.org/jira/browse/IGNITE-7794
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Denis Mekhanikov
 Fix For: 2.5
 Attachments: GridMarshallerMappingConsistencyTest.java

Find attached test class.

When a node connects to a cluster, that already has some marshaller mappings, 
they are not saved to disk on the joining node. It may result in "Unknown pair" 
error, if a cluster has persistence enabled, and a nodes without needed 
mappings start and try to read persisted data.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3519: IGNITE-7693: Printing out session ids on joining ...

[shroman]

GitHub user shroman opened a pull request:

https://github.com/apache/ignite/pull/3519

IGNITE-7693: Printing out session ids on joining via ZookeeperDiscove…

…rySpi.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shroman/ignite IGNITE-7693

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3519.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3519


commit fce93839db7ddc303ca5ced3cb71e6603d4b1adc
Author: shroman <rshtykh@...>
Date:   2018-02-14T02:50:29Z

IGNITE-7693: Printing out session ids on joining via ZookeeperDiscoverySpi.




---

[jira] [Created] (IGNITE-7693) New node joining via ZookeeperDiscoverySpi should print out its ZooKeeper sessionId

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7693:
---

 Summary: New node joining via ZookeeperDiscoverySpi should print 
out its ZooKeeper sessionId
 Key: IGNITE-7693
 URL: https://issues.apache.org/jira/browse/IGNITE-7693
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


For now there is no way to match Ignite nodes joining to Ignite cluster with 
log entries in ZooKeeper nodes' logs.

In ZooKeeper logs there are entries like this:
{noformat}
myid:1] - INFO  [CommitProcessor:1:ZooKeeperServer@687] - Established session 
0x161575d88530007 with negotiated timeout 1 for client 
/:{noformat}
but it is hard to match them with Ignite nodes when there are several started 
on the same host.

If Ignite node prints out its session on join it makes correlating them with 
particular ZooKeeper instance much easier.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7137) Provide a way to switch off BaselineTopology validation of nodes joining the cluster

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7137:
---

 Summary: Provide a way to switch off BaselineTopology validation 
of nodes joining the cluster
 Key: IGNITE-7137
 URL: https://issues.apache.org/jira/browse/IGNITE-7137
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Reporter: Sergey Chugunov


In specific circumstances like split-brain user may need an ability to switch 
BaselineTopology validation off for a period of time when the cluster is 
assembling back.

To do so we need to provide an API to switch BaselineTopology validation on and 
off dynamically.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #3036: IGNITE-6916: node joining with enabled pds and em...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3036


---

[GitHub] ignite pull request #3036: IGNITE-6916: node joining with enabled pds and em...

[zstan]

GitHub user zstan opened a pull request:

https://github.com/apache/ignite/pull/3036

IGNITE-6916: node joining with enabled pds and empty disc space cause…

…s exchange to hang

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6916

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3036.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3036


commit 56d27cb452d64c493dfb00d72578fd49f321795c
Author: Evgeny Stanilovskiy <estanilovs...@gridgain.com>
Date:   2017-11-15T08:51:25Z

IGNITE-6916: node joining with enabled pds and empty disc space causes 
exchange to hang




---

[jira] [Created] (IGNITE-6916) A node joining with enabled persistence and empty disc space causes exchange to hang.

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-6916:
--

 Summary: A node joining with enabled persistence and empty disc 
space causes exchange to hang.
 Key: IGNITE-6916
 URL: https://issues.apache.org/jira/browse/IGNITE-6916
 Project: Ignite
  Issue Type: Bug
  Security Level: Public (Viewable by anyone)
  Components: persistence
Affects Versions: 2.4
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
 Fix For: 2.4


If no more free disk space occurs, while node joining cluster, it will be 
hanging.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6695) Validation of joining node data consistency WRT the same data in grid

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-6695:
---

 Summary: Validation of joining node data consistency WRT the same 
data in grid
 Key: IGNITE-6695
 URL: https://issues.apache.org/jira/browse/IGNITE-6695
 Project: Ignite
  Issue Type: New Feature
  Security Level: Public (Viewable by anyone)
  Components: persistence
Reporter: Sergey Chugunov


h2. Scenario
Consider the following simple scenario (persistence is active):
# Start nodes A and B, activate, add (K1, V1) to cache.
# Stop A; update K1 to (K1, V2) (only B is aware of update). Stop B.
# Start A, activate, update K1 to (K1, V3).
After that B joining the cluster will lead to ambiguity of K1 value.

Also even having BaselineTopology tracking history of cluster nodes activations 
won't help here as after #3 node B's history is compatible with node A's 
history.

h2. Description
When there is load of data updates and user turns off nodes one by one, it is 
important to start nodes back in the opposite order. Node turned off the last 
must be started first and so one.
If it is not the case, situations like described above may happen.

A mechanism to detect this scenarios and refuse to join nodes with potentially 
conflicting data is needed.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6321) Nodes joining to active cluster remain in inactive state

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-6321:
---

 Summary: Nodes joining to active cluster remain in inactive state
 Key: IGNITE-6321
 URL: https://issues.apache.org/jira/browse/IGNITE-6321
 Project: Ignite
  Issue Type: Sub-task
Reporter: Sergey Chugunov


h2. Use Case
After starting up and activating grid user may start more brand-new nodes that 
are enabled to join the grid.
However these nodes must remain in inactive state. Otherwise partitions may be 
rebalanced to them and on next grid restart auto activation feature will lead 
to some data being unavailable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5704) Do not allow cluster to be deactivated if the joining node does not complete start all components

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-5704:
--

 Summary: Do not allow cluster to be deactivated if the joining 
node does not complete start all components
 Key: IGNITE-5704
 URL: https://issues.apache.org/jira/browse/IGNITE-5704
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.0, 2.1
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin
Priority: Critical
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Joining

[Denis Magda]

Mandhir,

Click on “subscribe” reference that is in the dev list row and send a message 
to the address pop up:
https://ignite.apache.org/community/resources.html#mail-lists

-
Denis

> On May 4, 2017, at 7:20 AM, Mandhir Gidda  wrote:
> 
> SUBSCRIBE

Joining

[Mandhir Gidda]

SUBSCRIBE

Re: joining exchange

[Semyon Boikov]

To send message to coordinator we need establish new connection, it is
preferably to use existing connections. Actually we tested this approach,
and on large clusters (> 200 nodes) it did not give start time improvments.

Thanks

On Wed, Apr 26, 2017 at 1:06 PM, ALEKSEY KUZNETSOV  wrote:

> Hi, Igntrs!
> When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage
> to arbitrary node N1.
> If N1 is not coordinator, then it will resend to all nodes.
>
> Why doesn't N1 send the message directly to coordinator ?
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: joining exchange

[Dmitriy Setrakyan]

On Wed, Apr 26, 2017 at 1:06 PM, ALEKSEY KUZNETSOV <alkuznetsov...@gmail.com
> wrote:

> Hi, Igntrs!
> When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage
> to arbitrary node N1.
> If N1 is not coordinator, then it will resend to all nodes.
>
> Why doesn't N1 send the message directly to coordinator ?
>

It think that the joining node sends its join-request message to the IP
address that was provided by the IP Finder, possibly in the configuration.

--
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

joining exchange

[ALEKSEY KUZNETSOV]

Hi, Igntrs!
When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage
to arbitrary node N1.
If N1 is not coordinator, then it will resend to all nodes.

Why doesn't N1 send the message directly to coordinator ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-4679) Consistency checks and error tracking during node joining process

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4679:
---

 Summary: Consistency checks and error tracking during node joining 
process
 Key: IGNITE-4679
 URL: https://issues.apache.org/jira/browse/IGNITE-4679
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Sergey Chugunov


h2. Notes
Right now new node requesting to join cluster may receive reject because of 
failed security checks.

But it is possible that any *GridComponent* may have wrong configuration or 
internal state that could lead to cluster instability.

It is better to identify these situations as early as possible and fail joining 
process prohibiting poison nodes to join.

h2. Acceptance Criteria
# API for consistency checks is proposed and approved by community.
# BinaryMetadata cache validation is performed by coordinator. In case of any 
conflicts new node joining request is rejected.
# [Optionally] Security checks are migrated to common mechanism.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4638) Share current DDL schema and pending DDL operations with joining nodes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-4638:
---

 Summary: Share current DDL schema and pending DDL operations with 
joining nodes
 Key: IGNITE-4638
 URL: https://issues.apache.org/jira/browse/IGNITE-4638
 Project: Ignite
  Issue Type: Sub-task
  Components: SQL
Reporter: Vladimir Ozerov
 Fix For: 2.0


Design considerations:
1) Should be implemented through custom discovery data mechanism. 
2) Probably it makes sense to add version to every DDL change. E.g. (topVer + 
local coordinator ctr). It will help us to avoid duplicated operations in case 
of some unforseen races.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4448) Implement correct affinity validation on joining topology.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4448:
-

 Summary: Implement correct affinity validation on joining topology.
 Key: IGNITE-4448
 URL: https://issues.apache.org/jira/browse/IGNITE-4448
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2,0


Currently on joining a topology only affinity class name and partition number 
are checked between configurations of local and remote nodes.

This is not enough in case of configured backup filter and possible extension 
with primary filter and can lead to disastrous situations due to node 
misconfiguration.

We should implement something like {{AffinityValidator}} having signature as 
follows:

{noformat}
boolean validate(Affinity affinity)
{noformat}

Maybe it'll be useful for other grid objects as well, like 
{{CacheStore}},{{NodeFilter}}, etc.









--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4223) Joining node should fetch affinity for all caches using single message

[Semen Boikov (JIRA)]

Semen Boikov created IGNITE-4223:


 Summary: Joining node should fetch affinity for all caches using 
single message
 Key: IGNITE-4223
 URL: https://issues.apache.org/jira/browse/IGNITE-4223
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Semen Boikov
Assignee: Konstantin Dudkov
 Fix For: 2.0


Currently when new node joins cluster and 'late affinity assignment' mode is 
enabled it requests caches affinity using message per cache (see 
CacheAffinitySharedManager.fetchAffinityOnJoin). Actually in 'late affinity 
assignment' mode coordinator has affinity information for all caches, so single 
request can be sent to coordinator.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)