Re: JCache 1.1: IGNITE-8715 Problems with Closeable objects from Factory

is the issues with obvious decision you describe? > > В Чт, 21/06/2018 в 17:48 +0300, Александр Меньшиков пишет: > > Hi, Igniters! > > Can someone give me advice about IGNITE-8715 [1]? > > It's a part of IEP-21 [2] about updating to JCache 1.1. > > > > Accor

JCache 1.1: IGNITE-8715 Problems with Closeable objects from Factory

Hi, Igniters! Can someone give me advice about IGNITE-8715 [1]? It's a part of IEP-21 [2] about updating to JCache 1.1. According to JCache 1.0 and 1.1 specifications Cache#close() should clean up all Closeable objects (CacheLoader, CacheWriter, CacheEntryListener, ExpiryPolicy) created by factori

Re: Upgrading Ignite to JCache 1.1

ttps://cwiki.apache.org/confluence/display/IGNITE/IEP- > 21%3A+JCache+1.1+support > > > > чт, 14 июн. 2018 г. в 12:48, Александр Меньшиков : > > > > > Igniters, > > > > > > I've prepared IEP-21 [1] for this JCache updating task. > > > I

Re: Upgrading Ignite to JCache 1.1

1 test suite altogether. > > > > D. > > > > On Tue, Jun 5, 2018 at 11:13 AM, Александр Меньшиков < > sharple...@gmail.com > > > > > wrote: > > > > > Okay. There are tests results: > > > > > > https://ci.ignite.apache.org/

Re: Upgrading Ignite to JCache 1.1

ew profile [1]. >> > > > > > > Is it required to have it to continue jcache 1.1 support >> implementation? >> > > > > > > >> > > > > > > I think Alexandex can proceed with current profile and change >> it to run >> > > &g

Re: Upgrading Ignite to JCache 1.1

GNITE-8687 [2]PR: https://github.com/apache/ignite/pull/4114/files [3]CI: https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull/4114/head&tab=buildTypeStatusDiv 2018-05-23 14:31 GMT+03:00 Александр Меньшиков : > Thanks, Slav

Re: IGNITE-8238 - Operation can fails with unexpected RuntimeException when node is stopping

t; context to the subject. This will improve the level of engagement from the >> community. >> >> I have changed the subject of this thread, let's continue the discussion >> here. >> >> D. >> >> On Tue, May 29, 2018 at 9:10 AM, Александр Меньшиков <

IGNITE-8238

Hi, Andrew. You suggested continuing the discussion on dev-list about IGNITE-8238 [1] I have reworked my PR [2]. Have I moved in the right direction? I see 57 usages of `checkpointReadLock` in the core module (without tests). And it still unclear for me should I catch all exceptions from `checkpo

Re: Upgrading Ignite to JCache 1.1

Thanks, Slava. You are right. 2018-05-23 14:00 GMT+03:00 Vyacheslav Daradur : > Hi, Alex! > > Please have a look at maven profile named "jcache-tck". > > I believe this is what you are looking for. > > On Wed, May 23, 2018 at 11:50 AM, Александр Меньшиков >

Re: Upgrading Ignite to JCache 1.1

Igniters, I think I can do it. As I see we already have JCache TCK tests in TC. Can I take somewhere settings/script which we are using? 2018-05-23 2:58 GMT+03:00 Dmitriy Setrakyan : > Igniters, > > It will be great if someone in the community would pick this up. The amount > of changes are minim

Re: Tests coverage report of Ignite 2.5 core module

ink about some other parameters or filtering -- let me know. 2018-05-14 20:54 GMT+03:00 Dmitry Pavlov : > Hi Alexander, > > I did not quite understand how this list of top tests was obtained. It does > not look like sorted. > > Can you clarify? > > Sincerely, > Dmitriy P

Re: Tests coverage report of Ignite 2.5 core module

Vyacheslav, I have made a simple ranking for your data for highlighting classes which more than other needs testing. Please take a look at the list which I have done (36 classes): https://drive.google.com/file/d/1RJrtnN77MeEWLTShFzqaLInCdOSb9WdC/view?usp=sharing Below you can read how did it in

Re: Tests coverage report of Ignite 2.5 core module

Hi Vyacheslav, Great job! I specifically happy to see jacoco.csv file into the archive. I think I can range classes by some complex criterion, like coverage/complexity. That classes could be the first in the queue for testing. 2018-05-14 17:49 GMT+03:00 Vyacheslav Daradur : > TestSuites weren't

IGNITE-6430 (Done) CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails periodically

Hi, I have fixed problem with the test CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime. Please review and merge if okay. P.S. Aleksey Plekhanov already approved it (see Jira). JIRA: https://issues.apache.org/jira/browse/IGNITE-6430 PR: https://github.com/apache/ignite/pull/3914

Re: Optimize GridLongList serialization

Pavlov > > пн, 7 мая 2018 г. в 11:30, Александр Меньшиков : > > > Hi. > > I have finished this task. Just replaced > > > > `writer.writeLongArray("arr", arr)` > > with > > `writer.writeLongArray("arr", arr, idx)` > > > > Please re

Re: Ticket review checklist

> > > when > > >> > > > > > reviewer might want to ask contributor to fix something. > > >> Checklist > > >> > is a > > >> > > > > > different thing - this is a set of rules which must be > > followed >

Re: Optimize GridLongList serialization

ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll&branch_IgniteTests24Java8=pull%2F3748%2Fhead&tab=buildTypeStatusDiv 2018-03-27 11:50 GMT+03:00 Александр Меньшиков : > The ticket is created: > https://issues.apache.org/jira/browse/IGNITE-8054 > > 2018

Re: Looks like a bug in ServerImpl.joinTopology()

+ Anton Vinogradov 2018-04-27 17:40 GMT+03:00 Александр Меньшиков : > Yakov, thank you for the advice. > > The thread.sleep is not enough, but some latch + future give me a way to > the > reproducer. > > I have created PR [1] into my master, for showing a test and modificat

Re: Looks like a bug in ServerImpl.joinTopology()

Yakov, thank you for the advice. The thread.sleep is not enough, but some latch + future give me a way to the reproducer. I have created PR [1] into my master, for showing a test and modification of ServerImpl which help me to slow down execution inside a danger section. A code of test a bit lon

Re: Ticket review checklist

should be > > > > reflected > > > > > in the code. > > > > > > > > > > 3) Logging. > > > > > Logging should be enough to troubleshoot the problem if someone > comes > > > to > > > > > user-list with an issue

Re: Ticket review checklist

4) Metrics. partially +1 It makes sense to have some minimal code coverage for new code in PR. IMHO. Also, we can limit the cyclomatic complexity of the new code in PR too. 6) Refactoring -1 I understand why people want to refactor old code. But I think refactoring should be always a separate t

Re: Optimize GridLongList serialization

> > Thanks, Alex. > > > > > > GridGain automatically compresses all the internal types. Somehow it > > looks > > > like the GridLongList may have been mixed. Can you please file a ticket > > for > > > 2.5 release? > > > > > > D

Optimize GridLongList serialization

I investigated network loading and found that a big part of internal data inside messages is `GridLongList`. It is a part of `GridDhtTxFinishRequest`, `GridDhtAtomicDeferredUpdateResponse`, `GridDhtAtomicUpdateRequest`, `GridNearAtomicFullUpdateRequest` and `NearCacheUpdates`. So I think it has th

Ignite-7640 Refactor DiscoveryDataClusterState to be immutable (Done)

Hi to all. I have done issue ignite-7640. Please review. JIRA: https://issues.apache.org/jira/browse/IGNITE-7640 PR: https://github.com/apache/ignite/pull/3515 TC: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&branch_IgniteTests24Java8=pull%2F3515%2Fhead CR: https://rev

Re: Wrapping [Ignite]Interrupted[Checked]Exception in benign exceptions

Ilya, I agree with you about reducing the number of unchecked exceptions in public API. Because when you work with grid it can throw about 4 types of different runtime exception. And there is no way except experiments to know about this types. 2018-02-15 15:57 GMT+03:00 Dmitriy Setrakyan : > Ilya

Looks like a bug in ServerImpl.joinTopology()

Hello. I saw such code in `ServerImpl.joinTopology()` locNode.order(1); locNode.internalOrder(1); spi.gridStartTime = U.currentTimeMillis(); locNode.visible(true); ring.clear(); ring.topologyVersion(1); And it looks like a bug because the `locNode` is contained inside the `ring` (`TcpDis

Re: IGNITE-4908 is ready for review (Ignite.reentrantLock looks much slower than IgniteCache.lock)

Hi, guys! I'm waiting (more than 2 months) for CR ignite-4908 ( https://issues.apache.org/jira/browse/IGNITE-4908 all links inside). It's about Ignite.reentrantlock. 2017-11-29 12:35 GMT+03:00 Александр Меньшиков : > Igniters, > > I’ve implemented new fast reentrant loc

IGNITE-6565: Use long type for size and keySize in cache metrics

I have done the task. Please review. JIRA: https://issues.apache.org/jira/browse/IGNITE-6565 PR: https://github.com/apache/ignite/pull/3130 TC: https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F3130%2Fhead UR: https://reviews.ignite.apache.org/ignite/rev

IGNITE-4908 is ready for review (Ignite.reentrantLock looks much slower than IgniteCache.lock)

Igniters, I’ve implemented new fast reentrant lock within an issue[1]. Could someone review prepared PR [2, 3, 4]? Some details are described below. The main idea: Current locks implementation is based on shared states in a cache, while the new lock uses IgniteCache#invoke* methods to update s

IGNITE-4908: Ignite.reentrantLock looks much slower than IgniteCache.lock

Hi! I need advice about the task: https://issues.apache.org/jira/browse/IGNITE-4908 Better to read about the problem in Jira because it needs a context (2 last messages). The question in the last message. Please take a look.

IGNITE-5994: IgniteInternalCache.invokeAsync().get() can return null

Hello, I found one small bug. JIRA: https://issues.apache.org/jira/browse/IGNITE-5994 The problem is IgniteInternalCache.invokeAsync().get() will return null if EntryProcessor return null. But the IgniteInternalCache.invoke() will return EntryProcessorResult in the same situation (with null insid

Brand new JMH and Yardstick benchmarks

Hi, guys. I have written benchmarks for comparing IgniteCache.lock() and Ignite.reentrantLock() and they merged to master branch. If someone new wants to make benchmarks look at the implementation. Don't forget to write both JMH and Yardstick benchmarks. In process of writing, I have found out th

Re: IGNITE-4365: Data grid in deadlock on stop by DataStreamerImpl

are 2 tests: 1) GridCacheNearTxForceKeyTest 2) CrossCacheTxRandomOperationsTest They all passed in a single running. 2017-06-29 15:31 GMT+03:00 Yakov Zhdanov : > Alex, can you please share a test that demonstrates the hang? > > --Yakov > > 2017-06-29 14:27 GMT+03:00 Александр Меньшиков : &g

IGNITE-4365: Data grid in deadlock on stop by DataStreamerImpl

Hello, I want to make ticket IGNITE-4365 . The problem came from DataStreamerImpl. There are methods which use DataStreamerImpl under the lock (GridCacheGateway), but the method DataStreamerImpl#doFlush() has a "while(true)" loop. And in case when

IGNITE-4908

Hello, Andrew! What do you think about create sub task for IGNITE-4908 about creating benchmark which highlights performance problem? I think it helps us to agree about use-case which we want to test. Link on Jira: https://issues.apache.org/jira/browse/IGNITE-4908

Questions about IGNITE-4684

Hello, Igniters! Can someone clarify the crux of ignite-4684 to me? I asked some questions inside Jira's discussion. Link: https://issues.apache.org/jira/browse/IGNITE-4684 In short: 1) What implementation of the IgniteCache we are interested in? 2) What locks we are interested in?

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexey, I just remind you about issue. 2017-02-20 16:42 GMT+03:00 Александр Меньшиков : > Alexey, > > I'm ready to make some conclusions. You can see result immediately here: > PR: https://github.com/apache/ignite/pull/1537/files > CI Tests: http://ci.ignite.apa

Re: Real size of a stored data in IgniteCache

Vyacheslav, Objects have different size in different runtime (x86 or Power, compress pointer on or off and so on). So only one possible way to see real size is do it in runtime. You can see how many bytes was allocated in one thread by using import *com.sun.management*.ThreadMXBean; ThreadMXB

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Yakov, can I take this ticket or you have already started to implement it? Ask because you are an assignee in JIRA. 2017-03-07 22:21 GMT+03:00 Denis Magda : > Good, the ticket is ready: > https://issues.apache.org/jira/browse/IGNITE-4799 < > https://issues.apache.org/jira/browse/IGNITE-4799> > >

Re: Unused argument in DirectMessageWriter

; > > These classes are part of plugin framework. Even though 'name' argument > is > > not used by Ignite implementations, it can be used by others. Therefore > it > > should not be removed. > > > > -Val > > > > On Thu, Mar 16, 2017 a

Unused argument in DirectMessageWriter

Hello, everyone! I found some strange thing. In 'MessageWriter' there are a lot of methods like 'write*(String name, * val)'. But in implementation 'DirectMessageWriter' argument 'name' isn't used in these methods. And there aren't other 'MessageWriter' implementations. Maybe we can remove 'name'

Re: Suggestion for remove ComputeJobContinuationAdapter

Okay, thank you. 2017-03-13 17:50 GMT+03:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > This class can't be removed as it's part of public API. It's a convenience > adapter that users can extend when using continuations. > > -Val > > On

Suggestion for remove ComputeJobContinuationAdapter

The abstract class "ComputeJobContinuationAdapter" is unused. There aren't any subclass. Looks we can remove it now.

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

code cleaner, then I will close issue. 2017-03-01 14:55 GMT+03:00 Александр Меньшиков : > First of all I want to replace the "byte resFlag" on the "bool haveResult" > only for aesthetic reasons. I think that use a byte as a boolean flag looks > like C in 1983. And cons

Re: IGNITE-603

gt; > 2017-02-13 23:10 GMT+03:00 Denis Magda : > > > Hi Alexander, > > > > Looks like the test is commented for a while. GridDeploymentMode has > > already been renamed to DeploymentMode. > > > > Yakov, is this test still relevant for the compute grid

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

produce > AssertionError. > > 1) 99.999% of time GridFutureAdapter#onDone() is called in some other > thread than the one which is frozen on get() > 2) What is volatile now which should not be? > > Regarding the flag - boolean and byte takes 1 byte in the object. I suppose >

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

d be more complicated... like something this: > > getState() != 0 && !resFlag and getState() != 0 && resFlag > > But unlike getState(), restFag is not volatile... > > On Tue, Feb 28, 2017 at 4:26 PM, Александр Меньшиков > wrote: > >> Alexey, Vladislav

Re: IGNITE-824: [Test] GridRandomSelfTest # testPerformance was disabled.

Yakov, please look at PR. It's simple removing. 2017-02-21 19:29 GMT+03:00 Александр Меньшиков : > Done. > > PR inside: > https://issues.apache.org/jira/browse/IGNITE-824 > > > 2017-02-21 13:04 GMT+03:00 Yakov Zhdanov : > >> Alexander, you can remove the test a

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

Alexey, Vladislav, are you agree with me, or not? I want to do it faster and move on. 2017-02-17 17:36 GMT+03:00 Александр Меньшиков : > We can check "onDone" method was called with using getState() method. If > getState()!=0 then resFlag!=0. Just look at code. > > > 2

Re: IGNITE-824: [Test] GridRandomSelfTest # testPerformance was disabled.

Done. PR inside: https://issues.apache.org/jira/browse/IGNITE-824 2017-02-21 13:04 GMT+03:00 Yakov Zhdanov : > Alexander, you can remove the test and resolve the issue. > > --Yakov > > 2017-02-20 17:43 GMT+03:00 Александр Меньшиков : > > > Do we still need this test? Can I remove it? > > >

IGNITE-824: [Test] GridRandomSelfTest # testPerformance was disabled.

Do we still need this test? Can I remove it?

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

rrect affinity > topology version here. Then, during a construction of CacheException > (unchecked, which is guaranteed to be thrown locally and will not be > serialized), you would create the retry ready future based on the topology > version set. > > Hope this helps, > AG &g

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

We can check "onDone" method was called with using getState() method. If getState()!=0 then resFlag!=0. Just look at code. 2017-02-17 17:12 GMT+03:00 Александр Меньшиков : > Like I said, if "resFlag==0" (of course 0 came from initialization) means > "you still h

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

ridFutureAdapter()), but > 1 and 2 states will be acquired on live. > > > On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков > > wrote: > > > Alexey, > > > > I see only one place where writes in resFlag: > > > > if (err !=

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

legalStateException if condition is false, because right now developer will not get clear error massage. 17 февр. 2017 г. 11:34 пользователь "Alexey Goncharuk" < alexey.goncha...@gmail.com> написал: Alexander, This change is not applicable for GridFutureAdapter because resFlag can

IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

Hello. I propose to do refactoring of classes "GridFinishedFuture" and "GridFutureAdapter". There is field "resFlag" which can equals "ERR = 1" or "RES = 2". So I can replace it to one "bool haveResult" field. If there are no objections, I'm ready to proceed. If you find more such classes, please

IGNITE-1624: [Test failed] Ignite SPI: TcpClientDiscoverySpiSelfTest.testJoinError failed

Hello. I try to fix test. But can't reproduce problem. I added reps in a loop and ran test local 10 minutes. There aren't problem. After that I set 1500 reps and ran on CI (my local machine can do 1900 reps in 5 minutes) and got timeout, but not the origin problem from issue. Anyone have any idea

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

Need to do code review until February 17, if we want to get this feature in version 1.9. 2017-02-08 22:14 GMT+03:00 Александр Меньшиков : > Done. Please look. > > JIRA: https://issues.apache.org/jira/browse/IGNITE-4501 > PR: https://github.com/apache/ignite/pull/1436/files &

Re: IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

Done. PR: https://github.com/apache/ignite/pull/1527 I just ran the tests : http://ci.ignite.apache.org/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull/1527/head 2017-02-14 12:36 GMT+03:00 Александр Меньшиков : > Yep, i will do it immediately > >

Re: IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

> Yakov, Sam? > >> > >> Please join and share your thoughts. > >> > >> — > >> Denis > >> > >>> On Feb 10, 2017, at 7:08 AM, Александр Меньшиков > > >> wrote: > >>> > >>> Denis, thank you f

IGNITE-603

Hello, everyone. I think the commented-out method "processSize2Test" can be removed. There aren't class "GridDeploymentMode" which used in arguments. Do you agree with me?

Re: IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

ing-Simplification-and-Automation-td13079.html < > http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-4212-Ignite- > Benchmarking-Simplification-and-Automation-td13079.html> > > As for GridCacheOffHeapTest it looks like a candidate for removal. *Yakov, > Sam*, do we sti

IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

Hello, everyone. GridCacheOffHeapTest is about the Off-heap benchmarks. As I understand it right now we haven't clear vision how better make benchmarks in Ignite. If it's not true, please make me know. I think it's a good idea to make benchmarks with JMH framework. It can be load with maven, r

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

Done. Please look. JIRA: https://issues.apache.org/jira/browse/IGNITE-4501 PR: https://github.com/apache/ignite/pull/1436/files Tests: http://ci.ignite.apache.org/project.html?projectId=IgniteTes ts&tab=projectOverview&branch_IgniteTests=pull/1436/head

Re: Test failures

+1 to Aleksey, Alexander and Vyacheslav. I suppose that the best option is make issue for every master-failed-test. And fix them all. Floating tests should be normal. I think in most case we can just add repeating. All new test for some not ready future should be marked like "Should be fix in IG

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Exception is being constructed, create a corresponding > local future based on wait version and throw the exception. > > Even though this still does not give us 100% guarantee that we did not miss > anything, it should cover a lot more cases than now. > > 2017-01-30 14:20 GMT+03:00 А

Re: Unused variables in code

And result of testing: http://ci.ignite.apache.org/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull/1466/head 2017-01-30 18:39 GMT+03:00 Александр Меньшиков : > Done. > > My PR: > https://github.com/apache/ignite/pull/1466/files > <https:

Re: Unused variables in code

Done. My PR: https://github.com/apache/ignite/pull/1466/files <https://github.com/apache/ignite/pull/1466> 2017-01-25 13:11 GMT+03:00 Александр Меньшиков : > Okay, I created issue: > https://issues.apache.org/jira/browse/IGNITE-4612 > > > 2017-01-24 18:19 GMT+03:00 Alex

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

nstructed, create a corresponding > local future based on wait version and throw the exception. > > Even though this still does not give us 100% guarantee that we did not miss > anything, it should cover a lot more cases than now. > > 2017-01-30 14:20 GMT+03:00 Александр Меньш

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

aces in the code where we already know what to wait for. > I do not see how you can initialize this future, for example, in > GridCacheIoManager#sendNoRetry(ClusterNode node, GridCacheMessage msg, > byte > plc) > > --AG > > 2017-01-27 15:45 GMT+03:00 Александр Меньшиков : >

IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

I found a lot of using "ClusterTopologyCheckedException" exception. In most use-case these exceptions were just ignored. It's easier to see if issue-4612 will be applied (I'm waiting for code review by my team leader) where I renamed all unused exceptions in the "ignored". It means that in some ca

Re: Unused variables in code

ariables > 4)... > 5) PROFIT :) > > On Tue, Jan 24, 2017 at 9:46 PM, Александр Меньшиков > > wrote: > > > Hello, everyone! > > > > I found some unused variables in code. For example: > > > > Unnecessary argument in method > > MiniFutur

Unused variables in code

Hello, everyone! I found some unused variables in code. For example: Unnecessary argument in method MiniFuture#onResult(ClusterTopologyCheckedException e) in inner class of GridDhtLockFuture. There isn't another onResult() method (in super class including) with another behavior. So argument can

IGNITE-4364: DML: AssertionError: Row@ ... null 5 -> mapcol_asc_idx

Hello, Sergey and other. I followed the instruction in issue description and I didn't get AssertionError, but got exception looks like in issue in "Caused by" part. I attached exception part of my logs in JIRA like file "Ubuntu_OpenJDK_1.8.111.txt" (name is my configuration).

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

Igor, I have thought about approach what you are talking about. It need add new field named like "sortedNodes" with custom ordering, which will have the same items as "nodes" field, because "nodes" has being used with default ordering in other methods. It have this advantages: 1. Method "nextNode"

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

Yakov, I changed the implementation. Please, look at my code again. https://github.com/apache/ignite/pull/1436 2017-01-19 15:37 GMT+03:00 Yakov Zhdanov : > Alexander, as far as I remember we talked about having cluster id set via > TcpDiscoverySpi configuration and also via system property. > >

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

Yakov, as I understand it we need add CLUSTER_REGION_ID for each nodes in config file. And in fact using some kind of sort in nextNode method (the search for extreme values to be exact). And the existence of valid comparator is a sufficient condition to sort nodes to build new correct ring. So I ha

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

I done that things: -- Add to TcpDiscoverySpi field Comparator nodeComparator for load custom comparators from config file like bean. -- Add implementation with old behavior: BaseNodeComparator -- Add region id implementation: RegionNodeComparator which get map from IP address to region ID in cons

Re: IGNITE-4487 - NPE on query execution

t; > https://cwiki.apache.org/confluence/display/IGNITE/How+ > to+Contribute#HowtoContribute-1.CreateGitHubpull-request> > > — > Denis > > > On Dec 29, 2016, at 3:45 AM, Александр Меньшиков > wrote: > > > > Alexey, I'm already make pull request whe

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

I think that in the weeks after the 'new year' holidays or sooner. 2016-12-29 13:28 GMT+03:00 Yakov Zhdanov : > Guys, I have updated the ticket. > > Alexander Menshikov, when do you expect the implementation to be finished? >

Re: IGNITE-4487 - NPE on query execution

; > 2016-12-28 22:06 GMT+03:00 Denis Magda : > > > Alexander, added you to the contributors list. Please check that you can > > assign the ticket on yourself. > > > > — > > Denis > > > > > On Dec 28, 2016, at 2:15 AM, Александр Меньшиков > &

Re: IGNITE-4487 - NPE on query execution

stopped and there are still scan queries running in > parallel. So, in general it’s not about data loss. > > Sam, Alex G., could you share your thoughts in regards to the proper fix? > > — > Denis > > > On Dec 26, 2016, at 2:43 AM, Александр Меньшиков > wrote: &

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

My JIRA account is: Username:sharplerFull Name:Alexander Menshikov 2016-12-27 17:22 GMT+03:00 Александр Меньшиков : > Yes, i can. But someone needs to give me the rights of contributor in Jira. > > 2016-12-27 17:07 GMT+03:00 Vyacheslav Daradur : > >> I have descr

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

Yes, i can. But someone needs to give me the rights of contributor in Jira. 2016-12-27 17:07 GMT+03:00 Vyacheslav Daradur : > I have described a task: https://issues.apache.org/jira/browse/IGNITE-4501 > > and linked a bug https://issues.apache.org/jira/browse/IGNITE-4499 > > Alex Menshikov, maybe

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

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: 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

; > > > I suggest to build communications between nodes on weight (or > > priority). > > > > > > > > For example, ordering on latency: > > > > - nodes on one host = 1 > > > > - nodes in one rack-blade = 2 > > > > - nodes in on

Re: [jira] [Created] (IGNITE-4487) NPE on query execution

I found that: in inner class 'GridCacheQueryAdapter.ScanQueryFallbackClosableIterator' in constructor is called with method 'init()', but method 'init()' cannot be called with an empty field 'nodes'. In source code it looks like: private ScanQueryFallbackClosableIterator(int part, GridCacheQueryA

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

Hello everyone, As far as I know nodes are connected in a ring. For example if i have 6 nodes, with names A, B, C, D, E, and F they can connect in ring any possible way: A-B-C-D-E-F-A, or A-F-B-E-C-D-A, etc. And if some node falls out of topology neighboring nodes must reconnect. If nodes A,B and

Re: Hello

while the rest in the others. > > [1] https://ignite.apache.org/releases/1.7.0/javadoc/org/ > apache/ignite/cache/affinity/rendezvous/RendezvousAffinityFunction.html > > — > Denis > > On Dec 20, 2016, at 7:02 AM, Александр Меньшиков > wrote: > > I think in near time

Re: Hello

I want to contribute. 2016-11-23 13:04 GMT+03:00 Vladislav Pyatkov : > Hi Alex, > > This is Apache Ignite development community. > Are you want to contribute to Ignite or you are have any suggestion? > > On Wed, Nov 23, 2016 at 12:41 PM, Александр Меньшиков < > sharp

Hello

Hello