[jira] [Created] (IGNITE-11621) Node is stuck in "No next node in topology" infinite loop in special case.

Sergey Chugunov created IGNITE-11621: Summary: Node is stuck in "No next node in topology" infinite loop in special case. Key: IGNITE-11621 URL: https://issues.apache.org/jira/browse/IGNITE-11621

Re: Ignite 2.7.5 Release scope

Hello! It seems that I can no longer test this case, on account of TcpDiscoveryCoordinatorFailureTest#testClusterFailedNewCoordinatorInitialized hanging every time under Java 11 on Windows. Alexey, Ivan, can you please take a look? https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTes

Re: Code inspection

Igniters, The issue [1] with enabled maven-checkstyle-plugin is ready for the review. All changes are prepared according to e-mail [2] the second option point (include the plugin in the maven build procedure by default). JIRA: IGNITE-11277 [1] PR: [3] Upsource: [4] How can take a look? [1] http

Re: GridDhtInvalidPartitionException takes the cluster down

Hi Roman, I think this InvalidPartition case can be simply handled in GridCacheTtlManager.expire method. For workaround a custom FailureHandler can be configured that will not stop a node in case of such exception is thrown. пн, 25 мар. 2019 г. в 08:38, Roman Shtykh : > Igniters, > > Restarting

Re: GridDhtInvalidPartitionException takes the cluster down

Guys. We should fix the SYSTEM_WORKER_TERMINATION once and for all. Seems, we have ten or more "cluster shutdown" bugs with this subsystem since it was introduced. Should we disable it by default in 2.7.5? пн, 25 мар. 2019 г. в 13:04, Pavel Kovalenko : > Hi Roman, > > I think this InvalidParti

[jira] [Created] (IGNITE-11622) Investigate how CacheEntryRemovedException can be thrown in onEntriesLocked

Alexey Goncharuk created IGNITE-11622: - Summary: Investigate how CacheEntryRemovedException can be thrown in onEntriesLocked Key: IGNITE-11622 URL: https://issues.apache.org/jira/browse/IGNITE-11622

[jira] [Created] (IGNITE-11623) MVCC: testRebalancingDuringLoad_N tests is flacky in master

Amelchev Nikita created IGNITE-11623: Summary: MVCC: testRebalancingDuringLoad_N tests is flacky in master Key: IGNITE-11623 URL: https://issues.apache.org/jira/browse/IGNITE-11623 Project: Ignite

[jira] [Created] (IGNITE-11624) Discovery SPI: The client can handle events from the previous cluster after reconnect.

Amelchev Nikita created IGNITE-11624: Summary: Discovery SPI: The client can handle events from the previous cluster after reconnect. Key: IGNITE-11624 URL: https://issues.apache.org/jira/browse/IGNITE-11624

Re: GridDhtInvalidPartitionException takes the cluster down

If it sticks to the behavior we had before introducing failure handler, I think it's better to have disabled instead of killing the whole cluster, as in my case, and create a parent issue for those ten bugs.Pavel, thanks for the suggestion! On Monday, March 25, 2019, 7:07:20 p.m. GMT+9,

[jira] [Created] (IGNITE-11625) AffinityTopologyVersion should be changed on client connect when this client node has new statically configured cache(s).

Vyacheslav Koptilin created IGNITE-11625: Summary: AffinityTopologyVersion should be changed on client connect when this client node has new statically configured cache(s). Key: IGNITE-11625 URL: https://i

Re: GridDhtInvalidPartitionException takes the cluster down

Failure handlers were introduced in order to avoid cluster hanging and they kill nodes instead. If critical worker was terminated by GridDhtInvalidPartitionException then your node is unable to work anymore. Unexpected cluster shutdown with reasons in logs that failure handlers provide is better

Re: UriDeploymentSpi and GAR files

Folks, I prepared a patch for the second ticket: https://github.com/apache/ignite/pull/6177 Ilya is concerned, that if you had some JAR files, lying next to your GARs in a repository, which is referred to over UriDeploymentSpi, then these JARs will now be loaded as well. So, this is a behaviour ch

[jira] [Created] (IGNITE-11626) InitNewCoordinatorFuture should be reported in diagnostic output

Alexey Goncharuk created IGNITE-11626: - Summary: InitNewCoordinatorFuture should be reported in diagnostic output Key: IGNITE-11626 URL: https://issues.apache.org/jira/browse/IGNITE-11626 Project:

Re: Ignite 2.7.5 Release scope

Hi Ignite Developers, So because nobody raised any feature I would like to call for scope freeze for 2.7.5. The scope is limited with corruption fix, Java 11 issues addressed. https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.7.5 Also, launch scripts will be tested for Java 12.

Re: Ignite 2.7.5 Release scope

Guys, what do you think about disabling SYSTEM_WORKER_TERMINATION (introduced with IEP-14) before "cluster shutdown" bugs are fixed, as suggested by Nikolay I. in "GridDhtInvalidPartitionException takes the cluster down" thread? -- Roman On Tuesday, March 26, 2019, 3:41:29 a.m. GMT+9, Dmi

Re: GridDhtInvalidPartitionException takes the cluster down

Nikolay, Thanks for kicking off this discussion. Surprisingly, planned to start a similar one today and incidentally came across this thread. Agree that the failure handler should be off by default or the default settings have to be revisited. That's true that people are complaining of nodes shut

Re: Apache Ignite pluggability and extensibility in terms of security (kerberos)

http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ We found some useful resource which might help. -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Ignite 2.7.5 Release scope

Roman, I think the worst thing we can do is to hide the bug you discovered. The sane options are either fix it urgently or classify it as non-critical and postpone. вт, 26 мар. 2019 г. в 05:13, Roman Shtykh : > Guys, what do you think about disabling SYSTEM_WORKER_TERMINATION > (introduced with I

Re: Ignite 2.7.5 Release scope

Andrey, hmm, I don't think putting back the behavior (if it's safe) we used to have with all those exceptions being logged etc. is hiding. I would never propose something like that. Btw, I have fixed the issue. If it looks good let's merge. -- Roman On Tuesday, March 26, 2019, 2:46:08 p.m

Re: GridDhtInvalidPartitionException takes the cluster down

+ 1 for having the default settings revisited. I understand Andrey's reasonings, but sometimes taking nodes down is too radical (as in my case it was GridDhtInvalidPartitionException which could be ignored for a while when rebalancing <- I might be wrong here). -- Roman On Tuesday, March

Re: Review IGNITE-11411 'Remove tearDown, setUp from JUnit3TestLegacySupport'

Ivan, I noticed that you updated PR [1] recently and changed an execution flow of setUp and tearDown methods in GridAbstractTest making it similar to what we have in master now. What did not work in an initial implementation? I spent some time seaching the reason why did we introduce JUnit3TestLeg