[jira] [Commented] (IGNITE-11115) Binary: rework thread-local binary context to avoid set() operation
[
https://issues.apache.org/jira/browse/IGNITE-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755802#comment-16755802
]
Ignite TC Bot commented on IGNITE-5:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2940133]]
* IgniteCacheRestartTestSuite:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups -
0,0% fails in last 407 master runs.
{color:#d04437}Cache (Restarts) 2{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2940134]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicPutAllFailoverSelfTest.testPutAllFailoverColocatedNearEnabledOneBackup
- 0,0% fails in last 423 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutEightNodesTwoBackups - 0,0%
fails in last 423 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,0%
fails in last 423 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxSixNodesTwoBackups - 0,0%
fails in last 423 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxFourNodesOneBackups - 0,0%
fails in last 423 master runs.
{color:#d04437}Data Structures{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2940148]]
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxTwoNodesOneBackup
- 0,0% fails in last 434 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testMultipleStructuresInDifferentGroups -
0,0% fails in last 434 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxSixNodesTwoBackups
- 0,0% fails in last 434 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxFourNodesOneBackups
- 0,0% fails in last 434 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups
- 0,0% fails in last 434 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2940188buildTypeId=IgniteTests24Java8_RunAll]
> Binary: rework thread-local binary context to avoid set() operation
> ---
>
> Key: IGNITE-5
> URL: https://issues.apache.org/jira/browse/IGNITE-5
> Project: Ignite
> Issue Type: Task
> Components: binary
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we call {{ThreadLocal.set()}} on every
> serialization/deserialization (see {{GridBinaryMarshaller#BINARY_CTX}}
> usages). This may lead to high CPU usage, especially during SQL query
> execution.
> Let's refactor access patterns to work only with {{ThreadLocal.get()}}
> operation.
--
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=16755801#comment-16755801
]
Artem Budnikov commented on IGNITE-10896:
-
The behaviour that [~ARomantsov] suggests for the two options should be
extended to all three options. It'll be better if all three options can be used
simultaneously. Mutually exclusive filtering options are really confusing.
This is how I envision it:
The default value for `--exclude-caches` is an empty set.
The default value for `--cache-filter` is no filtering.
The default value for `\-\-caches` is all caches.
All three options can be used simultaneously or all three can be omitted (in
which case the default values are used). If the result of applying the options
is an empty set, the script should print a warning to the console.
> 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
>Priority: Major
> Fix For: 2.8
>
>
> 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] [Assigned] (IGNITE-9801) Change style of export buttons to new one.
[ https://issues.apache.org/jira/browse/IGNITE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-9801: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) > Change style of export buttons to new one. > -- > > Key: IGNITE-9801 > URL: https://issues.apache.org/jira/browse/IGNITE-9801 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Minor > Attachments: image-2018-10-05-17-04-54-354.png > > Original Estimate: 1h > Time Spent: 1h > Remaining Estimate: 0h > > Currenlty buttons are the following. > !https://snag.gy/NHT13u.jpg! > We need to update styling. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
[
https://issues.apache.org/jira/browse/IGNITE-10985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755792#comment-16755792
]
Ignite TC Bot commented on IGNITE-10985:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Service Grid (legacy mode){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2943356]]
* IgniteServiceGridTestSuite:
GridServiceReassignmentSelfTest.testClusterSingleton - 0,0% fails in last 694
master runs.
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2943278]]
* JdbcThinStatementCancelSelfTest.testCancelQuery (last started)
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2943346]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2943371buildTypeId=IgniteTests24Java8_RunAll]
> SQL: create low-overhead implementation of Row for SELECTs
> --
>
> Key: IGNITE-10985
> URL: https://issues.apache.org/jira/browse/IGNITE-10985
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
> operations. This leads to *huge* memory overhead during {{SELECT}} execution.
> If you take a closer look on what is inside the row, you will note the
> following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never
> needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be
> created during {{SELECT}} operations only. It should contain only minimally
> necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket
> IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that
> we will need some pieces from it (e.g. cache ID and link for caching
> purposes), but it definitely will be only small subset of the whole
> {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
> {{GridH2Row}}, while in their usages only very relaxed version of
> {{GridH2SearchRow}} is needed. So let's start with new implementation of row
> for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9801) Change style of export buttons to new one.
[ https://issues.apache.org/jira/browse/IGNITE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755787#comment-16755787 ] Alexander Kalinin commented on IGNITE-9801: --- [~pkonstantinov] Button style changed. Please test. > Change style of export buttons to new one. > -- > > Key: IGNITE-9801 > URL: https://issues.apache.org/jira/browse/IGNITE-9801 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Minor > Attachments: image-2018-10-05-17-04-54-354.png > > Original Estimate: 1h > Time Spent: 1h > Remaining Estimate: 0h > > Currenlty buttons are the following. > !https://snag.gy/NHT13u.jpg! > We need to update styling. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7273) Web console: global visibility of User Profile
[ https://issues.apache.org/jira/browse/IGNITE-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-7273: Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Web console: global visibility of User Profile > -- > > Key: IGNITE-7273 > URL: https://issues.apache.org/jira/browse/IGNITE-7273 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > > # open two tabs with web console > # in the second tab open User\Profile page and make any changes, Save > # open Profile in the first tab - it doesn't show changes you made -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7273) Web console: global visibility of User Profile
[ https://issues.apache.org/jira/browse/IGNITE-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-7273. -- Resolution: Won't Fix It seems that no one interested. > Web console: global visibility of User Profile > -- > > Key: IGNITE-7273 > URL: https://issues.apache.org/jira/browse/IGNITE-7273 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > > # open two tabs with web console > # in the second tab open User\Profile page and make any changes, Save > # open Profile in the first tab - it doesn't show changes you made -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7273) Web console: global visibility of User Profile
[ https://issues.apache.org/jira/browse/IGNITE-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-7273. > Web console: global visibility of User Profile > -- > > Key: IGNITE-7273 > URL: https://issues.apache.org/jira/browse/IGNITE-7273 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Minor > > # open two tabs with web console > # in the second tab open User\Profile page and make any changes, Save > # open Profile in the first tab - it doesn't show changes you made -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11132) Web console: scrolling to invalid field works incorrectly under the MS Edge
[ https://issues.apache.org/jira/browse/IGNITE-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755739#comment-16755739 ] Ilya Borisov commented on IGNITE-11132: --- Given plans to switch Edge from EdgeHTML to Blink soon, I propose to wait and see if the issue gets fixed without our intervention. The issues is caused by an unfortunate combination of position: sticky and scrollIntoView() and the fact that Edge does not support experimental scrollIntoView options. > Web console: scrolling to invalid field works incorrectly under the MS Edge > --- > > Key: IGNITE-11132 > URL: https://issues.apache.org/jira/browse/IGNITE-11132 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > > Cluster - Advanced - General(panel) - Attempts count > Enter the -1 value > Save > An invalid value will be placed behind the viewport -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11132) Web console: scrolling to invalid field works incorrectly under the MS Edge
[ https://issues.apache.org/jira/browse/IGNITE-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755739#comment-16755739 ] Ilya Borisov edited comment on IGNITE-11132 at 1/30/19 6:43 AM: Given plans to switch Edge from EdgeHTML to Blink soon, I propose to wait and see if the issue gets resolved without our intervention. The issue is caused by an unfortunate combination of position: sticky, scrollIntoView() and the fact that Edge does not support experimental scrollIntoView options. was (Author: klaster_1): Given plans to switch Edge from EdgeHTML to Blink soon, I propose to wait and see if the issue gets fixed without our intervention. The issues is caused by an unfortunate combination of position: sticky and scrollIntoView() and the fact that Edge does not support experimental scrollIntoView options. > Web console: scrolling to invalid field works incorrectly under the MS Edge > --- > > Key: IGNITE-11132 > URL: https://issues.apache.org/jira/browse/IGNITE-11132 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > > Cluster - Advanced - General(panel) - Attempts count > Enter the -1 value > Save > An invalid value will be placed behind the viewport -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11101) Web console: validation does not work properly in corner case in Firefox
[ https://issues.apache.org/jira/browse/IGNITE-11101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-11101: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: validation does not work properly in corner case in Firefox > > > Key: IGNITE-11101 > URL: https://issues.apache.org/jira/browse/IGNITE-11101 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 1h 13m > Remaining Estimate: 0h > > You should use Firefox > Configuration - Cluster - Advanced - Data storage configuration > Enter a literal value into System region / Initial size > Save > Two points: > - no error message on entering the incorrect value > - no error message on Save and incorrect field is not on a viewport > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11101) Web console: validation does not work properly in corner case in Firefox
[ https://issues.apache.org/jira/browse/IGNITE-11101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755729#comment-16755729 ] Pavel Konstantinov commented on IGNITE-11101: - Tested under Firefox, Chrome, Safari, For MS Edge a new issue was created IGNITE-11132 > Web console: validation does not work properly in corner case in Firefox > > > Key: IGNITE-11101 > URL: https://issues.apache.org/jira/browse/IGNITE-11101 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 1h 13m > Remaining Estimate: 0h > > You should use Firefox > Configuration - Cluster - Advanced - Data storage configuration > Enter a literal value into System region / Initial size > Save > Two points: > - no error message on entering the incorrect value > - no error message on Save and incorrect field is not on a viewport > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11132) Web console: scrolling to invalid field works incorrectly under the MS Edge
Pavel Konstantinov created IGNITE-11132: --- Summary: Web console: scrolling to invalid field works incorrectly under the MS Edge Key: IGNITE-11132 URL: https://issues.apache.org/jira/browse/IGNITE-11132 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Assignee: Ilya Borisov Cluster - Advanced - General(panel) - Attempts count Enter the -1 value Save An invalid value will be placed behind the viewport -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755704#comment-16755704
]
Moldachev Sergey edited comment on IGNITE-8550 at 1/30/19 5:39 AM:
---
[~kuaw26] I think you are right. Current changes are similar to overengineering.
[~slukyanov] What do you think?
was (Author: smoldachev):
[~kuaw26] I think you are right. Current changes are similar to overengineering.
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755704#comment-16755704
]
Moldachev Sergey commented on IGNITE-8550:
--
[~kuaw26] I think you are right. Current changes are similar to overengineering.
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9450) Web console: remove manual rendering from ignite-icon directive
[ https://issues.apache.org/jira/browse/IGNITE-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755659#comment-16755659 ] Ilya Borisov commented on IGNITE-9450: -- While Chrome, Firefox and Edge support proposed solution, Safari is picky about SVG fragments, I couldn't make it work with any approach other than what's used currently. > Web console: remove manual rendering from ignite-icon directive > --- > > Key: IGNITE-9450 > URL: https://issues.apache.org/jira/browse/IGNITE-9450 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > When making the ignite-icon directive, I had to manually render SVGs because > at that moment we had to support IE11 and it doesn't support SVG directive > template namespace. Since IE11 support has been dropped, we can safely use > regular AngularJS template there and clean the code a bit. I think this > change will also fix invisible icons in TestCafe E2E tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9450) Web console: remove manual rendering from ignite-icon directive
[ https://issues.apache.org/jira/browse/IGNITE-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov resolved IGNITE-9450. -- Resolution: Won't Fix > Web console: remove manual rendering from ignite-icon directive > --- > > Key: IGNITE-9450 > URL: https://issues.apache.org/jira/browse/IGNITE-9450 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > When making the ignite-icon directive, I had to manually render SVGs because > at that moment we had to support IE11 and it doesn't support SVG directive > template namespace. Since IE11 support has been dropped, we can safely use > regular AngularJS template there and clean the code a bit. I think this > change will also fix invisible icons in TestCafe E2E tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9450) Web console: remove manual rendering from ignite-icon directive
[ https://issues.apache.org/jira/browse/IGNITE-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9450: - Component/s: wizards > Web console: remove manual rendering from ignite-icon directive > --- > > Key: IGNITE-9450 > URL: https://issues.apache.org/jira/browse/IGNITE-9450 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > When making the ignite-icon directive, I had to manually render SVGs because > at that moment we had to support IE11 and it doesn't support SVG directive > template namespace. Since IE11 support has been dropped, we can safely use > regular AngularJS template there and clean the code a bit. I think this > change will also fix invisible icons in TestCafe E2E tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9450) Web console: remove manual rendering from ignite-icon directive
[ https://issues.apache.org/jira/browse/IGNITE-9450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-9450: - Ignite Flags: (was: Docs Required) > Web console: remove manual rendering from ignite-icon directive > --- > > Key: IGNITE-9450 > URL: https://issues.apache.org/jira/browse/IGNITE-9450 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > When making the ignite-icon directive, I had to manually render SVGs because > at that moment we had to support IE11 and it doesn't support SVG directive > template namespace. Since IE11 support has been dropped, we can safely use > regular AngularJS template there and clean the code a bit. I think this > change will also fix invisible icons in TestCafe E2E tests. -- 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
]
Andrey Kalinin reassigned IGNITE-11120:
---
Assignee: Andrey Kalinin
> 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: Andrey Kalinin
>Priority: Major
> Labels: newbie
>
> {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)
[jira] [Assigned] (IGNITE-11114) Web console: add onhover state to the icons in the left menu
[ https://issues.apache.org/jira/browse/IGNITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-4: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: add onhover state to the icons in the left menu > > > Key: IGNITE-4 > URL: https://issues.apache.org/jira/browse/IGNITE-4 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Add hover state (red icon color) to icons in the left menu, like the > "Download agent" link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11114) Web console: add onhover state to the icons in the left menu
[ https://issues.apache.org/jira/browse/IGNITE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755644#comment-16755644 ] Pavel Konstantinov commented on IGNITE-4: - Tested. > Web console: add onhover state to the icons in the left menu > > > Key: IGNITE-4 > URL: https://issues.apache.org/jira/browse/IGNITE-4 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Add hover state (red icon color) to icons in the left menu, like the > "Download agent" link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11097) Web console: UI bug on Queries
[ https://issues.apache.org/jira/browse/IGNITE-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11097: -- Component/s: wizards > Web console: UI bug on Queries > -- > > Key: IGNITE-11097 > URL: https://issues.apache.org/jira/browse/IGNITE-11097 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > Attachments: image-2019-01-28-14-25-30-403.png > > > Open Query notebook > Open Metadata modal of any query > Collapse query > Look at left menu > !image-2019-01-28-14-25-30-403.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11097) Web console: UI bug on Queries
[ https://issues.apache.org/jira/browse/IGNITE-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11097: -- Ignite Flags: (was: Docs Required) > Web console: UI bug on Queries > -- > > Key: IGNITE-11097 > URL: https://issues.apache.org/jira/browse/IGNITE-11097 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > Attachments: image-2019-01-28-14-25-30-403.png > > > Open Query notebook > Open Metadata modal of any query > Collapse query > Look at left menu > !image-2019-01-28-14-25-30-403.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11097) Web console: UI bug on Queries
[ https://issues.apache.org/jira/browse/IGNITE-11097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov resolved IGNITE-11097. --- Resolution: Won't Fix The issue is caused by subpar bs-popover (part of angular-strap) positioning facilities. We have plans to display cache metadata info in the page flow and not in popover, which would remove the reported failure mode. > Web console: UI bug on Queries > -- > > Key: IGNITE-11097 > URL: https://issues.apache.org/jira/browse/IGNITE-11097 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Ilya Borisov >Priority: Major > Attachments: image-2019-01-28-14-25-30-403.png > > > Open Query notebook > Open Metadata modal of any query > Collapse query > Look at left menu > !image-2019-01-28-14-25-30-403.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11101) Web console: validation does not work properly in corner case in Firefox
[ https://issues.apache.org/jira/browse/IGNITE-11101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11101: -- Assignee: Pavel Konstantinov (was: Alexander Kalinin) > Web console: validation does not work properly in corner case in Firefox > > > Key: IGNITE-11101 > URL: https://issues.apache.org/jira/browse/IGNITE-11101 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 1h 13m > Remaining Estimate: 0h > > You should use Firefox > Configuration - Cluster - Advanced - Data storage configuration > Enter a literal value into System region / Initial size > Save > Two points: > - no error message on entering the incorrect value > - no error message on Save and incorrect field is not on a viewport > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755572#comment-16755572
]
Alexey Kuznetsov edited comment on IGNITE-8550 at 1/30/19 2:05 AM:
---
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Nothing was updated for entry [table=" + em.fullTableName() +
", entry=" + entry + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
was (Author: kuaw26):
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Nothing was updated for entry [table=" + em.fullTableName() +
", entry=" + entry + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755572#comment-16755572
]
Alexey Kuznetsov edited comment on IGNITE-8550 at 1/30/19 2:05 AM:
---
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Nothing was updated for entry [table=" + em.fullTableName() +
", entry=" + entry + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
was (Author: kuaw26):
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected > 0, actual = 0]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755572#comment-16755572
]
Alexey Kuznetsov edited comment on IGNITE-8550 at 1/30/19 2:04 AM:
---
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected > 0, actual = 0]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
was (Author: kuaw26):
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected > 0, actual=" + updCnt + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755572#comment-16755572
]
Alexey Kuznetsov edited comment on IGNITE-8550 at 1/30/19 2:03 AM:
---
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code:java}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected > 0, actual=" + updCnt + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
was (Author: kuaw26):
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected>1, actual=" + updCnt + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755572#comment-16755572
]
Alexey Kuznetsov commented on IGNITE-8550:
--
[~smoldachev] and [~slukyanov] I think that we need to fix this issue another
way.
Fix is simple and could be like:
{code}
if (updCnt == 0)
U.warn(log, "Unexpected number of updated entries [table=" +
em.fullTableName() +
", entry=" + entry + "expected>1, actual=" + updCnt + "]");
{code}
No need to modify dialects at all.
As far as I remember this warning was added in order to notify user about
situations when data was not updated.
What do you think?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11130) BackupPostProcessingClosure should not save initial value on a backup node when cache store is not configured.
[
https://issues.apache.org/jira/browse/IGNITE-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-11130:
-
Description:
The change introduced by IGNITE-7086 lead to the fact that
{{BackupPostProcessingClosure}} could attempt to store the initial value even
if the corresponding cache store is not configured.
For instance, transactional read operation where atomicity mode is
{{OPTIMISTIC}} and isolation level is {{SERIALIZABLE}} (native persistent
enabled) tries to update the local backup.
was:
The change introduced by IGNITE-7086 lead to the fact that
{{BackupPostProcessingClosure}} could attempt to store the initial value even
if the corresponding cache store is not configured.
For instance, transactional read operation where atomicity mode is OPTIMISTIC
and isolation level is SERIALIZABLE (native persistent enabled) tries to update
the local backup.
> BackupPostProcessingClosure should not save initial value on a backup node
> when cache store is not configured.
> --
>
> Key: IGNITE-11130
> URL: https://issues.apache.org/jira/browse/IGNITE-11130
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> The change introduced by IGNITE-7086 lead to the fact that
> {{BackupPostProcessingClosure}} could attempt to store the initial value even
> if the corresponding cache store is not configured.
> For instance, transactional read operation where atomicity mode is
> {{OPTIMISTIC}} and isolation level is {{SERIALIZABLE}} (native persistent
> enabled) tries to update the local backup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11084) Change copyrights to 2019
[
https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755436#comment-16755436
]
Ignite TC Bot commented on IGNITE-11084:
{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=2944374buildTypeId=IgniteTests24Java8_RunAll]
> Change copyrights to 2019
> -
>
> Key: IGNITE-11084
> URL: https://issues.apache.org/jira/browse/IGNITE-11084
> Project: Ignite
> Issue Type: Task
>Reporter: Andrey Aleksandrov
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Every year copyright date should be changed. We can use the build date for it
> or local date for cases when Ignite built from the sources,
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755406#comment-16755406
]
Moldachev Sergey commented on IGNITE-8550:
--
[~slukyanov] [~kuaw26] Thank you for review, I'll take into account the
comments!
[~slukyanov] I have a some questions:
1) Do we have any MySQL instances on TC for integration tests?
2) If answer on first question is Yes. Could you please provide some test with
MySQL (if they exist of course)?
Thank you very much :)
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11084) Change copyrights to 2019
[ https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755390#comment-16755390 ] Dmitriy Pavlov commented on IGNITE-11084: - I don't know why TC bot is not working, for me, Visa was added ^. Please share failure details (if any) > Change copyrights to 2019 > - > > Key: IGNITE-11084 > URL: https://issues.apache.org/jira/browse/IGNITE-11084 > Project: Ignite > Issue Type: Task >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Every year copyright date should be changed. We can use the build date for it > or local date for cases when Ignite built from the sources, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11084) Change copyrights to 2019
[
https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755387#comment-16755387
]
Ignite TC Bot commented on IGNITE-11084:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Continuous Query 2{color} [[tests 0 TIMEOUT , Out Of Memory
Error , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=2944269]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2944374buildTypeId=IgniteTests24Java8_RunAll]
> Change copyrights to 2019
> -
>
> Key: IGNITE-11084
> URL: https://issues.apache.org/jira/browse/IGNITE-11084
> Project: Ignite
> Issue Type: Task
>Reporter: Andrey Aleksandrov
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Every year copyright date should be changed. We can use the build date for it
> or local date for cases when Ignite built from the sources,
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[ https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11125: --- Description: Currently we can have the same columns for sorted inline indexes twice because in part cases use alternative columns for another case special column _key. To avoid duplicate the same columns need to use alternative columns (real columns) always. For example for CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY (ID1 DESC, ID2)) CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY* instead of ID2 DESC, ID1, MY_VAL DESC was: Currently we can have the same columns for sorted inline indexes twice because in part cases use alternative columns for another case special column _key. To avoid duplicate the same columns need to use alternative columns (real columns) always. For example for CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY (ID1 DESC, ID2)) CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, _KEY instead of ID2 DESC, ID1, MY_VAL DESC > Use alternative column instead of special _key for indexes. > --- > > Key: IGNITE-11125 > URL: https://issues.apache.org/jira/browse/IGNITE-11125 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we can have the same columns for sorted inline indexes twice > because in part cases use alternative columns for another case special column > _key. To avoid duplicate the same columns need to use alternative columns > (real columns) always. > > For example for > CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY > (ID1 DESC, ID2)) > CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) > > will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY* instead > of ID2 DESC, ID1, MY_VAL DESC > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[
https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755369#comment-16755369
]
Ignite TC Bot commented on IGNITE-11125:
{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=2942240buildTypeId=IgniteTests24Java8_RunAll]
> Use alternative column instead of special _key for indexes.
> ---
>
> Key: IGNITE-11125
> URL: https://issues.apache.org/jira/browse/IGNITE-11125
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we can have the same columns for sorted inline indexes twice
> because in part cases use alternative columns for another case special column
> _key. To avoid duplicate the same columns need to use alternative columns
> (real columns) always.
>
> For example for
> CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY
> (ID1 DESC, ID2))
> CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC)
>
> will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, _KEY instead of
> ID2 DESC, ID1, MY_VAL DESC
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11084) Change copyrights to 2019
[ https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755336#comment-16755336 ] Andrey Aleksandrov edited comment on IGNITE-11084 at 1/29/19 7:54 PM: -- [~dpavlov] Looks like visa bot doesn't work at the moment. However, the TeamCity run looks fine for me: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F5971%2Fhead Could you please take a look? was (Author: aealeksandrov): [~dpavlov] Looks like visa bot doesn't work at the moment. However, the TeamCity run looks fine for me: [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F5971] Could you please take a look? > Change copyrights to 2019 > - > > Key: IGNITE-11084 > URL: https://issues.apache.org/jira/browse/IGNITE-11084 > Project: Ignite > Issue Type: Task >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Every year copyright date should be changed. We can use the build date for it > or local date for cases when Ignite built from the sources, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11084) Change copyrights to 2019
[ https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755336#comment-16755336 ] Andrey Aleksandrov commented on IGNITE-11084: - [~dpavlov] Looks like visa bot doesn't work at the moment. However, the TeamCity run looks fine for me: [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F5971] Could you please take a look? > Change copyrights to 2019 > - > > Key: IGNITE-11084 > URL: https://issues.apache.org/jira/browse/IGNITE-11084 > Project: Ignite > Issue Type: Task >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Every year copyright date should be changed. We can use the build date for it > or local date for cases when Ignite built from the sources, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11131) Invalid use of static system properties in AffinityAssignment
Alexei Scherbakov created IGNITE-11131:
--
Summary: 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
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] [Comment Edited] (IGNITE-9903) Copy only actual amount of data during archiving of WAL segment
[
https://issues.apache.org/jira/browse/IGNITE-9903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755142#comment-16755142
]
Andrey Gura edited comment on IGNITE-9903 at 1/29/19 6:40 PM:
--
[~astelmak] I've looked at your change and have some comments:
- Size of {{SWITCH_SEGMENT_RECORD}} should be calculated using
{{RecordSerializer.size}} (see example here:
{{org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl#close}}).
- Unused import in all changed files.
- {{switchSegmentRecordOffset}} array never updates (except of {{0}} value).
Please add test for this situation.
Could you please fix this comments? Thanks.
was (Author: agura):
[~astelmak] I've looked at your change and have some comments:
- Size of {{SWITCH_SEGMENT_RECORD}} should be calculated using
{{RecordSerializer.size}} (see example here:
{{org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl#close}}).
- Unused import in all changed files.
- {{switchSegmentRecordOffset}} array never updates (except of {{0}} value).
Could you please fix this comments? Thanks.
> Copy only actual amount of data during archiving of WAL segment
> ---
>
> Key: IGNITE-9903
> URL: https://issues.apache.org/jira/browse/IGNITE-9903
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> Current WAL archiver implementation copies full WAL segment to the archive
> while actual size of the segment can be significantly less then
> {{maxWalSegmentSize}} (segment files are preallocated for max possible
> segment size).
> In order to reduce disk space consuming we need copy only actual data of
> segment using {{SWITCH_SEGMENT_RECORD}} as marker. It will require some kind
> of WAL iterator implementation that will just copy WAL records using
> information about record size without records deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11130) BackupPostProcessingClosure should not save initial value on a backup node when cache store is not configured.
[
https://issues.apache.org/jira/browse/IGNITE-11130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-11130:
-
Description:
The change introduced by IGNITE-7086 lead to the fact that
{{BackupPostProcessingClosure}} could attempt to store the initial value even
if the corresponding cache store is not configured.
For instance, transactional read operation where atomicity mode is OPTIMISTIC
and isolation level is SERIALIZABLE (native persistent enabled) tries to update
the local backup.
was:
The change introduced in IGNITE-7086 lead to the fact that
{{BackupPostProcessingClosure}} could attempt to store the initial value even
if the corresponding cache store is not configured.
For instance, transactional read operation where atomicity mode is OPTIMISTIC
and isolation level is SERIALIZABLE (native persistent enabled) tries to update
the local backup.
> BackupPostProcessingClosure should not save initial value on a backup node
> when cache store is not configured.
> --
>
> Key: IGNITE-11130
> URL: https://issues.apache.org/jira/browse/IGNITE-11130
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
>
> The change introduced by IGNITE-7086 lead to the fact that
> {{BackupPostProcessingClosure}} could attempt to store the initial value even
> if the corresponding cache store is not configured.
> For instance, transactional read operation where atomicity mode is OPTIMISTIC
> and isolation level is SERIALIZABLE (native persistent enabled) tries to
> update the local backup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9903) Copy only actual amount of data during archiving of WAL segment
[
https://issues.apache.org/jira/browse/IGNITE-9903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755249#comment-16755249
]
Alexey Stelmak commented on IGNITE-9903:
done
> Copy only actual amount of data during archiving of WAL segment
> ---
>
> Key: IGNITE-9903
> URL: https://issues.apache.org/jira/browse/IGNITE-9903
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> Current WAL archiver implementation copies full WAL segment to the archive
> while actual size of the segment can be significantly less then
> {{maxWalSegmentSize}} (segment files are preallocated for max possible
> segment size).
> In order to reduce disk space consuming we need copy only actual data of
> segment using {{SWITCH_SEGMENT_RECORD}} as marker. It will require some kind
> of WAL iterator implementation that will just copy WAL records using
> information about record size without records deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-11084) Change copyrights to 2019
[ https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov reopened IGNITE-11084: - Not all places were changed. Should be updated. > Change copyrights to 2019 > - > > Key: IGNITE-11084 > URL: https://issues.apache.org/jira/browse/IGNITE-11084 > Project: Ignite > Issue Type: Task >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Every year copyright date should be changed. We can use the build date for it > or local date for cases when Ignite built from the sources, -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[
https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755174#comment-16755174
]
Oleg Ignatenko commented on IGNITE-10179:
-
(i) [~agoncharuk] - this PR
([#5925|https://github.com/apache/ignite/pull/5925]) is one I told you about
last week, I would much appreciate if you take a look at it. TC bot visa above
suggests that it is most probably correct, however I will repeat this TC run in
order to make sure that multiple changes and merges from master made in last
few days didn't break something in previously validated test suites.
Core changes worth looking at are in {{GridAbstractTest}} and in
{{GridSpiAbstractTest}}, the rest is essentially just a scaffolding made to
accommodate these changes. Also of interest may be the expansion made in
{{MvccFeatureChecker}} to leverage JUnit 4 Assume API (IGNITE-11123) but in the
big picture it probably still qualifies more as a scaffolding.
-
Special thanks to [~Pavlukhin] for the idea to use class rule. Ivan, you can
also take a look at how it is implemented here if you're interested.
> Change new tests root to use @BeforeClass and @AfterClass instead of
> isFirstTest() and isLastTest()
> ---
>
> Key: IGNITE-10179
> URL: https://issues.apache.org/jira/browse/IGNITE-10179
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If needed, refer parent task for more details.
> isFirstTest() and isLastTest() homebrew methods seem to be in
> GridAbstractTest only because Junit 3 lacked necessary functionality; after
> migration to Junit 4 these would better changed to use standard API of this
> framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11129) Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
[
https://issues.apache.org/jira/browse/IGNITE-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11129:
--
Ignite Flags: (was: Docs Required)
> Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
>
>
> Key: IGNITE-11129
> URL: https://issues.apache.org/jira/browse/IGNITE-11129
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Priority: Major
>
> Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
> switched on. Size for this record type must be constant.
> See
> {{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
> {code:java}
> @Override public int size(WALRecord record) throws IgniteCheckedException
> {
> int clSz = plainSize(record);
> if (needEncryption(record))
> return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
> size */ + REC_TYPE_SIZE;
> return clSz;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[
https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755168#comment-16755168
]
Ignite TC Bot commented on IGNITE-10179:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2933660buildTypeId=IgniteTests24Java8_RunAllNightly]
> Change new tests root to use @BeforeClass and @AfterClass instead of
> isFirstTest() and isLastTest()
> ---
>
> Key: IGNITE-10179
> URL: https://issues.apache.org/jira/browse/IGNITE-10179
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If needed, refer parent task for more details.
> isFirstTest() and isLastTest() homebrew methods seem to be in
> GridAbstractTest only because Junit 3 lacked necessary functionality; after
> migration to Junit 4 these would better changed to use standard API of this
> framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11130) BackupPostProcessingClosure should not save initial value on a backup node when cache store is not configured.
Vyacheslav Koptilin created IGNITE-11130:
Summary: BackupPostProcessingClosure should not save initial value
on a backup node when cache store is not configured.
Key: IGNITE-11130
URL: https://issues.apache.org/jira/browse/IGNITE-11130
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.8
The change introduced in IGNITE-7086 lead to the fact that
{{BackupPostProcessingClosure}} could attempt to store the initial value even
if the corresponding cache store is not configured.
For instance, transactional read operation where atomicity mode is OPTIMISTIC
and isolation level is SERIALIZABLE (native persistent enabled) tries to update
the local backup.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9903) Copy only actual amount of data during archiving of WAL segment
[
https://issues.apache.org/jira/browse/IGNITE-9903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755142#comment-16755142
]
Andrey Gura commented on IGNITE-9903:
-
[~astelmak] I've looked at your change and have some comments:
- Size of {{SWITCH_SEGMENT_RECORD}} should be calculated using
{{RecordSerializer.size}} (see example here:
{{org.apache.ignite.internal.processors.cache.persistence.wal.filehandle.FileWriteHandleImpl#close}}).
- Unused import in all changed files.
- {{switchSegmentRecordOffset}} array never updates (except of {{0}} value).
Could you please fix this comments? Thanks.
> Copy only actual amount of data during archiving of WAL segment
> ---
>
> Key: IGNITE-9903
> URL: https://issues.apache.org/jira/browse/IGNITE-9903
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.8
>
>
> Current WAL archiver implementation copies full WAL segment to the archive
> while actual size of the segment can be significantly less then
> {{maxWalSegmentSize}} (segment files are preallocated for max possible
> segment size).
> In order to reduce disk space consuming we need copy only actual data of
> segment using {{SWITCH_SEGMENT_RECORD}} as marker. It will require some kind
> of WAL iterator implementation that will just copy WAL records using
> information about record size without records deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11129) Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
[
https://issues.apache.org/jira/browse/IGNITE-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-11129:
-
Description:
Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
switched on. Size for this record type must be constant.
See
{{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
{code:java}
@Override public int size(WALRecord record) throws IgniteCheckedException {
int clSz = plainSize(record);
if (needEncryption(record))
return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
size */ + REC_TYPE_SIZE;
return clSz;
}
{code}
was:
Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
switched on. Size for this record type should be constant.
See
{{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
{code:java}
@Override public int size(WALRecord record) throws IgniteCheckedException {
int clSz = plainSize(record);
if (needEncryption(record))
return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
size */ + REC_TYPE_SIZE;
return clSz;
}
{code}
> Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
>
>
> Key: IGNITE-11129
> URL: https://issues.apache.org/jira/browse/IGNITE-11129
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Priority: Major
>
> Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
> switched on. Size for this record type must be constant.
> See
> {{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
> {code:java}
> @Override public int size(WALRecord record) throws IgniteCheckedException
> {
> int clSz = plainSize(record);
> if (needEncryption(record))
> return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
> size */ + REC_TYPE_SIZE;
> return clSz;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11129) Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
Andrey Gura created IGNITE-11129:
Summary: Incorrect size calculation for SWITCH_SEGMENT_RECORD for
TDE
Key: IGNITE-11129
URL: https://issues.apache.org/jira/browse/IGNITE-11129
Project: Ignite
Issue Type: Bug
Reporter: Andrey Gura
Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
switched on. Size for this record type should be constant.
See
{{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
{code:java}
@Override public int size(WALRecord record) throws IgniteCheckedException {
int clSz = plainSize(record);
if (needEncryption(record))
return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
size */ + REC_TYPE_SIZE;
return clSz;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11129) Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
[
https://issues.apache.org/jira/browse/IGNITE-11129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-11129:
-
Description:
Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
switched on. Size for this record type should be constant.
See
{{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
{code:java}
@Override public int size(WALRecord record) throws IgniteCheckedException {
int clSz = plainSize(record);
if (needEncryption(record))
return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
size */ + REC_TYPE_SIZE;
return clSz;
}
{code}
was:
Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
switched on. Size for this record type should be constant.
See
{{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
{code:java}
@Override public int size(WALRecord record) throws IgniteCheckedException {
int clSz = plainSize(record);
if (needEncryption(record))
return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
size */ + REC_TYPE_SIZE;
return clSz;
}
{code}
> Incorrect size calculation for SWITCH_SEGMENT_RECORD for TDE
>
>
> Key: IGNITE-11129
> URL: https://issues.apache.org/jira/browse/IGNITE-11129
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Priority: Major
>
> Size of {{SWITCH_SEGMENT_RECORD}} will be invalid in case of encryption
> switched on. Size for this record type should be constant.
> See
> {{org.apache.ignite.internal.processors.cache.persistence.wal.serializer.RecordDataV1Serializer#size}}:
> {code:java}
> @Override public int size(WALRecord record) throws IgniteCheckedException
> {
> int clSz = plainSize(record);
> if (needEncryption(record))
> return encSpi.encryptedSize(clSz) + 4 /* groupId */ + 4 /* data
> size */ + REC_TYPE_SIZE;
> return clSz;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
[
https://issues.apache.org/jira/browse/IGNITE-10985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755132#comment-16755132
]
Vladimir Ozerov commented on IGNITE-10985:
--
https://ci.ignite.apache.org/viewQueued.html?itemId=2943371
> SQL: create low-overhead implementation of Row for SELECTs
> --
>
> Key: IGNITE-10985
> URL: https://issues.apache.org/jira/browse/IGNITE-10985
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
> operations. This leads to *huge* memory overhead during {{SELECT}} execution.
> If you take a closer look on what is inside the row, you will note the
> following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never
> needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be
> created during {{SELECT}} operations only. It should contain only minimally
> necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket
> IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that
> we will need some pieces from it (e.g. cache ID and link for caching
> purposes), but it definitely will be only small subset of the whole
> {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
> {{GridH2Row}}, while in their usages only very relaxed version of
> {{GridH2SearchRow}} is needed. So let's start with new implementation of row
> for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
[
https://issues.apache.org/jira/browse/IGNITE-10985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755132#comment-16755132
]
Vladimir Ozerov edited comment on IGNITE-10985 at 1/29/19 3:33 PM:
---
Implemented. Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=2943371
was (Author: vozerov):
https://ci.ignite.apache.org/viewQueued.html?itemId=2943371
> SQL: create low-overhead implementation of Row for SELECTs
> --
>
> Key: IGNITE-10985
> URL: https://issues.apache.org/jira/browse/IGNITE-10985
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
> operations. This leads to *huge* memory overhead during {{SELECT}} execution.
> If you take a closer look on what is inside the row, you will note the
> following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never
> needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be
> created during {{SELECT}} operations only. It should contain only minimally
> necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket
> IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that
> we will need some pieces from it (e.g. cache ID and link for caching
> purposes), but it definitely will be only small subset of the whole
> {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
> {{GridH2Row}}, while in their usages only very relaxed version of
> {{GridH2SearchRow}} is needed. So let's start with new implementation of row
> for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
[
https://issues.apache.org/jira/browse/IGNITE-10985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10985:
-
Labels: performance (was: )
> SQL: create low-overhead implementation of Row for SELECTs
> --
>
> Key: IGNITE-10985
> URL: https://issues.apache.org/jira/browse/IGNITE-10985
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search
> operations. This leads to *huge* memory overhead during {{SELECT}} execution.
> If you take a closer look on what is inside the row, you will note the
> following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never
> needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be
> created during {{SELECT}} operations only. It should contain only minimally
> necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket
> IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that
> we will need some pieces from it (e.g. cache ID and link for caching
> purposes), but it definitely will be only small subset of the whole
> {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return
> {{GridH2Row}}, while in their usages only very relaxed version of
> {{GridH2SearchRow}} is needed. So let's start with new implementation of row
> for these methods and then gradually remove all unnecessary stuff from there.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755105#comment-16755105
]
Stanislav Lukyanov commented on IGNITE-8550:
[~smoldachev] Big thanks for looking into this! I'm afraid this PR needs some
changes though.
First, MySQL spec says that valid values are 0, 1 and 2, not just 1 and 2 - see
the Description of the JIRA. Need to also allow that.
Second, adding a method to a Java interface is an incompatible change. Any
implementations of `JdbcDialect` that may exist out there will stop working
with this change.
One way to approach that would be to use a Java 8's `default` method that would
return 1, and only override it for MySQL.
Third, we need tests. Let's add test cases that would do inserts of new rows,
updates of existing rows and set the row to the same value (i.e. check all
three cases for which MySQL return different values). Without the fix some of
the MySQL test cases will fail, and with the fix they will pass.
Finally, let's add a comment to the MySQL implementation that would explain how
we can get different values from the `INSERT`.
If you have questions - feel free to ask, I'll be happy to assist.
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11128) Add support for composite configuration for Log4J2Logger
[
https://issues.apache.org/jira/browse/IGNITE-11128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Björkman updated IGNITE-11128:
-
Component/s: general
> Add support for composite configuration for Log4J2Logger
>
>
> Key: IGNITE-11128
> URL: https://issues.apache.org/jira/browse/IGNITE-11128
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7
>Reporter: Henrik Björkman
>Priority: Major
>
> Since Log4j2 v2.6 there has been support for composite configurations for
> logging by specifying a comma separated list of configuration files. This is
> however not supported for Ignite logging as one need to give a path to a
> single configuration file to instantiate the \{{Log4J2Logger}}. It would have
> been nice to be able to give a comma separated list of configuration files
> for the Ignite logging as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755059#comment-16755059
]
Alexey Kuznetsov commented on IGNITE-8550:
--
[~smoldachev] Looks good to me.
[~slukyanov] Could you also take a look? If you are also OK, I can merge to
master.
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10261) MVCC: cache operation may hangs during late affinity assignment.
[
https://issues.apache.org/jira/browse/IGNITE-10261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-10261:
---
Assignee: Roman Kondakov (was: Igor Seliverstov)
> MVCC: cache operation may hangs during late affinity assignment.
>
>
> Key: IGNITE-10261
> URL: https://issues.apache.org/jira/browse/IGNITE-10261
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Andrew Mashenkov
>Assignee: Roman Kondakov
>Priority: Critical
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> ForceKey response processing fails with ClassCastException with Mvcc mode
> that causes test hanging.
> Issue can be easily reproduced with backups > 0 and disabled rebalance. See
> GridCacheDhtPreloadPutGetSelfTest.testPutGetNone1().
> Also CacheLateAffinityAssignmentTest.testRandomOperations() hangs sometimes
> due to same reason.
>
> {noformat}
> java.lang.ClassCastException:
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry
> cannot be cast to
> org.apache.ignite.internal.processors.cache.mvcc.MvccVersionAware
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:545)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:202)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processForceKeyResponse(GridDhtCacheAdapter.java:180)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:208)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:206)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1434)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1416)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[ https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11125: --- Description: Currently we can have the same columns for sorted inline indexes twice because in part cases use alternative columns for another case special column _key. To avoid duplicate the same columns need to use alternative columns (real columns) always. For example for CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY (ID1 DESC, ID2)) CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, _KEY instead of ID2 DESC, ID1, MY_VAL DESC was: Currently we can have the same columns for inline indexes twice because in part cases use alternative columns for another case special column _key. To avoid duplicate the same columns need to use alternative columns (real columns) always. For example for CREATE TABLE CACHE_SQL (ID INT PRIMARY KEY, MY_VAL VARCHAR) will be used index with two columns ID and _KEY. > Use alternative column instead of special _key for indexes. > --- > > Key: IGNITE-11125 > URL: https://issues.apache.org/jira/browse/IGNITE-11125 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we can have the same columns for sorted inline indexes twice > because in part cases use alternative columns for another case special column > _key. To avoid duplicate the same columns need to use alternative columns > (real columns) always. > > For example for > CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY > (ID1 DESC, ID2)) > CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) > > will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, _KEY instead of > ID2 DESC, ID1, MY_VAL DESC > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11004) Backout public API changes of IGNITE-9858
[ https://issues.apache.org/jira/browse/IGNITE-11004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755033#comment-16755033 ] Ilya Kasnacheev commented on IGNITE-11004: -- [~xtern] thank you for the fix! I have merged it to master. > Backout public API changes of IGNITE-9858 > - > > Key: IGNITE-11004 > URL: https://issues.apache.org/jira/browse/IGNITE-11004 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Pavel Pereslegin >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > https://github.com/apache/ignite/commit/50dd28d28359930e020cf53d366965fc56b7 > "changes in TcpDiscoveryIpFinderAdapter may violate public API, we definitely > should rolling them back." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755030#comment-16755030
]
Moldachev Sergey commented on IGNITE-8550:
--
[~kuaw26] could you please review my changes?
> CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also
> return 2 or 0
>
>
> Key: IGNITE-8550
> URL: https://issues.apache.org/jira/browse/IGNITE-8550
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Stanislav Lukyanov
>Assignee: Moldachev Sergey
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11128) Add support for composite configuration for Log4J2Logger
[
https://issues.apache.org/jira/browse/IGNITE-11128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Björkman updated IGNITE-11128:
-
Affects Version/s: 2.7
> Add support for composite configuration for Log4J2Logger
>
>
> Key: IGNITE-11128
> URL: https://issues.apache.org/jira/browse/IGNITE-11128
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Henrik Björkman
>Priority: Major
>
> Since Log4j2 v2.6 there has been support for composite configurations for
> logging by specifying a comma separated list of configuration files. This is
> however not supported for Ignite logging as one need to give a path to a
> single configuration file to instantiate the \{{Log4J2Logger}}. It would have
> been nice to be able to give a comma separated list of configuration files
> for the Ignite logging as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11128) Add support for composite configuration for Log4J2Logger
Henrik Björkman created IGNITE-11128:
Summary: Add support for composite configuration for Log4J2Logger
Key: IGNITE-11128
URL: https://issues.apache.org/jira/browse/IGNITE-11128
Project: Ignite
Issue Type: Improvement
Reporter: Henrik Björkman
Since Log4j2 v2.6 there has been support for composite configurations for
logging by specifying a comma separated list of configuration files. This is
however not supported for Ignite logging as one need to give a path to a single
configuration file to instantiate the \{{Log4J2Logger}}. It would have been
nice to be able to give a comma separated list of configuration files for the
Ignite logging as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
[ https://issues.apache.org/jira/browse/IGNITE-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11124: Ignite Flags: (was: Docs Required) > CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover > sometimes throwing oom > - > > Key: IGNITE-11124 > URL: https://issues.apache.org/jira/browse/IGNITE-11124 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This test sometimes throwing OOM it happens because of IgniteTxManager::idMap > contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
[ https://issues.apache.org/jira/browse/IGNITE-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11124: -- Fix Version/s: 2.8 > CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover > sometimes throwing oom > - > > Key: IGNITE-11124 > URL: https://issues.apache.org/jira/browse/IGNITE-11124 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This test sometimes throwing OOM it happens because of IgniteTxManager::idMap > contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11108) Zookeeper validates joining nodes differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755000#comment-16755000 ] Ivan Bessonov edited comment on IGNITE-11108 at 1/29/19 1:19 PM: - Hi [~sboikov], I believe that old "validateNode" method (with one parameter) should be invoked as well, just like it is done in "ServerImpl" class, otherwise we will break many other services. was (Author: ibessonov): Hi [~sboikov], I believe that old "validateNode" method (with one parameter) should be invoked as well, just like it is done "ServerImpl", otherwise we will break many other services. > Zookeeper validates joining nodes differently > - > > Key: IGNITE-11108 > URL: https://issues.apache.org/jira/browse/IGNITE-11108 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.8 > > > Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery > suite I found that GridComponent#validateNode(ClusterNode, > JoiningNodeDiscoveryData) is never invoked so node validation might work > incorrectly. > For example, DistributedMetaStoragePersistentTest#testConflictingData will > fail on Zookeeper discovery, this means that DistributedMetaStorage feature > won't work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11127) GridDhtInvalidPartitionException not handled by GridCacheTtlManager
Ilya Kasnacheev created IGNITE-11127:
Summary: GridDhtInvalidPartitionException not handled by
GridCacheTtlManager
Key: IGNITE-11127
URL: https://issues.apache.org/jira/browse/IGNITE-11127
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.4
Reporter: Ilya Kasnacheev
Leading to either message processing problems:
{code}
[2019-01-27 16:57:45,474][ERROR][sys-stripe-2-#3][GridCacheIoManager] Failed to
process message [senderId=4839b5a2-a295-44cf-8a44-f0cb932b689e,
messageType=class
o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicFullUpdateRequest]
class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
[part=381, msg=Adding entry to partition that is concurrently evicted
[grp=, part=381, shouldBeMoving=, belongs=false,
topVer=AffinityTopologyVersion [topVer=818, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=818, minorTopVer=0]]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:917)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:794)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:952)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:943)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1047)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:835)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1093)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1066)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
at java.lang.Thread.run(Thread.java:748)
{code}
or unhandled unspecified exceptions in user code (possibly violating JCache):
{code}
[2019-01-27 10:23:35,451][ERROR][pub-#840058][ComputeJobProcess] class
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
[part=485, msg=Adding entry to partition that is concurrently evicted
[grp=, part=485, shouldBeMoving=, belongs=false,
topVer=AffinityTopologyVersion [topVer=815, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=815, minorTopVer=0]]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:917)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:794)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
at
[jira] [Updated] (IGNITE-11126) Rework TcpCommunicationSpi.createShmemClient failure detection logic.
[ https://issues.apache.org/jira/browse/IGNITE-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-11126: Description: We need to rework createShmemClient() logic, to support failure detection/exponential backoff timeout logic intruduced in IGNITE-7648. Also isRecoverableError() sleep loop needs to be implemented in case of exception. was:We need to rework > Rework TcpCommunicationSpi.createShmemClient failure detection logic. > - > > Key: IGNITE-11126 > URL: https://issues.apache.org/jira/browse/IGNITE-11126 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > > We need to rework createShmemClient() logic, to support failure > detection/exponential backoff timeout logic intruduced in IGNITE-7648. > Also isRecoverableError() sleep loop needs to be implemented in case of > exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11108) Zookeeper validates joining nodes differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16755000#comment-16755000 ] Ivan Bessonov commented on IGNITE-11108: Hi [~sboikov], I believe that old "validateNode" method (with one parameter) should be invoked as well, just like it is done "ServerImpl", otherwise we will break many other services. > Zookeeper validates joining nodes differently > - > > Key: IGNITE-11108 > URL: https://issues.apache.org/jira/browse/IGNITE-11108 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.8 > > > Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery > suite I found that GridComponent#validateNode(ClusterNode, > JoiningNodeDiscoveryData) is never invoked so node validation might work > incorrectly. > For example, DistributedMetaStoragePersistentTest#testConflictingData will > fail on Zookeeper discovery, this means that DistributedMetaStorage feature > won't work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11126) Rework TcpCommunicationSpi.createShmemClient failure detection logic.
[ https://issues.apache.org/jira/browse/IGNITE-11126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-11126: Description: We need to rework > Rework TcpCommunicationSpi.createShmemClient failure detection logic. > - > > Key: IGNITE-11126 > URL: https://issues.apache.org/jira/browse/IGNITE-11126 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Priority: Major > > We need to rework -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11126) Rework TcpCommunicationSpi.createShmemClient failure detection logic.
Pavel Voronkin created IGNITE-11126: --- Summary: Rework TcpCommunicationSpi.createShmemClient failure detection logic. Key: IGNITE-11126 URL: https://issues.apache.org/jira/browse/IGNITE-11126 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10219) MVCC: TX: Backup node update may fails after lost tx rollback.
[ https://issues.apache.org/jira/browse/IGNITE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754974#comment-16754974 ] Andrew Mashenkov edited comment on IGNITE-10219 at 1/29/19 12:52 PM: - Looks like it was fixed within IGNITE-10752. Just unmute a test. was (Author: amashenkov): Looks like it was fixed within IGNITE-10752. Test unmuted. > MVCC: TX: Backup node update may fails after lost tx rollback. > -- > > Key: IGNITE-10219 > URL: https://issues.apache.org/jira/browse/IGNITE-10219 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > Attachments: CacheMvccTxFailoverTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > The use case: > # Start Tx and update entry. > # Kill backup. > # Rollback Tx (backup miss this tx state change due to outage) > # Start backup. > # Update same entry may fails with unknown tx state for latest entry version. > Backup won't rebalance partition for the key as rollback doesn't increment > partition counter and can't found active transaction for latest entry version > as TxLog contains neither commit nor rollback record. > Also Tx can't be detected as rolled back as mvcc coordinator version hasn't > changed during backup node outage. > > Possible solutions are > # Increment mvcc coordinator version on every node join event that need to > be carefully tested. > # Scan cache to cleanup such entries on node startup (right after recovery > from WAL) which is inefficient. > # Or may be log Tx start in TxLog and rollback all active Tx on node startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9171) Use lazy mode with results pre-fetch
[
https://issues.apache.org/jira/browse/IGNITE-9171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754986#comment-16754986
]
Ignite TC Bot commented on IGNITE-9171:
---
{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=2893225buildTypeId=IgniteTests24Java8_RunAll]
> Use lazy mode with results pre-fetch
>
>
> Key: IGNITE-9171
> URL: https://issues.apache.org/jira/browse/IGNITE-9171
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Labels: sql-stability
> Fix For: 2.8
>
>
> Current implementation of the {{lazy}} mode always starts separate thread for
> {{MapQueryLazyWorker}}. It causes excessive overhead for requests that
> produces small results set.
> We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch
> first page of the results. In case results set is bigger than one page
> {{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle
> next pages lazy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11108) Zookeeper validates joining nodes differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11108: Ignite Flags: (was: Docs Required) > Zookeeper validates joining nodes differently > - > > Key: IGNITE-11108 > URL: https://issues.apache.org/jira/browse/IGNITE-11108 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.8 > > > Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery > suite I found that GridComponent#validateNode(ClusterNode, > JoiningNodeDiscoveryData) is never invoked so node validation might work > incorrectly. > For example, DistributedMetaStoragePersistentTest#testConflictingData will > fail on Zookeeper discovery, this means that DistributedMetaStorage feature > won't work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10219) MVCC: TX: Backup node update may fails after lost tx rollback.
[ https://issues.apache.org/jira/browse/IGNITE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754974#comment-16754974 ] Andrew Mashenkov commented on IGNITE-10219: --- Looks like it was fixed within IGNITE-10752. Test unmuted. > MVCC: TX: Backup node update may fails after lost tx rollback. > -- > > Key: IGNITE-10219 > URL: https://issues.apache.org/jira/browse/IGNITE-10219 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > Attachments: CacheMvccTxFailoverTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > The use case: > # Start Tx and update entry. > # Kill backup. > # Rollback Tx (backup miss this tx state change due to outage) > # Start backup. > # Update same entry may fails with unknown tx state for latest entry version. > Backup won't rebalance partition for the key as rollback doesn't increment > partition counter and can't found active transaction for latest entry version > as TxLog contains neither commit nor rollback record. > Also Tx can't be detected as rolled back as mvcc coordinator version hasn't > changed during backup node outage. > > Possible solutions are > # Increment mvcc coordinator version on every node join event that need to > be carefully tested. > # Scan cache to cleanup such entries on node startup (right after recovery > from WAL) which is inefficient. > # Or may be log Tx start in TxLog and rollback all active Tx on node startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11108) Zookeeper validates joining nodes differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11108: Fix Version/s: 2.8 > Zookeeper validates joining nodes differently > - > > Key: IGNITE-11108 > URL: https://issues.apache.org/jira/browse/IGNITE-11108 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.8 > > > Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery > suite I found that GridComponent#validateNode(ClusterNode, > JoiningNodeDiscoveryData) is never invoked so node validation might work > incorrectly. > For example, DistributedMetaStoragePersistentTest#testConflictingData will > fail on Zookeeper discovery, this means that DistributedMetaStorage feature > won't work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10219) MVCC: TX: Backup node update may fails after lost tx rollback.
[ https://issues.apache.org/jira/browse/IGNITE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-10219: - Assignee: Andrew Mashenkov > MVCC: TX: Backup node update may fails after lost tx rollback. > -- > > Key: IGNITE-10219 > URL: https://issues.apache.org/jira/browse/IGNITE-10219 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Labels: mvcc_stabilization_stage_1, transactions > Fix For: 2.8 > > Attachments: CacheMvccTxFailoverTest.java > > > The use case: > # Start Tx and update entry. > # Kill backup. > # Rollback Tx (backup miss this tx state change due to outage) > # Start backup. > # Update same entry may fails with unknown tx state for latest entry version. > Backup won't rebalance partition for the key as rollback doesn't increment > partition counter and can't found active transaction for latest entry version > as TxLog contains neither commit nor rollback record. > Also Tx can't be detected as rolled back as mvcc coordinator version hasn't > changed during backup node outage. > > Possible solutions are > # Increment mvcc coordinator version on every node join event that need to > be carefully tested. > # Scan cache to cleanup such entries on node startup (right after recovery > from WAL) which is inefficient. > # Or may be log Tx start in TxLog and rollback all active Tx on node startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11125) Use alternative column instead of special _key for indexes.
Yury Gerzhedovich created IGNITE-11125: -- Summary: Use alternative column instead of special _key for indexes. Key: IGNITE-11125 URL: https://issues.apache.org/jira/browse/IGNITE-11125 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Fix For: 2.8 Currently we can have the same columns for inline indexes twice because in part cases use alternative columns for another case special column _key. To avoid duplicate the same columns need to use alternative columns (real columns) always. For example for CREATE TABLE CACHE_SQL (ID INT PRIMARY KEY, MY_VAL VARCHAR) will be used index with two columns ID and _KEY. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10604) MVCC: mvcc history can be missed during remove operation.
[
https://issues.apache.org/jira/browse/IGNITE-10604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-10604:
-
Assignee: Andrew Mashenkov
> MVCC: mvcc history can be missed during remove operation.
> -
>
> Key: IGNITE-10604
> URL: https://issues.apache.org/jira/browse/IGNITE-10604
> Project: Ignite
> Issue Type: Bug
> Components: data structures, mvcc
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> IgniteAtomicLongChangingTopologySelfTest.testClientAtomicLongCreateCloseFailover
> fails on closing IgniteAtomicLong datastructure.
> CacheLateAffinityAssignmentTest.testNoForceKeysRequests() failed with same
> error.
> The root cause is DhtEnlist request for REMOVE operation with no history
> fails on MOVING partition.
>
> {noformat}
> [2018-12-07
> 20:05:14,674][ERROR][sys-stripe-6-#10748%dht.IgniteAtomicLongChangingTopologySelfTest3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=SingletonSet [SYSTEM_WORKER_BLOCKED]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.AssertionError]]
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.addToBatch(GridDhtTxAbstractEnlistFuture.java:701)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.processEntry(GridDhtTxAbstractEnlistFuture.java:651)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:534)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:363)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxEnlistRequest(GridDhtTransactionalCacheAdapter.java:2065)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$900(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$14.apply(GridDhtTransactionalCacheAdapter.java:229)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$14.apply(GridDhtTransactionalCacheAdapter.java:227)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10986) SQL: drop _VER field support
[
https://issues.apache.org/jira/browse/IGNITE-10986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10986:
-
Ignite Flags: (was: Docs Required)
> SQL: drop _VER field support
>
>
> Key: IGNITE-10986
> URL: https://issues.apache.org/jira/browse/IGNITE-10986
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.8
>
>
> {{_VER}} is undocumented hidden field which is never used in practice. But
> profiling shows that it consumes a lot of memory. Let's drop support of this
> field from all {{GridH2SearchRow}} implementations, as well as from internal
> descriptors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754961#comment-16754961
]
Vladimir Ozerov commented on IGNITE-10305:
--
Merged to master.
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
[ https://issues.apache.org/jira/browse/IGNITE-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim reassigned IGNITE-11124: - Assignee: Stepachev Maksim > CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover > sometimes throwing oom > - > > Key: IGNITE-11124 > URL: https://issues.apache.org/jira/browse/IGNITE-11124 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > > This test sometimes throwing OOM it happens because of IgniteTxManager::idMap > contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11121) MVCC TX: AssertionError in discovery manager on BLT change.
[
https://issues.apache.org/jira/browse/IGNITE-11121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11121:
Description:
The next exception occurred in logs on BLT change.
{noformat}
[12:11:36,912][SEVERE][sys-#87][GridClosureProcessor] Closure execution failed
with error.
java.lang.AssertionError
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1794)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1693)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.lambda$onTimeout0$16553d7$1(IgniteTxManager.java:2592)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2588)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$3300(IgniteTxManager.java:2505)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$1.run(IgniteTxManager.java:2623)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6874)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
>From the stack trace I see there is a node failure which causes transactions
>recovery and uninitialized Mvcc coordinator (it means there are no server
>nodes, or there is a coordinatorAssignClosure which returns no result, or a
>recovering node was not activated)
the scenario, where the exception may be observed:
# Start a cluster
# Load some data (from client node, the client node is shut down after that)
# Calculate hash
# Add new server node
# Change BLT
# Wait for rebalance
# Calculate new hash and check it is the same as previously calculated
was:
The next exception occurred in logs on BLT change.
{noformat}
[12:11:36,912][SEVERE][sys-#87][GridClosureProcessor] Closure execution failed
with error.
java.lang.AssertionError
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1794)
at
org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1693)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.lambda$onTimeout0$16553d7$1(IgniteTxManager.java:2592)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2588)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$3300(IgniteTxManager.java:2505)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$1.run(IgniteTxManager.java:2623)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6874)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
>From the stack trace I see there is a node failure which causes transactions
>recovery and uninitialized Mvcc coordinator (it means there are no server
>nodes, or there is a coordinatorAssignClosure which returns no result, or a
>recovering node was not activated)
the scenario, where the exception may be observed:
* Start a cluster
* Load some data (from client node, the client node is shut down after that)
* Calculate hash
* Add new server node
* Change BLT
* Wait for rebalance
* Calculate new hash and check it is the same as previously calculated
> MVCC TX: AssertionError in discovery manager on BLT change.
>
[jira] [Created] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
Stepachev Maksim created IGNITE-11124: - Summary: CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom Key: IGNITE-11124 URL: https://issues.apache.org/jira/browse/IGNITE-11124 Project: Ignite Issue Type: Improvement Reporter: Stepachev Maksim This test sometimes throwing OOM it happens because of IgniteTxManager::idMap contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10749) Improve speed of checkpoint finalization on binary memory recovery
[
https://issues.apache.org/jira/browse/IGNITE-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754928#comment-16754928
]
Ivan Rakov commented on IGNITE-10749:
-
[~DmitriyGovorukhin], looks good now. Please proceed with merge.
> Improve speed of checkpoint finalization on binary memory recovery
> --
>
> Key: IGNITE-10749
> URL: https://issues.apache.org/jira/browse/IGNITE-10749
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.0
>Reporter: Pavel Kovalenko
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Stopping node during checkpoint leads to binary memory recovery after node
> start.
> When binary memory is restored node performs checkpoint that fixes the
> consistent state of the page memory.
> It happens there
> {noformat}
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#finalizeCheckpointOnRecovery
> {noformat}
> Looking at the implementation of this method we can notice that it performs
> finalization in 1 thread, which is not optimal. This process can be speed-up
> using parallelization of collecting checkpoint pages like in regular
> checkpoints.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11123) MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure.
[ https://issues.apache.org/jira/browse/IGNITE-11123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754915#comment-16754915 ] Oleg Ignatenko commented on IGNITE-11123: - (i) in PR 5925 there is an example of how this can be reworked: [method skipIfNotSupported|https://github.com/apache/ignite/blob/1ee033459ac8f2ef0804029f5ce8f4caf5ddf5b6/modules/core/src/test/java/org/apache/ignite/testframework/MvccFeatureChecker.java] > MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure. > -- > > Key: IGNITE-11123 > URL: https://issues.apache.org/jira/browse/IGNITE-11123 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Let's rewrite MvccFeatureChecker.validateFeature() method with using JUnit4 > Assume instead of Assert.fail(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11123) MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure.
[ https://issues.apache.org/jira/browse/IGNITE-11123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11123: -- Description: Let's rewrite MvccFeatureChecker.validateFeature() method with using JUnit4 Assume instead of Assert.fail(). (was: Let's rewrite mvcc feature checks with using JUnit4 Assume instead of Assert.fail().) > MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure. > -- > > Key: IGNITE-11123 > URL: https://issues.apache.org/jira/browse/IGNITE-11123 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Let's rewrite MvccFeatureChecker.validateFeature() method with using JUnit4 > Assume instead of Assert.fail(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754902#comment-16754902
]
Sergey Chugunov commented on IGNITE-10927:
--
[~oignatenko],
Change looks good to me.
There is a way to fix the issue with {{org.junit.Assert.assertEquals(float,
float)}}, I'll leave a comment in IGNITE-6 about it.
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should respective
> {{2deprecation}} notices in javadocs that would encourage developers to
> (safely and gradually) change them to direct invocations and static imports
> of respective Assert methods instead of using those inherited from
> superclass. These patch methods should be declared {{protected final}} or
> {{protected static}}, in order to minimize their applicability and prevent
> them spreading more than intended. (as a side note, experimenting has shown
> that use of {{@Deprecated}} annotation is not feasible as it deprives
> developers an option to use static imports)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10764) MVCC: Transactions failed to acquire lock within timeout
[
https://issues.apache.org/jira/browse/IGNITE-10764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754909#comment-16754909
]
Ignite TC Bot commented on IGNITE-10764:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2893911]]
* IgnitePdsTestSuite:
BPlusTreeReuseListPageMemoryImplTest.testSizeForRandomPutRmvMultithreadedAsync_16
- 0,0% fails in last 430 master runs.
{color:#d04437}Cache 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2893895]]
* IgniteBinaryObjectsCacheTestSuite3:
IgniteCacheGroupsTest.testEntriesTtlAtomicPartitioned - 0,0% fails in last 277
master runs.
{color:#d04437}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2893901]]
* IgniteCacheTestSuite9: IoStatisticsManagerSelfTest.testPersistentIOGlobalStat
- 0,0% fails in last 76 master runs.
{color:#d04437}Cache 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2893896]]
* IgniteCacheTestSuite4:
CacheStoreUsageMultinodeDynamicStartTxTest.testDynamicStartWriteBehindStore -
0,0% fails in last 423 master runs.
{color:#d04437}Platform C++ (Win x64 | Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=2893870]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2893944buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Transactions failed to acquire lock within timeout
>
>
> Key: IGNITE-10764
> URL: https://issues.apache.org/jira/browse/IGNITE-10764
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some tests failed sporadically due to a transaction timeout though they
> update unique keys and deadlocks are not expected. It should be investigated.
> Reproducers:
> {{CacheMvccPartitionedSqlTxQueriesTest.testQueryInsertMultithread}}
> {{CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11123) MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure.
[ https://issues.apache.org/jira/browse/IGNITE-11123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11123: -- Ignite Flags: (was: Docs Required) > MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure. > -- > > Key: IGNITE-11123 > URL: https://issues.apache.org/jira/browse/IGNITE-11123 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Let's rewrite mvcc feature checks with using JUnit4 Assume instead of > Assert.fail(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754907#comment-16754907
]
Igor Seliverstov commented on IGNITE-10766:
---
[~Pavlukhin], looks good, merged to master.
> MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails
> sporadically
> -
>
> Key: IGNITE-10766
> URL: https://issues.apache.org/jira/browse/IGNITE-10766
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging, failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Attachments: testCountersNeighborcastServerFailed
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}} sporadically
> hangs on exchange. It should be investigated.
> Looks like the similar problem is in
> {{GridCachePartitionsStateValidationTest#testPartitionCountersConsistencyOnExchange}}
> with enabled MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[
https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754894#comment-16754894
]
Ignite TC Bot commented on IGNITE-8728:
---
{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=2929323buildTypeId=IgniteTests24Java8_RunAll]
> "IllegalStateException: Duplicate Key" on node join
> ---
>
> Key: IGNITE-8728
> URL: https://issues.apache.org/jira/browse/IGNITE-8728
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Mahesh Renduchintala
>Assignee: Stanislav Lukyanov
>Priority: Critical
> Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log,
> node-config.xml
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I have two nodes on which we have 3 tables which are partitioned. Index are
> also built on these tables.
> For 24 hours caches work fine. The tables are definitely distributed across
> both the nodes
> Node 2 reboots due to some issue - goes out of the baseline - comes back and
> joins the baseline. Other baseline nodes crash and in the logs we see
> duplicate Key error
> [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery
> accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102]
> [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery
> spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102]
> [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started
> serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102]
> [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi]
> Finished serving remote node connection [rmtAddr=/192.168.1.7:45102,
> rmtPort=45102
> [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> *java.lang.IllegalStateException: Duplicate key*
> at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
> at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
> at
> org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
> at
> org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException:
> Duplicate key]]
> java.lang.IllegalStateException: Duplicate key
> at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
> at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
> at
> org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
> at
> org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
>
[jira] [Updated] (IGNITE-11123) MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure.
[ https://issues.apache.org/jira/browse/IGNITE-11123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11123: -- Issue Type: Sub-task (was: Test) Parent: IGNITE-10951 > MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure. > -- > > Key: IGNITE-11123 > URL: https://issues.apache.org/jira/browse/IGNITE-11123 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > Let's rewrite mvcc feature checks with using JUnit4 Assume instead of > Assert.fail(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10749) Improve speed of checkpoint finalization on binary memory recovery
[
https://issues.apache.org/jira/browse/IGNITE-10749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754904#comment-16754904
]
Dmitriy Govorukhin commented on IGNITE-10749:
-
[~ivan.glukos] Done, please review again.
> Improve speed of checkpoint finalization on binary memory recovery
> --
>
> Key: IGNITE-10749
> URL: https://issues.apache.org/jira/browse/IGNITE-10749
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.0
>Reporter: Pavel Kovalenko
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Stopping node during checkpoint leads to binary memory recovery after node
> start.
> When binary memory is restored node performs checkpoint that fixes the
> consistent state of the page memory.
> It happens there
> {noformat}
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#finalizeCheckpointOnRecovery
> {noformat}
> Looking at the implementation of this method we can notice that it performs
> finalization in 1 thread, which is not optimal. This process can be speed-up
> using parallelization of collecting checkpoint pages like in regular
> checkpoints.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10963) Cache 2 suite hangs on CacheLockReleaseNodeLeaveTest#testLockNodeStop
[
https://issues.apache.org/jira/browse/IGNITE-10963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754900#comment-16754900
]
Ryabov Dmitrii commented on IGNITE-10963:
-
[~DmitriyGovorukhin], done.
> Cache 2 suite hangs on CacheLockReleaseNodeLeaveTest#testLockNodeStop
> -
>
> Key: IGNITE-10963
> URL: https://issues.apache.org/jira/browse/IGNITE-10963
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Suite fails with timeout exception on
> {{CacheLockReleaseNodeLeaveTest#testLockNodeStop}} test.
> One node isn't finished and trying to send messages to left node.
> [Suite
> fails|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E=failed],
> [build log with
> timeout|https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=2791865&_focus=44168].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11123) MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure.
Andrew Mashenkov created IGNITE-11123: - Summary: MVCC: Fix MvccFeatureChecker to throw assumption exception instead of failure. Key: IGNITE-11123 URL: https://issues.apache.org/jira/browse/IGNITE-11123 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov Fix For: 2.8 Let's rewrite mvcc feature checks with using JUnit4 Assume instead of Assert.fail(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[ https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754896#comment-16754896 ] Stanislav Lukyanov commented on IGNITE-8728: [~amashenkov], Done. Can you take another look? > "IllegalStateException: Duplicate Key" on node join > --- > > Key: IGNITE-8728 > URL: https://issues.apache.org/jira/browse/IGNITE-8728 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Assignee: Stanislav Lukyanov >Priority: Critical > Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log, > node-config.xml > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have two nodes on which we have 3 tables which are partitioned. Index are > also built on these tables. > For 24 hours caches work fine. The tables are definitely distributed across > both the nodes > Node 2 reboots due to some issue - goes out of the baseline - comes back and > joins the baseline. Other baseline nodes crash and in the logs we see > duplicate Key error > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started > serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102] > [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] > Finished serving remote node connection [rmtAddr=/192.168.1.7:45102, > rmtPort=45102 > [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi] > TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node > in order to prevent cluster wide instability. > *java.lang.IllegalStateException: Duplicate key* > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error > detected. Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: > Duplicate key]] > java.lang.IllegalStateException: Duplicate key > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,460][SEVERE][tcp-disco-msg-worker-#3|#3][] JVM will
[jira] [Commented] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754897#comment-16754897
]
Ignite TC Bot commented on IGNITE-10766:
{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=2930820buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails
> sporadically
> -
>
> Key: IGNITE-10766
> URL: https://issues.apache.org/jira/browse/IGNITE-10766
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Hanging, failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Attachments: testCountersNeighborcastServerFailed
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}} sporadically
> hangs on exchange. It should be investigated.
> Looks like the similar problem is in
> {{GridCachePartitionsStateValidationTest#testPartitionCountersConsistencyOnExchange}}
> with enabled MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
