Re: New Сommitter: Maxim Muzafarov

[Anton Vinogradov]

Welcome aboard :)

On Thu, Aug 29, 2019 at 3:35 AM Roman Shtykh 
wrote:

> Maxim, congratulations!
>
> -- Roman
>
>
> On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov <
> dpav...@apache.org> wrote:
>
>  Dear community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> Muzafarov to become a committer and we are pleased to announce that he has
> accepted.
>
> PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
> removal of WAL applying steps from Partition Map Exchange, finding and
> fixing non-trivial issues with the product, like mem leaks, and in setting
> up code inspections and maintaining this process.
>
> 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.
>
> Best regards,
> Dmitriy Pavlov
> on behalf of PMC, Apache Ignite
>

Re: New Сommitter: Maxim Muzafarov

[Roman Shtykh]

Maxim, congratulations!

-- Roman
 

On Thursday, August 29, 2019, 12:11:29 a.m. GMT+9, Dmitriy Pavlov 
 wrote:  
 
 Dear community,

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

PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
removal of WAL applying steps from Partition Map Exchange, finding and
fixing non-trivial issues with the product, like mem leaks, and in setting
up code inspections and maintaining this process.

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.

Best regards,
Dmitriy Pavlov
on behalf of PMC, Apache Ignite
  

Re: Log level changes in GridCacheWriteBehindStore.updateStore

[Denis Magda]

Agree with the proposed changes. Was the ticket created?

Denis

On Tuesday, August 27, 2019, Ilya Kasnacheev 
wrote:

> Hello!
>
> I think you should go ahead and create a JIRA ticket about it, then someone
> (or even you) can check it and fix it.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 26 авг. 2019 г. в 09:17, Sunny Chan, CLSA :
>
> > Hello,
> >
> >
> >
> > In the GridCacheWriteBehindStore
> >  083a2312dd/modules/core/src/main/java/org/apache/ignite/
> internal/processors/cache/store/GridCacheWriteBehindStore.java#L893>,
> > when the updateStore failed to write to underlying store, it logs this as
> > error:
> >
> >
> >
> > LT.error(log, e, "Unable to update underlying store: " + store);
> >
> >
> >
> > After this line logged the error, it would return false so that it would
> > retry the store (by returning false).
> >
> >
> >
> > While later on in the updatStore function, when the writeCache overflows,
> > it would log this:
> >
> >
> >
> > log.warning("Failed to update store (value will be lost as current buffer
> > size is greater " + …
> >
> >
> >
> > then it will remove the failed entry.
> >
> >
> >
> > I think the severity of the log messages is not right, as the fail update
> > would still be retried.
> >
> >
> >
> > So I propose to change the log severity level so that the first one would
> > be a warn, and second one would be error. Is that acceptable?
> >
> >
> >
> > *Sunny Chan*
> >
> > *Senior Lead Engineer, Executive Services*
> >
> > D  +852 2600 8907  |  M  +852 6386 1835  |  T  +852 2600 
> >
> > 5/F, One Island East, 18 Westlands Road, Island East, Hong Kong
> >
> >
> >
> > [image: :1. Social Media Icons:CLSA_Social Media Icons_linkedin.png]
> > [image: :1. Social Media
> > Icons:CLSA_Social Media Icons_twitter.png]
> > [image: :1. Social Media
> > Icons:CLSA_Social Media Icons_youtube.png]
> > [image: :1.
> > Social Media Icons:CLSA_Social Media Icons_facebook.png]
> > 
> >
> >
> >
> > *clsa.com* 
> >
> > *Insights. Liquidity. Capital. *
> >
> >
> >
> > [image: CLSA_RGB] 
> >
> >
> >
> > *A CITIC Securities Company*
> >
> >
> >
> > The content of this communication is intended for the recipient and is
> > subject to CLSA Legal and Regulatory Notices.
> > These can be viewed at https://www.clsa.com/disclaimer.html or sent to
> > you upon request.
> > Please consider before printing. CLSA is ISO14001 certified and committed
> > to reducing its impact on the environment.
> >
>


-- 
-
Denis

Ignite JIRA Access

[Greg Stachnick]

Hi Everyone,

Just a quick introduction, my name is Greg Stachnick and I am working in
product management for GridGain's cloud and tools (Visor and Web Console).
I joined the company earlier this year and am looking forward to sharing
some improvements that we have planned for Web Console in the coming
months.

I was wondering if I could get access to Ignite JIRA so that I can help
prioritize and assign Web Console related issues. I saw that there was a
recent pull request for https://issues.apache.org/jira/browse/IGNITE-12018
and want to make sure it gets the appropriate attention.

My id is greg.stachnick in JIRA.

Thanks and looking forward to participating in the community.

-Greg

-- 
Greg Stachnick
Director of Cloud Product Management
GridGain Systems
(415)407-7192
greg.stachn...@gridgain.com

Re: New Сommitter: Maxim Muzafarov

[Павлухин Иван]

Maxim, my congratulations!

2019-08-29 7:25 GMT+11:00, Andrey Kuznetsov :
> Great news! Congratulations!
>
> ср, 28 авг. 2019 г., 18:28 Alex Plehanov :
>
>> Maxim, congratulations!
>>
>> ср, 28 авг. 2019 г. в 18:13, Nikita Amelchev :
>>
>> > My congratulations, Maxim!
>> >
>> > ср, 28 авг. 2019 г. в 18:11, Dmitriy Pavlov :
>> > >
>> > > Dear community,
>> > >
>> > > The Project Management Committee (PMC) for Apache Ignite has invited
>> > Maxim
>> > > Muzafarov to become a committer and we are pleased to announce that
>> > > he
>> > has
>> > > accepted.
>> > >
>> > > PMC recognizes Maxim's efforts in developing file transfer for
>> > rebalancing,
>> > > removal of WAL applying steps from Partition Map Exchange, finding
>> > > and
>> > > fixing non-trivial issues with the product, like mem leaks, and in
>> > setting
>> > > up code inspections and maintaining this process.
>> > >
>> > > 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.
>> > >
>> > > Best regards,
>> > > Dmitriy Pavlov
>> > > on behalf of PMC, Apache Ignite
>> >
>> >
>> >
>> > --
>> > Best wishes,
>> > Amelchev Nikita
>> >
>>
>


-- 
Best regards,
Ivan Pavlukhin

Re: Making Ignite Collaboration 100% Open and Transparent

[Павлухин Иван]

+ Meeting minutes

2019-08-28 22:29 GMT+11:00, Alexey Zinoviev :
> I am totally support the idea with the planned and widely announced Hangout
> meeting between commiters and contributers and posting the link to the
> dev-list with the special Topic Name and short agenda. Maybe, the recorded
> video could be added to the YouTube (or to another platform) to share with
> the community members.
>
> пн, 26 авг. 2019 г. в 22:23, Amit Chavan :
>
>> Hi Denis,
>>
>> I really like the initiative for transparency and collaboration. Are
>> there
>> any plans to help get new contributors up to speed with the project where
>> they can contribute effectively? Sometimes it can be intimidating to
>> start
>> on a large project without some help or advice. Maybe assigning a mentor
>> or
>> an existing committer can be useful or some slack channel people can ping
>> on. I am starting new on the project and have picked out newbie ticket
>> from
>> the Jira board. As I make myself familiar with the code base maybe its
>> good
>> to have some direction on which area should I focus more on etc.
>>
>> Thanks,
>> Amit
>>
>> On Mon, Aug 26, 2019 at 11:54 AM Denis Magda  wrote:
>>
>> > Folks, let me share more details on why Anton started the conversation
>> > about Ignite Slack:
>> >
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
>> >
>> > Recently, a group of GridGain and Sberbank committers of Ignite has met
>> to
>> > discuss how to make our community more transparent and open. Anton and
>> > I
>> > took part in that meeting. The primary problems we see in regards to
>> > transparency and openness are as follows:
>> >
>> >- A lot of discussions on the dev list abrupts suddenly and it's
>> unclear
>> >whether a discussion is abandoned or something else is going on in
>> > the
>> >background with a task/bug/improvement. In many cases, we tend to
>> > fall
>> > back
>> >to faster communication ways like instant messaging, calls, or
>> > face-to-face
>> >meetings that are not visible to the rest of the community. Emails
>> (dev
>> >list) are the right communication channel but not for all of the
>> stages.
>> >- Change reviews seem to be in a chaotic state. Sometimes it takes
>> many
>> >rounds for a committer to urge another committer to do a review. In
>> many
>> >cases, the other committer might be simply overwhelmed with regular
>> > tasks
>> >imposed by an employer. It will be good to come up with some public
>> >tracking approach that will help us all to see who and when will be
>> > able to
>> >review certain changes and make them to Ignite.
>> >
>> > To address the problems we want to propose the following:
>> >
>> >- Keep using dev list the way you do today. No changes need to be
>> > done
>> >here.
>> >- Introduce Ignite Slack for instant messaging across all the
>> community
>> >members who are obviously employed by different companies. Ignite
>> > PMC
>> > will
>> >be managing channels for various topics. Go to Slack when email (dev
>> > list)
>> >conversation is no longer effective, the way we do daily, no need to
>> >complicate our lives just because we work on an open-source project
>> >together.
>> >- Two or more committers need to talk verbally? Go ahead and
>> > schedule
>> a
>> >meeting with Google Hangouts or another tool. Send an invite to the
>> dev
>> >list for those who'd like to join and listen or share opinion. Want
>> > to
>> > talk
>> >in your native language? Go ahead and put a disclaimer that a
>> > conversation
>> >will be in Chinese, Russia, French, whatever. Simple and open.
>> >- Don't know how soon you'll be able to review some changes and,
>> > thus,
>> >ignoring other committers requests? GridGain and Sberbank are ready
>> > to
>> >propose a solution here. Both vendors use an approach to cooperate
>> > between
>> >GridGain and Sberbank committers. Now we'd like to make it fully
>> > open
>> > and
>> >adjust for community needs if required.
>> >
>> > Thoughts, suggestions? I think we'll schedule a community meeting to
>> finish
>> > the conversation or discuss any cornerstone points. But start with your
>> > questions first.
>> >
>> > -
>> > Denis
>> >
>>
>


-- 
Best regards,
Ivan Pavlukhin

Re: New Сommitter: Maxim Muzafarov

[Andrey Kuznetsov]

Great news! Congratulations!

ср, 28 авг. 2019 г., 18:28 Alex Plehanov :

> Maxim, congratulations!
>
> ср, 28 авг. 2019 г. в 18:13, Nikita Amelchev :
>
> > My congratulations, Maxim!
> >
> > ср, 28 авг. 2019 г. в 18:11, Dmitriy Pavlov :
> > >
> > > Dear community,
> > >
> > > The Project Management Committee (PMC) for Apache Ignite has invited
> > Maxim
> > > Muzafarov to become a committer and we are pleased to announce that he
> > has
> > > accepted.
> > >
> > > PMC recognizes Maxim's efforts in developing file transfer for
> > rebalancing,
> > > removal of WAL applying steps from Partition Map Exchange, finding and
> > > fixing non-trivial issues with the product, like mem leaks, and in
> > setting
> > > up code inspections and maintaining this process.
> > >
> > > 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.
> > >
> > > Best regards,
> > > Dmitriy Pavlov
> > > on behalf of PMC, Apache Ignite
> >
> >
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >
>

Re: New Сommitter: Maxim Muzafarov

[Alex Plehanov]

Maxim, congratulations!

ср, 28 авг. 2019 г. в 18:13, Nikita Amelchev :

> My congratulations, Maxim!
>
> ср, 28 авг. 2019 г. в 18:11, Dmitriy Pavlov :
> >
> > Dear community,
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> Maxim
> > Muzafarov to become a committer and we are pleased to announce that he
> has
> > accepted.
> >
> > PMC recognizes Maxim's efforts in developing file transfer for
> rebalancing,
> > removal of WAL applying steps from Partition Map Exchange, finding and
> > fixing non-trivial issues with the product, like mem leaks, and in
> setting
> > up code inspections and maintaining this process.
> >
> > 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.
> >
> > Best regards,
> > Dmitriy Pavlov
> > on behalf of PMC, Apache Ignite
>
>
>
> --
> Best wishes,
> Amelchev Nikita
>

Re: Wiki permissions

[Nikita Amelchev]

Dmitriy, thank you!

ср, 28 авг. 2019 г. в 18:13, Dmitriy Pavlov :
>
> Hi Nikita,
>
> granted, please check.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 28 авг. 2019 г. в 17:44, Nikita Amelchev :
>
> > Hi, Igniters.
> >
> > I'm going to implement ability to rotate master encryption key (TDE Phase
> > 2).
> >
> > Could you grant me permissions to edit wiki about it?
> >
> > My wiki login is 'nsamelchev'.
> >
> > --
> > Best wishes,
> > Amelchev Nikita
> >



-- 
Best wishes,
Amelchev Nikita

Re: Wiki permissions

[Dmitriy Pavlov]

Hi Nikita,

granted, please check.

Sincerely,
Dmitriy Pavlov

ср, 28 авг. 2019 г. в 17:44, Nikita Amelchev :

> Hi, Igniters.
>
> I'm going to implement ability to rotate master encryption key (TDE Phase
> 2).
>
> Could you grant me permissions to edit wiki about it?
>
> My wiki login is 'nsamelchev'.
>
> --
> Best wishes,
> Amelchev Nikita
>

Re: New Сommitter: Maxim Muzafarov

[Nikita Amelchev]

My congratulations, Maxim!

ср, 28 авг. 2019 г. в 18:11, Dmitriy Pavlov :
>
> Dear community,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Maxim
> Muzafarov to become a committer and we are pleased to announce that he has
> accepted.
>
> PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
> removal of WAL applying steps from Partition Map Exchange, finding and
> fixing non-trivial issues with the product, like mem leaks, and in setting
> up code inspections and maintaining this process.
>
> 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.
>
> Best regards,
> Dmitriy Pavlov
> on behalf of PMC, Apache Ignite



-- 
Best wishes,
Amelchev Nikita

New Сommitter: Maxim Muzafarov

[Dmitriy Pavlov]

Dear community,

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

PMC recognizes Maxim's efforts in developing file transfer for rebalancing,
removal of WAL applying steps from Partition Map Exchange, finding and
fixing non-trivial issues with the product, like mem leaks, and in setting
up code inspections and maintaining this process.

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.

Best regards,
Dmitriy Pavlov
on behalf of PMC, Apache Ignite

Wiki permissions

[Nikita Amelchev]

Hi, Igniters.

I'm going to implement ability to rotate master encryption key (TDE Phase 2).

Could you grant me permissions to edit wiki about it?

My wiki login is 'nsamelchev'.

-- 
Best wishes,
Amelchev Nikita

Re: Hello

[Dmitriy Pavlov]

Hi Yuriy,

I've added your account to contributors list, now you can assign an issue
to yourself.

Please see the short guide on how to start contributing here
https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite
and
full guide here
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Should you have any questions don't hesitate to contact the community here.

Unfortunately for text queries, there are no maintainers and I'm not sure
about our vision about the future of this module in Apache Ignite. It may
worth to start a separate discussion about changes proposed. I also suggest
using an email with the subject containing GridLuceneIndex &
QueryTextFiled, so experts may notice this email and chime in.

Sincerely,
Dmitriy Pavlov

ср, 28 авг. 2019 г. в 16:54, Yuriy Shuliga :

> UPD:
> Jira ID:  Yuriy_Shuliha
> To whom it may concern, please add me as contributor
> 
> Yuriy
>
> -- Forwarded message -
> Від: Yuriy Shuliga 
> Date: ср, 28 серп. 2019 о 16:03
> Subject: Hello
> To: 
>
>
> Dear Ignite Team!
>
> My name is Yuriy Shuliha,
> My current work is dedicated to Search services for various businesses.
> Now we are working with Ignite as main computation facility, and are
> interested in development of its TextQuery capabilities backed up by
> Lucene inside.
>
> My contribution goal is to extend GridLuceneIndex functionality by :
> 1)  Ability to set limits to returned TopDocs.
> 2) Adding Sort fields to index/query (potentially via new annotation)
> 3) Adding Boost to certain indexed fields (by @QueryTextFiled annotation
> extending)
>
> Looking forward to productive  collaboration!
>
> Yuriy Shluiha
>

[jira] [Created] (IGNITE-12119) Peer Class Loading has no retries

[Ivan Bessonov (Jira)]

Ivan Bessonov created IGNITE-12119:
--

 Summary: Peer Class Loading has no retries
 Key: IGNITE-12119
 URL: https://issues.apache.org/jira/browse/IGNITE-12119
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
 Fix For: 2.8


That's it. Peer Class Loading has short timeout and no retries, and if it 
fails, loading of class will not be reattempted.

I believe this is in part because GridDeploymentClassLoader is a class loader. 
If it throws ClassNotFoundException when asked to load class, JVM will take 
notice and not reattempt to load this class, even if error was transient.

Proposed amendments:
 * Increase timeouts, introduce immediate retries.

 * See if we can report transient class loading issue to JVM.

 * If all failed, we need to mark class loader as invalid when timeout occurs, 
phase out its usage and create a new class loader which will reattempt to load 
this class later.

Please note that extended waiting in class loader is not recommended because it 
can cause grid to stall.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-12118) Preload MVCC entries using batch insert into page memory.

[Pavel Pereslegin (Jira)]

Pavel Pereslegin created IGNITE-12118:
-

 Summary: Preload MVCC entries using batch insert into page memory.
 Key: IGNITE-12118
 URL: https://issues.apache.org/jira/browse/IGNITE-12118
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Pereslegin


IGNITE-11584 introduces the ability to insert a collection of data rows into 
the row store (see {{RowStore#addRows}} and 
{{AbstractFreeList#insertDataRows}})).
This method is on average faster than sequential insertion using {{addRow}} and 
should be used for MVCC preloading ({{mvccPreloadEntries}}) similarly to the 
tx/atomic preloading ({{preloadEntries}}).



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Fwd: Hello

[Yuriy Shuliga]

UPD:
Jira ID:  Yuriy_Shuliha
To whom it may concern, please add me as contributor

Yuriy

-- Forwarded message -
Від: Yuriy Shuliga 
Date: ср, 28 серп. 2019 о 16:03
Subject: Hello
To: 


Dear Ignite Team!

My name is Yuriy Shuliha,
My current work is dedicated to Search services for various businesses.
Now we are working with Ignite as main computation facility, and are
interested in development of its TextQuery capabilities backed up by
Lucene inside.

My contribution goal is to extend GridLuceneIndex functionality by :
1)  Ability to set limits to returned TopDocs.
2) Adding Sort fields to index/query (potentially via new annotation)
3) Adding Boost to certain indexed fields (by @QueryTextFiled annotation
extending)

Looking forward to productive  collaboration!

Yuriy Shluiha

Hello

[Yuriy Shuliga]

Dear Ignite Team!

My name is Yuriy Shuliha,
My current work is dedicated to Search services for various businesses.
Now we are working with Ignite as main computation facility, and are
interested in development of its TextQuery capabilities backed up by
Lucene inside.

My contribution goal is to extend GridLuceneIndex functionality by :
1)  Ability to set limits to returned TopDocs.
2) Adding Sort fields to index/query (potentially via new annotation)
3) Adding Boost to certain indexed fields (by @QueryTextFiled annotation
extending)

Looking forward to productive  collaboration!

Yuriy Shluiha

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Nikolay Izhikov]

Separate repos for different Spark version is a good idea for me.
Anyway, can you help with Spark version migration,  for now?

В Ср, 28/08/2019 в 15:20 +0300, Alexey Zinoviev пишет:
> Maybe the best solution today add for each new version of Spark the
> sub-module (Spark-2.3, Spark-2.4) or the separate repository with modules
> for each version or another way with separate repository and different
> branches like in  https://github.com/datastax/spark-cassandra-connector
> 
> 3 ways to support different versions with the different costs of support
> 
> In the case of separate repository I could help, for example
> 
> ср, 28 авг. 2019 г. в 14:57, Nikolay Izhikov :
> 
> > Hello, Alexey.
> > 
> > > But the
> > > compatibility with Spark 2.3 will be broken, isn't it?
> > 
> > Yes.
> > 
> > > Do you have any
> > > plans to support the different version of Spark without loosing your
> > 
> > unique
> > > expertise in Spark-Ignite integration?
> > 
> > What do you mean by "my unique expertise"? :)
> > 
> > How do you see support of several Spark version?
> > 
> > 
> > В Ср, 28/08/2019 в 14:29 +0300, Alexey Zinoviev пишет:
> > > Dear Nikolay Izhikov
> > > Are you going to update the Ignite-Spark integration for Spark 2.4. But
> > 
> > the
> > > compatibility with Spark 2.3 will be broken, isn't it? Do you have any
> > > plans to support the different version of Spark without loosing your
> > 
> > unique
> > > expertise in Spark-Ignite integration?
> > > 
> > > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
> > > 
> > > > Hello, Igniters.
> > > > 
> > > > I try to upgrade Spark version but failed.
> > > > 
> > > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > > > changed a lot.
> > > > So it will take some time to upgrade version.
> > > > 
> > > > For now, I work hard to complete the second phase of IEP-35 so I
> > 
> > postpone
> > > > upgrade Spark version to Ignite 2.8.
> > > > 
> > > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > > > Hi Denis,
> > > > > 
> > > > > Sure, since code freeze is planned for today, I don't mind to include
> > > > 
> > > > this
> > > > > bug.
> > > > > 
> > > > > Ivan, could you complete this issue by 20 August?
> > > > > 
> > > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > > > > 
> > > > > BTW #2, FYI, release page is now available here
> > > > > 
> > 
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > > > > 
> > > > > BTW #3, FYI, release related test PR is here
> > > > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > > > 
> > > > here:
> > > > > 
> > > > 
> > > > 
> > 
> > https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=ignite-2.7.6&action=Latest&baseBranchForTc=ignite-2.7.6
> > > > > 
> > > > > 
> > > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > > > > 
> > > > > > An Ignite user just reported a silly issue that needs to be fixed
> > 
> > in
> > > > 
> > > > 2.7.6:
> > > > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > > > > 
> > > > > > More details and context:
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > > > > 
> > > > > > Ivan, please help us to make it to the release.
> > > > > > 
> > > > > > -
> > > > > > Denis
> > > > > > 
> > > > > > 
> > > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda 
> > 
> > wrote:
> > > > > > 
> > > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > > > 
> > > > definitely be
> > > > > > > added the scope and treated one of the main release drivers.
> > > > > > > 
> > > > > > > Dmitry, please let us know once the release wiki page is ready so
> > > > 
> > > > that we
> > > > > > > can finalize the timelines based on chosen scope.
> > > > > > > 
> > > > > > > -
> > > > > > > Denis
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
> > 
> > dpav...@apache.org>
> > > > > > 
> > > > > > wrote:
> > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Thanks to everyone, who participated in the discussion.
> > > > > > > > 
> > > > > > > > I would like to wait also fix for
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > > > > 
> > > > > > > > and discussion results for that issue:
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Since some issues are still open, we'll probably move some
> > 
> > dates
> > > > > > 
> > > > > > forward,
> > > > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > > > > 
> > > > > > > > I consider now the scope is frozen - no new featu

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Alexey Zinoviev]

Maybe the best solution today add for each new version of Spark the
sub-module (Spark-2.3, Spark-2.4) or the separate repository with modules
for each version or another way with separate repository and different
branches like in  https://github.com/datastax/spark-cassandra-connector

3 ways to support different versions with the different costs of support

In the case of separate repository I could help, for example

ср, 28 авг. 2019 г. в 14:57, Nikolay Izhikov :

> Hello, Alexey.
>
> > But the
> > compatibility with Spark 2.3 will be broken, isn't it?
>
> Yes.
>
> > Do you have any
> > plans to support the different version of Spark without loosing your
> unique
> > expertise in Spark-Ignite integration?
>
> What do you mean by "my unique expertise"? :)
>
> How do you see support of several Spark version?
>
>
> В Ср, 28/08/2019 в 14:29 +0300, Alexey Zinoviev пишет:
> > Dear Nikolay Izhikov
> > Are you going to update the Ignite-Spark integration for Spark 2.4. But
> the
> > compatibility with Spark 2.3 will be broken, isn't it? Do you have any
> > plans to support the different version of Spark without loosing your
> unique
> > expertise in Spark-Ignite integration?
> >
> > чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
> >
> > > Hello, Igniters.
> > >
> > > I try to upgrade Spark version but failed.
> > >
> > > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > > changed a lot.
> > > So it will take some time to upgrade version.
> > >
> > > For now, I work hard to complete the second phase of IEP-35 so I
> postpone
> > > upgrade Spark version to Ignite 2.8.
> > >
> > > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > > Hi Denis,
> > > >
> > > > Sure, since code freeze is planned for today, I don't mind to include
> > >
> > > this
> > > > bug.
> > > >
> > > > Ivan, could you complete this issue by 20 August?
> > > >
> > > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > > >
> > > > BTW #2, FYI, release page is now available here
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > > >
> > > > BTW #3, FYI, release related test PR is here
> > > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > >
> > > here:
> > > >
> > >
> > >
> https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=ignite-2.7.6&action=Latest&baseBranchForTc=ignite-2.7.6
> > > >
> > > >
> > > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > > >
> > > > > An Ignite user just reported a silly issue that needs to be fixed
> in
> > >
> > > 2.7.6:
> > > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > > >
> > > > > More details and context:
> > > > >
> > > > >
> > >
> > >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > > >
> > > > > Ivan, please help us to make it to the release.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda 
> wrote:
> > > > >
> > > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > >
> > > definitely be
> > > > > > added the scope and treated one of the main release drivers.
> > > > > >
> > > > > > Dmitry, please let us know once the release wiki page is ready so
> > >
> > > that we
> > > > > > can finalize the timelines based on chosen scope.
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov <
> dpav...@apache.org>
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks to everyone, who participated in the discussion.
> > > > > > >
> > > > > > > I would like to wait also fix for
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > > >
> > > > > > > and discussion results for that issue:
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > > >
> > > > > > >
> > > > > > > Since some issues are still open, we'll probably move some
> dates
> > > > >
> > > > > forward,
> > > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > > >
> > > > > > > I consider now the scope is frozen - no new feature can be
> added
> > >
> > > to the
> > > > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > > > >
> > > > > > > Sincerely,
> > > > > > > Dmitriy Pavlov
> > > > > > >
> > > > > > > See
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > > > for
> > > > > > > more details.
> > > > > > >
> > > > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > > > >  > > > > > > > :
> > > > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > > > CorruptedTreeException in some scenario.
> > > > > > > >
> > > > 

Re: [Discussion] Documentation process improvement: Release notes

[Dmitriy Pavlov]

Hi Igniters,

Fields are available in JIRA now, so for 2.7.6 I applied this new process
and moved all Release Notes from txt file back to JIRA field:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6#ApacheIgnite2.7.6-ReleaseNotes


Now Release Manager can easily track which changes still need to be added
to the Release notes (all new tickets will have set flag).

I also suggest adding 'Release Notes Required' flag to all 2.8 assigned
changes.

Sincerely,
Dmitriy Pavlov

вт, 27 авг. 2019 г. в 14:51, Dmitriy Pavlov :

> Hi Igniters,
>
> Thanks to everyone, https://issues.apache.org/jira/browse/INFRA-18944 created.
> For relatively small releases like 2.7.5,2.7.6, it is ok to collect RN
> manually, but for a major release, I assume we need a separate field for it.
>
> I also found not completed issue, which could benefit from separate field
> creation:
> https://issues.apache.org/jira/browse/IGNITE-5355
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 20 мая 2019 г. в 18:30, Garrett Alley :
>
>> I like the flag, it would help cut down on the work involved in creating
>> the release notes. Eventually, we may want to group the fixes "by
>> component" in the release notes.
>>
>> -g-
>>
>> On Mon, May 20, 2019 at 4:28 AM Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>
>> wrote:
>>
>> > Hello!
>> >
>> > I think it definitely makes sense to have Release Notes field in JIRA
>> > tickets (start using it if it is already present?). Not sure about the
>> > flag.
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > пн, 20 мая 2019 г. в 13:23, Dmitriy Pavlov :
>> >
>> > > Hi Ignite Developers,
>> > >
>> > > Kindly Reminder, please review the proposed changes and share your
>> > vision.
>> > > I would appreciate if this change will be approved by community
>> members,
>> > > but not via silence.
>> > >
>> > > Sincerely
>> > > Dmitriy Pavlov
>> > >
>> > > вт, 14 мая 2019 г. в 15:19, Dmitriy Pavlov :
>> > >
>> > > > Hi Igniters,
>> > > >
>> > > > During the preparation of release candidate 2.7.5, I’ve missed the
>> > > > development of Release notes for it, and this caused delay for a
>> vote.
>> > > >
>> > > > I want to suggest simple changes in our documentation process. Some
>> > time
>> > > > ago Artem B. proposed similar for the doc, but I would like to
>> adapt it
>> > > for
>> > > > release notes.
>> > > >
>> > > > Let us
>> > > > - Enrich Ignite flags with 'Release Notes required' flag (default
>> is,
>> > as
>> > > > always, true)
>> > > > - Add field 'Release Notes' to Ignite project.
>> > > >
>> > > > All tickets with empty Release Notes fields but with flag set may be
>> > > > checked with contributor if it needs to be mentioned in
>> > > RELEASE_NOTES.txt.
>> > > >
>> > > > If we agree on these changes, I’ll ask infra to add these fields in
>> 3
>> > > > days.
>> > > >
>> > > > Sincerely,
>> > > > Dmitriy Pavlov
>> > > >
>> > > >
>> > >
>> >
>>
>

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Nikolay Izhikov]

Hello, Alexey.

> But the
> compatibility with Spark 2.3 will be broken, isn't it?

Yes.

> Do you have any
> plans to support the different version of Spark without loosing your unique
> expertise in Spark-Ignite integration?

What do you mean by "my unique expertise"? :)

How do you see support of several Spark version?


В Ср, 28/08/2019 в 14:29 +0300, Alexey Zinoviev пишет:
> Dear Nikolay Izhikov
> Are you going to update the Ignite-Spark integration for Spark 2.4. But the
> compatibility with Spark 2.3 will be broken, isn't it? Do you have any
> plans to support the different version of Spark without loosing your unique
> expertise in Spark-Ignite integration?
> 
> чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :
> 
> > Hello, Igniters.
> > 
> > I try to upgrade Spark version but failed.
> > 
> > Seems, internal Spark API(External Catalog, SQL planner) that we use
> > changed a lot.
> > So it will take some time to upgrade version.
> > 
> > For now, I work hard to complete the second phase of IEP-35 so I postpone
> > upgrade Spark version to Ignite 2.8.
> > 
> > В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > > Hi Denis,
> > > 
> > > Sure, since code freeze is planned for today, I don't mind to include
> > 
> > this
> > > bug.
> > > 
> > > Ivan, could you complete this issue by 20 August?
> > > 
> > > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> > > 
> > > BTW #2, FYI, release page is now available here
> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> > > 
> > > BTW #3, FYI, release related test PR is here
> > > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> > 
> > here:
> > > 
> > 
> > https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=ignite-2.7.6&action=Latest&baseBranchForTc=ignite-2.7.6
> > > 
> > > 
> > > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> > > 
> > > > An Ignite user just reported a silly issue that needs to be fixed in
> > 
> > 2.7.6:
> > > > https://issues.apache.org/jira/browse/IGNITE-12068
> > > > 
> > > > More details and context:
> > > > 
> > > > 
> > 
> > https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > > > 
> > > > Ivan, please help us to make it to the release.
> > > > 
> > > > -
> > > > Denis
> > > > 
> > > > 
> > > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:
> > > > 
> > > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> > 
> > definitely be
> > > > > added the scope and treated one of the main release drivers.
> > > > > 
> > > > > Dmitry, please let us know once the release wiki page is ready so
> > 
> > that we
> > > > > can finalize the timelines based on chosen scope.
> > > > > 
> > > > > -
> > > > > Denis
> > > > > 
> > > > > 
> > > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov 
> > > > 
> > > > wrote:
> > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > Thanks to everyone, who participated in the discussion.
> > > > > > 
> > > > > > I would like to wait also fix for
> > > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > > > 
> > > > > > and discussion results for that issue:
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > > > 
> > > > > > 
> > > > > > Since some issues are still open, we'll probably move some dates
> > > > 
> > > > forward,
> > > > > > but it seems we managed to discuss scope before scope freeze.
> > > > > > 
> > > > > > I consider now the scope is frozen - no new feature can be added
> > 
> > to the
> > > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > > > 
> > > > > > Sincerely,
> > > > > > Dmitriy Pavlov
> > > > > > 
> > > > > > See
> > 
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > > for
> > > > > > more details.
> > > > > > 
> > > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > > >  > > > > > > :
> > > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > > CorruptedTreeException in some scenario.
> > > > > > > 
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi all,
> > > > > > > > Can we include
> > 
> > https://issues.apache.org/jira/browse/IGNITE-12060 ?
> > > > > > > 
> > > > > > > This is
> > > > > > > > a  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > > > 
> > > > > > > > On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> > > > 
> > > > nizhi...@apache.org
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > > Hello, Deni.
> > > > > > > > > 
> > > > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > > > 
> > > > > > > > > Yes, I will take a look.
> > > > > > > > > 
> > > > > > 

Re: Making Ignite Collaboration 100% Open and Transparent

[Alexey Zinoviev]

I am totally support the idea with the planned and widely announced Hangout
meeting between commiters and contributers and posting the link to the
dev-list with the special Topic Name and short agenda. Maybe, the recorded
video could be added to the YouTube (or to another platform) to share with
the community members.

пн, 26 авг. 2019 г. в 22:23, Amit Chavan :

> Hi Denis,
>
> I really like the initiative for transparency and collaboration. Are there
> any plans to help get new contributors up to speed with the project where
> they can contribute effectively? Sometimes it can be intimidating to start
> on a large project without some help or advice. Maybe assigning a mentor or
> an existing committer can be useful or some slack channel people can ping
> on. I am starting new on the project and have picked out newbie ticket from
> the Jira board. As I make myself familiar with the code base maybe its good
> to have some direction on which area should I focus more on etc.
>
> Thanks,
> Amit
>
> On Mon, Aug 26, 2019 at 11:54 AM Denis Magda  wrote:
>
> > Folks, let me share more details on why Anton started the conversation
> > about Ignite Slack:
> >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/The-ASF-Slack-td43233.html
> >
> > Recently, a group of GridGain and Sberbank committers of Ignite has met
> to
> > discuss how to make our community more transparent and open. Anton and I
> > took part in that meeting. The primary problems we see in regards to
> > transparency and openness are as follows:
> >
> >- A lot of discussions on the dev list abrupts suddenly and it's
> unclear
> >whether a discussion is abandoned or something else is going on in the
> >background with a task/bug/improvement. In many cases, we tend to fall
> > back
> >to faster communication ways like instant messaging, calls, or
> > face-to-face
> >meetings that are not visible to the rest of the community. Emails
> (dev
> >list) are the right communication channel but not for all of the
> stages.
> >- Change reviews seem to be in a chaotic state. Sometimes it takes
> many
> >rounds for a committer to urge another committer to do a review. In
> many
> >cases, the other committer might be simply overwhelmed with regular
> > tasks
> >imposed by an employer. It will be good to come up with some public
> >tracking approach that will help us all to see who and when will be
> > able to
> >review certain changes and make them to Ignite.
> >
> > To address the problems we want to propose the following:
> >
> >- Keep using dev list the way you do today. No changes need to be done
> >here.
> >- Introduce Ignite Slack for instant messaging across all the
> community
> >members who are obviously employed by different companies. Ignite PMC
> > will
> >be managing channels for various topics. Go to Slack when email (dev
> > list)
> >conversation is no longer effective, the way we do daily, no need to
> >complicate our lives just because we work on an open-source project
> >together.
> >- Two or more committers need to talk verbally? Go ahead and schedule
> a
> >meeting with Google Hangouts or another tool. Send an invite to the
> dev
> >list for those who'd like to join and listen or share opinion. Want to
> > talk
> >in your native language? Go ahead and put a disclaimer that a
> > conversation
> >will be in Chinese, Russia, French, whatever. Simple and open.
> >- Don't know how soon you'll be able to review some changes and, thus,
> >ignoring other committers requests? GridGain and Sberbank are ready to
> >propose a solution here. Both vendors use an approach to cooperate
> > between
> >GridGain and Sberbank committers. Now we'd like to make it fully open
> > and
> >adjust for community needs if required.
> >
> > Thoughts, suggestions? I think we'll schedule a community meeting to
> finish
> > the conversation or discuss any cornerstone points. But start with your
> > questions first.
> >
> > -
> > Denis
> >
>

Re: Re[2]: Apache Ignite 2.7.6 (Time, Scope, and Release manager)

[Alexey Zinoviev]

Dear Nikolay Izhikov
Are you going to update the Ignite-Spark integration for Spark 2.4. But the
compatibility with Spark 2.3 will be broken, isn't it? Do you have any
plans to support the different version of Spark without loosing your unique
expertise in Spark-Ignite integration?

чт, 15 авг. 2019 г. в 14:54, Nikolay Izhikov :

> Hello, Igniters.
>
> I try to upgrade Spark version but failed.
>
> Seems, internal Spark API(External Catalog, SQL planner) that we use
> changed a lot.
> So it will take some time to upgrade version.
>
> For now, I work hard to complete the second phase of IEP-35 so I postpone
> upgrade Spark version to Ignite 2.8.
>
> В Чт, 15/08/2019 в 14:51 +0300, Dmitriy Pavlov пишет:
> > Hi Denis,
> >
> > Sure, since code freeze is planned for today, I don't mind to include
> this
> > bug.
> >
> > Ivan, could you complete this issue by 20 August?
> >
> > BTW #1, Dmitriy Govoruchnin, please reply about commit for
> > https://issues.apache.org/jira/browse/IGNITE-11953?src=confmacro
> >
> > BTW #2, FYI, release page is now available here
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6
> >
> > BTW #3, FYI, release related test PR is here
> > https://github.com/apache/ignite/pull/6775 and it's TC Bot report is
> here:
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache&suiteId=IgniteTests24Java8_RunAll&branchForTc=ignite-2.7.6&action=Latest&baseBranchForTc=ignite-2.7.6
> >
> >
> > чт, 15 авг. 2019 г. в 13:55, Denis Magda :
> >
> > > An Ignite user just reported a silly issue that needs to be fixed in
> 2.7.6:
> > > https://issues.apache.org/jira/browse/IGNITE-12068
> > >
> > > More details and context:
> > >
> > >
> https://stackoverflow.com/questions/57479636/simple-select-query-missing-rows-in-ignite
> > >
> > > Ivan, please help us to make it to the release.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Aug 13, 2019 at 6:47 AM Denis Magda  wrote:
> > >
> > > > IGNITE-12507 (Persistence files are stored to temp dir) has
> definitely be
> > > > added the scope and treated one of the main release drivers.
> > > >
> > > > Dmitry, please let us know once the release wiki page is ready so
> that we
> > > > can finalize the timelines based on chosen scope.
> > > >
> > > > -
> > > > Denis
> > > >
> > > >
> > > > On Mon, Aug 12, 2019 at 7:12 PM Dmitriy Pavlov 
> > >
> > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Thanks to everyone, who participated in the discussion.
> > > > >
> > > > > I would like to wait also fix for
> > > > > https://issues.apache.org/jira/browse/IGNITE-12057
> > > > >
> > > > > and discussion results for that issue:
> > > > >
> > > > >
> > >
> > >
> https://lists.apache.org/thread.html/498a14b3971950a45ef57f45cc23d2438ce1afba000b586e230927bf@%3Cdev.ignite.apache.org%3E
> > > > >
> > > > >
> > > > > Since some issues are still open, we'll probably move some dates
> > >
> > > forward,
> > > > > but it seems we managed to discuss scope before scope freeze.
> > > > >
> > > > > I consider now the scope is frozen - no new feature can be added
> to the
> > > > > scope of 2.7.6. We're entering the rampdown phase.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > See
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > > > > for
> > > > > more details.
> > > > >
> > > > > пн, 12 авг. 2019 г. в 16:37, Zhenya Stanilovsky
> > > > >  > > > > > :
> > > > > > Hi al,, i also suggest to append [1], cause it could produce
> > > > > > CorruptedTreeException in some scenario.
> > > > > >
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12061
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > > Can we include
> https://issues.apache.org/jira/browse/IGNITE-12060 ?
> > > > > >
> > > > > > This is
> > > > > > > a  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > >
> > > > > > > On Fri, Aug 9, 2019 at 10:04 AM Nikolay Izhikov <
> > >
> > > nizhi...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > Hello, Deni.
> > > > > > > >
> > > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > >
> > > > > > > > Yes, I will take a look.
> > > > > > > >
> > > > > > > >
> > > > > > > > В Чт, 08/08/2019 в 11:08 -0700, Denis Magda пишет:
> > > > > > > > > Dmitry,
> > > > > > > > >
> > > > > > > > > Please add this BTree corruption fix to the scope:
> > > > > > > > >  https://issues.apache.org/jira/browse/IGNITE-11953
> > > > > > > > >
> > > > > > > > > Plus, I would upgrade our Spark integration to version 2.4
> as
> > >
> > > long
> > > > > as
> > > > > > 2.3
> > > > > > > > > goes with limitations reported by our users:
> > > > > > > > >  https://issues.apache.org/jira/browse/IGNITE-12054
> > > > > > > > >
> > > > > > > > > Nickolay, could you check if that's a quick upgrade?
> > > > > > > > >
> > > > > > > > > -
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Aug 8, 2019 at 10:40

Re: Thin client: transactions support

[Alex Plehanov]

Pavel, we already have OdbcEnabled, JdbcEnabled and ThinClientEnabled
properties inside ClientConnectorConfiguration. ThinClientEnabled=false
does not assume that JDBC thin client is disabled, it's clear and not
confusing. I'm not agreed that the same situation with
ThinClientConfiguration will be confusing, the same logic works here as for
ThinClientEnabled flag. At least we can add JavaDoc that this configuration
is not related to JDBC and ODBC, but I think it's redundant.

ср, 28 авг. 2019 г. в 12:41, Pavel Tupitsyn :

> ThinClientConfiguration name is very confusing in existing situation.
> E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy to
> assume it does.
>
> On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov 
> wrote:
>
> > Ilya, Igor,
> >
> > Nested property is what exactly I've done in the last fix.
> > ClientConnectorConfiguration now includes ThinClientConfiguration which
> > contain only one property MaxActiveTxPerConnection for now.
> >
> > Pavel,
> >
> > Why do you think that nested ThinClientConfiguration is more confusing
> than
> > property in common configuration which related only to part of
> configurable
> > elements? In case of nested configuration, user will know that property
> is
> > related only to thin client even without reference to JavaDoc.
> > Now it's only one such property, but if continue to introduce specific
> > properties to the common configuration in the future, after a while there
> > will be a mess.
> >
> >
> > вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > I think the nested property approach is correct. Sorry for causing the
> > > confusion.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
> > >
> > > > Ilya,
> > > >
> > > > Sorry, I've just got your first message wrong. I though, you were
> > > > proposing to remove ClientConnectorConfiguration altogether, my bad.
> > > >
> > > > Now, about separating ClientConnectorConfiguration and - I do not
> > > > propose to make it a copy with the same options. What I was proposing
> > > > is to keep common settings in ClientConnectorConfiguration and place
> > > > thin client specific things in a separate class which is going to be
> > > nested
> > > > as a property of ClientConnectorConfiguration.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > I don't see why it should break backward compatibility and
> protocol.
> > > Can
> > > > > you please elaborate? I imagine that Thin client with TX muxing
> > support
> > > > > will just send different requests to which server will respond
> > > > differently.
> > > > > Why would anything break?
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > > > >
> > > > > > Ilya,
> > > > > >
> > > > > > This will break backward compatibility and probably protocol, and
> > > this
> > > > is
> > > > > > not something we should discuss in the context of this specific
> > task.
> > > > > More
> > > > > > like this is a topic for 3.0 wishlist.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > > > ilya.kasnach...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Also, let's not add IGNITE_ settings for options that can
> > > reasonably
> > > > be
> > > > > > > configured from IgniteConfiguration. Let's keep it for very
> edge
> > > > cases.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Do we still need to separate client connector configuration
> > from
> > > > thin
> > > > > > > > connector configuration from ODBC connector configuration?
> > > > > > > >
> > > > > > > > I think this is a bad practice: For example, people often
> turn
> > on
> > > > SSL
> > > > > > or
> > > > > > > > auth on just a subset of connectors, think they are secure,
> > when
> > > in
> > > > > > fact
> > > > > > > > they still have unsecured connector around (e.g. ODBC) and
> > their
> > > > data
> > > > > > is
> > > > > > > > not protected at all.
> > > > > > > >
> > > > > > > > It may solve some specific issue that you are facing, but for
> > > > > newcomers
> > > > > > > to
> > > > > > > > project it is a drawback. I think we should seek to not add
> > > > connector
> > > > > > > > configurations anymore.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 23 авг. 2019 г. в 20:49, 

[jira] [Created] (IGNITE-12117) Historical rebalance should not be processed in striped way

[Anton Vinogradov (Jira)]

Anton Vinogradov created IGNITE-12117:
-

 Summary: Historical rebalance should not be processed in striped 
way
 Key: IGNITE-12117
 URL: https://issues.apache.org/jira/browse/IGNITE-12117
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov


We have to investigate is it possible to process historical rebalance like 
regular (using unstriped pool) and if possible then refactor it.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Thin client: transactions support

[Pavel Tupitsyn]

ThinClientConfiguration name is very confusing in existing situation.
E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy to
assume it does.

On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov 
wrote:

> Ilya, Igor,
>
> Nested property is what exactly I've done in the last fix.
> ClientConnectorConfiguration now includes ThinClientConfiguration which
> contain only one property MaxActiveTxPerConnection for now.
>
> Pavel,
>
> Why do you think that nested ThinClientConfiguration is more confusing than
> property in common configuration which related only to part of configurable
> elements? In case of nested configuration, user will know that property is
> related only to thin client even without reference to JavaDoc.
> Now it's only one such property, but if continue to introduce specific
> properties to the common configuration in the future, after a while there
> will be a mess.
>
>
> вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev :
>
> > Hello!
> >
> > I think the nested property approach is correct. Sorry for causing the
> > confusion.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
> >
> > > Ilya,
> > >
> > > Sorry, I've just got your first message wrong. I though, you were
> > > proposing to remove ClientConnectorConfiguration altogether, my bad.
> > >
> > > Now, about separating ClientConnectorConfiguration and - I do not
> > > propose to make it a copy with the same options. What I was proposing
> > > is to keep common settings in ClientConnectorConfiguration and place
> > > thin client specific things in a separate class which is going to be
> > nested
> > > as a property of ClientConnectorConfiguration.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I don't see why it should break backward compatibility and protocol.
> > Can
> > > > you please elaborate? I imagine that Thin client with TX muxing
> support
> > > > will just send different requests to which server will respond
> > > differently.
> > > > Why would anything break?
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > > >
> > > > > Ilya,
> > > > >
> > > > > This will break backward compatibility and probably protocol, and
> > this
> > > is
> > > > > not something we should discuss in the context of this specific
> task.
> > > > More
> > > > > like this is a topic for 3.0 wishlist.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Also, let's not add IGNITE_ settings for options that can
> > reasonably
> > > be
> > > > > > configured from IgniteConfiguration. Let's keep it for very edge
> > > cases.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Do we still need to separate client connector configuration
> from
> > > thin
> > > > > > > connector configuration from ODBC connector configuration?
> > > > > > >
> > > > > > > I think this is a bad practice: For example, people often turn
> on
> > > SSL
> > > > > or
> > > > > > > auth on just a subset of connectors, think they are secure,
> when
> > in
> > > > > fact
> > > > > > > they still have unsecured connector around (e.g. ODBC) and
> their
> > > data
> > > > > is
> > > > > > > not protected at all.
> > > > > > >
> > > > > > > It may solve some specific issue that you are facing, but for
> > > > newcomers
> > > > > > to
> > > > > > > project it is a drawback. I think we should seek to not add
> > > connector
> > > > > > > configurations anymore.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> > > plehanov.a...@gmail.com
> > > > >:
> > > > > > >
> > > > > > >> Pavel,
> > > > > > >>
> > > > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > > > clients,
> > > > > > >> the
> > > > > > >> new property only related to thin clients. If we put the new
> > > > property
> > > > > > >> directly into ClientConnectorConfiguration, someone might
> think
> > > that
> > > > > it
> > > > > > >> also affects JDBC and ODBC.
> > > > > > >>
> > > > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > > > >>
> > > > > > >> > Igor, Alex,
> > > > > > >> >
> > > > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > > > >> > ClientConnectorConfiguration.
> > > > > > >> > Very confusing IMO, because ClientConnectorConfigura

[jira] [Created] (IGNITE-12115) No event on partition exchange failure

[Moti Nisenson-Ken (Jira)]

Moti Nisenson-Ken created IGNITE-12115:
--

 Summary: No event on partition exchange failure
 Key: IGNITE-12115
 URL: https://issues.apache.org/jira/browse/IGNITE-12115
 Project: Ignite
  Issue Type: Bug
Reporter: Moti Nisenson-Ken


Partition exchange failure can (and does) happen for many different reasons - 
when it happens the cluster hangs. Currently, it just gets dumped out to logs. 
An error event should be raised to enable action to be taken; for example, have 
each node restart itself



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (IGNITE-12116) Cache doesn

[Stepachev Maksim (Jira)]

Stepachev Maksim created IGNITE-12116:
-

 Summary: Cache doesn
 Key: IGNITE-12116
 URL: https://issues.apache.org/jira/browse/IGNITE-12116
 Project: Ignite
  Issue Type: Improvement
Reporter: Stepachev Maksim






--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: Cluster ID and tag: identification of the cluster

[Dmitriy Pavlov]

Hi Sergey,

Would cluster tag be isolator of two clusters? E.g. I want in the same
network create 2 clusters, e.g. for educational purposes. Can I select
cTag=dpavlov, cTag=schugunov and these would be independent clusters?

Dmitriy Pavlov

ср, 28 авг. 2019 г. в 11:01, Sergey Chugunov :

> Hello folks,
>
> I would like to propose implementing new properties to identify the cluster
> and simplify managing it by external tools (e.g. custom scripts built on
> top of standard Control Utility).
>
> These properties are Cluster ID (UUID) and Cluster tag (String) exposed
> through existing IgniteCluster public API.
>
> Both properties are generated upon cluster startup (before activation if
> the cluster requires it) and survived restarts if cluster is configured in
> persistent mode and regenerated again if it is an in-memory cluster.
>
> Cluster ID is immutable and useful more for automated tools while Cluster
> tag is mutable (may be changed by user) and is supposed to be human
> readable to view it in any GUI or web-based management solutions.
>
> I already created a ticket [1] with some more technical details and invite
> community to discuss this feature.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12111
> --
> Best Regards,
> Sergey Chugunov.
>

Cluster ID and tag: identification of the cluster

[Sergey Chugunov]

Hello folks,

I would like to propose implementing new properties to identify the cluster
and simplify managing it by external tools (e.g. custom scripts built on
top of standard Control Utility).

These properties are Cluster ID (UUID) and Cluster tag (String) exposed
through existing IgniteCluster public API.

Both properties are generated upon cluster startup (before activation if
the cluster requires it) and survived restarts if cluster is configured in
persistent mode and regenerated again if it is an in-memory cluster.

Cluster ID is immutable and useful more for automated tools while Cluster
tag is mutable (may be changed by user) and is supposed to be human
readable to view it in any GUI or web-based management solutions.

I already created a ticket [1] with some more technical details and invite
community to discuss this feature.

[1] https://issues.apache.org/jira/browse/IGNITE-12111
--
Best Regards,
Sergey Chugunov.

Re: Replacing default work dir from tmp to current dir

[Dmitriy Pavlov]

Denis, we have 2 more tickets to fix before voting:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.6

ср, 28 авг. 2019 г. в 04:57, Denis Magda :

> Ok, seems like we came to a consensus. Let’s ensure that the path for our
> work dir is user.dir/ignite/work and restart the vote.
>
> Denis
>
> On Tuesday, August 27, 2019, Ilya Kasnacheev 
> wrote:
>
> > Hello!
> >
> > I have took the liberty to implement the change to existing code base to
> > remove concern about work/ directory:
> >
> > https://github.com/apache/ignite/pull/6816/files
> >
> > Some advocacy for this patch:
> > - Minimal change.
> > - Storing in user.dir/ignite/work (current directory, e.g. project root)
> > which is consistent with behavior of unzipped binary release.
> > - We can re-use user.dir/ignite for other uses in the future, such as
> > storing logs there.
> >
> > I have to admit that my previous reaction to the change was too strong.
> It
> > turned out the default was user.dir/work (project root) and not
> > user.home/work (home dir with imminent Work collision).
> > Nevertheless, I think that after this change it would be good enough to
> > last for a few years.
> >
> > What do you think?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 27 авг. 2019 г. в 18:28, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > In the current state of the project, we cannot directly compare Ignite
> > > setup process to the one of postgresql or another database. In many
> > Ignite
> > > examples, an embedded node (even with persistence) is started and it is
> > > supposed to run without any additional FS rights grants or init steps.
> > This
> > > may be changed in 3.0, but not in a maintenance release. If we are to
> > > change the directory to /var/lib, I would rather fail Ignite node start
> > > asking a user to explicitly provide work directory path. Let alone
> > /var/lib
> > > is not portable and I would not add an OS-switch to the code for no
> > reason.
> > >
> > > I vote for storing the work in ~/ignite/work - agree with Ilya that
> > writing
> > > large amounts of data in a hidden folder is a bad idea.
> > >
> > > вт, 27 авг. 2019 г. в 15:17, Dmitriy Pavlov :
> > >
> > > > Hi Igniters,
> > > >
> > > > I agree that user home maybe not the best place from Linux
> perspective
> > > and
> > > > philosophy, but  "user.home"/ignite/work  is more or less portable.
> > > >
> > > > For the Linux environment, we can add a suggestion about where to
> place
> > > > persisted data. For very first testing of Apache Ignite user home
> still
> > > > looks good for me.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > вт, 27 авг. 2019 г. в 11:56, Pavel Pereslegin :
> > > >
> > > > > Or instead of a WARNING, we can add a suggestion with a
> > recommendation
> > > > > for the production environment.
> > > > >
> > > > > вт, 27 авг. 2019 г. в 11:41, Petr Ivanov :
> > > > > >
> > > > > > /opt is either does not exist on fresh system, or has the same
> > > > > restriction: no user access without admin intervention.
> > > > > > /usr/local, /var/lib, etc. — all this is implemented in our DEB /
> > RPM
> > > > > packages already.
> > > > > >
> > > > > > For ZIP installation %HOME% seems to be the best approach for
> > > "2-click"
> > > > > launch.
> > > > > > Later user can update preferences and set working dir to whatever
> > > > > directory he would like.
> > > > > >
> > > > > > Also — we can put WARNING message to log noting that WORK_DIR is
> > set
> > > to
> > > > > default.
> > > > > >
> > > > > > > On 27 Aug 2019, at 10:16, Zhenya Stanilovsky
> > > > >  wrote:
> > > > > > >
> > > > > > >
> > > > > > > And what about /opt/ignite ?
> > > > > > >
> > > > > > > copy-paste:
> > > > > > > "
> > > > > > > The basic difference is that  /usr/local  is for software not
> > > managed
> > > > > by the system packager, but still following the standard unix
> > > deployment
> > > > > rules.
> > > > > > > That's why you have  /usr/local/bin ,  /usr/local/sbin
> > > > >  /usr/local/include  etc...
> > > > > > > /opt  on the other hand is for software that doesn't follow
> this
> > > and
> > > > > is deployed in a monolithic fashion. This usually includes
> commercial
> > > > > and/or cross-platform software that is packaged in the "Windows"
> > > style. "
> > > > > > >
> > > > > > >
> > > > > > >> Понедельник, 26 августа 2019, 22:49 +03:00 от Denis Magda <
> > > > > dma...@apache.org>:
> > > > > > >>
> > > > > > >> Igniters,
> > > > > > >>
> > > > > > >> I can't disagree with Nikolay that, as a database, Ignite
> needs
> > to
> > > > > persist
> > > > > > >> changes to a folder different from "user.home" one. But with
> the
> > > > > current
> > > > > > >> rate of project growth and adoption, I would encourage us to
> > > > > eliminate any
> > > > > > >> possible obstacles a user might come across during the getting
> > > > started
> > > > > > >> phase with Ignite. Unfortunately, folders different from
> > >