[jira] [Commented] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[
https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089946#comment-17089946
]
Ignite TC Bot commented on IGNITE-12934:
{panel:title=Branch: [pull/7715/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249205]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249219]]
* ZookeeperDiscoverySpiTestSuite3:
multijvm.GridCachePartitionedMultiJvmFullApiSelfTest - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249196]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests 1 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249191]]
* IgniteCacheTestSuite2:
IgniteCacheClientNodeChangingTopologyTest.testAtomicPrimaryPutAllMultinode -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cassandra Store{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249238]]
*
org.apache.ignite.tests.CassandraDirectPersistenceTest.pojoStrategyTransactionTest
- History for base branch is absent.
{color:#d04437}Basic 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249129]]
* IgniteComputeBasicConfigVariationsFullApiTestSuite:
IgniteComputeConfigVariationsFullApiTest_17.testDeployExecuteByName - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests 1 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249198]]
* IgniteCacheTestSuite9:
MetricsConfigurationTest.testConfigRemovedOnCacheRemove - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}OSGi{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5249203]]
*
org.apache.ignite.osgi.IgniteKarafFeaturesInstallationTest.testAllBundlesActiveAndFeaturesInstalled
- History for base branch is absent.
*
org.apache.ignite.osgi.IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked
- History for base branch is absent.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5249241&buildTypeId=IgniteTests24Java8_RunAll]
> Change test start|stop log format for correct TC and build.log visibility.
> --
>
> Key: IGNITE-12934
> URL: https://issues.apache.org/jira/browse/IGNITE-12934
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For correct TC and builds log visibility need to repeat log format, from :
> ">>> Stopping test: "
> as
> "##teamcity[testFinished name='"
> additional info:
> https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests
> Also, make “Starting test”, “Stopping test” messages visible in Quiet mode!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089892#comment-17089892
]
Ivan Daschinskiy edited comment on IGNITE-12827 at 4/22/20, 5:48 PM:
-
[~nizhikov] This issue, to be honest, not about OOM on special case, but about
counter intuitive API and confusing behaviour.
Let's explain. Consider this code:
{code:java}
@Test
public void testCoreDump() throws Exception {
BinaryMarshaller marsh = binaryMarshaller();
BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);
List col = IntStream.range(0,
1000).mapToObj(Value::new).collect(Collectors.toList());
marsh.binaryMarshaller().writer(os).marshal(col);
MappedFile memFile = new
MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());
long ptr = memFile.address();
GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr,
os.position());
BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr,
os.capacity());
List desCol =
(List)marsh.binaryMarshaller().reader(is)
.readObjectDetached();
memFile.close();
assertEquals(500, (int)desCol.get(500).field("val"));
}
{code}
Let's assume that once upon a time one igniter start to develop unmarshalling
from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He
probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully.
I think that confusing and errorneous API is worse, than small performance
penalty in some cases (and, as you can find in my report, in many cases, when
collection is large enough or object is not so small, has performance
benefits). Correctness is worth more than performance.
was (Author: ivandasch):
[~nizhikov] This issue, to be honest, not about OOM on special case, but about
conter intuitive API and confusing behaviour.
Let's explain. Consider this code:
{code:java}
@Test
public void testCoreDump() throws Exception {
BinaryMarshaller marsh = binaryMarshaller();
BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);
List col = IntStream.range(0,
1000).mapToObj(Value::new).collect(Collectors.toList());
marsh.binaryMarshaller().writer(os).marshal(col);
MappedFile memFile = new
MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());
long ptr = memFile.address();
GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr,
os.position());
BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr,
os.capacity());
List desCol =
(List)marsh.binaryMarshaller().reader(is)
.readObjectDetached();
memFile.close();
assertEquals(500, (int)desCol.get(500).field("val"));
}
{code}
Let's assume that once upon a time one igniter start to develop unmarshalling
from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He
probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully.
I think that confusing and errorneous API is worse, than small performance
penalty in some cases (and, as you can find in my report, in many cases, when
collection is large enough or object is not so small, has performance
benefits). Correctness is worth more than performance.
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089892#comment-17089892
]
Ivan Daschinskiy edited comment on IGNITE-12827 at 4/22/20, 5:43 PM:
-
[~nizhikov] This issue, to be honest, not about OOM on special case, but about
conter intuitive API and confusing behaviour.
Let's explain. Consider this code:
{code:java}
@Test
public void testCoreDump() throws Exception {
BinaryMarshaller marsh = binaryMarshaller();
BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);
List col = IntStream.range(0,
1000).mapToObj(Value::new).collect(Collectors.toList());
marsh.binaryMarshaller().writer(os).marshal(col);
MappedFile memFile = new
MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());
long ptr = memFile.address();
GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr,
os.position());
BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr,
os.capacity());
List desCol =
(List)marsh.binaryMarshaller().reader(is)
.readObjectDetached();
memFile.close();
assertEquals(500, (int)desCol.get(500).field("val"));
}
{code}
Let's assume that once upon a time one igniter start to develop unmarshalling
from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He
probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully.
I think that confusing and errorneous API is worse, than small performance
penalty in some cases (and, as you can find in my report, in many cases, when
collection is large enough or object is not so small, has performance
benefits). Correctness is worth more than performance.
was (Author: ivandasch):
[~nizhikov] This issue, to be honest, not about OOM on special case, but about
conter intuitive API and confusing behaviour.
Let's explain. Consider this code:
{code:java}
@Test
public void testCoreDump() throws Exception {
BinaryMarshaller marsh = binaryMarshaller();
BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);
List col = IntStream.range(0,
1000).mapToObj(Value::new).collect(Collectors.toList());
marsh.binaryMarshaller().writer(os).marshal(col);
MappedFile memFile = new
MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());
long ptr = memFile.address();
GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr,
os.capacity());
BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr,
os.capacity());
List desCol =
(List)marsh.binaryMarshaller().reader(is)
.readObjectDetached();
memFile.close();
assertEquals(500, (int)desCol.get(500).field("val"));
}
{code}
Let's assume that once upon a time one igniter start to develop unmarshalling
from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He
probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully.
I think that confusing and errorneous API is worse, than small performance
penalty in some cases (and, as you can find in my report, in many cases, when
collection is large enough or object is not so small, has performance
benefits). Correctness is worth more than performance.
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089892#comment-17089892
]
Ivan Daschinskiy commented on IGNITE-12827:
---
[~nizhikov] This issue, to be honest, not about OOM on special case, but about
conter intuitive API and confusing behaviour.
Let's explain. Consider this code:
{code:java}
@Test
public void testCoreDump() throws Exception {
BinaryMarshaller marsh = binaryMarshaller();
BinaryHeapOutputStream os = new BinaryHeapOutputStream(1024);
List col = IntStream.range(0,
1000).mapToObj(Value::new).collect(Collectors.toList());
marsh.binaryMarshaller().writer(os).marshal(col);
MappedFile memFile = new
MappedFile(Files.createTempFile("mem_","_test").toFile(), os.capacity());
long ptr = memFile.address();
GridUnsafe.copyHeapOffheap(os.array(), GridUnsafe.BYTE_ARR_OFF, ptr,
os.capacity());
BinaryOffheapInputStream is = new BinaryOffheapInputStream(ptr,
os.capacity());
List desCol =
(List)marsh.binaryMarshaller().reader(is)
.readObjectDetached();
memFile.close();
assertEquals(500, (int)desCol.get(500).field("val"));
}
{code}
Let's assume that once upon a time one igniter start to develop unmarshalling
from memory mapped file or some offheap data.
He or she writes some similar code like one above and BUM! got JVM crash. He
probably would yell a lot and think "WTF, object is detached!"
But unfortunatelly not fully.
I think that confusing and errorneous API is worse, than small performance
penalty in some cases (and, as you can find in my report, in many cases, when
collection is large enough or object is not so small, has performance
benefits). Correctness is worth more than performance.
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089823#comment-17089823
]
Ilya Kasnacheev commented on IGNITE-12765:
--
I think that's bad that we decide not to work on shipping procedures in minor
releases, we end up never working on them at all.
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12918) .NET: Add Travis job
[ https://issues.apache.org/jira/browse/IGNITE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-12918. - Fix Version/s: 2.9 Resolution: Fixed > .NET: Add Travis job > > > Key: IGNITE-12918 > URL: https://issues.apache.org/jira/browse/IGNITE-12918 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.9 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Add .NET build to .travis.yml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12902) Concurrent modification in time to iterate by events
[
https://issues.apache.org/jira/browse/IGNITE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-12902:
-
Reviewer: Alexey Goncharuk (was: Anton Kalashnikov)
> Concurrent modification in time to iterate by events
>
>
> Key: IGNITE-12902
> URL: https://issues.apache.org/jira/browse/IGNITE-12902
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
> 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
> processor: GridProcessorAdapter []
> [10:20:37]W: [org.apache.ignite:ignite-core]
> java.util.ConcurrentModificationException
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.next(ArrayList.java:859)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
> In that place we are going over event’s collection, looking for server
> leave’s event:
> {code:java}
> for (DiscoveryEvent evt : evts.events()) {
> if (serverLeftEvent(evt)) {
> for (CacheGroupContext grp : cctx.cache().cacheGroups())
> grp.affinityFunction().removeNode(evt.eventNode().id());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-10940:
-
Component/s: platforms
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build, platforms
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089779#comment-17089779
]
Nikolay Izhikov commented on IGNITE-12827:
--
Hello [~ivandasch]
This issue is reproducible only on the special cases when we have small heap
and heavy service requests from the .Net.
It requires some additional review from my side, also.
So I think we should exclude it from the 2.8.1 scope.
What do you think?
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12827:
-
Fix Version/s: (was: 2.8.1)
2.9
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[ https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12934: - Ignite Flags: (was: Docs Required,Release Notes Required) > Change test start|stop log format for correct TC and build.log visibility. > -- > > Key: IGNITE-12934 > URL: https://issues.apache.org/jira/browse/IGNITE-12934 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For correct TC and builds log visibility need to repeat log format, from : > ">>> Stopping test: " > as > "##teamcity[testFinished name='" > additional info: > https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests > Also, make “Starting test”, “Stopping test” messages visible in Quiet mode! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089771#comment-17089771
]
Nikolay Izhikov commented on IGNITE-12765:
--
Hello [~ilyak]
I excluded this ticket from 2.8.1 scope because 2.8.1 is a bugfix release.
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12765:
-
Fix Version/s: (was: 2.8.1)
2.9
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12922) SqlViewMetricExporterSpi is redundant entity
[
https://issues.apache.org/jira/browse/IGNITE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12922:
-
Fix Version/s: (was: 2.8.1)
2.9
> SqlViewMetricExporterSpi is redundant entity
> -
>
> Key: IGNITE-12922
> URL: https://issues.apache.org/jira/browse/IGNITE-12922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: IEP-35
> Fix For: 2.9
>
>
> {{SqlViewMetricExporterSpi}} is redundant entity both in terms of design and
> in terms of user experience.
> {{METRICS}} SQL view is the internal entity that could exist regardless of
> any exporters configuration. So it should be created on indexing module
> initialization. Also from an user stand point it is strange to configure
> special exporter in order to get access to the {{METRICS}} view via SQL.
> See also IGNITE-12921.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12921) System views design leads to bad user expirience.
[
https://issues.apache.org/jira/browse/IGNITE-12921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12921:
-
Fix Version/s: (was: 2.8.1)
2.9
> System views design leads to bad user expirience.
> -
>
> Key: IGNITE-12921
> URL: https://issues.apache.org/jira/browse/IGNITE-12921
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Priority: Critical
> Labels: IEP-35
> Fix For: 2.9
>
>
> Current implementation of system views has broken system behavior which is
> related with querying system views.
> Before 2.8 system views were available via SQL queries (if indexing is
> enabled). It did not depend on any configuration.
> After implementation of IGNITE-12145 system views available only if
> {{SqlViewExporterSpi}} is passed to
> {{IgniteConfiguration.setSystemViewExporterSpi()}}. Now, if an user
> configures some {{SystemViewExporterSpi}} then provided user configuration
> will rewrite default configuration and {{SqlViewExporterSpi}} won't be
> initialized. As result it is impossible to query system views and any query
> to the views fails with exception. This behavior is not obvious for the user.
> See tests below.
> The second problem is kind of design problem. System view is internal part of
> the system and should be available regardless of any exporter configuration
> (at least via SQL) such as it was implemented before 2.8 release.
> My suggestion is the following: we should remove {{SqlViewExporterSpi}} and
> configure all views on indexing module initialization. {{SqlViewExporterSPI}}
> also doesn't make sense because:
> - it operates by some internal API ({{SchemaManager}}, {{GridKernalContext}},
> {{IgniteH2Indexing}}).
> - it doesn't allow to end user to add any new system view.
> Only thing that could be useful is a filtering. But it could be done with SQL.
> Reproducer of broken behavior:
> {code:java}
> package org.apache.ignite.internal.processors.cache.metric;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.cluster.ClusterState;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.systemview.jmx.JmxSystemViewExporterSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import static java.util.Arrays.asList;
> import static
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest.queryProcessor;
> public class SystemViewTest extends GridCommonAbstractTest {
> private static boolean useDefaultSpi;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDataRegionConfigurations(
> new
> DataRegionConfiguration().setName("in-memory").setMaxSize(100L * 1024 * 1024))
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> if (!useDefaultSpi) {
> // Configure user provided system view exporter SPI.
> cfg.setSystemViewExporterSpi(new JmxSystemViewExporterSpi());
> }
> return cfg;
> }
> /**
> * Will executed succefully.
> */
> @Test
> public void testSystemViewWithDefaultSpi() throws Exception {
> useDefaultSpi = true;
> doTestSystemView();
> }
> /**
> * Will fail with Table "VIEWS" not found.
> */
> @Test
> public void testSystemViewWithCustomSpi() throws Exception {
> useDefaultSpi = false;
> doTestSystemView();
> }
> private void doTestSystemView() throws Exception {
> try (IgniteEx ignite = startGrid()) {
> ignite.cluster().state(ClusterState.ACTIVE);
> Set cacheNames = new HashSet<>(asList("cache-1",
> "cache-2"));
> for (String name : cacheNames)
> ignite.getOrCreateCache(name);
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT * FROM
> SYS.VIEWS");
> List> res = queryProcessor(ignite).querySqlFields(qry,
> true).getAll();
> res.forEach(item -> log.info("VIEW FOUND: " + item));
> }
[jira] [Created] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
Ilya Kasnacheev created IGNITE-12934: Summary: Change test start|stop log format for correct TC and build.log visibility. Key: IGNITE-12934 URL: https://issues.apache.org/jira/browse/IGNITE-12934 Project: Ignite Issue Type: Improvement Components: build Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev For correct TC and builds log visibility need to repeat log format, from : ">>> Stopping test: " as "##teamcity[testFinished name='" additional info: https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests Also, make “Starting test”, “Stopping test” messages visible in Quiet mode! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12080) Add extended logging for rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089713#comment-17089713
]
Ignite TC Bot commented on IGNITE-12080:
{panel:title=Branch: [pull/7705/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5248032&buildTypeId=IgniteTests24Java8_RunAll]
> Add extended logging for rebalance
> --
>
> Key: IGNITE-12080
> URL: https://issues.apache.org/jira/browse/IGNITE-12080
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> We should log information about finished rebalance on demander node.
> I'd have in log:
> h3. Total information:
> # Rebalance duration, rebalance start time/rebalance finish time
> # How many nodes were suppliers in rebalance (nodeId, number of supplied
> paritions, number of supplied entries, number of bytes, duraton of getting
> and processing partitions from supplier)
> h3. Information per cache group:
> # Rebalance duration, rebalance start time/rebalance finish time
> # How many nodes were suppliers in rebalance (nodeId, number of supplied
> paritions, list of partition ids with PRIMARY/BACKUP flag, number of supplied
> entries, number of bytes, duraton of getting and processing partitions from
> supplier)
> # Information about each partition distribution (list of nodeIds with
> primary/backup flag and marked supplier nodeId)
> h3. Information per supplier node:
> # How many paritions were requested:
> ** Total number
> ** Primary/backup distribution (number of primary partitions, number of
> backup partitions)
> ** Total number of entries
> ** Total size partitions in bytes
> # How many paritions were requested per cache group:
> ** Number of requested partitions
> ** Number of entries in partitions
> ** Total size of partitions in bytes
> ** List of requested partitions with size in bytes, count entries, primary
> or backup partition flag
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
Aleksey Plekhanov created IGNITE-12933:
--
Summary: Node failed after put incorrect key class for indexed
type to transactional cache
Key: IGNITE-12933
URL: https://issues.apache.org/jira/browse/IGNITE-12933
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Reproducer:
{code:java}
public class IndexedTypesTest extends GridCommonAbstractTest {
private boolean failed;
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setFailureHandler((ignite, ctx) -> failed = true)
.setCacheConfiguration(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setAtomicityMode(TRANSACTIONAL)
.setIndexedTypes(String.class, String.class));
}
@Test
public void testPutIndexedType() throws Exception {
Ignite ignite = startGrids(2);
for (int i = 0; i < 10; i++) {
try {
ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
}
catch (Exception ignore) {
}
}
assertFalse(failed);
}
}
{code}
Node failed with exception:
{noformat}
[2020-04-22
17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler
[hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a
transaction has produced runtime exception]]
class
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
Committing a transaction has produced runtime exception
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
index, incorrect key class [expCls=java.lang.String,
actualCls=java.lang.Integer]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2092)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:410)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2627)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1713)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1688)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089672#comment-17089672
]
Nikolay Izhikov commented on IGNITE-12905:
--
You can find details in Ignite how-to-contribute instructions.
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-GettingStarted
Basically you need:
* subscribe to dev-list
* ask for a contributor permissions on it.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089667#comment-17089667
]
Johnny Galatikitis commented on IGNITE-12905:
-
Hi, [~nizhikov],
I tried but couldn't - do I need additional jira permissions?
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11179) One of two nodes fail by handler with message - threadName=ttl-cleanup-worker, blockedFor=16s
[
https://issues.apache.org/jira/browse/IGNITE-11179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089661#comment-17089661
]
Nikolay Izhikov commented on IGNITE-11179:
--
Hello, [~ARomantsov] Is this issue still reproducible?
Since lack of activity on it, I'm moving it out of the scope of 2.8.1 release.
> One of two nodes fail by handler with message -
> threadName=ttl-cleanup-worker, blockedFor=16s
> -
>
> Key: IGNITE-11179
> URL: https://issues.apache.org/jira/browse/IGNITE-11179
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.8
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.9, 2.8.1
>
>
> Start two nodes, one of them fail after block "start caches in recovery mode"
> {code:java}
> [12:47:57,333][SEVERE][tcp-disco-msg-worker-#2][G] Blocked system-critical
> thread has been detected. This can lead to cluster-wide undefined behaviour
> [threadName=ttl-cleanup-worker, blockedFor=16s]
> [12:47:57,334][WARNING][tcp-disco-msg-worker-#2][G] Thread
> [name="ttl-cleanup-worker-#45", id=63, state=WAITING, blockCnt=0, waitCnt=1]
> [12:47:57,336][SEVERE][tcp-disco-msg-worker-#2][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=ttl-cleanup-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1549187260799]]]
> class org.apache.ignite.IgniteException: GridWorker [name=ttl-cleanup-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1549187260799]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1828)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2680)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7218)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7156)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11179) One of two nodes fail by handler with message - threadName=ttl-cleanup-worker, blockedFor=16s
[
https://issues.apache.org/jira/browse/IGNITE-11179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11179:
-
Fix Version/s: (was: 2.8.1)
> One of two nodes fail by handler with message -
> threadName=ttl-cleanup-worker, blockedFor=16s
> -
>
> Key: IGNITE-11179
> URL: https://issues.apache.org/jira/browse/IGNITE-11179
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.8
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.9
>
>
> Start two nodes, one of them fail after block "start caches in recovery mode"
> {code:java}
> [12:47:57,333][SEVERE][tcp-disco-msg-worker-#2][G] Blocked system-critical
> thread has been detected. This can lead to cluster-wide undefined behaviour
> [threadName=ttl-cleanup-worker, blockedFor=16s]
> [12:47:57,334][WARNING][tcp-disco-msg-worker-#2][G] Thread
> [name="ttl-cleanup-worker-#45", id=63, state=WAITING, blockCnt=0, waitCnt=1]
> [12:47:57,336][SEVERE][tcp-disco-msg-worker-#2][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=ttl-cleanup-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1549187260799]]]
> class org.apache.ignite.IgniteException: GridWorker [name=ttl-cleanup-worker,
> igniteInstanceName=null, finished=false, heartbeatTs=1549187260799]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1828)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2680)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7218)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7156)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089658#comment-17089658
]
Nikolay Izhikov commented on IGNITE-12905:
--
Hello, [~bleedah]
Can you, please, assign the ticket to yourself if you are working on it,
currently
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12907) GridSystemViewManager is not thread safe
[
https://issues.apache.org/jira/browse/IGNITE-12907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12907:
-
Fix Version/s: (was: 2.8.1)
2.9
> GridSystemViewManager is not thread safe
>
>
> Key: IGNITE-12907
> URL: https://issues.apache.org/jira/browse/IGNITE-12907
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.9
>
>
> {{GridSystemViewManager}} is not thread safe because it allows to registers
> walkers using public {{registerWalker()}} that just adds walker to a
> {{HashMap}}.
> It seems the simplest solution here: make {{registerWalker()}} method private
> because it has usages only from {{GridSystemViewManager}} constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12907) GridSystemViewManager is not thread safe
[
https://issues.apache.org/jira/browse/IGNITE-12907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-12907.
--
Resolution: Invalid
> GridSystemViewManager is not thread safe
>
>
> Key: IGNITE-12907
> URL: https://issues.apache.org/jira/browse/IGNITE-12907
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
>
> {{GridSystemViewManager}} is not thread safe because it allows to registers
> walkers using public {{registerWalker()}} that just adds walker to a
> {{HashMap}}.
> It seems the simplest solution here: make {{registerWalker()}} method private
> because it has usages only from {{GridSystemViewManager}} constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12921) System views design leads to bad user expirience.
[
https://issues.apache.org/jira/browse/IGNITE-12921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089654#comment-17089654
]
Nikolay Izhikov commented on IGNITE-12921:
--
Hello, [~agura] Thanks for the tickets!
I think this improvement should be included in 2.9 release because 2.8.1 is a
bugfix release.
> System views design leads to bad user expirience.
> -
>
> Key: IGNITE-12921
> URL: https://issues.apache.org/jira/browse/IGNITE-12921
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Priority: Critical
> Labels: IEP-35
> Fix For: 2.8.1
>
>
> Current implementation of system views has broken system behavior which is
> related with querying system views.
> Before 2.8 system views were available via SQL queries (if indexing is
> enabled). It did not depend on any configuration.
> After implementation of IGNITE-12145 system views available only if
> {{SqlViewExporterSpi}} is passed to
> {{IgniteConfiguration.setSystemViewExporterSpi()}}. Now, if an user
> configures some {{SystemViewExporterSpi}} then provided user configuration
> will rewrite default configuration and {{SqlViewExporterSpi}} won't be
> initialized. As result it is impossible to query system views and any query
> to the views fails with exception. This behavior is not obvious for the user.
> See tests below.
> The second problem is kind of design problem. System view is internal part of
> the system and should be available regardless of any exporter configuration
> (at least via SQL) such as it was implemented before 2.8 release.
> My suggestion is the following: we should remove {{SqlViewExporterSpi}} and
> configure all views on indexing module initialization. {{SqlViewExporterSPI}}
> also doesn't make sense because:
> - it operates by some internal API ({{SchemaManager}}, {{GridKernalContext}},
> {{IgniteH2Indexing}}).
> - it doesn't allow to end user to add any new system view.
> Only thing that could be useful is a filtering. But it could be done with SQL.
> Reproducer of broken behavior:
> {code:java}
> package org.apache.ignite.internal.processors.cache.metric;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.cluster.ClusterState;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.systemview.jmx.JmxSystemViewExporterSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import static java.util.Arrays.asList;
> import static
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest.queryProcessor;
> public class SystemViewTest extends GridCommonAbstractTest {
> private static boolean useDefaultSpi;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDataRegionConfigurations(
> new
> DataRegionConfiguration().setName("in-memory").setMaxSize(100L * 1024 * 1024))
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> if (!useDefaultSpi) {
> // Configure user provided system view exporter SPI.
> cfg.setSystemViewExporterSpi(new JmxSystemViewExporterSpi());
> }
> return cfg;
> }
> /**
> * Will executed succefully.
> */
> @Test
> public void testSystemViewWithDefaultSpi() throws Exception {
> useDefaultSpi = true;
> doTestSystemView();
> }
> /**
> * Will fail with Table "VIEWS" not found.
> */
> @Test
> public void testSystemViewWithCustomSpi() throws Exception {
> useDefaultSpi = false;
> doTestSystemView();
> }
> private void doTestSystemView() throws Exception {
> try (IgniteEx ignite = startGrid()) {
> ignite.cluster().state(ClusterState.ACTIVE);
> Set cacheNames = new HashSet<>(asList("cache-1",
> "cache-2"));
> for (String name : cacheNames)
> ignite.getOrCreateCache(name);
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT * FROM
> SYS.VIEWS");
> List> res = que
[jira] [Commented] (IGNITE-12922) SqlViewMetricExporterSpi is redundant entity
[
https://issues.apache.org/jira/browse/IGNITE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089656#comment-17089656
]
Nikolay Izhikov commented on IGNITE-12922:
--
Hello, [~agura] Thanks for the tickets!
I think this improvement should be included in 2.9 release because 2.8.1 is a
bugfix release.
> SqlViewMetricExporterSpi is redundant entity
> -
>
> Key: IGNITE-12922
> URL: https://issues.apache.org/jira/browse/IGNITE-12922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
>
> {{SqlViewMetricExporterSpi}} is redundant entity both in terms of design and
> in terms of user experience.
> {{METRICS}} SQL view is the internal entity that could exist regardless of
> any exporters configuration. So it should be created on indexing module
> initialization. Also from an user stand point it is strange to configure
> special exporter in order to get access to the {{METRICS}} view via SQL.
> See also IGNITE-12921.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089650#comment-17089650
]
Nikolay Izhikov commented on IGNITE-10940:
--
The scope of 2.8.1 is more then 80 tickets for now.
I can't see any urge with this improvement.
So I suggest moving it out of the scope of 2.8.1 release.
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: c++
> Fix For: 2.8.1
>
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12906) Add to IgniteWalConverter possibility output only hashes instead real data
[ https://issues.apache.org/jira/browse/IGNITE-12906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089644#comment-17089644 ] Kirill Tkalenko commented on IGNITE-12906: -- Build of new suite: [https://ci.ignite.apache.org/viewLog.html?buildId=5244369&tab=queuedBuildOverviewTab] > Add to IgniteWalConverter possibility output only hashes instead real data > -- > > Key: IGNITE-12906 > URL: https://issues.apache.org/jira/browse/IGNITE-12906 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add flag to be able to hide sensitive data in WAL reader output. For example, > we can use cryptographic hash to hide data and see some representation of it > to know is it unique or not, with high probability. > If define binaryMetadata then output field name and hash field value, else > output hash of source binary value > This change is required for user security reasons -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12902) Concurrent modification in time to iterate by events
[
https://issues.apache.org/jira/browse/IGNITE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-12902:
-
Comment: was deleted
(was: Build of new suite:
[https://ci.ignite.apache.org/viewLog.html?buildId=5244369&tab=queuedBuildOverviewTab])
> Concurrent modification in time to iterate by events
>
>
> Key: IGNITE-12902
> URL: https://issues.apache.org/jira/browse/IGNITE-12902
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
> 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
> processor: GridProcessorAdapter []
> [10:20:37]W: [org.apache.ignite:ignite-core]
> java.util.ConcurrentModificationException
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.next(ArrayList.java:859)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
> In that place we are going over event’s collection, looking for server
> leave’s event:
> {code:java}
> for (DiscoveryEvent evt : evts.events()) {
> if (serverLeftEvent(evt)) {
> for (CacheGroupContext grp : cctx.cache().cacheGroups())
> grp.affinityFunction().removeNode(evt.eventNode().id());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12758) zookeeper discovery does not work due to missed dependency
[ https://issues.apache.org/jira/browse/IGNITE-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089643#comment-17089643 ] Nikolay Izhikov commented on IGNITE-12758: -- Merged to master. Cherry-picked to 2.8.1 [~mmuzaf] Thanks for the contribution. > zookeeper discovery does not work due to missed dependency > -- > > Key: IGNITE-12758 > URL: https://issues.apache.org/jira/browse/IGNITE-12758 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Blocker > Fix For: 2.8.1 > > Time Spent: 10m > Remaining Estimate: 0h > > in new zookeeper 3.5.5 version part of classes were moved in new jar: > [https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper-jute/3.5.5] > which is missed in Apache Ignite release. > Sever fails to start with the following exception: > > [15:16:14,514][SEVERE][main][IgniteKernal] Got exception while starting (will > rollback startup routine). > java.lang.NoClassDefFoundError: org/apache/zookeeper/data/Id > at org.apache.zookeeper.ZooDefs$Ids.(ZooDefs.java:111) > at > org.apache.ignite.spi.discovery.zk.internal.ZookeeperClient.(ZookeeperClient.java:68) > at > org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.joinTopology(ZookeeperDiscoveryImpl.java:783) > at > org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:714) > at > org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:483) > at > org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297) > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:943) > at > org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1960) > at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1276) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038) > at > org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703) > at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) > at > org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) > at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) > at org.apache.ignite.Ignition.start(Ignition.java:346) > at > org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:300) > Caused by: java.lang.ClassNotFoundException: > [org.apache.zookeeper.data.Id|http://org.apache.zookeeper.data.id/] > at java.net.URLClassLoader.findClass(URLClassLoader.java:382) > at java.lang.ClassLoader.loadClass(ClassLoader.java:418) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) > at java.lang.ClassLoader.loadClass(ClassLoader.java:351) > ... 19 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12732) SQL: KILL QUERY command hangs on query when query cursor is held by user or leak
[ https://issues.apache.org/jira/browse/IGNITE-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089628#comment-17089628 ] Nikolay Izhikov commented on IGNITE-12732: -- [~rkondakov] Thank you. PR merged in the 2.8.1 > SQL: KILL QUERY command hangs on query when query cursor is held by user or > leak > > > Key: IGNITE-12732 > URL: https://issues.apache.org/jira/browse/IGNITE-12732 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Scenario to reproduce: > 1. Execute a query > 2. Don't close the query cursor, don't iterate to the end of results. > 3. Run "KILL QUERY" command. The command hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: Cannot enable read-through (loader or store is not provided) for cache
[
https://issues.apache.org/jira/browse/IGNITE-12898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089624#comment-17089624
]
Ivan Daschinskiy commented on IGNITE-12898:
---
The main reason of failure -- that storeFactory is deserialized too late,
after node join validation. If remove {{@SerializeSeparately}} on field
{{org.apache.ignite.configuration.CacheConfiguration#storeFactory}}, everything
works ok.
> Server node with CacheStore fails to re-join the cluster: Cannot enable
> read-through (loader or store is not provided) for cache
>
>
> Key: IGNITE-12898
> URL: https://issues.apache.org/jira/browse/IGNITE-12898
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
>
> If a cache with external persistence is dynamically created on a non-affinity
> node then the cache affinity node cannot join the cluster after restart.
> h2. Repro Steps
> # Run an "empty" Ignite node where no cache is going to be started
> # Run a cache affinity node having the "ROLE" attribute set to "DATA"
> # Create the cache from the "empty" node and use a Node Filter to limit the
> cache to the "data" node. External persistence is configured for the cache.
> # Restart the "data" node
> h3. Actual Result
> {{IgniteCheckedException: Cannot enable read-through (loader or store is not
> provided) for cache}}
> h2. Reproducer
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> @Test
> public void test() throws Exception {
> final String DB_URL = "jdbc:h2:mem:test";
> final String ENTITY_NAME = "Person";
> Function igniteCfgFactory = instanceName
> ->
> new IgniteConfiguration()
> .setIgniteInstanceName(instanceName)
> .setDiscoverySpi(new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> // 1. Run an "empty" Ignite node where no cache is going to be started
> try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa",
> "");
> Statement dbStmt = dbConn.createStatement();
> Ignite emptyNode =
> Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
> // 2. Run a "Person" cache affinity node having the "ROLE"
> attribute set to "DATA"
> Map dataNodeAttrs = new HashMap<>(1);
> dataNodeAttrs.put(DataNodeFilter.ATTR_NAME,
> DataNodeFilter.ATTR_VAL);
> Ignite dataNode =
> Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));
> // 3. Create the "Person" cache from the "empty" node and use a
> Node Filter to limit the cache to the
> // "data" node. External persistence to the "Person" table in H2
> DB is configured for the cache.
> dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY
> KEY, name varchar)");
> CacheJdbcPojoStoreFactory
> igniteStoreFactory = new CacheJdbcPojoStoreFactory<>();
> igniteStoreFactory.setDataSourceFactory(() ->
> JdbcConnectionPool.create(DB_URL, "sa", ""))
> .setTypes(
> new JdbcType()
> .setCacheName(ENTITY_NAME)
> .setDatabaseTable(ENTITY_NAME)
> .setKeyType(Integer.class)
> .setValueType(ENTITY_NAME)
> .setKeyFields(new
> JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"))
> .setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name",
> String.class, "name")
> )
> );
> CacheConfiguration cacheCfg =
> new CacheConfiguration(ENTITY_NAME)
> .setCacheMode(CacheMode.REPLICATED)
> .setCacheStoreFactory(igniteStoreFactory)
> .setWriteThrough(true)
> .setReadThrough(true)
> .setNodeFilter(new DataNodeFilter());
> emptyNode.createCache(cacheCfg).withKeepBinary();
> // 4. Restart the "data" node
> dataNode.close();
> dataNode =
> Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));
> dataNode.close();
> }
> }
> private static class DataNodeFilter implements
> IgnitePredicate {
> pu
[jira] [Assigned] (IGNITE-12898) Server node with CacheStore fails to re-join the cluster: Cannot enable read-through (loader or store is not provided) for cache
[
https://issues.apache.org/jira/browse/IGNITE-12898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-12898:
-
Assignee: Ivan Daschinskiy
> Server node with CacheStore fails to re-join the cluster: Cannot enable
> read-through (loader or store is not provided) for cache
>
>
> Key: IGNITE-12898
> URL: https://issues.apache.org/jira/browse/IGNITE-12898
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
>
> If a cache with external persistence is dynamically created on a non-affinity
> node then the cache affinity node cannot join the cluster after restart.
> h2. Repro Steps
> # Run an "empty" Ignite node where no cache is going to be started
> # Run a cache affinity node having the "ROLE" attribute set to "DATA"
> # Create the cache from the "empty" node and use a Node Filter to limit the
> cache to the "data" node. External persistence is configured for the cache.
> # Restart the "data" node
> h3. Actual Result
> {{IgniteCheckedException: Cannot enable read-through (loader or store is not
> provided) for cache}}
> h2. Reproducer
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> @Test
> public void test() throws Exception {
> final String DB_URL = "jdbc:h2:mem:test";
> final String ENTITY_NAME = "Person";
> Function igniteCfgFactory = instanceName
> ->
> new IgniteConfiguration()
> .setIgniteInstanceName(instanceName)
> .setDiscoverySpi(new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> // 1. Run an "empty" Ignite node where no cache is going to be started
> try (Connection dbConn = DriverManager.getConnection(DB_URL, "sa",
> "");
> Statement dbStmt = dbConn.createStatement();
> Ignite emptyNode =
> Ignition.start(igniteCfgFactory.apply("emptyyNode"))) {
> // 2. Run a "Person" cache affinity node having the "ROLE"
> attribute set to "DATA"
> Map dataNodeAttrs = new HashMap<>(1);
> dataNodeAttrs.put(DataNodeFilter.ATTR_NAME,
> DataNodeFilter.ATTR_VAL);
> Ignite dataNode =
> Ignition.start(igniteCfgFactory.apply("dataNode").setUserAttributes(dataNodeAttrs));
> // 3. Create the "Person" cache from the "empty" node and use a
> Node Filter to limit the cache to the
> // "data" node. External persistence to the "Person" table in H2
> DB is configured for the cache.
> dbStmt.execute("CREATE TABLE " + ENTITY_NAME + " (id int PRIMARY
> KEY, name varchar)");
> CacheJdbcPojoStoreFactory
> igniteStoreFactory = new CacheJdbcPojoStoreFactory<>();
> igniteStoreFactory.setDataSourceFactory(() ->
> JdbcConnectionPool.create(DB_URL, "sa", ""))
> .setTypes(
> new JdbcType()
> .setCacheName(ENTITY_NAME)
> .setDatabaseTable(ENTITY_NAME)
> .setKeyType(Integer.class)
> .setValueType(ENTITY_NAME)
> .setKeyFields(new
> JdbcTypeField(java.sql.Types.INTEGER, "id", Integer.class, "id"))
> .setValueFields(
> new JdbcTypeField(java.sql.Types.INTEGER, "id",
> Integer.class, "id"),
> new JdbcTypeField(java.sql.Types.VARCHAR, "name",
> String.class, "name")
> )
> );
> CacheConfiguration cacheCfg =
> new CacheConfiguration(ENTITY_NAME)
> .setCacheMode(CacheMode.REPLICATED)
> .setCacheStoreFactory(igniteStoreFactory)
> .setWriteThrough(true)
> .setReadThrough(true)
> .setNodeFilter(new DataNodeFilter());
> emptyNode.createCache(cacheCfg).withKeepBinary();
> // 4. Restart the "data" node
> dataNode.close();
> dataNode =
> Ignition.start(igniteCfgFactory.apply("node2").setUserAttributes(dataNodeAttrs));
> dataNode.close();
> }
> }
> private static class DataNodeFilter implements
> IgnitePredicate {
> public static final String ATTR_NAME = "ROLE";
> public static final String ATTR_VAL = "DATA";
> @Override public boolean apply(ClusterNode node) {
> Object role = node.attributes().get(ATTR_NAME);
> return role != null &&
[jira] [Updated] (IGNITE-12902) Concurrent modification in time to iterate by events
[
https://issues.apache.org/jira/browse/IGNITE-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12902:
--
Description:
{code:java}
[10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
processor: GridProcessorAdapter []
[10:20:37]W: [org.apache.ignite:ignite-core]
java.util.ConcurrentModificationException
[10:20:37]W: [org.apache.ignite:ignite-core] at
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
[10:20:37]W: [org.apache.ignite:ignite-core] at
java.util.ArrayList$Itr.next(ArrayList.java:859)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
In that place we are going over event’s collection, looking for server leave’s
event:
{code:java}
for (DiscoveryEvent evt : evts.events()) {
if (serverLeftEvent(evt)) {
for (CacheGroupContext grp : cctx.cache().cacheGroups())
grp.affinityFunction().removeNode(evt.eventNode().id());
}
}
{code}
was:
{code:java}
[10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
processor: GridProcessorAdapter []
[10:20:37]W: [org.apache.ignite:ignite-core]
java.util.ConcurrentModificationException
[10:20:37]W: [org.apache.ignite:ignite-core] at
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
[10:20:37]W: [org.apache.ignite:ignite-core] at
java.util.ArrayList$Itr.next(ArrayList.java:859)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2302)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:142)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:464)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStop0(GridCachePartitionExchangeManager.java:821)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.onKernalStop(GridCacheSharedManagerAdapter.java:120)
[10:20:37]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:972){code}
In that place we are going over event’s collection, looking for server leave’s
event:
{code:java}
for (DiscoveryEvent evt : evts.events()) {
if (serverLeftEvent(evt)) {
for (CacheGroupContext grp : cctx.cache().cacheGroups())
grp.affinityFunction().removeNode(evt.eventNode().id());
}
}
{code}
> Concurrent modification in time to iterate by events
>
>
> Key: IGNITE-12902
> URL: https://issues.apache.org/jira/browse/IGNITE-12902
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> [10:20:37]W: [org.apache.ignite:ignite-core] [2020-02-20
> 10:20:37,324][ERROR][main][CacheExchangeMergeTest9] Failed to pre-stop
> processor: GridProcessorAdapter []
> [10:20:37]W: [org.apache.ignite:ignite-core]
> java.util.ConcurrentModificationException
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> java.util.ArrayList$Itr.next(ArrayList.java:859)
> [10:20:37]W: [org.apache.ignite:ignite-core] at
> or
[jira] [Updated] (IGNITE-12889) checkRingLatency loops if there is only one server node with client in topology
[ https://issues.apache.org/jira/browse/IGNITE-12889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12889: -- Fix Version/s: 2.9 > checkRingLatency loops if there is only one server node with client in > topology > --- > > Key: IGNITE-12889 > URL: https://issues.apache.org/jira/browse/IGNITE-12889 > Project: Ignite > Issue Type: Bug >Reporter: Igor Akkuratov >Assignee: Igor Akkuratov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > If there is only one server node with any count of clients in topology call > checkRingLatency loops until any server node join the topology. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8984) Ignite 2.5 - Vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-8984: -- Fix Version/s: 2.8 > Ignite 2.5 - Vulnerabilities > > > Key: IGNITE-8984 > URL: https://issues.apache.org/jira/browse/IGNITE-8984 > Project: Ignite > Issue Type: Bug >Reporter: Segu Riluvan >Assignee: Dmitry Pavlov >Priority: Major > Labels: security, vulnerability > Fix For: 2.8 > > Attachments: Ignite-Spark-Ignite_2_5_Blackduck_Scan_4_Github.xlsx, > Ignite_2_5_Blackduck_Scan_4_Github.zip > > > Recently we have scanned Apache Ignite 2.5 source code and all the associated > maven packages using Blackduck. The scan identified with many of the > dependencies for Ignite 2.5. Many of these vulnerabilities are rated as High > risk vulnerabilities. I've attached the vulnerability report to this ticket. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12930) DistributedProcess fails node if unable to send single message to coordinator
[
https://issues.apache.org/jira/browse/IGNITE-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-12930:
-
Issue Type: Bug (was: Task)
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12930) DistributedProcess fails node if unable to send single message to coordinator
[
https://issues.apache.org/jira/browse/IGNITE-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-12930:
-
Fix Version/s: 2.9
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8717) Move persisted cache configuration to metastore and introduce cache configuration versioning
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-8717: -- Assignee: (was: Sergey Antonov) > Move persisted cache configuration to metastore and introduce cache > configuration versioning > > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12732) SQL: KILL QUERY command hangs on query when query cursor is held by user or leak
[ https://issues.apache.org/jira/browse/IGNITE-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089544#comment-17089544 ] Roman Kondakov commented on IGNITE-12732: - [~nizhikov], here it is: [https://github.com/apache/ignite/pull/7706] > SQL: KILL QUERY command hangs on query when query cursor is held by user or > leak > > > Key: IGNITE-12732 > URL: https://issues.apache.org/jira/browse/IGNITE-12732 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Scenario to reproduce: > 1. Execute a query > 2. Don't close the query cursor, don't iterate to the end of results. > 3. Run "KILL QUERY" command. The command hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12930) DistributedProcess fails node if unable to send single message to coordinator
[
https://issues.apache.org/jira/browse/IGNITE-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-12930:
Assignee: Amelchev Nikita
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Major
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12928) CacheMetricsMXBean does not provide proper descriptions for rebalancing attributes
[ https://issues.apache.org/jira/browse/IGNITE-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089507#comment-17089507 ] Maria Makedonskaya commented on IGNITE-12928: - [~ivan.glukos], could you please review my ticket? > CacheMetricsMXBean does not provide proper descriptions for rebalancing > attributes > -- > > Key: IGNITE-12928 > URL: https://issues.apache.org/jira/browse/IGNITE-12928 > Project: Ignite > Issue Type: Bug >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When querying MBean info via JMX one expects to get meaningful descriptions > for all attributes. > However, for bean CacheMetricsMXBean, no descriptions provided for following > attributes, default value 'Attribute exposed for management' returned instead: > * EstimatedRebalancingFinishTime > * KeysToRebalanceLeft > * RebalancingBytesRate > * RebalancingKeysRate > * RebalancingPartitionsCount > * RebalancingStartTime > * TotalPartitionsCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12928) CacheMetricsMXBean does not provide proper descriptions for rebalancing attributes
[ https://issues.apache.org/jira/browse/IGNITE-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Makedonskaya updated IGNITE-12928: Reviewer: Ivan Rakov (was: Ivan Rakov) > CacheMetricsMXBean does not provide proper descriptions for rebalancing > attributes > -- > > Key: IGNITE-12928 > URL: https://issues.apache.org/jira/browse/IGNITE-12928 > Project: Ignite > Issue Type: Bug >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > When querying MBean info via JMX one expects to get meaningful descriptions > for all attributes. > However, for bean CacheMetricsMXBean, no descriptions provided for following > attributes, default value 'Attribute exposed for management' returned instead: > * EstimatedRebalancingFinishTime > * KeysToRebalanceLeft > * RebalancingBytesRate > * RebalancingKeysRate > * RebalancingPartitionsCount > * RebalancingStartTime > * TotalPartitionsCount -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12928) CacheMetricsMXBean does not provide proper descriptions for rebalancing attributes
[
https://issues.apache.org/jira/browse/IGNITE-12928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089494#comment-17089494
]
Ignite TC Bot commented on IGNITE-12928:
{panel:title=Branch: [pull/7711/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5246069&buildTypeId=IgniteTests24Java8_RunAll]
> CacheMetricsMXBean does not provide proper descriptions for rebalancing
> attributes
> --
>
> Key: IGNITE-12928
> URL: https://issues.apache.org/jira/browse/IGNITE-12928
> Project: Ignite
> Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When querying MBean info via JMX one expects to get meaningful descriptions
> for all attributes.
> However, for bean CacheMetricsMXBean, no descriptions provided for following
> attributes, default value 'Attribute exposed for management' returned instead:
> * EstimatedRebalancingFinishTime
> * KeysToRebalanceLeft
> * RebalancingBytesRate
> * RebalancingKeysRate
> * RebalancingPartitionsCount
> * RebalancingStartTime
> * TotalPartitionsCount
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-9560:
-
Comment: was deleted
(was: {panel:title=Branch: [pull/6363/head] Base: [master] : Possible Blockers
(44)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445036]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsCorruptedIndexTest.testCorruption - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445046]]
* exe: IgniteStartStopTest.TestProcessorInit - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444968]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 138s is more that 1 minute
{color:#d04437}Start Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444986]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodeById - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3445042]]
* exe: ComputeApiTest.TestNodes - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: ComputeApiTest.TestTopology - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: ComputeApiTest.TestWithNoFailover - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: ComputeApiTest.TestWithTimeout - Test has low fail rate in base branch
0,0% and is not flaky
* exe: ConsoleRedirectTest.TestMultipleDomains - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteAll - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445005]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlQueriesTest.testAccountsTxSql_WithRemoves_SingleNode_Persistence
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444999]]
* IgniteBasicTestSuite: IgniteDevOnlyLogTest.testDevOnlyVerboseMessage - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445021]]
* IgniteCacheTestSuite2:
IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445043]]
* dll: ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445067]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3445068]]
* IgnitePdsMvccTestSuite2: IgniteNodeStoppedDuringDisableWALTest.test - New
test duration 69s is more that 1 minute
* IgnitePdsMvccTestSuite2: IgniteRebalanceScheduleResendPartitionsTest.test -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 4{color} [[tests
15|https://ci.ignite.apache.org/viewLog.html?buildId=3445070]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 106s is more that 1 minute
* IgnitePdsMvccTestSuite4: ResetLostPartitionTest.testResetLostPartitions -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 103s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 101s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePds
[jira] [Issue Comment Deleted] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-9560:
-
Comment: was deleted
(was: {panel:title=Branch: [pull/4922/head] Base: [master] : Possible Blockers
(39)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689073]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689099]]
* IgniteCacheMvccTestSuite7:
MvccCacheGroupMetricsMBeanTest.testCacheGroupMetrics - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689063]]
* IgniteCacheTestSuite7: WalModeChangeAdvancedSelfTest.testClientReconnect -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689005]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 178s is more that 1 minute
{color:#d04437}Platform .NET{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3689079]]
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteSafe - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PersistenceTest.TestBaselineTopology - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689085]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3697002]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testAccountsTxSql_SingleNode_Persistence -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689058]]
* IgniteCacheTestSuite2:
CacheTxLoadingConcurrentGridStartSelfTestAllowOverwrite.testLoadCacheWithDataStreamerSequentialWithConfigAndRestarts
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite2: cache.CacheExchangeMessageDuplicatedStateTest -
History for base branch is absent.
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3699923]]
{color:#d04437}MVCC PDS 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689102]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers_5_Clients_FromClient
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689103]]
* IgnitePdsMvccTestSuite2: IgniteNodeStoppedDuringDisableWALTest.test - History
for base branch is absent.
{color:#d04437}MVCC PDS 4{color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=3689105]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 103s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 110s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 107s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 118s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 108s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_1_1
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsCont
[jira] [Issue Comment Deleted] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-9560:
-
Comment: was deleted
(was: {panel:title=Branch: [pull/6343/head] Base: [master] : Possible Blockers
(33)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422386]]
* exe: IgniteStartStopTest.TestProcessorInit - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422404]]
* IgniteCacheMvccTestSuite7:
MvccCacheGroupMetricsMBeanTest.testCacheGroupMetrics - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422366]]
* IgniteCacheTestSuite7:
TransactionIntegrityWithPrimaryIndexCorruptionTest.testPrimaryIndexCorruptionDuringCommitPrimaryColocatedThrowsUnchecked
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}SPI{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3422327]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite:
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422308]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 62s is more that 1 minute
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422382]]
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422407]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 4{color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=3424608]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 97s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 99s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 111s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_1_1
- New test duration 115s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_1
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_8_1
- New test duration 100s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_1_1
- New test duration 113s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_1_1
- New test duration 98s is more that 1 minute
... and 3 tests blockers
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422322]]
* IgniteBinaryCacheQueryTestSuite2: IgniteCacheQueriesLoadTest1.testQueries -
New test duration 87s is more that 1 minute
{color:#d04437}Cache 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422362]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheNearOnlyTopologySelfTest.testNodeLeave - Test has low fail rate in
base branch 0,0
[jira] [Created] (IGNITE-12932) Thin client cluster discovery
Pavel Tupitsyn created IGNITE-12932: --- Summary: Thin client cluster discovery Key: IGNITE-12932 URL: https://issues.apache.org/jira/browse/IGNITE-12932 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.9 Thin clients should be able to discover all server nodes automatically when connected to any of them, and maintain an up to date list of servers at all times. See linked IEP-44 for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12927) The CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime is flacky
[
https://issues.apache.org/jira/browse/IGNITE-12927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089477#comment-17089477
]
Nikolai Kulagin commented on IGNITE-12927:
--
LGTM
> The CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime is flacky
> --
>
> Key: IGNITE-12927
> URL: https://issues.apache.org/jira/browse/IGNITE-12927
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime}} is
> flacky.
> [TC
> history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-448222889376376497&branch=%3Cdefault%3E&tab=testDetails]
> {noformat}
> java.lang.IllegalStateException: Duplicate key 1472820775 (attempted merging
> values 1472820775 and 1472820775)
> at
> java.base/java.util.stream.Collectors.duplicateKeyException(Collectors.java:133)
> at
> java.base/java.util.stream.Collectors.lambda$uniqKeysMapAccumulator$1(Collectors.java:180)
> at
> java.base/java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at
> java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
> at
> java.base/java.util.Random$RandomIntsSpliterator.forEachRemaining(Random.java:1044)
> at
> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime(CacheGroupsMetricsRebalanceTest.java:315)
> {noformat}
> The reason is that randomly generated keys can be duplicated and cant be
> collected from stream .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9340) Update Jetty version in Apache Ignite (ignite-rest-http)
[ https://issues.apache.org/jira/browse/IGNITE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9340: Security: (was: Private) > Update Jetty version in Apache Ignite (ignite-rest-http) > > > Key: IGNITE-9340 > URL: https://issues.apache.org/jira/browse/IGNITE-9340 > Project: Ignite > Issue Type: Task > Components: rest >Affects Versions: 2.6 >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Labels: important > Fix For: 2.7 > > > log4j-core-2.8.1.jar 1 Vulnerability, 1 High: CVE-2017-5645 - update done in > IGNITE-9035 > jetty-util-9.2.11.v20150529.jar 2 Vulnerabilities, 2 High: > CVE-2016-4800, CVE-2017-9735 > jetty-util-9.2.11.v20150529.jar 2 Vulnerabilities, 2 High: > CVE-2016-4800, CVE-2017-9735 > jetty-server-9.2.11.v20150529.jar 2 Vulnerabilities, 1 High: CVE-2016-4800, 1 > Medium: CVE-2017-7658 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9340) Update Jetty version in Apache Ignite (ignite-rest-http)
[ https://issues.apache.org/jira/browse/IGNITE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9340: Labels: important vulnerability (was: important) > Update Jetty version in Apache Ignite (ignite-rest-http) > > > Key: IGNITE-9340 > URL: https://issues.apache.org/jira/browse/IGNITE-9340 > Project: Ignite > Issue Type: Task > Components: rest >Affects Versions: 2.6 >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > Labels: important, vulnerability > Fix For: 2.7 > > > log4j-core-2.8.1.jar 1 Vulnerability, 1 High: CVE-2017-5645 - update done in > IGNITE-9035 > jetty-util-9.2.11.v20150529.jar 2 Vulnerabilities, 2 High: > CVE-2016-4800, CVE-2017-9735 > jetty-util-9.2.11.v20150529.jar 2 Vulnerabilities, 2 High: > CVE-2016-4800, CVE-2017-9735 > jetty-server-9.2.11.v20150529.jar 2 Vulnerabilities, 1 High: CVE-2016-4800, 1 > Medium: CVE-2017-7658 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089461#comment-17089461
]
Ignite TC Bot commented on IGNITE-9560:
---
{panel:title=Branch: [pull/6363/head] Base: [master] : Possible Blockers
(44)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445036]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsCorruptedIndexTest.testCorruption - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445046]]
* exe: IgniteStartStopTest.TestProcessorInit - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444968]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 138s is more that 1 minute
{color:#d04437}Start Nodes{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444986]]
* IgniteStartStopRestartTestSuite:
IgniteProjectionStartStopRestartSelfTest.testRestartNodeById - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=3445042]]
* exe: ComputeApiTest.TestNodes - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: ComputeApiTest.TestTopology - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: ComputeApiTest.TestWithNoFailover - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: ComputeApiTest.TestWithTimeout - Test has low fail rate in base branch
0,0% and is not flaky
* exe: ConsoleRedirectTest.TestMultipleDomains - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteAll - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445005]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlQueriesTest.testAccountsTxSql_WithRemoves_SingleNode_Persistence
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3444999]]
* IgniteBasicTestSuite: IgniteDevOnlyLogTest.testDevOnlyVerboseMessage - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445021]]
* IgniteCacheTestSuite2:
IgniteClientCacheStartFailoverTest.testClientStartCloseServersRestart - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445043]]
* dll: ClientConnectionTest.TestClientDisposeWhileOperationsAreInProgress -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3445067]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3445068]]
* IgnitePdsMvccTestSuite2: IgniteNodeStoppedDuringDisableWALTest.test - New
test duration 69s is more that 1 minute
* IgnitePdsMvccTestSuite2: IgniteRebalanceScheduleResendPartitionsTest.test -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 4{color} [[tests
15|https://ci.ignite.apache.org/viewLog.html?buildId=3445070]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 106s is more that 1 minute
* IgnitePdsMvccTestSuite4: ResetLostPartitionTest.testResetLostPartitions -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 103s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 101s is more that 1 minute
* IgnitePdsMvccTe
[jira] [Commented] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089462#comment-17089462
]
Ignite TC Bot commented on IGNITE-9560:
---
{panel:title=Branch: [pull/6343/head] Base: [master] : Possible Blockers
(33)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422386]]
* exe: IgniteStartStopTest.TestProcessorInit - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422404]]
* IgniteCacheMvccTestSuite7:
MvccCacheGroupMetricsMBeanTest.testCacheGroupMetrics - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422366]]
* IgniteCacheTestSuite7:
TransactionIntegrityWithPrimaryIndexCorruptionTest.testPrimaryIndexCorruptionDuringCommitPrimaryColocatedThrowsUnchecked
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}SPI{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3422327]]
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testDisconnectOnRequest -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite:
TcpDiscoveryWithWrongServerTest.testWrongHandshakeResponse - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testEarlyDisconnect -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite: TcpDiscoveryWithWrongServerTest.testNoHandshakeResponse -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422308]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 62s is more that 1 minute
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422382]]
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422407]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 4{color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=3424608]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 97s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 99s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 111s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_1_1
- New test duration 115s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_8_16
- New test duration 98s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_1
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_8_1
- New test duration 100s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_500_1_1
- New test duration 113s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_1_1
- New test duration 98s is more that 1 minute
... and 3 tests blockers
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422322]]
* IgniteBinaryCacheQueryTestSuite2: IgniteCacheQueriesLoadTest1.testQueries -
New test duration 87s is more that 1 minute
{color:#d04437}Cache 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3422362]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheNearOnlyTopologySelfTest.testNodeLeave - Test has low fail rate
[jira] [Commented] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[
https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089463#comment-17089463
]
Ignite TC Bot commented on IGNITE-9560:
---
{panel:title=Branch: [pull/4922/head] Base: [master] : Possible Blockers
(39)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689073]]
* IgnitePdsWithIndexingCoreTestSuite:
IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689099]]
* IgniteCacheMvccTestSuite7:
MvccCacheGroupMetricsMBeanTest.testCacheGroupMetrics - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689063]]
* IgniteCacheTestSuite7: WalModeChangeAdvancedSelfTest.testClientReconnect -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Examples{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689005]]
* IgniteExamplesSelfTestSuite: HelloWorldGAExampleSelfTest.testExample - New
test duration 178s is more that 1 minute
{color:#d04437}Platform .NET{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=3689079]]
* exe: PartitionLossTest.TestReadOnlyAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteAll - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PartitionLossTest.TestReadWriteSafe - Test has low fail rate in base
branch 0,0% and is not flaky
* exe: PersistenceTest.TestBaselineTopology - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689085]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionAlterTable - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlNotNullConstraintTest.testReadThroughRestrictionCreateTable - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3697002]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlQueriesTest.testAccountsTxSql_SingleNode_Persistence -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689058]]
* IgniteCacheTestSuite2:
CacheTxLoadingConcurrentGridStartSelfTestAllowOverwrite.testLoadCacheWithDataStreamerSequentialWithConfigAndRestarts
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite2: cache.CacheExchangeMessageDuplicatedStateTest -
History for base branch is absent.
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3699923]]
{color:#d04437}MVCC PDS 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=3689102]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers_5_Clients_FromClient
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3689103]]
* IgnitePdsMvccTestSuite2: IgniteNodeStoppedDuringDisableWALTest.test - History
for base branch is absent.
{color:#d04437}MVCC PDS 4{color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=3689105]]
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_500_8_16
- New test duration 103s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_10_10_1_1
- New test duration 110s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_2_8_16
- New test duration 107s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_8_16
- New test duration 118s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_1_1
- New test duration 108s is more that 1 minute
* IgnitePdsMvccTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_8000_8000_1_1
- New test duration 114s is more that 1 minute
* IgnitePdsMvccTestSu
[jira] [Updated] (IGNITE-8713) Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar
[ https://issues.apache.org/jira/browse/IGNITE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8713: Labels: CVE security vulnerability (was: CVE security) > Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar > -- > > Key: IGNITE-8713 > URL: https://issues.apache.org/jira/browse/IGNITE-8713 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.5 >Reporter: Harendra Rai >Assignee: Andrey N. Gura >Priority: Major > Labels: CVE, security, vulnerability > Fix For: 2.6 > > > I am using Ignite for .NET and I have found following Security > vulnerabilities in *“spring-data-commons-1.13.1.RELEASE.jar”* > # CVE-2018-1273 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1273]) > *Description*: Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to > 2.0.5, and older unsupported versions, contain a property binder > vulnerability caused by improper neutralization of special elements. An > unauthenticated remote malicious user (or attacker) can supply specially > crafted request parameters against Spring Data REST backed HTTP resources or > using Spring Data's projection-based request payload binding hat can lead to > a remote code execution attack. > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. > 2. CVE-2018-1274 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1274]) > Description: Spring Data Commons, versions 1.13 to 1.13.10, 2.0 to 2.0.5, and > older unsupported versions, contain a property path parser vulnerability > caused by unlimited resource allocation. An unauthenticated remote malicious > user (or attacker) can issue requests against Spring Data REST endpoints or > endpoints using property path parsing which can cause a denial of service > (CPU and memory consumption). > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8713) Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar
[ https://issues.apache.org/jira/browse/IGNITE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8713: Security: (was: Private) > Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar > -- > > Key: IGNITE-8713 > URL: https://issues.apache.org/jira/browse/IGNITE-8713 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.5 >Reporter: Harendra Rai >Assignee: Andrey N. Gura >Priority: Major > Labels: CVE, security > Fix For: 2.6 > > > I am using Ignite for .NET and I have found following Security > vulnerabilities in *“spring-data-commons-1.13.1.RELEASE.jar”* > # CVE-2018-1273 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1273]) > *Description*: Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to > 2.0.5, and older unsupported versions, contain a property binder > vulnerability caused by improper neutralization of special elements. An > unauthenticated remote malicious user (or attacker) can supply specially > crafted request parameters against Spring Data REST backed HTTP resources or > using Spring Data's projection-based request payload binding hat can lead to > a remote code execution attack. > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. > 2. CVE-2018-1274 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1274]) > Description: Spring Data Commons, versions 1.13 to 1.13.10, 2.0 to 2.0.5, and > older unsupported versions, contain a property path parser vulnerability > caused by unlimited resource allocation. An unauthenticated remote malicious > user (or attacker) can issue requests against Spring Data REST endpoints or > endpoints using property path parsing which can cause a denial of service > (CPU and memory consumption). > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6856) SQL: invalid security checks during query execution
[
https://issues.apache.org/jira/browse/IGNITE-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6856:
Security: (was: Private)
> SQL: invalid security checks during query execution
> ---
>
> Key: IGNITE-6856
> URL: https://issues.apache.org/jira/browse/IGNITE-6856
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.8
>
>
> Currently security check is performed inside {{IgniteCacheProxy}}. This is
> wrong place. Instead, we should perform it inside query processor after
> parsing when all affected caches are known.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6856) SQL: invalid security checks during query execution
[
https://issues.apache.org/jira/browse/IGNITE-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6856:
Labels: vulnerability (was: )
> SQL: invalid security checks during query execution
> ---
>
> Key: IGNITE-6856
> URL: https://issues.apache.org/jira/browse/IGNITE-6856
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: vulnerability
> Fix For: 2.8
>
>
> Currently security check is performed inside {{IgniteCacheProxy}}. This is
> wrong place. Instead, we should perform it inside query processor after
> parsing when all affected caches are known.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8713) Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar
[ https://issues.apache.org/jira/browse/IGNITE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8713: Component/s: spring > Security vulnerabilities in spring-data-commons-1.13.1.RELEASE.jar > -- > > Key: IGNITE-8713 > URL: https://issues.apache.org/jira/browse/IGNITE-8713 > Project: Ignite > Issue Type: Bug > Components: security, spring >Affects Versions: 2.5 >Reporter: Harendra Rai >Assignee: Andrey N. Gura >Priority: Major > Labels: CVE, security, vulnerability > Fix For: 2.6 > > > I am using Ignite for .NET and I have found following Security > vulnerabilities in *“spring-data-commons-1.13.1.RELEASE.jar”* > # CVE-2018-1273 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1273]) > *Description*: Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to > 2.0.5, and older unsupported versions, contain a property binder > vulnerability caused by improper neutralization of special elements. An > unauthenticated remote malicious user (or attacker) can supply specially > crafted request parameters against Spring Data REST backed HTTP resources or > using Spring Data's projection-based request payload binding hat can lead to > a remote code execution attack. > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. > 2. CVE-2018-1274 > ([https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1274]) > Description: Spring Data Commons, versions 1.13 to 1.13.10, 2.0 to 2.0.5, and > older unsupported versions, contain a property path parser vulnerability > caused by unlimited resource allocation. An unauthenticated remote malicious > user (or attacker) can issue requests against Spring Data REST endpoints or > endpoints using property path parsing which can cause a denial of service > (CPU and memory consumption). > *Fix*: Users of affected versions should apply the following mitigation: > 2.0.x users should upgrade to 2.0.6 > 1.13.x users should upgrade to 1.13.11 > Older versions should upgrade to a supported branch > Releases that have fixed this issue include: > Spring Data REST 2.6.11 (Ingalls SR11) > Spring Data REST 3.0.6 (Kay SR6) > There are no other mitigation steps necessary. > Note that the use of authentication and authorization for endpoints, both of > which are provided by Spring Security, limits exposure to this vulnerability > to authorized users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[ https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9560: Labels: vulnerability (was: ) > Security Engine fixes and test coverage. Phase #1. > -- > > Key: IGNITE-9560 > URL: https://issues.apache.org/jira/browse/IGNITE-9560 > Project: Ignite > Issue Type: Task > Components: security >Affects Versions: 2.6 >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: vulnerability > Fix For: 2.8 > > > Compute and other Public API, which able to run arbitrary code at a remote > node, now run it with remote node permissions. > Affected API: > - IgniteEvents, > - CQ, > - Compute, > - Services, > - Entry processor, > - Data Streamer, > - Scan Query, > - Cache load, > - Messaging, > - ... > So, the original security context now ignored at remote executions. > We have to > 1) Fix Security Engine to use original Security Context at remote executions > 2) Cover every securable public API (only most important list at phase #1) > with appropriate tests > - API required special permissions to be executed, should be checked to > require them > - Remote executions should be checked to be executed at the original Security > Context -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9560) Security Engine fixes and test coverage. Phase #1.
[ https://issues.apache.org/jira/browse/IGNITE-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9560: Security: (was: Private) > Security Engine fixes and test coverage. Phase #1. > -- > > Key: IGNITE-9560 > URL: https://issues.apache.org/jira/browse/IGNITE-9560 > Project: Ignite > Issue Type: Task > Components: security >Affects Versions: 2.6 >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.8 > > > Compute and other Public API, which able to run arbitrary code at a remote > node, now run it with remote node permissions. > Affected API: > - IgniteEvents, > - CQ, > - Compute, > - Services, > - Entry processor, > - Data Streamer, > - Scan Query, > - Cache load, > - Messaging, > - ... > So, the original security context now ignored at remote executions. > We have to > 1) Fix Security Engine to use original Security Context at remote executions > 2) Cover every securable public API (only most important list at phase #1) > with appropriate tests > - API required special permissions to be executed, should be checked to > require them > - Remote executions should be checked to be executed at the original Security > Context -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9349) Update Spring Data 2x and 1x and Spring 5x and 4x versions
[ https://issues.apache.org/jira/browse/IGNITE-9349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9349: Security: (was: Private) > Update Spring Data 2x and 1x and Spring 5x and 4x versions > -- > > Key: IGNITE-9349 > URL: https://issues.apache.org/jira/browse/IGNITE-9349 > Project: Ignite > Issue Type: Task > Components: spring >Affects Versions: 2.6 >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Critical > Labels: important, vulnerability > Fix For: 2.7 > > > CVE-2018-1257 - Spring Framework, versions 5.0.x prior to 5.0.6, versions > 4.3.x prior to 4.3.17-, needs to be fixed > CVE-2018-1258 - Spring Framework versions prior to 5.0.6, needs to be fixed > following vulnerabilities are actual for Ignite dependencies at the master > because spring version are 4.3.16 & 5.0.5 > CVE-2018-1259 - Spring Data Commons, versions 1.13 prior to 1.13.12 and 2.0 > prior to 2.0.7 > CVE-2018-1273 - Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 > to 2.0.5 > Spring-data and spring-data-2-0 need versions update. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8471: Security: (was: Private) > Apache ignite for .NET has security vulnerabilities > --- > > Key: IGNITE-8471 > URL: https://issues.apache.org/jira/browse/IGNITE-8471 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.4 >Reporter: Harendra Rai >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.5 > > > There are two security vulnerabilities in the latest 2.4.0 version. > # commons-beanutils-1.8.3.jar. Here is the vulnerability id CVE-2014-0114 : > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114] > *Resolution to this issue is*: All Commons BeanUtils users should upgrade to > the latest version >= commons-beanutils-1.9.2 > # commons-codec-1.6.jar: Here is the vulnerability detail > https://issues.apache.org/jira/browse/CODEC-96 > *Resolution* *to this issue is:* To upgrade to the latest available Version > 1.11 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8471: Labels: vulnerability (was: ) > Apache ignite for .NET has security vulnerabilities > --- > > Key: IGNITE-8471 > URL: https://issues.apache.org/jira/browse/IGNITE-8471 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.4 >Reporter: Harendra Rai >Assignee: Andrey N. Gura >Priority: Major > Labels: vulnerability > Fix For: 2.5 > > > There are two security vulnerabilities in the latest 2.4.0 version. > # commons-beanutils-1.8.3.jar. Here is the vulnerability id CVE-2014-0114 : > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114] > *Resolution to this issue is*: All Commons BeanUtils users should upgrade to > the latest version >= commons-beanutils-1.9.2 > # commons-codec-1.6.jar: Here is the vulnerability detail > https://issues.apache.org/jira/browse/CODEC-96 > *Resolution* *to this issue is:* To upgrade to the latest available Version > 1.11 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12927) The CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime is flacky
[
https://issues.apache.org/jira/browse/IGNITE-12927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089451#comment-17089451
]
Ignite TC Bot commented on IGNITE-12927:
{panel:title=Branch: [pull/7709/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5245270&buildTypeId=IgniteTests24Java8_RunAll]
> The CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime is flacky
> --
>
> Key: IGNITE-12927
> URL: https://issues.apache.org/jira/browse/IGNITE-12927
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime}} is
> flacky.
> [TC
> history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-448222889376376497&branch=%3Cdefault%3E&tab=testDetails]
> {noformat}
> java.lang.IllegalStateException: Duplicate key 1472820775 (attempted merging
> values 1472820775 and 1472820775)
> at
> java.base/java.util.stream.Collectors.duplicateKeyException(Collectors.java:133)
> at
> java.base/java.util.stream.Collectors.lambda$uniqKeysMapAccumulator$1(Collectors.java:180)
> at
> java.base/java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at
> java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180)
> at
> java.base/java.util.Random$RandomIntsSpliterator.forEachRemaining(Random.java:1044)
> at
> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:699)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalancingLastCancelledTime(CacheGroupsMetricsRebalanceTest.java:315)
> {noformat}
> The reason is that randomly generated keys can be duplicated and cant be
> collected from stream .
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8472: Security: (was: Private) > Apache ignite for .NET has security vulnerabilities > --- > > Key: IGNITE-8472 > URL: https://issues.apache.org/jira/browse/IGNITE-8472 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.4 >Reporter: Harendra Rai >Priority: Critical > > There are two vulnerabilities in the latest 2.3.0 version. > # commons-beanutils-1.8.3.jar. Here is the vulnerability id CVE-2014-0114 : > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114] > *Resolution to this issue is*: Upgrade Commons BeanUtils to the latest > version >= commons-beanutils-1.9.2 > # commons-codec-1.6.jar: Here is the vulnerability detail > https://issues.apache.org/jira/browse/CODEC-96 > *Resolution to this issue is:* To upgrade to the latest available Version 1.11 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8472: Component/s: (was: security) > Apache ignite for .NET has security vulnerabilities > --- > > Key: IGNITE-8472 > URL: https://issues.apache.org/jira/browse/IGNITE-8472 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Harendra Rai >Priority: Critical > > There are two vulnerabilities in the latest 2.3.0 version. > # commons-beanutils-1.8.3.jar. Here is the vulnerability id CVE-2014-0114 : > [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114] > *Resolution to this issue is*: Upgrade Commons BeanUtils to the latest > version >= commons-beanutils-1.9.2 > # commons-codec-1.6.jar: Here is the vulnerability detail > https://issues.apache.org/jira/browse/CODEC-96 > *Resolution to this issue is:* To upgrade to the latest available Version 1.11 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8565) Arbitrary code execution from GridClientJdkMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8565: Labels: vulnerability (was: ) > Arbitrary code execution from GridClientJdkMarshaller > - > > Key: IGNITE-8565 > URL: https://issues.apache.org/jira/browse/IGNITE-8565 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Denis A. Magda >Assignee: Andrey N. Gura >Priority: Blocker > Labels: vulnerability > Fix For: 2.6 > > > The reported issue is related to previously discovered and addressed > vulnerability: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1295 > The vulnerability can be exploited if the one sends a specially prepared form > of a serialized object to one of the deserialization endpoints of some Ignite > components. > It was noticed that some results ended up in the `GridClientJdkMarshaller`, > which is not protected by the measures that you put in place in > CVE-2018-1295: > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/marshaller/jdk/GridClientJdkMarshaller.java?#L66 > It looks like most of the results go through a polymorphic call of this > following function (i.e., from the 4th result): > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/impl/connection/GridClientConnectionManagerAdapter.java?sort=name&dir=ASC&mode=heatmap&showExcluded=false#L633 > Has to be mitigated using the same approach as in CVE-2018-1295. > Use the following CVE when will be reporting to Mitre: *CVE-2018-8018* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8565) Arbitrary code execution from GridClientJdkMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8565: Component/s: binary > Arbitrary code execution from GridClientJdkMarshaller > - > > Key: IGNITE-8565 > URL: https://issues.apache.org/jira/browse/IGNITE-8565 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Denis A. Magda >Assignee: Andrey N. Gura >Priority: Blocker > Fix For: 2.6 > > > The reported issue is related to previously discovered and addressed > vulnerability: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1295 > The vulnerability can be exploited if the one sends a specially prepared form > of a serialized object to one of the deserialization endpoints of some Ignite > components. > It was noticed that some results ended up in the `GridClientJdkMarshaller`, > which is not protected by the measures that you put in place in > CVE-2018-1295: > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/marshaller/jdk/GridClientJdkMarshaller.java?#L66 > It looks like most of the results go through a polymorphic call of this > following function (i.e., from the 4th result): > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/impl/connection/GridClientConnectionManagerAdapter.java?sort=name&dir=ASC&mode=heatmap&showExcluded=false#L633 > Has to be mitigated using the same approach as in CVE-2018-1295. > Use the following CVE when will be reporting to Mitre: *CVE-2018-8018* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8565) Arbitrary code execution from GridClientJdkMarshaller
[ https://issues.apache.org/jira/browse/IGNITE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8565: Security: (was: Private) > Arbitrary code execution from GridClientJdkMarshaller > - > > Key: IGNITE-8565 > URL: https://issues.apache.org/jira/browse/IGNITE-8565 > Project: Ignite > Issue Type: Bug >Reporter: Denis A. Magda >Assignee: Andrey N. Gura >Priority: Blocker > Fix For: 2.6 > > > The reported issue is related to previously discovered and addressed > vulnerability: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1295 > The vulnerability can be exploited if the one sends a specially prepared form > of a serialized object to one of the deserialization endpoints of some Ignite > components. > It was noticed that some results ended up in the `GridClientJdkMarshaller`, > which is not protected by the measures that you put in place in > CVE-2018-1295: > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/marshaller/jdk/GridClientJdkMarshaller.java?#L66 > It looks like most of the results go through a polymorphic call of this > following function (i.e., from the 4th result): > https://lgtm.com/projects/g/apache/ignite/snapshot/ef232f82e217ed104f1d2be282612727a47c79ee/files/modules/core/src/main/java/org/apache/ignite/internal/client/impl/connection/GridClientConnectionManagerAdapter.java?sort=name&dir=ASC&mode=heatmap&showExcluded=false#L633 > Has to be mitigated using the same approach as in CVE-2018-1295. > Use the following CVE when will be reporting to Mitre: *CVE-2018-8018* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10435) Remove dead code from IGNITE-9988
[ https://issues.apache.org/jira/browse/IGNITE-10435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10435: - Labels: vulnerability (was: ) > Remove dead code from IGNITE-9988 > - > > Key: IGNITE-10435 > URL: https://issues.apache.org/jira/browse/IGNITE-10435 > Project: Ignite > Issue Type: Task > Components: jdbc, security, thin client >Affects Versions: 2.7 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: vulnerability > Fix For: 2.8 > > > Some dead code remained after IGNITE-9988 implementation. Need to remove it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10435) Remove dead code from IGNITE-9988
[ https://issues.apache.org/jira/browse/IGNITE-10435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10435: - Security: (was: Private) > Remove dead code from IGNITE-9988 > - > > Key: IGNITE-10435 > URL: https://issues.apache.org/jira/browse/IGNITE-10435 > Project: Ignite > Issue Type: Task > Components: jdbc, security, thin client >Affects Versions: 2.7 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > > Some dead code remained after IGNITE-9988 implementation. Need to remove it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8931) Potential vulnerability with spring-messages
[ https://issues.apache.org/jira/browse/IGNITE-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8931: Labels: vulnerability (was: ) > Potential vulnerability with spring-messages > > > Key: IGNITE-8931 > URL: https://issues.apache.org/jira/browse/IGNITE-8931 > Project: Ignite > Issue Type: Bug > Components: spring >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Labels: vulnerability > Fix For: 2.6 > > > Potential vulnerability accordingly to > https://pivotal.io/security/cve-2018-1270 > Spring Framework dependencies should be upgraded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8931) Potential vulnerability with spring-messages
[ https://issues.apache.org/jira/browse/IGNITE-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8931: Security: (was: Private) > Potential vulnerability with spring-messages > > > Key: IGNITE-8931 > URL: https://issues.apache.org/jira/browse/IGNITE-8931 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.6 > > > Potential vulnerability accordingly to > https://pivotal.io/security/cve-2018-1270 > Spring Framework dependencies should be upgraded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8931) Potential vulnerability with spring-messages
[ https://issues.apache.org/jira/browse/IGNITE-8931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8931: Component/s: spring > Potential vulnerability with spring-messages > > > Key: IGNITE-8931 > URL: https://issues.apache.org/jira/browse/IGNITE-8931 > Project: Ignite > Issue Type: Bug > Components: spring >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.6 > > > Potential vulnerability accordingly to > https://pivotal.io/security/cve-2018-1270 > Spring Framework dependencies should be upgraded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9988) Thin client: integration with 3rd party security may not work properly
[ https://issues.apache.org/jira/browse/IGNITE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9988: Labels: security vulnerability (was: security) > Thin client: integration with 3rd party security may not work properly > -- > > Key: IGNITE-9988 > URL: https://issues.apache.org/jira/browse/IGNITE-9988 > Project: Ignite > Issue Type: Task > Components: security, sql >Affects Versions: 2.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: security, vulnerability > Fix For: 2.8 > > > Current thin client handler can delegate to 3rd party security if it is > enabled. However, it fails to set proper security context. As a result, > certain operations may remain unauthorized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9988) Thin client: integration with 3rd party security may not work properly
[ https://issues.apache.org/jira/browse/IGNITE-9988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-9988: Security: (was: Private) > Thin client: integration with 3rd party security may not work properly > -- > > Key: IGNITE-9988 > URL: https://issues.apache.org/jira/browse/IGNITE-9988 > Project: Ignite > Issue Type: Task > Components: security, sql >Affects Versions: 2.6 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: security > Fix For: 2.8 > > > Current thin client handler can delegate to 3rd party security if it is > enabled. However, it fails to set proper security context. As a result, > certain operations may remain unauthorized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12918) .NET: Add Travis job
[ https://issues.apache.org/jira/browse/IGNITE-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089441#comment-17089441 ] Maxim Muzafarov commented on IGNITE-12918: -- [~ptupitsyn] Sorry, I've missed that. Now I see. I've left some comments in PR. > .NET: Add Travis job > > > Key: IGNITE-12918 > URL: https://issues.apache.org/jira/browse/IGNITE-12918 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Add .NET build to .travis.yml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12931) General error: "java.lang.ArrayIndexOutOfBound
icode created IGNITE-12931: -- Summary: General error: "java.lang.ArrayIndexOutOfBound Key: IGNITE-12931 URL: https://issues.apache.org/jira/browse/IGNITE-12931 Project: Ignite Issue Type: Bug Reporter: icode Attachments: console.log Hi guys! I'm use ignite v2.8.0. I get the some error, please help me. Thanks. I find like this error in mailling list, but it different. Please see attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8984) Ignite 2.5 - Vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8984: Labels: security vulnerability (was: security) > Ignite 2.5 - Vulnerabilities > > > Key: IGNITE-8984 > URL: https://issues.apache.org/jira/browse/IGNITE-8984 > Project: Ignite > Issue Type: Bug >Reporter: Segu Riluvan >Assignee: Dmitry Pavlov >Priority: Major > Labels: security, vulnerability > Attachments: Ignite-Spark-Ignite_2_5_Blackduck_Scan_4_Github.xlsx, > Ignite_2_5_Blackduck_Scan_4_Github.zip > > > Recently we have scanned Apache Ignite 2.5 source code and all the associated > maven packages using Blackduck. The scan identified with many of the > dependencies for Ignite 2.5. Many of these vulnerabilities are rated as High > risk vulnerabilities. I've attached the vulnerability report to this ticket. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8984) Ignite 2.5 - Vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-8984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8984: Security: (was: Private) > Ignite 2.5 - Vulnerabilities > > > Key: IGNITE-8984 > URL: https://issues.apache.org/jira/browse/IGNITE-8984 > Project: Ignite > Issue Type: Bug >Reporter: Segu Riluvan >Assignee: Dmitry Pavlov >Priority: Major > Labels: security > Attachments: Ignite-Spark-Ignite_2_5_Blackduck_Scan_4_Github.xlsx, > Ignite_2_5_Blackduck_Scan_4_Github.zip > > > Recently we have scanned Apache Ignite 2.5 source code and all the associated > maven packages using Blackduck. The scan identified with many of the > dependencies for Ignite 2.5. Many of these vulnerabilities are rated as High > risk vulnerabilities. I've attached the vulnerability report to this ticket. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6643: Labels: secu (was: ) > Exploitable unsafe deserialization in Ignite cluster > > > Key: IGNITE-6643 > URL: https://issues.apache.org/jira/browse/IGNITE-6643 > Project: Ignite > Issue Type: Bug >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Blocker > Labels: secu > Fix For: 2.4 > > Attachments: ExampleNodeExploit.java, obj > > > The security breach was reported by an end-user: > https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e > This unsafe deserialization here can be used to attack any ignite node (not > require other pluggins enabled), happened during an incoming packet is parsed > (so probably pre-authentication) and can be attacked through the standard > ignite port (47500). > 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'. > 2. Run `ExampleNodeExploit` to send a malicious packet. > Remote code execution will happen when: > https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771 > calls the `JdkMarshaller` to deserializer the packet data. (The logging in > line 5760 also shows that this is a plausible scenario)This is easily > prevented as you know at compile time that this data is supposed to be an > instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent > unsafe deserialization in this case is fairly straightforward. > Please let me know if you need help or more information. Thanks. > *Vulnerabilities resolution process:* > https://www.apache.org/security/committers.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[
https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089434#comment-17089434
]
Ilya Kasnacheev edited comment on IGNITE-6643 at 4/22/20, 8:12 AM:
---
commit d268eb2573ad46efce8b6d9480b7c9c317b792cd
Author: Andrey Gura
Date: Mon Jan 22 22:41:54 2018 +0300
ignite-6643 Marshalling improvements
was (Author: ilyak):
{{
commit d268eb2573ad46efce8b6d9480b7c9c317b792cd
Author: Andrey Gura
Date: Mon Jan 22 22:41:54 2018 +0300
ignite-6643 Marshalling improvements
}}
> Exploitable unsafe deserialization in Ignite cluster
>
>
> Key: IGNITE-6643
> URL: https://issues.apache.org/jira/browse/IGNITE-6643
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis A. Magda
>Assignee: Denis A. Magda
>Priority: Blocker
> Fix For: 2.4
>
> Attachments: ExampleNodeExploit.java, obj
>
>
> The security breach was reported by an end-user:
> https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e
> This unsafe deserialization here can be used to attack any ignite node (not
> require other pluggins enabled), happened during an incoming packet is parsed
> (so probably pre-authentication) and can be attacked through the standard
> ignite port (47500).
> 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'.
> 2. Run `ExampleNodeExploit` to send a malicious packet.
> Remote code execution will happen when:
> https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771
> calls the `JdkMarshaller` to deserializer the packet data. (The logging in
> line 5760 also shows that this is a plausible scenario)This is easily
> prevented as you know at compile time that this data is supposed to be an
> instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent
> unsafe deserialization in this case is fairly straightforward.
> Please let me know if you need help or more information. Thanks.
> *Vulnerabilities resolution process:*
> https://www.apache.org/security/committers.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6643: Component/s: security > Exploitable unsafe deserialization in Ignite cluster > > > Key: IGNITE-6643 > URL: https://issues.apache.org/jira/browse/IGNITE-6643 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Blocker > Labels: secu > Fix For: 2.4 > > Attachments: ExampleNodeExploit.java, obj > > > The security breach was reported by an end-user: > https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e > This unsafe deserialization here can be used to attack any ignite node (not > require other pluggins enabled), happened during an incoming packet is parsed > (so probably pre-authentication) and can be attacked through the standard > ignite port (47500). > 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'. > 2. Run `ExampleNodeExploit` to send a malicious packet. > Remote code execution will happen when: > https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771 > calls the `JdkMarshaller` to deserializer the packet data. (The logging in > line 5760 also shows that this is a plausible scenario)This is easily > prevented as you know at compile time that this data is supposed to be an > instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent > unsafe deserialization in this case is fairly straightforward. > Please let me know if you need help or more information. Thanks. > *Vulnerabilities resolution process:* > https://www.apache.org/security/committers.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6643: Component/s: (was: security) binary > Exploitable unsafe deserialization in Ignite cluster > > > Key: IGNITE-6643 > URL: https://issues.apache.org/jira/browse/IGNITE-6643 > Project: Ignite > Issue Type: Bug > Components: binary >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Blocker > Labels: vulnerability > Fix For: 2.4 > > Attachments: ExampleNodeExploit.java, obj > > > The security breach was reported by an end-user: > https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e > This unsafe deserialization here can be used to attack any ignite node (not > require other pluggins enabled), happened during an incoming packet is parsed > (so probably pre-authentication) and can be attacked through the standard > ignite port (47500). > 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'. > 2. Run `ExampleNodeExploit` to send a malicious packet. > Remote code execution will happen when: > https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771 > calls the `JdkMarshaller` to deserializer the packet data. (The logging in > line 5760 also shows that this is a plausible scenario)This is easily > prevented as you know at compile time that this data is supposed to be an > instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent > unsafe deserialization in this case is fairly straightforward. > Please let me know if you need help or more information. Thanks. > *Vulnerabilities resolution process:* > https://www.apache.org/security/committers.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6643: Labels: vulnerability (was: secu) > Exploitable unsafe deserialization in Ignite cluster > > > Key: IGNITE-6643 > URL: https://issues.apache.org/jira/browse/IGNITE-6643 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Blocker > Labels: vulnerability > Fix For: 2.4 > > Attachments: ExampleNodeExploit.java, obj > > > The security breach was reported by an end-user: > https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e > This unsafe deserialization here can be used to attack any ignite node (not > require other pluggins enabled), happened during an incoming packet is parsed > (so probably pre-authentication) and can be attacked through the standard > ignite port (47500). > 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'. > 2. Run `ExampleNodeExploit` to send a malicious packet. > Remote code execution will happen when: > https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771 > calls the `JdkMarshaller` to deserializer the packet data. (The logging in > line 5760 also shows that this is a plausible scenario)This is easily > prevented as you know at compile time that this data is supposed to be an > instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent > unsafe deserialization in this case is fairly straightforward. > Please let me know if you need help or more information. Thanks. > *Vulnerabilities resolution process:* > https://www.apache.org/security/committers.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[
https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089434#comment-17089434
]
Ilya Kasnacheev commented on IGNITE-6643:
-
{{
commit d268eb2573ad46efce8b6d9480b7c9c317b792cd
Author: Andrey Gura
Date: Mon Jan 22 22:41:54 2018 +0300
ignite-6643 Marshalling improvements
}}
> Exploitable unsafe deserialization in Ignite cluster
>
>
> Key: IGNITE-6643
> URL: https://issues.apache.org/jira/browse/IGNITE-6643
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis A. Magda
>Assignee: Denis A. Magda
>Priority: Blocker
> Fix For: 2.4
>
> Attachments: ExampleNodeExploit.java, obj
>
>
> The security breach was reported by an end-user:
> https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e
> This unsafe deserialization here can be used to attack any ignite node (not
> require other pluggins enabled), happened during an incoming packet is parsed
> (so probably pre-authentication) and can be attacked through the standard
> ignite port (47500).
> 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'.
> 2. Run `ExampleNodeExploit` to send a malicious packet.
> Remote code execution will happen when:
> https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771
> calls the `JdkMarshaller` to deserializer the packet data. (The logging in
> line 5760 also shows that this is a plausible scenario)This is easily
> prevented as you know at compile time that this data is supposed to be an
> instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent
> unsafe deserialization in this case is fairly straightforward.
> Please let me know if you need help or more information. Thanks.
> *Vulnerabilities resolution process:*
> https://www.apache.org/security/committers.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6643) Exploitable unsafe deserialization in Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-6643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-6643: Security: (was: Private) > Exploitable unsafe deserialization in Ignite cluster > > > Key: IGNITE-6643 > URL: https://issues.apache.org/jira/browse/IGNITE-6643 > Project: Ignite > Issue Type: Bug >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Blocker > Fix For: 2.4 > > Attachments: ExampleNodeExploit.java, obj > > > The security breach was reported by an end-user: > https://mail-search.apache.org/pmc/private-arch/ignite-private/201710.mbox/%3cdda66c96-83c3-458b-abc7-ec89cff0f...@apache.org%3e > This unsafe deserialization here can be used to attack any ignite node (not > require other pluggins enabled), happened during an incoming packet is parsed > (so probably pre-authentication) and can be attacked through the standard > ignite port (47500). > 1. Start an ignite node e.g. with 'examples/config/example-ignite.xml'. > 2. Run `ExampleNodeExploit` to send a malicious packet. > Remote code execution will happen when: > https://lgtm.com/projects/g/apache/ignite/latest/files/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java?sort=name&dir=ASC&mode=list#L5771 > calls the `JdkMarshaller` to deserializer the packet data. (The logging in > line 5760 also shows that this is a plausible scenario)This is easily > prevented as you know at compile time that this data is supposed to be an > instance of `TcpDiscoveryAbstractMessage`, so checking the type and prevent > unsafe deserialization in this case is fairly straightforward. > Please let me know if you need help or more information. Thanks. > *Vulnerabilities resolution process:* > https://www.apache.org/security/committers.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12855) Node failed after get operation when entries from the cache expired concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089380#comment-17089380
]
Aleksey Plekhanov commented on IGNITE-12855:
[~akalashnikov] I've made fixes taking into account IGNITE-12594. Please have a
look again.
> Node failed after get operation when entries from the cache expired
> concurrently
> -
>
> Key: IGNITE-12855
> URL: https://issues.apache.org/jira/browse/IGNITE-12855
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed with the error:
> {noformat}
> [12:10:50] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter$6...@7c956694java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2456)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4401)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4095)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:767)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGetVersioned(GridCacheMapEntry.java:694)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2175)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:709)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:413)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:279)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:261)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:821)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:836)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:152)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> {noformat}
> Reproducer:
>
> {code:java}
> @Test
> public void shouldNotBeProblemToPutToExpiredCacheConcurrently() throws
> Exception {
> final AtomicBoolean end = new AtomicBoolean();
> final IgniteEx srv = startGrid(3);
> srv.cluster().active(true);
> IgniteInternalFuture loadFut = runMultiThreadedAsync(() -> {
> while (!end.get() && !fail) {
> IgniteCache cache = srv.cache(CACHE_NAME);
> for (int i = 0; i < ENTRIES; i++)
> cache.put(i, new byte[1024]);
> for (int i = 0; i < ENTRIES; i++)
> cache.get(i); // touch entries
> }
> }, WORKLOAD_THREADS_CNT, "high-workload");
>
[jira] [Commented] (IGNITE-12855) Node failed after get operation when entries from the cache expired concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089381#comment-17089381
]
Ignite TC Bot commented on IGNITE-12855:
{panel:title=Branch: [pull/7609/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5246488&buildTypeId=IgniteTests24Java8_RunAll]
> Node failed after get operation when entries from the cache expired
> concurrently
> -
>
> Key: IGNITE-12855
> URL: https://issues.apache.org/jira/browse/IGNITE-12855
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed with the error:
> {noformat}
> [12:10:50] (err) Failed to notify listener:
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter$6...@7c956694java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2456)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4401)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4095)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:767)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGetVersioned(GridCacheMapEntry.java:694)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2175)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:709)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:413)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:279)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:261)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:821)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:836)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:152)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:150)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> {noformat}
> Reproducer:
>
> {code:java}
> @Test
> public void shouldNotBeProblemToPutToExpiredCacheConcurrently() throws
> Exception {
> final AtomicBoolean end = new AtomicBoolean();
> final IgniteEx srv = startGrid(3);
> srv.cluster().active(true);
> IgniteInternalFuture loadFut = runMultiThreadedAsync(() -> {
> while (!end.get() && !fail) {
> IgniteCache cache = srv.cache(CACHE_NAME);
> for (int i = 0; i < ENTRIES; i++)
> cache.put(i, new byt
