[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954721#comment-16954721 ] Zane Hu commented on IGNITE-10959: -- We hit this issue too. Is it possible to have a quick fix patch soon? Thanks! > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12142) Ignite ignores that on-heap store is disabled when putting values through near cache
[
https://issues.apache.org/jira/browse/IGNITE-12142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954677#comment-16954677
]
Bartłomiej Stefański edited comment on IGNITE-12142 at 10/18/19 3:44 PM:
-
[~dmagda] I've done some debugging today. From what I found:
-if near cache is created then reader is added to server.- each entry added by
near cache to cache have a reader on server. Server node uses reader to update
near cache when value is changed on server.
During eviction, Ignite invokes this line:
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheMapEntry.java#L4598]
So, when near cache is enabled condition will be evaluated to false, because
reader exists. That is why eviction do not remove entries from cache.
Can you confirm that what I wrote is true? Is it a bug? Do you plan to fix it?
was (Author: bstefanski):
[~dmagda] I've done some debugging today. From what I found:
if near cache is created then reader is added to server. Server node uses
reader to update near cache when value is changed on server.
During eviction, Ignite invokes this line:
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheMapEntry.java#L4598]
So, when near cache is enabled condition will be evaluated to false, because
reader exists. That is why eviction do not remove entries from cache.
Can you confirm that what I wrote is true? Is it a bug? Do you plan to fix it?
> Ignite ignores that on-heap store is disabled when putting values through
> near cache
>
>
> Key: IGNITE-12142
> URL: https://issues.apache.org/jira/browse/IGNITE-12142
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7, 2.7.5
>Reporter: Bartłomiej Stefański
>Priority: Major
>
> I have an Ignite cluster that consists of two nodes:
> * @n0 - server node
> * @n1 - client node
> Installed PARTITIONED cache {{myCache}} on both of them. Cache has near cache
> on client node and disabled on-heap caching on server.
> Server configuration:
> {code:xml}
>
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>
>
>
>
> {code}
> Client configuration:
> {code:xml}
>
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
> class="org.apache.ignite.configuration.NearCacheConfiguration">
>
> class="org.apache.ignite.cache.eviction.lru.LruEvictionPolicy">
>
>
>
>
>
>
>
>
>
>
> {code}
> I have noticed (using visor) strange cache state after putting 20k entries to
> that cache through client node (@n1):
> {code}
> +==+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
> Size (Primary / Backup)| Hi/Mi/Rd/Wr |
> +==+
> | 99E64885(@n0), 172.17.0.1 | 4| 2.56 %| 0.50 % | 00:02:47.615 |
> Total: 4 (4 / 0) | Hi: 0 |
> | | | | | |
> Heap: 2 (2 / ) | Mi: 0 |
> | | | | | |
> Off-Heap: 2 (2 / 0) | Rd: 0 |
> | | | | | |
> Off-Heap Memory: | Wr: 0 |
> +---+--+---+--+--+---+-+
> |
[jira] [Comment Edited] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954690#comment-16954690 ] Trung edited comment on IGNITE-10959 at 10/18/19 3:27 PM: -- We're affected by this issue as well. Memory is leaked at an alarming rate. See the attached continuousquery_leak_profile.png for the profile result of where the leaks are, They're all in byte[] buffers inside BinaryObjectImpl inside CacheContinuousQueryEntry, was (Author: tdo): We're affected by this issue as well. Memory is leaked at an alarming rate. See the attached continuousquery_leak_profile.png for the profile result of where the leaks are, They're all in byte[] buffers of BinaryObjectImpl inside CacheContinuousQueryEntry, > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954690#comment-16954690 ] Trung commented on IGNITE-10959: We're affected by this issue as well. Memory is leaked at an alarming rate. See the attached continuousquery_leak_profile.png for the profile result of where the leaks are, They're all in byte[] buffers of BinaryObjectImpl inside CacheContinuousQueryEntry, > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trung updated IGNITE-10959: --- Attachment: continuousquery_leak_profile.png > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java, > continuousquery_leak_profile.png > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trung updated IGNITE-10959: --- Attachment: MicrosoftTeams-image.png > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10959) Memory leaks in continuous query handlers
[ https://issues.apache.org/jira/browse/IGNITE-10959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trung updated IGNITE-10959: --- Attachment: (was: MicrosoftTeams-image.png) > Memory leaks in continuous query handlers > - > > Key: IGNITE-10959 > URL: https://issues.apache.org/jira/browse/IGNITE-10959 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.9 > > Attachments: CacheContinuousQueryMemoryUsageTest.java > > > Continuous query handlers don't clear internal data structures after cache > events are processed. > A test, that reproduces the problem, is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12142) Ignite ignores that on-heap store is disabled when putting values through near cache
[
https://issues.apache.org/jira/browse/IGNITE-12142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954677#comment-16954677
]
Bartłomiej Stefański commented on IGNITE-12142:
---
[~dmagda] I've done some debugging today. From what I found:
if near cache is created then reader is added to server. Server node uses
reader to update near cache when value is changed on server.
During eviction, Ignite invokes this line:
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheMapEntry.java#L4598]
So, when near cache is enabled condition will be evaluated to false, because
reader exists. That is why eviction do not remove entries from cache.
Can you confirm that what I wrote is true? Is it a bug? Do you plan to fix it?
> Ignite ignores that on-heap store is disabled when putting values through
> near cache
>
>
> Key: IGNITE-12142
> URL: https://issues.apache.org/jira/browse/IGNITE-12142
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7, 2.7.5
>Reporter: Bartłomiej Stefański
>Priority: Major
>
> I have an Ignite cluster that consists of two nodes:
> * @n0 - server node
> * @n1 - client node
> Installed PARTITIONED cache {{myCache}} on both of them. Cache has near cache
> on client node and disabled on-heap caching on server.
> Server configuration:
> {code:xml}
>
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
>
>
>
>
> {code}
> Client configuration:
> {code:xml}
>
> http://www.springframework.org/schema/beans;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
>http://www.springframework.org/schema/beans
>http://www.springframework.org/schema/beans/spring-beans.xsd;>
>
>
>
>
> class="org.apache.ignite.configuration.CacheConfiguration">
>
>
>
>
> class="org.apache.ignite.configuration.NearCacheConfiguration">
>
> class="org.apache.ignite.cache.eviction.lru.LruEvictionPolicy">
>
>
>
>
>
>
>
>
>
>
> {code}
> I have noticed (using visor) strange cache state after putting 20k entries to
> that cache through client node (@n1):
> {code}
> +==+
> | Node ID8(@), IP | CPUs | Heap Used | CPU Load | Up Time|
> Size (Primary / Backup)| Hi/Mi/Rd/Wr |
> +==+
> | 99E64885(@n0), 172.17.0.1 | 4| 2.56 %| 0.50 % | 00:02:47.615 |
> Total: 4 (4 / 0) | Hi: 0 |
> | | | | | |
> Heap: 2 (2 / ) | Mi: 0 |
> | | | | | |
> Off-Heap: 2 (2 / 0) | Rd: 0 |
> | | | | | |
> Off-Heap Memory: | Wr: 0 |
> +---+--+---+--+--+---+-+
> | FE7BEE4F(@n1), 172.17.0.1 | 4| 3.89 %| 3.10 % | 00:02:37.269 |
> Total: 1000 (1000 / 0)| Hi: 0 |
> | | | | | |
> Heap: 1000 (1000 / ) | Mi: 0 |
> | | | | | |
> Off-Heap: 0 (0 / 0) | Rd: 0 |
> | | | | | |
> Off-Heap Memory: 0 | Wr: 0 |
> +--+
> {code}
> Why Ignite stores entries on heap space on server node? If I put 20k entries
> through server node then server on-heap space is not used:
> {code}
>
[jira] [Commented] (IGNITE-11724) IgniteSpark integration forget to close the IgniteContext and stops the client node in case if error during PairFunction logic
[
https://issues.apache.org/jira/browse/IGNITE-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954588#comment-16954588
]
Nikolay Izhikov commented on IGNITE-11724:
--
Hello [~aealeksandrov], [~zaleslaw]
I don't understand what the issue here.
Ignite instance close on {{IgniteContext#close}}.
Why do you think we should close it on the exception in {{savePairs}}?
> IgniteSpark integration forget to close the IgniteContext and stops the
> client node in case if error during PairFunction logic
> ---
>
> Key: IGNITE-11724
> URL: https://issues.apache.org/jira/browse/IGNITE-11724
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.8
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Zinoviev
>Priority: Major
> Labels: await
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Next code could hang in case if PairFunction logic will throw the exception:
> {code:java}
> JavaPairRDD rdd_records = records.mapToPair(new MapFunction());
> JavaIgniteContext igniteContext = new
> JavaIgniteContext<>(sparkCtx, configUrl);
> JavaIgniteRDD igniteRdd = igniteContext. Value>fromCache(cacheName);
> igniteRdd.savePairs(rdd_records);
> Looks like next internal code (saveValues method)should also close the
> IgniteContext in case of an unexpected exception, not only data streamer:
> try {
> it.foreach(value ⇒
> { val key = affinityKeyFunc(value, node.orNull)
> streamer.addData(key, value) }
> )
> }
> finally
> { streamer.close() }
> })
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11724) IgniteSpark integration forget to close the IgniteContext and stops the client node in case if error during PairFunction logic
[
https://issues.apache.org/jira/browse/IGNITE-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11724:
-
Description:
Next code could hang in case if PairFunction logic will throw the exception:
{code:java}
JavaPairRDD rdd_records = records.mapToPair(new MapFunction());
JavaIgniteContext igniteContext = new JavaIgniteContext<>(sparkCtx,
configUrl);
JavaIgniteRDD igniteRdd = igniteContext.fromCache(cacheName);
igniteRdd.savePairs(rdd_records);
Looks like next internal code (saveValues method)should also close the
IgniteContext in case of an unexpected exception, not only data streamer:
try {
it.foreach(value ⇒
{ val key = affinityKeyFunc(value, node.orNull)
streamer.addData(key, value) }
)
}
finally
{ streamer.close() }
})
}
{code}
was:
Next code could hang in case if PairFunction logic will throw the exception:
JavaPairRDD rdd_records = records.mapToPair(new MapFunction());
JavaIgniteContext igniteContext = new JavaIgniteContext<>(sparkCtx,
configUrl);
JavaIgniteRDD igniteRdd = igniteContext.fromCache(cacheName);
igniteRdd.savePairs(rdd_records);
Looks like next internal code (saveValues method)should also close the
IgniteContext in case of an unexpected exception, not only data streamer:
try {
it.foreach(value ⇒ {
val key = affinityKeyFunc(value, node.orNull)
streamer.addData(key, value)
})
}
finally {
streamer.close()
}
})
}
> IgniteSpark integration forget to close the IgniteContext and stops the
> client node in case if error during PairFunction logic
> ---
>
> Key: IGNITE-11724
> URL: https://issues.apache.org/jira/browse/IGNITE-11724
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Affects Versions: 2.8
>Reporter: Andrey Aleksandrov
>Assignee: Alexey Zinoviev
>Priority: Major
> Labels: await
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Next code could hang in case if PairFunction logic will throw the exception:
> {code:java}
> JavaPairRDD rdd_records = records.mapToPair(new MapFunction());
> JavaIgniteContext igniteContext = new
> JavaIgniteContext<>(sparkCtx, configUrl);
> JavaIgniteRDD igniteRdd = igniteContext. Value>fromCache(cacheName);
> igniteRdd.savePairs(rdd_records);
> Looks like next internal code (saveValues method)should also close the
> IgniteContext in case of an unexpected exception, not only data streamer:
> try {
> it.foreach(value ⇒
> { val key = affinityKeyFunc(value, node.orNull)
> streamer.addData(key, value) }
> )
> }
> finally
> { streamer.close() }
> })
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11087) GridJobCheckpointCleanupSelfTest.testCheckpointCleanup is flaky
[
https://issues.apache.org/jira/browse/IGNITE-11087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954567#comment-16954567
]
Nikolai Kulagin commented on IGNITE-11087:
--
[~mmuzaf], please, review my change.
> GridJobCheckpointCleanupSelfTest.testCheckpointCleanup is flaky
> ---
>
> Key: IGNITE-11087
> URL: https://issues.apache.org/jira/browse/IGNITE-11087
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Attachments: #removeCheckpoint is called once more.txt,
> #removeCheckpoint isn't called.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The method of remove a checkpoint is sometimes not called or is called once
> more. Test has a very low fail rate, 1 per 366 runs on
> [TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7655052229521669617=testDetails_IgniteTests24Java8=%3Cdefault%3E]
> and 1 per 412 on TC Bot. On local machine approximately 1 failure per 100
> runs. Logs in the attachment.
> Test is flaky for a long time. Before replacing IP Finder in IGNITE-10555,
> test was slower, which made fail rate even less.
>
> {code:java}
> [2019-01-25 14:49:03,050][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
>
> [^#removeCheckpoint isn't called.txt]
> ^_^
>
> {code:java}
> [2019-01-25 14:50:03,282][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<-1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
> [^#removeCheckpoint is called once more.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12302) Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is broken.
[
https://issues.apache.org/jira/browse/IGNITE-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954555#comment-16954555
]
Amelchev Nikita commented on IGNITE-12302:
--
[~alex_pl], could you take a look, please?
> Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is
> broken.
> -
>
> Key: IGNITE-12302
> URL: https://issues.apache.org/jira/browse/IGNITE-12302
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test checks that a new node will not be started with the same node id.
> Newly added SystemView creates table on node startup and fails with error:
> {noformat}
> java.lang.AssertionError: Unexpected exception
> at
> org.apache.ignite.testframework.GridTestUtils.fail(GridTestUtils.java:622)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:465)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:582)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2090)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
> system view.
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1401)
> 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.start(IgnitionEx.java:615)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:983)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:924)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:912)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:878)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.lambda$testDuplicatedNodeId$0(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:583)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:449)
> ... 11 more
> Caused by: class org.apache.ignite.IgniteException: Failed to register system
> view.
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemView(SchemaManager.java:238)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemViews(SchemaManager.java:247)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.start(SchemaManager.java:195)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:2083)
> [2019-10-17 21:50:42,017][INFO ][main][root] >>> Stopping test:
> ZookeeperDiscoveryTopologyChangeAndReconnectTest#testDuplicatedNodeId in 261
> ms <<<
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:250)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1977)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1213)
> ... 21 more
> Caused by: org.h2.jdbc.JdbcSQLException: Таблица "NODE_ATTRIBUTES" уже
> существует
> Table "NODE_ATTRIBUTES" already exists; SQL statement:
> CREATE TABLE NODE_ATTRIBUTES(NODE_ID UUID, NAME VARCHAR, VALUE VARCHAR)
> ENGINE
> "org.apache.ignite.internal.processors.query.h2.sys.SqlSystemTableEngine"
> [42101-197]
> at
[jira] [Commented] (IGNITE-11087) GridJobCheckpointCleanupSelfTest.testCheckpointCleanup is flaky
[
https://issues.apache.org/jira/browse/IGNITE-11087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954546#comment-16954546
]
Ignite TC Bot commented on IGNITE-11087:
{panel:title=Branch: [pull/6987/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=4707285buildTypeId=IgniteTests24Java8_RunAll]
> GridJobCheckpointCleanupSelfTest.testCheckpointCleanup is flaky
> ---
>
> Key: IGNITE-11087
> URL: https://issues.apache.org/jira/browse/IGNITE-11087
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: MakeTeamcityGreenAgain
> Attachments: #removeCheckpoint is called once more.txt,
> #removeCheckpoint isn't called.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The method of remove a checkpoint is sometimes not called or is called once
> more. Test has a very low fail rate, 1 per 366 runs on
> [TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7655052229521669617=testDetails_IgniteTests24Java8=%3Cdefault%3E]
> and 1 per 412 on TC Bot. On local machine approximately 1 failure per 100
> runs. Logs in the attachment.
> Test is flaky for a long time. Before replacing IP Finder in IGNITE-10555,
> test was slower, which made fail rate even less.
>
> {code:java}
> [2019-01-25 14:49:03,050][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
>
> [^#removeCheckpoint isn't called.txt]
> ^_^
>
> {code:java}
> [2019-01-25 14:50:03,282][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: expected:<-1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at
> org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
> at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748){code}
> [^#removeCheckpoint is called once more.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11992) Improvements for new security approach
[ https://issues.apache.org/jira/browse/IGNITE-11992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954545#comment-16954545 ] Stepachev Maksim commented on IGNITE-11992: --- The point 3, was removed. https://github.com/apache/ignite/pull/6990/files > Improvements for new security approach > -- > > Key: IGNITE-11992 > URL: https://issues.apache.org/jira/browse/IGNITE-11992 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 50m > Remaining Estimate: 0h > > 1. The visor tasks lost permission. > The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses > context. > 2. The GridRestProcessor does tasks outside "withContext" section. As result > context loses. > In additional: > Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and > CacheQueryReadEvent. > "Gets security subject ID initiated this task event, if available. > This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET > task event. > Subject ID will be set either to node ID or client ID initiated task > execution." > by: > "Gets security subject ID initiated this task event if IgniteSecurity is > enabled, otherwise returns null." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11992) Improvements for new security approach
[ https://issues.apache.org/jira/browse/IGNITE-11992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11992: -- Description: 1. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 2. The GridRestProcessor does tasks outside "withContext" section. As result context loses. In additional: Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and CacheQueryReadEvent. "Gets security subject ID initiated this task event, if available. This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET task event. Subject ID will be set either to node ID or client ID initiated task execution." by: "Gets security subject ID initiated this task event if IgniteSecurity is enabled, otherwise returns null." was: 1. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 2. The GridRestProcessor does tasks outside "withContext" section. As result context loses. 3. The GridRestProcessor isn't client, we can't read security subject from node attribute. We should transmit secCtx for fake nodes and secSubjId for real. In additional: Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and CacheQueryReadEvent. "Gets security subject ID initiated this task event, if available. This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET task event. Subject ID will be set either to node ID or client ID initiated task execution." by: "Gets security subject ID initiated this task event if IgniteSecurity is enabled, otherwise returns null." > Improvements for new security approach > -- > > Key: IGNITE-11992 > URL: https://issues.apache.org/jira/browse/IGNITE-11992 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 1. The visor tasks lost permission. > The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses > context. > 2. The GridRestProcessor does tasks outside "withContext" section. As result > context loses. > In additional: > Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and > CacheQueryReadEvent. > "Gets security subject ID initiated this task event, if available. > This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET > task event. > Subject ID will be set either to node ID or client ID initiated task > execution." > by: > "Gets security subject ID initiated this task event if IgniteSecurity is > enabled, otherwise returns null." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12302) Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is broken.
[
https://issues.apache.org/jira/browse/IGNITE-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954485#comment-16954485
]
Amelchev Nikita commented on IGNITE-12302:
--
Fixed test by disabling registering system views.
Optimized test speed by decreasing server join tries counts.
Added correct SPI exception check.
> Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is
> broken.
> -
>
> Key: IGNITE-12302
> URL: https://issues.apache.org/jira/browse/IGNITE-12302
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test checks that a new node will not be started with the same node id.
> Newly added SystemView creates table on node startup and fails with error:
> {noformat}
> java.lang.AssertionError: Unexpected exception
> at
> org.apache.ignite.testframework.GridTestUtils.fail(GridTestUtils.java:622)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:465)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:582)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2090)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
> system view.
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1401)
> 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.start(IgnitionEx.java:615)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:983)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:924)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:912)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:878)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.lambda$testDuplicatedNodeId$0(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:583)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:449)
> ... 11 more
> Caused by: class org.apache.ignite.IgniteException: Failed to register system
> view.
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemView(SchemaManager.java:238)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemViews(SchemaManager.java:247)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.start(SchemaManager.java:195)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:2083)
> [2019-10-17 21:50:42,017][INFO ][main][root] >>> Stopping test:
> ZookeeperDiscoveryTopologyChangeAndReconnectTest#testDuplicatedNodeId in 261
> ms <<<
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:250)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1977)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1213)
> ... 21 more
> Caused by: org.h2.jdbc.JdbcSQLException: Таблица "NODE_ATTRIBUTES" уже
> существует
> Table "NODE_ATTRIBUTES" already exists; SQL statement:
> CREATE TABLE NODE_ATTRIBUTES(NODE_ID UUID, NAME VARCHAR, VALUE VARCHAR)
> ENGINE
>
[jira] [Created] (IGNITE-12303) Change comment for an enumeration item CACHE_DESTROY
Surkov Aleksandr created IGNITE-12303: - Summary: Change comment for an enumeration item CACHE_DESTROY Key: IGNITE-12303 URL: https://issues.apache.org/jira/browse/IGNITE-12303 Project: Ignite Issue Type: Wish Components: documentation, security Reporter: Surkov Aleksandr For the _org.apache.ignite.plugin.security.SecurityPermission#CACHE_DESTROY_ enumeration element it would be worth changing the comment. "Cache create permission." it's not very good. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12302) Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is broken.
[
https://issues.apache.org/jira/browse/IGNITE-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954477#comment-16954477
]
Ignite TC Bot commented on IGNITE-12302:
{panel:title=Branch: [pull/6986/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=4705571buildTypeId=IgniteTests24Java8_RunAll]
> Test ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId is
> broken.
> -
>
> Key: IGNITE-12302
> URL: https://issues.apache.org/jira/browse/IGNITE-12302
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test checks that a new node will not be started with the same node id.
> Newly added SystemView creates table on node startup and fails with error:
> {noformat}
> java.lang.AssertionError: Unexpected exception
> at
> org.apache.ignite.testframework.GridTestUtils.fail(GridTestUtils.java:622)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:465)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.testDuplicatedNodeId(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:582)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2090)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to register
> system view.
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1401)
> 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.start(IgnitionEx.java:615)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:983)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:924)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:912)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:878)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryTopologyChangeAndReconnectTest.lambda$testDuplicatedNodeId$0(ZookeeperDiscoveryTopologyChangeAndReconnectTest.java:583)
> at
> org.apache.ignite.testframework.GridTestUtils.assertThrowsAnyCause(GridTestUtils.java:449)
> ... 11 more
> Caused by: class org.apache.ignite.IgniteException: Failed to register system
> view.
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemView(SchemaManager.java:238)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.createSystemViews(SchemaManager.java:247)
> at
> org.apache.ignite.internal.processors.query.h2.SchemaManager.start(SchemaManager.java:195)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:2083)
> [2019-10-17 21:50:42,017][INFO ][main][root] >>> Stopping test:
> ZookeeperDiscoveryTopologyChangeAndReconnectTest#testDuplicatedNodeId in 261
> ms <<<
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:250)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1977)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1213)
> ... 21 more
> Caused by: org.h2.jdbc.JdbcSQLException: Таблица "NODE_ATTRIBUTES" уже
> существует
> Table "NODE_ATTRIBUTES" already
[jira] [Commented] (IGNITE-12232) NPE while node join processing
[ https://issues.apache.org/jira/browse/IGNITE-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954385#comment-16954385 ] Aleksey Plekhanov commented on IGNITE-12232: [~SomeFire], LGTM, merged to master. Thanks for your contribution! > NPE while node join processing > -- > > Key: IGNITE-12232 > URL: https://issues.apache.org/jira/browse/IGNITE-12232 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7.6 >Reporter: PetrovMikhail >Assignee: Ryabov Dmitrii >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > ServerImpl.RingMessageWorker#processNodeAddedMessage method throws npe > exception in case DiscoverySpiNodeAuthenticator#authenticateNode returns null. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12240) ReadOnlyCollectionView2X fails on iterator.next
[
https://issues.apache.org/jira/browse/IGNITE-12240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954319#comment-16954319
]
Venkata commented on IGNITE-12240:
--
[~kcheng.mvp] If you are ok. can i submit the fix?
> ReadOnlyCollectionView2X fails on iterator.next
> ---
>
> Key: IGNITE-12240
> URL: https://issues.apache.org/jira/browse/IGNITE-12240
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: kcheng.mvp
>Priority: Major
> Labels: newbie
>
> Simple reproducer below will throw {{NoSuchElementException}}.
> Iterator only works if one call {{hasNext}} before {{next}}.
> {code:java}
> /** */
> @Test
> public void testReadOnlyCollection() throws Exception {
> Collection c1 = Collections.emptyList();
> Collection c2 = Arrays.asList("1");
> ReadOnlyCollectionView2X view = new
> ReadOnlyCollectionView2X<>(c1, c2);
> assertEquals("1", view.iterator().next());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
