[MTCGA]: new failures in builds [2327011] needs to be handled
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 test failure in master IgniteCacheLockPartitionOnAffinityRunTest.testSingleCache https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=475277171234191079=%3Cdefault%3E=testDetails Changes may lead to failure were done by - isapego https://ci.ignite.apache.org//viewModification.html?modId=265274 - alexey.goncharuk https://ci.ignite.apache.org//viewModification.html?modId=265721 - isapego https://ci.ignite.apache.org//viewModification.html?modId=265179 - dmitriy.govorukhin https://ci.ignite.apache.org//viewModification.html?modId=26 - spiderru5597 https://ci.ignite.apache.org//viewModification.html?modId=264337 - irakov https://ci.ignite.apache.org//viewModification.html?modId=265720 - spiderru5597 https://ci.ignite.apache.org//viewModification.html?modId=265040 - ppozerov https://ci.ignite.apache.org//viewModification.html?modId=265966 - 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 06:20:27 16-11-2018
Re: proposed design for thin client SQL management and monitoring (view running queries and kill it)
Vladimir, Thanks, make perfect sense to me. On Thu, Nov 15, 2018 at 12:18 AM Vladimir Ozerov wrote: > Denis, > > The idea is that QueryDetailMetrics will be exposed through separate > "historical" SQL view in addition to current API. So we are on the same > page here. > > As far as query ID I do not see any easy way to operate on a single integer > value (even 64bit). This is distributed system - we do not want to have > coordination between nodes to get query ID. And coordination is the only > possible way to get sexy "long". Instead, I would propose to form ID from > node order and query counter within node. This will be (int, long) pair. > For use convenience we may convert it to a single string, e.g. > "[node_order].[query_counter]". Then the syntax would be: > > KILL QUERY '25.1234'; // Kill query 1234 on node 25 > KILL QUERY '25.*; // Kill all queries on the node 25 > > Makes sense? > > Vladimir. > > On Wed, Nov 14, 2018 at 1:25 PM Denis Magda wrote: > > > Yury, > > > > As I understand you mean that the view should contains both running and > > > finished queries. If be honest for the view I was going to use just > > queries > > > running right now. For finished queries I thought about another view > with > > > another set of fields which should include I/O related ones. Is it > works? > > > > > > Got you, so if only running queries are there then your initial proposal > > makes total sense. Not sure we need a view of the finished queries. It > will > > be possible to analyze them through the updated DetailedMetrics approach, > > won't it? > > > > For "KILL QUERY node_id query_id" node_id required as part of unique key > > > of query and help understand Ignite which node start the distributed > > query. > > > Use both parameters will allow cheap generate unique key across all > > nodes. > > > Node which started a query can cancel it on all nodes participate > nodes. > > > So, to stop any queries initially we need just send the cancel request > to > > > node who started the query. This mechanism is already in Ignite. > > > > > > Can we locate node_id behind the scenes if the user supplies query_id > only? > > A query record in the view already contains query_id and node_id and it > > sounds like an extra work for the user to fill in all the details for us. > > Embed node_id into query_id if you'd like to avoid extra network hops for > > query_id to node_id mapping. > > > > -- > > Denis > > > > On Wed, Nov 14, 2018 at 1:04 AM Юрий > wrote: > > > > > Denis, > > > > > > Under the hood 'time' will be as startTime, but for system view I > planned > > > use duration which will be simple calculated as now - startTime. So, > > there > > > is't a performance issue. > > > As I understand you mean that the view should contains both running and > > > finished queries. If be honest for the view I was going to use just > > queries > > > running right now. For finished queries I thought about another view > with > > > another set of fields which should include I/O related ones. Is it > works? > > > > > > For "KILL QUERY node_id query_id" node_id required as part of unique > key > > > of query and help understand Ignite which node start the distributed > > query. > > > Use both parameters will allow cheap generate unique key across all > > nodes. > > > Node which started a query can cancel it on all nodes participate > nodes. > > > So, to stop any queries initially we need just send the cancel request > to > > > node who started the query. This mechanism is already in Ignite. > > > > > > Native SQL APIs will automatically support the futures after > implementing > > > for thin clients. So we are good here. > > > > > > > > > > > > вт, 13 нояб. 2018 г. в 18:52, Denis Magda : > > > > > > > Yury, > > > > > > > > Please consider the following: > > > > > > > >- If we record the duration instead of startTime, then the former > > has > > > to > > > >be updated frequently - sounds like a performance red flag. Should > > we > > > > store > > > >startTime and endTime instead? This way a query record will be > > updated > > > >twice - when the query is started and terminated. > > > >- In the IEP you've mentioned I/O related fields that should help > to > > > >grasp why a query runs that slow. Should they be stored in this > > view? > > > >- "KILL QUERY query_id" is more than enough. Let's not add > "node_id" > > > >unless it's absolutely required. Our queries are distributed and > > > > executed > > > >across several nodes that's why the node_id parameter is > redundant. > > > >- This API needs to be supported across all our interfaces. We can > > > start > > > >with JDBC/ODBC and thin clients and then support for the native > SQL > > > APIs > > > >(Java, Net, C++) > > > >- Please share examples of SELECTs in the IEP that would show how > to > > > >find long running queries, queries that cause a lot of I/O > troubles. > > > > > > > > -- > > > > Denis > > > > >
[GitHub] ignite pull request #5405: IGNITE-10290 Fix missed prepareForCache in localG...
GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/5405 IGNITE-10290 Fix missed prepareForCache in localGet operation Signed-off-by: Dmitriy Govorukhin You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10290 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5405.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5405 commit 71308b18d891e707c801959f5fe92460b3bde69b Author: Dmitriy Govorukhin Date: 2018-11-15T23:15:18Z IGNITE-10290 Fix missed prepareForCache in localGet operation Signed-off-by: Dmitriy Govorukhin ---
[jira] [Created] (IGNITE-10290) Map.Entry interface for key cache may lead to incorrect calculation hash code
Dmitriy Govorukhin created IGNITE-10290: --- Summary: Map.Entry interface for key cache may lead to incorrect calculation hash code Key: IGNITE-10290 URL: https://issues.apache.org/jira/browse/IGNITE-10290 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin Attachments: Reproducer.java In case if use Map.Entry interface for a key, we can try to find (key, value) in store with incorrect calculated hash code for binary representation. The problem is in the GridPartitionedSingleGetFuture#localGet() and GridPartitionedGetFuture#localGet() does not execute prepareForCache before reading cacheDataRow from row store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10289) [ML] Import models from XGBoost
Yury Babak created IGNITE-10289: --- Summary: [ML] Import models from XGBoost Key: IGNITE-10289 URL: https://issues.apache.org/jira/browse/IGNITE-10289 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak Assignee: Anton Dmitriev We want to have the ability of import model from 3rd part ml libraries into Apache Ignite. We could start this process from XGBoost library for trees and GDB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5404: IGNITE-10285 Implement job stealing for U.doInPar...
GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/5404 IGNITE-10285 Implement job stealing for U.doInParallel You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10285 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5404.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5404 commit 37d1310d24996966c60d673754033051f02abccb Author: Dmitriy Govorukhin Date: 2018-11-15T22:37:40Z IGNITE-10285 Implement job stealing for U.doInParallel in case if executor busy and cannot perform task immediately Signed-off-by: Dmitriy Govorukhin ---
[jira] [Created] (IGNITE-10288) [ML] Model inference
Yury Babak created IGNITE-10288: --- Summary: [ML] Model inference Key: IGNITE-10288 URL: https://issues.apache.org/jira/browse/IGNITE-10288 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak We need a convenient API for model inference. The current idea is to utilize Service Grid for this purpose. We should have two options, first is deliver a model to any node(server or client) and infer this model on that node. The second approach is to pin a model to a specific server and infer model on that server, it could be useful in case if we need some specific hardware which we don't have at any server like a GPU or TPU. So the first approach is suitable for lightweight models and the second approach is suitable for some complex models like Neural Networks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10287) [ML] Model storage
Yury Babak created IGNITE-10287: --- Summary: [ML] Model storage Key: IGNITE-10287 URL: https://issues.apache.org/jira/browse/IGNITE-10287 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak We want to have some storage for any kind of models in Apache Ignite. It should allow storing a model from any node after training and evaluation(MB with some meta info and model metrics) and provide API to get this model to any node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10285) U.doInParallel may lead to deadlock
Dmitriy Govorukhin created IGNITE-10285: --- Summary: U.doInParallel may lead to deadlock Key: IGNITE-10285 URL: https://issues.apache.org/jira/browse/IGNITE-10285 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin Attachments: dump.rtf There are exist case when we can get a deadlock on the thread pool. If we try doInParallel in the thread of sys-pool in the number of hreads==sys-pool.size we lead to deadlock because threads in sys-pool will try doInParallel through the same sys-pool, and they will wait on future infinitely because no one thread cannot complete operation doInParallel which require threads from sys-pool. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10286) [ML] Umbrella: Model serving
Yury Babak created IGNITE-10286: --- Summary: [ML] Umbrella: Model serving Key: IGNITE-10286 URL: https://issues.apache.org/jira/browse/IGNITE-10286 Project: Ignite Issue Type: New Feature Components: ml Reporter: Yury Babak Assignee: Yury Babak We want to have convenient API for model serving. It means that we need a mechanism for storing models and infer them inside Apache Ignite. For now, I see 2 important features - distributed storage for any models and inference. >From my point of view, we could use some built-in(predefined) cache as model >storage. And use service grid for model inference. We could implement some >"ModelService" for access to our storage, receive the list of all suitable >model(including model metrics and some other information about a model), >choose one(or several) and infer it from this service. Model from TF should also use the same mechanisms for storing and inference. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [2323069] needs to be handled
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 test failure in master IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6915392932418459317=%3Cdefault%3E=testDetails *New test failure in master IgniteCacheReplicatedQueryP2PDisabledSelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-393492269618641229=%3Cdefault%3E=testDetails *New test failure in master IgniteCacheReplicatedQuerySelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2363137591361112031=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ygerzhedovich https://ci.ignite.apache.org//viewModification.html?modId=263959 - vozerov https://ci.ignite.apache.org//viewModification.html?modId=263853 - vozerov https://ci.ignite.apache.org//viewModification.html?modId=263956 - 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 00:35:13 16-11-2018
[MTCGA]: new failures in builds [2323068] needs to be handled
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 test failure in master IgniteCacheReplicatedQueryP2PDisabledSelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1328782023632161768=%3Cdefault%3E=testDetails *New test failure in master IgniteCacheReplicatedQuerySelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8379349225494042650=%3Cdefault%3E=testDetails *New test failure in master IgniteCacheReplicatedQueryEvtsDisabledSelfTest.testSqlQueryEvents https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8210650449325388796=%3Cdefault%3E=testDetails Changes may lead to failure were done by - ygerzhedovich https://ci.ignite.apache.org//viewModification.html?modId=263959 - vozerov https://ci.ignite.apache.org//viewModification.html?modId=263853 - vozerov https://ci.ignite.apache.org//viewModification.html?modId=263956 - 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 00:21:14 16-11-2018
[GitHub] ololo3000 closed pull request #71: IGNITE-9939 BuildObserver refactor. Visas request cancellation added
ololo3000 closed pull request #71: IGNITE-9939 BuildObserver refactor. Visas
request cancellation added
URL: https://github.com/apache/ignite-teamcity-bot/pull/71
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
index 44facf29..cea883b6 100644
--- a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
+++ b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/TcHelper.java
@@ -164,8 +164,12 @@ private BranchesTracked getTrackedBranches() {
String comment = generateJiraComment(suitesStatuses, build.webUrl);
-blockers = suitesStatuses.stream().mapToInt(suite ->
-suite.testFailures.size()).sum();
+blockers = suitesStatuses.stream().mapToInt(suite -> {
+if (suite.testFailures.isEmpty())
+return 1;
+
+return suite.testFailures.size();})
+.sum();
res = objectMapper.readValue(teamcity.sendJiraComment(ticket,
comment), JiraCommentResponse.class);
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
index cf294684..954173fb 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
@@ -17,7 +17,6 @@
package org.apache.ignite.ci.observer;
-import java.util.Collection;
import java.util.Objects;
import java.util.Timer;
import javax.inject.Inject;
@@ -60,6 +59,11 @@ public void stop() {
timer.cancel();
}
+/** */
+public void stopObservation(String srv, String branchForTc) {
+observerTask.removeBuildInfo(srv, branchForTc);
+}
+
/**
* @param srvId Server id.
* @param prov Credentials.
@@ -81,16 +85,13 @@ public void observe(String srvId, ICredentialsProv prov,
String ticket, String b
public String getObservationStatus(String srvId, String branch) {
StringBuilder sb = new StringBuilder();
-Collection builds = observerTask.getInfos();
+BuildsInfo bi = observerTask.getInfo(srvId, branch);
-for (BuildsInfo bi : builds) {
-if (Objects.equals(bi.branchForTc, branch)
-&& Objects.equals(bi.srvId, srvId)) {
-sb.append(bi.ticket).append(" to be commented, waiting for
builds. ");
-sb.append(bi.finishedBuildsCount());
-sb.append(" builds done from ");
-sb.append(bi.buildsCount());
-}
+if (Objects.nonNull(bi)) {
+sb.append(bi.ticket).append(" to be commented, waiting for builds.
");
+sb.append(bi.finishedBuildsCount());
+sb.append(" builds done from ");
+sb.append(bi.buildsCount());
}
return sb.toString();
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
index 71171694..f52c5a04 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
@@ -71,7 +71,8 @@ public BuildsInfo(CompactBuildsInfo buildsInfo,
IStringCompactor strCompactor) {
this.ticket = strCompactor.getStringFromId(buildsInfo.ticket());
this.branchForTc =
strCompactor.getStringFromId(buildsInfo.branchForTc());
this.buildTypeId =
strCompactor.getStringFromId(buildsInfo.buildTypeId());
-this.finishedBuilds.putAll(buildsInfo.getFinishedBuilds());
+
+buildsInfo.getBuilds().forEach(id -> finishedBuilds.put(id, false));
}
/**
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
index c07f05af..69b3efed 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/CompactBuildsInfo.java
@@ -17,10 +17,10 @@
package org.apache.ignite.ci.observer;
+import java.util.ArrayList;
import java.util.Collections;
import java.util.Date;
-import java.util.HashMap;
-import java.util.Map;
+import java.util.List;
import java.util.Objects;
import org.apache.ignite.ci.teamcity.ignited.IStringCompactor;
@@ -46,9 +46,11 @@
/** */
[jira] [Created] (IGNITE-10284) performance drop on PME time during 1 server node left
Max Shonichev created IGNITE-10284: -- Summary: performance drop on PME time during 1 server node left Key: IGNITE-10284 URL: https://issues.apache.org/jira/browse/IGNITE-10284 Project: Ignite Issue Type: Bug Reporter: Max Shonichev 7 server nodes (1 node per host), 120 caches, G1GC, 32768 partitions 1 client tx loading 1. start cluster, fix baseline, preload data 2. start tx transfer task 3. kill 1 server node 4. wait for topology snapshot change, measure PME time 5. restart killed node 6. wait for topology snapshot change, measure PME time for 1 server LEAVE, we see 7%-10% degradation, BUG for 1 server JOIN, we see performance degradation on first exchange (evt=NODE_LEFT) and performance increase on second exchange (evt=CacheAffinityChange), overall 40-60% increase. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
Let's move git notifications to a separate list. As for JIRA, not sure it bothers me, it took me several minutes to set up all the filters to spread the messages out across specific folders. Otherwise, some of us might ignore subscribing to jira-list and would miss notifications when their input is needed. -- Denis On Thu, Nov 15, 2018 at 12:03 PM Vladimir Ozerov wrote: > Dmitry, > > I am not referring to some "authoritative ASF member" as a guide for us. We > are on our own. What I meant is that at some point in time we were pointed > to an idea, that tons of automated messages has nothing to do with healthy > community. Which seems pretty reasonable to me. > > On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov > wrote: > > > What incubator mentor do you refer to? Incubator member are asf members > as > > well. > > > > I was involved at least to 3 discussions at the list started from Jira > > issue created. > > > > If others were not involved, it do not convince me its is not useful to > > keep forwarding. > > > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov : > > > > > Dmitry, > > > > > > What Apache member do you refer to? > > > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > > > > > > > How do you know what to watch if new tickets are not forwarded? > > > > > > > > Again, PRs are ok to remove since it is duplicate to jira, but jira > > > removal > > > > does not make any sense for me. > > > > > > > > Com dev folks instead suggest to forward all comments and all > activity > > > from > > > > github to the list. So if Apache member will confirm it is not useful > > to > > > > allow dev. list watchers see new issues on the list we can continue > > > > discussion. Openness is needed not for veterans but for all community > > > > members and users who is subscribed to the list. > > > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > > Emails to everyone are not. > > > > > > > > > > +1 for separate mailing list for all automated emails. > > > > > I don't think we can avoid automated emails completely, but dev > list > > > > should > > > > > be human-only. > > > > > So separate list is the only way. > > > > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > > voze...@gridgain.com> > > > > > wrote: > > > > > > > > > > > Completely agree with Denis. Tons of generated messages and > > community > > > > > > health are not relevant. Currently we obviously have too much > > tickets > > > > and > > > > > > too little communications. This is bad. But whether we accumulate > > > > > generated > > > > > > stuff here or in some other place is not important at all, > provided > > > > that > > > > > we > > > > > > can point dev-list readers to JIRA channel. And as far as > generated > > > > > stuff, > > > > > > this was one of very serious concerns of our mentors during > > > incubation > > > > > > phase - too many tickets, too little real communications. > Splitting > > > > > message > > > > > > flows will help us understand where we are. > > > > > > > > > > > > And another very interesting thing is how PMCs treat all these > > > > messages - > > > > > > they ignore them. When I come with that problem, one PMC proposed > > > > > solution > > > > > > - "just filter them like I do". Then I, another PMC, answered - > "I > > do > > > > not > > > > > > know how to filter them". Finally, third PMC, who also filters > > these > > > > > > messages, helped me create proper filter in GMail. > > > > > > > > > > > > Isn't it demonstrative enough that so many PMC, who are expected > to > > > > > > understand project very well and follow a lot of activities, find > > it > > > > > useful > > > > > > to *remove* JIRA emails from their inboxes in order to ... well > ... > > > > > > understand what is going on. If Ignite veterans do not find these > > > > > generated > > > > > > emails useful, then I do not know who else can benefit from them. > > > > > > > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > > > > dmekhani...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > > I doesn't mean we should make them do it. > > > > > > > > > > > > > > How do JIRA messages help? > > > > > > > If you want do discuss something – write to dev list. > > > > > > > If you want a code review – write to dev list. > > > > > > > If you have an announcement – write to dev list. > > > > > > > I don't see, how JIRA messages can replace any of these points. > > > > > > > > > > > > > > Literally nobody ever answered a message from JIRA bot. > > > > > > > I think, that only watchers of JIRA tickets should be notified > > > about > > > > > > > updates. > > > > > > > There is no point in sending messages to everyone. > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov < >
[GitHub] ignite pull request #4908: IGNITE-9786
Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/4908 ---
[jira] [Created] (IGNITE-10283) `control.sh --baseline` does not output other nodes when cluster is inactive
Max Shonichev created IGNITE-10283:
--
Summary: `control.sh --baseline` does not output other nodes when
cluster is inactive
Key: IGNITE-10283
URL: https://issues.apache.org/jira/browse/IGNITE-10283
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
Fix For: 2.7
1. start 2 nodes from clean LFS
2. control.sh --baseline
expected: 0 baseline nodes, 2 other nodes
actual: 0 baseline nodes, 0 other nodes, BUG
{noformat}
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Cluster state: inactive
Current topology version: 2
Baseline nodes not found.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #5403: Ignite 2.4.12 p1
GitHub user antkr opened a pull request: https://github.com/apache/ignite/pull/5403 Ignite 2.4.12 p1 Pull request for teamcity run. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2.4.12-p1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5403.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5403 commit 7214eff5b5d8102ba32a7b7bf7597ac5a4b04eee Author: Alexey Kukushkin Date: 2018-04-02T08:08:05Z IGNITE-8076: Java Thin Client: authentication. This closes #3720. commit 2c0e269fe7793bb70d1be28d2052f1394b96f2b1 Author: devozerov Date: 2018-04-02T08:09:17Z Merge branch 'ignite-2.4.4' into ignite-2.4-master commit cb89494be26be1b0e397e06f7eaeb6419aec1828 Author: Alexey Kuznetsov Date: 2018-03-02T09:35:26Z IGNITE-7803 REST: Implemented possibility to get values from cache inserted via API or SQL. (cherry picked from commit a84018b) commit 149802a3be82ba1f88770dbff75d74b892bb0a94 Author: Alexey Kuznetsov Date: 2018-03-07T17:17:20Z IGNITE-7803 Fixed regression in tests. (cherry picked from commit 90c0af8) commit 5b5571adc7282a29cdecd8ab2e945a446ea709fc Author: Alexey Kuznetsov Date: 2018-03-23T02:55:13Z IGNITE-8002 REST: Added support of new authentication via new API. (cherry picked from commit 921f0cf) commit 128fdfcd874286f4a358546c0f43b6ef082a064b Author: devozerov Date: 2018-04-02T10:11:16Z IGNITE-7884: Sample data set for JDBC. This closes #3702. commit 247a9ef5a68de198106a866b277f1bee596c3633 Author: devozerov Date: 2018-04-02T10:16:00Z Merge branch 'ignite-2.4.4' into ignite-2.4-master commit 3949df02128e3003c409e0169ad0c80948ba134c Author: Aleksey Plekhanov Date: 2018-02-13T13:43:49Z IGNITE-5265 Eviction Rate memory metric to be implemented Signed-off-by: Anton Vinogradov commit 7bc6c1ad3bacaf5e354d2710931eb398c346c06c Author: Tim Onyschak Date: 2018-03-31T12:58:25Z IGNITE-7090 Semaphore Stuck when no acquirers to assign permit - Fixes #3443. Signed-off-by: dspavlov (cherry picked from commit 3fc5d57) commit c854ad86f4c64260171085c8c7cce97ba1ad2530 Author: Pavel Kovalenko Date: 2018-02-22T09:02:31Z IGNITE-7749 Fixed testDiscoCacheReuseOnNodeJoin test. - Fixes #3540. Signed-off-by: Alexey Goncharuk commit b2e94b36bddebbf7b3ff40631e099939d16926d2 Author: Alexey Goncharuk Date: 2018-02-13T15:53:23Z IGNITE-7692 Corrected test to not fail when SQL is executed on backup commit 852425d4170ed1871c79f5ac26bfb3d03cc36a6f Author: ÐлекÑей СÑелÑмак Date: 2018-04-06T15:28:22Z IGNITE-8049 Limit the number of operation cycles in B+Tree - Fixes #3769. Signed-off-by: dpavlov (cherry picked from commit e491f10) commit 42f529f0a04ce22786bb4a23032a64f93e214233 Author: Alexey Kuznetsov Date: 2018-04-09T02:25:50Z IGNITE-8159 control.sh: Fixed NPE on adding nodes on empty baseline and not active cluster. (cherry picked from commit 834869c) commit b5f180838246f895d36846ea707790c1ff7fe70a Author: Stanislav Lukyanov Date: 2018-04-09T11:33:13Z IGNITE-7904: Changed IgniteUtils::cast not to trim exception chains. This closes #3683. (cherry picked from commit 3a4f23b) commit 1ce8e1a8fd48469073592e2fb77e2881a168a219 Author: Roman Guseinov Date: 2018-04-09T11:45:44Z IGNITE-7944: Disconnected client node tries to send JOB_CANCEL message. Applied fix: - Skip sending message if client disconnected; - Throw IgniteCheckedException if a client node is disconnected and communication client is null. This closes #3737. (cherry picked from commit d70477b) commit 840e193b3e604e8b0d90be5fac16cf11d8c832e6 Author: Ilya Lantukh Date: 2018-04-06T10:49:10Z ignite-8087 : Backported ignite-8018. (cherry picked from commit 175edf3) commit 94e857c94ce5e7998fc39e38deee69f389ddbc5b Author: Alexey Goncharuk Date: 2018-04-10T17:33:47Z IGNITE-6430 Complete failing test early commit 770f7469d4b86ce9af61e9e43c7262d86ee05b54 Author: Eduard Shangareev Date: 2018-04-06T16:22:07Z IGNITE-8114 Add fail recovery mechanism to tracking pages commit 549d6e3de86a22697577f77a2ebab3d0dca7338d Author: Alexey Kukushkin Date: 2018-04-11T13:29:07Z IGNITE-8221: Security for thin clients. commit 94c0f56ef78e6c61f0e753c8aa0185c611630d45 Author: devozerov Date: 2018-04-11T13:44:33Z IGNITE-8148: JDBC thin: semicolon as delimiter for properties. This closes #3794. commit d99a50ccd6923aa48da78955207fe747b287ea81 Author: mcherkasov Date: 2018-04-11T00:23:29Z IGNITE-8153 Nodes fail to connect each other when SSL is enabled - Fixes #3773. Signed-off-by: Valentin Kulichenko commit
[jira] [Created] (IGNITE-10282) control.sh: implement proper shell arguments escaping due to the possible usage of regular expression in --cache command
Max Shonichev created IGNITE-10282:
--
Summary: control.sh: implement proper shell arguments escaping due
to the possible usage of regular expression in --cache command
Key: IGNITE-10282
URL: https://issues.apache.org/jira/browse/IGNITE-10282
Project: Ignite
Issue Type: Bug
Reporter: Max Shonichev
Fix For: 2.7
mandatory argument regexPattern after --cache list command is not
shell-escaped, which leads to unexpected behaviour
{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Check arguments.
Error: Invalid UUID string: benchmarks
{noformat}
{noformat}
$ IGNITE_HOME=`pwd` bin/control.sh --cache list '.*' --config
Control utility [ver. 2.5.1-p150#20181101-sha1:b46a69df]
2018 Copyright(C) Apache Software Foundation
User: mshonichev
Check arguments.
Error: Invalid UUID string: ..
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
Dmitry, I am not referring to some "authoritative ASF member" as a guide for us. We are on our own. What I meant is that at some point in time we were pointed to an idea, that tons of automated messages has nothing to do with healthy community. Which seems pretty reasonable to me. On Thu, Nov 15, 2018 at 10:15 PM Dmitriy Pavlov wrote: > What incubator mentor do you refer to? Incubator member are asf members as > well. > > I was involved at least to 3 discussions at the list started from Jira > issue created. > > If others were not involved, it do not convince me its is not useful to > keep forwarding. > > чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov : > > > Dmitry, > > > > What Apache member do you refer to? > > > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > > > > > How do you know what to watch if new tickets are not forwarded? > > > > > > Again, PRs are ok to remove since it is duplicate to jira, but jira > > removal > > > does not make any sense for me. > > > > > > Com dev folks instead suggest to forward all comments and all activity > > from > > > github to the list. So if Apache member will confirm it is not useful > to > > > allow dev. list watchers see new issues on the list we can continue > > > discussion. Openness is needed not for veterans but for all community > > > members and users who is subscribed to the list. > > > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > > Emails to everyone are not. > > > > > > > > +1 for separate mailing list for all automated emails. > > > > I don't think we can avoid automated emails completely, but dev list > > > should > > > > be human-only. > > > > So separate list is the only way. > > > > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov < > voze...@gridgain.com> > > > > wrote: > > > > > > > > > Completely agree with Denis. Tons of generated messages and > community > > > > > health are not relevant. Currently we obviously have too much > tickets > > > and > > > > > too little communications. This is bad. But whether we accumulate > > > > generated > > > > > stuff here or in some other place is not important at all, provided > > > that > > > > we > > > > > can point dev-list readers to JIRA channel. And as far as generated > > > > stuff, > > > > > this was one of very serious concerns of our mentors during > > incubation > > > > > phase - too many tickets, too little real communications. Splitting > > > > message > > > > > flows will help us understand where we are. > > > > > > > > > > And another very interesting thing is how PMCs treat all these > > > messages - > > > > > they ignore them. When I come with that problem, one PMC proposed > > > > solution > > > > > - "just filter them like I do". Then I, another PMC, answered - "I > do > > > not > > > > > know how to filter them". Finally, third PMC, who also filters > these > > > > > messages, helped me create proper filter in GMail. > > > > > > > > > > Isn't it demonstrative enough that so many PMC, who are expected to > > > > > understand project very well and follow a lot of activities, find > it > > > > useful > > > > > to *remove* JIRA emails from their inboxes in order to ... well ... > > > > > understand what is going on. If Ignite veterans do not find these > > > > generated > > > > > emails useful, then I do not know who else can benefit from them. > > > > > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > > > dmekhani...@gmail.com> > > > > > wrote: > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > I doesn't mean we should make them do it. > > > > > > > > > > > > How do JIRA messages help? > > > > > > If you want do discuss something – write to dev list. > > > > > > If you want a code review – write to dev list. > > > > > > If you have an announcement – write to dev list. > > > > > > I don't see, how JIRA messages can replace any of these points. > > > > > > > > > > > > Literally nobody ever answered a message from JIRA bot. > > > > > > I think, that only watchers of JIRA tickets should be notified > > about > > > > > > updates. > > > > > > There is no point in sending messages to everyone. > > > > > > > > > > > > Denis > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov >: > > > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > > > > > > > > > JIRA ticket is an intention to be done by contributors in > future. > > > > > > > > > > > > > > If PMC member admits decisions are made off the list and just > > > > provided > > > > > as > > > > > > > fact-in-the-past for others - it really signs poor community > > > health. > > > > So > > > > > > for > > > > > > > me, it is not reasonable to fight with JIRA messages it is > > > reasonable > > > > > to > > > > > > > grow a culture of on-list development. If we don't have it, > JIRA > > > > should > > > > > > > remain here. > > > > >
Re: Time to remove automated messages from the devlist?
Personally I am comfortable with the way how things are now because mail filters appear to work well for me. However this thread made me curious about whether ASF has some guidance or recommendations on that matter. I searched quite a bit and found none of that kind. It looks like Apache leaves it at discretion of the project community to decide whether to make separate list for automated messages or not (which made a fairly good sense after I gave it a bit more thought, see below). --- After that I decided to check how other Apache projects manage their mailing lists and as far as I can tell most active ones tend to have separate mailing lists for automatic notifications from version control and / or issue tracker. I checked few top projects by number of committers from the list here: https://projects.apache.org/projects.html?number - specifically top 8 that had over 80 committers (for comparison, this list currently says Ignite has 38, I think we're fairly close to that league). - https://hadoop.apache.org/mailing_lists.html https://openoffice.apache.org/mailing-lists.html http://cloudstack.apache.org/mailing-lists.html http://ambari.apache.org/mail-lists.html ---> Separate lists for commits and for issue tracker. - http://geode.apache.org/community/#mailing-lists https://cordova.apache.org/contact/ http://subversion.apache.org/mailing-lists.html http://hive.apache.org/mailing_lists.html ---> Separate list for commits. For the sake of completeness I also sampled 4 projects having 38 committers, just like Ignite. - http://chemistry.apache.org/project/community.html ---> No lists for commits nor issues. - http://ctakes.apache.org/mailing.html ---> Separate list for commits. - http://metron.apache.org/community/ ---> Separate list for issues. - https://orc.apache.org/develop/ ---> Separate lists for commits and for issue tracker. --- Based on my personal experience this issue looks to some extent a matter of whether we consider some barrier for entry to dev list desirable or not. I could not actively use list until I learned how to setup mail filters because it was difficult to find discussions to participate. On the other hand, after setting these filters it turned out very easy. So the question is, do we want to have dev list easier or harder to use for "passers by" who aren't deeply involved in project. If we want to keep it strictly at top experience level, then we better keep all automated messages in. If we want it welcoming for any random passer by, then we better move all automated messages somewhere else. And there are of course intermediate approaches, we can basically tune ease of entry by picking which part of automated messages will stay and which will go away. --- Another important thing I learned when studying mailing lists of other projects is we better take into account that regular automated messages may help in keeping dev list "lively" in the slow times, when there are little to none discussions. At first I was tempted to propose moving all the automated messages outside - "just like big boys do" - note how top 4 projects in my list all have commits and issues in separate lists. But looking how smaller projects tend to handle it differently made me wonder if maybe it is a bit more complicated, maybe there is some difference worth considering. And as far as I can tell, the important difference is size of community / amount of committers. When there are lots of people actively involved in the project it is very likely that they can permanently maintain dev list active by natural discussions. But when the project is smaller, there is a substantial risk that sometimes most active developers are focused on issue tracker or github which means dev list may look abandoned (if it contains only discussions). If there is such a risk then keeping some (not necessarily all) automated messages in dev list will help its subscribers and visitors avoid misleading impression of "abandoned empty place" by showing that the project is indeed actively maintained. regards, Oleg -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[GitHub] ignite pull request #5395: IGNITE-10253
Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/5395 ---
Re: Time to remove automated messages from the devlist?
What incubator mentor do you refer to? Incubator member are asf members as well. I was involved at least to 3 discussions at the list started from Jira issue created. If others were not involved, it do not convince me its is not useful to keep forwarding. чт, 15 нояб. 2018 г., 21:23 Vladimir Ozerov : > Dmitry, > > What Apache member do you refer to? > > чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > > > How do you know what to watch if new tickets are not forwarded? > > > > Again, PRs are ok to remove since it is duplicate to jira, but jira > removal > > does not make any sense for me. > > > > Com dev folks instead suggest to forward all comments and all activity > from > > github to the list. So if Apache member will confirm it is not useful to > > allow dev. list watchers see new issues on the list we can continue > > discussion. Openness is needed not for veterans but for all community > > members and users who is subscribed to the list. > > > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > > > Personal emails for _watched_ JIRA tickets are very useful. > > > Emails to everyone are not. > > > > > > +1 for separate mailing list for all automated emails. > > > I don't think we can avoid automated emails completely, but dev list > > should > > > be human-only. > > > So separate list is the only way. > > > > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov > > > wrote: > > > > > > > Completely agree with Denis. Tons of generated messages and community > > > > health are not relevant. Currently we obviously have too much tickets > > and > > > > too little communications. This is bad. But whether we accumulate > > > generated > > > > stuff here or in some other place is not important at all, provided > > that > > > we > > > > can point dev-list readers to JIRA channel. And as far as generated > > > stuff, > > > > this was one of very serious concerns of our mentors during > incubation > > > > phase - too many tickets, too little real communications. Splitting > > > message > > > > flows will help us understand where we are. > > > > > > > > And another very interesting thing is how PMCs treat all these > > messages - > > > > they ignore them. When I come with that problem, one PMC proposed > > > solution > > > > - "just filter them like I do". Then I, another PMC, answered - "I do > > not > > > > know how to filter them". Finally, third PMC, who also filters these > > > > messages, helped me create proper filter in GMail. > > > > > > > > Isn't it demonstrative enough that so many PMC, who are expected to > > > > understand project very well and follow a lot of activities, find it > > > useful > > > > to *remove* JIRA emails from their inboxes in order to ... well ... > > > > understand what is going on. If Ignite veterans do not find these > > > generated > > > > emails useful, then I do not know who else can benefit from them. > > > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > > dmekhani...@gmail.com> > > > > wrote: > > > > > > > > > Dmitriy, > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > I doesn't mean we should make them do it. > > > > > > > > > > How do JIRA messages help? > > > > > If you want do discuss something – write to dev list. > > > > > If you want a code review – write to dev list. > > > > > If you have an announcement – write to dev list. > > > > > I don't see, how JIRA messages can replace any of these points. > > > > > > > > > > Literally nobody ever answered a message from JIRA bot. > > > > > I think, that only watchers of JIRA tickets should be notified > about > > > > > updates. > > > > > There is no point in sending messages to everyone. > > > > > > > > > > Denis > > > > > > > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > > > > > > > JIRA ticket is an intention to be done by contributors in future. > > > > > > > > > > > > If PMC member admits decisions are made off the list and just > > > provided > > > > as > > > > > > fact-in-the-past for others - it really signs poor community > > health. > > > So > > > > > for > > > > > > me, it is not reasonable to fight with JIRA messages it is > > reasonable > > > > to > > > > > > grow a culture of on-list development. If we don't have it, JIRA > > > should > > > > > > remain here. > > > > > > > > > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov < > > > dmekhani...@gmail.com > > > > >: > > > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > > > If we want people to act openly and community-friendly, then we > > > > should > > > > > > make > > > > > > > it a part of the required development process. > > > > > > > Otherwise people just won't care about it. > > > > > > > Moreover, all JIRA tickets are open for everyone, so no > openness > > > > would > > > > > be > > > > > > > violated if we made a separate mailing list for bots. > > > > > > > JIRA tickets are just as easy to search through, as
Re: Time to remove automated messages from the devlist?
Dmitry, What Apache member do you refer to? чт, 15 нояб. 2018 г. в 21:10, Dmitriy Pavlov : > How do you know what to watch if new tickets are not forwarded? > > Again, PRs are ok to remove since it is duplicate to jira, but jira removal > does not make any sense for me. > > Com dev folks instead suggest to forward all comments and all activity from > github to the list. So if Apache member will confirm it is not useful to > allow dev. list watchers see new issues on the list we can continue > discussion. Openness is needed not for veterans but for all community > members and users who is subscribed to the list. > > чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > > > Personal emails for _watched_ JIRA tickets are very useful. > > Emails to everyone are not. > > > > +1 for separate mailing list for all automated emails. > > I don't think we can avoid automated emails completely, but dev list > should > > be human-only. > > So separate list is the only way. > > > > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov > > wrote: > > > > > Completely agree with Denis. Tons of generated messages and community > > > health are not relevant. Currently we obviously have too much tickets > and > > > too little communications. This is bad. But whether we accumulate > > generated > > > stuff here or in some other place is not important at all, provided > that > > we > > > can point dev-list readers to JIRA channel. And as far as generated > > stuff, > > > this was one of very serious concerns of our mentors during incubation > > > phase - too many tickets, too little real communications. Splitting > > message > > > flows will help us understand where we are. > > > > > > And another very interesting thing is how PMCs treat all these > messages - > > > they ignore them. When I come with that problem, one PMC proposed > > solution > > > - "just filter them like I do". Then I, another PMC, answered - "I do > not > > > know how to filter them". Finally, third PMC, who also filters these > > > messages, helped me create proper filter in GMail. > > > > > > Isn't it demonstrative enough that so many PMC, who are expected to > > > understand project very well and follow a lot of activities, find it > > useful > > > to *remove* JIRA emails from their inboxes in order to ... well ... > > > understand what is going on. If Ignite veterans do not find these > > generated > > > emails useful, then I do not know who else can benefit from them. > > > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov < > dmekhani...@gmail.com> > > > wrote: > > > > > > > Dmitriy, > > > > > > > > > I do believe Igniters can set up a filter. > > > > I doesn't mean we should make them do it. > > > > > > > > How do JIRA messages help? > > > > If you want do discuss something – write to dev list. > > > > If you want a code review – write to dev list. > > > > If you have an announcement – write to dev list. > > > > I don't see, how JIRA messages can replace any of these points. > > > > > > > > Literally nobody ever answered a message from JIRA bot. > > > > I think, that only watchers of JIRA tickets should be notified about > > > > updates. > > > > There is no point in sending messages to everyone. > > > > > > > > Denis > > > > > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > > > > > > > I do believe Igniters can set up a filter. > > > > > > > > > > JIRA ticket is an intention to be done by contributors in future. > > > > > > > > > > If PMC member admits decisions are made off the list and just > > provided > > > as > > > > > fact-in-the-past for others - it really signs poor community > health. > > So > > > > for > > > > > me, it is not reasonable to fight with JIRA messages it is > reasonable > > > to > > > > > grow a culture of on-list development. If we don't have it, JIRA > > should > > > > > remain here. > > > > > > > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov < > > dmekhani...@gmail.com > > > >: > > > > > > > > > > > Dmitriy, > > > > > > > > > > > > If we want people to act openly and community-friendly, then we > > > should > > > > > make > > > > > > it a part of the required development process. > > > > > > Otherwise people just won't care about it. > > > > > > Moreover, all JIRA tickets are open for everyone, so no openness > > > would > > > > be > > > > > > violated if we made a separate mailing list for bots. > > > > > > JIRA tickets are just as easy to search through, as the emails. > > > > > > > > > > > > If you write anything to the dev list, then only the once, who > > spent > > > > half > > > > > > an hour, configuring the email filters will see it. > > > > > > Others won't notice it, because it will get lost among the flood > of > > > > spam > > > > > > messages from bots. > > > > > > > > > > > > If you are interested in receiving the JIRA notifications, you > > could > > > > > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > > > > > and keep track of what happens there. It would simplify >
Re: Time to remove automated messages from the devlist?
How do you know what to watch if new tickets are not forwarded? Again, PRs are ok to remove since it is duplicate to jira, but jira removal does not make any sense for me. Com dev folks instead suggest to forward all comments and all activity from github to the list. So if Apache member will confirm it is not useful to allow dev. list watchers see new issues on the list we can continue discussion. Openness is needed not for veterans but for all community members and users who is subscribed to the list. чт, 15 нояб. 2018 г., 21:00 Pavel Tupitsyn : > Personal emails for _watched_ JIRA tickets are very useful. > Emails to everyone are not. > > +1 for separate mailing list for all automated emails. > I don't think we can avoid automated emails completely, but dev list should > be human-only. > So separate list is the only way. > > > On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov > wrote: > > > Completely agree with Denis. Tons of generated messages and community > > health are not relevant. Currently we obviously have too much tickets and > > too little communications. This is bad. But whether we accumulate > generated > > stuff here or in some other place is not important at all, provided that > we > > can point dev-list readers to JIRA channel. And as far as generated > stuff, > > this was one of very serious concerns of our mentors during incubation > > phase - too many tickets, too little real communications. Splitting > message > > flows will help us understand where we are. > > > > And another very interesting thing is how PMCs treat all these messages - > > they ignore them. When I come with that problem, one PMC proposed > solution > > - "just filter them like I do". Then I, another PMC, answered - "I do not > > know how to filter them". Finally, third PMC, who also filters these > > messages, helped me create proper filter in GMail. > > > > Isn't it demonstrative enough that so many PMC, who are expected to > > understand project very well and follow a lot of activities, find it > useful > > to *remove* JIRA emails from their inboxes in order to ... well ... > > understand what is going on. If Ignite veterans do not find these > generated > > emails useful, then I do not know who else can benefit from them. > > > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov > > wrote: > > > > > Dmitriy, > > > > > > > I do believe Igniters can set up a filter. > > > I doesn't mean we should make them do it. > > > > > > How do JIRA messages help? > > > If you want do discuss something – write to dev list. > > > If you want a code review – write to dev list. > > > If you have an announcement – write to dev list. > > > I don't see, how JIRA messages can replace any of these points. > > > > > > Literally nobody ever answered a message from JIRA bot. > > > I think, that only watchers of JIRA tickets should be notified about > > > updates. > > > There is no point in sending messages to everyone. > > > > > > Denis > > > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > > > > > I do believe Igniters can set up a filter. > > > > > > > > JIRA ticket is an intention to be done by contributors in future. > > > > > > > > If PMC member admits decisions are made off the list and just > provided > > as > > > > fact-in-the-past for others - it really signs poor community health. > So > > > for > > > > me, it is not reasonable to fight with JIRA messages it is reasonable > > to > > > > grow a culture of on-list development. If we don't have it, JIRA > should > > > > remain here. > > > > > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov < > dmekhani...@gmail.com > > >: > > > > > > > > > Dmitriy, > > > > > > > > > > If we want people to act openly and community-friendly, then we > > should > > > > make > > > > > it a part of the required development process. > > > > > Otherwise people just won't care about it. > > > > > Moreover, all JIRA tickets are open for everyone, so no openness > > would > > > be > > > > > violated if we made a separate mailing list for bots. > > > > > JIRA tickets are just as easy to search through, as the emails. > > > > > > > > > > If you write anything to the dev list, then only the once, who > spent > > > half > > > > > an hour, configuring the email filters will see it. > > > > > Others won't notice it, because it will get lost among the flood of > > > spam > > > > > messages from bots. > > > > > > > > > > If you are interested in receiving the JIRA notifications, you > could > > > > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > > > > and keep track of what happens there. It would simplify filtering, > > > > because > > > > > you should only filter out the corresponding recipient. > > > > > > > > > > Currently if you want to filter out all messages from bots, you > > should > > > > > enumerate all possible topics, that bots may generate. > > > > > And since the number of bots only grows with time, the filter > should > > be > > > > > kept in actual state,
Re: Time to remove automated messages from the devlist?
Hi, In my opinion there should be only development discussions and important notifications on dev list. But I must say that I started to look through Jira and even GitHub notifications from time to time. And I find that it sometimes gives me a useful information like "contributor A is doing B". But I think that there will be no harm for me to check it on different mail list. чт, 15 нояб. 2018 г. в 20:11, Vladimir Ozerov : > > Completely agree with Denis. Tons of generated messages and community > health are not relevant. Currently we obviously have too much tickets and > too little communications. This is bad. But whether we accumulate generated > stuff here or in some other place is not important at all, provided that we > can point dev-list readers to JIRA channel. And as far as generated stuff, > this was one of very serious concerns of our mentors during incubation > phase - too many tickets, too little real communications. Splitting message > flows will help us understand where we are. > > And another very interesting thing is how PMCs treat all these messages - > they ignore them. When I come with that problem, one PMC proposed solution > - "just filter them like I do". Then I, another PMC, answered - "I do not > know how to filter them". Finally, third PMC, who also filters these > messages, helped me create proper filter in GMail. > > Isn't it demonstrative enough that so many PMC, who are expected to > understand project very well and follow a lot of activities, find it useful > to *remove* JIRA emails from their inboxes in order to ... well ... > understand what is going on. If Ignite veterans do not find these generated > emails useful, then I do not know who else can benefit from them. > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov > wrote: > > > Dmitriy, > > > > > I do believe Igniters can set up a filter. > > I doesn't mean we should make them do it. > > > > How do JIRA messages help? > > If you want do discuss something – write to dev list. > > If you want a code review – write to dev list. > > If you have an announcement – write to dev list. > > I don't see, how JIRA messages can replace any of these points. > > > > Literally nobody ever answered a message from JIRA bot. > > I think, that only watchers of JIRA tickets should be notified about > > updates. > > There is no point in sending messages to everyone. > > > > Denis > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > > > I do believe Igniters can set up a filter. > > > > > > JIRA ticket is an intention to be done by contributors in future. > > > > > > If PMC member admits decisions are made off the list and just provided as > > > fact-in-the-past for others - it really signs poor community health. So > > for > > > me, it is not reasonable to fight with JIRA messages it is reasonable to > > > grow a culture of on-list development. If we don't have it, JIRA should > > > remain here. > > > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov : > > > > > > > Dmitriy, > > > > > > > > If we want people to act openly and community-friendly, then we should > > > make > > > > it a part of the required development process. > > > > Otherwise people just won't care about it. > > > > Moreover, all JIRA tickets are open for everyone, so no openness would > > be > > > > violated if we made a separate mailing list for bots. > > > > JIRA tickets are just as easy to search through, as the emails. > > > > > > > > If you write anything to the dev list, then only the once, who spent > > half > > > > an hour, configuring the email filters will see it. > > > > Others won't notice it, because it will get lost among the flood of > > spam > > > > messages from bots. > > > > > > > > If you are interested in receiving the JIRA notifications, you could > > > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > > > and keep track of what happens there. It would simplify filtering, > > > because > > > > you should only filter out the corresponding recipient. > > > > > > > > Currently if you want to filter out all messages from bots, you should > > > > enumerate all possible topics, that bots may generate. > > > > And since the number of bots only grows with time, the filter should be > > > > kept in actual state, otherwise messages will spill into the inbox. > > > > > > > > Denis > > > > > > > > чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > > > > > > > > > Hi Denis, > > > > > > > > > > Another side of this decision is the openness of the development. > > > > > > > > > > Since not all contributors pay attention to run their development in > > an > > > > > open/community friendly manner: > > > > > - to announce important features, and > > > > > - Telegraph their intent > > > > > - Draft designs openly > > > > > - Submit work in chunks > > > > > - Welcome feedback along the way > > > > > > > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > > > > > > > > > we can't just remove JIRA from the list. > > > > > >
Re: Time to remove automated messages from the devlist?
Personal emails for _watched_ JIRA tickets are very useful. Emails to everyone are not. +1 for separate mailing list for all automated emails. I don't think we can avoid automated emails completely, but dev list should be human-only. So separate list is the only way. On Thu, Nov 15, 2018 at 8:11 PM Vladimir Ozerov wrote: > Completely agree with Denis. Tons of generated messages and community > health are not relevant. Currently we obviously have too much tickets and > too little communications. This is bad. But whether we accumulate generated > stuff here or in some other place is not important at all, provided that we > can point dev-list readers to JIRA channel. And as far as generated stuff, > this was one of very serious concerns of our mentors during incubation > phase - too many tickets, too little real communications. Splitting message > flows will help us understand where we are. > > And another very interesting thing is how PMCs treat all these messages - > they ignore them. When I come with that problem, one PMC proposed solution > - "just filter them like I do". Then I, another PMC, answered - "I do not > know how to filter them". Finally, third PMC, who also filters these > messages, helped me create proper filter in GMail. > > Isn't it demonstrative enough that so many PMC, who are expected to > understand project very well and follow a lot of activities, find it useful > to *remove* JIRA emails from their inboxes in order to ... well ... > understand what is going on. If Ignite veterans do not find these generated > emails useful, then I do not know who else can benefit from them. > > On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov > wrote: > > > Dmitriy, > > > > > I do believe Igniters can set up a filter. > > I doesn't mean we should make them do it. > > > > How do JIRA messages help? > > If you want do discuss something – write to dev list. > > If you want a code review – write to dev list. > > If you have an announcement – write to dev list. > > I don't see, how JIRA messages can replace any of these points. > > > > Literally nobody ever answered a message from JIRA bot. > > I think, that only watchers of JIRA tickets should be notified about > > updates. > > There is no point in sending messages to everyone. > > > > Denis > > > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > > > I do believe Igniters can set up a filter. > > > > > > JIRA ticket is an intention to be done by contributors in future. > > > > > > If PMC member admits decisions are made off the list and just provided > as > > > fact-in-the-past for others - it really signs poor community health. So > > for > > > me, it is not reasonable to fight with JIRA messages it is reasonable > to > > > grow a culture of on-list development. If we don't have it, JIRA should > > > remain here. > > > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov >: > > > > > > > Dmitriy, > > > > > > > > If we want people to act openly and community-friendly, then we > should > > > make > > > > it a part of the required development process. > > > > Otherwise people just won't care about it. > > > > Moreover, all JIRA tickets are open for everyone, so no openness > would > > be > > > > violated if we made a separate mailing list for bots. > > > > JIRA tickets are just as easy to search through, as the emails. > > > > > > > > If you write anything to the dev list, then only the once, who spent > > half > > > > an hour, configuring the email filters will see it. > > > > Others won't notice it, because it will get lost among the flood of > > spam > > > > messages from bots. > > > > > > > > If you are interested in receiving the JIRA notifications, you could > > > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > > > and keep track of what happens there. It would simplify filtering, > > > because > > > > you should only filter out the corresponding recipient. > > > > > > > > Currently if you want to filter out all messages from bots, you > should > > > > enumerate all possible topics, that bots may generate. > > > > And since the number of bots only grows with time, the filter should > be > > > > kept in actual state, otherwise messages will spill into the inbox. > > > > > > > > Denis > > > > > > > > чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > > > > > > > > > Hi Denis, > > > > > > > > > > Another side of this decision is the openness of the development. > > > > > > > > > > Since not all contributors pay attention to run their development > in > > an > > > > > open/community friendly manner: > > > > > - to announce important features, and > > > > > - Telegraph their intent > > > > > - Draft designs openly > > > > > - Submit work in chunks > > > > > - Welcome feedback along the way > > > > > > > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > > > > > > > > > we can't just remove JIRA from the list. > > > > > > > > > > Today JIRA forwarding is an only way to keep Ignite development > easy > > to
Re: Time to remove automated messages from the devlist?
Completely agree with Denis. Tons of generated messages and community health are not relevant. Currently we obviously have too much tickets and too little communications. This is bad. But whether we accumulate generated stuff here or in some other place is not important at all, provided that we can point dev-list readers to JIRA channel. And as far as generated stuff, this was one of very serious concerns of our mentors during incubation phase - too many tickets, too little real communications. Splitting message flows will help us understand where we are. And another very interesting thing is how PMCs treat all these messages - they ignore them. When I come with that problem, one PMC proposed solution - "just filter them like I do". Then I, another PMC, answered - "I do not know how to filter them". Finally, third PMC, who also filters these messages, helped me create proper filter in GMail. Isn't it demonstrative enough that so many PMC, who are expected to understand project very well and follow a lot of activities, find it useful to *remove* JIRA emails from their inboxes in order to ... well ... understand what is going on. If Ignite veterans do not find these generated emails useful, then I do not know who else can benefit from them. On Thu, Nov 15, 2018 at 7:06 PM Denis Mekhanikov wrote: > Dmitriy, > > > I do believe Igniters can set up a filter. > I doesn't mean we should make them do it. > > How do JIRA messages help? > If you want do discuss something – write to dev list. > If you want a code review – write to dev list. > If you have an announcement – write to dev list. > I don't see, how JIRA messages can replace any of these points. > > Literally nobody ever answered a message from JIRA bot. > I think, that only watchers of JIRA tickets should be notified about > updates. > There is no point in sending messages to everyone. > > Denis > > чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > > > I do believe Igniters can set up a filter. > > > > JIRA ticket is an intention to be done by contributors in future. > > > > If PMC member admits decisions are made off the list and just provided as > > fact-in-the-past for others - it really signs poor community health. So > for > > me, it is not reasonable to fight with JIRA messages it is reasonable to > > grow a culture of on-list development. If we don't have it, JIRA should > > remain here. > > > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov : > > > > > Dmitriy, > > > > > > If we want people to act openly and community-friendly, then we should > > make > > > it a part of the required development process. > > > Otherwise people just won't care about it. > > > Moreover, all JIRA tickets are open for everyone, so no openness would > be > > > violated if we made a separate mailing list for bots. > > > JIRA tickets are just as easy to search through, as the emails. > > > > > > If you write anything to the dev list, then only the once, who spent > half > > > an hour, configuring the email filters will see it. > > > Others won't notice it, because it will get lost among the flood of > spam > > > messages from bots. > > > > > > If you are interested in receiving the JIRA notifications, you could > > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > > and keep track of what happens there. It would simplify filtering, > > because > > > you should only filter out the corresponding recipient. > > > > > > Currently if you want to filter out all messages from bots, you should > > > enumerate all possible topics, that bots may generate. > > > And since the number of bots only grows with time, the filter should be > > > kept in actual state, otherwise messages will spill into the inbox. > > > > > > Denis > > > > > > чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > > > > > > > Hi Denis, > > > > > > > > Another side of this decision is the openness of the development. > > > > > > > > Since not all contributors pay attention to run their development in > an > > > > open/community friendly manner: > > > > - to announce important features, and > > > > - Telegraph their intent > > > > - Draft designs openly > > > > - Submit work in chunks > > > > - Welcome feedback along the way > > > > > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > > > > > > > we can't just remove JIRA from the list. > > > > > > > > Today JIRA forwarding is an only way to keep Ignite development easy > to > > > > follow by subscribing to dev. list. > > > > > > > > If we came to practice that all contributors announce important > > features > > > > and bugs, JIRA can be removed. Now it can't. > > > > > > > > Which problem we can solve by removing JIRA from the list? > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov < > dmekhani...@gmail.com > > >: > > > > > > > > > Guys, > > > > > > > > > > I vote for moving automatically generated messages to a separate > > > mailing > > > > > list (maybe
[GitHub] ignite pull request #5360: IGNITE-10207 Fix missed loss policy checks
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5360 ---
Re: Time to remove automated messages from the devlist?
Dmitriy, > I do believe Igniters can set up a filter. I doesn't mean we should make them do it. How do JIRA messages help? If you want do discuss something – write to dev list. If you want a code review – write to dev list. If you have an announcement – write to dev list. I don't see, how JIRA messages can replace any of these points. Literally nobody ever answered a message from JIRA bot. I think, that only watchers of JIRA tickets should be notified about updates. There is no point in sending messages to everyone. Denis чт, 15 нояб. 2018 г. в 18:50, Dmitriy Pavlov : > I do believe Igniters can set up a filter. > > JIRA ticket is an intention to be done by contributors in future. > > If PMC member admits decisions are made off the list and just provided as > fact-in-the-past for others - it really signs poor community health. So for > me, it is not reasonable to fight with JIRA messages it is reasonable to > grow a culture of on-list development. If we don't have it, JIRA should > remain here. > > чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov : > > > Dmitriy, > > > > If we want people to act openly and community-friendly, then we should > make > > it a part of the required development process. > > Otherwise people just won't care about it. > > Moreover, all JIRA tickets are open for everyone, so no openness would be > > violated if we made a separate mailing list for bots. > > JIRA tickets are just as easy to search through, as the emails. > > > > If you write anything to the dev list, then only the once, who spent half > > an hour, configuring the email filters will see it. > > Others won't notice it, because it will get lost among the flood of spam > > messages from bots. > > > > If you are interested in receiving the JIRA notifications, you could > > subscribe to ignite-bots (or even ignite-jira) mailing list, > > and keep track of what happens there. It would simplify filtering, > because > > you should only filter out the corresponding recipient. > > > > Currently if you want to filter out all messages from bots, you should > > enumerate all possible topics, that bots may generate. > > And since the number of bots only grows with time, the filter should be > > kept in actual state, otherwise messages will spill into the inbox. > > > > Denis > > > > чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > > > > > Hi Denis, > > > > > > Another side of this decision is the openness of the development. > > > > > > Since not all contributors pay attention to run their development in an > > > open/community friendly manner: > > > - to announce important features, and > > > - Telegraph their intent > > > - Draft designs openly > > > - Submit work in chunks > > > - Welcome feedback along the way > > > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > > > > > we can't just remove JIRA from the list. > > > > > > Today JIRA forwarding is an only way to keep Ignite development easy to > > > follow by subscribing to dev. list. > > > > > > If we came to practice that all contributors announce important > features > > > and bugs, JIRA can be removed. Now it can't. > > > > > > Which problem we can solve by removing JIRA from the list? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov >: > > > > > > > Guys, > > > > > > > > I vote for moving automatically generated messages to a separate > > mailing > > > > list (maybe except most important ones). > > > > I already wrote about it here: > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > > > > > > > What we have now makes the Nabble portal an absolute mess with no > > ability > > > > to track human communication. > > > > It's even hard to search for old discussions, because messages about > > JIRA > > > > tickets and git commit messages pop in the search results. > > > > > > > > Making every person configure email filters is waisting everybody's > > time. > > > > Just imagine, how many human-hours has been spent on it. > > > > We should respect time of others, and make the separation of emails > on > > > the > > > > sending side. > > > > > > > > Denis > > > > > > > > чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > > > > > > > > > IMO we need to run a formal vote on this change, and then PMC chair > > can > > > > > create (or reuse) a separate list for messages from Git repos. > > > > > > > > > > > > > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov < > voze...@gridgain.com > > >: > > > > > > > > > > > Igniters, > > > > > > > > > > > > I would say that "set the filter" is not a solution. First, it is > > not > > > > > > always possible technically. E.g. I use GMail and my dev-list > > emails > > > > are > > > > > > already use a rule. I cannot extract generated emails from > overall > > > flow > > > > > > with GMail capabilities. But the more important things - is why > in > > > the > > > > > > first place someone needs to went
Re: Time to remove automated messages from the devlist?
I do believe Igniters can set up a filter. JIRA ticket is an intention to be done by contributors in future. If PMC member admits decisions are made off the list and just provided as fact-in-the-past for others - it really signs poor community health. So for me, it is not reasonable to fight with JIRA messages it is reasonable to grow a culture of on-list development. If we don't have it, JIRA should remain here. чт, 15 нояб. 2018 г. в 18:30, Denis Mekhanikov : > Dmitriy, > > If we want people to act openly and community-friendly, then we should make > it a part of the required development process. > Otherwise people just won't care about it. > Moreover, all JIRA tickets are open for everyone, so no openness would be > violated if we made a separate mailing list for bots. > JIRA tickets are just as easy to search through, as the emails. > > If you write anything to the dev list, then only the once, who spent half > an hour, configuring the email filters will see it. > Others won't notice it, because it will get lost among the flood of spam > messages from bots. > > If you are interested in receiving the JIRA notifications, you could > subscribe to ignite-bots (or even ignite-jira) mailing list, > and keep track of what happens there. It would simplify filtering, because > you should only filter out the corresponding recipient. > > Currently if you want to filter out all messages from bots, you should > enumerate all possible topics, that bots may generate. > And since the number of bots only grows with time, the filter should be > kept in actual state, otherwise messages will spill into the inbox. > > Denis > > чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > > > Hi Denis, > > > > Another side of this decision is the openness of the development. > > > > Since not all contributors pay attention to run their development in an > > open/community friendly manner: > > - to announce important features, and > > - Telegraph their intent > > - Draft designs openly > > - Submit work in chunks > > - Welcome feedback along the way > > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > > > we can't just remove JIRA from the list. > > > > Today JIRA forwarding is an only way to keep Ignite development easy to > > follow by subscribing to dev. list. > > > > If we came to practice that all contributors announce important features > > and bugs, JIRA can be removed. Now it can't. > > > > Which problem we can solve by removing JIRA from the list? > > > > Sincerely, > > Dmitriy Pavlov > > > > чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov : > > > > > Guys, > > > > > > I vote for moving automatically generated messages to a separate > mailing > > > list (maybe except most important ones). > > > I already wrote about it here: > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > > > > > What we have now makes the Nabble portal an absolute mess with no > ability > > > to track human communication. > > > It's even hard to search for old discussions, because messages about > JIRA > > > tickets and git commit messages pop in the search results. > > > > > > Making every person configure email filters is waisting everybody's > time. > > > Just imagine, how many human-hours has been spent on it. > > > We should respect time of others, and make the separation of emails on > > the > > > sending side. > > > > > > Denis > > > > > > чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > > > > > > > IMO we need to run a formal vote on this change, and then PMC chair > can > > > > create (or reuse) a separate list for messages from Git repos. > > > > > > > > > > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov >: > > > > > > > > > Igniters, > > > > > > > > > > I would say that "set the filter" is not a solution. First, it is > not > > > > > always possible technically. E.g. I use GMail and my dev-list > emails > > > are > > > > > already use a rule. I cannot extract generated emails from overall > > flow > > > > > with GMail capabilities. But the more important things - is why in > > the > > > > > first place someone needs to went through that generated nightmare? > > > > > > > > > > Git messages is a spam. Looks like everyone agrees with that. As > far > > as > > > > > JIRA ticket creation - this is all about importance. When someone > > > writes > > > > an > > > > > email to the devlist, this is likely to be important topic > requiring > > > > > attention. When someone creates a ticket, most likely this either a > > > bug, > > > > or > > > > > a piece of already discussed issue, or so. In other words - average > > > > devlist > > > > > user is likely to be interested in manual messages and is very > > unlikely > > > > to > > > > > be interested in "Ticket created" messages. Not important > information > > > > > overshadows important. Let's continue disucssion this. > > > > > > > > > > As far as Git - what should be done to remove Git messages from the > > > list? >
[jira] [Created] (IGNITE-10281) Log to file all jars in classpath on start node.
Sergey Antonov created IGNITE-10281: --- Summary: Log to file all jars in classpath on start node. Key: IGNITE-10281 URL: https://issues.apache.org/jira/browse/IGNITE-10281 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Fix For: 2.8 We should print all jars in classpath for analize jar's hell. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5402: Ignite 2.5.3.b2
GitHub user antkr opened a pull request: https://github.com/apache/ignite/pull/5402 Ignite 2.5.3.b2 Pull request for teamcity run. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2.5.3.b2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5402.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5402 commit 807197e4c70357fb5c1479162ab63e64dcf9d294 Author: Dmitriy Govorukhin Date: 2018-07-23T15:22:25Z Merge remote-tracking branch 'professional/ignite-2.5-master' into ignite-2.5-master commit 13565452fc6a360310d688db15e5d98d4a044246 Author: dmitrievanthony Date: 2018-07-24T14:56:50Z IGNITE-9055: [ML] SVM throws NPE in case of empty partitions this closes #4412 (cherry picked from commit d0e6def) commit 8c88b6f86a1c1273a782a9178e766c1550ee5cd6 Author: Andrey V. Mashenkov Date: 2018-07-24T14:38:34Z IGNITE-8892 Fixed CacheQueryFuture usage in DataStructures processor - Fixes #4415. Signed-off-by: Alexey Goncharuk (cherry picked from commit 281a400) commit 0b1d4e16fc1af9309d24ed9288d96872040caa13 Author: Andrey V. Mashenkov Date: 2018-07-24T15:23:02Z Merge remote-tracking branch 'origin/ignite-2.5-master' into ignite-2.5-master commit e46068cc2efc6bf4279e38a762819344deedc807 Author: pvinokurov Date: 2018-07-23T15:25:21Z IGNITE-8968 Fixed failure not being rethrown from rebalance closure - Fixes #4338. Signed-off-by: Alexey Goncharuk (cherry picked from commit 47e6f99) commit 00d994196eb68b34cdea3b23ce58dda4924088f8 Author: dkarachentsev Date: 2018-07-25T10:03:42Z IGNITE-9038 Node join serialization defaults Signed-off-by: Andrey Gura (cherry picked from commit 0ee363f) commit c603d146347542f3b1faacea3cfb6f1f7902ea49 Author: dkarachentsev Date: 2018-07-25T12:51:15Z IGNITE-8944 TcpDiscoverySpi: set connection check frequency to fixed value. - Fixes #4320. Signed-off-by: Alexey Kuznetsov (cherry picked from commit 8d75ebf) commit 30167085feefb6b81d5623004938e24e388b1994 Author: Sergey Chugunov Date: 2018-07-25T13:26:12Z IGNITE-9040 StopNodeFailureHandler is not able to stop node correctly on node segmentation Signed-off-by: Andrey Gura (cherry-picked from commit#469aaba59c0539507972f4725642b2f2f81c08a0) commit e173153f05694daf3c5d71fb38cc1fd758e1817a Author: Anton Dmitriev Date: 2018-07-27T13:52:52Z IGNITE-9055: [ML] SVM throws NPE in case of empty partitions backport, compilation fix commit 8df693c15c6c0effb5bba2c62d2a37ffcfb2093c Author: Alexey Kuznetsov Date: 2018-06-22T10:00:11Z IGNITE-8428 Web Console: Implemented connection to secured cluster. (cherry picked from commit c8be8c2) commit 8e3bac2c0b66472fc3c68f91d377bc9e533f3aab Author: Alexey Kuznetsov Date: 2018-07-11T13:25:52Z IGNITE-8428 Web Console: Added support for task arguments with private constructors. (cherry picked from commit d7723dc) commit a0e236117afe75596d865bb2ceeff9c3164c5f04 Author: Alexey Kuznetsov Date: 2018-07-30T11:46:42Z WC-558 Merge with ignite-2.5-master. commit 02d671f5fe6471a98c4221f912a09df9adb698df Author: Vasiliy Sisko Date: 2018-07-31T04:41:55Z IGNITE-7255 Web Console: Fixed EXPLAIN execution on Queries screen. (cherry picked from commit d73211d2c1fc3897681a3abdc98c5eb383d24475) commit b5398412d54bf68f6358d2fb11a41fcb64ba4e68 Author: Anton Kalashnikov Date: 2018-07-23T13:48:18Z IGNITE-8998 Send reconnect exception without partitions - Fixes #4358. Signed-off-by: Alexey Goncharuk (cherry picked from commit 78e0bb7) commit 7bc2b33a5456c28452f265640a3401093054c634 Author: devozerov Date: 2018-07-31T09:53:51Z IGNITE-9114: SQL: fail query after some timeout if it cannot be mapped to topology. This closes #4453. commit 207e01ec5b8c297285a5dff17f8ae108f558fe81 Author: Dmitriy Shabalin Date: 2018-07-31T11:12:13Z IGNITE-9139 Web Console: Fixed issue with dropdown for chart options on Queries screen. (cherry picked from commit f6c67e864212bf66abc38293f7c7c27e380116c2) commit 83de638b282b6bb9a7c5f7110dc4ce08b0ed57c7 Author: Alexey Kuznetsov Date: 2018-07-31T11:35:20Z IGNITE-8999 Web Console: Fixed issue with missing errorParser on paragraph creation. (cherry picked from commit bea6fe31125f907c57446582292b878ef7d6d994) commit 7c9c3d8ad92990213bab3b19a637b124736262e8 Author: Alexey Kuznetsov Date: 2018-07-31T11:41:01Z IGNITE-9136 Web Console: Do not show (de)activate switcher for clusters older than v2.0.0. (cherry picked from commit bcda7a1f584af3f8c3d1db3020ddc952dd4bb918) commit
Re: Time to remove automated messages from the devlist?
Dmitriy, If we want people to act openly and community-friendly, then we should make it a part of the required development process. Otherwise people just won't care about it. Moreover, all JIRA tickets are open for everyone, so no openness would be violated if we made a separate mailing list for bots. JIRA tickets are just as easy to search through, as the emails. If you write anything to the dev list, then only the once, who spent half an hour, configuring the email filters will see it. Others won't notice it, because it will get lost among the flood of spam messages from bots. If you are interested in receiving the JIRA notifications, you could subscribe to ignite-bots (or even ignite-jira) mailing list, and keep track of what happens there. It would simplify filtering, because you should only filter out the corresponding recipient. Currently if you want to filter out all messages from bots, you should enumerate all possible topics, that bots may generate. And since the number of bots only grows with time, the filter should be kept in actual state, otherwise messages will spill into the inbox. Denis чт, 15 нояб. 2018 г. в 17:58, Dmitriy Pavlov : > Hi Denis, > > Another side of this decision is the openness of the development. > > Since not all contributors pay attention to run their development in an > open/community friendly manner: > - to announce important features, and > - Telegraph their intent > - Draft designs openly > - Submit work in chunks > - Welcome feedback along the way > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > we can't just remove JIRA from the list. > > Today JIRA forwarding is an only way to keep Ignite development easy to > follow by subscribing to dev. list. > > If we came to practice that all contributors announce important features > and bugs, JIRA can be removed. Now it can't. > > Which problem we can solve by removing JIRA from the list? > > Sincerely, > Dmitriy Pavlov > > чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov : > > > Guys, > > > > I vote for moving automatically generated messages to a separate mailing > > list (maybe except most important ones). > > I already wrote about it here: > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > > > What we have now makes the Nabble portal an absolute mess with no ability > > to track human communication. > > It's even hard to search for old discussions, because messages about JIRA > > tickets and git commit messages pop in the search results. > > > > Making every person configure email filters is waisting everybody's time. > > Just imagine, how many human-hours has been spent on it. > > We should respect time of others, and make the separation of emails on > the > > sending side. > > > > Denis > > > > чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > > > > > IMO we need to run a formal vote on this change, and then PMC chair can > > > create (or reuse) a separate list for messages from Git repos. > > > > > > > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov : > > > > > > > Igniters, > > > > > > > > I would say that "set the filter" is not a solution. First, it is not > > > > always possible technically. E.g. I use GMail and my dev-list emails > > are > > > > already use a rule. I cannot extract generated emails from overall > flow > > > > with GMail capabilities. But the more important things - is why in > the > > > > first place someone needs to went through that generated nightmare? > > > > > > > > Git messages is a spam. Looks like everyone agrees with that. As far > as > > > > JIRA ticket creation - this is all about importance. When someone > > writes > > > an > > > > email to the devlist, this is likely to be important topic requiring > > > > attention. When someone creates a ticket, most likely this either a > > bug, > > > or > > > > a piece of already discussed issue, or so. In other words - average > > > devlist > > > > user is likely to be interested in manual messages and is very > unlikely > > > to > > > > be interested in "Ticket created" messages. Not important information > > > > overshadows important. Let's continue disucssion this. > > > > > > > > As far as Git - what should be done to remove Git messages from the > > list? > > > > > > > > Vladimir. > > > > > > > > On Tue, Nov 6, 2018 at 6:49 PM Dmitriy Pavlov > > > > > wrote: > > > > > > > > > Petr, some manual digest, is probably not needed because Apache > list > > > > allows > > > > > subscribing to digest. dev-digest-subsr...@ignite.apache.org if I > > > > remember > > > > > this correctly. > > > > > > > > > > вт, 6 нояб. 2018 г. в 18:28, Petr Ivanov : > > > > > > > > > > > Can be Jira notifications united in some kind of daily digest? > > > > > > Maybe we can add special filter (new tasks / updates during last > 24 > > > > > hours) > > > > > > with notification scheme? > > > > > > > > > > > > > > > > > > > On 6 Nov 2018, at 18:15, Dmitriy Pavlov > > > > > wrote: > > > > >
Re: Time to remove automated messages from the devlist?
Dmitriy, The problem is already outlined above - JIRA notifications have very little to do with openness, as most of them are either minor things or decisions which are already made. You will never see the whole picture of what the project is doing. What is *MUCH* worse is that currently we have false impression that all is fine. Top 5 active dev list! Woohoo!.Reality: 90% is generate messages. Remove them - and we will see what really happens to the project. And if we see silence on the list, this will raise immediate questions on community health. In any case, moving JIRA messages to another mailing list will never do any harm if implemented properly. E.g. we can send weekly notifications to the devlist to keep readers aware that opened tickets are tracked in another list. Even better, we may send weekly digests with all opened tickets. Instead of 100 messages we will have 1. Or we can do it daily if needed. The key idea - split *mostly* important communications from *mostly* unimportant. Vladimir. On Thu, Nov 15, 2018 at 5:58 PM Dmitriy Pavlov wrote: > Hi Denis, > > Another side of this decision is the openness of the development. > > Since not all contributors pay attention to run their development in an > open/community friendly manner: > - to announce important features, and > - Telegraph their intent > - Draft designs openly > - Submit work in chunks > - Welcome feedback along the way > http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 > > we can't just remove JIRA from the list. > > Today JIRA forwarding is an only way to keep Ignite development easy to > follow by subscribing to dev. list. > > If we came to practice that all contributors announce important features > and bugs, JIRA can be removed. Now it can't. > > Which problem we can solve by removing JIRA from the list? > > Sincerely, > Dmitriy Pavlov > > чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov : > > > Guys, > > > > I vote for moving automatically generated messages to a separate mailing > > list (maybe except most important ones). > > I already wrote about it here: > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > > > What we have now makes the Nabble portal an absolute mess with no ability > > to track human communication. > > It's even hard to search for old discussions, because messages about JIRA > > tickets and git commit messages pop in the search results. > > > > Making every person configure email filters is waisting everybody's time. > > Just imagine, how many human-hours has been spent on it. > > We should respect time of others, and make the separation of emails on > the > > sending side. > > > > Denis > > > > чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > > > > > IMO we need to run a formal vote on this change, and then PMC chair can > > > create (or reuse) a separate list for messages from Git repos. > > > > > > > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov : > > > > > > > Igniters, > > > > > > > > I would say that "set the filter" is not a solution. First, it is not > > > > always possible technically. E.g. I use GMail and my dev-list emails > > are > > > > already use a rule. I cannot extract generated emails from overall > flow > > > > with GMail capabilities. But the more important things - is why in > the > > > > first place someone needs to went through that generated nightmare? > > > > > > > > Git messages is a spam. Looks like everyone agrees with that. As far > as > > > > JIRA ticket creation - this is all about importance. When someone > > writes > > > an > > > > email to the devlist, this is likely to be important topic requiring > > > > attention. When someone creates a ticket, most likely this either a > > bug, > > > or > > > > a piece of already discussed issue, or so. In other words - average > > > devlist > > > > user is likely to be interested in manual messages and is very > unlikely > > > to > > > > be interested in "Ticket created" messages. Not important information > > > > overshadows important. Let's continue disucssion this. > > > > > > > > As far as Git - what should be done to remove Git messages from the > > list? > > > > > > > > Vladimir. > > > > > > > > On Tue, Nov 6, 2018 at 6:49 PM Dmitriy Pavlov > > > > > wrote: > > > > > > > > > Petr, some manual digest, is probably not needed because Apache > list > > > > allows > > > > > subscribing to digest. dev-digest-subsr...@ignite.apache.org if I > > > > remember > > > > > this correctly. > > > > > > > > > > вт, 6 нояб. 2018 г. в 18:28, Petr Ivanov : > > > > > > > > > > > Can be Jira notifications united in some kind of daily digest? > > > > > > Maybe we can add special filter (new tasks / updates during last > 24 > > > > > hours) > > > > > > with notification scheme? > > > > > > > > > > > > > > > > > > > On 6 Nov 2018, at 18:15, Dmitriy Pavlov > > > > > wrote: > > > > > > > > > > > > > > I should mention I disagree to remove JIRA issues as the first > > > step. >
[jira] [Created] (IGNITE-10280) Create Yardstick IgniteGetAllTxBenchmark
Ivan Artukhov created IGNITE-10280: -- Summary: Create Yardstick IgniteGetAllTxBenchmark Key: IGNITE-10280 URL: https://issues.apache.org/jira/browse/IGNITE-10280 Project: Ignite Issue Type: Improvement Components: yardstick Reporter: Ivan Artukhov Yardstick module has no transactional getAll benchmark. Only atomic IgniteGetAllBenchmark. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5401: IGNITE-10278 The checkpointReadLock must be acqui...
GitHub user sk0x50 opened a pull request: https://github.com/apache/ignite/pull/5401 IGNITE-10278 The checkpointReadLock must be acquired before calling MvccProcessor.updateState You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10278 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5401.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5401 commit beaf05fbef68fb7933738a501533317158566abe Author: Slava Koptilin Date: 2018-11-15T15:07:33Z IGNITE-10278 The checkpointReadLock must be acquired before calling MvccProcessor.updateState ---
[jira] [Created] (IGNITE-10279) Control.sh utility unify options naming format
Sergey Antonov created IGNITE-10279: --- Summary: Control.sh utility unify options naming format Key: IGNITE-10279 URL: https://issues.apache.org/jira/browse/IGNITE-10279 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.8 Now we have options in several styles: --ping-interval, --skipZeros. I think, we must unify options naming format. We should follow linux format, i.e. --word1-word2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Time to remove automated messages from the devlist?
Hi Denis, Another side of this decision is the openness of the development. Since not all contributors pay attention to run their development in an open/community friendly manner: - to announce important features, and - Telegraph their intent - Draft designs openly - Submit work in chunks - Welcome feedback along the way http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 we can't just remove JIRA from the list. Today JIRA forwarding is an only way to keep Ignite development easy to follow by subscribing to dev. list. If we came to practice that all contributors announce important features and bugs, JIRA can be removed. Now it can't. Which problem we can solve by removing JIRA from the list? Sincerely, Dmitriy Pavlov чт, 15 нояб. 2018 г. в 17:34, Denis Mekhanikov : > Guys, > > I vote for moving automatically generated messages to a separate mailing > list (maybe except most important ones). > I already wrote about it here: > > http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html > > What we have now makes the Nabble portal an absolute mess with no ability > to track human communication. > It's even hard to search for old discussions, because messages about JIRA > tickets and git commit messages pop in the search results. > > Making every person configure email filters is waisting everybody's time. > Just imagine, how many human-hours has been spent on it. > We should respect time of others, and make the separation of emails on the > sending side. > > Denis > > чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > > > IMO we need to run a formal vote on this change, and then PMC chair can > > create (or reuse) a separate list for messages from Git repos. > > > > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov : > > > > > Igniters, > > > > > > I would say that "set the filter" is not a solution. First, it is not > > > always possible technically. E.g. I use GMail and my dev-list emails > are > > > already use a rule. I cannot extract generated emails from overall flow > > > with GMail capabilities. But the more important things - is why in the > > > first place someone needs to went through that generated nightmare? > > > > > > Git messages is a spam. Looks like everyone agrees with that. As far as > > > JIRA ticket creation - this is all about importance. When someone > writes > > an > > > email to the devlist, this is likely to be important topic requiring > > > attention. When someone creates a ticket, most likely this either a > bug, > > or > > > a piece of already discussed issue, or so. In other words - average > > devlist > > > user is likely to be interested in manual messages and is very unlikely > > to > > > be interested in "Ticket created" messages. Not important information > > > overshadows important. Let's continue disucssion this. > > > > > > As far as Git - what should be done to remove Git messages from the > list? > > > > > > Vladimir. > > > > > > On Tue, Nov 6, 2018 at 6:49 PM Dmitriy Pavlov > > > wrote: > > > > > > > Petr, some manual digest, is probably not needed because Apache list > > > allows > > > > subscribing to digest. dev-digest-subsr...@ignite.apache.org if I > > > remember > > > > this correctly. > > > > > > > > вт, 6 нояб. 2018 г. в 18:28, Petr Ivanov : > > > > > > > > > Can be Jira notifications united in some kind of daily digest? > > > > > Maybe we can add special filter (new tasks / updates during last 24 > > > > hours) > > > > > with notification scheme? > > > > > > > > > > > > > > > > On 6 Nov 2018, at 18:15, Dmitriy Pavlov > > > wrote: > > > > > > > > > > > > I should mention I disagree to remove JIRA issues as the first > > step. > > > It > > > > > > helps everyone to understand what other people are going to do in > > the > > > > > > project. You always can comment if it is not the best approach, > > > find a > > > > > > duplicate issue, and you may suggest help. > > > > > > > > > > > > PR notification is more or less duplicates JIRA (as 1 JIRA 1..* > > PR), > > > so > > > > > it > > > > > > may be ok to move Git's messages to > > notificati...@ignite.apache.org > > > > > > > > > > > > > > > > > > But we should keep JIRA and test failures. > > > > > > > > > > > > вт, 6 нояб. 2018 г. в 17:49, Alexey Kuznetsov < > > akuznet...@apache.org > > > >: > > > > > > > > > > > >> Hi! > > > > > >> > > > > > >> I have filter for e-mail from JIRA (very useful, I can quick > > search > > > > > issue > > > > > >> there without visiting JIRA). > > > > > >> > > > > > >> And I'm just deleting tons of e-mails from GitBox & about PRs. > > > > > >> > > > > > >> I don't know what for we need them? > > > > > >> > > > > > >> May by we try to move GitBox & PRs-related mails first and see > how > > > it > > > > > goes? > > > > > >> > > > > > >> -- > > > > > >> Alexey Kuznetsov > > > > > >> > > > > > > > > > > > > > > > > > > > >
Re: control.sh: a bug or feature?
Max, correct link to ticket is https://issues.apache.org/jira/browse/IGNITE-10258 I would agree with you and Vladimir that parameters in mentioned case may appear in any order. --Yakov
[jira] [Created] (IGNITE-10277) Prepare-commit ordering is violated for one-phase commit transactions
Ivan Rakov created IGNITE-10277: --- Summary: Prepare-commit ordering is violated for one-phase commit transactions Key: IGNITE-10277 URL: https://issues.apache.org/jira/browse/IGNITE-10277 Project: Ignite Issue Type: Improvement Reporter: Ivan Rakov Fix For: 2.8 Basic transactions invariant (all prepares should happen-before all commits) is violated in one-phase commit scenario. Reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10278) The checkpointReadLock must be acquired before calling MvccProcessor.updateState
Vyacheslav Koptilin created IGNITE-10278:
Summary: The checkpointReadLock must be acquired before calling
MvccProcessor.updateState
Key: IGNITE-10278
URL: https://issues.apache.org/jira/browse/IGNITE-10278
Project: Ignite
Issue Type: Bug
Components: mvcc
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
It looks like acquiring \{{checkpointReadLock}} is missing when we are trying
to apply mvcc tx records.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Brainstorm: Make TC Run All faster
Denis, you can go even further. E.g. you can start topology once for the full set of single threaded full api cache tests. Each test should start cache dynamically and run it logic. As for me, I would think of splitting RunAll to 2 steps - one containing basic tests and another with more complex tests. 2nd step should not start (except manually) if 1st step results in any build failure. --Yakov
Re: Time to remove automated messages from the devlist?
Guys, I vote for moving automatically generated messages to a separate mailing list (maybe except most important ones). I already wrote about it here: http://apache-ignite-developers.2346864.n4.nabble.com/Bots-on-dev-list-td34406.html What we have now makes the Nabble portal an absolute mess with no ability to track human communication. It's even hard to search for old discussions, because messages about JIRA tickets and git commit messages pop in the search results. Making every person configure email filters is waisting everybody's time. Just imagine, how many human-hours has been spent on it. We should respect time of others, and make the separation of emails on the sending side. Denis чт, 15 нояб. 2018 г. в 13:20, Dmitriy Pavlov : > IMO we need to run a formal vote on this change, and then PMC chair can > create (or reuse) a separate list for messages from Git repos. > > > ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov : > > > Igniters, > > > > I would say that "set the filter" is not a solution. First, it is not > > always possible technically. E.g. I use GMail and my dev-list emails are > > already use a rule. I cannot extract generated emails from overall flow > > with GMail capabilities. But the more important things - is why in the > > first place someone needs to went through that generated nightmare? > > > > Git messages is a spam. Looks like everyone agrees with that. As far as > > JIRA ticket creation - this is all about importance. When someone writes > an > > email to the devlist, this is likely to be important topic requiring > > attention. When someone creates a ticket, most likely this either a bug, > or > > a piece of already discussed issue, or so. In other words - average > devlist > > user is likely to be interested in manual messages and is very unlikely > to > > be interested in "Ticket created" messages. Not important information > > overshadows important. Let's continue disucssion this. > > > > As far as Git - what should be done to remove Git messages from the list? > > > > Vladimir. > > > > On Tue, Nov 6, 2018 at 6:49 PM Dmitriy Pavlov > > wrote: > > > > > Petr, some manual digest, is probably not needed because Apache list > > allows > > > subscribing to digest. dev-digest-subsr...@ignite.apache.org if I > > remember > > > this correctly. > > > > > > вт, 6 нояб. 2018 г. в 18:28, Petr Ivanov : > > > > > > > Can be Jira notifications united in some kind of daily digest? > > > > Maybe we can add special filter (new tasks / updates during last 24 > > > hours) > > > > with notification scheme? > > > > > > > > > > > > > On 6 Nov 2018, at 18:15, Dmitriy Pavlov > > wrote: > > > > > > > > > > I should mention I disagree to remove JIRA issues as the first > step. > > It > > > > > helps everyone to understand what other people are going to do in > the > > > > > project. You always can comment if it is not the best approach, > > find a > > > > > duplicate issue, and you may suggest help. > > > > > > > > > > PR notification is more or less duplicates JIRA (as 1 JIRA 1..* > PR), > > so > > > > it > > > > > may be ok to move Git's messages to > notificati...@ignite.apache.org > > > > > > > > > > > > > > > But we should keep JIRA and test failures. > > > > > > > > > > вт, 6 нояб. 2018 г. в 17:49, Alexey Kuznetsov < > akuznet...@apache.org > > >: > > > > > > > > > >> Hi! > > > > >> > > > > >> I have filter for e-mail from JIRA (very useful, I can quick > search > > > > issue > > > > >> there without visiting JIRA). > > > > >> > > > > >> And I'm just deleting tons of e-mails from GitBox & about PRs. > > > > >> > > > > >> I don't know what for we need them? > > > > >> > > > > >> May by we try to move GitBox & PRs-related mails first and see how > > it > > > > goes? > > > > >> > > > > >> -- > > > > >> Alexey Kuznetsov > > > > >> > > > > > > > > > > > > > >
[GitHub] ignite pull request #5080: IGNITE-10009: ODBC fix for escaped table names
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5080 ---
[jira] [Created] (IGNITE-10276) MVCC TX: Optimize logger creations
Igor Seliverstov created IGNITE-10276: - Summary: MVCC TX: Optimize logger creations Key: IGNITE-10276 URL: https://issues.apache.org/jira/browse/IGNITE-10276 Project: Ignite Issue Type: Improvement Components: mvcc Reporter: Igor Seliverstov Fix For: 2.8 We need to initialize loggers in all new classes like it was done in *GridDhtAtomicAbstractUpdateFuture* for example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Brainstorm: Make TC Run All faster
Dmitry, Sergey, There is a common pattern in the test codebase, when each test starts its own set of nodes, and closes them after the test finishes. Node startup takes quite a lot of time, and this time could be reduced, if tests shared the same set of nodes. I mean, if there is a test class with a lot of methods, then in many cases it's enough to start nodes in *beforeTestsStarted* and stop them in *afterTestsStopped* instead of doing it in every test case. We should encourage contributors to use this pattern. It's not applicable for all tests, and would violate isolation of tests, but I think, it's a good trade-off, because the running time of tests is a real problem. Denis чт, 15 нояб. 2018 г. в 15:11, Sergey Chugunov : > Dmitriy, > > You brought up really important topic that has a great impact on our > project. Faster runAlls mean quicker feedback and faster progress on issues > and features. > > We have a pretty big code base of tests, about 50 thousands tests. Do we > have an idea of how these tests overlap with each other? In my mind it is > possible that we have a good bunch of tests that cover the same code and > could be replaced with just a single test. > > In the ideal world we would even determine the minimal set of tests to > cover our codebase and remove excessive. > > -- > Best regards, > Sergey Chugunov. > > On Thu, Nov 15, 2018 at 2:34 PM Dmitriy Pavlov wrote: > > > Hi Igniters, > > > > > > > > Some of us started to use the Bot to get an approval of PRs. It helps to > > protect master from new failures, but this requires to run RunAll tests > set > > for each commit and this makes markable pressure to TC infra. > > > > > > > > I would like to ask you to share your ideas on how to make runAll faster, > > maybe you can share any of your measurements and any other info about > > (possible) bottlenecks. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > >
[GitHub] ignite pull request #5248: IGNITE-9897: ODBC fix for PDO when used with unix...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5248 ---
[GitHub] ignite pull request #5400: IGNITE-10192 OptimizedMarshallerTest#testAllocati...
GitHub user ibessonov opened a pull request: https://github.com/apache/ignite/pull/5400 IGNITE-10192 OptimizedMarshallerTest#testAllocationOverflow throws OOME instead of expected IOE You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10192 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5400.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5400 commit 1a45b39e522574721710d938472a3e454cd79611 Author: ibessonov Date: 2018-11-15T13:54:45Z IGNITE-10192 Optimized MarshallerTest#_testAllocationOverflow. Buffer expansion in GridUnsafeDataOutput improved. ---
[GitHub] ignite pull request #5398: ignite-10246 StandaloneWALRecordIterator must thr...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5398 ---
[GitHub] ignite pull request #5399: IGNITE-10273: Fixed retrieval of affinity mapping
GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/5399 IGNITE-10273: Fixed retrieval of affinity mapping You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10273 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5399.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5399 commit 904d22f164baac4f206f84b0e1276f31369c8fa2 Author: Igor Sapego Date: 2018-11-15T12:44:17Z IGNITE-10273: Added test that shows the issue commit 4a86945cb3ea11d77978ecabe35f836afa29d10f Author: Igor Sapego Date: 2018-11-15T12:46:56Z IGNITE-10273: Fix ---
[GitHub] ignite pull request #5398: ignite-10246 StandaloneWALRecordIterator must thr...
GitHub user SpiderRus opened a pull request: https://github.com/apache/ignite/pull/5398 ignite-10246 StandaloneWALRecordIterator must throw checkBounds exception You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10246 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5398.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5398 commit c40fd5c62760d0c1b814a1dd15c32af9ff233329 Author: Alexey Stelmak Date: 2018-11-15T13:19:58Z StrictBounsCheckException ---
[GitHub] asfgit closed pull request #72: IGNITE-10275 Jira spam fast fix
asfgit closed pull request #72: IGNITE-10275 Jira spam fast fix
URL: https://github.com/apache/ignite-teamcity-bot/pull/72
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
index 5ad13505..86768688 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/ObserverTask.java
@@ -141,7 +141,7 @@ protected String runObserverTask() {
if (info.isFinishedWithFailures(teamcity)) {
boolean rmv = compactInfos().remove(compactInfo);
-
+
Preconditions.checkState(rmv, "Key not found: " + compactInfo);
logger.error("JIRA will not be commented." +
@@ -157,34 +157,35 @@ protected String runObserverTask() {
continue;
}
-ICredentialsProv creds = tcHelper.getServerAuthorizerCreds();
+try {
+rmvdVisas.add(objMapper.writeValueAsString(compactInfo));
+}
+catch (Exception e) {
+logger.error("JSON string parse failed: " + e.getMessage(), e);
-Visa visa = jiraIntegration.notifyJira(info.srvId, creds,
info.buildTypeId,
-info.branchForTc, info.ticket);
+return "Exception while JSON parsing: " +
e.getClass().getSimpleName() + ": " + e.getMessage();
+}
-
visasHistoryStorage.updateVisaRequestRes(info.getContributionKey(), info.date,
visa);
+try {
+boolean rmv = compactInfos().remove(compactInfo);
-if (visa.isSuccess()) {
-ticketsNotified.add(info.ticket);
+if (!rmv)
+continue;
+}
+catch (Exception e) {
+logger.error("cache remove: " + e.getMessage(), e);
+
+return X.getFullStackTrace(e);
+}
-try {
-rmvdVisas.add(objMapper.writeValueAsString(compactInfo));
-}
-catch (Exception e) {
-logger.error("JSON string parse failed: " +
e.getMessage(), e);
+ICredentialsProv creds = tcHelper.getServerAuthorizerCreds();
-return "Exception while JSON parsing: " +
e.getClass().getSimpleName() + ": " + e.getMessage();
-}
+Visa visa = jiraIntegration.notifyJira(info.srvId, creds,
info.buildTypeId,
+info.branchForTc, info.ticket);
-try {
-compactInfos().remove(compactInfo);
-}
-catch (Exception e) {
-logger.error("cache remove: " + e.getMessage(), e);
+
visasHistoryStorage.updateVisaRequestRes(info.getContributionKey(), info.date,
visa);
-return X.getFullStackTrace(e);
-}
-}
+ticketsNotified.add(info.ticket);
}
return "Checked " + checkedBuilds + " not finished " +
notFinishedBuilds + " notified: " + ticketsNotified +
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] ololo3000 opened a new pull request #72: IGNITE-10275 Jira spam fast fix
ololo3000 opened a new pull request #72: IGNITE-10275 Jira spam fast fix URL: https://github.com/apache/ignite-teamcity-bot/pull/72 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IGNITE-10275) [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed
Dmitriy Pavlov created IGNITE-10275: --- Summary: [TC Bot] Several JIRA comments are issued in case ignite.cache.remove failed Key: IGNITE-10275 URL: https://issues.apache.org/jira/browse/IGNITE-10275 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: PetrovMikhail Example of spam: https://issues.apache.org/jira/browse/IGNITE-9308 org/apache/ignite/ci/observer/ObserverTask.java:179 org.apache.ignite.IgniteCache#remove(K) returns false, so bot tries to re-comment ticket in next cycle. It is possible as a fast fix at first check removes result, as a full fix we can refactor visa requests queue to some new (probably synthetic key). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10273) CPP Thin: Client is unable to get affinity mapping in some cases
Igor Sapego created IGNITE-10273:
Summary: CPP Thin: Client is unable to get affinity mapping in
some cases
Key: IGNITE-10273
URL: https://issues.apache.org/jira/browse/IGNITE-10273
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.8
Reproducer test:
{code:cpp}
BOOST_AUTO_TEST_CASE(CacheClientDefaultDynamicCacheThreeNodes)
{
StartNode("node1");
StartNode("node2");
IgniteClientConfiguration cfg;
cfg.SetEndPoints("127.0.0.1:0..11120");
IgniteClient client = IgniteClient::Start(cfg);
cache::CacheClient cache =
client.CreateCache("defaultdynamic3");
cache.RefreshAffinityMapping();
for (int64_t i = 1; i < 1000; ++i)
cache.Put(ignite::common::LexicalCast(i * 39916801), i *
5039);
for (int64_t i = 1; i < 1000; ++i)
{
int64_t val;
LocalPeek(cache, ignite::common::LexicalCast(i *
39916801), val);
BOOST_CHECK_EQUAL(val, i * 5039);
}
}
{code:cpp}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10274) MVCC: Optimize get from local backup.
Andrew Mashenkov created IGNITE-10274: - Summary: MVCC: Optimize get from local backup. Key: IGNITE-10274 URL: https://issues.apache.org/jira/browse/IGNITE-10274 Project: Ignite Issue Type: Bug Reporter: Andrew Mashenkov Fix test GridCachePartitionedGetSelfTest.testGetFromBackupNode(). Get from local backup with readFromBackup=true should not create SingleGetRequest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #5383: ignite-8735 Metastorage creates its own index par...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5383 ---
Re: Brainstorm: Make TC Run All faster
Dmitriy, You brought up really important topic that has a great impact on our project. Faster runAlls mean quicker feedback and faster progress on issues and features. We have a pretty big code base of tests, about 50 thousands tests. Do we have an idea of how these tests overlap with each other? In my mind it is possible that we have a good bunch of tests that cover the same code and could be replaced with just a single test. In the ideal world we would even determine the minimal set of tests to cover our codebase and remove excessive. -- Best regards, Sergey Chugunov. On Thu, Nov 15, 2018 at 2:34 PM Dmitriy Pavlov wrote: > Hi Igniters, > > > > Some of us started to use the Bot to get an approval of PRs. It helps to > protect master from new failures, but this requires to run RunAll tests set > for each commit and this makes markable pressure to TC infra. > > > > I would like to ask you to share your ideas on how to make runAll faster, > maybe you can share any of your measurements and any other info about > (possible) bottlenecks. > > > > Sincerely, > > Dmitriy Pavlov >
[jira] [Created] (IGNITE-10272) Inject learning environment into scope of dataset compute task
Artem Malykh created IGNITE-10272: - Summary: Inject learning environment into scope of dataset compute task Key: IGNITE-10272 URL: https://issues.apache.org/jira/browse/IGNITE-10272 Project: Ignite Issue Type: Improvement Reporter: Artem Malykh Assignee: Artem Malykh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Brainstorm: Make TC Run All faster
Hi Igniters, Some of us started to use the Bot to get an approval of PRs. It helps to protect master from new failures, but this requires to run RunAll tests set for each commit and this makes markable pressure to TC infra. I would like to ask you to share your ideas on how to make runAll faster, maybe you can share any of your measurements and any other info about (possible) bottlenecks. Sincerely, Dmitriy Pavlov
Re: Time to remove automated messages from the devlist?
IMO we need to run a formal vote on this change, and then PMC chair can create (or reuse) a separate list for messages from Git repos. ср, 14 нояб. 2018 г. в 16:08, Vladimir Ozerov : > Igniters, > > I would say that "set the filter" is not a solution. First, it is not > always possible technically. E.g. I use GMail and my dev-list emails are > already use a rule. I cannot extract generated emails from overall flow > with GMail capabilities. But the more important things - is why in the > first place someone needs to went through that generated nightmare? > > Git messages is a spam. Looks like everyone agrees with that. As far as > JIRA ticket creation - this is all about importance. When someone writes an > email to the devlist, this is likely to be important topic requiring > attention. When someone creates a ticket, most likely this either a bug, or > a piece of already discussed issue, or so. In other words - average devlist > user is likely to be interested in manual messages and is very unlikely to > be interested in "Ticket created" messages. Not important information > overshadows important. Let's continue disucssion this. > > As far as Git - what should be done to remove Git messages from the list? > > Vladimir. > > On Tue, Nov 6, 2018 at 6:49 PM Dmitriy Pavlov > wrote: > > > Petr, some manual digest, is probably not needed because Apache list > allows > > subscribing to digest. dev-digest-subsr...@ignite.apache.org if I > remember > > this correctly. > > > > вт, 6 нояб. 2018 г. в 18:28, Petr Ivanov : > > > > > Can be Jira notifications united in some kind of daily digest? > > > Maybe we can add special filter (new tasks / updates during last 24 > > hours) > > > with notification scheme? > > > > > > > > > > On 6 Nov 2018, at 18:15, Dmitriy Pavlov > wrote: > > > > > > > > I should mention I disagree to remove JIRA issues as the first step. > It > > > > helps everyone to understand what other people are going to do in the > > > > project. You always can comment if it is not the best approach, > find a > > > > duplicate issue, and you may suggest help. > > > > > > > > PR notification is more or less duplicates JIRA (as 1 JIRA 1..* PR), > so > > > it > > > > may be ok to move Git's messages to notificati...@ignite.apache.org > > > > > > > > > > > > But we should keep JIRA and test failures. > > > > > > > > вт, 6 нояб. 2018 г. в 17:49, Alexey Kuznetsov >: > > > > > > > >> Hi! > > > >> > > > >> I have filter for e-mail from JIRA (very useful, I can quick search > > > issue > > > >> there without visiting JIRA). > > > >> > > > >> And I'm just deleting tons of e-mails from GitBox & about PRs. > > > >> > > > >> I don't know what for we need them? > > > >> > > > >> May by we try to move GitBox & PRs-related mails first and see how > it > > > goes? > > > >> > > > >> -- > > > >> Alexey Kuznetsov > > > >> > > > > > > > > >
[jira] [Created] (IGNITE-10271) Document transaction labels
Vladimir Ozerov created IGNITE-10271:
Summary: Document transaction labels
Key: IGNITE-10271
URL: https://issues.apache.org/jira/browse/IGNITE-10271
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Vladimir Ozerov
Assignee: Artem Budnikov
Added in IGNITE-9274. Label can be defined for transaction, which is then
passed to cache events. Needed for monitoring.
Usage:
{code}
try (Transaction tx = node.transactions().withLabel("myLabel").txStart()) {
...
}
{code}
When label is passed this way, it will be reflected in {{CacheEvent.txLabel()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4600: Ignite 9274
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4600 ---
[jira] [Created] (IGNITE-10270) MVCC: Pass transaction labels to MVCC
Vladimir Ozerov created IGNITE-10270: Summary: MVCC: Pass transaction labels to MVCC Key: IGNITE-10270 URL: https://issues.apache.org/jira/browse/IGNITE-10270 Project: Ignite Issue Type: Task Components: mvcc Reporter: Vladimir Ozerov Fix For: 2.8 Transaction labels were introduced in IGNITE-9274. Need to pass them to MVCC messages as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10269) MVCC: CacheMvccReplicatedBackupsTest fails when query over REPLICATED cache is converted to local form
Vladimir Ozerov created IGNITE-10269:
Summary: MVCC: CacheMvccReplicatedBackupsTest fails when query
over REPLICATED cache is converted to local form
Key: IGNITE-10269
URL: https://issues.apache.org/jira/browse/IGNITE-10269
Project: Ignite
Issue Type: Task
Components: mvcc, sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Steps to reproduce:
1) Remove MVCC check from {{GridSqlQueryParser.isLocalQuery}}
2) Run {{CacheMvccReplicatedBackupsTest}}
Need to investigate why test fails.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10268) Remove documentation about "replicatedOnly" flag
Vladimir Ozerov created IGNITE-10268: Summary: Remove documentation about "replicatedOnly" flag Key: IGNITE-10268 URL: https://issues.apache.org/jira/browse/IGNITE-10268 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 SqlQuery.replicatedOnly and SqlFieldsQuery.replicatedOnly flags were deprecated. Need to remove all places where it is mentioned from docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10267) Deprecate "replicatedOnly" flag in thin clients
Vladimir Ozerov created IGNITE-10267:
Summary: Deprecate "replicatedOnly" flag in thin clients
Key: IGNITE-10267
URL: https://issues.apache.org/jira/browse/IGNITE-10267
Project: Ignite
Issue Type: Task
Components: sql, thin client
Reporter: Vladimir Ozerov
Fix For: 2.8
{{SqlQuery.replicatedOnly}} and {{SqlFieldsQuery.replicatedOnly}} flags were
deprecated. Need to do the same for thin clients.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #5373: IGNITE-6295
Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/5373 ---
Re: proposed design for thin client SQL management and monitoring (view running queries and kill it)
Denis, The idea is that QueryDetailMetrics will be exposed through separate "historical" SQL view in addition to current API. So we are on the same page here. As far as query ID I do not see any easy way to operate on a single integer value (even 64bit). This is distributed system - we do not want to have coordination between nodes to get query ID. And coordination is the only possible way to get sexy "long". Instead, I would propose to form ID from node order and query counter within node. This will be (int, long) pair. For use convenience we may convert it to a single string, e.g. "[node_order].[query_counter]". Then the syntax would be: KILL QUERY '25.1234'; // Kill query 1234 on node 25 KILL QUERY '25.*; // Kill all queries on the node 25 Makes sense? Vladimir. On Wed, Nov 14, 2018 at 1:25 PM Denis Magda wrote: > Yury, > > As I understand you mean that the view should contains both running and > > finished queries. If be honest for the view I was going to use just > queries > > running right now. For finished queries I thought about another view with > > another set of fields which should include I/O related ones. Is it works? > > > Got you, so if only running queries are there then your initial proposal > makes total sense. Not sure we need a view of the finished queries. It will > be possible to analyze them through the updated DetailedMetrics approach, > won't it? > > For "KILL QUERY node_id query_id" node_id required as part of unique key > > of query and help understand Ignite which node start the distributed > query. > > Use both parameters will allow cheap generate unique key across all > nodes. > > Node which started a query can cancel it on all nodes participate nodes. > > So, to stop any queries initially we need just send the cancel request to > > node who started the query. This mechanism is already in Ignite. > > > Can we locate node_id behind the scenes if the user supplies query_id only? > A query record in the view already contains query_id and node_id and it > sounds like an extra work for the user to fill in all the details for us. > Embed node_id into query_id if you'd like to avoid extra network hops for > query_id to node_id mapping. > > -- > Denis > > On Wed, Nov 14, 2018 at 1:04 AM Юрий wrote: > > > Denis, > > > > Under the hood 'time' will be as startTime, but for system view I planned > > use duration which will be simple calculated as now - startTime. So, > there > > is't a performance issue. > > As I understand you mean that the view should contains both running and > > finished queries. If be honest for the view I was going to use just > queries > > running right now. For finished queries I thought about another view with > > another set of fields which should include I/O related ones. Is it works? > > > > For "KILL QUERY node_id query_id" node_id required as part of unique key > > of query and help understand Ignite which node start the distributed > query. > > Use both parameters will allow cheap generate unique key across all > nodes. > > Node which started a query can cancel it on all nodes participate nodes. > > So, to stop any queries initially we need just send the cancel request to > > node who started the query. This mechanism is already in Ignite. > > > > Native SQL APIs will automatically support the futures after implementing > > for thin clients. So we are good here. > > > > > > > > вт, 13 нояб. 2018 г. в 18:52, Denis Magda : > > > > > Yury, > > > > > > Please consider the following: > > > > > >- If we record the duration instead of startTime, then the former > has > > to > > >be updated frequently - sounds like a performance red flag. Should > we > > > store > > >startTime and endTime instead? This way a query record will be > updated > > >twice - when the query is started and terminated. > > >- In the IEP you've mentioned I/O related fields that should help to > > >grasp why a query runs that slow. Should they be stored in this > view? > > >- "KILL QUERY query_id" is more than enough. Let's not add "node_id" > > >unless it's absolutely required. Our queries are distributed and > > > executed > > >across several nodes that's why the node_id parameter is redundant. > > >- This API needs to be supported across all our interfaces. We can > > start > > >with JDBC/ODBC and thin clients and then support for the native SQL > > APIs > > >(Java, Net, C++) > > >- Please share examples of SELECTs in the IEP that would show how to > > >find long running queries, queries that cause a lot of I/O troubles. > > > > > > -- > > > Denis > > > > > > On Tue, Nov 13, 2018 at 1:15 AM Юрий > > wrote: > > > > > > > Igniters, > > > > > > > > Some comments for my original email's. > > > > > > > > The proposal related to part of IEP-29 > > > > < > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring > > > > > > > > > . > > > > > > > > What purpose are we
Re: control.sh: a bug or feature?
I think this is definitely a bug. From our experience with millions of other utilities we know, that relative order of parameters with "-" or "--" prefixes against each other doesn't matter. This is what users will expect from our utility too. On Thu, Nov 15, 2018 at 11:05 AM mshonich wrote: > Hello, Igniters! > > AI 2.6 has added `--cache idle_verify command` to control.sh. > > Upcoming changes in 2.7 would add some optional arguments, specifically > `--dump`. Also, all `control.sh` commands, including `--cache`, have > optional connection arguments like, e.g. `--host`, `--port`. > > During testing I found that order of optional arguments is crucial to > success. > > In other words, this command works as expected: > > ``` > bin/control.sh --host 172.25.1.14 --cache idle_verify --dump > ``` > > while this command miserably fails: > ``` > bin/control.sh --cache idle_verify --host 172.25.1.14 --dump > ``` > > I consider this a behaviour unexpected to user and filed an issue to > improve > > https://ggsystems.atlassian.net/browse/IGN-12325 > > Later on, during personal discussion with developer, we argue whether this > is actually a bug from user experience point of view or not, so I would > like to ask your help voting for whether this should be fixed or not. > > --- > Thanks in advance, > Max >
control.sh: a bug or feature?
Hello, Igniters! AI 2.6 has added `--cache idle_verify command` to control.sh. Upcoming changes in 2.7 would add some optional arguments, specifically `--dump`. Also, all `control.sh` commands, including `--cache`, have optional connection arguments like, e.g. `--host`, `--port`. During testing I found that order of optional arguments is crucial to success. In other words, this command works as expected: ``` bin/control.sh --host 172.25.1.14 --cache idle_verify --dump ``` while this command miserably fails: ``` bin/control.sh --cache idle_verify --host 172.25.1.14 --dump ``` I consider this a behaviour unexpected to user and filed an issue to improve https://ggsystems.atlassian.net/browse/IGN-12325 Later on, during personal discussion with developer, we argue whether this is actually a bug from user experience point of view or not, so I would like to ask your help voting for whether this should be fixed or not. --- Thanks in advance, Max
