Re: [VOTE] Stop Maintenance of Ignite WebConsole

[Nikolay Izhikov]

+1

ср, 13 мая 2020 г., 07:35 Alexey Zinoviev :

> +1
>
> ср, 13 мая 2020 г., 5:52 Saikat Maitra :
>
> > +1
> >
> > Regards
> > Saikat
> >
> > On Tue, 12 May 2020 at 7:03 PM, Denis Magda  wrote:
> >
> > > Igniters,
> > >
> > > As it was discussed earlier [1], it feels like we abandoned the
> > development
> > > and maintenance of Ignite WebConsole. The users keep creating tickets
> for
> > > improvements and report issues, while the backlog only keeps growing
> with
> > > no reaction on our end.
> > >
> > > With this vote, we hope to put WebConsole's development and maintenance
> > on
> > > hold *officially* by moving it to a separate Ignite repository and
> > closing
> > > all WebConsole-related tickets with a proper maintenance
> discontinuation
> > > notice. That's a gentle phase-out. If anybody joins the community and
> > > decides to resurrect the project they will have a chance to do that.
> > > Otherwise, WebConsole ends up on a graveyard eventually.
> > >
> > > Please cast your vote:
> > > +1 - to discontinue Ignite WebConsole's development and maintenance by
> > > moving to a separate Ignite repository.
> > > -1 - against this course of action.
> > >
> > > I'll let this vote last for 7 days and close it on May 18th.
> > >
> > >
> > > [1]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-WebConsole-Deprecation-td47259.html
> > >
> > > -
> > > Denis
> > >
> >
>

Re: [VOTE] Stop Maintenance of Ignite WebConsole

[Alexey Zinoviev]

+1

ср, 13 мая 2020 г., 5:52 Saikat Maitra :

> +1
>
> Regards
> Saikat
>
> On Tue, 12 May 2020 at 7:03 PM, Denis Magda  wrote:
>
> > Igniters,
> >
> > As it was discussed earlier [1], it feels like we abandoned the
> development
> > and maintenance of Ignite WebConsole. The users keep creating tickets for
> > improvements and report issues, while the backlog only keeps growing with
> > no reaction on our end.
> >
> > With this vote, we hope to put WebConsole's development and maintenance
> on
> > hold *officially* by moving it to a separate Ignite repository and
> closing
> > all WebConsole-related tickets with a proper maintenance discontinuation
> > notice. That's a gentle phase-out. If anybody joins the community and
> > decides to resurrect the project they will have a chance to do that.
> > Otherwise, WebConsole ends up on a graveyard eventually.
> >
> > Please cast your vote:
> > +1 - to discontinue Ignite WebConsole's development and maintenance by
> > moving to a separate Ignite repository.
> > -1 - against this course of action.
> >
> > I'll let this vote last for 7 days and close it on May 18th.
> >
> >
> > [1]
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-WebConsole-Deprecation-td47259.html
> >
> > -
> > Denis
> >
>

Re: [VOTE] Stop Maintenance of Ignite WebConsole

[Saikat Maitra]

+1

Regards
Saikat

On Tue, 12 May 2020 at 7:03 PM, Denis Magda  wrote:

> Igniters,
>
> As it was discussed earlier [1], it feels like we abandoned the development
> and maintenance of Ignite WebConsole. The users keep creating tickets for
> improvements and report issues, while the backlog only keeps growing with
> no reaction on our end.
>
> With this vote, we hope to put WebConsole's development and maintenance on
> hold *officially* by moving it to a separate Ignite repository and closing
> all WebConsole-related tickets with a proper maintenance discontinuation
> notice. That's a gentle phase-out. If anybody joins the community and
> decides to resurrect the project they will have a chance to do that.
> Otherwise, WebConsole ends up on a graveyard eventually.
>
> Please cast your vote:
> +1 - to discontinue Ignite WebConsole's development and maintenance by
> moving to a separate Ignite repository.
> -1 - against this course of action.
>
> I'll let this vote last for 7 days and close it on May 18th.
>
>
> [1]
>
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-WebConsole-Deprecation-td47259.html
>
> -
> Denis
>

[VOTE] Stop Maintenance of Ignite WebConsole

[Denis Magda]

Igniters,

As it was discussed earlier [1], it feels like we abandoned the development
and maintenance of Ignite WebConsole. The users keep creating tickets for
improvements and report issues, while the backlog only keeps growing with
no reaction on our end.

With this vote, we hope to put WebConsole's development and maintenance on
hold *officially* by moving it to a separate Ignite repository and closing
all WebConsole-related tickets with a proper maintenance discontinuation
notice. That's a gentle phase-out. If anybody joins the community and
decides to resurrect the project they will have a chance to do that.
Otherwise, WebConsole ends up on a graveyard eventually.

Please cast your vote:
+1 - to discontinue Ignite WebConsole's development and maintenance by
moving to a separate Ignite repository.
-1 - against this course of action.

I'll let this vote last for 7 days and close it on May 18th.


[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-WebConsole-Deprecation-td47259.html

-
Denis

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Saikat Maitra]

Congratulations!!!

On Tue, 12 May 2020 at 2:05 PM, Vladimir Ozerov  wrote:

> Congratulations, Taras!
>
> Well deserved!
>
> вт, 12 мая 2020 г. в 20:27, Ivan Rakov :
>
> > Taras,
> >
> > Congratulations and welcome!
> >
> > On Tue, May 12, 2020 at 8:26 PM Denis Magda  wrote:
> >
> > > Taras,
> > >
> > > Welcome, that was long overdue on our part! Hope to see you soon among
> > the
> > > PMC group.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, May 12, 2020 at 9:09 AM Dmitriy Pavlov 
> > wrote:
> > >
> > > > Hello Ignite Community,
> > > >
> > > >
> > > >
> > > > The Project Management Committee (PMC) for Apache Ignite has invited
> > > Taras
> > > > Ledkov to become a committer and we are pleased to announce that he
> has
> > > > accepted.
> > > >
> > > >
> > > > Taras is an Ignite SQL veteran who knows in detail current Ignite -
> H2
> > > > integration and binary serialization, actively participates in JDBC
> and
> > > > thin client protocol development, he is eager to help users on the
> user
> > > > list within his area of expertise.
> > > >
> > > >
> > > >
> > > > Being a committer enables easier contribution to the project since
> > there
> > > is
> > > > no need to go via the patch submission process. This should enable
> > better
> > > > productivity.
> > > >
> > > >
> > > >
> > > > Taras, thank you for all your efforts, congratulations and welcome on
> > > > board!
> > > > .
> > > >
> > > >
> > > >
> > > > Best Regards,
> > > >
> > > > Dmitriy Pavlov
> > > >
> > > > on behalf of Apache Ignite PMC
> > > >
> > >
> >
>

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Vladimir Ozerov]

Congratulations, Taras!

Well deserved!

вт, 12 мая 2020 г. в 20:27, Ivan Rakov :

> Taras,
>
> Congratulations and welcome!
>
> On Tue, May 12, 2020 at 8:26 PM Denis Magda  wrote:
>
> > Taras,
> >
> > Welcome, that was long overdue on our part! Hope to see you soon among
> the
> > PMC group.
> >
> > -
> > Denis
> >
> >
> > On Tue, May 12, 2020 at 9:09 AM Dmitriy Pavlov 
> wrote:
> >
> > > Hello Ignite Community,
> > >
> > >
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited
> > Taras
> > > Ledkov to become a committer and we are pleased to announce that he has
> > > accepted.
> > >
> > >
> > > Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> > > integration and binary serialization, actively participates in JDBC and
> > > thin client protocol development, he is eager to help users on the user
> > > list within his area of expertise.
> > >
> > >
> > >
> > > Being a committer enables easier contribution to the project since
> there
> > is
> > > no need to go via the patch submission process. This should enable
> better
> > > productivity.
> > >
> > >
> > >
> > > Taras, thank you for all your efforts, congratulations and welcome on
> > > board!
> > > .
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Dmitriy Pavlov
> > >
> > > on behalf of Apache Ignite PMC
> > >
> >
>

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Ivan Rakov]

Taras,

Congratulations and welcome!

On Tue, May 12, 2020 at 8:26 PM Denis Magda  wrote:

> Taras,
>
> Welcome, that was long overdue on our part! Hope to see you soon among the
> PMC group.
>
> -
> Denis
>
>
> On Tue, May 12, 2020 at 9:09 AM Dmitriy Pavlov  wrote:
>
> > Hello Ignite Community,
> >
> >
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> Taras
> > Ledkov to become a committer and we are pleased to announce that he has
> > accepted.
> >
> >
> > Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> > integration and binary serialization, actively participates in JDBC and
> > thin client protocol development, he is eager to help users on the user
> > list within his area of expertise.
> >
> >
> >
> > Being a committer enables easier contribution to the project since there
> is
> > no need to go via the patch submission process. This should enable better
> > productivity.
> >
> >
> >
> > Taras, thank you for all your efforts, congratulations and welcome on
> > board!
> > .
> >
> >
> >
> > Best Regards,
> >
> > Dmitriy Pavlov
> >
> > on behalf of Apache Ignite PMC
> >
>

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Denis Magda]

Taras,

Welcome, that was long overdue on our part! Hope to see you soon among the
PMC group.

-
Denis


On Tue, May 12, 2020 at 9:09 AM Dmitriy Pavlov  wrote:

> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Taras
> Ledkov to become a committer and we are pleased to announce that he has
> accepted.
>
>
> Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> integration and binary serialization, actively participates in JDBC and
> thin client protocol development, he is eager to help users on the user
> list within his area of expertise.
>
>
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
>
>
> Taras, thank you for all your efforts, congratulations and welcome on
> board!
> .
>
>
>
> Best Regards,
>
> Dmitriy Pavlov
>
> on behalf of Apache Ignite PMC
>

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Andrey Mashenkov]

Congrats, Taras!

вт, 12 мая 2020 г., 19:09 Dmitriy Pavlov :

> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Taras
> Ledkov to become a committer and we are pleased to announce that he has
> accepted.
>
>
> Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> integration and binary serialization, actively participates in JDBC and
> thin client protocol development, he is eager to help users on the user
> list within his area of expertise.
>
>
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
>
>
> Taras, thank you for all your efforts, congratulations and welcome on
> board!
> .
>
>
>
> Best Regards,
>
> Dmitriy Pavlov
>
> on behalf of Apache Ignite PMC
>

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Ivan Pavlukhin]

Congratulations Taras! Hooray!

Best regards,
Ivan Pavlukhin

вт, 12 мая 2020 г. в 19:33, Roman Kondakov :
>
> Taras,
>
> congratulations! Keep it up!
>
>
> --
> Kind Regards
> Roman Kondakov
>
>
> On 12.05.2020 19:09, Dmitriy Pavlov wrote:
> > Hello Ignite Community,
> >
> >
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited Taras
> > Ledkov to become a committer and we are pleased to announce that he has
> > accepted.
> >
> >
> > Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> > integration and binary serialization, actively participates in JDBC and
> > thin client protocol development, he is eager to help users on the user
> > list within his area of expertise.
> >
> >
> >
> > Being a committer enables easier contribution to the project since there is
> > no need to go via the patch submission process. This should enable better
> > productivity.
> >
> >
> >
> > Taras, thank you for all your efforts, congratulations and welcome on board!
> > .
> >
> >
> >
> > Best Regards,
> >
> > Dmitriy Pavlov
> >
> > on behalf of Apache Ignite PMC
> >

Re: Discovery-based services deployment guarantees question

[Vyacheslav Daradur]

Hi Mikhail, proposed changes make sense to me.
I left some comments to the pr.
Thank you!

On Wed, May 6, 2020 at 2:28 PM Mikhail Petrov  wrote:

> Hello, Igniters.
>
> I am working on IGNITE-12894 - [1]. It seems that it has the root cause
> which is similar to the problem described in this thread.
>
> To solve these problems, I propose to change the behavior of the
> IgniteServiceProcessor#serviceTopology if the timeout argument is 0.
> At the moment, IgniteServiceProcessor#serviceTopology returns the
> topology immediately, regardless of whether it was initialized or not in
> this case. I propose to wait for the service topology to be initialized
> if the requested service is already registered on local node, but the
> full message was not received from the coordinator yet.
>
> So the final behavior of IgniteServices#serviceProxy() will be:
> 1. If the timeout is specified - it waits for the topology over a
> specified timeout even if the requested service was not registered yet.
> As in current implementation.
>
> 2. If the timeout is not specified - if service was not registered it
> fails immediately, else it is waiting for the topology initialization
> (full message from the coordinator) if needed.
>
> Here is PR with the implementation of the described proposal - [2].
>
> WDYT?
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-12894
> [2] - https://github.com/apache/ignite/pull/7771
>
> On 30.12.2019 13:03, Alexey Goncharuk wrote:
> > Agree, sounds like a plan, thanks for taking over!
> >
> > пн, 30 дек. 2019 г. в 13:00, Vyacheslav Daradur :
> >
> >> Alexey,
> >>
> >> I would not make it default in the current implementation.
> >>
> >> Waiting of proxies on non-deployment-initiator nodes should be
> >> improved - additional checks are required:
> >> 1) We should not wait if requested service has not been submitted to
> >> deploy (when there is no info about such service)
> >> 2) If service deployment failed - getting proxy should be failed or
> >> interrupted as well (do not wait for all available timeout)
> >>
> >> Let's schedule this improvement to next release, I'll try to find a
> >> time to implement it.
> >>
> >> What do you think?
> >>
> >> On Mon, Dec 30, 2019 at 12:05 PM Alexey Goncharuk
> >>  wrote:
> >>> Vyacheslav, thanks for the explanation, makes sense to me.
> >>>
> >>> I was thinking though, should we make the behavior with the timeout
> >> default
> >>> for all proxies?
> >>>
> >>> Just my opinion - I think for a user it would be hard to control which
> >> node
> >>> deploys the service, especially if multiple nodes deploy it
> concurrently.
> >>> Most likely users will end up always calling the second option of the
> >> proxy
> >>> (with the timeout), so, perhaps, make it default?
> >>>
> >>> вс, 29 дек. 2019 г. в 21:05, Vyacheslav Daradur :
> >>>
>  Alexey,
> 
>  I've prepared pr [1] to show our proxy invocation guarantees and to
>  avoid misunderstanding.
> 
>  Please, let me know if you think that we should improve our guaranties
>  in some cases.
> 
>  [1] https://github.com/apache/ignite/pull/7213
> 
>  On Tue, Dec 24, 2019 at 7:27 PM Vyacheslav Daradur <
> >> daradu...@gmail.com>
>  wrote:
> >> even the local deployment looks broken: if a compute job
> >> is sent to a remote node after the service deployment
> > This is a different case and covered by retries:
> > * If you deploy a service from node A to node B, then take a proxy
> > from node A (deployment initiator) it should NOT fail even if node B
> > has not received yet a message that deployment finished successfully,
> > because of proxy invocation retries.
> >
> > Look like It's better to describe all these cases on the wiki.
> >
> >> Should we schedule this ticket for the further work on Services
> >> IEP?
> > If it is a frequent use-case we definitely should implement it.
> >
> >
> > On Tue, Dec 24, 2019 at 6:55 PM Alexey Goncharuk
> >  wrote:
> >> Ok, got it.
> >>
> >> I agree that this is consistent with the old behavior, but this is
> >> the
>  kind
> >> of errors we wanted to get rid of when we started the IEP. From the
> >> user perspective, even the local deployment looks broken: if a
> >> compute
>  job
> >> is sent to a remote node after the service deployment, the job
>  execution
> >> may fail due to this error.
> >>
> >> Should we schedule this ticket for the further work on Services
> >> IEP?
> >> вт, 24 дек. 2019 г. в 18:49, Vyacheslav Daradur <
> >> daradu...@gmail.com>:
> >>> Not sure that "user fallback" is the right definition, it is not
> >> new
> >>> behaviour in comparison with legacy implementation.
> >>>
> >>> Our synchronous deployment provides guaranties for a deployment
> >>> initiator to be able to start work with service immediately after
> >>> deployment finished successfully.
> >>> For not 

Re: [ANNOUNCE] New Committer: Taras Ledkov

[Roman Kondakov]

Taras,

congratulations! Keep it up!


-- 
Kind Regards
Roman Kondakov


On 12.05.2020 19:09, Dmitriy Pavlov wrote:
> Hello Ignite Community,
> 
> 
> 
> The Project Management Committee (PMC) for Apache Ignite has invited Taras
> Ledkov to become a committer and we are pleased to announce that he has
> accepted.
> 
> 
> Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> integration and binary serialization, actively participates in JDBC and
> thin client protocol development, he is eager to help users on the user
> list within his area of expertise.
> 
> 
> 
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
> 
> 
> 
> Taras, thank you for all your efforts, congratulations and welcome on board!
> .
> 
> 
> 
> Best Regards,
> 
> Dmitriy Pavlov
> 
> on behalf of Apache Ignite PMC
> 

Re: [ANNOUNCE] New Committer: Taras Ledkov

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

Hooray!

Congratulations, Taras! Well deserved, keep going!

Thanks,
S.

вт, 12 мая 2020 г. в 19:09, Dmitriy Pavlov :

> Hello Ignite Community,
>
>
>
> The Project Management Committee (PMC) for Apache Ignite has invited Taras
> Ledkov to become a committer and we are pleased to announce that he has
> accepted.
>
>
> Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
> integration and binary serialization, actively participates in JDBC and
> thin client protocol development, he is eager to help users on the user
> list within his area of expertise.
>
>
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
>
>
> Taras, thank you for all your efforts, congratulations and welcome on
> board!
> .
>
>
>
> Best Regards,
>
> Dmitriy Pavlov
>
> on behalf of Apache Ignite PMC
>

Re: [ANNOUNCE] New PMC member: Maxim Muzafarov

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

Hi Maxim,

My congratulations!

Thanks,
S.

сб, 9 мая 2020 г. в 07:12, Denis Magda :

> Congrats, Maxim. Well deserved!
>
> -
> Denis
>
>
> On Thu, May 7, 2020 at 4:47 AM Dmitriy Pavlov  wrote:
>
> > The Project Management Committee (PMC) for Apache Ignite
> >
> > has invited Maxim Muzafarov to become new PMC member and we are pleased
> to
> > announce that he has accepted.
> >
> >
> >
> > Maxim is active dev list participant, speaker at meetups, and contributes
> > to additional checks of the product using travis and started new file
> > rebalance. Maxim did a fantastic job to make release 2.8 possible
> >
> >
> >
> > Being a PMC member enables assistance with the management
> >
> > and to guide the direction of the project.
> >
> > Maxim, congrats with new role and keep the pace !
> >
> >
> >
> > Best Regards,
> >
> > Dmitriy Pavlov
> >
> > on behalf of Apache Ignite PMC
> >
>

Re: [DISCUSSION] ASF Board Report Draft, May 2020

[Dmitriy Pavlov]

Here is filed version of the report:

## Description:
The mission of Ignite is the creation and maintenance of software related
to
is a horizontally scalable, fault-tolerant
distributed in-memory computing platform for building real-time
applications that can process terabytes of data with in-memory speed.

## Issues:
There are no issues requiring board attention.

## Membership Data:
Apache Ignite was founded 2015-08-19 (5 years ago)
There are currently 51 committers and 34 PMC members in this project.
The Committer-to-PMC ratio is 3:2.

Community changes, past quarter:
- Maxim Muzafarov was added to the PMC on 2020-04-28
- Slava Koptilin was added as committer on 2020-02-15
- Taras Ledkov was added as committer on 2020-05-09

## Project Activity:
- Apache Ignite 2.8.0 was released on 2020-03-03.
- Spring Boot extensions 1.0.0 was released on 2020-05-07.
- Apache Ignite 2.8.1 release is under preparation.
- Flume, Flink, and some other extensions have been migrated to the
  extensions repository.
   https://github.com/apache/ignite-extensions/tree/master/modules
- Released a new version of the Apache Ignite website:
   https://ignite.apache.org

## Community Health:
- Community prepared a public roadmap with significant improvements planned
  for the rest of 2020:
  https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
- Activity at development-related mailing lists (dev@, issues@,
  notifications@) increased in comparison to last quater (+30..40%). Commits
  count this quarter is slightly less (-17%)
- Community members gave 19 public online and offline presentations about
the
  project since the beginning of 2020. Around 8 talks are yet to be
presented
  and even more to follow: https://ignite.apache.org/events.html

вт, 12 мая 2020 г. в 16:44, Dmitriy Pavlov :

> Hi Denis,
>
> You are right, sending emails to bo...@apache.org is obsolete since it
> generates huge email traffic on the list. Board encourages to use 'Submit
> report to the board meeting agenda" in reporter.apache.org. Report is
> being filed there without any additional emails.
>
> I'll share final version.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 12 мая 2020 г. в 00:16, Denis Magda :
>
>> Dmitry, thanks for taking care of this.
>>
>> Btw, I remember that the report generation UI had a sort of "Send Email"
>> checkmark that allowed us to do both - add the report to the board's
>> agenda
>> and also generate an email template for dev@ignite.apache.org. Do you
>> still
>> see such a checkmark/button? If they removed this capability from the
>> interface, would you mind sending a copy of a final report to @dev?
>>
>> -
>> Denis
>>
>>
>> On Sun, May 10, 2020 at 6:22 AM Dmitriy Pavlov 
>> wrote:
>>
>> > Hi Denis,
>> >
>> > Thank you for your valuable proposals, I appreciate it.
>> >
>> > I've updated the description. Eventually, we need to update it in the
>> ASF
>> > records, I guess at projects.apache.org. Report's description is taken
>> > from
>> > somewhere else and is auto-generated.
>> >
>> > I've added all points to project or community activities sections (e.g.
>> > talks go to the community).
>> >
>> > Since where was Spring Boot Extensions 1.0.0 release announce at the
>> list,
>> > I've added it as well to the report.
>> >
>> > The report is now filed into the board meeting agenda.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> >
>> > пт, 8 мая 2020 г. в 00:49, Denis Magda :
>> >
>> > > Hi Dmitry, thanks!
>> > >
>> > > Please add the following to the project activity section:
>> > >
>> > >- Released a new version of the Apache Ignite website:
>> > >https://ignite.apache.org
>> > >- Prepared a public roadmap with significant improvements planned
>> for
>> > >the rest of 2020:
>> > >
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
>> > >- Flume, flinks and some other extensions have been migrated to the
>> > >extensions repository:
>> > >https://github.com/apache/ignite-extensions/tree/master/modules
>> > >- Community members gave 19 public online and offline presentations
>> > >about the project since the beginning of 2020. Around 8 talks are
>> yet
>> > > to be
>> > >presented and even more to follow:
>> > > https://ignite.apache.org/events.html
>> > >
>> > > To my knowledge, the Spring Boot extension has been already released (
>> > > https://apacheignite-mix.readme.io/docs/spring-boot). @Nikolay
>> Izhikov
>> > > , is it ready to be announced?
>> > >
>> > > Also, I would suggest using this as a definition of the project (what
>> > > Ignite is) - Apache Ignite® is a horizontally scalable, fault-tolerant
>> > > distributed in-memory computing platform for building real-time
>> > > applications that can process terabytes of data with in-memory speed.
>> > >
>> > > -
>> > > Denis
>> > >
>> > >
>> > > On Thu, May 7, 2020 at 7:46 AM Dmitriy Pavlov 
>> > wrote:
>> > >
>> > > > Hi Igniters,
>> > > >
>> > > > To increase involvement of each 

[ANNOUNCE] New Committer: Taras Ledkov

[Dmitriy Pavlov]

Hello Ignite Community,



The Project Management Committee (PMC) for Apache Ignite has invited Taras
Ledkov to become a committer and we are pleased to announce that he has
accepted.


Taras is an Ignite SQL veteran who knows in detail current Ignite - H2
integration and binary serialization, actively participates in JDBC and
thin client protocol development, he is eager to help users on the user
list within his area of expertise.



Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.



Taras, thank you for all your efforts, congratulations and welcome on board!
.



Best Regards,

Dmitriy Pavlov

on behalf of Apache Ignite PMC

[jira] [Created] (IGNITE-13004) Fix wrong comparison in TcpCommunicationSpi#closeConnections(UUID)

[Sergey Antonov (Jira)]

Sergey Antonov created IGNITE-13004:
---

 Summary: Fix wrong comparison in 
TcpCommunicationSpi#closeConnections(UUID)
 Key: IGNITE-13004
 URL: https://issues.apache.org/jira/browse/IGNITE-13004
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.9, 2.8.1
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.9


In IGNITE-12774 was introduced a bug in comparison:

{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey))
continue; 
{code}

The right code is: 

{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey.nodeId()))
continue; 
{code}




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

Re: [DISCUSS] TC bot instructions for open source contributors

[Ivan Pavlukhin]

What worries me is that the page [1] is quite large. I would love to
see a short (and sufficient enough) version for new contributors.

[1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Best regards,
Ivan Pavlukhin

вт, 12 мая 2020 г. в 16:41, Dmitriy Pavlov :
>
> +1 for linking it from How to contribute  -
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> to instructions related to the bot.
>
> May be eventually I would be able to contribute some automation into the
> Bot to make this process easier and requiring less contributor
> intervention.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 12 мая 2020 г. в 12:42, Ilya Kasnacheev :
>
> > Hello!
> >
> > I think it should be mentioned in [2] since this is the link we try to give
> > to every new Ignite contributor.
> >
> > Regards.
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 11 мая 2020 г. в 11:29, Ivan Pavlukhin :
> >
> > > Hi,
> > >
> > > Recently I faced problems explaining how a code contribution for
> > > Ignite should be checked with TC bot. Initially I thought that this
> > > process is well defined in our beloved contribution guidelines [1, 2].
> > > But as I see neither of them explains the process directly. Finally I
> > > found better instructions [3].
> > >
> > > So, the questions is should not we mention TC bot as earlier as
> > > possible? Naively I would like to see some words about it in
> > > CONTRIBUTING.md [1].
> > >
> > > Please, share your thoughts on this!
> > >
> > > [1] https://github.com/apache/ignite/blob/master/CONTRIBUTING.md
> > > [2] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > [3]
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >

Re: [DISCUSS] Apache URL for TC bot

[Ivan Pavlukhin]

Yes, it sounds reasonable at the first place to research how much
computing power we can get for free.

Best regards,
Ivan Pavlukhin

вт, 12 мая 2020 г. в 16:36, Dmitriy Pavlov :
>
> Hi Igniters,
>
> Open clouds for TC Bot sounds really good, but only concern here if there
> will be enough storage space and capabilities to run an Apache Ignite
> instance there.
>
> Currently, TC Bot requires a lot of resources, e.g. its DB size >100Gb and
> RAM allocated is approx 32Gb.
>
> Sincerely,
> Dmitriy Pavlov
>
> вт, 12 мая 2020 г. в 15:35, Ivan Rakov :
>
> > Ivan,
> >
> > Agree.
> > Mail notifications can be temporarily turned off in configuration of the
> > new bot.
> >
> > On Tue, May 12, 2020 at 3:12 PM Ivan Pavlukhin 
> > wrote:
> >
> > > Having bot deployed in open/free (and reliable) infrastructure sounds
> > > great! One precaution which seems important to me though is avoidance
> > > of duplicate (or even controversial) notifications from 2 bots at the
> > > same time.
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > вт, 12 мая 2020 г. в 15:06, Ivan Rakov :
> > > >
> > > > Hi,
> > > >
> > > > I've created an INFRA ticket [1] for forwarding requests from "
> > > > mtcga.ignite.apache.org" to the server where TC bot is hosted [1].
> > > > Definitely, I wouldn't object if anyone will deploy TC bot to the
> > public
> > > > cloud. We can live with two bots for a while, and then start using a
> > > public
> > > > bot after it accumulates enough build history to grant VISAs. If anyone
> > > is
> > > > interested, please check TC bot homepage on github with setup guide
> > [2].
> > > > 
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/INFRA-20257
> > > > [2]: https://github.com/apache/ignite-teamcity-bot
> > > >
> > > > --
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > > On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > It would be nice if somebody would try to bring up a parallel
> > > deployment of
> > > > > MTCGA bot on Apache domain.
> > > > >
> > > > > This way people will have a choice of using "old" or "new" bot, and
> > > they we
> > > > > may decide of sticking to one of them.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :
> > > > >
> > > > > > Ivan,
> > > > > >
> > > > > >
> > > > > > Good idea.
> > > > > > +1 to have the right domain name.
> > > > > >
> > > > > > I can imagine that we can go even further and completely move
> > TC.Bot
> > > > > > to some public cloud storage. For example, Amazon can provide
> > > > > > promotional credits for open source projects [1].
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > >
> > https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> > > > > >
> > > > > > On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin 
> > > > > wrote:
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > As you might know currently TC bot has a domain name in a
> > GridGain
> > > > > > > domain [1]. What do you think should we assign a name in an
> > Apache
> > > > > > > domain to the bot?
> > > > > > >
> > > > > > > [1] https://mtcga.gridgain.com/
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > >
> > > > >
> > >
> >

Re: [DISCUSSION] ASF Board Report Draft, May 2020

[Dmitriy Pavlov]

Hi Denis,

You are right, sending emails to bo...@apache.org is obsolete since it
generates huge email traffic on the list. Board encourages to use 'Submit
report to the board meeting agenda" in reporter.apache.org. Report is being
filed there without any additional emails.

I'll share final version.

Sincerely,
Dmitriy Pavlov

вт, 12 мая 2020 г. в 00:16, Denis Magda :

> Dmitry, thanks for taking care of this.
>
> Btw, I remember that the report generation UI had a sort of "Send Email"
> checkmark that allowed us to do both - add the report to the board's agenda
> and also generate an email template for dev@ignite.apache.org. Do you
> still
> see such a checkmark/button? If they removed this capability from the
> interface, would you mind sending a copy of a final report to @dev?
>
> -
> Denis
>
>
> On Sun, May 10, 2020 at 6:22 AM Dmitriy Pavlov  wrote:
>
> > Hi Denis,
> >
> > Thank you for your valuable proposals, I appreciate it.
> >
> > I've updated the description. Eventually, we need to update it in the ASF
> > records, I guess at projects.apache.org. Report's description is taken
> > from
> > somewhere else and is auto-generated.
> >
> > I've added all points to project or community activities sections (e.g.
> > talks go to the community).
> >
> > Since where was Spring Boot Extensions 1.0.0 release announce at the
> list,
> > I've added it as well to the report.
> >
> > The report is now filed into the board meeting agenda.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
> > пт, 8 мая 2020 г. в 00:49, Denis Magda :
> >
> > > Hi Dmitry, thanks!
> > >
> > > Please add the following to the project activity section:
> > >
> > >- Released a new version of the Apache Ignite website:
> > >https://ignite.apache.org
> > >- Prepared a public roadmap with significant improvements planned
> for
> > >the rest of 2020:
> > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Roadmap
> > >- Flume, flinks and some other extensions have been migrated to the
> > >extensions repository:
> > >https://github.com/apache/ignite-extensions/tree/master/modules
> > >- Community members gave 19 public online and offline presentations
> > >about the project since the beginning of 2020. Around 8 talks are
> yet
> > > to be
> > >presented and even more to follow:
> > > https://ignite.apache.org/events.html
> > >
> > > To my knowledge, the Spring Boot extension has been already released (
> > > https://apacheignite-mix.readme.io/docs/spring-boot). @Nikolay Izhikov
> > > , is it ready to be announced?
> > >
> > > Also, I would suggest using this as a definition of the project (what
> > > Ignite is) - Apache Ignite® is a horizontally scalable, fault-tolerant
> > > distributed in-memory computing platform for building real-time
> > > applications that can process terabytes of data with in-memory speed.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Thu, May 7, 2020 at 7:46 AM Dmitriy Pavlov 
> > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > > To increase involvement of each member of the community and increase
> > > > transparency I'd like to share report draft for ASF board with all
> dev@
> > > > community. Thanks to Ivan P. for this idea.
> > > >
> > > > What would you like to add to this report? Major features, events,
> > > popular
> > > > publications could be mentioned in the report (main manual sections
> are
> > > > community and project activity, and issues - if any). Let's make it
> > more
> > > > representative and useful. I'm going to publish it during weekend.
> > Please
> > > > find report draft below and share your thoughts.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ## Description:
> > > > The mission of Ignite is the creation and maintenance of software
> > related
> > > > to
> > > > High-performance, integrated and distributed in-memory platform for
> > > > computing
> > > > and transacting on large-scale data sets in real-time
> > > >
> > > > ## Issues:
> > > > There are no issues requiring board attention.
> > > >
> > > > ## Membership Data:
> > > > Apache Ignite was founded 2015-08-19 (5 years ago)
> > > > There are currently 50 committers and 34 PMC members in this project.
> > > > The Committer-to-PMC ratio is roughly 7:5.
> > > >
> > > > Community changes, past quarter:
> > > > - Maxim Muzafarov was added to the PMC on 2020-04-28
> > > > - Slava Koptilin was added as committer on 2020-02-15
> > > >
> > > > ## Project Activity:
> > > > 2.8.0 was released on 2020-03-03.
> > > > Spring boot starter was voted to be released.
> > > > Apache Ignite 2.8.1  release is under preparation.
> > > >
> > > > ## Community Health:
> > > > Activity at development related mailing lists (dev@, issues@,
> > > > notifications@)
> > > >
> > > > increased in compare to past quarter (+30..40%)
> > > > Commits count this quarter is slightly less (-17%)
> > > >
> > >
> >
>

Re: [DISCUSS] TC bot instructions for open source contributors

[Dmitriy Pavlov]

+1 for linking it from How to contribute  -
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
to instructions related to the bot.

May be eventually I would be able to contribute some automation into the
Bot to make this process easier and requiring less contributor
intervention.

Sincerely,
Dmitriy Pavlov

вт, 12 мая 2020 г. в 12:42, Ilya Kasnacheev :

> Hello!
>
> I think it should be mentioned in [2] since this is the link we try to give
> to every new Ignite contributor.
>
> Regards.
> --
> Ilya Kasnacheev
>
>
> пн, 11 мая 2020 г. в 11:29, Ivan Pavlukhin :
>
> > Hi,
> >
> > Recently I faced problems explaining how a code contribution for
> > Ignite should be checked with TC bot. Initially I thought that this
> > process is well defined in our beloved contribution guidelines [1, 2].
> > But as I see neither of them explains the process directly. Finally I
> > found better instructions [3].
> >
> > So, the questions is should not we mention TC bot as earlier as
> > possible? Naively I would like to see some words about it in
> > CONTRIBUTING.md [1].
> >
> > Please, share your thoughts on this!
> >
> > [1] https://github.com/apache/ignite/blob/master/CONTRIBUTING.md
> > [2] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > [3]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: [DISCUSS] Apache URL for TC bot

[Dmitriy Pavlov]

Hi Igniters,

Open clouds for TC Bot sounds really good, but only concern here if there
will be enough storage space and capabilities to run an Apache Ignite
instance there.

Currently, TC Bot requires a lot of resources, e.g. its DB size >100Gb and
RAM allocated is approx 32Gb.

Sincerely,
Dmitriy Pavlov

вт, 12 мая 2020 г. в 15:35, Ivan Rakov :

> Ivan,
>
> Agree.
> Mail notifications can be temporarily turned off in configuration of the
> new bot.
>
> On Tue, May 12, 2020 at 3:12 PM Ivan Pavlukhin 
> wrote:
>
> > Having bot deployed in open/free (and reliable) infrastructure sounds
> > great! One precaution which seems important to me though is avoidance
> > of duplicate (or even controversial) notifications from 2 bots at the
> > same time.
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > вт, 12 мая 2020 г. в 15:06, Ivan Rakov :
> > >
> > > Hi,
> > >
> > > I've created an INFRA ticket [1] for forwarding requests from "
> > > mtcga.ignite.apache.org" to the server where TC bot is hosted [1].
> > > Definitely, I wouldn't object if anyone will deploy TC bot to the
> public
> > > cloud. We can live with two bots for a while, and then start using a
> > public
> > > bot after it accumulates enough build history to grant VISAs. If anyone
> > is
> > > interested, please check TC bot homepage on github with setup guide
> [2].
> > > 
> > >
> > > [1]: https://issues.apache.org/jira/browse/INFRA-20257
> > > [2]: https://github.com/apache/ignite-teamcity-bot
> > >
> > > --
> > > Best Regards,
> > > Ivan Rakov
> > >
> > > On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > It would be nice if somebody would try to bring up a parallel
> > deployment of
> > > > MTCGA bot on Apache domain.
> > > >
> > > > This way people will have a choice of using "old" or "new" bot, and
> > they we
> > > > may decide of sticking to one of them.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :
> > > >
> > > > > Ivan,
> > > > >
> > > > >
> > > > > Good idea.
> > > > > +1 to have the right domain name.
> > > > >
> > > > > I can imagine that we can go even further and completely move
> TC.Bot
> > > > > to some public cloud storage. For example, Amazon can provide
> > > > > promotional credits for open source projects [1].
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > >
> >
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> > > > >
> > > > > On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin 
> > > > wrote:
> > > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > As you might know currently TC bot has a domain name in a
> GridGain
> > > > > > domain [1]. What do you think should we assign a name in an
> Apache
> > > > > > domain to the bot?
> > > > > >
> > > > > > [1] https://mtcga.gridgain.com/
> > > > > >
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > >
> > > >
> >
>

Re: Moving binary metadata to PDS storage folder

[Sergey Antonov]

Hello Semyon,

This is a good idea!

вт, 12 мая 2020 г. в 15:53, Вячеслав Коптилин :

> Hello Semyon,
>
> This is a good and long-awaited improvement! Thank you for your efforts!
>
> Thanks,
> S.
>
> вт, 12 мая 2020 г. в 15:11, Данилов Семён :
>
> > Hello!
> >
> > I would like to propose moving /binary_meta and /marshaller folders to
> the
> > PDS folder.
> >
> > Motivation: data, directly related to the persistence, is stored outside
> > the persistence dir, which can lead to various issues and also is not
> very
> > convenient to use. In particular, with k8s, deployment disk that is
> > attached to a container can not be accessed from other containers or
> > outside of k8s. In case if support will need to drop persistence except
> > data, there will be no way to recover due to binary metadata is required
> to
> > process PDS files.
> >
> > I created an issue (https://issues.apache.org/jira/browse/IGNITE-12994)
> and a
> > pull request(https://github.com/apache/ignite/pull/7792) that fixes the
> > issue.
> >
> > In that PR I made the following:
> >
> >
> > * store binary meta and marshaller data inside db/ folder
> > * if binary meta of marshaller are found in "legacy" locations --
> > safely move them to new locations during the node startup
> >
> >
> > Kind regards,
> >
> > Semyon Danilov.
> >
>


-- 
BR, Sergey Antonov

Re: Moving binary metadata to PDS storage folder

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

Hello Semyon,

This is a good and long-awaited improvement! Thank you for your efforts!

Thanks,
S.

вт, 12 мая 2020 г. в 15:11, Данилов Семён :

> Hello!
>
> I would like to propose moving /binary_meta and /marshaller folders to the
> PDS folder.
>
> Motivation: data, directly related to the persistence, is stored outside
> the persistence dir, which can lead to various issues and also is not very
> convenient to use. In particular, with k8s, deployment disk that is
> attached to a container can not be accessed from other containers or
> outside of k8s. In case if support will need to drop persistence except
> data, there will be no way to recover due to binary metadata is required to
> process PDS files.
>
> I created an issue (https://issues.apache.org/jira/browse/IGNITE-12994) and a
> pull request(https://github.com/apache/ignite/pull/7792) that fixes the
> issue.
>
> In that PR I made the following:
>
>
> * store binary meta and marshaller data inside db/ folder
> * if binary meta of marshaller are found in "legacy" locations --
> safely move them to new locations during the node startup
>
>
> Kind regards,
>
> Semyon Danilov.
>

Re: [DISCUSS] Apache URL for TC bot

[Ivan Rakov]

Ivan,

Agree.
Mail notifications can be temporarily turned off in configuration of the
new bot.

On Tue, May 12, 2020 at 3:12 PM Ivan Pavlukhin  wrote:

> Having bot deployed in open/free (and reliable) infrastructure sounds
> great! One precaution which seems important to me though is avoidance
> of duplicate (or even controversial) notifications from 2 bots at the
> same time.
>
> Best regards,
> Ivan Pavlukhin
>
> вт, 12 мая 2020 г. в 15:06, Ivan Rakov :
> >
> > Hi,
> >
> > I've created an INFRA ticket [1] for forwarding requests from "
> > mtcga.ignite.apache.org" to the server where TC bot is hosted [1].
> > Definitely, I wouldn't object if anyone will deploy TC bot to the public
> > cloud. We can live with two bots for a while, and then start using a
> public
> > bot after it accumulates enough build history to grant VISAs. If anyone
> is
> > interested, please check TC bot homepage on github with setup guide [2].
> > 
> >
> > [1]: https://issues.apache.org/jira/browse/INFRA-20257
> > [2]: https://github.com/apache/ignite-teamcity-bot
> >
> > --
> > Best Regards,
> > Ivan Rakov
> >
> > On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > It would be nice if somebody would try to bring up a parallel
> deployment of
> > > MTCGA bot on Apache domain.
> > >
> > > This way people will have a choice of using "old" or "new" bot, and
> they we
> > > may decide of sticking to one of them.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :
> > >
> > > > Ivan,
> > > >
> > > >
> > > > Good idea.
> > > > +1 to have the right domain name.
> > > >
> > > > I can imagine that we can go even further and completely move TC.Bot
> > > > to some public cloud storage. For example, Amazon can provide
> > > > promotional credits for open source projects [1].
> > > >
> > > >
> > > > [1]
> > > >
> > >
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> > > >
> > > > On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin 
> > > wrote:
> > > > >
> > > > > Igniters,
> > > > >
> > > > > As you might know currently TC bot has a domain name in a GridGain
> > > > > domain [1]. What do you think should we assign a name in an Apache
> > > > > domain to the bot?
> > > > >
> > > > > [1] https://mtcga.gridgain.com/
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > >
> > >
>

Re: [DISCUSS] Data loss handling improvements

[Ivan Pavlukhin]

Have not chance to read this thread carefully, but a following
discussion sounds very similar and might be somehow useful [1].

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Partition-Loss-Policies-issues-td37304.html

Best regards,
Ivan Pavlukhin

чт, 7 мая 2020 г. в 11:36, Alexei Scherbakov :
>
> Yes, it will work this way.
>
> чт, 7 мая 2020 г. в 10:43, Anton Vinogradov :
>
> > Seems I got the vision, thanks.
> > There should be only 2 ways to reset lost partition: to gain an owner from
> > resurrected first or to remove ex-owner from baseline (partition will be
> > rearranged).
> > And we should make a decision for every lost partition before calling the
> > reset.
> >
> > On Wed, May 6, 2020 at 8:02 PM Alexei Scherbakov <
> > alexey.scherbak...@gmail.com> wrote:
> >
> > > ср, 6 мая 2020 г. в 12:54, Anton Vinogradov :
> > >
> > > > Alexei,
> > > >
> > > > 1,2,4,5 - looks good to me, no objections here.
> > > >
> > > > >> 3. Lost state is impossible to reset if a topology doesn't have at
> > > least
> > > > >> one owner for each lost partition.
> > > >
> > > > Do you mean that, according to your example, where
> > > > >> a node2 has left, soon a node3 has left. If the node2 is returned to
> > > > >> the topology first, it would have stale data for some keys.
> > > > we have to have node2 at cluster to be able to reset "lost" to node2's
> > > > data?
> > > >
> > >
> > > Not sure if I understand a question, but try to answer using an example:
> > > Assume 3 nodes n1, n2, n3, 1 backup, persistence enabled, partition p is
> > > owned by n2 and n3.
> > > 1. Topology is activated.
> > > 2. cache.put(p, 0) // n2 and n3 have p->0, updateCounter=1
> > > 3. n2 has failed.
> > > 4. cache.put(p, 1) // n3 has p->1, updateCounter=2
> > > 5. n3 has failed, partition loss is happened.
> > > 6. n2 joins a topology, it has stale data (p->0)
> > >
> > > We actually have 2 issues:
> > > 7. cache.put(p, 2) will success, n2 has p->2, n3 has p->0, data is
> > diverged
> > > and will not be adjusted by counters rebalancing if n3 is later joins a
> > > topology.
> > > or
> > > 8. n3 joins a topology, it has actual data (p->1) but rebalancing will
> > not
> > > work because joining node has highest counter (it can only be a demander
> > in
> > > this scenario).
> > >
> > > In both cases rebalancing by counters will not work causing data
> > divergence
> > > in copies.
> > >
> > >
> > > >
> > > > >> at least one owner for each lost partition.
> > > > What the reason to have owners for all lost partitions when we want to
> > > > reset only some (available)?
> > > >
> > >
> > > It's never were possible to reset only subset of lost partitions. The
> > > reason is to make guarantee of resetLostPartitions method - all cache
> > > operations are resumed, data is correct.
> > >
> > >
> > > > Will it be possible to perform operations on non-lost partitions when
> > the
> > > > cluster has at least one lost partition?
> > > >
> > >
> > > Yes it will be.
> > >
> > >
> > > >
> > > > On Wed, May 6, 2020 at 11:45 AM Alexei Scherbakov <
> > > > alexey.scherbak...@gmail.com> wrote:
> > > >
> > > > > Folks,
> > > > >
> > > > > I've almost finished a patch bringing some improvements to the data
> > > loss
> > > > > handling code, and I wish to discuss proposed changes with the
> > > community
> > > > > before submitting.
> > > > >
> > > > > *The issue*
> > > > >
> > > > > During the grid's lifetime, it's possible to get into a situation
> > when
> > > > some
> > > > > data nodes have failed or mistakenly stopped. If a number of stopped
> > > > nodes
> > > > > exceeds a certain threshold depending on configured backups, count a
> > > data
> > > > > loss will occur. For example, a grid having one backup (meaning at
> > > least
> > > > > two copies of each data partition exist at the same time) can
> > tolerate
> > > > only
> > > > > one node loss at the time. Generally, data loss is guaranteed to
> > occur
> > > if
> > > > > backups + 1 or more nodes have failed simultaneously using default
> > > > affinity
> > > > > function.
> > > > >
> > > > > For in-memory caches, data is lost forever. For persistent caches,
> > data
> > > > is
> > > > > not physically lost and accessible again after failed nodes are
> > > returned
> > > > to
> > > > > the topology.
> > > > >
> > > > > Possible data loss should be taken into consideration while designing
> > > an
> > > > > application.
> > > > >
> > > > >
> > > > >
> > > > > *Consider an example: money is transferred from one deposit to
> > another,
> > > > and
> > > > > all nodes holding data for one of the deposits are gone.In such a
> > > case, a
> > > > > transaction temporary cannot be completed until a cluster is
> > recovered
> > > > from
> > > > > the data loss state. Ignoring this can cause data inconsistency.*
> > > > > It is necessary to have an API telling us if an operation is safe to
> > > > > complete from the perspective of data loss.
> > > > >
> > > > > Such an API exists for some 

Re: [DISCUSS] Apache URL for TC bot

[Ivan Pavlukhin]

Having bot deployed in open/free (and reliable) infrastructure sounds
great! One precaution which seems important to me though is avoidance
of duplicate (or even controversial) notifications from 2 bots at the
same time.

Best regards,
Ivan Pavlukhin

вт, 12 мая 2020 г. в 15:06, Ivan Rakov :
>
> Hi,
>
> I've created an INFRA ticket [1] for forwarding requests from "
> mtcga.ignite.apache.org" to the server where TC bot is hosted [1].
> Definitely, I wouldn't object if anyone will deploy TC bot to the public
> cloud. We can live with two bots for a while, and then start using a public
> bot after it accumulates enough build history to grant VISAs. If anyone is
> interested, please check TC bot homepage on github with setup guide [2].
> 
>
> [1]: https://issues.apache.org/jira/browse/INFRA-20257
> [2]: https://github.com/apache/ignite-teamcity-bot
>
> --
> Best Regards,
> Ivan Rakov
>
> On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev 
> wrote:
>
> > Hello!
> >
> > It would be nice if somebody would try to bring up a parallel deployment of
> > MTCGA bot on Apache domain.
> >
> > This way people will have a choice of using "old" or "new" bot, and they we
> > may decide of sticking to one of them.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :
> >
> > > Ivan,
> > >
> > >
> > > Good idea.
> > > +1 to have the right domain name.
> > >
> > > I can imagine that we can go even further and completely move TC.Bot
> > > to some public cloud storage. For example, Amazon can provide
> > > promotional credits for open source projects [1].
> > >
> > >
> > > [1]
> > >
> > https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> > >
> > > On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin 
> > wrote:
> > > >
> > > > Igniters,
> > > >
> > > > As you might know currently TC bot has a domain name in a GridGain
> > > > domain [1]. What do you think should we assign a name in an Apache
> > > > domain to the bot?
> > > >
> > > > [1] https://mtcga.gridgain.com/
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > >
> >

Moving binary metadata to PDS storage folder

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

Hello!

I would like to propose moving /binary_meta and /marshaller folders to the PDS 
folder.

Motivation: data, directly related to the persistence, is stored outside the 
persistence dir, which can lead to various issues and also is not very 
convenient to use. In particular, with k8s, deployment disk that is attached to 
a container can not be accessed from other containers or outside of k8s. In 
case if support will need to drop persistence except data, there will be no way 
to recover due to binary metadata is required to process PDS files.

I created an issue (https://issues.apache.org/jira/browse/IGNITE-12994) and a 
pull request(https://github.com/apache/ignite/pull/7792) that fixes the issue.

In that PR I made the following:


*     store binary meta and marshaller data inside db/ folder
*     if binary meta of marshaller are found in "legacy" locations -- safely 
move them to new locations during the node startup


Kind regards,

Semyon Danilov.

Re: [DISCUSS] Apache URL for TC bot

[Ivan Rakov]

Hi,

I've created an INFRA ticket [1] for forwarding requests from "
mtcga.ignite.apache.org" to the server where TC bot is hosted [1].
Definitely, I wouldn't object if anyone will deploy TC bot to the public
cloud. We can live with two bots for a while, and then start using a public
bot after it accumulates enough build history to grant VISAs. If anyone is
interested, please check TC bot homepage on github with setup guide [2].


[1]: https://issues.apache.org/jira/browse/INFRA-20257
[2]: https://github.com/apache/ignite-teamcity-bot

--
Best Regards,
Ivan Rakov

On Tue, May 12, 2020 at 12:44 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> It would be nice if somebody would try to bring up a parallel deployment of
> MTCGA bot on Apache domain.
>
> This way people will have a choice of using "old" or "new" bot, and they we
> may decide of sticking to one of them.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :
>
> > Ivan,
> >
> >
> > Good idea.
> > +1 to have the right domain name.
> >
> > I can imagine that we can go even further and completely move TC.Bot
> > to some public cloud storage. For example, Amazon can provide
> > promotional credits for open source projects [1].
> >
> >
> > [1]
> >
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
> >
> > On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin 
> wrote:
> > >
> > > Igniters,
> > >
> > > As you might know currently TC bot has a domain name in a GridGain
> > > domain [1]. What do you think should we assign a name in an Apache
> > > domain to the bot?
> > >
> > > [1] https://mtcga.gridgain.com/
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> >
>

[jira] [Created] (IGNITE-13003) Improve data loss handling

[Alexey Scherbakov (Jira)]

Alexey Scherbakov created IGNITE-13003:
--

 Summary: Improve data loss handling
 Key: IGNITE-13003
 URL: https://issues.apache.org/jira/browse/IGNITE-13003
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.8
Reporter: Alexey Scherbakov
Assignee: Alexey Scherbakov
 Fix For: 2.9






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

[jira] [Created] (IGNITE-13002) Supports user's java object by JDBC thin client

[Konstantin Orlov (Jira)]

Konstantin Orlov created IGNITE-13002:
-

 Summary: Supports user's java object by JDBC thin client
 Key: IGNITE-13002
 URL: https://issues.apache.org/jira/browse/IGNITE-13002
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov


Now JDBC thin client doesn't support no-SQL types.
e.g.:
{{CREATE TABLE TEST (ID INT PRIMARY KEY, VAL OTHER)}}
{code}
PreparedStatement stmt = conn.prepareStatement("INSERT INTO TEST VALUES(?, ?)")
stmt.setInteger(1, 0);
stmt.setObject(2, new MyClass());
{code}

We have to support {{GridBinaryMarshaller}} for the JDBC thin client.




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

Re: Github pull requests are not linked automatically to jira tickets.

[Pavel Pereslegin]

Ivan,

unfortunately this did not help, I left a comment about it in the
latest INFRA ticket on this subject [1].

[1] https://issues.apache.org/jira/browse/INFRA-20253

вт, 12 мая 2020 г. в 13:47, Ivan Pavlukhin :
>
> Pavel, folks,
>
> Does anyone have an evidence that PR linking works fine now? I noticed
> that for a ticket [1] a PR link had not been added automatically.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12994
>
> Best regards,
> Ivan Pavlukhin
>
> пн, 11 мая 2020 г. в 11:55, Ivan Pavlukhin :
> >
> > Pavel,
> >
> > Thank you! I merged the PR.
> >
> > Let's see that PR linking to JIRA and everything else work fine.
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > пт, 8 мая 2020 г. в 14:45, Pavel Pereslegin :
> > >
> > > Igniters,
> > >
> > > ticket created [1], please take a look at the proposed changes [2].
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12993
> > > [2] https://github.com/apache/ignite/pull/7784/files
> > >
> > > пт, 8 мая 2020 г. в 12:02, Maxim Muzafarov :
> > > >
> > > > Pavel,
> > > >
> > > >
> > > > I have no objections. Let's file a ticket.
> > > >
> > > > On Fri, 8 May 2020 at 08:04, Ivan Pavlukhin  wrote:
> > > > >
> > > > > Pavel,
> > > > >
> > > > > Thank you for starting this discussion!
> > > > >
> > > > > Controlling all this repo options on our side sounds very attractive.
> > > > >
> > > > > Personally I do not have any arguments about the proposal.
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > > чт, 7 мая 2020 г. в 17:39, Pavel Pereslegin :
> > > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > recent github pull requests are not automatically linked to the jira
> > > > > > tickets.
> > > > > >
> > > > > > Infra advises creating a yaml configuration in the root of the 
> > > > > > repository
> > > > > > with the settings for the github bot [1].
> > > > > > Examples of such configuration in Hive [2] and HBase [3].
> > > > > > I suggest the following settings for Ignite [4].
> > > > > >
> > > > > > If there are no objections, I'll file a ticket for this.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/INFRA-20177
> > > > > > [2] https://github.com/apache/hbase/blob/master/.asf.yaml
> > > > > > [3] https://github.com/apache/hive/blob/master/.asf.yaml
> > > > > > [4] https://gist.github.com/xtern/572cbc7d4a7916f6e933fbafe5034492

Re: Github pull requests are not linked automatically to jira tickets.

[Ivan Pavlukhin]

Pavel, folks,

Does anyone have an evidence that PR linking works fine now? I noticed
that for a ticket [1] a PR link had not been added automatically.

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

Best regards,
Ivan Pavlukhin

пн, 11 мая 2020 г. в 11:55, Ivan Pavlukhin :
>
> Pavel,
>
> Thank you! I merged the PR.
>
> Let's see that PR linking to JIRA and everything else work fine.
>
> Best regards,
> Ivan Pavlukhin
>
> пт, 8 мая 2020 г. в 14:45, Pavel Pereslegin :
> >
> > Igniters,
> >
> > ticket created [1], please take a look at the proposed changes [2].
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12993
> > [2] https://github.com/apache/ignite/pull/7784/files
> >
> > пт, 8 мая 2020 г. в 12:02, Maxim Muzafarov :
> > >
> > > Pavel,
> > >
> > >
> > > I have no objections. Let's file a ticket.
> > >
> > > On Fri, 8 May 2020 at 08:04, Ivan Pavlukhin  wrote:
> > > >
> > > > Pavel,
> > > >
> > > > Thank you for starting this discussion!
> > > >
> > > > Controlling all this repo options on our side sounds very attractive.
> > > >
> > > > Personally I do not have any arguments about the proposal.
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > чт, 7 мая 2020 г. в 17:39, Pavel Pereslegin :
> > > > >
> > > > > Igniters,
> > > > >
> > > > > recent github pull requests are not automatically linked to the jira
> > > > > tickets.
> > > > >
> > > > > Infra advises creating a yaml configuration in the root of the 
> > > > > repository
> > > > > with the settings for the github bot [1].
> > > > > Examples of such configuration in Hive [2] and HBase [3].
> > > > > I suggest the following settings for Ignite [4].
> > > > >
> > > > > If there are no objections, I'll file a ticket for this.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/INFRA-20177
> > > > > [2] https://github.com/apache/hbase/blob/master/.asf.yaml
> > > > > [3] https://github.com/apache/hive/blob/master/.asf.yaml
> > > > > [4] https://gist.github.com/xtern/572cbc7d4a7916f6e933fbafe5034492

[jira] [Created] (IGNITE-13001) .NET: Thin Client Compute

[Pavel Tupitsyn (Jira)]

Pavel Tupitsyn created IGNITE-13001:
---

 Summary: .NET: Thin Client Compute
 Key: IGNITE-13001
 URL: https://issues.apache.org/jira/browse/IGNITE-13001
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.9


Add Compute to .NET Thin Client. See IGNITE-12853.



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

Re: [DISCUSS] Apache URL for TC bot

[Ilya Kasnacheev]

Hello!

It would be nice if somebody would try to bring up a parallel deployment of
MTCGA bot on Apache domain.

This way people will have a choice of using "old" or "new" bot, and they we
may decide of sticking to one of them.

Regards,
-- 
Ilya Kasnacheev


пн, 11 мая 2020 г. в 18:37, Maxim Muzafarov :

> Ivan,
>
>
> Good idea.
> +1 to have the right domain name.
>
> I can imagine that we can go even further and completely move TC.Bot
> to some public cloud storage. For example, Amazon can provide
> promotional credits for open source projects [1].
>
>
> [1]
> https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/
>
> On Mon, 11 May 2020 at 11:35, Ivan Pavlukhin  wrote:
> >
> > Igniters,
> >
> > As you might know currently TC bot has a domain name in a GridGain
> > domain [1]. What do you think should we assign a name in an Apache
> > domain to the bot?
> >
> > [1] https://mtcga.gridgain.com/
> >
> > Best regards,
> > Ivan Pavlukhin
>

Re: [DISCUSS] TC bot instructions for open source contributors

[Ilya Kasnacheev]

Hello!

I think it should be mentioned in [2] since this is the link we try to give
to every new Ignite contributor.

Regards.
-- 
Ilya Kasnacheev


пн, 11 мая 2020 г. в 11:29, Ivan Pavlukhin :

> Hi,
>
> Recently I faced problems explaining how a code contribution for
> Ignite should be checked with TC bot. Initially I thought that this
> process is well defined in our beloved contribution guidelines [1, 2].
> But as I see neither of them explains the process directly. Finally I
> found better instructions [3].
>
> So, the questions is should not we mention TC bot as earlier as
> possible? Naively I would like to see some words about it in
> CONTRIBUTING.md [1].
>
> Please, share your thoughts on this!
>
> [1] https://github.com/apache/ignite/blob/master/CONTRIBUTING.md
> [2] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> [3]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot
>
> Best regards,
> Ivan Pavlukhin
>

[jira] [Created] (IGNITE-13000) Connection.prepareStatement(String,int) always throws UnsupportedException ignoring 'autoGeneratedKeys' parameter

[Pavel Vinokurov (Jira)]

Pavel Vinokurov created IGNITE-13000:


 Summary: Connection.prepareStatement(String,int) always throws 
UnsupportedException  ignoring  'autoGeneratedKeys' parameter
 Key: IGNITE-13000
 URL: https://issues.apache.org/jira/browse/IGNITE-13000
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8
Reporter: Pavel Vinokurov


Below the method call throwing Exception.
{code:java}
conn.prepareStatement(query, Statement.NO_GENERATED_KEYS)
{code}

But there is should be the same result as for:
{code:java}
conn.prepareStatement(query)
{code}


The possible fix:
{code:java}
@Override 
public PreparedStatement prepareStatement(String sql, int autoGeneratedKeys) 
throws SQLException {
ensureNotClosed();
if(autoGeneratedKeys == Statement.RETURN_GENERATED_KEYS)
throw new SQLFeatureNotSupportedException("Auto generated keys are not 
supported.");
return prepareStatement(sql);
}
{code}




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

Re: Crash recovery speed-up #3, Cellular Switch

[Anton Vinogradov]

Denis,

Rebalance is not expected here since this optimization works only on a
fully rebalanced cluster with baseline.

On Sat, May 9, 2020 at 12:48 AM Denis Magda  wrote:

> Hi Anton,
>
> Generally, it means that Ignite will keep executing operations/transactions
> that are mapped into the partitions of those cells that won't be
> rebalanced, is that correct?
>
> -
> Denis
>
>
> On Wed, May 6, 2020 at 3:24 AM Anton Vinogradov  wrote:
>
> > Igniters,
> >
> > PME-free switch [1] (since 2.8) skips PME on node left when possible
> > (baseline + fully rebalanced cluster).
> > This means we already wait for nothing (except recovery) to perform the
> > switch.
> > This optimization allows continuing already started operations during or
> > after the switch if they are not affected by failed primary.
> > But upcoming operations still can't be started until the switch is
> finished
> > cluster-wide.
> >
> > Let me propose an additional optimization - Cellular switch.
> > Cellular Affinity [2] means that nodes combined into virtual cells where,
> > for each partition, backups located at the same cell with primaries.
> > The simplest way to gain Cellular Affinity is to use backup filters [3].
> >
> > Cellular Affinity allows to finish the switch outside the affected cell
> > instantly with the following assumptions:
> > - Replicated caches should be recovered first since every node affected
> (as
> > a backup) by any failed primary.
> >   But, it is expected that replicated caches effectively read-only (has
> > extremely rare updates), so, nothing to wait here.
> > - Upcoming replicated transactions (with non-failed primaries) can be
> > started but can't be committed until switch finished cluster-wide.
> > - Upcoming transactions related to the broken cell will wait for cell
> > recovery (cluster-wide switch finish).
> >
> > ... and this means:
> > In addition to PME-free switch, where we able to continue already started
> > operations during or after the switch, now we also able to perform most
> of
> > the upcoming operations during the switch.
> >
> > In other words, Cellular switch has little effect on the operation's
> > latency, when operation not related to the failed cell.
> >
> > According to benchmark [4] which checks "how fast upcoming transactions
> > (started after switch start) can be committed when we have thousands of
> > prepared transactions (prepared before switch start)", we have 5326 ms
> [5]
> > operation's latency on master and 65 ms [6] with the proposed fix, which
> is
> > ~100 times faster.
> >
> > Fix [7] (as a part of IEP-45 [8]) ready to be reviewed.
> > Waiting for your review!
> >
> >
> > [1]
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Non-blocking-PME-Phase-One-Node-fail-tp43531p44586.html
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-45%3A+Crash+Recovery+Speed-Up#IEP-45:CrashRecoverySpeed-Up-Cellularswitch
> > [3]
> >
> >
> https://gist.github.com/anton-vinogradov/c50f9d0ce3e3e2997646f84ba7eba5f5#file-bench-java-L417
> > [4]
> >
> https://gist.github.com/anton-vinogradov/c50f9d0ce3e3e2997646f84ba7eba5f5
> > [5]
> >
> >
> https://gist.github.com/anton-vinogradov/a35a3a8151b7494aa84b83f58cb75889#file-master-txt-L15
> > [6]
> >
> >
> https://gist.github.com/anton-vinogradov/a35a3a8151b7494aa84b83f58cb75889#file-fix-txt-L15
> > [7] https://issues.apache.org/jira/browse/IGNITE-12617
> > [8]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-45%3A+Crash+Recovery+Speed-Up
> >
>