Re: Sort nodes in the ring in order to minimize the number of reconnections

>> My main concern here is code complexity. Yakov, how difficult it is to stick a new node in an arbitrary spot of a discovery ring? >> Dmitry, I think this is not hard. At least I don't see any issue now. >> I think the NodeComparator approach will work. User can chose how to sort nodes from one

[jira] [Created] (IGNITE-4496) Review all logging for sensitive data leak

Alexandr Kuramshin created IGNITE-4496: -- Summary: Review all logging for sensitive data leak Key: IGNITE-4496 URL: https://issues.apache.org/jira/browse/IGNITE-4496 Project: Ignite Issue

Re: EXPLAIN for DML statements

I agree. I also would very much like to see the support of "Explain" for DML statements. Is there some limitation in H2 that prevents us from supporting it? On Fri, Dec 23, 2016 at 10:36 AM, Denis Magda wrote: > This might be a tricky part for the users because they need to recreate > the query

Re: DML Documentation Readiness

On Fri, Dec 23, 2016 at 10:40 AM, Denis Magda wrote: > The URL will be the same as the name of the page which is “Performance and > Debugging”. I wouldn’t not rename the page because it’s already located > under “SQL Grid” section. However, even if we rename the page the URL will > be left the sa

Re: Striped pool configuration

On Mon, Dec 26, 2016 at 2:08 AM, Yakov Zhdanov wrote: > Dmitry, for example, running queries from old fashioned pool seems to > perform better, but short-term cache updates perform better when run on > striped pool. > Do we know why? It seems like a mystery to me.

Re: Sort nodes in the ring in order to minimize the number of reconnections

I think the NodeComparator approach will work. User can chose how to sort nodes from one rack before nodes from another rack. Same goes for subnets, or data centers. My main concern here is code complexity. Yakov, how difficult it is to stick a new node in an arbitrary spot of a discovery ring? D

Re: Sort nodes in the ring in order to minimize the number of reconnections

Of course where is no need to sort all nodes. It's enough just to select smallest node. 2016-12-26 22:29 GMT+03:00 Alexei Scherbakov : > Yakov, > > ARC_ID approach seems just a variation of node attribute based ordering > for me. > > I suggest more generic approach. > > What if we define node or

Re: Sort nodes in the ring in order to minimize the number of reconnections

Yakov, ARC_ID approach seems just a variation of node attribute based ordering for me. I suggest more generic approach. What if we define node ordering using something like NodeComparator? Then a new node joins topology, it calculates node for joining using sorting on current topology + new nod

[jira] [Created] (IGNITE-4495) .NET: Support user-defined identity resolvers

Pavel Tupitsyn created IGNITE-4495: -- Summary: .NET: Support user-defined identity resolvers Key: IGNITE-4495 URL: https://issues.apache.org/jira/browse/IGNITE-4495 Project: Ignite Issue Type

IGNITE-4374 - Ignite should validate JVM and OS configuration and output warning in log

I picked up https://issues.apache.org/jira/browse/IGNITE-4374 I have some questions: 1. It is necessary to check a flag MaxDirectMemorySize, but there is no recommendation of it: https://apacheignite.readme.io/docs/jvm-and-system-tuning 2. Whether it is necessary to output message in "Quiet mode

[GitHub] ignite pull request #1387: IGNITE-4490 Query-less INSERT and MERGE

GitHub user alexpaschenko opened a pull request: https://github.com/apache/ignite/pull/1387 IGNITE-4490 Query-less INSERT and MERGE You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4490 Alternatively

[GitHub] ignite pull request #1386: IGNITE-4106: SQL: parallelize sql queries over ca...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1386 IGNITE-4106: SQL: parallelize sql queries over cache local partitions Tree index splitted into segmentes in GridH2StripedTreeIndex Tests added You can merge this pull request into a Git repo

[GitHub] ignite pull request #1385: IGNITE-4106: SQL: parallelize sql queries over ca...

Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/1385 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[GitHub] ignite pull request #1385: IGNITE-4016: SQL: parallelize sql queries over ca...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1385 IGNITE-4016: SQL: parallelize sql queries over cache local partitions Tree index splitted into segmentes in GridH2StripedTreeIndex Tests added You can merge this pull request into a Git repo

[GitHub] ignite pull request #1198: IGNITE-4106: SQL: parallelize sql queries over ca...

Github user AMashenkov closed the pull request at: https://github.com/apache/ignite/pull/1198 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[jira] [Created] (IGNITE-4494) .NET: Optimize ExamplesTest.TestRemoteNodes

Pavel Tupitsyn created IGNITE-4494: -- Summary: .NET: Optimize ExamplesTest.TestRemoteNodes Key: IGNITE-4494 URL: https://issues.apache.org/jira/browse/IGNITE-4494 Project: Ignite Issue Type:

Re: Sort nodes in the ring in order to minimize the number of reconnections

> Can you please explain why this is better than arc approach? We had a misunderstanding. Everything okay with arc approach. But we must choose how nodes will determine "ARC_ID", and i think it can be calculated from latency values. If users will be able to set "ARC_ID" in config file then they ca

[jira] [Created] (IGNITE-4493) ODBC: Add missing diagnostic records in case of API errors

Sergey Kalashnikov created IGNITE-4493: -- Summary: ODBC: Add missing diagnostic records in case of API errors Key: IGNITE-4493 URL: https://issues.apache.org/jira/browse/IGNITE-4493 Project: Ignite

[jira] [Created] (IGNITE-4492) Add MBean for StripedExecutor

Yakov Zhdanov created IGNITE-4492: - Summary: Add MBean for StripedExecutor Key: IGNITE-4492 URL: https://issues.apache.org/jira/browse/IGNITE-4492 Project: Ignite Issue Type: Improvement

[GitHub] ignite pull request #1384: IGNITE-4470 Added support for log file configurat...

GitHub user skalashnikov opened a pull request: https://github.com/apache/ignite/pull/1384 IGNITE-4470 Added support for log file configuration via environmental variable IGNITE_ODBC_LOG_PATH You can merge this pull request into a Git repository by running: $ git pull https:/

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> Vyacheslav, I agree that latency increase in the way you describe, but I still don't understand how we use this information in discovery. Latency may differ from time to time depending on many factors. I still think that arc approach is more intuitive for user and easier to implement. >> Way of

Re: Make async API great again

me too. --Yakov

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> I just want to understand which benefits we get when implement what we're talking about. If major benefit is reduced latency of ring messages, then the assignment 'ARC ID' in accordance with latency value is quite enough. But if there are any hidden problems because of the large number of reconn

[GitHub] ignite pull request #1380: IGNITE-4486 Added serialVersionUID to AttributeNo...

Github user alexpaschenko closed the pull request at: https://github.com/apache/ignite/pull/1380 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> I thought of latency values. Latency between host nodes < Latency between same rack nodes < Latency between subnet nodes < etc. >> Vyacheslav, I agree that latency increase in the way you describe, but I still don't understand how we use this information in discovery. Latency may differ from t

[GitHub] ignite pull request #1383: IGNITE-3875

GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/1383 IGNITE-3875 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3875 Alternatively you can review and apply these

[jira] [Created] (IGNITE-4491) Commutation loss between two nodes leads to hang whole cluster.

Vladislav Pyatkov created IGNITE-4491: - Summary: Commutation loss between two nodes leads to hang whole cluster. Key: IGNITE-4491 URL: https://issues.apache.org/jira/browse/IGNITE-4491 Project: Ig

Re: Sort nodes in the ring in order to minimize the number of reconnections

> I am afraid I did not understand this at all. Please elaborate. I just want to understand which benefits we get when implement what we're talking about. If major benefit is reduced latency of ring messages, then the assignment 'ARC ID' in accordance with latency value is quite enough. But if the

IGNITE-4487 - NPE on query execution

Hello everyone. I want to pick up *https://issues.apache.org/jira/browse/IGNITE-4487 * as my first issue. Please add me as contributor. I already found that: in inner class 'GridCacheQueryAdapter.ScanQueryFallbackClosableIterator' in constructor

Re: Make async API great again

Answered. On Mon, Dec 26, 2016 at 12:51 PM, Yakov Zhdanov wrote: > Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480 > and https://issues.apache.org/jira/browse/IGNITE-4479 and > https://issues.apache.org/jira/browse/IGNITE-4476 > > I agree that current approach for asyn

Re: IGNITE-4464 - JclLogger ignores IGNITE_QUIET system property

Vladimir, Thanks, I will choose another issue. 2016-12-26 13:07 GMT+03:00 Vladimir Ozerov : > Hi Vyacheslav, > > I believe this issue was already resolved as a part of IGNITE-4248 [1]. > I'll close it as duplicate. Please choose another issue. I'll added you to > contributor's list. > > [1] http

Re: Striped pool configuration

Dmitry, for example, running queries from old fashioned pool seems to perform better, but short-term cache updates perform better when run on striped pool. --Yakov

Re: IGNITE-4464 - JclLogger ignores IGNITE_QUIET system property

Hi Vyacheslav, I believe this issue was already resolved as a part of IGNITE-4248 [1]. I'll close it as duplicate. Please choose another issue. I'll added you to contributor's list. [1] https://issues.apache.org/jira/browse/IGNITE-4248 Vladimir. On Mon, Dec 26, 2016 at 12:45 PM, Vyacheslav Dara

Re: Sort nodes in the ring in order to minimize the number of reconnections

>Then, as I understand it, a lot of reconnection in the ring cannot create even temporary but major problems for performance. And in general this optimization will change practically nothing. Or am I missing some things? I am afraid I did not understand this at all. Please elaborate. I did not su

Re: Make async API great again

Vladimir, I commented in https://issues.apache.org/jira/browse/IGNITE-4480 and https://issues.apache.org/jira/browse/IGNITE-4479 and https://issues.apache.org/jira/browse/IGNITE-4476 I agree that current approach for async API is not good at all and needs to be fixed. As far as callback semantics

IGNITE-4464 - JclLogger ignores IGNITE_QUIET system property

Hello everyone. I want to pick up https://issues.apache.org/jira/browse/IGNITE-4464 as my first issue. Please add me as contributor.

Re: Sort nodes in the ring in order to minimize the number of reconnections

Thank you, Denis, for your explanation. Then, as I understand it, a lot of reconnection in the ring cannot create even temporary but major problems for performance. And in general this optimization will change practically nothing. Or am I missing some things? 2016-12-26 12:20 GMT+03:00 Yakov Zhdan

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> Vyacheslav, please elaborate on how we can determine whether we are on the same rack. I am not sure this is possible in general case. Please see my suggestions below. >> I thought of latency values. Latency between host nodes < Latency between same rack nodes < Latency between subnet nodes < e

[GitHub] ignite pull request #1382: Ignite 4147 SSL misconfiguration is not handled p...

GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/1382 Ignite 4147 SSL misconfiguration is not handled properly You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-41

Re: Sort nodes in the ring in order to minimize the number of reconnections

>> For example, ordering on latency: - nodes on one host = 1 - nodes in one rack-blade = 2 - nodes in one server-rack = 3 - nodes in one physical cluster = 4 - nodes in one subnet = 5 - etc. Maybe it'll be better to use some metrics from ClusterMetrics interface. The algorithm of ordering can be

Hello

Hello, Ignite Community! My name is Alexandr. I want to contribute to Apache Ignite. Counting on your help. Thanks! -- Kind regards, Alexandr.