[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809524#comment-16809524
]
Ivan Pavlukhin commented on IGNITE-11412:
-
Also one concern about {{nameRule}} came to mind. It might that it is located
in a superclass in order to guarantee that it is called before other rules
(junit 4 specifics). If it is so we can consider other options to guarantee the
order or add a comment explaining why it should be placed in a superclass.
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11131) Invalid use of static system properties in AffinityAssignment
[
https://issues.apache.org/jira/browse/IGNITE-11131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry reassigned IGNITE-11131:
---
Assignee: Dmitry
> Invalid use of static system properties in AffinityAssignment
> -
>
> Key: IGNITE-11131
> URL: https://issues.apache.org/jira/browse/IGNITE-11131
> Project: Ignite
> Issue Type: Task
>Reporter: Alexei Scherbakov
>Assignee: Dmitry
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> Recently added properties
> {{org.apache.ignite.internal.processors.affinity.AffinityAssignment#IGNITE_AFFINITY_BACKUPS_THRESHOLD}}
> and
> {{org.apache.ignite.internal.processors.affinity.AffinityAssignment#IGNITE_DISABLE_AFFINITY_MEMORY_OPTIMIZATION}}
> have flaw - the are defined as static making it impossible to change between
> node restarts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809418#comment-16809418
]
Ignite TC Bot commented on IGNITE-11563:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3501046buildTypeId=IgniteTests24Java8_RunAll]
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[
https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809388#comment-16809388
]
Ignite TC Bot commented on IGNITE-11226:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux)*{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3500883]]
* dll: IgniteConfigurationTest.TestAllConfigurationProperties - 0,0% fails in
last 453 master runs.
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3500876]]
* IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRecoveryTest.testRecoveryLargeNoCheckpoint - 0,0% fails in last 325
master runs.
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3500864]]
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadOnlySafeWithPersistence[ATOMIC]
- 0,0% fails in last 206 master runs.
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
, Failure on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3500842]]
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3500846]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3500889]]
{color:#d04437}_Javadoc_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3500847]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3500912buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Remove GridQueryIndexing.prepareNativeStatement
>
>
> Key: IGNITE-11226
> URL: https://issues.apache.org/jira/browse/IGNITE-11226
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This method is the only leak of H2 internals to the outer code. Close
> analysis of code reveals that the only reason we have it is *JDBC metadata*.
> Need to create a method which will prepare metadata for a statement and
> return it as a detached object. Most probably we already have all necessary
> mechanics. This is more about refactoring.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809354#comment-16809354
]
Ignite TC Bot commented on IGNITE-7101:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3500925]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3500927]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3499260buildTypeId=IgniteTests24Java8_RunAll]
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11226) SQL: Remove GridQueryIndexing.prepareNativeStatement
[
https://issues.apache.org/jira/browse/IGNITE-11226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809240#comment-16809240
]
Pavel Kuznetsov commented on IGNITE-11226:
--
[~vozerov] Ok I've updated patch according to your comments
p2: Thanks, I forgot to update method signatures in the interface, fixed that.
Actually, in the methods themselves, we don't throw any exceptions, we rely on
the validation performed in the parser, which already sets
{{IgniteQueryErrorCode}} s. Should we catch them in the indexing and re-throw
with some other code?
p3: hm. Ok, I switched to {{IgniteCheckedException}} it means we hide original
reason (which is thrown by h2) from user. Is it ok?
> SQL: Remove GridQueryIndexing.prepareNativeStatement
>
>
> Key: IGNITE-11226
> URL: https://issues.apache.org/jira/browse/IGNITE-11226
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This method is the only leak of H2 internals to the outer code. Close
> analysis of code reveals that the only reason we have it is *JDBC metadata*.
> Need to create a method which will prepare metadata for a statement and
> return it as a detached object. Most probably we already have all necessary
> mechanics. This is more about refactoring.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809173#comment-16809173
]
Ignite TC Bot commented on IGNITE-7101:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3499191]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3499241]]
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3499194]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3499237]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3499186]]
{color:#d04437}Platform .NET (Core Linux)*{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3499231]]
* dll:
IgniteProductVersionTests.TestClientVersionIsMoreOrEqualsServerNodeVersion
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3499183]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectMultinodeLongHistory - 0,0% fails
in last 337 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3499260buildTypeId=IgniteTests24Java8_RunAll]
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809114#comment-16809114 ] Alexei Scherbakov edited comment on IGNITE-11614 at 4/3/19 6:58 PM: Looks like small window of race is still possible for first approach but it's smaller than in second. was (Author: ascherbakov): Looks like small window of race is still possible for first approach but it's smalle than in second. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809114#comment-16809114 ] Alexei Scherbakov commented on IGNITE-11614: Looks like small window of race is still possible for first approach but it's smalle than in second. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809106#comment-16809106 ] Alexei Scherbakov commented on IGNITE-11614: [~agoncharuk] This would work too, but I prefer first because it removes race with rollback by tx timeout. rollbackNearTxLocalAsync will be called only once. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Bolyandra updated IGNITE-11614: -- Comment: was deleted (was: This would work too, but for me first is better because it removes race with rollback by tx timeout.) > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809101#comment-16809101 ] Konstantin Bolyandra commented on IGNITE-11614: --- This would work too, but for me first is better because it removes race with rollback by tx timeout. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809095#comment-16809095
]
Ivan Pavlukhin commented on IGNITE-11412:
-
[~ivanan.fed], I am looking at
{{TestJUnit3TestLegacySupport/TestConditionsAware}} class and cannot figure out
it purpose. Currently it contains definitions of our custom _before/after_
methods and a {{getName}} method. And it is funny that _before/after_ methods
are not used in that class at all. I think that we can get rid of this class
and put it's content into {{GridAbstractTest}}. What do you think about it?
Another minor but in my mind useful thing is renaming
{{GridAbstractTest.setUp/tearDown}} to something more specific to avoid
confustion with standard junit {{setUp/tearDown}}. I can imagine naming like
{{setUp -> prepareTestEnvironment, tearDown -> cleanupTestEnvironment}}.
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[
https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809026#comment-16809026
]
Alexey Goncharuk commented on IGNITE-11614:
---
[~ascherbakov], {{prepFut}} check looks a bit narrow, I will try the following
one:
{code}
if (state != COMMITTING && state != ROLLING_BACK && (!trackTimeout || rmv ||
state == MARKED_ROLLBACK))
rollbackNearTxLocalAsync(clearThreadMap, false).get();
{code}
> Transaction with timeout on cache hangs after cache store failure
> -
>
> Key: IGNITE-11614
> URL: https://issues.apache.org/jira/browse/IGNITE-11614
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Anton Kurbanov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: CacheStoreTxPutAllMultiNodeTest.java
>
>
> If CacheStore fails before/during transaction commit, transaction with set
> timeout remains active.
> Setting cfg.setTransactionConfiguration(new
> TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes
> the issue in test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8382) Problem with ignite-spring-data and Spring Boot 2
[
https://issues.apache.org/jira/browse/IGNITE-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808972#comment-16808972
]
Tim Shea commented on IGNITE-8382:
--
We are hitting this too... and I tracked it down to Java cache-api 1.1.0 used
by spring and 1.0.0 used by the ignite API (and core). This causes items
serialized by the core (built by you) to failed to deserialize in the client
(which gets upgraded to 1.1.0 when packaged with spring-boot application). I
looked at the other issue mentioned and do not see that it would fix this.
I pulled ignite 2.7.0, upgraded cache-api to 1.1.0 in the parent pom and built
it fine. I ran the basic test suite and it all passed. I think Ignite can
safely make this change to be compatible with spring boot (only the most
popular web framework for JVM out there). Please consider making this change.
BTW due to corporate rules I cannot use my build of Ignite to solve this issue
for us. :/
> Problem with ignite-spring-data and Spring Boot 2
> -
>
> Key: IGNITE-8382
> URL: https://issues.apache.org/jira/browse/IGNITE-8382
> Project: Ignite
> Issue Type: Bug
> Components: spring
>Affects Versions: 2.4
>Reporter: Patrice R
>Priority: Major
>
> Hi,
> I've tried to update to Spring Boot 2 using an IgniteRepository (from
> ignite-spring-data) and I got the following exception during the start.
> The same code with Spring Boot 1.5.9 is working.
>
> {color:#FF}_***_{color}
> {color:#FF}_APPLICATION FAILED TO START_{color}
> {color:#FF}_***_{color}
> {color:#FF}_Description:_{color}
> {color:#FF}_Parameter 0 of constructor in
> org.apache.ignite.springdata.repository.support.IgniteRepositoryImpl required
> a bean of type 'org.apache.ignite.IgniteCache' that could not be
> found._{color}
> {color:#FF}_Action:_{color}
> {color:#FF}_Consider defining a bean of type
> 'org.apache.ignite.IgniteCache' in your configuration._{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808883#comment-16808883
]
Ivan Rakov edited comment on IGNITE-10896 at 4/3/19 4:13 PM:
-
[~Denis Chudov],
1.
{code:java}
try {
Pattern.compile(cacheName);
} catch (PatternSyntaxException e) {
throw new RuntimeException(format("Invalid cache name regexp
'%s': %s", cacheName, e.getMessage()));
}
{code}
catch should be on separate line
2. As I see from the code, cache filtering actually works on group names as
well. Let's mention it in --cache help output.
3. Let's cover by test that non-trivial cache filter (e.g. PERSISTENT) works
simultaneously with regexp filtering.
4. I agree with Sergey on his points 5 and 6. A descriptive message should be
displayed in case there are no caches that match the filter.
5. "idle_verify task args were following" - doesn't it sound a bit rough? What
about "idle_verify task was executed with the following args"?
was (Author: ivan.glukos):
[~Denis Chudov],
1.
{code:java}
try {
Pattern.compile(cacheName);
} catch (PatternSyntaxException e) {
throw new RuntimeException(format("Invalid cache name regexp
'%s': %s", cacheName, e.getMessage()));
}
{code}
catch should be on separate line
2. As I see from the code, cache filtering actually works on group names as
well. Let's mention it in --cache help output.
3. Let's cover that non-trivial cache filter (e.g. PERSISTENT) works
simultaneously with regexp filtering.
4. I agree with Sergey on his points 5 and 6. A descriptive message should be
displayed in case there are no caches that match the filter.
5. "idle_verify task args were following" - doesn't it sound a bit rough? What
about "idle_verify task was executed with the following args"?
> Add ability to use simultaneous cache filtering options with control.sh
> --cache idle_verify
> ---
>
> Key: IGNITE-10896
> URL: https://issues.apache.org/jira/browse/IGNITE-10896
> Project: Ignite
> Issue Type: Improvement
>Reporter: ARomantsov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Now I can use only one of next options
> 1) --exclude-caches cache1,...,cacheN
> 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
> 3) cache1,...,cacheN
> Trying to use two or more of this options currently results in error:
> {noformat}
> Error: Should use only one of option: --excludeCaches, --cache-filter or pass
> caches explicitly
> {noformat}
> Instead, utility should do the following:
> 1) when two or more options specified, result cache set to make dump of
> should be logical AND of results of each option applied individually.
> ex.
> {noformat}
> cache.* --cache-filter PERSISTENT
> {noformat}
> should select all persistent caches starting from 'cache'
> {noformat}
>--cache-filter ALL
>--exclude-caches wrong-.*-caches
> {noformat}
> should select all caches but matching 'wrong-.*-caches' regexp
> etc.
> 2) filtering options passed to control utility should be logged into result
> dump file, so that user could understand that dump was taken from subset of
> cluster caches
> 3) when result of filter or filters AND'ing is empty set of cache names,
> proper error message should be given and no dump file generated.
> e.g.
> {noformat}Error: can't find any cache matching cache names '--skup-zerus' and
> cache filter 'PERSISTENT', dump won't be generated.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808883#comment-16808883
]
Ivan Rakov edited comment on IGNITE-10896 at 4/3/19 4:12 PM:
-
[~Denis Chudov],
1.
{code:java}
try {
Pattern.compile(cacheName);
} catch (PatternSyntaxException e) {
throw new RuntimeException(format("Invalid cache name regexp
'%s': %s", cacheName, e.getMessage()));
}
{code}
catch should be on separate line
2. As I see from the code, cache filtering actually works on group names as
well. Let's mention it in --cache help output.
3. Let's cover that non-trivial cache filter (e.g. PERSISTENT) works
simultaneously with regexp filtering.
4. I agree with Sergey on his points 5 and 6. A descriptive message should be
displayed in case there are no caches that match the filter.
5. "idle_verify task args were following" - doesn't it sound a bit rough? What
about "idle_verify task was executed with the following args"?
was (Author: ivan.glukos):
[~Denis Chudov],
1.
{code:java}
try {
Pattern.compile(cacheName);
} catch (PatternSyntaxException e) {
throw new RuntimeException(format("Invalid cache name regexp
'%s': %s", cacheName, e.getMessage()));
}
{code}
catch should be on separate line
2. As I see from the code, cache filtering actually works on group names as
well. Let's meтtion it in --cache help output.
3. Let's cover that non-trivial cache filter (e.g. PERSISTENT) works
simultaneously with regexp filtering.
4. I agree with Sergey on his points 5 and 6. A descriptive message should be
displayed in case there are no caches that match the filter.
5. "idle_verify task args were following" - doesn't it sound a bit rough? What
about "idle_verify task was executed with the following args"?
> Add ability to use simultaneous cache filtering options with control.sh
> --cache idle_verify
> ---
>
> Key: IGNITE-10896
> URL: https://issues.apache.org/jira/browse/IGNITE-10896
> Project: Ignite
> Issue Type: Improvement
>Reporter: ARomantsov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Now I can use only one of next options
> 1) --exclude-caches cache1,...,cacheN
> 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
> 3) cache1,...,cacheN
> Trying to use two or more of this options currently results in error:
> {noformat}
> Error: Should use only one of option: --excludeCaches, --cache-filter or pass
> caches explicitly
> {noformat}
> Instead, utility should do the following:
> 1) when two or more options specified, result cache set to make dump of
> should be logical AND of results of each option applied individually.
> ex.
> {noformat}
> cache.* --cache-filter PERSISTENT
> {noformat}
> should select all persistent caches starting from 'cache'
> {noformat}
>--cache-filter ALL
>--exclude-caches wrong-.*-caches
> {noformat}
> should select all caches but matching 'wrong-.*-caches' regexp
> etc.
> 2) filtering options passed to control utility should be logged into result
> dump file, so that user could understand that dump was taken from subset of
> cluster caches
> 3) when result of filter or filters AND'ing is empty set of cache names,
> proper error message should be given and no dump file generated.
> e.g.
> {noformat}Error: can't find any cache matching cache names '--skup-zerus' and
> cache filter 'PERSISTENT', dump won't be generated.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10896) Add ability to use simultaneous cache filtering options with control.sh --cache idle_verify
[
https://issues.apache.org/jira/browse/IGNITE-10896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808883#comment-16808883
]
Ivan Rakov commented on IGNITE-10896:
-
[~Denis Chudov],
1.
{code:java}
try {
Pattern.compile(cacheName);
} catch (PatternSyntaxException e) {
throw new RuntimeException(format("Invalid cache name regexp
'%s': %s", cacheName, e.getMessage()));
}
{code}
catch should be on separate line
2. As I see from the code, cache filtering actually works on group names as
well. Let's meтtion it in --cache help output.
3. Let's cover that non-trivial cache filter (e.g. PERSISTENT) works
simultaneously with regexp filtering.
4. I agree with Sergey on his points 5 and 6. A descriptive message should be
displayed in case there are no caches that match the filter.
5. "idle_verify task args were following" - doesn't it sound a bit rough? What
about "idle_verify task was executed with the following args"?
> Add ability to use simultaneous cache filtering options with control.sh
> --cache idle_verify
> ---
>
> Key: IGNITE-10896
> URL: https://issues.apache.org/jira/browse/IGNITE-10896
> Project: Ignite
> Issue Type: Improvement
>Reporter: ARomantsov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Now I can use only one of next options
> 1) --exclude-caches cache1,...,cacheN
> 2) --cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT
> 3) cache1,...,cacheN
> Trying to use two or more of this options currently results in error:
> {noformat}
> Error: Should use only one of option: --excludeCaches, --cache-filter or pass
> caches explicitly
> {noformat}
> Instead, utility should do the following:
> 1) when two or more options specified, result cache set to make dump of
> should be logical AND of results of each option applied individually.
> ex.
> {noformat}
> cache.* --cache-filter PERSISTENT
> {noformat}
> should select all persistent caches starting from 'cache'
> {noformat}
>--cache-filter ALL
>--exclude-caches wrong-.*-caches
> {noformat}
> should select all caches but matching 'wrong-.*-caches' regexp
> etc.
> 2) filtering options passed to control utility should be logged into result
> dump file, so that user could understand that dump was taken from subset of
> cluster caches
> 3) when result of filter or filters AND'ing is empty set of cache names,
> proper error message should be given and no dump file generated.
> e.g.
> {noformat}Error: can't find any cache matching cache names '--skup-zerus' and
> cache filter 'PERSISTENT', dump won't be generated.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[ https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808862#comment-16808862 ] Ivan Fedotov commented on IGNITE-11412: --- [~EdShangGG], [~Pavlukhin] Could you please take a look on this patch? Basically, it is about documentation, so this ticket is the last one in the context of JUnit 3->4 migration. If you have any other suggestions about fixes, that should be done in this context, feel free to tell me about them. > Actualize JUnit3TestLegacySupport class > --- > > Key: IGNITE-11412 > URL: https://issues.apache.org/jira/browse/IGNITE-11412 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > Specify JUnit3TestLegacySupport class documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11188) Optimize baseline autoadjustment for in-memory clusters with zero timeout
[
https://issues.apache.org/jira/browse/IGNITE-11188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808854#comment-16808854
]
Ignite TC Bot commented on IGNITE-11188:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3488515buildTypeId=IgniteTests24Java8_RunAll]
> Optimize baseline autoadjustment for in-memory clusters with zero timeout
> -
>
> Key: IGNITE-11188
> URL: https://issues.apache.org/jira/browse/IGNITE-11188
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
>
> In current implementation (IGNITE-8571) zero-timeout case initiates two
> partition map exchanges on join/leave node events. This could be improved so
> that baseline is updated at the same time as join/leave event processing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808855#comment-16808855
]
Ignite TC Bot commented on IGNITE-11412:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3496183buildTypeId=IgniteTests24Java8_RunAll]
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[
https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808830#comment-16808830
]
Alexei Scherbakov commented on IGNITE-11614:
[~agoncharuk], seems a commit error on tx near node doesn't trigger failure
handler and is propagated to near finish future without valid handling in
GridNearLocalTx.close.
The possible fix is the following:
{code:java}
if (state != COMMITTING && state != ROLLING_BACK && (!trackTimeout || rmv ||
prepFut != null && prepFut.isDone()))
rollbackNearTxLocalAsync(clearThreadMap, false).get();{code}
> Transaction with timeout on cache hangs after cache store failure
> -
>
> Key: IGNITE-11614
> URL: https://issues.apache.org/jira/browse/IGNITE-11614
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Anton Kurbanov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: CacheStoreTxPutAllMultiNodeTest.java
>
>
> If CacheStore fails before/during transaction commit, transaction with set
> timeout remains active.
> Setting cfg.setTransactionConfiguration(new
> TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes
> the issue in test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11574) Exchange on NodeLeft event hangs when cluster is in transition state
[
https://issues.apache.org/jira/browse/IGNITE-11574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808825#comment-16808825
]
Ignite TC Bot commented on IGNITE-11574:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3497538]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3487650buildTypeId=IgniteTests24Java8_RunAll]
> Exchange on NodeLeft event hangs when cluster is in transition state
>
>
> Key: IGNITE-11574
> URL: https://issues.apache.org/jira/browse/IGNITE-11574
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Attachments: ExchangeDeadlockTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is in this code (GridCachePartitionExchangeManager#discoLsnr) :
> {code:java}
> if (cache.state().transition()) {
> if (log.isDebugEnabled())
> log.debug("Adding pending event: " + evt);
> pendingEvts.add(new PendingDiscoveryEvent(evt, cache));
> }{code}
> Problem occurs when "setBaseline" and "nodeLeft" events happen simultaneously
> (+ some undetermined conditions).
> "nodeLeft" provokes exchange, and while that exchange isn't finished
> "setBaseline" is invoked. This moves cluster into a transition state and
> "CacheAffinityChangeMessage" from the exchange cannot be processed properly.
> At the same time "setBaseline" cannot be completed before the exchange, so we
> have a deadlock.
> Reproducer attached.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11574) Exchange on NodeLeft event hangs when cluster is in transition state
[
https://issues.apache.org/jira/browse/IGNITE-11574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808828#comment-16808828
]
Ivan Bessonov commented on IGNITE-11574:
License headers were broken in master at the moment of tests running.
> Exchange on NodeLeft event hangs when cluster is in transition state
>
>
> Key: IGNITE-11574
> URL: https://issues.apache.org/jira/browse/IGNITE-11574
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Attachments: ExchangeDeadlockTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The problem is in this code (GridCachePartitionExchangeManager#discoLsnr) :
> {code:java}
> if (cache.state().transition()) {
> if (log.isDebugEnabled())
> log.debug("Adding pending event: " + evt);
> pendingEvts.add(new PendingDiscoveryEvent(evt, cache));
> }{code}
> Problem occurs when "setBaseline" and "nodeLeft" events happen simultaneously
> (+ some undetermined conditions).
> "nodeLeft" provokes exchange, and while that exchange isn't finished
> "setBaseline" is invoked. This moves cluster into a transition state and
> "CacheAffinityChangeMessage" from the exchange cannot be processed properly.
> At the same time "setBaseline" cannot be completed before the exchange, so we
> have a deadlock.
> Reproducer attached.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808794#comment-16808794
]
Ivan Pavlukhin commented on IGNITE-10078:
-
[~ascherbakov], additionally it seems that _read-through_ becomes broken as
well, because it updates counters using an old flow. On the other hand it seems
broken currently in the master as well, because counters are updated only on
one node when a value is _read-through_.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11569) Enable baseline auto-adjust by default only for empty cluster
[ https://issues.apache.org/jira/browse/IGNITE-11569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808719#comment-16808719 ] Dmitriy Govorukhin commented on IGNITE-11569: - [~akalashnikov] Thanks for the contribution, merged to master. > Enable baseline auto-adjust by default only for empty cluster > - > > Key: IGNITE-11569 > URL: https://issues.apache.org/jira/browse/IGNITE-11569 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It is required to enable baseline auto-adjust by default only for empty > cluster -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11679) MVCC: Security check is violated for MVCC caches
[ https://issues.apache.org/jira/browse/IGNITE-11679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808712#comment-16808712 ] Roman Kondakov commented on IGNITE-11679: - See corresponding IGN ticket for details > MVCC: Security check is violated for MVCC caches > > > Key: IGNITE-11679 > URL: https://issues.apache.org/jira/browse/IGNITE-11679 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Roman Kondakov >Priority: Major > > Security check is not applied for MVCC caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11679) MVCC: Security check is violated for MVCC caches
Roman Kondakov created IGNITE-11679: --- Summary: MVCC: Security check is violated for MVCC caches Key: IGNITE-11679 URL: https://issues.apache.org/jira/browse/IGNITE-11679 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Roman Kondakov Security check is not applied for MVCC caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808706#comment-16808706
]
Ignite TC Bot commented on IGNITE-11434:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3489137buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_ID | int | Column ID |
> | COLUMN_NAME | string | Column name |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | SQL TYPE | int | SQL data type ID |
> | DATA_TYPE | string | SQL data type |
> | DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
> | PRECISION | int | Precision |
> | SCALE | int | Scale |
> | AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11334) SQL: Deprecate SqlQuery
[
https://issues.apache.org/jira/browse/IGNITE-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808705#comment-16808705
]
Taras Ledkov commented on IGNITE-11334:
---
[~vozerov], looks like the PHP & python suites have a problem at the master
branch too.
> SQL: Deprecate SqlQuery
> ---
>
> Key: IGNITE-11334
> URL: https://issues.apache.org/jira/browse/IGNITE-11334
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This API is very limited comparing to {{SqlFieldsQuery}}. Let's deprecate it
> with proper links to {{SqlFieldsQuery}}. This should be not only deprecation
> on public API, but removal from examples as well.
> Separate ticket for documentation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11334) SQL: Deprecate SqlQuery
[
https://issues.apache.org/jira/browse/IGNITE-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808704#comment-16808704
]
Ignite TC Bot commented on IGNITE-11334:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3496548]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3496550]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3440931buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Deprecate SqlQuery
> ---
>
> Key: IGNITE-11334
> URL: https://issues.apache.org/jira/browse/IGNITE-11334
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This API is very limited comparing to {{SqlFieldsQuery}}. Let's deprecate it
> with proper links to {{SqlFieldsQuery}}. This should be not only deprecation
> on public API, but removal from examples as well.
> Separate ticket for documentation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11499) SQL: DML should not use batches by default
[
https://issues.apache.org/jira/browse/IGNITE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808694#comment-16808694
]
Ignite TC Bot commented on IGNITE-11499:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3490358]]
* IgniteJdbcDriverTestSuite: JdbcThinConnectionSelfTest.testInvalidEndpoint -
1,8% fails in last 339 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3490451buildTypeId=IgniteTests24Java8_RunAll]
> SQL: DML should not use batches by default
> --
>
> Key: IGNITE-11499
> URL: https://issues.apache.org/jira/browse/IGNITE-11499
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}.
> This is prone to deadlocks. Instead, we should apply updates one-by-one by
> default. Proposal:
> # Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by
> default
> # Print a warning about deadlock to log if it is greater than 1
> # Add it to JDBC and ODBC drivers
> # Add it to other languages
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11678) Forbidding joining persistence node to in-memory cluster
Anton Kalashnikov created IGNITE-11678: -- Summary: Forbidding joining persistence node to in-memory cluster Key: IGNITE-11678 URL: https://issues.apache.org/jira/browse/IGNITE-11678 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Forbidding joining persistence node to in-memory cluster when baseline auto-adjust enabled and timeout equal to 0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11569) Enable baseline auto-adjust by default only for empty cluster
[
https://issues.apache.org/jira/browse/IGNITE-11569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808688#comment-16808688
]
Ignite TC Bot commented on IGNITE-11569:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3478849buildTypeId=IgniteTests24Java8_RunAll]
> Enable baseline auto-adjust by default only for empty cluster
> -
>
> Key: IGNITE-11569
> URL: https://issues.apache.org/jira/browse/IGNITE-11569
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is required to enable baseline auto-adjust by default only for empty
> cluster
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[
https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808679#comment-16808679
]
Alexey Goncharuk commented on IGNITE-11614:
---
Looks like there this has been broken by IGNITE-6827. In the attached test
scenario we have successfully completed the prepare step, so the timeout object
has been removed.
On commit cache store exception occurs, and when we get to
{{GridNearTxLocal#close(boolean)}} method, {{trackTimeout}} is {{true}}, but
the timeout object is already removed, so we do not call
{{rollbackNearTxLocalAsync(clearThreadMap, false).get()}}.
I am not sure yet how this should be fixed. Firs idea is to reset
{{trackTimeout}} flag once the timeout object is removed. Another one is to
check if state is equal to {{MARKED_ROLLBACK}}.
[~ascherbakov], what do you think?
> Transaction with timeout on cache hangs after cache store failure
> -
>
> Key: IGNITE-11614
> URL: https://issues.apache.org/jira/browse/IGNITE-11614
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Anton Kurbanov
>Assignee: Alexey Goncharuk
>Priority: Major
> Attachments: CacheStoreTxPutAllMultiNodeTest.java
>
>
> If CacheStore fails before/during transaction commit, transaction with set
> timeout remains active.
> Setting cfg.setTransactionConfiguration(new
> TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes
> the issue in test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11614: -- Priority: Critical (was: Major) > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11614: -- Fix Version/s: 2.8 > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11641) Server node copies a lot of WAL files in WAL archive after restart
[
https://issues.apache.org/jira/browse/IGNITE-11641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808676#comment-16808676
]
Anton Kalashnikov commented on IGNITE-11641:
[~DmitriyGovorukhin] thanks for your changes. Looks good to me.
> Server node copies a lot of WAL files in WAL archive after restart
> --
>
> Key: IGNITE-11641
> URL: https://issues.apache.org/jira/browse/IGNITE-11641
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Pre-condition: PDS is enabled, wal_path and wal_archive_path are set in
> config file.
> 1. Cluster is up and running. Some data uploaded into caches.
> 2. Start load to generate a lot of files in wal archive (more than files in
> wal directory).
> 3. Stop some node and delete all files from wal archive.
> 4. Start node.
> In this case node copies WAL files from WAL dir into wal archive dir again
> and again until the amount of files will be the same it was in wal archive
> before stop.
> Here is information from server node log
> {code}
> 10:10:17,054][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
> state for local groups.
> [10:10:18,522][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/.wal]
> [10:10:18,523][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=1, segIdx=1,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,631][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0001.wal]
> [10:10:20,632][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=2, segIdx=2,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0002.wal]
> [10:10:23,276][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=3, segIdx=3,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,995][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0003.wal]
> [10:10:23,996][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=4, segIdx=4,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,644][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal,
>
> dst=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0004.wal]
> [10:10:24,645][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Starting to copy WAL segment [absIdx=5, segIdx=5,
> origFile=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
> dstFile=/storage/ssd/avolkov/wal_archive/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal]
> [10:10:25,301][INFO][wal-file-archiver%null-#64][FileWriteAheadLogManager]
> Copied file
> [src=/storage/ssd/avolkov/wal/node00-83c9db32-fee5-4f3e-8a1c-559221817759/0005.wal,
>
>
[jira] [Assigned] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-11614: - Assignee: Alexey Goncharuk > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Major > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11614: -- Ignite Flags: (was: Docs Required) > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Assignee: Alexey Goncharuk >Priority: Major > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808672#comment-16808672 ] Dmitriy Govorukhin commented on IGNITE-11416: - [~ibessonov], [~akalashnikov] Many thanks for the contribution, merged to master. > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11600) Fix launch script for Java 12 - clearly state that version is not supported
[
https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808666#comment-16808666
]
Ignite TC Bot commented on IGNITE-11600:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3497136]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3489396buildTypeId=IgniteTests24Java8_RunAll]
> Fix launch script for Java 12 - clearly state that version is not supported
> ---
>
> Key: IGNITE-11600
> URL: https://issues.apache.org/jira/browse/IGNITE-11600
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Labels: important
> Fix For: 2.8, 2.7.5
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> bin/ignite.bat:251
> if "%MAJOR_JAVA_VER%" == "11" (
> need to change to "%MAJOR_JAVA_VER%" GEQ "11" (
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11600) Fix launch script for Java 12 - clearly state that version is not supported
[
https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11600:
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
47|https://ci.ignite.apache.org/viewLog.html?buildId=3489311]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeLeave - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectSegmentedAfterJoinTimeoutServerFailed
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeFailOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientAndRouterFail - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite: TcpClientDiscoverySpiFailureTimeoutSelfTest.testMetrics -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOnRouterSuspend
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testPingFailedClientNode - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeFail - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectTopologyChange1
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeJoin - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite: TcpDiscoverySegmentationPolicyTest.testStopOnSegmentation
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectTopologyChange2
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeJoinOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testServerNodeFail - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFail - 0,0% fails
in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDisconnectAfterNetworkTimeout -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientMessageWorkerStartSingleServer
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite: AuthenticationRestartTest.testClientReconnect - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDuplicateId - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOneServerOneClient
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testForceClientReconnect - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite: TcpClientDiscoverySpiFailureTimeoutSelfTest.testPing -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectClusterRestart - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientSegmentation - 0,0% fails
in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailConcurrentJoin
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeLeaveOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testServerNodeJoin - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinTimeout - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterMassiveTopologyChange
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientMessageWorkerStartTwoServers1
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testGridStartTime - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOnRouterFail -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientFailReconnectDisabled -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterPause - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
[jira] [Commented] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
[
https://issues.apache.org/jira/browse/IGNITE-11673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808654#comment-16808654
]
Roman Kondakov commented on IGNITE-11673:
-
[~amashenkov] it seems that DML and Commands permissions are checked in another
places. For example, DML is checked in {{GridNearTxLocal#beforePut}} or
{{GridDhtAtomicCache#updateAll0}} or several another places. Commands are
checked in {{CommandProcessor#runCommandH2}}.
But it looks like something goes wrong in MVCC case. I'll create a ticket.
> SQL: It looks like security check is missed in h2 indexing.
> ---
>
> Key: IGNITE-11673
> URL: https://issues.apache.org/jira/browse/IGNITE-11673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
> after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11677) LOCAL cache on client node can't be created if persistence enabled
Nikolay Izhikov created IGNITE-11677:
Summary: LOCAL cache on client node can't be created if
persistence enabled
Key: IGNITE-11677
URL: https://issues.apache.org/jira/browse/IGNITE-11677
Project: Ignite
Issue Type: Task
Components: cache
Affects Versions: 2.7
Reporter: Nikolay Izhikov
Reproducer:
{code:java}
/** */
public class LocalCacheWithPersistenceEnabledTest extends
GridCommonAbstractTest {
/** */
private boolean client = false;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setClientMode(client);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDataRegionConfigurations(
new DataRegionConfiguration()
.setName("data-region")
.setPersistenceEnabled(true)));
return cfg;
}
/** @throws Exception If failed. */
@Test
public void testLocalCacheOnClientNodeWithLazyAllocation() throws Exception
{
client = false;
IgniteEx srv = startGrid(0);
srv.cluster().active(true);
awaitPartitionMapExchange();
client = true;
IgniteEx clnt = startGrid(1);
IgniteCache cache =
clnt.createCache(new CacheConfiguration("my-cache")
.setCacheMode(CacheMode.LOCAL)
.setDataRegionName("data-region"));
cache.put(1, "test");
assertEquals(cache.get(1), "test");
}
@Before
public void before() throws Exception {
cleanPersistenceDir();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11621) Node is stuck in "No next node in topology" infinite loop in special case.
[
https://issues.apache.org/jira/browse/IGNITE-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808620#comment-16808620
]
Ignite TC Bot commented on IGNITE-11621:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3490320]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3487889buildTypeId=IgniteTests24Java8_RunAll]
> Node is stuck in "No next node in topology" infinite loop in special case.
> --
>
> Key: IGNITE-11621
> URL: https://issues.apache.org/jira/browse/IGNITE-11621
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: NoNextNodeInTopologyReproducer.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In special case (reproducer is attached) node may stuck in the loop when the
> following sequence of events happens:
> * Nodes A and B are already in cluster.
> * Node C starts joining the cluster.
> * On node C NodeAdded message new node D is started.
> * Before NodeAddFinished for node C reaches it socket to node C fails and
> node is considered failed by the cluster.
> * When NodeFailed message for node C reaches node B both A and B fails.
> * After that node D gets stuck in infinite "No next node in topology" loop
> processing NodeFailed messages for A, B and C indefinitely.
> The main logic in attached reproducer lives in node1SpecialSpi - it is a
> TcpDiscoverySpi node B starts with.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11504) [ML] Preprocessor trainers should support new feature-label extraction API
[ https://issues.apache.org/jira/browse/IGNITE-11504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11504: Assignee: Aleksey Zinoviev > [ML] Preprocessor trainers should support new feature-label extraction API > -- > > Key: IGNITE-11504 > URL: https://issues.apache.org/jira/browse/IGNITE-11504 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > > Problem is same as feature extractors serialization bug. We should narrow our > API. (see parent task) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11581) [ML] Adapt tutorial to new vectorizer API
[ https://issues.apache.org/jira/browse/IGNITE-11581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11581: Assignee: Aleksey Zinoviev > [ML] Adapt tutorial to new vectorizer API > - > > Key: IGNITE-11581 > URL: https://issues.apache.org/jira/browse/IGNITE-11581 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > > Currently tutorial uses old feature-labels extraction API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11582) [ML] Pipelines should work with Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11582: Assignee: Aleksey Zinoviev > [ML] Pipelines should work with Vectorizers > --- > > Key: IGNITE-11582 > URL: https://issues.apache.org/jira/browse/IGNITE-11582 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > > Currently Pipelines are implemented using feature/label extraction functions > with generic label value. We should adapt pipelines for vectorizers (maybe > after this ticket - IGNITE-11481). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11642) [ML] Umbrella: API for Feature/Label extracting (part 2)
[ https://issues.apache.org/jira/browse/IGNITE-11642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11642: Assignee: Aleksey Zinoviev > [ML] Umbrella: API for Feature/Label extracting (part 2) > > > Key: IGNITE-11642 > URL: https://issues.apache.org/jira/browse/IGNITE-11642 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Critical > Labels: stability > Fix For: 2.8 > > > Replace current lambdas with fixed API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11580) [ML] Evaluators should accept Vectorizers
[ https://issues.apache.org/jira/browse/IGNITE-11580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11580: Assignee: Aleksey Zinoviev > [ML] Evaluators should accept Vectorizers > - > > Key: IGNITE-11580 > URL: https://issues.apache.org/jira/browse/IGNITE-11580 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Alexey Platonov >Assignee: Aleksey Zinoviev >Priority: Major > Labels: stability > > Currently evaluation API uses old interface with separated feature-label > extractors. In context of IGNITE-11449 we should change this API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11439) MVCC: Error in transaction mode validation.
[
https://issues.apache.org/jira/browse/IGNITE-11439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-11439:
-
Assignee: Andrew Mashenkov
> MVCC: Error in transaction mode validation.
> ---
>
> Key: IGNITE-11439
> URL: https://issues.apache.org/jira/browse/IGNITE-11439
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: Reproducer
>
>
> Currently MVCC transaction mode is validated within {{MvccUtils#tx()}}
> method. If this method is called during execution of {{OPTIMISTIC}}
> transaction over non-mvcc cache it can cause {{UnsupportedTxModeException}}
> in the case when at least one mvcc cache is also started in the cluster. This
> happens due to improper use of {{MvccUtils#mvccEnabled}} method which returns
> {{true}} if at least one mvcc cache is started. This is a global
> {{mvccEnabled}} flag, but not a per-cache one.
> A very common pattern of using the combination of these two methods is
> completely wrong:
> {code:java}
> if (MvccUtils.mvccEnabled(kernalCtx)) <- global check of enabled mvcc
> tx = MvccUtils#tx(kernalCtx) <- an attempt to get a transaction with
> wrong assumption of enabled mvcc. Exception is thrown here.
> {code}
> We need to revise mvcc transaction mode validation and using these methods in
> the project. All possible scenarios should be covered by tests.
> See reproducer in attachment. Error stacktrace is below:
> {noformat}
> class
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils$UnsupportedTxModeException:
> Only pessimistic transactions are supported when MVCC is enabled.
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:717)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccUtils.tx(MvccUtils.java:696)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:488)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:1102)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iter(QueryCursorImpl.java:102)
> at
> org.apache.ignite.internal.processors.cache.query.RegisteredQueryCursor.iter(RegisteredQueryCursor.java:64)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:121)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccSqlTxModesTest.testConsequentMvccNonMvccOperations(CacheMvccSqlTxModesTest.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 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$7.run(GridAbstractTest.java:2049)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11664) [ML] Use Double.NaN as default values for missing values in Vector
[ https://issues.apache.org/jira/browse/IGNITE-11664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Platonov reassigned IGNITE-11664: Assignee: Alexey Platonov > [ML] Use Double.NaN as default values for missing values in Vector > -- > > Key: IGNITE-11664 > URL: https://issues.apache.org/jira/browse/IGNITE-11664 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: stability > > Currently, we use 0.0 value for default values in vectors if a value is > missing. But this way contradicts to preprocessors politics where for missing > values Double.NaN is using. Moreover, Double.NaN is a more convenient value > for missing feature values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11647) [ML] ML Vectors should work with all Serializable objects besides double
[ https://issues.apache.org/jira/browse/IGNITE-11647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-11647: Fix Version/s: 2.8 > [ML] ML Vectors should work with all Serializable objects besides double > > > Key: IGNITE-11647 > URL: https://issues.apache.org/jira/browse/IGNITE-11647 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Fix For: 2.8 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Such refactoring allows us to reduce hierarchy parallelism between > preprocessors and dataset trainers. Also, support of types besides double > allows improving some algorithms like decision trees. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808598#comment-16808598
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3496581]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3491169buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11654) ML: Memory leak in KNNClassificationModel
[ https://issues.apache.org/jira/browse/IGNITE-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev resolved IGNITE-11654. --- Resolution: Fixed > ML: Memory leak in KNNClassificationModel > - > > Key: IGNITE-11654 > URL: https://issues.apache.org/jira/browse/IGNITE-11654 > Project: Ignite > Issue Type: Bug > Components: ml >Affects Versions: 2.7 >Reporter: Anton Dmitriev >Assignee: Aleksey Zinoviev >Priority: Critical > Time Spent: 20m > Remaining Estimate: 0h > > KNNClassificationModel acquires datasets which keeps resources within the > cluster, but doesn't close it. As result of that we have a memory leak > because resources allocated for dataset are not collected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3491092]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testTxStateAfterClientReconnect - 0,3% fails in
last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectMultinodeLongHistory - 0,0% fails
in last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated - 0,0%
fails in last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectInitialExchangeInProgress - 0,0%
fails in last 349 master runs.
{color:#d04437}Continuous Query 3{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3491127]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3491095]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3491169buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11676) Clean up custom event callbacks
[
https://issues.apache.org/jira/browse/IGNITE-11676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11676:
--
Ignite Flags: (was: Docs Required)
> Clean up custom event callbacks
> ---
>
> Key: IGNITE-11676
> URL: https://issues.apache.org/jira/browse/IGNITE-11676
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> Currently, {{GridDiscoveryManager}} has several ways of notifying Ignite
> components of discovery events:
> * Line 668: a set of {{instanceof}} statements to invoke specific callbacks
> for components (for example, {{ctx.state().onStateChangeMessage(...)}},
> {{ctx.cache().onCustomEvent(...)}}
> * Later, on line 715: we call a somewhat generic custom event listeners
> * Finally, on line 876, if the custom message was of a specific type, we
> fire EVT_DISCOVERY_CUSTOM_EVT
> Overall, this is a huge abstraction leak, and all non-discovery specifics
> should be eliminated from {{GridDiscoveryManager}}. I suggest the following:
> 1) Change {{CustomEventListener}} to have two methods: one of them should
> return {{true}} or {{false}} to determine whether the minor topology version
> should be incremented
> 2) Move all logic to corresponding components
> 3) Get rid of code on line 876, I see no need in this. Also, consider
> removing {{EVT_DISCOVERY_CUSTOM_EVT}}, as this is private API and should now
> be covered by the specific listener
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11676) Clean up custom event callbacks
Alexey Goncharuk created IGNITE-11676:
-
Summary: Clean up custom event callbacks
Key: IGNITE-11676
URL: https://issues.apache.org/jira/browse/IGNITE-11676
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Currently, {{GridDiscoveryManager}} has several ways of notifying Ignite
components of discovery events:
* Line 668: a set of {{instanceof}} statements to invoke specific callbacks
for components (for example, {{ctx.state().onStateChangeMessage(...)}},
{{ctx.cache().onCustomEvent(...)}}
* Later, on line 715: we call a somewhat generic custom event listeners
* Finally, on line 876, if the custom message was of a specific type, we fire
EVT_DISCOVERY_CUSTOM_EVT
Overall, this is a huge abstraction leak, and all non-discovery specifics
should be eliminated from {{GridDiscoveryManager}}. I suggest the following:
1) Change {{CustomEventListener}} to have two methods: one of them should
return {{true}} or {{false}} to determine whether the minor topology version
should be incremented
2) Move all logic to corresponding components
3) Get rid of code on line 876, I see no need in this. Also, consider removing
{{EVT_DISCOVERY_CUSTOM_EVT}}, as this is private API and should now be covered
by the specific listener
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11442) Renaming IGNITE schema to something more clear SYS, SYSTEM, ...
[ https://issues.apache.org/jira/browse/IGNITE-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-11442: -- Assignee: Yury Gerzhedovich > Renaming IGNITE schema to something more clear SYS, SYSTEM, ... > --- > > Key: IGNITE-11442 > URL: https://issues.apache.org/jira/browse/IGNITE-11442 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > Consider renaming IGNITE schema to something more clear. E.g. SYS or SYSTEM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808564#comment-16808564 ] Yury Gerzhedovich commented on IGNITE-11456: [~vozerov], master merged to base branch and pushed to GridGain's upstream. > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
[
https://issues.apache.org/jira/browse/IGNITE-11673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808556#comment-16808556
]
Andrew Mashenkov commented on IGNITE-11673:
---
[~rkondakov],
"executeSelect0()" is called from executeSelect() and executeSelectFromDml()
methods.
Security check is present in first one, but missed in second one.
So, before your fix, Dml query execution looks not secured at all and after fix
security checks can be performed twice.
Also, I've found "executeDml()" and "executeCommand()" (see querySqlFields)
also has no security checks.
Do we need to create a separate ticket for this or I've missed smth?
> SQL: It looks like security check is missed in h2 indexing.
> ---
>
> Key: IGNITE-11673
> URL: https://issues.apache.org/jira/browse/IGNITE-11673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
> after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11674) Cancellation of SQL query request should await cancellation on all nodes
[ https://issues.apache.org/jira/browse/IGNITE-11674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-11674: -- Assignee: (was: Yury Gerzhedovich) > Cancellation of SQL query request should await cancellation on all nodes > > > Key: IGNITE-11674 > URL: https://issues.apache.org/jira/browse/IGNITE-11674 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.8 >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > > As of now during cancellation process reduce's node send cancellation > requests to map nodes and don't wait answer from them. Need to await answer > from all of map nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11675) [ML] Create additional examples for linear regressions, knn and kmeans
Alexey Platonov created IGNITE-11675: Summary: [ML] Create additional examples for linear regressions, knn and kmeans Key: IGNITE-11675 URL: https://issues.apache.org/jira/browse/IGNITE-11675 Project: Ignite Issue Type: Improvement Components: documentation, ml Reporter: Alexey Platonov Assignee: Alexey Platonov We should create additional examples for linear regressions, knn and kmeans in examples module for ebook about ML in Ignite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov resolved IGNITE-11413. --- Resolution: Not A Problem > Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport > - > > Key: IGNITE-11413 > URL: https://issues.apache.org/jira/browse/IGNITE-11413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > beforeTestsStarted and afterTestsStarted methods are deprecated in context of > JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass > annotations for such purposes. Methods must be moved in corresponded classes > and marked by annotations. > It could require changes in start/stop nodes process because methods under > @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov closed IGNITE-11413. - > Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport > - > > Key: IGNITE-11413 > URL: https://issues.apache.org/jira/browse/IGNITE-11413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > beforeTestsStarted and afterTestsStarted methods are deprecated in context of > JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass > annotations for such purposes. Methods must be moved in corresponded classes > and marked by annotations. > It could require changes in start/stop nodes process because methods under > @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808482#comment-16808482 ] Amelchev Nikita commented on IGNITE-9913: - [~Jokser], Thank you for the review! For now the coordinator set partitions states based on their availability if cluster has moving partitions. In theory we can calculate it locally too. But it should be consistent for each node. I suggest do it with other optimizations, such as leaving not-baseline node with persistence enabled. > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.8 > > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 50m > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-11414) Remove JUnit3LegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov closed IGNITE-11414. - > Remove JUnit3LegacySupport > -- > > Key: IGNITE-11414 > URL: https://issues.apache.org/jira/browse/IGNITE-11414 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest > class or remove if it is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11414) Remove JUnit3LegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov resolved IGNITE-11414. --- Resolution: Not A Problem As it was mentioned in the ticket [IGNITE-11413|https://issues.apache.org/jira/browse/IGNITE-11413] beforeTest/afterTest and beforeTests/afterTests methods should be used under the Rule and ClassRule annotations respectively. In this context mentioned methods will remain in Ignite test framework and removing of JUnit3LegacySupport class becomes not actual. > Remove JUnit3LegacySupport > -- > > Key: IGNITE-11414 > URL: https://issues.apache.org/jira/browse/IGNITE-11414 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest > class or remove if it is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11674) Cancellation of SQL query request should await cancellation on all nodes
Yury Gerzhedovich created IGNITE-11674: -- Summary: Cancellation of SQL query request should await cancellation on all nodes Key: IGNITE-11674 URL: https://issues.apache.org/jira/browse/IGNITE-11674 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.8 Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Fix For: 2.8 As of now during cancellation process reduce's node send cancellation requests to map nodes and don't wait answer from them. Need to await answer from all of map nodes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
[
https://issues.apache.org/jira/browse/IGNITE-11673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808474#comment-16808474
]
Roman Kondakov commented on IGNITE-11673:
-
[~vozerov], [~amashenkov], please, review the patch. Tests look good: there are
some problems with PHP and Python clients in the master branch.
> SQL: It looks like security check is missed in h2 indexing.
> ---
>
> Key: IGNITE-11673
> URL: https://issues.apache.org/jira/browse/IGNITE-11673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
> after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
[
https://issues.apache.org/jira/browse/IGNITE-11673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808470#comment-16808470
]
Ignite TC Bot commented on IGNITE-11673:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3495287]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3495289]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3491836buildTypeId=IgniteTests24Java8_RunAll]
> SQL: It looks like security check is missed in h2 indexing.
> ---
>
> Key: IGNITE-11673
> URL: https://issues.apache.org/jira/browse/IGNITE-11673
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
> after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11456) Use separate pool for KILL QUERY command
[ https://issues.apache.org/jira/browse/IGNITE-11456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808466#comment-16808466 ] Yury Gerzhedovich commented on IGNITE-11456: Waiting a BOT vise. > Use separate pool for KILL QUERY command > > > Key: IGNITE-11456 > URL: https://issues.apache.org/jira/browse/IGNITE-11456 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > As of now we use QUERY_POOL to process cancellation requests. It can lead to > unable to cancel a queries in case the pool will be overflowed. > So, need to use separate pool or MGMT pool + non-blocking processing through > futures. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808458#comment-16808458 ] Ivan Bessonov edited comment on IGNITE-11416 at 4/3/19 8:14 AM: [~akalashnikov], [~DmitriyGovorukhin] I improved new test just like you asked, please take a look. Overall it feels like we can finally merge these changes. was (Author: ibessonov): [~akalashnikov], [~DmitriyGovorukhin] I improved new test just like you asked, please take a look. Otherwise it feels like we can finally merge these changes. > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808458#comment-16808458 ] Ivan Bessonov commented on IGNITE-11416: [~akalashnikov], [~DmitriyGovorukhin] I improved new test just like you asked, please take a look. Otherwise it feels like we can finally merge these changes. > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3479508buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808452#comment-16808452
]
Pavel Tupitsyn commented on IGNITE-7101:
[~ashapkin] please see some more comments on GitHub.
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808448#comment-16808448 ] Ivan Pavlukhin commented on IGNITE-11413: - [~ivanan.fed], ok. > Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport > - > > Key: IGNITE-11413 > URL: https://issues.apache.org/jira/browse/IGNITE-11413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > beforeTestsStarted and afterTestsStarted methods are deprecated in context of > JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass > annotations for such purposes. Methods must be moved in corresponded classes > and marked by annotations. > It could require changes in start/stop nodes process because methods under > @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11588) The wrong result for Query
[
https://issues.apache.org/jira/browse/IGNITE-11588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808431#comment-16808431
]
Vladimir Ozerov commented on IGNITE-11588:
--
[~pkouznet], [~isapego], looks good to me, except of unnecessary diffs in
{{xml}} files (excluding {{query-example.xml}}). I'd propose to rollback them,
as they are not related to the ticket.
Let's merge it once TC bot visa is there.
> The wrong result for Query
> --
>
> Key: IGNITE-11588
> URL: https://issues.apache.org/jira/browse/IGNITE-11588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.7
> Environment: Windows 10, Visual Studio 2010 Pro, Oracle JDK 8
>Reporter: Sergey Kozlov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Attachments: query-example-fix.xml, query_example.cpp
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I use modified C++ Query Example (see attached files) that verify the
> received result against expected one and print out message if they're
> different.
> Just copy *.cpp file in {{platforms/cpp/examples/query-example/src}} and
> build example project
> 1. Start two nodes {{bin\ignite.bat query-example-fix.xml -v}}
> 2. Run query-example.exe:
> {noformat}
> [13:35:48] Ignite node started OK (id=1e2c0f81)
> [13:35:48] Topology snapshot [ver=3, locNode=1e2c0f81, servers=3, clients=0,
> state=ACTIVE, CPUs=8, offheap=9.5GB, heap=2.9GB]
> >>> Cache query example started.
> Iteration 698. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 699. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 700. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 701. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 702. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 703. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 704. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 705. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
>
> Iteration 996. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 997. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 998. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> Iteration 999. Average salary for 'ApacheIgnite' employees, expected 1500,
> found: 2000
> [13:35:51] Ignite node stopped OK [uptime=00:00:02.652]
> >>> Example finished, press 'Enter' to exit ...
> {noformat}
> 3. All next runs have no failures
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11120) Remove static fields from GridDhtLockFuture
[
https://issues.apache.org/jira/browse/IGNITE-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chumarin Rafael reassigned IGNITE-11120:
Assignee: Chumarin Rafael
> Remove static fields from GridDhtLockFuture
> ---
>
> Key: IGNITE-11120
> URL: https://issues.apache.org/jira/browse/IGNITE-11120
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Chumarin Rafael
>Priority: Major
> Labels: newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> /** Logger reference. */
> private static final AtomicReference logRef = new
> AtomicReference<>();
> /** Logger. */
> private static IgniteLogger log;
> /** Logger. */
> private static IgniteLogger msgLog;
> {code}
>
> In that case we can to miss log messages, when restart node without restart
> JVM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
