[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in GirdKernalContextImpl.isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Summary: Cache "IGNITE_DAEMON" system properties in GirdKernalContextImpl.isDaemon call (was: Cache "IGNITE_DAEMON" system properties in isDaemon call) > Cache "IGNITE_DAEMON" system properties in GirdKernalContextImpl.isDaemon call > -- > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > !isDaemon.jpg! > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Attachment: isDaemon.jpg > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Attachment: (was: isDaemon.jpg) > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Description: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() !isDaemon.jpg! This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way was: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > !isDaemon.jpg! > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Description: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way was: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Description: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way was: In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() !isDaemon.jpg! This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > This is generated with the earlier version of Ignite, and when I examine the > latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
[ https://issues.apache.org/jira/browse/IGNITE-12842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sunny Chan updated IGNITE-12842: Attachment: isDaemon.jpg > Cache "IGNITE_DAEMON" system properties in isDaemon call > > > Key: IGNITE-12842 > URL: https://issues.apache.org/jira/browse/IGNITE-12842 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.7.6 >Reporter: Sunny Chan >Priority: Major > Attachments: isDaemon.jpg > > > In our performance tuning exercise using JFR, we have observed that when > accessing the cache, Ignite will repeatedly called System.getProperty in > GridKernalContextImpl.isDaemon() > !isDaemon.jpg! This is generated with the earlier version of Ignite, and when > I examine the latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12842) Cache "IGNITE_DAEMON" system properties in isDaemon call
Sunny Chan created IGNITE-12842: --- Summary: Cache "IGNITE_DAEMON" system properties in isDaemon call Key: IGNITE-12842 URL: https://issues.apache.org/jira/browse/IGNITE-12842 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.7.6 Reporter: Sunny Chan In our performance tuning exercise using JFR, we have observed that when accessing the cache, Ignite will repeatedly called System.getProperty in GridKernalContextImpl.isDaemon() !isDaemon.jpg! This is generated with the earlier version of Ignite, and when I examine the latest code it also behaving the same way -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
[
https://issues.apache.org/jira/browse/IGNITE-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068019#comment-17068019
]
Ignite TC Bot commented on IGNITE-12829:
{panel:title=Branch: [pull/7574/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=5158935buildTypeId=IgniteTests24Java8_RunAll]
> Custom GROUP_CONCAT separator is ignored
>
>
> Key: IGNITE-12829
> URL: https://issues.apache.org/jira/browse/IGNITE-12829
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12829-vs-2.8.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to [https://apacheignite-sql.readme.io/docs/group_concat]
> GROUP_CONCAT supports user-defined separator. Actually it is not supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12841) @Override must be on the same line as a method
[
https://issues.apache.org/jira/browse/IGNITE-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067998#comment-17067998
]
Ignite TC Bot commented on IGNITE-12841:
{panel:title=Branch: [pull/7578/head] Base: [master] : Possible Blockers
(113)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159915]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159954]]
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159980]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159944]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159968]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159943]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159914]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159906]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159965]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159964]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159945]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159913]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159887]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159940]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159929]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159911]]
{color:#d04437}Platform .NET{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159960]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159984]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159966]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159904]]
{color:#d04437}PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159957]]
{color:#d04437}Start Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159905]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159920]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159946]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159924]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159918]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159956]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159901]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159961]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159939]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159949]]
{color:#d04437}Basic 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159919]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159950]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159986]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159974]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159969]]
{color:#d04437}MVCC PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159983]]
{color:#d04437}Thin Client: Java{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159897]]
{color:#d04437}MVCC Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5159978]]
[jira] [Comment Edited] (IGNITE-12804) SQL: ConnectionManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-12804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067970#comment-17067970 ] Taras Ledkov edited comment on IGNITE-12804 at 3/26/20, 7:16 PM: - Benchmark results: performance drop about 2%-3%: sql-query benchmark (two runs): || master || patch || | 42786.50 | 41625.50 (-2.71%) | | 42629.80 | 41557.00 (-2.52%) | was (Author: tledkov-gridgain): Benchmark results: performance drop about 2%-3%: sql-query benchmark (two runs): || master || patch || | 42786.50 0.00% | 41625.50-2.71% | | 42629.80 0.00% | 41557.00-2.52% | > SQL: ConnectionManager refactoring > -- > > Key: IGNITE-12804 > URL: https://issues.apache.org/jira/browse/IGNITE-12804 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.8 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now ConnectionManager is a mess, really hard to understand. We should > refactor it. > Also ThreadLocal connection is a root cause of complicated behavior of local > queries & map queries. > I guess we have to use simple connection pool. > For better performance connection pools will be striped by Thread ID. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12804) SQL: ConnectionManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-12804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067970#comment-17067970 ] Taras Ledkov commented on IGNITE-12804: --- Benchmark results: performance drop about 2%-3%: sql-query benchmark (two runs): || master || patch || | 42786.50 0.00% | 41625.50-2.71% | | 42629.80 0.00% | 41557.00-2.52% | > SQL: ConnectionManager refactoring > -- > > Key: IGNITE-12804 > URL: https://issues.apache.org/jira/browse/IGNITE-12804 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.8 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now ConnectionManager is a mess, really hard to understand. We should > refactor it. > Also ThreadLocal connection is a root cause of complicated behavior of local > queries & map queries. > I guess we have to use simple connection pool. > For better performance connection pools will be striped by Thread ID. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067941#comment-17067941
]
Kartik Somani commented on IGNITE-12702:
Also, IgniteCache interface has 3 implementations. I'll have to write log in
each of these implementations, but won't be able to ensure that future
implementations will also do this.
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Assignee: Kartik Somani
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067939#comment-17067939
]
Kartik Somani commented on IGNITE-12702:
Thats true. Just that on every call of .put, i'll be going through all
attributes of value's type, to print warning that might be a rare event. Is the
performance cost worth it?
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Assignee: Kartik Somani
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067772#comment-17067772
]
Ignite TC Bot commented on IGNITE-12832:
{panel:title=Branch: [pull/7566/head] Base: [master] : Possible Blockers
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 1{color} [[tests 5 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5159002]]
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testLocalDataStreamerDedicatedThreadPool
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testCustomUserUpdater - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testLoaderApi - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testReplicatedIsolated - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testPartitionedMultiThreaded -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Thin Client: Java{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5158960]]
{color:#d04437}ZooKeeper{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5158973]]
* ZookeeperIpFinderTestSuite: ZookeeperIpFinderTest.testOneIgniteNodeIsAlone -
Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperIpFinderTestSuite: zk.ZookeeperIpFinderTest - History for base
branch is absent.
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testFourNodesRestartLastSeveralTimes - Test has low fail
rate in base branch 0,0% and is not flaky
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testFourNodesWithNoDuplicateRegistrations - Test has low
fail rate in base branch 0,0% and is not flaky
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testTwoIgniteNodesFindEachOther - Test has low fail rate
in base branch 0,0% and is not flaky
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testThreeNodesWithThreeDifferentConfigMethods - Test has
low fail rate in base branch 0,0% and is not flaky
* ZookeeperIpFinderTestSuite:
ZookeeperIpFinderTest.testFourNodesStartingAndStopping - Test has low fail rate
in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5159053buildTypeId=IgniteTests24Java8_RunAll]
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12826) Poor JDBC Cache Store performance due to default fetch size
[ https://issues.apache.org/jira/browse/IGNITE-12826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12826: - Fix Version/s: 2.9 > Poor JDBC Cache Store performance due to default fetch size > --- > > Key: IGNITE-12826 > URL: https://issues.apache.org/jira/browse/IGNITE-12826 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Fix For: 2.9 > > Attachments: ignite-12826-vs-2.8.patch > > Time Spent: 10m > Remaining Estimate: 0h > > JDBC "fetchSize" parameter specifies the number of rows to be fetched from > the database when additional rows are needed. For most drivers it is 10 by > default. Larger fetchSize can significantly improve performance due to less > network roundtrips (at expense of greater memory consumption). > For some reason out-of-box JDBC POJO Cache Store uses default fetchSize in > the loadCache method implementation. > We have very poor loadCache performance when loading large amount of data > from Oracle with the default fetchSize of 10. We tried setting fetchSize to > 20K and that improved performance 40 times. > We need to use JdbcDialect#fetchSize in the loadCache implementation so that > users could implement a custom JdbcDialect to configure fetchSIze. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12804) SQL: ConnectionManager refactoring
[ https://issues.apache.org/jira/browse/IGNITE-12804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067689#comment-17067689 ] Taras Ledkov commented on IGNITE-12804: --- Master base branch to benchmark: [PR7576|https://github.com/apache/ignite/pull/7576] > SQL: ConnectionManager refactoring > -- > > Key: IGNITE-12804 > URL: https://issues.apache.org/jira/browse/IGNITE-12804 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.8 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now ConnectionManager is a mess, really hard to understand. We should > refactor it. > Also ThreadLocal connection is a root cause of complicated behavior of local > queries & map queries. > I guess we have to use simple connection pool. > For better performance connection pools will be striped by Thread ID. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12841) @Override must be on the same line as a method
[
https://issues.apache.org/jira/browse/IGNITE-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ostanin reassigned IGNITE-12841:
-
Assignee: Oleg Ostanin
> @Override must be on the same line as a method
> --
>
> Key: IGNITE-12841
> URL: https://issues.apache.org/jira/browse/IGNITE-12841
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Oleg Ostanin
>Priority: Trivial
> Labels: newbie
>
> Right now, there are many places where codestyle broken.
> {noformat}
> /** {@inheritDoc} */
> @Override
> public boolean registerClassName(byte platformId, int typeId, String
> clsName) throws IgniteCheckedException {
> return registerClassName(platformId, typeId, clsName, false);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12841) @Override must be on the same line as a method
[
https://issues.apache.org/jira/browse/IGNITE-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12841:
-
Labels: newbie (was: )
> @Override must be on the same line as a method
> --
>
> Key: IGNITE-12841
> URL: https://issues.apache.org/jira/browse/IGNITE-12841
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Priority: Trivial
> Labels: newbie
>
> Right now, there are many places where codestyle broken.
> {noformat}
> /** {@inheritDoc} */
> @Override
> public boolean registerClassName(byte platformId, int typeId, String
> clsName) throws IgniteCheckedException {
> return registerClassName(platformId, typeId, clsName, false);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12841) @Override must be on the same line as a method
Nikolay Izhikov created IGNITE-12841:
Summary: @Override must be on the same line as a method
Key: IGNITE-12841
URL: https://issues.apache.org/jira/browse/IGNITE-12841
Project: Ignite
Issue Type: Bug
Reporter: Nikolay Izhikov
Right now, there are many places where codestyle broken.
{noformat}
/** {@inheritDoc} */
@Override
public boolean registerClassName(byte platformId, int typeId, String
clsName) throws IgniteCheckedException {
return registerClassName(platformId, typeId, clsName, false);
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12832) Add user attributes support to control.sh
[
https://issues.apache.org/jira/browse/IGNITE-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067671#comment-17067671
]
Ignite TC Bot commented on IGNITE-12832:
{panel:title=Branch: [pull/7566/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Licenses Headers]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5158756]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5158819buildTypeId=IgniteTests24Java8_RunAll]
> Add user attributes support to control.sh
> -
>
> Key: IGNITE-12832
> URL: https://issues.apache.org/jira/browse/IGNITE-12832
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
> Time Spent: 3h
> Remaining Estimate: 0h
>
> Change [1] introduced user attributes for various thin clients.
> {{control.sh|bat}} script uses {{GridClient}} to connect to cluster, but it's
> impossible to set user attributes in corresponding
> {{GridClientConfiguration}} currenly. I suggest to add {{.properties}} file
> support, so that user attributes could be set in a file specified by
> {{--user-attrs-file /path/to/filename.properties}} as {{attrName=attrValue}}
> lines.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12839) IGNITE-12789 broke WALRecordSerializationTest
[ https://issues.apache.org/jira/browse/IGNITE-12839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067662#comment-17067662 ] Ivan Bessonov commented on IGNITE-12839: [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3192056576753991319=%3Cdefault%3E=testDetails_IgniteTests24Java8=pull%2F7573%2Fhead] > IGNITE-12789 broke WALRecordSerializationTest > - > > Key: IGNITE-12839 > URL: https://issues.apache.org/jira/browse/IGNITE-12839 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3192056576753991319=%3Cdefault%3E=testDetails] > > Sorry, too bad that I skipped it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12839) IGNITE-12789 broke WALRecordSerializationTest
[
https://issues.apache.org/jira/browse/IGNITE-12839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067659#comment-17067659
]
Ignite TC Bot commented on IGNITE-12839:
{panel:title=Branch: [pull/7573/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=5158220buildTypeId=IgniteTests24Java8_RunAll]
> IGNITE-12789 broke WALRecordSerializationTest
> -
>
> Key: IGNITE-12839
> URL: https://issues.apache.org/jira/browse/IGNITE-12839
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3192056576753991319=%3Cdefault%3E=testDetails]
>
> Sorry, too bad that I skipped it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12826) Poor JDBC Cache Store performance due to default fetch size
[ https://issues.apache.org/jira/browse/IGNITE-12826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12826: Assignee: Nikolay Izhikov (was: Alexey Kukushkin) > Poor JDBC Cache Store performance due to default fetch size > --- > > Key: IGNITE-12826 > URL: https://issues.apache.org/jira/browse/IGNITE-12826 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Attachments: ignite-12826-vs-2.8.patch > > > JDBC "fetchSize" parameter specifies the number of rows to be fetched from > the database when additional rows are needed. For most drivers it is 10 by > default. Larger fetchSize can significantly improve performance due to less > network roundtrips (at expense of greater memory consumption). > For some reason out-of-box JDBC POJO Cache Store uses default fetchSize in > the loadCache method implementation. > We have very poor loadCache performance when loading large amount of data > from Oracle with the default fetchSize of 10. We tried setting fetchSize to > 20K and that improved performance 40 times. > We need to use JdbcDialect#fetchSize in the loadCache implementation so that > users could implement a custom JdbcDialect to configure fetchSIze. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12702) Print warning when a cache value contains @AffinityKeyMapped annotation
[
https://issues.apache.org/jira/browse/IGNITE-12702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067610#comment-17067610
]
Denis Mekhanikov commented on IGNITE-12702:
---
I only see a possibility to write such warnings when IgniteCache#put is
performed. But we need to throttle such messages and make sure that no
performance impact is going to be introduced in this case. For log throttling
check out the following class: GridLogThrottle
Alternatively it can be a moment of type registration. But as far as I know, we
don't propagate the information whether the object is going to be used as a key
or a value to the code that performs the type registration.
> Print warning when a cache value contains @AffinityKeyMapped annotation
> ---
>
> Key: IGNITE-12702
> URL: https://issues.apache.org/jira/browse/IGNITE-12702
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Denis Mekhanikov
>Assignee: Kartik Somani
>Priority: Major
> Labels: newbie
>
> Consider the following code snippet:
> {code:java}
> public class WrongAffinityExample {
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache =
> ignite.getOrCreateCache("employees");
> EmployeeKey key = new EmployeeKey(1);
> EmployeeValue value = new EmployeeValue(1, "Denis");
> cache.put(key, value);
> }
> public static class EmployeeKey {
> private int id;
> public EmployeeKey(int id) {
> this.id = id;
> }
> }
> public static class EmployeeValue {
> @AffinityKeyMapped
> int departmentId;
> String name;
> public EmployeeValue(int departmentId, String name) {
> this.departmentId = departmentId;
> this.name = name;
> }
> }
> }
> {code}
> Note, that {{EmployeeValue}} contains an {{@AffinityKeyMapped}} annotation,
> which doesn't have any effect, since it's specified in a value, and not in a
> key.
> Such mistake is simple to make and pretty hard to track down.
> This configuration should trigger a warning message printed in log to let
> the user know that this affinity key configuration is not applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12783) Partition state validation warnings erroneously logged when cache groups are used
[
https://issues.apache.org/jira/browse/IGNITE-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067601#comment-17067601
]
Stepachev Maksim commented on IGNITE-12783:
---
[~slava.koptilin] Hi, LGTM!
> Partition state validation warnings erroneously logged when cache groups are
> used
> -
>
> Key: IGNITE-12783
> URL: https://issues.apache.org/jira/browse/IGNITE-12783
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that IGNITE-12206 does not cover all possible cases. For instance,
> the following cache configurations are still validated and therefore it may
> be the reason for erroneously warning.
> {code:java}
> String grpName = "test-group";
> CacheConfiguration cfg1 = new CacheConfiguration<>("cache-1")
> .setBackups(1)
> .setGroupName(grpName);
> CacheConfiguration cfg2 = new CacheConfiguration<>("cache-2")
> .setBackups(1)
> .setExpiryPolicyFactory(AccessedExpiryPolicy.factoryOf(new
> Duration(TimeUnit.SECONDS, 1)))
> .setGroupName(grpName);
> {code}
> The following code takes into account only the first cache configuration for
> a particular cache group:
> {code:java|title=GridDhtPartitionsExchangeFuture#validatePartitionsState()}
> CacheGroupContext grpCtx = cctx.cache().cacheGroup(grpDesc.groupId());
> ...
> // Do not validate read or write through caches or caches with disabled
> rebalance
> // or ExpiryPolicy is set or validation is disabled.
> boolean eternalExpiryPolicy = grpCtx != null &&
> (grpCtx.config().getExpiryPolicyFactory() == null
> || grpCtx.config().getExpiryPolicyFactory().create() instanceof
> EternalExpiryPolicy);
>
> if (grpCtx == null
> ...
> || !eternalExpiryPolicy
> return null; // It means that validation should not be triggered.
> {code}
> The obvious way to fix the issue is to check all the configurations included
> in the cache group as follows:
> {code:java|title=GridDhtPartitionsExchangeFuture#validatePartitionsState()}
> CacheGroupContext grpCtx = cctx.cache().cacheGroup(grpDesc.groupId());
> ...
> boolean customExpiryPolicy = Optional.ofNullable(grpCtx)
> .map((v) -> v.caches())
> .orElseGet(() -> Collections.emptyList())
> .stream()
> .anyMatch(ctx -> ctx.expiry() != null && !(ctx.expiry() instanceof
> EternalExpiryPolicy));
> if (grpCtx == null
> ...
> || customExpityPolicy
> return null; // It means that validation should not be triggered.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12828) Intermittent [Failed to notify direct custom event listener] exception on node shutdown
[
https://issues.apache.org/jira/browse/IGNITE-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12828:
-
Description:
+*Reproducer*+:
Run a server node
Run a client node that:
* Creates cache "cache1"
* Deploys a grid service that starts a continuous query against "cache1" in
method init()
* Leaves the cluster
+*Actual result*+
Intermittent exception in the client node:
{noformat}
[16:54:38,758][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
Failed to notify direct custom event listener: StartRoutineDiscoveryMessage
[startReqData=StartRequestData
[prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@63ae71a9,
clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler
[returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@594bf5b8,
cacheName=CALC_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false,
notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true,
taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true,
ackBuf=null, cacheId=-1608655250, initTopVer=null, nodeLeft=false,
ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0,
autoUnsubscribe=true], keepBinary=true,
routineId=021dd2ce-3d8a-41c1-a4d0-b625ea1284f4]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
at
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2683)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2721)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:745)
[16:54:39,725][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
Failed to notify direct custom event listener: StartRoutineDiscoveryMessage
[startReqData=StartRequestData
[prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@7462c96c,
clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler
[returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@6451dd70,
cacheName=DISTRIBUTED_REQUESTS, rmtFilter=null, rmtFilterDep=null,
internal=false, notifyExisting=false, oldValRequired=true, sync=false,
ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false,
keepBinary=true, ackBuf=null, cacheId=1419803136, initTopVer=null,
nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null],
bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true,
routineId=1fca5f04-d220-49ac-850a-0d4527e22eef]
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
at
org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202)
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
at
[jira] [Commented] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
[ https://issues.apache.org/jira/browse/IGNITE-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067555#comment-17067555 ] Nikolay Izhikov commented on IGNITE-12829: -- Hello, [~rkondakov]. Can you, please, take a look at my changes? PR - https://github.com/apache/ignite/pull/7574 > Custom GROUP_CONCAT separator is ignored > > > Key: IGNITE-12829 > URL: https://issues.apache.org/jira/browse/IGNITE-12829 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Fix For: 2.9 > > Attachments: ignite-12829-vs-2.8.patch > > Time Spent: 10m > Remaining Estimate: 0h > > According to [https://apacheignite-sql.readme.io/docs/group_concat] > GROUP_CONCAT supports user-defined separator. Actually it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12783) Partition state validation warnings erroneously logged when cache groups are used
[
https://issues.apache.org/jira/browse/IGNITE-12783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067549#comment-17067549
]
Vyacheslav Koptilin commented on IGNITE-12783:
--
Hello [~mstepachev],
Could you please take a look at this PR?
> Partition state validation warnings erroneously logged when cache groups are
> used
> -
>
> Key: IGNITE-12783
> URL: https://issues.apache.org/jira/browse/IGNITE-12783
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that IGNITE-12206 does not cover all possible cases. For instance,
> the following cache configurations are still validated and therefore it may
> be the reason for erroneously warning.
> {code:java}
> String grpName = "test-group";
> CacheConfiguration cfg1 = new CacheConfiguration<>("cache-1")
> .setBackups(1)
> .setGroupName(grpName);
> CacheConfiguration cfg2 = new CacheConfiguration<>("cache-2")
> .setBackups(1)
> .setExpiryPolicyFactory(AccessedExpiryPolicy.factoryOf(new
> Duration(TimeUnit.SECONDS, 1)))
> .setGroupName(grpName);
> {code}
> The following code takes into account only the first cache configuration for
> a particular cache group:
> {code:java|title=GridDhtPartitionsExchangeFuture#validatePartitionsState()}
> CacheGroupContext grpCtx = cctx.cache().cacheGroup(grpDesc.groupId());
> ...
> // Do not validate read or write through caches or caches with disabled
> rebalance
> // or ExpiryPolicy is set or validation is disabled.
> boolean eternalExpiryPolicy = grpCtx != null &&
> (grpCtx.config().getExpiryPolicyFactory() == null
> || grpCtx.config().getExpiryPolicyFactory().create() instanceof
> EternalExpiryPolicy);
>
> if (grpCtx == null
> ...
> || !eternalExpiryPolicy
> return null; // It means that validation should not be triggered.
> {code}
> The obvious way to fix the issue is to check all the configurations included
> in the cache group as follows:
> {code:java|title=GridDhtPartitionsExchangeFuture#validatePartitionsState()}
> CacheGroupContext grpCtx = cctx.cache().cacheGroup(grpDesc.groupId());
> ...
> boolean customExpiryPolicy = Optional.ofNullable(grpCtx)
> .map((v) -> v.caches())
> .orElseGet(() -> Collections.emptyList())
> .stream()
> .anyMatch(ctx -> ctx.expiry() != null && !(ctx.expiry() instanceof
> EternalExpiryPolicy));
> if (grpCtx == null
> ...
> || customExpityPolicy
> return null; // It means that validation should not be triggered.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
[ https://issues.apache.org/jira/browse/IGNITE-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067506#comment-17067506 ] Nikolay Izhikov commented on IGNITE-12829: -- I've checked the provided patch and it seems it doesn't fix the described issue. Moreover, all changes from patch already in Ignite master. > Custom GROUP_CONCAT separator is ignored > > > Key: IGNITE-12829 > URL: https://issues.apache.org/jira/browse/IGNITE-12829 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Attachments: ignite-12829-vs-2.8.patch > > > According to [https://apacheignite-sql.readme.io/docs/group_concat] > GROUP_CONCAT supports user-defined separator. Actually it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12840) Leaking H2 internals when querying from pyignite
[ https://issues.apache.org/jira/browse/IGNITE-12840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-12840: - Attachment: test_insert_in_cache.py read_cache_insert_update_table.py TEST_TABLE.sql > Leaking H2 internals when querying from pyignite > > > Key: IGNITE-12840 > URL: https://issues.apache.org/jira/browse/IGNITE-12840 > Project: Ignite > Issue Type: Bug > Components: clients, python >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Priority: Critical > Fix For: 2.8.1 > > Attachments: TEST_TABLE.sql, read_cache_insert_update_table.py, > test_insert_in_cache.py > > > I am sharing a slightly modified reproducer from userlist. > To run: > Start a node (with JVM_OPTS=-Xmx512m to see it most clearly). > Run a .sql file with sqlline (!run) > python3 test_insert_in_cache.py > in parallel terminal: python3 read_cache_insert_update_table.py > Then you should observe slowing down and long GC pauses on server node. jmap > will collect ever-increasing heap dumps. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12840) Leaking H2 internals when querying from pyignite
Ilya Kasnacheev created IGNITE-12840: Summary: Leaking H2 internals when querying from pyignite Key: IGNITE-12840 URL: https://issues.apache.org/jira/browse/IGNITE-12840 Project: Ignite Issue Type: Bug Components: clients, python Affects Versions: 2.8 Reporter: Ilya Kasnacheev Fix For: 2.8.1 I am sharing a slightly modified reproducer from userlist. To run: Start a node (with JVM_OPTS=-Xmx512m to see it most clearly). Run a .sql file with sqlline (!run) python3 test_insert_in_cache.py in parallel terminal: python3 read_cache_insert_update_table.py Then you should observe slowing down and long GC pauses on server node. jmap will collect ever-increasing heap dumps. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
[ https://issues.apache.org/jira/browse/IGNITE-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067494#comment-17067494 ] Nikolay Izhikov commented on IGNITE-12829: -- Hello, [~kukushal] Thank you for reporting this issue and providing a patch for it. As long as this patch requires some additional work I assigned a ticket to myself if you don't mind. > Custom GROUP_CONCAT separator is ignored > > > Key: IGNITE-12829 > URL: https://issues.apache.org/jira/browse/IGNITE-12829 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Attachments: ignite-12829-vs-2.8.patch > > > According to [https://apacheignite-sql.readme.io/docs/group_concat] > GROUP_CONCAT supports user-defined separator. Actually it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12829) Custom GROUP_CONCAT separator is ignored
[ https://issues.apache.org/jira/browse/IGNITE-12829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12829: Assignee: Nikolay Izhikov (was: Alexey Kukushkin) > Custom GROUP_CONCAT separator is ignored > > > Key: IGNITE-12829 > URL: https://issues.apache.org/jira/browse/IGNITE-12829 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Nikolay Izhikov >Priority: Major > Labels: sbcf > Attachments: ignite-12829-vs-2.8.patch > > > According to [https://apacheignite-sql.readme.io/docs/group_concat] > GROUP_CONCAT supports user-defined separator. Actually it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[ https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067446#comment-17067446 ] Ilya Shishkov commented on IGNITE-12831: [~ktkale...@gridgain.com], thank you for your doc editions, now it looks more understandable. > Invoking destroy of local cache on one node destroys local caches with the > same name on all other nodes > --- > > Key: IGNITE-12831 > URL: https://issues.apache.org/jira/browse/IGNITE-12831 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8, 2.7.6 >Reporter: Ilya Shishkov >Priority: Major > Attachments: MyLocalCacheDestroyReproducer.java > > > If you create caches with cache mode CacheMode.LOCAL and same name, but on > different nodes, then all those caches will be destroyed after invoking > destroy of cache on one of the cluster nodes. > Expected behaviour: local cache should be destroyed only on the node invoking > destroy. > Reproducer in attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067438#comment-17067438
]
Sergei Ryzhov commented on IGNITE-12220:
[~mstepachev], [~garus.d.g] Thanks for the review.
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[ https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067436#comment-17067436 ] Ilya Shishkov commented on IGNITE-12831: [~antonovsergey93], [~ktkale...@gridgain.com], as I see, you are right, local caches has cluster-wide behaviour, and created and destroyed on all nodes. But from the point of ordinary Apache Ignite user, the above phrase very implicitly tells us about behaviour of create and destroy procedures. So, IMHO, we should add to documentation some warnings about add/destroy, and about that fact, that local caches are deprecated and will be removed from Apache Ignite 3.0 and are strictly 'not recommended' for use in production. > Invoking destroy of local cache on one node destroys local caches with the > same name on all other nodes > --- > > Key: IGNITE-12831 > URL: https://issues.apache.org/jira/browse/IGNITE-12831 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8, 2.7.6 >Reporter: Ilya Shishkov >Priority: Major > Attachments: MyLocalCacheDestroyReproducer.java > > > If you create caches with cache mode CacheMode.LOCAL and same name, but on > different nodes, then all those caches will be destroyed after invoking > destroy of cache on one of the cluster nodes. > Expected behaviour: local cache should be destroyed only on the node invoking > destroy. > Reproducer in attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[ https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067435#comment-17067435 ] Kirill Tkalenko commented on IGNITE-12831: -- Documentation has been updated. > Invoking destroy of local cache on one node destroys local caches with the > same name on all other nodes > --- > > Key: IGNITE-12831 > URL: https://issues.apache.org/jira/browse/IGNITE-12831 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8, 2.7.6 >Reporter: Ilya Shishkov >Priority: Major > Attachments: MyLocalCacheDestroyReproducer.java > > > If you create caches with cache mode CacheMode.LOCAL and same name, but on > different nodes, then all those caches will be destroyed after invoking > destroy of cache on one of the cluster nodes. > Expected behaviour: local cache should be destroyed only on the node invoking > destroy. > Reproducer in attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12833) JDBC thin client SELECT hangs under 2.8.0
[
https://issues.apache.org/jira/browse/IGNITE-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-12833:
Component/s: jdbc
> JDBC thin client SELECT hangs under 2.8.0
> -
>
> Key: IGNITE-12833
> URL: https://issues.apache.org/jira/browse/IGNITE-12833
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, security
>Affects Versions: 2.8
>Reporter: Veena Mithare
>Priority: Major
> Labels: iep-41
> Attachments: JdbcSelectHangsIn2.8.0Mail.txt
>
>
> |
> |When security is enabled, and an update or select sql is issued from
> dbeaver, the security context in
> class GridIOManager ,
> method -createGridIoMessage -
> line - ctx.security().securityContext() returns the securitycontext of the
> thin client.
> The message generated out of createGridIoMessage is passed on to the next
> node.
> This is used in
> class - IgniteSecurityProcessor
> method - ( withContext)
> line - ctx.discovery().node(uuid)
> on the next node :
> @Override public OperationSecurityContext withContext(UUID nodeId)
> { return withContext( secCtxs.computeIfAbsent(nodeId,
>
> uuid -> nodeSecurityContext( marsh,
> U.resolveClassLoader(ctx.config()), ctx.discovery().node(uuid)
> ) ) ); }
> The ctx.discovery().node(uuid) used to
> determine the ClusterNode that is passed into nodeSecurityContext() returns
> null, since the uuid is that of the remote client id not the remote node id.
> Hence
> class: SecurityUtils.java
> method : nodeSecurityContext
> line : byte[] subjBytes =
> node.attribute(IgniteNodeAttributes.ATTR_SECURITY_SUBJECT_V2);
> Throws null pointer exception since node is null.
> Related ticket :
> IGNITE-12579
>
> Related discussion :
> [http://apache-ignite-users.70518.x6.nabble.com/2-8-0-JDBC-Thin-Client-Unable-to-load-the-tables-via-DBeaver-td31681.html#a31847]|
> |
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4683308buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4866965buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4760823buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4793573]]
* ZookeeperDiscoverySpiTestSuite3:
CacheContinuousQueryOperationP2PTest.testTxClient - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4793518]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperClientTest.testReconnect1_InCallback - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4793545]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4793595buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4724635buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4707966buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4793595buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067414#comment-17067414
]
Ivan Pavlukhin commented on IGNITE-12766:
-
[~slava.koptilin], the patch looks good to me. Thank you!
> Node startup can be broken in case of using Local cache with persistence
> enabled.
> -
>
> Key: IGNITE-12766
> URL: https://issues.apache.org/jira/browse/IGNITE-12766
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
> example) may result in the following exception when Local cache is used and
> persistence enabled.
> {code}
> [2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
> processors, node will be stopped and close connections[2020-03-05
> 16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: An error occurred during cache
> configuration loading from file [file=...] at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
> 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.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to find class
> with given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
> cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
> ... 18 moreCaused by: java.lang.ClassNotFoundException:
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1826)
> at
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4637637buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4637637buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-12220:
--
Comment: was deleted
(was: {panel:title=Branch: [pull/6904/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=4637637buildTypeId=IgniteTests24Java8_RunAll])
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12839) IGNITE-12789 broke WALRecordSerializationTest
Ivan Bessonov created IGNITE-12839: -- Summary: IGNITE-12789 broke WALRecordSerializationTest Key: IGNITE-12839 URL: https://issues.apache.org/jira/browse/IGNITE-12839 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3192056576753991319=%3Cdefault%3E=testDetails] Sorry, too bad that I skipped it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[ https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066813#comment-17066813 ] Ilya Shishkov edited comment on IGNITE-12831 at 3/26/20, 6:09 AM: -- May be it should be noted that local caches are not recommended and deprecated? was (Author: shishkovilja): May it should be noted that local caches are not recommended and deprecated? > Invoking destroy of local cache on one node destroys local caches with the > same name on all other nodes > --- > > Key: IGNITE-12831 > URL: https://issues.apache.org/jira/browse/IGNITE-12831 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8, 2.7.6 >Reporter: Ilya Shishkov >Priority: Major > Attachments: MyLocalCacheDestroyReproducer.java > > > If you create caches with cache mode CacheMode.LOCAL and same name, but on > different nodes, then all those caches will be destroyed after invoking > destroy of cache on one of the cluster nodes. > Expected behaviour: local cache should be destroyed only on the node invoking > destroy. > Reproducer in attachment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
