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

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. > > > > According to JCache 1.0 a

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

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. > > > It wil

Re: Upgrading Ignite to JCache 1.1

t 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

it to continue jcache 1.1 support >> implementation? >> > > > > > > >> > > > > > > I think Alexandex can proceed with current profile and change >> it to run >> > > > > > > tests for JCach

Re: Upgrading Ignite to JCache 1.1

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

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

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, Александр Меньшиков < >> sharple...@gmail.com> wrote: >&g

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

Re: Upgrading Ignite to JCache 1.1

Thanks, Slava. You are right. 2018-05-23 14:00 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>: > 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:

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

Re: Tests coverage report of Ignite 2.5 core module

t; Sincerely, > Dmitriy Pavlov > > пн, 14 мая 2018 г. в 20:48, Александр Меньшиков <sharple...@gmail.com>: > > > Vyacheslav, > > I have made a simple ranking for your data for highlighting classes which > > more than other needs testing. > > > > Plea

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 :

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:

Re: Optimize GridLongList serialization

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

Re: Ticket review checklist

> >> > process, > > >> > > > > > > >> > > > > when > > >> > > > > > reviewer might want to ask contributor to fix something. > > >> Checklist > > >> > is a > > >> >

Re: Optimize GridLongList serialization

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

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

+ Anton Vinogradov 2018-04-27 17:40 GMT+03:00 Александр Меньшиков <sharple...@gmail.com>: > 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

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

Re: Ticket review checklist

t; > > to > > > > > user-list with an issue in the code. > > > > > > > > > > > > > > > On Fri, Apr 20, 2018 at 7:06 PM, Dmitry Pavlov < > > dpavlov@gmail.com> > > > > > wrote: &

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

Re: Optimize GridLongList serialization

вт, 27 мар. 2018 г. в 3:06, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > Thanks, Alex. > > > > > > GridGain automatically compresses all the internal types. Somehow it > > looks > > > like the GridLongList may have been mixed. Can you plea

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

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_IgniteTests24Java8=pull%2F3515%2Fhead CR:

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

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`

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 Александр Меньшиков <sharple...@gmail.com>: > Igniters, > > I’ve implemented new fast

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

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

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

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

) GridCacheNearTxForceKeyTest 2) CrossCacheTxRandomOperationsTest They all passed in a single running. 2017-06-29 15:31 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > Alex, can you please share a test that demonstrates the hang? > > --Yakov > > 2017-06-29 14:27 GMT+03:00 Алексан

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

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 Александр Меньшиков <sharple...@gmail.com>: > Alexey, > > I'm ready to make some conclusions. You can see result immediately here: > PR: https://github.com/apache/ignite/pull/1537/files

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;

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

Re: Unused argument in DirectMessageWriter

@gmail.com>: > > > Hi, > > > > 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 T

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

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 Mon, Mar 13, 20

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

er, then I will close issue. 2017-03-01 14:55 GMT+03:00 Александр Меньшиков <sharple...@gmail.com>: > 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 > l

Re: IGNITE-603

test still relevant for the compute grid? > > > > — > > Denis > > > > > On Feb 13, 2017, at 5:45 AM, Александр Меньшиков <sharple...@gmail.com > > > > wrote: > > > > > > 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-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

e > 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 > some ti

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

resFlag == ERR > > should 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, Александр Меньшиков <sharple...@gmail

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 Александр Меньшиков <sharple...@gmail.com>: > Done. > > PR inside: > https://issues.apache.org/jira/browse/IGNITE-824 > > > 2017-02-21 13:04 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>

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 Александр Меньшиков <sharple...@gmail.com>: > We can check "onDone" method was called with using getState() method. If > getState()!=0 then resFlag!=0. Just lo

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 <yzhda...@apache.org>: > Alexander, you can remove the test and resolve the issue. > > --Yakov > > 2017-02-20 17:43 GMT+03:00 Александр Меньшиков <sharple...@gmail

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()

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

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 Александр Меньшиков <sharple...@gmail.com>: > Like I said, if "resFlag==0" (of course 0 came from initializatio

Re: IGNITE-4713 : refactoring of GridFinishedFuture and GridFutureAdapter

resFlag will be initiated as 0 (new GridFutureAdapter()), but > 1 and 2 states will be acquired on live. > > > On Fri, Feb 17, 2017 at 1:56 PM, Александр Меньшиков <sharple...@gmail.com > > > wrote: > > > Alexey, > > > > I see only one place where writes in resFlag:

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 res

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,

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

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 Александр Меньшиков <sharple...@gmail.com>: > Done. Please look. > > JIRA: https://issues.apache.org/jira/browse/IGNITE-4501 > PR: https://github.com/apache/igni

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

Denis Magda <dma...@apache.org> wrote: > > > >> Yakov, Sam? > >> > >> Please join and share your thoughts. > >> > >> — > >> Denis > >> > >>> On Feb 10, 2017, at 7:08 AM, Александр Меньшиков <sharple...@gmail.com >

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

t; Sam*, do we still need this test? > > > On Feb 9, 2017, at 6:25 AM, Александр Меньшиков <sharple...@gmail.com> > wrote: > > > > Hello, everyone. > > > > GridCacheOffHeapTest is about the Off-heap benchmarks. > > > > As I understand it righ

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,

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

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

iate exception > 3) When CacheTopologyException 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 n

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 Александр Меньшиков <sharple...@gmail.com>: > Okay, I created issue: > https://issues.apache.org/jira/browse/IGNITE-4612 > > >

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

eTopologyException 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

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

rtain places 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

Re: Unused variables in code

> ignored > 3) Remove unused variables > 4)... > 5) PROFIT :) > > On Tue, Jan 24, 2017 at 9:46 PM, Александр Меньшиков <sharple...@gmail.com > > > wrote: > > > Hello, everyone! > > > > I found some unused variables in code. For example: > > > &g

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

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

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

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

Re: IGNITE-4487 - NPE on query execution

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

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

should fail with an exception. > > 2016-12-28 22:06 GMT+03:00 Denis Magda <dma...@apache.org>: > > > Alexander, added you to the contributors list. Please check that you can > > assign the ticket on yourself. > > > > — > > Denis > > > > >

Re: IGNITE-4487 - NPE on query execution

e race when a > cache is being 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, Александр Мень

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

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

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

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

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

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

t; I think it is a great idea. > > > > > > > > I suggest to build communications between nodes on weight (or > > priority). > > > > > > > > For example, ordering on latency: > > > > - nodes on one host = 1 > > > > - nodes in

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,

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

physical location 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, Александр Меньшиков <sharple...@gmail.com

Re: Hello

I want to contribute. 2016-11-23 13:04 GMT+03:00 Vladislav Pyatkov <vpyat...@gridgain.com>: > 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, Алексан