[jira] [Created] (IGNITE-12019) [TC Bot] PR screen resets the base branch on page refresh

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-12019:
-

 Summary: [TC Bot] PR screen resets the base branch on page refresh
 Key: IGNITE-12019
 URL: https://issues.apache.org/jira/browse/IGNITE-12019
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


Even though 'baseBranchForTc' is already supported by the page, it is not 
picked up because the initial value is '' and the URL is not updated when 
select is updated.

I suggest to update the URL on select change using history object.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[MTCGA]: new failures in builds [4379865] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *Recently contributed test failed in master-nightly 
cache.PartitionedTransactionalOptimisticCacheGetsDistributionTest 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7727280989402544651=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - tkalkir...@yandex.ru 
https://ci.ignite.apache.org/viewModification.html?modId=888452

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 04:25:48 26-07-2019 

Re: Threadpools and .WithExecute() for C# clients

[Raymond Wilson]

Thanks Pavel!

Does the priority on the Jira ticket suggest this will target IA 2.8?

Thanks,
Raymond.

On Wed, Jul 24, 2019 at 8:21 PM Pavel Tupitsyn  wrote:

> Denis, yes, looks like a simple thing to add.
>
> On Tue, Jul 23, 2019 at 10:38 PM Denis Magda  wrote:
>
>> Looping in the dev list.
>>
>> Pavel, Igor and other C# maintainers, this looks like a valuable extension
>> of our C# APIs. Shouldn't this be a quick addition to Ignite?
>>
>> -
>> Denis
>>
>>
>> On Mon, Jul 22, 2019 at 3:22 PM Raymond Wilson <
>> raymond_wil...@trimble.com>
>> wrote:
>>
>> > Alexandr,
>> >
>> > If .WithExecute is not planned to be made available in the C# client,
>> what
>> > is the plan to support custom thread pools from the C# side of things?
>> >
>> > Thanks,
>> > Raymond.
>> >
>> >
>> > On Thu, Jul 18, 2019 at 9:28 AM Raymond Wilson <
>> raymond_wil...@trimble.com>
>> > wrote:
>> >
>> >> The source of inbound requests into Server A is from client
>> applications.
>> >>
>> >> Server B is really a cluster of servers that are performing clustered
>> >> transformations and computations across a data set.
>> >>
>> >> I originally used IComputeJob and similar functions which work very
>> well
>> >> but have the restriction that they return the entire result set from a
>> >> Server B node in a single response. These result sets can be large
>> (100's
>> >> of megabytes and larger), which makes life pretty hard for Server A if
>> it
>> >> has to field multiple incoming responses of this size. So, these types
>> of
>> >> requests progressively send responses back (using Ignite messaging) to
>> >> Server A using the Ignite messaging fabric. As Server A receives each
>> part
>> >> of the overall response it processes it according the business rules
>> >> relevant to the request.
>> >>
>> >> The cluster config and numbers of nodes are not really material to
>> this.
>> >>
>> >> Raymond.
>> >>
>> >> On Thu, Jul 18, 2019 at 12:26 AM Alexandr Shapkin 
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> Can you share a more detailed use case, please?
>> >>>
>> >>>
>> >>>
>> >>> Right now it’s not clear why do you need a messaging fabric.
>> >>>
>> >>> If you are interesting in a progress tracking, then you could try a
>> >>> CacheAPI or QueryContinious, for example.
>> >>>
>> >>>
>> >>>
>> >>> What are the sources of inbound requests? Is it a client requests?
>> >>>
>> >>>
>> >>>
>> >>> What is your cluster config? How many nodes do you have for your
>> >>> distributed computations?
>> >>>
>> >>>
>> >>>
>> >>> *From: *Raymond Wilson 
>> >>> *Sent: *Wednesday, July 17, 2019 1:49 PM
>> >>> *To: *user 
>> >>> *Subject: *Re: Threadpools and .WithExecute() for C# clients
>> >>>
>> >>>
>> >>>
>> >>> Hi Alexandr,
>> >>>
>> >>>
>> >>>
>> >>> To summarise from the original thread, say I have server A that
>> accepts
>> >>> requests. It contacts server B in order to help processing those
>> requests.
>> >>> Server B sends in-progress results to server A using the Ignite
>> messaging
>> >>> fabric. If the thread pool in server A is saturated with inbound
>> requests,
>> >>> then there are no available threads to service the messaging fabric
>> traffic
>> >>> from server B to server A resulting in a deadlock condition.
>> >>>
>> >>>
>> >>>
>> >>> In the original discussion it was suggested creating a custom thread
>> >>> pool to handle the Server B to Server A traffic would resolve it.
>> >>>
>> >>>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Raymond.
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Jul 17, 2019 at 9:48 PM Alexandr Shapkin 
>> >>> wrote:
>> >>>
>> >>> Hi, Raymond!
>> >>>
>> >>>
>> >>>
>> >>> As far as I can see, there are no plans for porting custom executors
>> >>> configuration in .NET client right now [1].
>> >>>
>> >>>
>> >>>
>> >>> Please, remind, why do you need a separate pool instead of a default
>> >>> PublicPool?
>> >>>
>> >>>
>> >>>
>> >>> [1] - https://issues.apache.org/jira/browse/IGNITE-6566
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *From: *Raymond Wilson 
>> >>> *Sent: *Wednesday, July 17, 2019 10:58 AM
>> >>> *To: *user 
>> >>> *Subject: *Threadpools and .WithExecute() for C# clients
>> >>>
>> >>>
>> >>>
>> >>> Some time ago I ran into and issue with thread pool exhaustion and
>> >>> deadlocking in AI 2.2.
>> >>>
>> >>>
>> >>>
>> >>> This is the original thread:
>> >>>
>> http://apache-ignite-users.70518.x6.nabble.com/Possible-dead-lock-when-number-of-jobs-exceeds-thread-pool-td17262.html
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> At the time .WithExecutor() was not implemented in the C# client so
>> >>> there was little option but to expand the size of the public thread
>> pool
>> >>> sufficiently to prevent the deadlocking.
>> >>>
>> >>>
>> >>>
>> >>> We have been revisiting this issue and see that .WithExecutor() is not
>> >>> supported in the AI 2.7.5 client.
>> >>>
>> >>>
>> >>>
>> >>> Can this be supported in the C# client, or is there a workaround in
>> the
>> >>> .Net environment? that does not require this 

[jira] [Created] (IGNITE-12018) Web Agent docker image: 'functions.sh' not found

[Igor Belyakov (JIRA)]

Igor Belyakov created IGNITE-12018:
--

 Summary: Web Agent docker image: 'functions.sh' not found
 Key: IGNITE-12018
 URL: https://issues.apache.org/jira/browse/IGNITE-12018
 Project: Ignite
  Issue Type: Bug
  Components: UI
Affects Versions: 2.7.5, 2.7
Reporter: Igor Belyakov


Steps to reproduce:

1. Build docker image by using "docker/web-agent/Dockerfile" according to 
README file.
2. Start docker container by using generated image.
3. Next error happens on container start:

 
{code:java}
./ignite-web-agent.sh: line 39: 
/opt/ignite/ignite-web-agent/include/functions.sh: No such file or directory
./ignite-web-agent.sh: line 44: checkJava: command not found
./ignite-web-agent.sh: line 64: javaMajorVersion: command not found
./ignite-web-agent.sh: line 66: [: -eq: unary operator expected
./ignite-web-agent.sh: line 71: [: -gt: unary operator expected
./ignite-web-agent.sh: line 84: [: -eq: unary operator expected
./ignite-web-agent.sh: line 95: : command not found{code}
 

Image contains next files in "/opt/ignite/ignite-web-agent" directory without 
any sub directories:

 
{code:java}
-rw-r--r-- 1 root root 89 Dec 4 2018 README.txt
-rw-r--r-- 1 root root 8080 Dec 4 2018 db-init.sql
-rw-rw-r-- 1 root root 203 Jul 25 12:30 default.properties
-rwxr-xr-x 1 root root 2721 Dec 4 2018 functions.sh
-rw-r--r-- 1 root root 29118502 Dec 6 2018 ignite-web-agent-2.7.0.jar
-rw-r--r-- 1 root root 4590 Dec 4 2018 ignite-web-agent.bat
-rw-rw-r-- 1 root root 561 Jul 25 16:31 ignite-web-agent.log
-rwxr-xr-x 1 root root 3229 Jul 25 16:33 ignite-web-agent.sh 
{code}
The issue happens during executing files copy command in Dockerfile, it doesn't 
keep directories structure. To solve this problem "COPY ignite-web-agent*/* ./" 
command should be changed to "COPY ignite-web-agent* ./"



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [DISCUSSION] Ignite 3.0 and to be removed list

[Denis Magda]

Folks, I've seen that someone added Spark to the list of "Integrations for
Discontinuation". I wouldn't do this. IMO, Spark is one of the key
integrations along with Spring Data, TensorFlow, Kafka that should be moved
out of the core but to be supported by the community:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IgniteModules

-
Denis


On Thu, Jul 25, 2019 at 1:21 AM Alexey Zinoviev 
wrote:

> Thanks for the clarification, will try to vote
>
> чт, 25 июл. 2019 г. в 04:11, Denis Magda :
>
> > Alexey,
> >
> > I've changed format on the wiki so that every community member can cast
> +1
> > and -1 vote explaining his/her stance. This should help us to filter out
> > those integrations that everyone agrees to discontinue vs. those that are
> > controversial. Please, *everyone interested* share your opinion by
> putting
> > a name and +1/-1 in these tables:
> >
> >- Integrations for discontinuation:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> >- APIs for removal:
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> >
> >
> >
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> >
> >
> > Both spatial and full-text search indexes provide limit support and not
> > integrated with Ignite's memory architecture. It's better for us to
> remove
> > them in Ignite 3.0 (that will go with a new API to be proposed soon by
> Alex
> > Goncharuk) and rebuild from scratch in 3.1/3.2.
> >
> >
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> >
> >
> > Why don't we have them as separate Github projects that can be updated
> both
> > by the community members and independent developers? I just don't want
> this
> > to be a burden of the community to test and maintain it for every
> release.
> >
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > > I suppose it's useful feature
> >
> >
> > Alex Goncharuk should propose a new API for 3.0 soon.
> >
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> >
> >
> > I wouldn't do this because 3rd party MQs go with their own versions that
> > start conflicting over the time. For instance, we already have several
> > modules for Hibernate and Spring Data integrations. To fix that, we just
> > need to store integrations in separate repos and do forks if a new
> > conflicting version has to be supported but there is still significant
> > usage of the old one.
> >
> > --
> > Denis Magda
> >
> >
> > On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev 
> > wrote:
> >
> > > I have a few ideas, maybe somebody will support me
> > > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > > issues, but is I'd like this kind of index)
> > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > > because I've ready to try support them (or dive in this question) I
> think
> > > no so many work to support them or move to the separate module like
> > > BigDataTools Integrations
> > > 3. Annotations based configuration of SQL - we should be careful with
> > that,
> > > I suppose it's useful feature
> > > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > > integration into one module for messaging support
> > >
> > > What do you think guys?
> > >
> > > пн, 22 июл. 2019 г. в 22:51, Denis Magda :
> > >
> > > > Igniters,
> > > >
> > > > I did the first run through the wishlist and selected integrations
> and
> > > APIs
> > > > for discontinuation. My suggestion would be to use IEP-36
> > > (Modularization)
> > > > page for the final list that we'll send to the user list for
> feedback:
> > > >
> > > >- Integrations for discontinuation:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > > >- APIs for removal:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > > >
> > > > Please check those lists and let us know if you have any arguments
> > > against
> > > > discontinuation/removal of X. Also, if you believe that something
> > listed
> > > in
> > > > the wishlist should be added to the EIP then let's discuss that.
> > > > Personally, I see the whishlist as a page with ideas while the IEP a
> > > final
> > > > 

Re: Partition map exchange metrics

[Pavel Kovalenko]

Nikolay,

Okay, sounds reasonable.
I just want to add that currentPmeTime is also useful alerting systems, not
only for eye observing. If the time become too long and exceeds some
threshold appropriate alert firing can help to early determine a critical
problem.

On Thu, 25 Jul 2019 at 21.12, Nikolay Izhikov  wrote:

> I think exact time should be obtained from logs, isnt it?
>
>
> чт, 25 июля 2019 г., 20:00 Pavel Kovalenko :
>
> > Nikolay,
> >
> > Yes, I have a chance to see HistogramMetric and moreover reviewed it) My
> > question was mostly about what exactly we will track in Histogram.
> > If we use histogram do you know how we can find exact time e.g. when PME
> > with time > 1s happened?
> >
> > чт, 25 июл. 2019 г. в 19:24, Nikolay Izhikov :
> >
> > > Pavel
> > >
> > > Do you have a chance to see HistogramMetric source?
> > > It in master now.
> > > Look in source would be better then my explanation)
> > >
> > > We should count PME processes that blocks operations for some amount of
> > > time. For example [less then 50, less then 250, less then 1000, more
> then
> > > 1000] millis.
> > >
> > > чт, 25 июля 2019 г., 18:55 Pavel Kovalenko :
> > >
> > > > Nikolay,
> > > >
> > > > Could you please explain deeper what structure will be of PME
> > histogram?
> > > >
> > > > чт, 25 июл. 2019 г. в 11:56, Nikolay Izhikov :
> > > >
> > > > > Hello, Nikita.
> > > > >
> > > > > I think
> > > > >
> > > > > > 1. The totalCacheOperationsBlockedDuration metric that will
> > > accumulate
> > > > > > all blocking durations that happen after node starts.
> > > > >
> > > > > No, we don't need it.
> > > > >
> > > > > > 2. Blocking duration histogram. Based on the HistogramMetric
> class.
> > > > >
> > > > > Yes, we need it.
> > > > >
> > > > > В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> > > > > > Igniters,
> > > > > >
> > > > > > All want to see the сacheOperationsBlockedDuration metric that
> will
> > > > > > show current blocking duration or 0 if there is no blocking right
> > > now.
> > > > > >
> > > > > > Do we need the following metrics? It seems one of them will be
> > > > > superfluous.
> > > > > > 1. The totalCacheOperationsBlockedDuration metric that will
> > > accumulate
> > > > > > all blocking durations that happen after node starts.
> > > > > > 2. Blocking duration histogram. Based on the HistogramMetric
> class.
> > > > > > User will be able to configure bounds.
> > > > > >
> > > > > > ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov <
> nizhi...@apache.org
> > >:
> > > > > > >
> > > > > > > Guys.
> > > > > > >
> > > > > > > I think we should go with the 2 metrics
> > > > > > >
> > > > > > > * current PME duration (resets on finish)
> > > > > > >
> > > > > > > This metric required for alerting(or automatic
> > > > > actions) on long PME.
> > > > > > >
> > > > > > > * PME duration histogram (value added to metrics on PME
> > > > finish)
> > > > > > > This metric required for an:
> > > > > > > * Quick PME trend analysis
> > > > > > > * Quick PME history analysis
> > > > > > >
> > > > > > >
> > > > > > > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > > > > > > Nikita and Maxim,
> > > > > > > >
> > > > > > > > > What if we just update current metric getCurrentPmeDuration
> > > > > behaviour
> > > > > > > > > to show durations only for blocking PMEs?
> > > > > > > > > Remain it as a long value and rename it to
> > > > > getCacheOperationsBlockedDuration.
> > > > > > > > >
> > > > > > > > > No other changes will require.
> > > > > > > > >
> > > > > > > > > WDYT?
> > > > > > > >
> > > > > > > > I agree with these two metrics. I also think that current
> > > > > > > > getCurrentPmeDuration will become redundant.
> > > > > > > >
> > > > > > > > Anton,
> > > > > > > >
> > > > > > > > > It looks like we're trying to implement "extended debug"
> > > instead
> > > > of
> > > > > > > > > "monitoring".
> > > > > > > > > It should not be interesting for real admin what phase of
> PME
> > > is
> > > > in
> > > > > > > > > progress and so on.
> > > > > > > >
> > > > > > > > PME is mission critical cluster process. I agree that
> there's a
> > > > fine
> > > > > > > > line between monitoring and debug here. However, it's not
> good
> > to
> > > > add
> > > > > > > > monitoring capabilities only for scenario when everything is
> > > > alright.
> > > > > > > > If PME will really hang, *real admin* will be extremely
> > > interested
> > > > > how
> > > > > > > > to return cluster back to working state. Metrics about stages
> > > > > completion
> > > > > > > > time may really help here: e.g. if one specific node hasn't
> > > > completed
> > > > > > > > stage X while rest of the cluster has, it can be a signal
> that
> > > this
> > > > > node
> > > > > > > > should be killed.
> > > > > > > >
> > > > > > > > Of course, it's possible to build monitoring system that
> > extract
> > > > this
> > > > > > > > information 

[MTCGA]: new failures in builds [4394336] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New Trusted Suite failure in master [Check Code Style] 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CheckCodeStyle=%3Cdefault%3E=buildTypeStatusDiv
 Changes may lead to failure were done by 
 - zaleslaw@gmail.com 
https://ci.ignite.apache.org/viewModification.html?modId=888540

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 21:26:38 25-07-2019 

Re: Partition map exchange metrics

[Nikolay Izhikov]

I think exact time should be obtained from logs, isnt it?


чт, 25 июля 2019 г., 20:00 Pavel Kovalenko :

> Nikolay,
>
> Yes, I have a chance to see HistogramMetric and moreover reviewed it) My
> question was mostly about what exactly we will track in Histogram.
> If we use histogram do you know how we can find exact time e.g. when PME
> with time > 1s happened?
>
> чт, 25 июл. 2019 г. в 19:24, Nikolay Izhikov :
>
> > Pavel
> >
> > Do you have a chance to see HistogramMetric source?
> > It in master now.
> > Look in source would be better then my explanation)
> >
> > We should count PME processes that blocks operations for some amount of
> > time. For example [less then 50, less then 250, less then 1000, more then
> > 1000] millis.
> >
> > чт, 25 июля 2019 г., 18:55 Pavel Kovalenko :
> >
> > > Nikolay,
> > >
> > > Could you please explain deeper what structure will be of PME
> histogram?
> > >
> > > чт, 25 июл. 2019 г. в 11:56, Nikolay Izhikov :
> > >
> > > > Hello, Nikita.
> > > >
> > > > I think
> > > >
> > > > > 1. The totalCacheOperationsBlockedDuration metric that will
> > accumulate
> > > > > all blocking durations that happen after node starts.
> > > >
> > > > No, we don't need it.
> > > >
> > > > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > > >
> > > > Yes, we need it.
> > > >
> > > > В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> > > > > Igniters,
> > > > >
> > > > > All want to see the сacheOperationsBlockedDuration metric that will
> > > > > show current blocking duration or 0 if there is no blocking right
> > now.
> > > > >
> > > > > Do we need the following metrics? It seems one of them will be
> > > > superfluous.
> > > > > 1. The totalCacheOperationsBlockedDuration metric that will
> > accumulate
> > > > > all blocking durations that happen after node starts.
> > > > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > > > > User will be able to configure bounds.
> > > > >
> > > > > ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov  >:
> > > > > >
> > > > > > Guys.
> > > > > >
> > > > > > I think we should go with the 2 metrics
> > > > > >
> > > > > > * current PME duration (resets on finish)
> > > > > >
> > > > > > This metric required for alerting(or automatic
> > > > actions) on long PME.
> > > > > >
> > > > > > * PME duration histogram (value added to metrics on PME
> > > finish)
> > > > > > This metric required for an:
> > > > > > * Quick PME trend analysis
> > > > > > * Quick PME history analysis
> > > > > >
> > > > > >
> > > > > > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > > > > > Nikita and Maxim,
> > > > > > >
> > > > > > > > What if we just update current metric getCurrentPmeDuration
> > > > behaviour
> > > > > > > > to show durations only for blocking PMEs?
> > > > > > > > Remain it as a long value and rename it to
> > > > getCacheOperationsBlockedDuration.
> > > > > > > >
> > > > > > > > No other changes will require.
> > > > > > > >
> > > > > > > > WDYT?
> > > > > > >
> > > > > > > I agree with these two metrics. I also think that current
> > > > > > > getCurrentPmeDuration will become redundant.
> > > > > > >
> > > > > > > Anton,
> > > > > > >
> > > > > > > > It looks like we're trying to implement "extended debug"
> > instead
> > > of
> > > > > > > > "monitoring".
> > > > > > > > It should not be interesting for real admin what phase of PME
> > is
> > > in
> > > > > > > > progress and so on.
> > > > > > >
> > > > > > > PME is mission critical cluster process. I agree that there's a
> > > fine
> > > > > > > line between monitoring and debug here. However, it's not good
> to
> > > add
> > > > > > > monitoring capabilities only for scenario when everything is
> > > alright.
> > > > > > > If PME will really hang, *real admin* will be extremely
> > interested
> > > > how
> > > > > > > to return cluster back to working state. Metrics about stages
> > > > completion
> > > > > > > time may really help here: e.g. if one specific node hasn't
> > > completed
> > > > > > > stage X while rest of the cluster has, it can be a signal that
> > this
> > > > node
> > > > > > > should be killed.
> > > > > > >
> > > > > > > Of course, it's possible to build monitoring system that
> extract
> > > this
> > > > > > > information from logs, but:
> > > > > > > - It's more resource intensive as it requires parsing logs for
> > all
> > > > the time
> > > > > > > - It's less reliable as log messages may change
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Ivan Rakov
> > > > > > >
> > > > > > > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > +1 with Anton post.
> > > > > > > >
> > > > > > > > What if we just update current metric getCurrentPmeDuration
> > > > behaviour
> > > > > > > > to show durations only for blocking PMEs?
> > > > > > > > Remain it as a long value and rename it to

Re: Clean up of our PRs and IEPs before 2019

[Dmitriy Pavlov]

Hi Anton,

Teamcity Bot shows JIRA status in addition to a link to PR, so once PR
count is 100 instead of 1200 we easily can clean up it from time to time.
Just the same way with cleaning up git branches in the Apache repository.

I do this cleaning time to time and its not a problem. Just like I've
closed https://github.com/apache/ignite/pull/6575 now. The issue now is to
clean the main part of PRs opened during years in ASF.

Sincerely

чт, 25 июл. 2019 г. в 15:48, Anton Vinogradov :

> Peter,
>
> Not sure I've got how you're going to keep this ok in future.
> This crusade is useful only in case you have the plan.
>
> >> And closing PRs after merge or some decent waiting period of inactivity
> seems to be at least sign of respect to each other of our community.
> We have to find an easy (automated) way instead of respectful :)
> For example, PRs should be automatically closed once issue resolved.
>
> On Thu, Jul 25, 2019 at 2:42 PM Petr Ivanov  wrote:
>
> > Anton,
> >
> >
> > Maintaining order always worth it.
> > If we did not made this mess initially, no crusade would be required now.
> > And closing PRs after merge or some decent waiting period of inactivity
> > seems to be at least sign of respect to each other of our community.
> >
> > Anyway, looks like that this task can be done in half-lazy pace without
> > much of the disturbance to anyone.
> >
> >
> > > On 25 Jul 2019, at 13:44, Anton Vinogradov  wrote:
> > >
> > > Folks,
> > >
> > > Is it possible just to ignore obsolete PRs somehow?
> > > Not sure this crusade worth it.
> > >
> > > On Thu, Jul 25, 2019 at 1:18 PM Павлухин Иван 
> > wrote:
> > >
> > >> Maxim,
> > >>
> > >> Quite a nice idea. Could we go even further? Add a comment to each 1-2
> > >> year old PR asking if the author could close it (most likely with help
> > >> of some automation). As I know GitHub sends emails with PR comments to
> > >> authors.
> > >>
> > >> чт, 25 июл. 2019 г. в 13:05, Dmitriy Pavlov :
> > >>>
> > >>> Folks, please close not needed PRs.
> > >>>
> > >>> I don't have contact with Pyatkov & dkarachentsev. Folks, please step
> > in.
> > >>> Also, feel free to reopen PRs if you still want change to be merged.
> > >>>
> > >>> чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :
> > >>>
> >  Folks,
> > 
> >  Can we contact with some members manually and ask them to close
> unused
> >  PRs? Most of the users are active community members, so I think they
> >  will respond quite fast.
> > 
> >  I've briefly checked GitHub:
> > 
> >  dkarachentsev - 62 opened PRs
> >  ilantukh - 58 opened PRs
> >  dgovorukhin - 44 opened PRs
> >  mcherkasov - 23 opened PRs
> >  ascherbakoff  - 22 opened PRs
> >  vldpyatkov - 21 opened PRs
> > 
> >  On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov 
> > >> wrote:
> > >
> > > Hi Alexey,
> > >
> > > second need it to check all open PRs from community members for
> > >> fixes,
> > > which could be merged to Ignite codebase.
> > >
> > > Which is why I'm not so sure that we should automatically close. I
> > >> ask
> > > everyone to close their PRs, and I manually double-check PRs
> remained
> > > opened.
> > >
> > > The third need is to automatically tests all opened PRs and provide
> > >> visas
> > > to every PR we have. In case we have PRs with 0 blockers we should
> > >> take
> >  it
> > > into review process. No all newcomers aware of TC Bot, so I would
> > >> like to
> > > automate this process as much as possible.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev <
> zaleslaw@gmail.com
> > >>> :
> > >
> > >> The long period totally reduces the discontent and outrage of
> > >> community
> > >> members (if you reduce to 2-6 weeks it could be intersected with
> > >> human
> > >> events of most part of contributors like vacation, birthdays,
> > >> wedding,
> >  spam
> > >> filters and etc.), believe me (I have the same experience as I
> >  mentioned)
> > >>
> > >> From the other hand, what the real reason to reduce it to the
> > >> shorter
> > >> period? Bot needs? Robot needs?
> > >> Robot could wait, I hope:)
> > >>
> > >> чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> > >>
> > >>> Alexey,
> > >>>
> > >>> Yep, I imagined a similar procedure in my mind. Just curious,
> > >> why do
> > >>> you think that a period before actions are taken should be so
> > >> long
> > >>> (3-6 months)?.
> > >>>
> > >>> чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev <
> > >> zaleslaw@gmail.com
> > > :
> > 
> >  Dear Igniters, I have one suggestion
> > 
> >  If a most of commiters will support idea of automatic
> > >> "cleaning",
> >  we
> > >>> should
> >  provide next options
> > 
> >    - declare a long period for putting 

Re: Partition map exchange metrics

[Pavel Kovalenko]

Nikolay,

Yes, I have a chance to see HistogramMetric and moreover reviewed it) My
question was mostly about what exactly we will track in Histogram.
If we use histogram do you know how we can find exact time e.g. when PME
with time > 1s happened?

чт, 25 июл. 2019 г. в 19:24, Nikolay Izhikov :

> Pavel
>
> Do you have a chance to see HistogramMetric source?
> It in master now.
> Look in source would be better then my explanation)
>
> We should count PME processes that blocks operations for some amount of
> time. For example [less then 50, less then 250, less then 1000, more then
> 1000] millis.
>
> чт, 25 июля 2019 г., 18:55 Pavel Kovalenko :
>
> > Nikolay,
> >
> > Could you please explain deeper what structure will be of PME histogram?
> >
> > чт, 25 июл. 2019 г. в 11:56, Nikolay Izhikov :
> >
> > > Hello, Nikita.
> > >
> > > I think
> > >
> > > > 1. The totalCacheOperationsBlockedDuration metric that will
> accumulate
> > > > all blocking durations that happen after node starts.
> > >
> > > No, we don't need it.
> > >
> > > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > >
> > > Yes, we need it.
> > >
> > > В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> > > > Igniters,
> > > >
> > > > All want to see the сacheOperationsBlockedDuration metric that will
> > > > show current blocking duration or 0 if there is no blocking right
> now.
> > > >
> > > > Do we need the following metrics? It seems one of them will be
> > > superfluous.
> > > > 1. The totalCacheOperationsBlockedDuration metric that will
> accumulate
> > > > all blocking durations that happen after node starts.
> > > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > > > User will be able to configure bounds.
> > > >
> > > > ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov :
> > > > >
> > > > > Guys.
> > > > >
> > > > > I think we should go with the 2 metrics
> > > > >
> > > > > * current PME duration (resets on finish)
> > > > >
> > > > > This metric required for alerting(or automatic
> > > actions) on long PME.
> > > > >
> > > > > * PME duration histogram (value added to metrics on PME
> > finish)
> > > > > This metric required for an:
> > > > > * Quick PME trend analysis
> > > > > * Quick PME history analysis
> > > > >
> > > > >
> > > > > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > > > > Nikita and Maxim,
> > > > > >
> > > > > > > What if we just update current metric getCurrentPmeDuration
> > > behaviour
> > > > > > > to show durations only for blocking PMEs?
> > > > > > > Remain it as a long value and rename it to
> > > getCacheOperationsBlockedDuration.
> > > > > > >
> > > > > > > No other changes will require.
> > > > > > >
> > > > > > > WDYT?
> > > > > >
> > > > > > I agree with these two metrics. I also think that current
> > > > > > getCurrentPmeDuration will become redundant.
> > > > > >
> > > > > > Anton,
> > > > > >
> > > > > > > It looks like we're trying to implement "extended debug"
> instead
> > of
> > > > > > > "monitoring".
> > > > > > > It should not be interesting for real admin what phase of PME
> is
> > in
> > > > > > > progress and so on.
> > > > > >
> > > > > > PME is mission critical cluster process. I agree that there's a
> > fine
> > > > > > line between monitoring and debug here. However, it's not good to
> > add
> > > > > > monitoring capabilities only for scenario when everything is
> > alright.
> > > > > > If PME will really hang, *real admin* will be extremely
> interested
> > > how
> > > > > > to return cluster back to working state. Metrics about stages
> > > completion
> > > > > > time may really help here: e.g. if one specific node hasn't
> > completed
> > > > > > stage X while rest of the cluster has, it can be a signal that
> this
> > > node
> > > > > > should be killed.
> > > > > >
> > > > > > Of course, it's possible to build monitoring system that extract
> > this
> > > > > > information from logs, but:
> > > > > > - It's more resource intensive as it requires parsing logs for
> all
> > > the time
> > > > > > - It's less reliable as log messages may change
> > > > > >
> > > > > > Best Regards,
> > > > > > Ivan Rakov
> > > > > >
> > > > > > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > > > > > Folks,
> > > > > > >
> > > > > > > +1 with Anton post.
> > > > > > >
> > > > > > > What if we just update current metric getCurrentPmeDuration
> > > behaviour
> > > > > > > to show durations only for blocking PMEs?
> > > > > > > Remain it as a long value and rename it to
> > > getCacheOperationsBlockedDuration.
> > > > > > >
> > > > > > > No other changes will require.
> > > > > > >
> > > > > > > WDYT?
> > > > > > >
> > > > > > > On Wed, 24 Jul 2019 at 14:02, Nikita Amelchev <
> > > nsamelc...@gmail.com> wrote:
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > The сacheOperationsBlockedDuration metric will show current
> > > blocking
> > > > > > 

Re: Partition map exchange metrics

[Nikolay Izhikov]

Pavel

Do you have a chance to see HistogramMetric source?
It in master now.
Look in source would be better then my explanation)

We should count PME processes that blocks operations for some amount of
time. For example [less then 50, less then 250, less then 1000, more then
1000] millis.

чт, 25 июля 2019 г., 18:55 Pavel Kovalenko :

> Nikolay,
>
> Could you please explain deeper what structure will be of PME histogram?
>
> чт, 25 июл. 2019 г. в 11:56, Nikolay Izhikov :
>
> > Hello, Nikita.
> >
> > I think
> >
> > > 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> > > all blocking durations that happen after node starts.
> >
> > No, we don't need it.
> >
> > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> >
> > Yes, we need it.
> >
> > В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> > > Igniters,
> > >
> > > All want to see the сacheOperationsBlockedDuration metric that will
> > > show current blocking duration or 0 if there is no blocking right now.
> > >
> > > Do we need the following metrics? It seems one of them will be
> > superfluous.
> > > 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> > > all blocking durations that happen after node starts.
> > > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > > User will be able to configure bounds.
> > >
> > > ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov :
> > > >
> > > > Guys.
> > > >
> > > > I think we should go with the 2 metrics
> > > >
> > > > * current PME duration (resets on finish)
> > > >
> > > > This metric required for alerting(or automatic
> > actions) on long PME.
> > > >
> > > > * PME duration histogram (value added to metrics on PME
> finish)
> > > > This metric required for an:
> > > > * Quick PME trend analysis
> > > > * Quick PME history analysis
> > > >
> > > >
> > > > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > > > Nikita and Maxim,
> > > > >
> > > > > > What if we just update current metric getCurrentPmeDuration
> > behaviour
> > > > > > to show durations only for blocking PMEs?
> > > > > > Remain it as a long value and rename it to
> > getCacheOperationsBlockedDuration.
> > > > > >
> > > > > > No other changes will require.
> > > > > >
> > > > > > WDYT?
> > > > >
> > > > > I agree with these two metrics. I also think that current
> > > > > getCurrentPmeDuration will become redundant.
> > > > >
> > > > > Anton,
> > > > >
> > > > > > It looks like we're trying to implement "extended debug" instead
> of
> > > > > > "monitoring".
> > > > > > It should not be interesting for real admin what phase of PME is
> in
> > > > > > progress and so on.
> > > > >
> > > > > PME is mission critical cluster process. I agree that there's a
> fine
> > > > > line between monitoring and debug here. However, it's not good to
> add
> > > > > monitoring capabilities only for scenario when everything is
> alright.
> > > > > If PME will really hang, *real admin* will be extremely interested
> > how
> > > > > to return cluster back to working state. Metrics about stages
> > completion
> > > > > time may really help here: e.g. if one specific node hasn't
> completed
> > > > > stage X while rest of the cluster has, it can be a signal that this
> > node
> > > > > should be killed.
> > > > >
> > > > > Of course, it's possible to build monitoring system that extract
> this
> > > > > information from logs, but:
> > > > > - It's more resource intensive as it requires parsing logs for all
> > the time
> > > > > - It's less reliable as log messages may change
> > > > >
> > > > > Best Regards,
> > > > > Ivan Rakov
> > > > >
> > > > > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > > > > Folks,
> > > > > >
> > > > > > +1 with Anton post.
> > > > > >
> > > > > > What if we just update current metric getCurrentPmeDuration
> > behaviour
> > > > > > to show durations only for blocking PMEs?
> > > > > > Remain it as a long value and rename it to
> > getCacheOperationsBlockedDuration.
> > > > > >
> > > > > > No other changes will require.
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > On Wed, 24 Jul 2019 at 14:02, Nikita Amelchev <
> > nsamelc...@gmail.com> wrote:
> > > > > > > Nikolay,
> > > > > > >
> > > > > > > The сacheOperationsBlockedDuration metric will show current
> > blocking
> > > > > > > duration or 0 if there is no blocking right now.
> > > > > > >
> > > > > > > The totalCacheOperationsBlockedDuration metric will accumulate
> > all
> > > > > > > blocking durations that happen after node starts.
> > > > > > >
> > > > > > > ср, 24 июл. 2019 г. в 13:35, Nikolay Izhikov <
> > nizhi...@apache.org>:
> > > > > > > > Nikita
> > > > > > > >
> > > > > > > > What is the difference between those two metrics?
> > > > > > > >
> > > > > > > > ср, 24 июля 2019 г., 12:45 Nikita Amelchev <
> > nsamelc...@gmail.com>:
> > > > > > > >
> > > > > > > > > Igniters, thanks 

Re: Partition map exchange metrics

[Pavel Kovalenko]

Nikolay,

Could you please explain deeper what structure will be of PME histogram?

чт, 25 июл. 2019 г. в 11:56, Nikolay Izhikov :

> Hello, Nikita.
>
> I think
>
> > 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> > all blocking durations that happen after node starts.
>
> No, we don't need it.
>
> > 2. Blocking duration histogram. Based on the HistogramMetric class.
>
> Yes, we need it.
>
> В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> > Igniters,
> >
> > All want to see the сacheOperationsBlockedDuration metric that will
> > show current blocking duration or 0 if there is no blocking right now.
> >
> > Do we need the following metrics? It seems one of them will be
> superfluous.
> > 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> > all blocking durations that happen after node starts.
> > 2. Blocking duration histogram. Based on the HistogramMetric class.
> > User will be able to configure bounds.
> >
> > ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov :
> > >
> > > Guys.
> > >
> > > I think we should go with the 2 metrics
> > >
> > > * current PME duration (resets on finish)
> > >
> > > This metric required for alerting(or automatic
> actions) on long PME.
> > >
> > > * PME duration histogram (value added to metrics on PME finish)
> > > This metric required for an:
> > > * Quick PME trend analysis
> > > * Quick PME history analysis
> > >
> > >
> > > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > > Nikita and Maxim,
> > > >
> > > > > What if we just update current metric getCurrentPmeDuration
> behaviour
> > > > > to show durations only for blocking PMEs?
> > > > > Remain it as a long value and rename it to
> getCacheOperationsBlockedDuration.
> > > > >
> > > > > No other changes will require.
> > > > >
> > > > > WDYT?
> > > >
> > > > I agree with these two metrics. I also think that current
> > > > getCurrentPmeDuration will become redundant.
> > > >
> > > > Anton,
> > > >
> > > > > It looks like we're trying to implement "extended debug" instead of
> > > > > "monitoring".
> > > > > It should not be interesting for real admin what phase of PME is in
> > > > > progress and so on.
> > > >
> > > > PME is mission critical cluster process. I agree that there's a fine
> > > > line between monitoring and debug here. However, it's not good to add
> > > > monitoring capabilities only for scenario when everything is alright.
> > > > If PME will really hang, *real admin* will be extremely interested
> how
> > > > to return cluster back to working state. Metrics about stages
> completion
> > > > time may really help here: e.g. if one specific node hasn't completed
> > > > stage X while rest of the cluster has, it can be a signal that this
> node
> > > > should be killed.
> > > >
> > > > Of course, it's possible to build monitoring system that extract this
> > > > information from logs, but:
> > > > - It's more resource intensive as it requires parsing logs for all
> the time
> > > > - It's less reliable as log messages may change
> > > >
> > > > Best Regards,
> > > > Ivan Rakov
> > > >
> > > > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > > > Folks,
> > > > >
> > > > > +1 with Anton post.
> > > > >
> > > > > What if we just update current metric getCurrentPmeDuration
> behaviour
> > > > > to show durations only for blocking PMEs?
> > > > > Remain it as a long value and rename it to
> getCacheOperationsBlockedDuration.
> > > > >
> > > > > No other changes will require.
> > > > >
> > > > > WDYT?
> > > > >
> > > > > On Wed, 24 Jul 2019 at 14:02, Nikita Amelchev <
> nsamelc...@gmail.com> wrote:
> > > > > > Nikolay,
> > > > > >
> > > > > > The сacheOperationsBlockedDuration metric will show current
> blocking
> > > > > > duration or 0 if there is no blocking right now.
> > > > > >
> > > > > > The totalCacheOperationsBlockedDuration metric will accumulate
> all
> > > > > > blocking durations that happen after node starts.
> > > > > >
> > > > > > ср, 24 июл. 2019 г. в 13:35, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > > > > > Nikita
> > > > > > >
> > > > > > > What is the difference between those two metrics?
> > > > > > >
> > > > > > > ср, 24 июля 2019 г., 12:45 Nikita Amelchev <
> nsamelc...@gmail.com>:
> > > > > > >
> > > > > > > > Igniters, thanks for comments.
> > > > > > > >
> > > > > > > >  From the discussion it can be seen that we need only two
> metrics for now:
> > > > > > > > - сacheOperationsBlockedDuration (long)
> > > > > > > > - totalCacheOperationsBlockedDuration (long)
> > > > > > > >
> > > > > > > > I will prepare PR at the nearest time.
> > > > > > > >
> > > > > > > > ср, 24 июл. 2019 г. в 09:11, Zhenya Stanilovsky
>  > > > > > > > > :
> > > > > > > > >
> > > > > > > > > +1 with Anton decisions.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Среда, 24 июля 2019, 8:44 +03:00 от Anton Vinogradov <
> a...@apache.org>:
> > > > 

Re: Clean up of our PRs and IEPs before 2019

[Anton Vinogradov]

Peter,

Not sure I've got how you're going to keep this ok in future.
This crusade is useful only in case you have the plan.

>> And closing PRs after merge or some decent waiting period of inactivity
seems to be at least sign of respect to each other of our community.
We have to find an easy (automated) way instead of respectful :)
For example, PRs should be automatically closed once issue resolved.

On Thu, Jul 25, 2019 at 2:42 PM Petr Ivanov  wrote:

> Anton,
>
>
> Maintaining order always worth it.
> If we did not made this mess initially, no crusade would be required now.
> And closing PRs after merge or some decent waiting period of inactivity
> seems to be at least sign of respect to each other of our community.
>
> Anyway, looks like that this task can be done in half-lazy pace without
> much of the disturbance to anyone.
>
>
> > On 25 Jul 2019, at 13:44, Anton Vinogradov  wrote:
> >
> > Folks,
> >
> > Is it possible just to ignore obsolete PRs somehow?
> > Not sure this crusade worth it.
> >
> > On Thu, Jul 25, 2019 at 1:18 PM Павлухин Иван 
> wrote:
> >
> >> Maxim,
> >>
> >> Quite a nice idea. Could we go even further? Add a comment to each 1-2
> >> year old PR asking if the author could close it (most likely with help
> >> of some automation). As I know GitHub sends emails with PR comments to
> >> authors.
> >>
> >> чт, 25 июл. 2019 г. в 13:05, Dmitriy Pavlov :
> >>>
> >>> Folks, please close not needed PRs.
> >>>
> >>> I don't have contact with Pyatkov & dkarachentsev. Folks, please step
> in.
> >>> Also, feel free to reopen PRs if you still want change to be merged.
> >>>
> >>> чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :
> >>>
>  Folks,
> 
>  Can we contact with some members manually and ask them to close unused
>  PRs? Most of the users are active community members, so I think they
>  will respond quite fast.
> 
>  I've briefly checked GitHub:
> 
>  dkarachentsev - 62 opened PRs
>  ilantukh - 58 opened PRs
>  dgovorukhin - 44 opened PRs
>  mcherkasov - 23 opened PRs
>  ascherbakoff  - 22 opened PRs
>  vldpyatkov - 21 opened PRs
> 
>  On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov 
> >> wrote:
> >
> > Hi Alexey,
> >
> > second need it to check all open PRs from community members for
> >> fixes,
> > which could be merged to Ignite codebase.
> >
> > Which is why I'm not so sure that we should automatically close. I
> >> ask
> > everyone to close their PRs, and I manually double-check PRs remained
> > opened.
> >
> > The third need is to automatically tests all opened PRs and provide
> >> visas
> > to every PR we have. In case we have PRs with 0 blockers we should
> >> take
>  it
> > into review process. No all newcomers aware of TC Bot, so I would
> >> like to
> > automate this process as much as possible.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev  >>> :
> >
> >> The long period totally reduces the discontent and outrage of
> >> community
> >> members (if you reduce to 2-6 weeks it could be intersected with
> >> human
> >> events of most part of contributors like vacation, birthdays,
> >> wedding,
>  spam
> >> filters and etc.), believe me (I have the same experience as I
>  mentioned)
> >>
> >> From the other hand, what the real reason to reduce it to the
> >> shorter
> >> period? Bot needs? Robot needs?
> >> Robot could wait, I hope:)
> >>
> >> чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> >>
> >>> Alexey,
> >>>
> >>> Yep, I imagined a similar procedure in my mind. Just curious,
> >> why do
> >>> you think that a period before actions are taken should be so
> >> long
> >>> (3-6 months)?.
> >>>
> >>> чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev <
> >> zaleslaw@gmail.com
> > :
> 
>  Dear Igniters, I have one suggestion
> 
>  If a most of commiters will support idea of automatic
> >> "cleaning",
>  we
> >>> should
>  provide next options
> 
>    - declare a long period for putting labels or leaving
> >> comments
>  for
>    useful PRs from their authors (about 3-6 months)
>    - generate notifications for all authors of all PRs with
> >> clarification
>    of our goals
>    - every month reminder in dev-list and via e-mail to each
> >> PR's
> >> author
> 
>  The best way, of course, the closing by our hands in each
> >> module
>  and
> >> area
>  with tags "obsolete" or something else.
> 
>  P.S. I was in the same situation in Open Street Map community
> >> and
>  the
>  principles for automated cleaning were the same like suggested
> >> by
> >> myself
>  above
> 
>  I hope that we will be careful with our community
> 

[jira] [Created] (IGNITE-12017) Avoid calling GridDhtPartitionsExchangeFuture#onEvent more than once.

[Amelchev Nikita (JIRA)]

Amelchev Nikita created IGNITE-12017:


 Summary: Avoid calling GridDhtPartitionsExchangeFuture#onEvent 
more than once.
 Key: IGNITE-12017
 URL: https://issues.apache.org/jira/browse/IGNITE-12017
 Project: Ignite
  Issue Type: Task
Reporter: Amelchev Nikita


When the GridDhtPartitionsExchangeFuture#onEvent method called it releases init 
latch. It means that we can't change the initial event (firstDiscoEvt). 
Otherwise, it breaks the exchange logic.
I have checked on TC and this method may be called twice with one event 
(identical references).
The following assert is correct:
{noformat}
assert exchId.equals(this.exchId) && (firstDiscoEvt == null || firstDiscoEvt == 
discoEvt);
{noformat}
Need to refactor the method usages and avoid confusing developers that the 
first event may be changed.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-12016) Is there option to increase or decrease Ignite SQL Table backup count after its initialized?

[hirik (JIRA)]

hirik created IGNITE-12016:
--

 Summary: Is there option to increase or decrease Ignite SQL Table 
backup count after its initialized?
 Key: IGNITE-12016
 URL: https://issues.apache.org/jira/browse/IGNITE-12016
 Project: Ignite
  Issue Type: New Feature
Reporter: hirik


Hi, 

We are working in a dynamic environment, based on the new nodes we should 
update the backup count of existing SQL tables. is there any api available to 
support this requirement? 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-12015) Text caseinsensitive search

[hirik (JIRA)]

hirik created IGNITE-12015:
--

 Summary: Text caseinsensitive search 
 Key: IGNITE-12015
 URL: https://issues.apache.org/jira/browse/IGNITE-12015
 Project: Ignite
  Issue Type: Improvement
Reporter: hirik


Hi,

I'm looking for 
[VARCHAR_IGNORECASE|http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type]
 kind of datatype in Ignite SQL for text ignore-case search. Is there any 
reason for this not available in Ignite even though Apache Ignite SQL engine is 
tightly coupled with H2 database?  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-12014) Getting affinity for topology version earlier than affinity is calculated for system cache

[PetrovMikhail (JIRA)]

PetrovMikhail created IGNITE-12014:
--

 Summary:  Getting affinity for topology version earlier than 
affinity is calculated for system cache
 Key: IGNITE-12014
 URL: https://issues.apache.org/jira/browse/IGNITE-12014
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7.5
Reporter: PetrovMikhail
 Attachments: JcacheExchangeAwaitTest.java

The following exception was being caught occasionally on a big cluster (128 
nodes) after it's activation and concurrent Ignite#reentrantLock() method call 
from different nodes. (On 16 nodes cluster this exception was never detected 
with no code change).

It's attached a presumptive reproducer of that problem which stable fails with 
the specified exception.

{code:java}
java.lang.IllegalStateException: Getting affinity for topology version earlier 
than affinity is calculated [locNode=TcpDiscoveryNode 
[id=cf397493-7528-46dc-bc5a-444f9d51, consistentId=127.0.0.1:47501, 
addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47501], 
discPort=47501, order=2, intOrder=2, lastExchangeTime=1564050248387, loc=true, 
ver=2.8.0#20190725-sha1:, isClient=false], 
grp=default-volatile-ds-group, topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=1], lastAffChangeTopVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=1], head=AffinityTopologyVersion [topVer=2, minorTopVer=2], 
history=[AffinityTopologyVersion [topVer=2, minorTopVer=2]]]
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:802)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:749)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:657)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:227)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:273)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:264)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:288)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.entryExx(GridDhtColocatedCache.java:161)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.entryEx(GridNearTxLocal.java:4470)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistRead(GridNearTxLocal.java:2709)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:2188)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$4.op(GridDhtColocatedCache.java:204)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter$AsyncOp.op(GridCacheAdapter.java:5644)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4561)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:202)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4842)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.repairableGet(GridCacheAdapter.java:4808)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1480)
at 
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:396)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:561)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$4.applyx(DataStructuresProcessor.java:556)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1664)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.getAtomic(DataStructuresProcessor.java:556)
at 
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.reentrantLock(DataStructuresProcessor.java:1361)
at 
org.apache.ignite.internal.IgniteKernal.reentrantLock(IgniteKernal.java:4065)
at 
org.apache.ignite.JcacheExchangeAwaitTest.testJcacheExchangeAwait(JcacheExchangeAwaitTest.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62

Re: Clean up of our PRs and IEPs before 2019

[Petr Ivanov]

Anton,


Maintaining order always worth it.
If we did not made this mess initially, no crusade would be required now.
And closing PRs after merge or some decent waiting period of inactivity seems 
to be at least sign of respect to each other of our community.

Anyway, looks like that this task can be done in half-lazy pace without much of 
the disturbance to anyone.


> On 25 Jul 2019, at 13:44, Anton Vinogradov  wrote:
> 
> Folks,
> 
> Is it possible just to ignore obsolete PRs somehow?
> Not sure this crusade worth it.
> 
> On Thu, Jul 25, 2019 at 1:18 PM Павлухин Иван  wrote:
> 
>> Maxim,
>> 
>> Quite a nice idea. Could we go even further? Add a comment to each 1-2
>> year old PR asking if the author could close it (most likely with help
>> of some automation). As I know GitHub sends emails with PR comments to
>> authors.
>> 
>> чт, 25 июл. 2019 г. в 13:05, Dmitriy Pavlov :
>>> 
>>> Folks, please close not needed PRs.
>>> 
>>> I don't have contact with Pyatkov & dkarachentsev. Folks, please step in.
>>> Also, feel free to reopen PRs if you still want change to be merged.
>>> 
>>> чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :
>>> 
 Folks,
 
 Can we contact with some members manually and ask them to close unused
 PRs? Most of the users are active community members, so I think they
 will respond quite fast.
 
 I've briefly checked GitHub:
 
 dkarachentsev - 62 opened PRs
 ilantukh - 58 opened PRs
 dgovorukhin - 44 opened PRs
 mcherkasov - 23 opened PRs
 ascherbakoff  - 22 opened PRs
 vldpyatkov - 21 opened PRs
 
 On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov 
>> wrote:
> 
> Hi Alexey,
> 
> second need it to check all open PRs from community members for
>> fixes,
> which could be merged to Ignite codebase.
> 
> Which is why I'm not so sure that we should automatically close. I
>> ask
> everyone to close their PRs, and I manually double-check PRs remained
> opened.
> 
> The third need is to automatically tests all opened PRs and provide
>> visas
> to every PR we have. In case we have PRs with 0 blockers we should
>> take
 it
> into review process. No all newcomers aware of TC Bot, so I would
>> like to
> automate this process as much as possible.
> 
> Sincerely,
> Dmitriy Pavlov
> 
> чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev >> :
> 
>> The long period totally reduces the discontent and outrage of
>> community
>> members (if you reduce to 2-6 weeks it could be intersected with
>> human
>> events of most part of contributors like vacation, birthdays,
>> wedding,
 spam
>> filters and etc.), believe me (I have the same experience as I
 mentioned)
>> 
>> From the other hand, what the real reason to reduce it to the
>> shorter
>> period? Bot needs? Robot needs?
>> Robot could wait, I hope:)
>> 
>> чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
>> 
>>> Alexey,
>>> 
>>> Yep, I imagined a similar procedure in my mind. Just curious,
>> why do
>>> you think that a period before actions are taken should be so
>> long
>>> (3-6 months)?.
>>> 
>>> чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev <
>> zaleslaw@gmail.com
> :
 
 Dear Igniters, I have one suggestion
 
 If a most of commiters will support idea of automatic
>> "cleaning",
 we
>>> should
 provide next options
 
   - declare a long period for putting labels or leaving
>> comments
 for
   useful PRs from their authors (about 3-6 months)
   - generate notifications for all authors of all PRs with
>> clarification
   of our goals
   - every month reminder in dev-list and via e-mail to each
>> PR's
>> author
 
 The best way, of course, the closing by our hands in each
>> module
 and
>> area
 with tags "obsolete" or something else.
 
 P.S. I was in the same situation in Open Street Map community
>> and
 the
 principles for automated cleaning were the same like suggested
>> by
>> myself
 above
 
 I hope that we will be careful with our community
 
 чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov <
>> dpav...@apache.org>:
 
> Nikolay, committer could after setting up a link between GH &
 Apache
> accounts.
> https://gitbox.apache.org/setup/
> 
> чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov <
 nizhi...@apache.org>:
> 
>> Yes.
>> 
>> Do someone have permission to close my(or any other
 contributor) PR
>>> to
>> apache/ignite?
>> 
>> В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
>>> NIkolay,
>>> 
>>> Do you mean technical ability?
>>> 
>>> чт, 25 июл. 2019 г. в 10:33, Nikolay 

Re: Test naming on TC JUnit 5

[Ivan Fedotov]

Also, according to IGNITE-10973 [1] (in nutshell: maven dependencies +
migration Examples module), we are ready for JUnit 5.

What is a strategy for massive migration?

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

чт, 25 июл. 2019 г. в 14:33, Ivan Fedotov :

> Hi Dmitriy.
>
> Thank you for your reply, re-running concrete test cases, not a suite, is
> another one utility of JUnit 5.
>
> I want to pay your (and other Igniters) attention on .net tests. I faced
> with failure "The filename or extension is too long" in ExecutableTest [1].
> The problem is in jvmClasspath because other args are hardcoded. After
> comparison log files from my branch [2] and master [3] I found that
> jvmClasspath variable contains all maven dependencies. I added more
> dependencies to parent/pom file and mentioned string becomes too long for
> system .net function.
>
> I think that the problem is in Classpath.cs#CreateClasspath method: if we
> want to add more dependencies to Ignite project (not necessary JUnit, any
> dependency) it will lead to the same problem. Furthermore, jvmClasspath
> variable contains an enumeration of all jar files.
>
> Is it correct behavior of CreateClasspath method or we need to change its
> implementation?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148
> [2]
> https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning
> [3]
> https://ci.ignite.apache.org/viewLog.html?buildId=4394312=IgniteTests24Java8_PlatformNetLongRunning=testsInfo
>
>
> чт, 25 июл. 2019 г. в 10:11, Dmitriy Pavlov :
>
>> Hi Ivan.
>>
>> Yes, test name changes (reported by TC), would be a short term issue, but
>> TC bot will accumulate statistics quite fast.
>>
>> We can consider applying changes before a weekend, so the maximum number
>> of
>> re-runs occur; so the maximum statistic is the outcome.
>>
>> Moreover, the test name change may have a positive effect in long-term,
>> because of a re-run of a particular suite on TC has exactly the same
>> impact
>> on test name. It will be a path to test case wihtout suite.
>> So for now, Re-run possible blockers activate the whole suite, but when
>> all
>> tests change their names, TC bot could activate only some test case(s)
>> with
>> a test(s) failure to rerun. It could also bring faster detection of master
>> failures.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>> пн, 22 июл. 2019 г. в 20:10, Ivan Fedotov :
>>
>> > Hi, igniters!
>> >
>> > In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5
>> > tests are going to appear in master.
>> >
>> > During migration Ignite on JUnit5 I faced that the test naming will be
>> > changed.
>> > The names are different, in the version before path consists from "path
>> to
>> > suite: path to test" [2] and in the version after just "path to test"
>> [3].
>> > I want to inform you that it will lead to obsolete current history for
>> some
>> > tests: see tests with label "History for base branch is absent" [4]. It
>> > means that TC bot shows those tests as blockers because of a different
>> > name, but indeed tests were red on JUnit 4 version also. After some
>> time in
>> > the new version of JUnit we will get a history for mentioned tests
>> again.
>> >
>> > Do have some of us have questions/comments according to migration?
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-10973
>> > [2]
>> >
>> >
>> https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1
>> > [3]
>> >
>> >
>> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__
>> > [4]
>> >
>> >
>> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest
>> > --
>> > Ivan Fedotov.
>> >
>> > ivanan...@gmail.com
>> >
>>
>
>
> --
> Ivan Fedotov.
>
> ivanan...@gmail.com
>


-- 
Ivan Fedotov.

ivanan...@gmail.com

Re: Test naming on TC JUnit 5

[Ivan Fedotov]

Hi Dmitriy.

Thank you for your reply, re-running concrete test cases, not a suite, is
another one utility of JUnit 5.

I want to pay your (and other Igniters) attention on .net tests. I faced
with failure "The filename or extension is too long" in ExecutableTest [1].
The problem is in jvmClasspath because other args are hardcoded. After
comparison log files from my branch [2] and master [3] I found that
jvmClasspath variable contains all maven dependencies. I added more
dependencies to parent/pom file and mentioned string becomes too long for
system .net function.

I think that the problem is in Classpath.cs#CreateClasspath method: if we
want to add more dependencies to Ignite project (not necessary JUnit, any
dependency) it will lead to the same problem. Furthermore, jvmClasspath
variable contains an enumeration of all jar files.

Is it correct behavior of CreateClasspath method or we need to change its
implementation?

[1]
https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core.Tests/ExecutableTest.cs#L148
[2]
https://ci.ignite.apache.org/viewLog.html?buildId=4318302=buildResultsDiv=IgniteTests24Java8_PlatformNetLongRunning
[3]
https://ci.ignite.apache.org/viewLog.html?buildId=4394312=IgniteTests24Java8_PlatformNetLongRunning=testsInfo


чт, 25 июл. 2019 г. в 10:11, Dmitriy Pavlov :

> Hi Ivan.
>
> Yes, test name changes (reported by TC), would be a short term issue, but
> TC bot will accumulate statistics quite fast.
>
> We can consider applying changes before a weekend, so the maximum number of
> re-runs occur; so the maximum statistic is the outcome.
>
> Moreover, the test name change may have a positive effect in long-term,
> because of a re-run of a particular suite on TC has exactly the same impact
> on test name. It will be a path to test case wihtout suite.
> So for now, Re-run possible blockers activate the whole suite, but when all
> tests change their names, TC bot could activate only some test case(s) with
> a test(s) failure to rerun. It could also bring faster detection of master
> failures.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 22 июл. 2019 г. в 20:10, Ivan Fedotov :
>
> > Hi, igniters!
> >
> > In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5
> > tests are going to appear in master.
> >
> > During migration Ignite on JUnit5 I faced that the test naming will be
> > changed.
> > The names are different, in the version before path consists from "path
> to
> > suite: path to test" [2] and in the version after just "path to test"
> [3].
> > I want to inform you that it will lead to obsolete current history for
> some
> > tests: see tests with label "History for base branch is absent" [4]. It
> > means that TC bot shows those tests as blockers because of a different
> > name, but indeed tests were red on JUnit 4 version also. After some time
> in
> > the new version of JUnit we will get a history for mentioned tests again.
> >
> > Do have some of us have questions/comments according to migration?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-10973
> > [2]
> >
> >
> https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1
> > [3]
> >
> >
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__
> > [4]
> >
> >
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest
> > --
> > Ivan Fedotov.
> >
> > ivanan...@gmail.com
> >
>


-- 
Ivan Fedotov.

ivanan...@gmail.com

Re: Clean up of our PRs and IEPs before 2019

[Anton Vinogradov]

Folks,

Is it possible just to ignore obsolete PRs somehow?
Not sure this crusade worth it.

On Thu, Jul 25, 2019 at 1:18 PM Павлухин Иван  wrote:

> Maxim,
>
> Quite a nice idea. Could we go even further? Add a comment to each 1-2
> year old PR asking if the author could close it (most likely with help
> of some automation). As I know GitHub sends emails with PR comments to
> authors.
>
> чт, 25 июл. 2019 г. в 13:05, Dmitriy Pavlov :
> >
> > Folks, please close not needed PRs.
> >
> > I don't have contact with Pyatkov & dkarachentsev. Folks, please step in.
> > Also, feel free to reopen PRs if you still want change to be merged.
> >
> > чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :
> >
> > > Folks,
> > >
> > > Can we contact with some members manually and ask them to close unused
> > > PRs? Most of the users are active community members, so I think they
> > > will respond quite fast.
> > >
> > > I've briefly checked GitHub:
> > >
> > > dkarachentsev - 62 opened PRs
> > > ilantukh - 58 opened PRs
> > > dgovorukhin - 44 opened PRs
> > > mcherkasov - 23 opened PRs
> > > ascherbakoff  - 22 opened PRs
> > > vldpyatkov - 21 opened PRs
> > >
> > > On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov 
> wrote:
> > > >
> > > > Hi Alexey,
> > > >
> > > > second need it to check all open PRs from community members for
> fixes,
> > > > which could be merged to Ignite codebase.
> > > >
> > > > Which is why I'm not so sure that we should automatically close. I
> ask
> > > > everyone to close their PRs, and I manually double-check PRs remained
> > > > opened.
> > > >
> > > > The third need is to automatically tests all opened PRs and provide
> visas
> > > > to every PR we have. In case we have PRs with 0 blockers we should
> take
> > > it
> > > > into review process. No all newcomers aware of TC Bot, so I would
> like to
> > > > automate this process as much as possible.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev  >:
> > > >
> > > > > The long period totally reduces the discontent and outrage of
> community
> > > > > members (if you reduce to 2-6 weeks it could be intersected with
> human
> > > > > events of most part of contributors like vacation, birthdays,
> wedding,
> > > spam
> > > > > filters and etc.), believe me (I have the same experience as I
> > > mentioned)
> > > > >
> > > > > From the other hand, what the real reason to reduce it to the
> shorter
> > > > > period? Bot needs? Robot needs?
> > > > > Robot could wait, I hope:)
> > > > >
> > > > > чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > Yep, I imagined a similar procedure in my mind. Just curious,
> why do
> > > > > > you think that a period before actions are taken should be so
> long
> > > > > > (3-6 months)?.
> > > > > >
> > > > > > чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev <
> zaleslaw@gmail.com
> > > >:
> > > > > > >
> > > > > > > Dear Igniters, I have one suggestion
> > > > > > >
> > > > > > > If a most of commiters will support idea of automatic
> "cleaning",
> > > we
> > > > > > should
> > > > > > > provide next options
> > > > > > >
> > > > > > >- declare a long period for putting labels or leaving
> comments
> > > for
> > > > > > >useful PRs from their authors (about 3-6 months)
> > > > > > >- generate notifications for all authors of all PRs with
> > > > > clarification
> > > > > > >of our goals
> > > > > > >- every month reminder in dev-list and via e-mail to each
> PR's
> > > > > author
> > > > > > >
> > > > > > > The best way, of course, the closing by our hands in each
> module
> > > and
> > > > > area
> > > > > > > with tags "obsolete" or something else.
> > > > > > >
> > > > > > > P.S. I was in the same situation in Open Street Map community
> and
> > > the
> > > > > > > principles for automated cleaning were the same like suggested
> by
> > > > > myself
> > > > > > > above
> > > > > > >
> > > > > > > I hope that we will be careful with our community
> > > > > > >
> > > > > > > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov <
> dpav...@apache.org>:
> > > > > > >
> > > > > > > > Nikolay, committer could after setting up a link between GH &
> > > Apache
> > > > > > > > accounts.
> > > > > > > > https://gitbox.apache.org/setup/
> > > > > > > >
> > > > > > > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov <
> > > nizhi...@apache.org>:
> > > > > > > >
> > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > Do someone have permission to close my(or any other
> > > contributor) PR
> > > > > > to
> > > > > > > > > apache/ignite?
> > > > > > > > >
> > > > > > > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > > > > > > NIkolay,
> > > > > > > > > >
> > > > > > > > > > Do you mean technical ability?
> > > > > > > > > >
> > > > > > > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov <
> > > > > nizhi...@apache.org
> > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > Hello, Ivan.
> > > > 

[jira] [Created] (IGNITE-12013) NullPointerException is thrown by ExchangeLatchManager during cache creation

[Vyacheslav Koptilin (JIRA)]

Vyacheslav Koptilin created IGNITE-12013:


 Summary: NullPointerException is thrown by ExchangeLatchManager 
during cache creation
 Key: IGNITE-12013
 URL: https://issues.apache.org/jira/browse/IGNITE-12013
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
 Attachments: ignitenullpointer.log

{{NullPointerException}} may be thrown during cluster topology change:
{code:java}
[14:15:49,820][SEVERE][exchange-worker-#63][GridDhtPartitionsExchangeFuture] 
Failed to reinitialize local partitions (rebalancing will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=468, 
minorTopVer=1], discoEvt=DiscoveryCustomEvent 
[customMsg=DynamicCacheChangeBatch 
[id=728f11e1c61-11d31f36-508d-47e0-9a9c-d4f5a270948d, 
reqs=[DynamicCacheChangeRequest [cacheName=SQL_PUBLIC_UPRIYA_112093_TB, 
hasCfg=true, nodeId=10a0b1a4-09bb-4aa6-81e0-537a6431283b, 
clientStartOnly=false, stop=false, destroy=false, disabledAfterStartfalse]], 
exchangeActions=ExchangeActions [startCaches=[SQL_PUBLIC_UPRIYA_112093_TB], 
stopCaches=null, startGrps=[SQL_PUBLIC_UPRIYA_112093_TB], stopGrps=[], 
resetParts=null, stateChangeRequest=null], startCaches=false], 
affTopVer=AffinityTopologyVersion [topVer=468, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=10a0b1a4-09bb-4aa6-81e0-537a6431283b, addrs=[0:0:0:0:0:0:0:1%lo, 
10.244.1.100, 127.0.0.1], sockAddrs=[/10.244.1.100:0, /0:0:0:0:0:0:0:1%lo:0, 
/127.0.0.1:0], discPort=0, order=39, intOrder=27, 
lastExchangeTime=1563872413854, loc=false, ver=2.7.0#20181130-sha1:256ae401, 
isClient=true], topVer=468, nodeId8=6a076901, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1563891349722]], nodeId=10a0b1a4, 
evt=DISCOVERY_CUSTOM_EVT]
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.canSkipJoiningNodes(ExchangeLatchManager.java:327)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1401)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:806)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:745)
{code}
The original topic on the user-list: 
[http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-7-0-server-node-null-pointer-exception-td28899.html]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Clean up of our PRs and IEPs before 2019

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

Maxim,

Quite a nice idea. Could we go even further? Add a comment to each 1-2
year old PR asking if the author could close it (most likely with help
of some automation). As I know GitHub sends emails with PR comments to
authors.

чт, 25 июл. 2019 г. в 13:05, Dmitriy Pavlov :
>
> Folks, please close not needed PRs.
>
> I don't have contact with Pyatkov & dkarachentsev. Folks, please step in.
> Also, feel free to reopen PRs if you still want change to be merged.
>
> чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :
>
> > Folks,
> >
> > Can we contact with some members manually and ask them to close unused
> > PRs? Most of the users are active community members, so I think they
> > will respond quite fast.
> >
> > I've briefly checked GitHub:
> >
> > dkarachentsev - 62 opened PRs
> > ilantukh - 58 opened PRs
> > dgovorukhin - 44 opened PRs
> > mcherkasov - 23 opened PRs
> > ascherbakoff  - 22 opened PRs
> > vldpyatkov - 21 opened PRs
> >
> > On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov  wrote:
> > >
> > > Hi Alexey,
> > >
> > > second need it to check all open PRs from community members for fixes,
> > > which could be merged to Ignite codebase.
> > >
> > > Which is why I'm not so sure that we should automatically close. I ask
> > > everyone to close their PRs, and I manually double-check PRs remained
> > > opened.
> > >
> > > The third need is to automatically tests all opened PRs and provide visas
> > > to every PR we have. In case we have PRs with 0 blockers we should take
> > it
> > > into review process. No all newcomers aware of TC Bot, so I would like to
> > > automate this process as much as possible.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev :
> > >
> > > > The long period totally reduces the discontent and outrage of community
> > > > members (if you reduce to 2-6 weeks it could be intersected with human
> > > > events of most part of contributors like vacation, birthdays, wedding,
> > spam
> > > > filters and etc.), believe me (I have the same experience as I
> > mentioned)
> > > >
> > > > From the other hand, what the real reason to reduce it to the shorter
> > > > period? Bot needs? Robot needs?
> > > > Robot could wait, I hope:)
> > > >
> > > > чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> > > >
> > > > > Alexey,
> > > > >
> > > > > Yep, I imagined a similar procedure in my mind. Just curious, why do
> > > > > you think that a period before actions are taken should be so long
> > > > > (3-6 months)?.
> > > > >
> > > > > чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev  > >:
> > > > > >
> > > > > > Dear Igniters, I have one suggestion
> > > > > >
> > > > > > If a most of commiters will support idea of automatic "cleaning",
> > we
> > > > > should
> > > > > > provide next options
> > > > > >
> > > > > >- declare a long period for putting labels or leaving comments
> > for
> > > > > >useful PRs from their authors (about 3-6 months)
> > > > > >- generate notifications for all authors of all PRs with
> > > > clarification
> > > > > >of our goals
> > > > > >- every month reminder in dev-list and via e-mail to each PR's
> > > > author
> > > > > >
> > > > > > The best way, of course, the closing by our hands in each module
> > and
> > > > area
> > > > > > with tags "obsolete" or something else.
> > > > > >
> > > > > > P.S. I was in the same situation in Open Street Map community and
> > the
> > > > > > principles for automated cleaning were the same like suggested by
> > > > myself
> > > > > > above
> > > > > >
> > > > > > I hope that we will be careful with our community
> > > > > >
> > > > > > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
> > > > > >
> > > > > > > Nikolay, committer could after setting up a link between GH &
> > Apache
> > > > > > > accounts.
> > > > > > > https://gitbox.apache.org/setup/
> > > > > > >
> > > > > > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov <
> > nizhi...@apache.org>:
> > > > > > >
> > > > > > > > Yes.
> > > > > > > >
> > > > > > > > Do someone have permission to close my(or any other
> > contributor) PR
> > > > > to
> > > > > > > > apache/ignite?
> > > > > > > >
> > > > > > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > > > > > NIkolay,
> > > > > > > > >
> > > > > > > > > Do you mean technical ability?
> > > > > > > > >
> > > > > > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov <
> > > > nizhi...@apache.org
> > > > > >:
> > > > > > > > > >
> > > > > > > > > > Hello, Ivan.
> > > > > > > > > >
> > > > > > > > > > Do we have the ability to close PRs from other
> > contributors?
> > > > > > > > > >
> > > > > > > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > >  I would like to resume a discussion about PRs cleanup.
> > > > > > > Additionally
> > > > > > > > > > > to concerns provided earlier some TC Bot operations are
> > > > slowed
> > > > > down
> > > > > > > > > > > due to a huge 

Re: Clean up of our PRs and IEPs before 2019

[Dmitriy Pavlov]

Folks, please close not needed PRs.

I don't have contact with Pyatkov & dkarachentsev. Folks, please step in.
Also, feel free to reopen PRs if you still want change to be merged.

чт, 25 июл. 2019 г. в 12:39, Maxim Muzafarov :

> Folks,
>
> Can we contact with some members manually and ask them to close unused
> PRs? Most of the users are active community members, so I think they
> will respond quite fast.
>
> I've briefly checked GitHub:
>
> dkarachentsev - 62 opened PRs
> ilantukh - 58 opened PRs
> dgovorukhin - 44 opened PRs
> mcherkasov - 23 opened PRs
> ascherbakoff  - 22 opened PRs
> vldpyatkov - 21 opened PRs
>
> On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov  wrote:
> >
> > Hi Alexey,
> >
> > second need it to check all open PRs from community members for fixes,
> > which could be merged to Ignite codebase.
> >
> > Which is why I'm not so sure that we should automatically close. I ask
> > everyone to close their PRs, and I manually double-check PRs remained
> > opened.
> >
> > The third need is to automatically tests all opened PRs and provide visas
> > to every PR we have. In case we have PRs with 0 blockers we should take
> it
> > into review process. No all newcomers aware of TC Bot, so I would like to
> > automate this process as much as possible.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev :
> >
> > > The long period totally reduces the discontent and outrage of community
> > > members (if you reduce to 2-6 weeks it could be intersected with human
> > > events of most part of contributors like vacation, birthdays, wedding,
> spam
> > > filters and etc.), believe me (I have the same experience as I
> mentioned)
> > >
> > > From the other hand, what the real reason to reduce it to the shorter
> > > period? Bot needs? Robot needs?
> > > Robot could wait, I hope:)
> > >
> > > чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> > >
> > > > Alexey,
> > > >
> > > > Yep, I imagined a similar procedure in my mind. Just curious, why do
> > > > you think that a period before actions are taken should be so long
> > > > (3-6 months)?.
> > > >
> > > > чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev  >:
> > > > >
> > > > > Dear Igniters, I have one suggestion
> > > > >
> > > > > If a most of commiters will support idea of automatic "cleaning",
> we
> > > > should
> > > > > provide next options
> > > > >
> > > > >- declare a long period for putting labels or leaving comments
> for
> > > > >useful PRs from their authors (about 3-6 months)
> > > > >- generate notifications for all authors of all PRs with
> > > clarification
> > > > >of our goals
> > > > >- every month reminder in dev-list and via e-mail to each PR's
> > > author
> > > > >
> > > > > The best way, of course, the closing by our hands in each module
> and
> > > area
> > > > > with tags "obsolete" or something else.
> > > > >
> > > > > P.S. I was in the same situation in Open Street Map community and
> the
> > > > > principles for automated cleaning were the same like suggested by
> > > myself
> > > > > above
> > > > >
> > > > > I hope that we will be careful with our community
> > > > >
> > > > > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
> > > > >
> > > > > > Nikolay, committer could after setting up a link between GH &
> Apache
> > > > > > accounts.
> > > > > > https://gitbox.apache.org/setup/
> > > > > >
> > > > > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov <
> nizhi...@apache.org>:
> > > > > >
> > > > > > > Yes.
> > > > > > >
> > > > > > > Do someone have permission to close my(or any other
> contributor) PR
> > > > to
> > > > > > > apache/ignite?
> > > > > > >
> > > > > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > > > > NIkolay,
> > > > > > > >
> > > > > > > > Do you mean technical ability?
> > > > > > > >
> > > > > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov <
> > > nizhi...@apache.org
> > > > >:
> > > > > > > > >
> > > > > > > > > Hello, Ivan.
> > > > > > > > >
> > > > > > > > > Do we have the ability to close PRs from other
> contributors?
> > > > > > > > >
> > > > > > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > > > > > Igniters,
> > > > > > > > > >
> > > > > > > > > >  I would like to resume a discussion about PRs cleanup.
> > > > > > Additionally
> > > > > > > > > > to concerns provided earlier some TC Bot operations are
> > > slowed
> > > > down
> > > > > > > > > > due to a huge amount of open PRs.
> > > > > > > > > >
> > > > > > > > > > As time has passed, I ask you all again to share an
> opinion
> > > > about
> > > > > > > > > > centralized cleanup of obsolete PRs. Also, a precise
> criteria
> > > > to
> > > > > > > > > > consider PR as obsolete is a subject for dicsussion as
> well.
> > > > > > > > > >
> > > > > > > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov <
> > > mr.wei...@gmail.com
> > > > >:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > On 11 Dec 2018, at 10:10, 

Re: Clean up of our PRs and IEPs before 2019

[Maxim Muzafarov]

Folks,

Can we contact with some members manually and ask them to close unused
PRs? Most of the users are active community members, so I think they
will respond quite fast.

I've briefly checked GitHub:

dkarachentsev - 62 opened PRs
ilantukh - 58 opened PRs
dgovorukhin - 44 opened PRs
mcherkasov - 23 opened PRs
ascherbakoff  - 22 opened PRs
vldpyatkov - 21 opened PRs

On Thu, 25 Jul 2019 at 12:28, Dmitriy Pavlov  wrote:
>
> Hi Alexey,
>
> second need it to check all open PRs from community members for fixes,
> which could be merged to Ignite codebase.
>
> Which is why I'm not so sure that we should automatically close. I ask
> everyone to close their PRs, and I manually double-check PRs remained
> opened.
>
> The third need is to automatically tests all opened PRs and provide visas
> to every PR we have. In case we have PRs with 0 blockers we should take it
> into review process. No all newcomers aware of TC Bot, so I would like to
> automate this process as much as possible.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev :
>
> > The long period totally reduces the discontent and outrage of community
> > members (if you reduce to 2-6 weeks it could be intersected with human
> > events of most part of contributors like vacation, birthdays, wedding, spam
> > filters and etc.), believe me (I have the same experience as I mentioned)
> >
> > From the other hand, what the real reason to reduce it to the shorter
> > period? Bot needs? Robot needs?
> > Robot could wait, I hope:)
> >
> > чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
> >
> > > Alexey,
> > >
> > > Yep, I imagined a similar procedure in my mind. Just curious, why do
> > > you think that a period before actions are taken should be so long
> > > (3-6 months)?.
> > >
> > > чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev :
> > > >
> > > > Dear Igniters, I have one suggestion
> > > >
> > > > If a most of commiters will support idea of automatic "cleaning", we
> > > should
> > > > provide next options
> > > >
> > > >- declare a long period for putting labels or leaving comments for
> > > >useful PRs from their authors (about 3-6 months)
> > > >- generate notifications for all authors of all PRs with
> > clarification
> > > >of our goals
> > > >- every month reminder in dev-list and via e-mail to each PR's
> > author
> > > >
> > > > The best way, of course, the closing by our hands in each module and
> > area
> > > > with tags "obsolete" or something else.
> > > >
> > > > P.S. I was in the same situation in Open Street Map community and the
> > > > principles for automated cleaning were the same like suggested by
> > myself
> > > > above
> > > >
> > > > I hope that we will be careful with our community
> > > >
> > > > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
> > > >
> > > > > Nikolay, committer could after setting up a link between GH & Apache
> > > > > accounts.
> > > > > https://gitbox.apache.org/setup/
> > > > >
> > > > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :
> > > > >
> > > > > > Yes.
> > > > > >
> > > > > > Do someone have permission to close my(or any other contributor) PR
> > > to
> > > > > > apache/ignite?
> > > > > >
> > > > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > > > NIkolay,
> > > > > > >
> > > > > > > Do you mean technical ability?
> > > > > > >
> > > > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov <
> > nizhi...@apache.org
> > > >:
> > > > > > > >
> > > > > > > > Hello, Ivan.
> > > > > > > >
> > > > > > > > Do we have the ability to close PRs from other contributors?
> > > > > > > >
> > > > > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > >  I would like to resume a discussion about PRs cleanup.
> > > > > Additionally
> > > > > > > > > to concerns provided earlier some TC Bot operations are
> > slowed
> > > down
> > > > > > > > > due to a huge amount of open PRs.
> > > > > > > > >
> > > > > > > > > As time has passed, I ask you all again to share an opinion
> > > about
> > > > > > > > > centralized cleanup of obsolete PRs. Also, a precise criteria
> > > to
> > > > > > > > > consider PR as obsolete is a subject for dicsussion as well.
> > > > > > > > >
> > > > > > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov <
> > mr.wei...@gmail.com
> > > >:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov <
> > > nizhi...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hello, Ivan.
> > > > > > > > > > >
> > > > > > > > > > > Personally, I keep my PR's clear.
> > > > > > > > > > > So, I don't have dozens of opened PR.
> > > > > > > > > > >
> > > > > > > > > > > But, I don't support Dmitriy proposal for several
> > reasons:
> > > > > > > > > > >
> > > > > > > > > > > 1. We introduce some new, not required, level of
> > > bureaucracy.
> > > > > > > > > > > From my experience - not 

Re: Clean up of our PRs and IEPs before 2019

[Dmitriy Pavlov]

Hi Alexey,

second need it to check all open PRs from community members for fixes,
which could be merged to Ignite codebase.

Which is why I'm not so sure that we should automatically close. I ask
everyone to close their PRs, and I manually double-check PRs remained
opened.

The third need is to automatically tests all opened PRs and provide visas
to every PR we have. In case we have PRs with 0 blockers we should take it
into review process. No all newcomers aware of TC Bot, so I would like to
automate this process as much as possible.

Sincerely,
Dmitriy Pavlov

чт, 25 июл. 2019 г. в 12:22, Alexey Zinoviev :

> The long period totally reduces the discontent and outrage of community
> members (if you reduce to 2-6 weeks it could be intersected with human
> events of most part of contributors like vacation, birthdays, wedding, spam
> filters and etc.), believe me (I have the same experience as I mentioned)
>
> From the other hand, what the real reason to reduce it to the shorter
> period? Bot needs? Robot needs?
> Robot could wait, I hope:)
>
> чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :
>
> > Alexey,
> >
> > Yep, I imagined a similar procedure in my mind. Just curious, why do
> > you think that a period before actions are taken should be so long
> > (3-6 months)?.
> >
> > чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev :
> > >
> > > Dear Igniters, I have one suggestion
> > >
> > > If a most of commiters will support idea of automatic "cleaning", we
> > should
> > > provide next options
> > >
> > >- declare a long period for putting labels or leaving comments for
> > >useful PRs from their authors (about 3-6 months)
> > >- generate notifications for all authors of all PRs with
> clarification
> > >of our goals
> > >- every month reminder in dev-list and via e-mail to each PR's
> author
> > >
> > > The best way, of course, the closing by our hands in each module and
> area
> > > with tags "obsolete" or something else.
> > >
> > > P.S. I was in the same situation in Open Street Map community and the
> > > principles for automated cleaning were the same like suggested by
> myself
> > > above
> > >
> > > I hope that we will be careful with our community
> > >
> > > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
> > >
> > > > Nikolay, committer could after setting up a link between GH & Apache
> > > > accounts.
> > > > https://gitbox.apache.org/setup/
> > > >
> > > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :
> > > >
> > > > > Yes.
> > > > >
> > > > > Do someone have permission to close my(or any other contributor) PR
> > to
> > > > > apache/ignite?
> > > > >
> > > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > > NIkolay,
> > > > > >
> > > > > > Do you mean technical ability?
> > > > > >
> > > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov <
> nizhi...@apache.org
> > >:
> > > > > > >
> > > > > > > Hello, Ivan.
> > > > > > >
> > > > > > > Do we have the ability to close PRs from other contributors?
> > > > > > >
> > > > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > >  I would like to resume a discussion about PRs cleanup.
> > > > Additionally
> > > > > > > > to concerns provided earlier some TC Bot operations are
> slowed
> > down
> > > > > > > > due to a huge amount of open PRs.
> > > > > > > >
> > > > > > > > As time has passed, I ask you all again to share an opinion
> > about
> > > > > > > > centralized cleanup of obsolete PRs. Also, a precise criteria
> > to
> > > > > > > > consider PR as obsolete is a subject for dicsussion as well.
> > > > > > > >
> > > > > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov <
> mr.wei...@gmail.com
> > >:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov <
> > nizhi...@apache.org
> > > > >
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hello, Ivan.
> > > > > > > > > >
> > > > > > > > > > Personally, I keep my PR's clear.
> > > > > > > > > > So, I don't have dozens of opened PR.
> > > > > > > > > >
> > > > > > > > > > But, I don't support Dmitriy proposal for several
> reasons:
> > > > > > > > > >
> > > > > > > > > > 1. We introduce some new, not required, level of
> > bureaucracy.
> > > > > > > > > > From my experience - not required bureaucracy is a BAD
> > thing.
> > > > > > > > > >
> > > > > > > > > > 2. We spread our work pattern to whole community.
> > > > > > > > > > I believe there are many patterns of dealing with *YOUR
> > OWN*
> > > > PRs.
> > > > > > > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > > > > > > Whats wrong with it?
> > > > > > > > > >
> > > > > > > > > > 3. I dont' see any issues with many opened PRs.
> > > > > > > > > > What problem we trying to solve?
> > > > > > > > >
> > > > > > > > > But I see.
> > > > > > > > > Lots of opened PRs (and obsolete branches as well) consumes
> > huge
> > > > > amount of data and time when TC performs 

Re: Clean up of our PRs and IEPs before 2019

[Alexey Zinoviev]

The long period totally reduces the discontent and outrage of community
members (if you reduce to 2-6 weeks it could be intersected with human
events of most part of contributors like vacation, birthdays, wedding, spam
filters and etc.), believe me (I have the same experience as I mentioned)

>From the other hand, what the real reason to reduce it to the shorter
period? Bot needs? Robot needs?
Robot could wait, I hope:)

чт, 25 июл. 2019 г. в 14:08, Павлухин Иван :

> Alexey,
>
> Yep, I imagined a similar procedure in my mind. Just curious, why do
> you think that a period before actions are taken should be so long
> (3-6 months)?.
>
> чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev :
> >
> > Dear Igniters, I have one suggestion
> >
> > If a most of commiters will support idea of automatic "cleaning", we
> should
> > provide next options
> >
> >- declare a long period for putting labels or leaving comments for
> >useful PRs from their authors (about 3-6 months)
> >- generate notifications for all authors of all PRs with clarification
> >of our goals
> >- every month reminder in dev-list and via e-mail to each PR's author
> >
> > The best way, of course, the closing by our hands in each module and area
> > with tags "obsolete" or something else.
> >
> > P.S. I was in the same situation in Open Street Map community and the
> > principles for automated cleaning were the same like suggested by myself
> > above
> >
> > I hope that we will be careful with our community
> >
> > чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
> >
> > > Nikolay, committer could after setting up a link between GH & Apache
> > > accounts.
> > > https://gitbox.apache.org/setup/
> > >
> > > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :
> > >
> > > > Yes.
> > > >
> > > > Do someone have permission to close my(or any other contributor) PR
> to
> > > > apache/ignite?
> > > >
> > > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > > NIkolay,
> > > > >
> > > > > Do you mean technical ability?
> > > > >
> > > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov  >:
> > > > > >
> > > > > > Hello, Ivan.
> > > > > >
> > > > > > Do we have the ability to close PRs from other contributors?
> > > > > >
> > > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > > Igniters,
> > > > > > >
> > > > > > >  I would like to resume a discussion about PRs cleanup.
> > > Additionally
> > > > > > > to concerns provided earlier some TC Bot operations are slowed
> down
> > > > > > > due to a huge amount of open PRs.
> > > > > > >
> > > > > > > As time has passed, I ask you all again to share an opinion
> about
> > > > > > > centralized cleanup of obsolete PRs. Also, a precise criteria
> to
> > > > > > > consider PR as obsolete is a subject for dicsussion as well.
> > > > > > >
> > > > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov  >:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov <
> nizhi...@apache.org
> > > >
> > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello, Ivan.
> > > > > > > > >
> > > > > > > > > Personally, I keep my PR's clear.
> > > > > > > > > So, I don't have dozens of opened PR.
> > > > > > > > >
> > > > > > > > > But, I don't support Dmitriy proposal for several reasons:
> > > > > > > > >
> > > > > > > > > 1. We introduce some new, not required, level of
> bureaucracy.
> > > > > > > > > From my experience - not required bureaucracy is a BAD
> thing.
> > > > > > > > >
> > > > > > > > > 2. We spread our work pattern to whole community.
> > > > > > > > > I believe there are many patterns of dealing with *YOUR
> OWN*
> > > PRs.
> > > > > > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > > > > > Whats wrong with it?
> > > > > > > > >
> > > > > > > > > 3. I dont' see any issues with many opened PRs.
> > > > > > > > > What problem we trying to solve?
> > > > > > > >
> > > > > > > > But I see.
> > > > > > > > Lots of opened PRs (and obsolete branches as well) consumes
> huge
> > > > amount of data and time when TC performs changes detect operations
> (every
> > > > minute, BTW).
> > > > > > > > Also, IMO, ORDER is not an unnecessary level of bureaucracy,
> but
> > > > part of the project development workflow in area of cleaning up and
> > > keeping
> > > > everything fresh and actual.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 4. Closing abanodned PRs doesn't force anybody to review
> the
> > > > rest.
> > > > > > > > > Instead of ordering something to one way or another, let's
> > > solve
> > > > real problem:
> > > > > > > > >
> > > > > > > > >   - help the community doing PR review.
> > > > > > > > >   - fixing failing tests.
> > > > > > > > >   - introducing new code inspections to make our code
> base
> > > > clear.
> > > > > > > > >   - making Ignite improvements
> > > > > > > > >
> > > > > > > > > 5. I don't see how our numbers differs from other Apache
> > > projects
> > > 

Re: Clean up of our PRs and IEPs before 2019

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

Alexey,

Yep, I imagined a similar procedure in my mind. Just curious, why do
you think that a period before actions are taken should be so long
(3-6 months)?.

чт, 25 июл. 2019 г. в 11:55, Alexey Zinoviev :
>
> Dear Igniters, I have one suggestion
>
> If a most of commiters will support idea of automatic "cleaning", we should
> provide next options
>
>- declare a long period for putting labels or leaving comments for
>useful PRs from their authors (about 3-6 months)
>- generate notifications for all authors of all PRs with clarification
>of our goals
>- every month reminder in dev-list and via e-mail to each PR's author
>
> The best way, of course, the closing by our hands in each module and area
> with tags "obsolete" or something else.
>
> P.S. I was in the same situation in Open Street Map community and the
> principles for automated cleaning were the same like suggested by myself
> above
>
> I hope that we will be careful with our community
>
> чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :
>
> > Nikolay, committer could after setting up a link between GH & Apache
> > accounts.
> > https://gitbox.apache.org/setup/
> >
> > чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :
> >
> > > Yes.
> > >
> > > Do someone have permission to close my(or any other contributor) PR to
> > > apache/ignite?
> > >
> > > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > > NIkolay,
> > > >
> > > > Do you mean technical ability?
> > > >
> > > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov :
> > > > >
> > > > > Hello, Ivan.
> > > > >
> > > > > Do we have the ability to close PRs from other contributors?
> > > > >
> > > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > > Igniters,
> > > > > >
> > > > > >  I would like to resume a discussion about PRs cleanup.
> > Additionally
> > > > > > to concerns provided earlier some TC Bot operations are slowed down
> > > > > > due to a huge amount of open PRs.
> > > > > >
> > > > > > As time has passed, I ask you all again to share an opinion about
> > > > > > centralized cleanup of obsolete PRs. Also, a precise criteria to
> > > > > > consider PR as obsolete is a subject for dicsussion as well.
> > > > > >
> > > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  > >
> > > wrote:
> > > > > > > >
> > > > > > > > Hello, Ivan.
> > > > > > > >
> > > > > > > > Personally, I keep my PR's clear.
> > > > > > > > So, I don't have dozens of opened PR.
> > > > > > > >
> > > > > > > > But, I don't support Dmitriy proposal for several reasons:
> > > > > > > >
> > > > > > > > 1. We introduce some new, not required, level of bureaucracy.
> > > > > > > > From my experience - not required bureaucracy is a BAD thing.
> > > > > > > >
> > > > > > > > 2. We spread our work pattern to whole community.
> > > > > > > > I believe there are many patterns of dealing with *YOUR OWN*
> > PRs.
> > > > > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > > > > Whats wrong with it?
> > > > > > > >
> > > > > > > > 3. I dont' see any issues with many opened PRs.
> > > > > > > > What problem we trying to solve?
> > > > > > >
> > > > > > > But I see.
> > > > > > > Lots of opened PRs (and obsolete branches as well) consumes huge
> > > amount of data and time when TC performs changes detect operations (every
> > > minute, BTW).
> > > > > > > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but
> > > part of the project development workflow in area of cleaning up and
> > keeping
> > > everything fresh and actual.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > 4. Closing abanodned PRs doesn't force anybody to review the
> > > rest.
> > > > > > > > Instead of ordering something to one way or another, let's
> > solve
> > > real problem:
> > > > > > > >
> > > > > > > >   - help the community doing PR review.
> > > > > > > >   - fixing failing tests.
> > > > > > > >   - introducing new code inspections to make our code base
> > > clear.
> > > > > > > >   - making Ignite improvements
> > > > > > > >
> > > > > > > > 5. I don't see how our numbers differs from other Apache
> > projects
> > > > > > > >
> > > > > > > > Apache Kafka - 533 PR opened.
> > > > > > > > Apache Spark - 484 PR opened.
> > > > > > > > Apache Flink - 430 PR opened.
> > > > > > > >
> > > > > > > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > > > > > > Agree with Dmitriy.
> > > > > > > > >
> > > > > > > > > We use GitHub PRs in our workflow, therefore we should keep
> > > them in order.
> > > > > > > > >
> > > > > > > > > We can close PRs that refer to closed tickets, this can be
> > > done with a
> > > > > > > > > simple script.
> > > > > > > > >
> > > > > > > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван <
> > > vololo...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Nikolay,
> > > > > > > > > >
> > > > > > > > > > I must say that 

Re: Partition map exchange metrics

[Nikolay Izhikov]

Hello, Nikita.

I think

> 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> all blocking durations that happen after node starts.

No, we don't need it.

> 2. Blocking duration histogram. Based on the HistogramMetric class.

Yes, we need it.

В Чт, 25/07/2019 в 11:50 +0300, Nikita Amelchev пишет:
> Igniters,
> 
> All want to see the сacheOperationsBlockedDuration metric that will
> show current blocking duration or 0 if there is no blocking right now.
> 
> Do we need the following metrics? It seems one of them will be superfluous.
> 1. The totalCacheOperationsBlockedDuration metric that will accumulate
> all blocking durations that happen after node starts.
> 2. Blocking duration histogram. Based on the HistogramMetric class.
> User will be able to configure bounds.
> 
> ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov :
> > 
> > Guys.
> > 
> > I think we should go with the 2 metrics
> > 
> > * current PME duration (resets on finish)
> > 
> > This metric required for alerting(or automatic actions) on 
> > long PME.
> > 
> > * PME duration histogram (value added to metrics on PME finish)
> > This metric required for an:
> > * Quick PME trend analysis
> > * Quick PME history analysis
> > 
> > 
> > В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > > Nikita and Maxim,
> > > 
> > > > What if we just update current metric getCurrentPmeDuration behaviour
> > > > to show durations only for blocking PMEs?
> > > > Remain it as a long value and rename it to 
> > > > getCacheOperationsBlockedDuration.
> > > > 
> > > > No other changes will require.
> > > > 
> > > > WDYT?
> > > 
> > > I agree with these two metrics. I also think that current
> > > getCurrentPmeDuration will become redundant.
> > > 
> > > Anton,
> > > 
> > > > It looks like we're trying to implement "extended debug" instead of
> > > > "monitoring".
> > > > It should not be interesting for real admin what phase of PME is in
> > > > progress and so on.
> > > 
> > > PME is mission critical cluster process. I agree that there's a fine
> > > line between monitoring and debug here. However, it's not good to add
> > > monitoring capabilities only for scenario when everything is alright.
> > > If PME will really hang, *real admin* will be extremely interested how
> > > to return cluster back to working state. Metrics about stages completion
> > > time may really help here: e.g. if one specific node hasn't completed
> > > stage X while rest of the cluster has, it can be a signal that this node
> > > should be killed.
> > > 
> > > Of course, it's possible to build monitoring system that extract this
> > > information from logs, but:
> > > - It's more resource intensive as it requires parsing logs for all the 
> > > time
> > > - It's less reliable as log messages may change
> > > 
> > > Best Regards,
> > > Ivan Rakov
> > > 
> > > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > > Folks,
> > > > 
> > > > +1 with Anton post.
> > > > 
> > > > What if we just update current metric getCurrentPmeDuration behaviour
> > > > to show durations only for blocking PMEs?
> > > > Remain it as a long value and rename it to 
> > > > getCacheOperationsBlockedDuration.
> > > > 
> > > > No other changes will require.
> > > > 
> > > > WDYT?
> > > > 
> > > > On Wed, 24 Jul 2019 at 14:02, Nikita Amelchev  
> > > > wrote:
> > > > > Nikolay,
> > > > > 
> > > > > The сacheOperationsBlockedDuration metric will show current blocking
> > > > > duration or 0 if there is no blocking right now.
> > > > > 
> > > > > The totalCacheOperationsBlockedDuration metric will accumulate all
> > > > > blocking durations that happen after node starts.
> > > > > 
> > > > > ср, 24 июл. 2019 г. в 13:35, Nikolay Izhikov :
> > > > > > Nikita
> > > > > > 
> > > > > > What is the difference between those two metrics?
> > > > > > 
> > > > > > ср, 24 июля 2019 г., 12:45 Nikita Amelchev :
> > > > > > 
> > > > > > > Igniters, thanks for comments.
> > > > > > > 
> > > > > > >  From the discussion it can be seen that we need only two metrics 
> > > > > > > for now:
> > > > > > > - сacheOperationsBlockedDuration (long)
> > > > > > > - totalCacheOperationsBlockedDuration (long)
> > > > > > > 
> > > > > > > I will prepare PR at the nearest time.
> > > > > > > 
> > > > > > > ср, 24 июл. 2019 г. в 09:11, Zhenya Stanilovsky 
> > > > > > >  > > > > > > > :
> > > > > > > > 
> > > > > > > > +1 with Anton decisions.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > Среда, 24 июля 2019, 8:44 +03:00 от Anton Vinogradov 
> > > > > > > > > :
> > > > > > > > > 
> > > > > > > > > Folks,
> > > > > > > > > 
> > > > > > > > > It looks like we're trying to implement "extended debug" 
> > > > > > > > > instead of
> > > > > > > > > "monitoring".
> > > > > > > > > It should not be interesting for real admin what phase of PME 
> > > > > > > > > is in
> > > > > > > > > progress and so on.
> > > > > > > > > Interested 

Re: Clean up of our PRs and IEPs before 2019

[Alexey Zinoviev]

Dear Igniters, I have one suggestion

If a most of commiters will support idea of automatic "cleaning", we should
provide next options

   - declare a long period for putting labels or leaving comments for
   useful PRs from their authors (about 3-6 months)
   - generate notifications for all authors of all PRs with clarification
   of our goals
   - every month reminder in dev-list and via e-mail to each PR's author

The best way, of course, the closing by our hands in each module and area
with tags "obsolete" or something else.

P.S. I was in the same situation in Open Street Map community and the
principles for automated cleaning were the same like suggested by myself
above

I hope that we will be careful with our community

чт, 25 июл. 2019 г. в 13:23, Dmitriy Pavlov :

> Nikolay, committer could after setting up a link between GH & Apache
> accounts.
> https://gitbox.apache.org/setup/
>
> чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :
>
> > Yes.
> >
> > Do someone have permission to close my(or any other contributor) PR to
> > apache/ignite?
> >
> > В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > > NIkolay,
> > >
> > > Do you mean technical ability?
> > >
> > > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov :
> > > >
> > > > Hello, Ivan.
> > > >
> > > > Do we have the ability to close PRs from other contributors?
> > > >
> > > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > > Igniters,
> > > > >
> > > > >  I would like to resume a discussion about PRs cleanup.
> Additionally
> > > > > to concerns provided earlier some TC Bot operations are slowed down
> > > > > due to a huge amount of open PRs.
> > > > >
> > > > > As time has passed, I ask you all again to share an opinion about
> > > > > centralized cleanup of obsolete PRs. Also, a precise criteria to
> > > > > consider PR as obsolete is a subject for dicsussion as well.
> > > > >
> > > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  >
> > wrote:
> > > > > > >
> > > > > > > Hello, Ivan.
> > > > > > >
> > > > > > > Personally, I keep my PR's clear.
> > > > > > > So, I don't have dozens of opened PR.
> > > > > > >
> > > > > > > But, I don't support Dmitriy proposal for several reasons:
> > > > > > >
> > > > > > > 1. We introduce some new, not required, level of bureaucracy.
> > > > > > > From my experience - not required bureaucracy is a BAD thing.
> > > > > > >
> > > > > > > 2. We spread our work pattern to whole community.
> > > > > > > I believe there are many patterns of dealing with *YOUR OWN*
> PRs.
> > > > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > > > Whats wrong with it?
> > > > > > >
> > > > > > > 3. I dont' see any issues with many opened PRs.
> > > > > > > What problem we trying to solve?
> > > > > >
> > > > > > But I see.
> > > > > > Lots of opened PRs (and obsolete branches as well) consumes huge
> > amount of data and time when TC performs changes detect operations (every
> > minute, BTW).
> > > > > > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but
> > part of the project development workflow in area of cleaning up and
> keeping
> > everything fresh and actual.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > 4. Closing abanodned PRs doesn't force anybody to review the
> > rest.
> > > > > > > Instead of ordering something to one way or another, let's
> solve
> > real problem:
> > > > > > >
> > > > > > >   - help the community doing PR review.
> > > > > > >   - fixing failing tests.
> > > > > > >   - introducing new code inspections to make our code base
> > clear.
> > > > > > >   - making Ignite improvements
> > > > > > >
> > > > > > > 5. I don't see how our numbers differs from other Apache
> projects
> > > > > > >
> > > > > > > Apache Kafka - 533 PR opened.
> > > > > > > Apache Spark - 484 PR opened.
> > > > > > > Apache Flink - 430 PR opened.
> > > > > > >
> > > > > > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > > > > > Agree with Dmitriy.
> > > > > > > >
> > > > > > > > We use GitHub PRs in our workflow, therefore we should keep
> > them in order.
> > > > > > > >
> > > > > > > > We can close PRs that refer to closed tickets, this can be
> > done with a
> > > > > > > > simple script.
> > > > > > > >
> > > > > > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван <
> > vololo...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Nikolay,
> > > > > > > > >
> > > > > > > > > I must say that when I first saw 1K+ open PRs my first
> > thought was
> > > > > > > > > that something was wrong with a review process. In my mind
> > in not very
> > > > > > > > > big project open PR list can reflect very well the real
> work
> > in
> > > > > > > > > progress. For bigger projects things become more
> complicated.
> > > > > > > > >
> > > > > > > > > Dmitriy,
> > > > > > > > >
> > > > > > > > > Do you have some cleanup automation in mind? Immediately I
> 

Re: Partition map exchange metrics

[Nikita Amelchev]

Igniters,

All want to see the сacheOperationsBlockedDuration metric that will
show current blocking duration or 0 if there is no blocking right now.

Do we need the following metrics? It seems one of them will be superfluous.
1. The totalCacheOperationsBlockedDuration metric that will accumulate
all blocking durations that happen after node starts.
2. Blocking duration histogram. Based on the HistogramMetric class.
User will be able to configure bounds.

ср, 24 июл. 2019 г. в 18:26, Nikolay Izhikov :
>
> Guys.
>
> I think we should go with the 2 metrics
>
> * current PME duration (resets on finish)
>
> This metric required for alerting(or automatic actions) on 
> long PME.
>
> * PME duration histogram (value added to metrics on PME finish)
> This metric required for an:
> * Quick PME trend analysis
> * Quick PME history analysis
>
>
> В Ср, 24/07/2019 в 15:01 +0300, Ivan Rakov пишет:
> > Nikita and Maxim,
> >
> > > What if we just update current metric getCurrentPmeDuration behaviour
> > > to show durations only for blocking PMEs?
> > > Remain it as a long value and rename it to 
> > > getCacheOperationsBlockedDuration.
> > >
> > > No other changes will require.
> > >
> > > WDYT?
> >
> > I agree with these two metrics. I also think that current
> > getCurrentPmeDuration will become redundant.
> >
> > Anton,
> >
> > > It looks like we're trying to implement "extended debug" instead of
> > > "monitoring".
> > > It should not be interesting for real admin what phase of PME is in
> > > progress and so on.
> >
> > PME is mission critical cluster process. I agree that there's a fine
> > line between monitoring and debug here. However, it's not good to add
> > monitoring capabilities only for scenario when everything is alright.
> > If PME will really hang, *real admin* will be extremely interested how
> > to return cluster back to working state. Metrics about stages completion
> > time may really help here: e.g. if one specific node hasn't completed
> > stage X while rest of the cluster has, it can be a signal that this node
> > should be killed.
> >
> > Of course, it's possible to build monitoring system that extract this
> > information from logs, but:
> > - It's more resource intensive as it requires parsing logs for all the time
> > - It's less reliable as log messages may change
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 24.07.2019 14:57, Maxim Muzafarov wrote:
> > > Folks,
> > >
> > > +1 with Anton post.
> > >
> > > What if we just update current metric getCurrentPmeDuration behaviour
> > > to show durations only for blocking PMEs?
> > > Remain it as a long value and rename it to 
> > > getCacheOperationsBlockedDuration.
> > >
> > > No other changes will require.
> > >
> > > WDYT?
> > >
> > > On Wed, 24 Jul 2019 at 14:02, Nikita Amelchev  
> > > wrote:
> > > > Nikolay,
> > > >
> > > > The сacheOperationsBlockedDuration metric will show current blocking
> > > > duration or 0 if there is no blocking right now.
> > > >
> > > > The totalCacheOperationsBlockedDuration metric will accumulate all
> > > > blocking durations that happen after node starts.
> > > >
> > > > ср, 24 июл. 2019 г. в 13:35, Nikolay Izhikov :
> > > > > Nikita
> > > > >
> > > > > What is the difference between those two metrics?
> > > > >
> > > > > ср, 24 июля 2019 г., 12:45 Nikita Amelchev :
> > > > >
> > > > > > Igniters, thanks for comments.
> > > > > >
> > > > > >  From the discussion it can be seen that we need only two metrics 
> > > > > > for now:
> > > > > > - сacheOperationsBlockedDuration (long)
> > > > > > - totalCacheOperationsBlockedDuration (long)
> > > > > >
> > > > > > I will prepare PR at the nearest time.
> > > > > >
> > > > > > ср, 24 июл. 2019 г. в 09:11, Zhenya Stanilovsky 
> > > > > >  > > > > > > :
> > > > > > >
> > > > > > > +1 with Anton decisions.
> > > > > > >
> > > > > > >
> > > > > > > > Среда, 24 июля 2019, 8:44 +03:00 от Anton Vinogradov 
> > > > > > > > :
> > > > > > > >
> > > > > > > > Folks,
> > > > > > > >
> > > > > > > > It looks like we're trying to implement "extended debug" 
> > > > > > > > instead of
> > > > > > > > "monitoring".
> > > > > > > > It should not be interesting for real admin what phase of PME 
> > > > > > > > is in
> > > > > > > > progress and so on.
> > > > > > > > Interested metrics are
> > > > > > > > - total blocked time (will be used for real SLA counting)
> > > > > > > > - are we blocked right now (shows we have an SLA degradation 
> > > > > > > > right now)
> > > > > > > > Duration of the current blocking period can be easily presented 
> > > > > > > > using
> > > > > >
> > > > > > any
> > > > > > > > modern monitoring tool by regular checks.
> > > > > > > > Initial true will means "period start", precision will be a 
> > > > > > > > result of
> > > > > > > > checks frequency.
> > > > > > > > Anyway, I'm ok to have current metric presented with long, 
> > > > > > > > where long
> 

Re: Clean up of our PRs and IEPs before 2019

[Dmitriy Pavlov]

Nikolay, committer could after setting up a link between GH & Apache
accounts.
https://gitbox.apache.org/setup/

чт, 25 июл. 2019 г. в 11:17, Nikolay Izhikov :

> Yes.
>
> Do someone have permission to close my(or any other contributor) PR to
> apache/ignite?
>
> В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> > NIkolay,
> >
> > Do you mean technical ability?
> >
> > чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov :
> > >
> > > Hello, Ivan.
> > >
> > > Do we have the ability to close PRs from other contributors?
> > >
> > > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > > Igniters,
> > > >
> > > >  I would like to resume a discussion about PRs cleanup. Additionally
> > > > to concerns provided earlier some TC Bot operations are slowed down
> > > > due to a huge amount of open PRs.
> > > >
> > > > As time has passed, I ask you all again to share an opinion about
> > > > centralized cleanup of obsolete PRs. Also, a precise criteria to
> > > > consider PR as obsolete is a subject for dicsussion as well.
> > > >
> > > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > > > >
> > > > >
> > > > >
> > > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov 
> wrote:
> > > > > >
> > > > > > Hello, Ivan.
> > > > > >
> > > > > > Personally, I keep my PR's clear.
> > > > > > So, I don't have dozens of opened PR.
> > > > > >
> > > > > > But, I don't support Dmitriy proposal for several reasons:
> > > > > >
> > > > > > 1. We introduce some new, not required, level of bureaucracy.
> > > > > > From my experience - not required bureaucracy is a BAD thing.
> > > > > >
> > > > > > 2. We spread our work pattern to whole community.
> > > > > > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > > Whats wrong with it?
> > > > > >
> > > > > > 3. I dont' see any issues with many opened PRs.
> > > > > > What problem we trying to solve?
> > > > >
> > > > > But I see.
> > > > > Lots of opened PRs (and obsolete branches as well) consumes huge
> amount of data and time when TC performs changes detect operations (every
> minute, BTW).
> > > > > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but
> part of the project development workflow in area of cleaning up and keeping
> everything fresh and actual.
> > > > >
> > > > >
> > > > > >
> > > > > > 4. Closing abanodned PRs doesn't force anybody to review the
> rest.
> > > > > > Instead of ordering something to one way or another, let's solve
> real problem:
> > > > > >
> > > > > >   - help the community doing PR review.
> > > > > >   - fixing failing tests.
> > > > > >   - introducing new code inspections to make our code base
> clear.
> > > > > >   - making Ignite improvements
> > > > > >
> > > > > > 5. I don't see how our numbers differs from other Apache projects
> > > > > >
> > > > > > Apache Kafka - 533 PR opened.
> > > > > > Apache Spark - 484 PR opened.
> > > > > > Apache Flink - 430 PR opened.
> > > > > >
> > > > > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > > > > Agree with Dmitriy.
> > > > > > >
> > > > > > > We use GitHub PRs in our workflow, therefore we should keep
> them in order.
> > > > > > >
> > > > > > > We can close PRs that refer to closed tickets, this can be
> done with a
> > > > > > > simple script.
> > > > > > >
> > > > > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван <
> vololo...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Nikolay,
> > > > > > > >
> > > > > > > > I must say that when I first saw 1K+ open PRs my first
> thought was
> > > > > > > > that something was wrong with a review process. In my mind
> in not very
> > > > > > > > big project open PR list can reflect very well the real work
> in
> > > > > > > > progress. For bigger projects things become more complicated.
> > > > > > > >
> > > > > > > > Dmitriy,
> > > > > > > >
> > > > > > > > Do you have some cleanup automation in mind? Immediately I
> think that
> > > > > > > > it is fully safe to close all PRs that were not touched more
> than a
> > > > > > > > year.
> > > > > > > > пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov <
> dpav...@apache.org>:
> > > > > > > > >
> > > > > > > > > The main concern is related to chances that newcomer will
> have to obtain
> > > > > > > >
> > > > > > > > a
> > > > > > > > > review support from the community.
> > > > > > > > >
> > > > > > > > > Actually, a lot of people doing their best to provide a
> feedback to
> > > > > > > > > newcomers, and count of issues still in PA state goes down
> (84 is a
> > > > > > > > > relatively small count of issues in PA state). But 1428
> PRs may imply we
> > > > > > > > > don't review here, as we have tons of incomplete PRs.
> Actually, most of
> > > > > > > > > these PRs were merged (but not using
> ./apply-pull-request.sh script, but
> > > > > > > > > manually, without reference to PRs).
> > > > > > > > >
> > > > > > > > > Another benefit of revising this list, if there are any

Re: Clean up of our PRs and IEPs before 2019

[Dmitriy Pavlov]

Hi Ivan,

Thank you for bumping this topic.

I consider PRs for resolved or closed tickets are obsolete and I close it
from time to time.

TC Bot shows which PRs related to closed and resolved, so it is possible to
enter your GitHub ID at PRs page and see which PRs are not needed.

Also, committers could close PRs opened by other contributors.

Sincerely,
Dmitriy Pavlov

чт, 25 июл. 2019 г. в 09:12, Павлухин Иван :

> Igniters,
>
>  I would like to resume a discussion about PRs cleanup. Additionally
> to concerns provided earlier some TC Bot operations are slowed down
> due to a huge amount of open PRs.
>
> As time has passed, I ask you all again to share an opinion about
> centralized cleanup of obsolete PRs. Also, a precise criteria to
> consider PR as obsolete is a subject for dicsussion as well.
>
> чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> >
> >
> >
> > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  wrote:
> > >
> > > Hello, Ivan.
> > >
> > > Personally, I keep my PR's clear.
> > > So, I don't have dozens of opened PR.
> > >
> > > But, I don't support Dmitriy proposal for several reasons:
> > >
> > > 1. We introduce some new, not required, level of bureaucracy.
> > > From my experience - not required bureaucracy is a BAD thing.
> > >
> > > 2. We spread our work pattern to whole community.
> > > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > > Some of them can lead to dozens of opened PRs to master.
> > > Whats wrong with it?
> > >
> > > 3. I dont' see any issues with many opened PRs.
> > > What problem we trying to solve?
> >
> > But I see.
> > Lots of opened PRs (and obsolete branches as well) consumes huge amount
> of data and time when TC performs changes detect operations (every minute,
> BTW).
> > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but part of
> the project development workflow in area of cleaning up and keeping
> everything fresh and actual.
> >
> >
> > >
> > > 4. Closing abanodned PRs doesn't force anybody to review the rest.
> > > Instead of ordering something to one way or another, let's solve real
> problem:
> > >
> > >   - help the community doing PR review.
> > >   - fixing failing tests.
> > >   - introducing new code inspections to make our code base clear.
> > >   - making Ignite improvements
> > >
> > > 5. I don't see how our numbers differs from other Apache projects
> > >
> > > Apache Kafka - 533 PR opened.
> > > Apache Spark - 484 PR opened.
> > > Apache Flink - 430 PR opened.
> > >
> > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > >> Agree with Dmitriy.
> > >>
> > >> We use GitHub PRs in our workflow, therefore we should keep them in
> order.
> > >>
> > >> We can close PRs that refer to closed tickets, this can be done with a
> > >> simple script.
> > >>
> > >> On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван 
> wrote:
> > >>
> > >>> Nikolay,
> > >>>
> > >>> I must say that when I first saw 1K+ open PRs my first thought was
> > >>> that something was wrong with a review process. In my mind in not
> very
> > >>> big project open PR list can reflect very well the real work in
> > >>> progress. For bigger projects things become more complicated.
> > >>>
> > >>> Dmitriy,
> > >>>
> > >>> Do you have some cleanup automation in mind? Immediately I think that
> > >>> it is fully safe to close all PRs that were not touched more than a
> > >>> year.
> > >>> пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov :
> > 
> >  The main concern is related to chances that newcomer will have to
> obtain
> > >>>
> > >>> a
> >  review support from the community.
> > 
> >  Actually, a lot of people doing their best to provide a feedback to
> >  newcomers, and count of issues still in PA state goes down (84 is a
> >  relatively small count of issues in PA state). But 1428 PRs may
> imply we
> >  don't review here, as we have tons of incomplete PRs. Actually,
> most of
> >  these PRs were merged (but not using ./apply-pull-request.sh
> script, but
> >  manually, without reference to PRs).
> > 
> >  Another benefit of revising this list, if there are any changes
> which
> >  were not accomplished with a proper ticket with PA status, we will
> > >>>
> > >>> identify
> >  a number of additional contributions to be applied to the codebase.
> > 
> > 
> >  пн, 10 дек. 2018 г. в 19:53, Nikolay Izhikov :
> > 
> > > Hello, Dmitriy.
> > >
> > > What, exactly concerns newcomers?
> > > What is wrong with opened PR?
> > > How project will benefit from closed PR?
> > >
> > >> The same proposal is related to IEP statuses. If you were involved
> > >>>
> > >>> in an
> > > IEP, please validate its status
> > >
> > > +1. We should maintain IEP description up to date.
> > >
> > > пн, 10 дек. 2018 г., 19:15 Dmitriy Pavlov dpav...@apache.org:
> > >
> > >> Hi Igniters,
> > >>
> > >> Newcomers to Apache Ignite sometimes became 

Re: [DISCUSSION] Ignite 3.0 and to be removed list

[Alexey Zinoviev]

Thanks for the clarification, will try to vote

чт, 25 июл. 2019 г. в 04:11, Denis Magda :

> Alexey,
>
> I've changed format on the wiki so that every community member can cast +1
> and -1 vote explaining his/her stance. This should help us to filter out
> those integrations that everyone agrees to discontinue vs. those that are
> controversial. Please, *everyone interested* share your opinion by putting
> a name and +1/-1 in these tables:
>
>- Integrations for discontinuation:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
>- APIs for removal:
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
>
>
>
> 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
>
>
> Both spatial and full-text search indexes provide limit support and not
> integrated with Ignite's memory architecture. It's better for us to remove
> them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex
> Goncharuk) and rebuild from scratch in 3.1/3.2.
>
>
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
>
>
> Why don't we have them as separate Github projects that can be updated both
> by the community members and independent developers? I just don't want this
> to be a burden of the community to test and maintain it for every release.
>
> 3. Annotations based configuration of SQL - we should be careful with that,
> > I suppose it's useful feature
>
>
> Alex Goncharuk should propose a new API for 3.0 soon.
>
> 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
>
>
> I wouldn't do this because 3rd party MQs go with their own versions that
> start conflicting over the time. For instance, we already have several
> modules for Hibernate and Spring Data integrations. To fix that, we just
> need to store integrations in separate repos and do forks if a new
> conflicting version has to be supported but there is still significant
> usage of the old one.
>
> --
> Denis Magda
>
>
> On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev 
> wrote:
>
> > I have a few ideas, maybe somebody will support me
> > 1. Exclude Spatial Indexes from API for removal (I don't know internal
> > issues, but is I'd like this kind of index)
> > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation
> > because I've ready to try support them (or dive in this question) I think
> > no so many work to support them or move to the separate module like
> > BigDataTools Integrations
> > 3. Annotations based configuration of SQL - we should be careful with
> that,
> > I suppose it's useful feature
> > 4. Ignite Messaging should be combined together with Kafka/different MQ
> > integration into one module for messaging support
> >
> > What do you think guys?
> >
> > пн, 22 июл. 2019 г. в 22:51, Denis Magda :
> >
> > > Igniters,
> > >
> > > I did the first run through the wishlist and selected integrations and
> > APIs
> > > for discontinuation. My suggestion would be to use IEP-36
> > (Modularization)
> > > page for the final list that we'll send to the user list for feedback:
> > >
> > >- Integrations for discontinuation:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation
> > >- APIs for removal:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval
> > >
> > > Please check those lists and let us know if you have any arguments
> > against
> > > discontinuation/removal of X. Also, if you believe that something
> listed
> > in
> > > the wishlist should be added to the EIP then let's discuss that.
> > > Personally, I see the whishlist as a page with ideas while the IEP a
> > final
> > > plan for action.
> > >
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur <
> daradu...@gmail.com
> > >
> > > wrote:
> > >
> > > > I think all agreed items should be marked @Deprecated in the code
> > > > base, so we will be able to remove them transparently for the
> > > > end-users.
> > > >
> > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван 
> > > wrote:
> > > > >
> > > > > Alex,
> > > > >
> > > > > I already added a couple of items to wishlist [1].
> > > > >
> > > > > Yes, I agree that the process should be iterative. But I am
> confused
> > > > > on what stage we are in a current interation? I suppose that Denis
> is
> > > > > going to present a list of removal candidates which we as
> developers
> > > > > agreed on. And should not we have that list 

Re: Clean up of our PRs and IEPs before 2019

[Nikolay Izhikov]

Yes.

Do someone have permission to close my(or any other contributor) PR to 
apache/ignite?

В Чт, 25/07/2019 в 11:05 +0300, Павлухин Иван пишет:
> NIkolay,
> 
> Do you mean technical ability?
> 
> чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov :
> > 
> > Hello, Ivan.
> > 
> > Do we have the ability to close PRs from other contributors?
> > 
> > В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > > Igniters,
> > > 
> > >  I would like to resume a discussion about PRs cleanup. Additionally
> > > to concerns provided earlier some TC Bot operations are slowed down
> > > due to a huge amount of open PRs.
> > > 
> > > As time has passed, I ask you all again to share an opinion about
> > > centralized cleanup of obsolete PRs. Also, a precise criteria to
> > > consider PR as obsolete is a subject for dicsussion as well.
> > > 
> > > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > > > 
> > > > 
> > > > 
> > > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  wrote:
> > > > > 
> > > > > Hello, Ivan.
> > > > > 
> > > > > Personally, I keep my PR's clear.
> > > > > So, I don't have dozens of opened PR.
> > > > > 
> > > > > But, I don't support Dmitriy proposal for several reasons:
> > > > > 
> > > > > 1. We introduce some new, not required, level of bureaucracy.
> > > > > From my experience - not required bureaucracy is a BAD thing.
> > > > > 
> > > > > 2. We spread our work pattern to whole community.
> > > > > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > > > > Some of them can lead to dozens of opened PRs to master.
> > > > > Whats wrong with it?
> > > > > 
> > > > > 3. I dont' see any issues with many opened PRs.
> > > > > What problem we trying to solve?
> > > > 
> > > > But I see.
> > > > Lots of opened PRs (and obsolete branches as well) consumes huge amount 
> > > > of data and time when TC performs changes detect operations (every 
> > > > minute, BTW).
> > > > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but part 
> > > > of the project development workflow in area of cleaning up and keeping 
> > > > everything fresh and actual.
> > > > 
> > > > 
> > > > > 
> > > > > 4. Closing abanodned PRs doesn't force anybody to review the rest.
> > > > > Instead of ordering something to one way or another, let's solve real 
> > > > > problem:
> > > > > 
> > > > >   - help the community doing PR review.
> > > > >   - fixing failing tests.
> > > > >   - introducing new code inspections to make our code base clear.
> > > > >   - making Ignite improvements
> > > > > 
> > > > > 5. I don't see how our numbers differs from other Apache projects
> > > > > 
> > > > > Apache Kafka - 533 PR opened.
> > > > > Apache Spark - 484 PR opened.
> > > > > Apache Flink - 430 PR opened.
> > > > > 
> > > > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > > > Agree with Dmitriy.
> > > > > > 
> > > > > > We use GitHub PRs in our workflow, therefore we should keep them in 
> > > > > > order.
> > > > > > 
> > > > > > We can close PRs that refer to closed tickets, this can be done 
> > > > > > with a
> > > > > > simple script.
> > > > > > 
> > > > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван  
> > > > > > wrote:
> > > > > > 
> > > > > > > Nikolay,
> > > > > > > 
> > > > > > > I must say that when I first saw 1K+ open PRs my first thought was
> > > > > > > that something was wrong with a review process. In my mind in not 
> > > > > > > very
> > > > > > > big project open PR list can reflect very well the real work in
> > > > > > > progress. For bigger projects things become more complicated.
> > > > > > > 
> > > > > > > Dmitriy,
> > > > > > > 
> > > > > > > Do you have some cleanup automation in mind? Immediately I think 
> > > > > > > that
> > > > > > > it is fully safe to close all PRs that were not touched more than 
> > > > > > > a
> > > > > > > year.
> > > > > > > пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov :
> > > > > > > > 
> > > > > > > > The main concern is related to chances that newcomer will have 
> > > > > > > > to obtain
> > > > > > > 
> > > > > > > a
> > > > > > > > review support from the community.
> > > > > > > > 
> > > > > > > > Actually, a lot of people doing their best to provide a 
> > > > > > > > feedback to
> > > > > > > > newcomers, and count of issues still in PA state goes down (84 
> > > > > > > > is a
> > > > > > > > relatively small count of issues in PA state). But 1428 PRs may 
> > > > > > > > imply we
> > > > > > > > don't review here, as we have tons of incomplete PRs. Actually, 
> > > > > > > > most of
> > > > > > > > these PRs were merged (but not using ./apply-pull-request.sh 
> > > > > > > > script, but
> > > > > > > > manually, without reference to PRs).
> > > > > > > > 
> > > > > > > > Another benefit of revising this list, if there are any changes 
> > > > > > > > which
> > > > > > > > were not accomplished with a proper ticket with PA status, we 
> > > > > > > > will
> > > > > > > 
> > > > > > > identify
> > > > > > > > a number 

Re: Clean up of our PRs and IEPs before 2019

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

NIkolay,

Do you mean technical ability?

чт, 25 июл. 2019 г. в 10:33, Nikolay Izhikov :
>
> Hello, Ivan.
>
> Do we have the ability to close PRs from other contributors?
>
> В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> > Igniters,
> >
> >  I would like to resume a discussion about PRs cleanup. Additionally
> > to concerns provided earlier some TC Bot operations are slowed down
> > due to a huge amount of open PRs.
> >
> > As time has passed, I ask you all again to share an opinion about
> > centralized cleanup of obsolete PRs. Also, a precise criteria to
> > consider PR as obsolete is a subject for dicsussion as well.
> >
> > чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > >
> > >
> > >
> > > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  wrote:
> > > >
> > > > Hello, Ivan.
> > > >
> > > > Personally, I keep my PR's clear.
> > > > So, I don't have dozens of opened PR.
> > > >
> > > > But, I don't support Dmitriy proposal for several reasons:
> > > >
> > > > 1. We introduce some new, not required, level of bureaucracy.
> > > > From my experience - not required bureaucracy is a BAD thing.
> > > >
> > > > 2. We spread our work pattern to whole community.
> > > > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > > > Some of them can lead to dozens of opened PRs to master.
> > > > Whats wrong with it?
> > > >
> > > > 3. I dont' see any issues with many opened PRs.
> > > > What problem we trying to solve?
> > >
> > > But I see.
> > > Lots of opened PRs (and obsolete branches as well) consumes huge amount 
> > > of data and time when TC performs changes detect operations (every 
> > > minute, BTW).
> > > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but part of 
> > > the project development workflow in area of cleaning up and keeping 
> > > everything fresh and actual.
> > >
> > >
> > > >
> > > > 4. Closing abanodned PRs doesn't force anybody to review the rest.
> > > > Instead of ordering something to one way or another, let's solve real 
> > > > problem:
> > > >
> > > >   - help the community doing PR review.
> > > >   - fixing failing tests.
> > > >   - introducing new code inspections to make our code base clear.
> > > >   - making Ignite improvements
> > > >
> > > > 5. I don't see how our numbers differs from other Apache projects
> > > >
> > > > Apache Kafka - 533 PR opened.
> > > > Apache Spark - 484 PR opened.
> > > > Apache Flink - 430 PR opened.
> > > >
> > > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > > Agree with Dmitriy.
> > > > >
> > > > > We use GitHub PRs in our workflow, therefore we should keep them in 
> > > > > order.
> > > > >
> > > > > We can close PRs that refer to closed tickets, this can be done with a
> > > > > simple script.
> > > > >
> > > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван  
> > > > > wrote:
> > > > >
> > > > > > Nikolay,
> > > > > >
> > > > > > I must say that when I first saw 1K+ open PRs my first thought was
> > > > > > that something was wrong with a review process. In my mind in not 
> > > > > > very
> > > > > > big project open PR list can reflect very well the real work in
> > > > > > progress. For bigger projects things become more complicated.
> > > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > Do you have some cleanup automation in mind? Immediately I think 
> > > > > > that
> > > > > > it is fully safe to close all PRs that were not touched more than a
> > > > > > year.
> > > > > > пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov :
> > > > > > >
> > > > > > > The main concern is related to chances that newcomer will have to 
> > > > > > > obtain
> > > > > >
> > > > > > a
> > > > > > > review support from the community.
> > > > > > >
> > > > > > > Actually, a lot of people doing their best to provide a feedback 
> > > > > > > to
> > > > > > > newcomers, and count of issues still in PA state goes down (84 is 
> > > > > > > a
> > > > > > > relatively small count of issues in PA state). But 1428 PRs may 
> > > > > > > imply we
> > > > > > > don't review here, as we have tons of incomplete PRs. Actually, 
> > > > > > > most of
> > > > > > > these PRs were merged (but not using ./apply-pull-request.sh 
> > > > > > > script, but
> > > > > > > manually, without reference to PRs).
> > > > > > >
> > > > > > > Another benefit of revising this list, if there are any changes 
> > > > > > > which
> > > > > > > were not accomplished with a proper ticket with PA status, we will
> > > > > >
> > > > > > identify
> > > > > > > a number of additional contributions to be applied to the 
> > > > > > > codebase.
> > > > > > >
> > > > > > >
> > > > > > > пн, 10 дек. 2018 г. в 19:53, Nikolay Izhikov 
> > > > > > > :
> > > > > > >
> > > > > > > > Hello, Dmitriy.
> > > > > > > >
> > > > > > > > What, exactly concerns newcomers?
> > > > > > > > What is wrong with opened PR?
> > > > > > > > How project will benefit from closed PR?
> > > > > > > >
> > > > > > > > > The same proposal is related to IEP 

Re: Threadpools and .WithExecute() for C# clients

[Pavel Tupitsyn]

Denis, I've just created one:
https://issues.apache.org/jira/browse/IGNITE-12012

Thanks

On Thu, Jul 25, 2019 at 2:25 AM Denis Magda  wrote:

> Pavel,
>
> Do we already have a ticket or do you want me to create one?
>
> -
> Denis
>
>
> On Wed, Jul 24, 2019 at 1:21 AM Pavel Tupitsyn 
> wrote:
>
> > Denis, yes, looks like a simple thing to add.
> >
> > On Tue, Jul 23, 2019 at 10:38 PM Denis Magda  wrote:
> >
> >> Looping in the dev list.
> >>
> >> Pavel, Igor and other C# maintainers, this looks like a valuable
> extension
> >> of our C# APIs. Shouldn't this be a quick addition to Ignite?
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Mon, Jul 22, 2019 at 3:22 PM Raymond Wilson <
> >> raymond_wil...@trimble.com>
> >> wrote:
> >>
> >> > Alexandr,
> >> >
> >> > If .WithExecute is not planned to be made available in the C# client,
> >> what
> >> > is the plan to support custom thread pools from the C# side of things?
> >> >
> >> > Thanks,
> >> > Raymond.
> >> >
> >> >
> >> > On Thu, Jul 18, 2019 at 9:28 AM Raymond Wilson <
> >> raymond_wil...@trimble.com>
> >> > wrote:
> >> >
> >> >> The source of inbound requests into Server A is from client
> >> applications.
> >> >>
> >> >> Server B is really a cluster of servers that are performing clustered
> >> >> transformations and computations across a data set.
> >> >>
> >> >> I originally used IComputeJob and similar functions which work very
> >> well
> >> >> but have the restriction that they return the entire result set from
> a
> >> >> Server B node in a single response. These result sets can be large
> >> (100's
> >> >> of megabytes and larger), which makes life pretty hard for Server A
> if
> >> it
> >> >> has to field multiple incoming responses of this size. So, these
> types
> >> of
> >> >> requests progressively send responses back (using Ignite messaging)
> to
> >> >> Server A using the Ignite messaging fabric. As Server A receives each
> >> part
> >> >> of the overall response it processes it according the business rules
> >> >> relevant to the request.
> >> >>
> >> >> The cluster config and numbers of nodes are not really material to
> >> this.
> >> >>
> >> >> Raymond.
> >> >>
> >> >> On Thu, Jul 18, 2019 at 12:26 AM Alexandr Shapkin  >
> >> >> wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>>
> >> >>>
> >> >>> Can you share a more detailed use case, please?
> >> >>>
> >> >>>
> >> >>>
> >> >>> Right now it’s not clear why do you need a messaging fabric.
> >> >>>
> >> >>> If you are interesting in a progress tracking, then you could try a
> >> >>> CacheAPI or QueryContinious, for example.
> >> >>>
> >> >>>
> >> >>>
> >> >>> What are the sources of inbound requests? Is it a client requests?
> >> >>>
> >> >>>
> >> >>>
> >> >>> What is your cluster config? How many nodes do you have for your
> >> >>> distributed computations?
> >> >>>
> >> >>>
> >> >>>
> >> >>> *From: *Raymond Wilson 
> >> >>> *Sent: *Wednesday, July 17, 2019 1:49 PM
> >> >>> *To: *user 
> >> >>> *Subject: *Re: Threadpools and .WithExecute() for C# clients
> >> >>>
> >> >>>
> >> >>>
> >> >>> Hi Alexandr,
> >> >>>
> >> >>>
> >> >>>
> >> >>> To summarise from the original thread, say I have server A that
> >> accepts
> >> >>> requests. It contacts server B in order to help processing those
> >> requests.
> >> >>> Server B sends in-progress results to server A using the Ignite
> >> messaging
> >> >>> fabric. If the thread pool in server A is saturated with inbound
> >> requests,
> >> >>> then there are no available threads to service the messaging fabric
> >> traffic
> >> >>> from server B to server A resulting in a deadlock condition.
> >> >>>
> >> >>>
> >> >>>
> >> >>> In the original discussion it was suggested creating a custom thread
> >> >>> pool to handle the Server B to Server A traffic would resolve it.
> >> >>>
> >> >>>
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Raymond.
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Wed, Jul 17, 2019 at 9:48 PM Alexandr Shapkin  >
> >> >>> wrote:
> >> >>>
> >> >>> Hi, Raymond!
> >> >>>
> >> >>>
> >> >>>
> >> >>> As far as I can see, there are no plans for porting custom executors
> >> >>> configuration in .NET client right now [1].
> >> >>>
> >> >>>
> >> >>>
> >> >>> Please, remind, why do you need a separate pool instead of a default
> >> >>> PublicPool?
> >> >>>
> >> >>>
> >> >>>
> >> >>> [1] - https://issues.apache.org/jira/browse/IGNITE-6566
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> *From: *Raymond Wilson 
> >> >>> *Sent: *Wednesday, July 17, 2019 10:58 AM
> >> >>> *To: *user 
> >> >>> *Subject: *Threadpools and .WithExecute() for C# clients
> >> >>>
> >> >>>
> >> >>>
> >> >>> Some time ago I ran into and issue with thread pool exhaustion and
> >> >>> deadlocking in AI 2.2.
> >> >>>
> >> >>>
> >> >>>
> >> >>> This is the original thread:
> >> >>>
> >>
> http://apache-ignite-users.70518.x6.nabble.com/Possible-dead-lock-when-number-of-jobs-exceeds-thread-pool-td17262.html
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> At the time 

[jira] [Created] (IGNITE-12012) .NET: ICompute.WithExecutor

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-12012:
---

 Summary: .NET: ICompute.WithExecutor
 Key: IGNITE-12012
 URL: https://issues.apache.org/jira/browse/IGNITE-12012
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn


Propagate the following APIs to .NET:
* IgniteCompute.withExecutor
* IgniteConfiguration.ExecutorConfiguration



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Clean up of our PRs and IEPs before 2019

[Nikolay Izhikov]

Hello, Ivan.

Do we have the ability to close PRs from other contributors? 

В Чт, 25/07/2019 в 09:12 +0300, Павлухин Иван пишет:
> Igniters,
> 
>  I would like to resume a discussion about PRs cleanup. Additionally
> to concerns provided earlier some TC Bot operations are slowed down
> due to a huge amount of open PRs.
> 
> As time has passed, I ask you all again to share an opinion about
> centralized cleanup of obsolete PRs. Also, a precise criteria to
> consider PR as obsolete is a subject for dicsussion as well.
> 
> чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
> > 
> > 
> > 
> > > On 11 Dec 2018, at 10:10, Nikolay Izhikov  wrote:
> > > 
> > > Hello, Ivan.
> > > 
> > > Personally, I keep my PR's clear.
> > > So, I don't have dozens of opened PR.
> > > 
> > > But, I don't support Dmitriy proposal for several reasons:
> > > 
> > > 1. We introduce some new, not required, level of bureaucracy.
> > > From my experience - not required bureaucracy is a BAD thing.
> > > 
> > > 2. We spread our work pattern to whole community.
> > > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > > Some of them can lead to dozens of opened PRs to master.
> > > Whats wrong with it?
> > > 
> > > 3. I dont' see any issues with many opened PRs.
> > > What problem we trying to solve?
> > 
> > But I see.
> > Lots of opened PRs (and obsolete branches as well) consumes huge amount of 
> > data and time when TC performs changes detect operations (every minute, 
> > BTW).
> > Also, IMO, ORDER is not an unnecessary level of bureaucracy, but part of 
> > the project development workflow in area of cleaning up and keeping 
> > everything fresh and actual.
> > 
> > 
> > > 
> > > 4. Closing abanodned PRs doesn't force anybody to review the rest.
> > > Instead of ordering something to one way or another, let's solve real 
> > > problem:
> > > 
> > >   - help the community doing PR review.
> > >   - fixing failing tests.
> > >   - introducing new code inspections to make our code base clear.
> > >   - making Ignite improvements
> > > 
> > > 5. I don't see how our numbers differs from other Apache projects
> > > 
> > > Apache Kafka - 533 PR opened.
> > > Apache Spark - 484 PR opened.
> > > Apache Flink - 430 PR opened.
> > > 
> > > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> > > > Agree with Dmitriy.
> > > > 
> > > > We use GitHub PRs in our workflow, therefore we should keep them in 
> > > > order.
> > > > 
> > > > We can close PRs that refer to closed tickets, this can be done with a
> > > > simple script.
> > > > 
> > > > On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван  
> > > > wrote:
> > > > 
> > > > > Nikolay,
> > > > > 
> > > > > I must say that when I first saw 1K+ open PRs my first thought was
> > > > > that something was wrong with a review process. In my mind in not very
> > > > > big project open PR list can reflect very well the real work in
> > > > > progress. For bigger projects things become more complicated.
> > > > > 
> > > > > Dmitriy,
> > > > > 
> > > > > Do you have some cleanup automation in mind? Immediately I think that
> > > > > it is fully safe to close all PRs that were not touched more than a
> > > > > year.
> > > > > пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov :
> > > > > > 
> > > > > > The main concern is related to chances that newcomer will have to 
> > > > > > obtain
> > > > > 
> > > > > a
> > > > > > review support from the community.
> > > > > > 
> > > > > > Actually, a lot of people doing their best to provide a feedback to
> > > > > > newcomers, and count of issues still in PA state goes down (84 is a
> > > > > > relatively small count of issues in PA state). But 1428 PRs may 
> > > > > > imply we
> > > > > > don't review here, as we have tons of incomplete PRs. Actually, 
> > > > > > most of
> > > > > > these PRs were merged (but not using ./apply-pull-request.sh 
> > > > > > script, but
> > > > > > manually, without reference to PRs).
> > > > > > 
> > > > > > Another benefit of revising this list, if there are any changes 
> > > > > > which
> > > > > > were not accomplished with a proper ticket with PA status, we will
> > > > > 
> > > > > identify
> > > > > > a number of additional contributions to be applied to the codebase.
> > > > > > 
> > > > > > 
> > > > > > пн, 10 дек. 2018 г. в 19:53, Nikolay Izhikov :
> > > > > > 
> > > > > > > Hello, Dmitriy.
> > > > > > > 
> > > > > > > What, exactly concerns newcomers?
> > > > > > > What is wrong with opened PR?
> > > > > > > How project will benefit from closed PR?
> > > > > > > 
> > > > > > > > The same proposal is related to IEP statuses. If you were 
> > > > > > > > involved
> > > > > 
> > > > > in an
> > > > > > > IEP, please validate its status
> > > > > > > 
> > > > > > > +1. We should maintain IEP description up to date.
> > > > > > > 
> > > > > > > пн, 10 дек. 2018 г., 19:15 Dmitriy Pavlov dpav...@apache.org:
> > > > > > > 
> > > > > > > > Hi Igniters,
> > > > > > > > 
> > > > > > > > Newcomers to Apache 

Re: Test naming on TC JUnit 5

[Dmitriy Pavlov]

Hi Ivan.

Yes, test name changes (reported by TC), would be a short term issue, but
TC bot will accumulate statistics quite fast.

We can consider applying changes before a weekend, so the maximum number of
re-runs occur; so the maximum statistic is the outcome.

Moreover, the test name change may have a positive effect in long-term,
because of a re-run of a particular suite on TC has exactly the same impact
on test name. It will be a path to test case wihtout suite.
So for now, Re-run possible blockers activate the whole suite, but when all
tests change their names, TC bot could activate only some test case(s) with
a test(s) failure to rerun. It could also bring faster detection of master
failures.

Sincerely,
Dmitriy Pavlov

пн, 22 июл. 2019 г. в 20:10, Ivan Fedotov :

> Hi, igniters!
>
> In the context of IEP-30 and IGNITE-10958 in particular [1], the JUnit5
> tests are going to appear in master.
>
> During migration Ignite on JUnit5 I faced that the test naming will be
> changed.
> The names are different, in the version before path consists from "path to
> suite: path to test" [2] and in the version after just "path to test" [3].
> I want to inform you that it will lead to obsolete current history for some
> tests: see tests with label "History for base branch is absent" [4]. It
> means that TC bot shows those tests as blockers because of a different
> name, but indeed tests were red on JUnit 4 version also. After some time in
> the new version of JUnit we will get a history for mentioned tests again.
>
> Do have some of us have questions/comments according to migration?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-10973
> [2]
>
> https://ci.ignite.apache.org/project.html?tab=testDetails_IgniteTests24Java8=%3Cdefault%3E=IgniteTests24Java8=680055112352967935=1
> [3]
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8375541702052870683=%3Cdefault%3E=testDetails_IgniteTests24Java8=__all_branches__
> [4]
>
> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6606/head=Latest
> --
> Ivan Fedotov.
>
> ivanan...@gmail.com
>

Re: Clean up of our PRs and IEPs before 2019

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

Igniters,

 I would like to resume a discussion about PRs cleanup. Additionally
to concerns provided earlier some TC Bot operations are slowed down
due to a huge amount of open PRs.

As time has passed, I ask you all again to share an opinion about
centralized cleanup of obsolete PRs. Also, a precise criteria to
consider PR as obsolete is a subject for dicsussion as well.

чт, 13 дек. 2018 г. в 11:55, Petr Ivanov :
>
>
>
> > On 11 Dec 2018, at 10:10, Nikolay Izhikov  wrote:
> >
> > Hello, Ivan.
> >
> > Personally, I keep my PR's clear.
> > So, I don't have dozens of opened PR.
> >
> > But, I don't support Dmitriy proposal for several reasons:
> >
> > 1. We introduce some new, not required, level of bureaucracy.
> > From my experience - not required bureaucracy is a BAD thing.
> >
> > 2. We spread our work pattern to whole community.
> > I believe there are many patterns of dealing with *YOUR OWN* PRs.
> > Some of them can lead to dozens of opened PRs to master.
> > Whats wrong with it?
> >
> > 3. I dont' see any issues with many opened PRs.
> > What problem we trying to solve?
>
> But I see.
> Lots of opened PRs (and obsolete branches as well) consumes huge amount of 
> data and time when TC performs changes detect operations (every minute, BTW).
> Also, IMO, ORDER is not an unnecessary level of bureaucracy, but part of the 
> project development workflow in area of cleaning up and keeping everything 
> fresh and actual.
>
>
> >
> > 4. Closing abanodned PRs doesn't force anybody to review the rest.
> > Instead of ordering something to one way or another, let's solve real 
> > problem:
> >
> >   - help the community doing PR review.
> >   - fixing failing tests.
> >   - introducing new code inspections to make our code base clear.
> >   - making Ignite improvements
> >
> > 5. I don't see how our numbers differs from other Apache projects
> >
> > Apache Kafka - 533 PR opened.
> > Apache Spark - 484 PR opened.
> > Apache Flink - 430 PR opened.
> >
> > В Вт, 11/12/2018 в 09:24 +0300, Pavel Tupitsyn пишет:
> >> Agree with Dmitriy.
> >>
> >> We use GitHub PRs in our workflow, therefore we should keep them in order.
> >>
> >> We can close PRs that refer to closed tickets, this can be done with a
> >> simple script.
> >>
> >> On Tue, Dec 11, 2018 at 9:15 AM Павлухин Иван  wrote:
> >>
> >>> Nikolay,
> >>>
> >>> I must say that when I first saw 1K+ open PRs my first thought was
> >>> that something was wrong with a review process. In my mind in not very
> >>> big project open PR list can reflect very well the real work in
> >>> progress. For bigger projects things become more complicated.
> >>>
> >>> Dmitriy,
> >>>
> >>> Do you have some cleanup automation in mind? Immediately I think that
> >>> it is fully safe to close all PRs that were not touched more than a
> >>> year.
> >>> пн, 10 дек. 2018 г. в 20:01, Dmitriy Pavlov :
> 
>  The main concern is related to chances that newcomer will have to obtain
> >>>
> >>> a
>  review support from the community.
> 
>  Actually, a lot of people doing their best to provide a feedback to
>  newcomers, and count of issues still in PA state goes down (84 is a
>  relatively small count of issues in PA state). But 1428 PRs may imply we
>  don't review here, as we have tons of incomplete PRs. Actually, most of
>  these PRs were merged (but not using ./apply-pull-request.sh script, but
>  manually, without reference to PRs).
> 
>  Another benefit of revising this list, if there are any changes which
>  were not accomplished with a proper ticket with PA status, we will
> >>>
> >>> identify
>  a number of additional contributions to be applied to the codebase.
> 
> 
>  пн, 10 дек. 2018 г. в 19:53, Nikolay Izhikov :
> 
> > Hello, Dmitriy.
> >
> > What, exactly concerns newcomers?
> > What is wrong with opened PR?
> > How project will benefit from closed PR?
> >
> >> The same proposal is related to IEP statuses. If you were involved
> >>>
> >>> in an
> > IEP, please validate its status
> >
> > +1. We should maintain IEP description up to date.
> >
> > пн, 10 дек. 2018 г., 19:15 Dmitriy Pavlov dpav...@apache.org:
> >
> >> Hi Igniters,
> >>
> >> Newcomers to Apache Ignite sometimes became concerned about many
> >>>
> >>> open PRs
> >> in the project. Apache Ignite TC Bot also performs runs checks with
> >>>
> >>> a PR
> >> open. Apache Ignite pulls list
> >>>
> >>> https://github.com/apache/ignite/pulls
> >> contains
> >> 1442 PRs open while only 84 issues are waiting for review.
> >>
> >> Could you please verify the list of your PRs in Apache Ignite
> >> https://github.com/pulls  and close every not needed/already merged
> >> change?
> >>
> >> The same proposal is related to IEP statuses. If you were involved
> >>>
> >>> in an
> >> IEP, please validate its status here
> >>