[jira] [Resolved] (IGNITE-6928) Web console: use redesigned context menus everywhere
[ https://issues.apache.org/jira/browse/IGNITE-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov resolved IGNITE-6928. -- Resolution: Won't Fix > Web console: use redesigned context menus everywhere > > > Key: IGNITE-6928 > URL: https://issues.apache.org/jira/browse/IGNITE-6928 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > At the moment web console has two distinct context menu styles. Eventually, > all older context menus have to be replaced with newer ones. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (IGNITE-8094) Web console: investigate/fix broken E2E test for basic editing
[
https://issues.apache.org/jira/browse/IGNITE-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov resolved IGNITE-8094.
--
Resolution: Won't Fix
This has already been fixed.
> Web console: investigate/fix broken E2E test for basic editing
> --
>
> Key: IGNITE-8094
> URL: https://issues.apache.org/jira/browse/IGNITE-8094
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> The "Basic editing" E2E test fails if you use {{save}} page model method
> instead of {{saveWithoutDownload}}. I suspect it might be another case of
> incompatibility between some of directives (it was {{on-focus-out}} before)
> and TestCafe overlays. If fixed, restore {{saveWithoutDownload}} call back to
> {{save}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (IGNITE-9476) Web console: extract configuration-specific mixins from mixins.pug
[ https://issues.apache.org/jira/browse/IGNITE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov resolved IGNITE-9476. -- Resolution: Duplicate Already done in https://issues.apache.org/jira/browse/IGNITE-9879. > Web console: extract configuration-specific mixins from mixins.pug > -- > > Key: IGNITE-9476 > URL: https://issues.apache.org/jira/browse/IGNITE-9476 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > Most of form field Pug mixins used in configuration are very specific to it > and are not used elsewhere. The _mixins.pug_ that these currently reside in > is too big for my liking. I suggest to move all configuration mixins to > configuration module (for example, _page-configure/mixins.pug_), with the > following benefits: > # All code specific to configuration will stay in configuration module. > # mixins.pug will become easier to maintain. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12126) ODBC: SQLNumResultCols for prepared statement
AH created IGNITE-12126: --- Summary: ODBC: SQLNumResultCols for prepared statement Key: IGNITE-12126 URL: https://issues.apache.org/jira/browse/IGNITE-12126 Project: Ignite Issue Type: Bug Components: odbc Affects Versions: 2.7.5 Environment: Windows 7 Reporter: AH According to ODBC Programmer's Reference, SQLNumResultCols can be called successfully only when the statement is in the prepared, executed, or positioned state. However, it is not working when the statement is in the prepared state and not yet executed: column count returned is 0. Full Connect(Default) Env. Attr. SQL_ATTR_ODBC_VERSION set to SQL_OV_ODBC3 Successfully connected to DSN 'Apache Ignite DSN'. SQLExecDirect: In: Statementhandle = 0x005C3828, StatementText = "SELECT * FROM M.I where 1 = 0", Statementlength = 37 Return: SQL_SUCCESS=0 SQLNumResultCols: In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 Return: SQL_SUCCESS=0 Out: *ColumnCountPtr = 20 SQLPrepare: In: StatementHandle = 0x005C3828, StatementText = "SELECT * FROM M.I where 1 = 0", TextLength = 37 Return: SQL_SUCCESS=0 SQLExecute: In: StatementHandle = 0x005C3828 Return: SQL_SUCCESS=0 SQLNumResultCols: In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 Return: SQL_SUCCESS=0 Out: *ColumnCountPtr = 20 Not working: SQLPrepare: In: StatementHandle = 0x005C3828, StatementText = "SELECT * FROM M.I where 1 = 0", TextLength = 37 Return: SQL_SUCCESS=0 SQLNumResultCols: In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 Return: SQL_SUCCESS=0 Out: *ColumnCountPtr = 0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12103) Change the default ignite work directory once again to avoid writing to ~/work
[
https://issues.apache.org/jira/browse/IGNITE-12103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918941#comment-16918941
]
Denis Magda commented on IGNITE-12103:
--
[~ilyak], I left a minor comment in PR. The rest is good, thanks.
> Change the default ignite work directory once again to avoid writing to ~/work
> --
>
> Key: IGNITE-12103
> URL: https://issues.apache.org/jira/browse/IGNITE-12103
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.7.6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While testing 2.7.6-RC1 it came up that we no longer write data to
> /tmp/ignite/work, which is good, but now we would instead write to
> /home/username/work, which is bad. ~/work is a generic directory not linked
> to Ignite in any obvious way, and users will be puzzled by its appearance
> with possibilities of data loss or, even worse, their own documents loss if
> they happen to have something in Work dir and it gets clobbered/removed by
> accident.
> I suggest changing this default once more, to use either
> /home/username/ignite/{work,logs,etc} or ./ignite/{work,logs,etc} by
> leveraging user.dir property pointing to current working dir.
> Please note that user.dir has its own problems since it is supposed to not be
> changeable after JVM is up, but some code still tries to change it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12125) Concurrency problem in PagesWriteThrottle
[
https://issues.apache.org/jira/browse/IGNITE-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918917#comment-16918917
]
Sergey Antonov commented on IGNITE-12125:
-
[~ivan.glukos] Could you review my changes please?
> Concurrency problem in PagesWriteThrottle
> -
>
> Key: IGNITE-12125
> URL: https://issues.apache.org/jira/browse/IGNITE-12125
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-12006 and IGNITE-9231 was added code:
> {code}
> parkThrds.forEach(LockSupport::unpark);
> parkThrds.clear();
> {code}
> This code isn't thread-safe. We should remove from {{parkThrds}} only
> unparked threads.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12125) Concurrency problem in PagesWriteThrottle
[
https://issues.apache.org/jira/browse/IGNITE-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918916#comment-16918916
]
Ignite TC Bot commented on IGNITE-12125:
{panel:title=Branch: [pull/6826/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0 JVM CRASH
|https://ci.ignite.apache.org/viewLog.html?buildId=4548950]]
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3185237&buildTypeId=IgniteTests24Java8_RunAll]
> Concurrency problem in PagesWriteThrottle
> -
>
> Key: IGNITE-12125
> URL: https://issues.apache.org/jira/browse/IGNITE-12125
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-12006 and IGNITE-9231 was added code:
> {code}
> parkThrds.forEach(LockSupport::unpark);
> parkThrds.clear();
> {code}
> This code isn't thread-safe. We should remove from {{parkThrds}} only
> unparked threads.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12125) Concurrency problem in PagesWriteThrottle
Sergey Antonov created IGNITE-12125:
---
Summary: Concurrency problem in PagesWriteThrottle
Key: IGNITE-12125
URL: https://issues.apache.org/jira/browse/IGNITE-12125
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
In IGNITE-12006 and IGNITE-9231 were added code:
{code}
parkThrds.forEach(LockSupport::unpark);
parkThrds.clear();
{code}
This code isn't thread-safe. We should remove from {{parkThrds}} only unparked
threads.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12121) Double checkpoint triggering due to incorrect place of update current checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-12121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918744#comment-16918744
]
Ignite TC Bot commented on IGNITE-12121:
{panel:title=Branch: [pull/6824/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4547876&buildTypeId=IgniteTests24Java8_RunAll]
> Double checkpoint triggering due to incorrect place of update current
> checkpoint
>
>
> Key: IGNITE-12121
> URL: https://issues.apache.org/jira/browse/IGNITE-12121
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Double checkpoint triggering due to incorrect place of update current
> checkpoint. This can lead to two ckeckpoints one by one if checkpoint trigger
> was 'too many dirty pages'.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12124) Stopping the cache does not wait for expiration process, which may be started and may lead to errors
Vyacheslav Koptilin created IGNITE-12124: Summary: Stopping the cache does not wait for expiration process, which may be started and may lead to errors Key: IGNITE-12124 URL: https://issues.apache.org/jira/browse/IGNITE-12124 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin Fix For: 2.8 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12125) Concurrency problem in PagesWriteThrottle
[
https://issues.apache.org/jira/browse/IGNITE-12125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12125:
Description:
In IGNITE-12006 and IGNITE-9231 was added code:
{code}
parkThrds.forEach(LockSupport::unpark);
parkThrds.clear();
{code}
This code isn't thread-safe. We should remove from {{parkThrds}} only unparked
threads.
was:
In IGNITE-12006 and IGNITE-9231 were added code:
{code}
parkThrds.forEach(LockSupport::unpark);
parkThrds.clear();
{code}
This code isn't thread-safe. We should remove from {{parkThrds}} only unparked
threads.
> Concurrency problem in PagesWriteThrottle
> -
>
> Key: IGNITE-12125
> URL: https://issues.apache.org/jira/browse/IGNITE-12125
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
>
> In IGNITE-12006 and IGNITE-9231 was added code:
> {code}
> parkThrds.forEach(LockSupport::unpark);
> parkThrds.clear();
> {code}
> This code isn't thread-safe. We should remove from {{parkThrds}} only
> unparked threads.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12038) Fix several failing tests after IGNITE-10078
[ https://issues.apache.org/jira/browse/IGNITE-12038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918720#comment-16918720 ] Alexei Scherbakov commented on IGNITE-12038: The contribution contains a bunch of fixes related to new partition counter implementation (IGNITE-10078) discovered during private testing. This also should fix mentioned above tests. List of fixes: Fixed issues related to incorrect partition clearing in OWNING state. Fixed RENTING->EVICTED partition state change prevention. CheckpointReadLock() may hang during node stop - fixed. Fixed invalid invalid topology version assertion thrown on PartitionCountersNeighborcastRequest. Fixed an issue when cross-cache tx is mapped on wrong primary when enlisted caches have incompatible assignments. Now transactions will be rolled back if are preparing on invalid primary node. Stablilized LocalWalModeChangeDuringRebalancingSelfTest. [~ivan.glukos] could you do review? > Fix several failing tests after IGNITE-10078 > > > Key: IGNITE-12038 > URL: https://issues.apache.org/jira/browse/IGNITE-12038 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > *New stable failure of a flaky test in master > LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6585115376754732686&branch=%3Cdefault%3E&tab=testDetails > *New stable failure of a flaky test in master > GridCacheRebalancingWithAsyncClearingMvccTest.testPartitionClearingNotBlockExchange > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7007912051428984819&branch=%3Cdefault%3E&tab=testDetails > *New stable failure of a flaky test in master > GridCacheRebalancingAsyncSelfTest.testComplexRebalancing > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8829809273565657995&branch=%3Cdefault%3E&tab=testDetails -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12038) Fix several failing tests after IGNITE-10078
[
https://issues.apache.org/jira/browse/IGNITE-12038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918710#comment-16918710
]
Ignite TC Bot commented on IGNITE-12038:
{panel:title=Branch: [pull/6746/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4546480&buildTypeId=IgniteTests24Java8_RunAll]
> Fix several failing tests after IGNITE-10078
>
>
> Key: IGNITE-12038
> URL: https://issues.apache.org/jira/browse/IGNITE-12038
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New stable failure of a flaky test in master
> LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6585115376754732686&branch=%3Cdefault%3E&tab=testDetails
> *New stable failure of a flaky test in master
> GridCacheRebalancingWithAsyncClearingMvccTest.testPartitionClearingNotBlockExchange
>
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7007912051428984819&branch=%3Cdefault%3E&tab=testDetails
> *New stable failure of a flaky test in master
> GridCacheRebalancingAsyncSelfTest.testComplexRebalancing
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8829809273565657995&branch=%3Cdefault%3E&tab=testDetails
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12123) Cache throws npe at {null, null, null} array key.
[
https://issues.apache.org/jira/browse/IGNITE-12123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepachev Maksim updated IGNITE-12123:
--
Description:
When we put null-key to ignite cache we get NPE with the problem description
"java.lang.NullPointerException: Ouch! Argument cannot be null: key"
But when we put "new String[]
{"c", *null*, "a"}
> Cache throws npe at {null, null, null} array key.
> -
>
> Key: IGNITE-12123
> URL: https://issues.apache.org/jira/browse/IGNITE-12123
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
>
> When we put null-key to ignite cache we get NPE with the problem description
> "java.lang.NullPointerException: Ouch! Argument cannot be null: key"
> But when we put "new String[]
> {"c", *null*, "a"}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12123) Cache throws npe at {null, null, null} array key.
[
https://issues.apache.org/jira/browse/IGNITE-12123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepachev Maksim updated IGNITE-12123:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Cache throws npe at {null, null, null} array key.
> -
>
> Key: IGNITE-12123
> URL: https://issues.apache.org/jira/browse/IGNITE-12123
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
>
> When we put null-key to ignite cache we get NPE with the problem description
> "java.lang.NullPointerException: Ouch! Argument cannot be null: key"
> But when we put "new String[]
> {"c", *null*, "a"}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12113) control.sh terminates silently when JAVA_HOME is not set
[
https://issues.apache.org/jira/browse/IGNITE-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12113:
--
Fix Version/s: (was: 2.8)
> control.sh terminates silently when JAVA_HOME is not set
>
>
> Key: IGNITE-12113
> URL: https://issues.apache.org/jira/browse/IGNITE-12113
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.7.6
>
> Attachments:
> IGNITE-12113_Fix_silent_control_sh_fail_when_JAVA_HOME_is_empty.patch
>
>
> Running control.sh from ignite-2.7.6 release candidate on MacOS with empty
> JAVA_HOME produces no output - the script terminates without any action.
> The reason is the following line in {{bin/control.sh}}:
> {code}
> javaMajorVersion "${JAVA_HOME}/bin/java"
> {code}
> Since {{JAVA_HOME}} is empty, the argument passed to the function is invalid
> and the function terminates the script. I suggest replacing the
> {{${JAVA_HOME}/bin/java}} with just {{$JAVA}} because it is already
> determined earlier in the scope. The suggested fix works in my environment
> for all options of {{JAVA_HOME}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12113) control.sh terminates silently when JAVA_HOME is not set
[
https://issues.apache.org/jira/browse/IGNITE-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12113:
--
Release Note: Fixed silent control.sh script termination when JAVA_HOME is
not set
> control.sh terminates silently when JAVA_HOME is not set
>
>
> Key: IGNITE-12113
> URL: https://issues.apache.org/jira/browse/IGNITE-12113
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8, 2.7.6
>
> Attachments:
> IGNITE-12113_Fix_silent_control_sh_fail_when_JAVA_HOME_is_empty.patch
>
>
> Running control.sh from ignite-2.7.6 release candidate on MacOS with empty
> JAVA_HOME produces no output - the script terminates without any action.
> The reason is the following line in {{bin/control.sh}}:
> {code}
> javaMajorVersion "${JAVA_HOME}/bin/java"
> {code}
> Since {{JAVA_HOME}} is empty, the argument passed to the function is invalid
> and the function terminates the script. I suggest replacing the
> {{${JAVA_HOME}/bin/java}} with just {{$JAVA}} because it is already
> determined earlier in the scope. The suggested fix works in my environment
> for all options of {{JAVA_HOME}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12123) Cache throws npe at {null, null, null} array key.
Stepachev Maksim created IGNITE-12123:
-
Summary: Cache throws npe at {null, null, null} array key.
Key: IGNITE-12123
URL: https://issues.apache.org/jira/browse/IGNITE-12123
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8
Reporter: Stepachev Maksim
Assignee: Stepachev Maksim
Fix For: 2.8
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12116) Cache doesn't support array as key
[ https://issues.apache.org/jira/browse/IGNITE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918620#comment-16918620 ] Stepachev Maksim commented on IGNITE-12116: --- [~xtern] Oh, It's my mistake. I'm going to fix in the next ticket. Thanks! > Cache doesn't support array as key > -- > > Key: IGNITE-12116 > URL: https://issues.apache.org/jira/browse/IGNITE-12116 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The ignite cache doesn't support array as key. You couldn't do the base > operations with it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (IGNITE-12118) Preload MVCC entries using batch insert into page memory.
[
https://issues.apache.org/jira/browse/IGNITE-12118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-12118:
-
Assignee: (was: Pavel Pereslegin)
> Preload MVCC entries using batch insert into page memory.
> -
>
> Key: IGNITE-12118
> URL: https://issues.apache.org/jira/browse/IGNITE-12118
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Priority: Major
>
> IGNITE-11584 introduces the ability to insert a collection of data rows into
> the row store (see {{RowStore#addRows}} and
> {{AbstractFreeList#insertDataRows}})).
> This method is on average faster than sequential insertion using {{addRow}}
> and should be used for MVCC preloading ({{mvccPreloadEntries}}) similarly to
> the tx/atomic preloading ({{preloadEntries}}).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12116) Cache doesn't support array as key
[
https://issues.apache.org/jira/browse/IGNITE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918556#comment-16918556
]
Pavel Pereslegin commented on IGNITE-12116:
---
[~mstepachev], [~EdShangGG]
When we put null-key to ignite cache we get NPE with the problem description
"java.lang.NullPointerException: Ouch! Argument cannot be null: key"
But when we put "new String[] {"c", *null*, "a"}" we get just NPE, and I think
we should at least explain the problem in the same way if this is the expected
behavior.
Should I file a ticket for this, what do you think?
> Cache doesn't support array as key
> --
>
> Key: IGNITE-12116
> URL: https://issues.apache.org/jira/browse/IGNITE-12116
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The ignite cache doesn't support array as key. You couldn't do the base
> operations with it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IGNITE-1666) Fallback for full scan query does not work
[
https://issues.apache.org/jira/browse/IGNITE-1666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diana Iakovleva reassigned IGNITE-1666:
---
Assignee: Diana Iakovleva (was: Semen Boikov)
> Fallback for full scan query does not work
> --
>
> Key: IGNITE-1666
> URL: https://issues.apache.org/jira/browse/IGNITE-1666
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Andrey Gura
>Assignee: Diana Iakovleva
>Priority: Major
>
> Fallback for full scan query doesn't work.
> Steps to reproduce (all in one thread):
> 1. Start N nodes, create cache and populate some entries to cache.
> 2. Stop some node.
> 3. Get iterator on the cache and fetch all entries one by one.
> 4. Repeat from step 2.
> On some iteration scan query fails with exception:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Query execution failed: GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1614)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:181)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.init(CacheWeakQueryIteratorsHolder.java:228)
> at
> org.apache.ignite.internal.processors.cache.CacheWeakQueryIteratorsHolder$WeakQueryFutureIterator.onHasNext(CacheWeakQueryIteratorsHolder.java:180)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.doTest(CacheIteratorWhileRemovalSelfTest.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.CacheIteratorWhileRemovalSelfTest.testFullScanIterator(CacheIteratorWhileRemovalSelfTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1658)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:112)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1596)
> Caused by: class org.apache.ignite.IgniteCheckedException: Query execution
> failed: GridCacheQueryBean [qry=GridCacheQueryAdapter [type=SCAN,
> clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.checkError(GridCacheQueryFutureAdapter.java:267)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.internalIterator(GridCacheQueryFutureAdapter.java:276)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:171)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> query on node [query=GridCacheQueryBean [qry=GridCacheQueryAdapter
> [type=SCAN, clsName=null, clause=null, filter=null, part=null, incMeta=false,
> metrics=GridCacheQueryMetricsAdapter [minTime=0, maxTime=0, sumTime=0,
> avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024, timeout=0,
> keepAll=false, incBackups=false, dedup=false, prj=null, keepPortable=false,
> subjId=3026635f-2a79-4a59-83cb-9db427f45003, taskHash=0], rdc=null,
> trans=null], nodeId=203d0a36-8587-4a32-aa51-3332d126d002]
> at
> org.apache.ignit
[jira] [Commented] (IGNITE-11094) Add SSL support for ignite zookeeper SPI
[
https://issues.apache.org/jira/browse/IGNITE-11094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918481#comment-16918481
]
Ignite TC Bot commented on IGNITE-11094:
{panel:title=Branch: [pull/6799/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4524543&buildTypeId=IgniteTests24Java8_RunAll]
> Add SSL support for ignite zookeeper SPI
>
>
> Key: IGNITE-11094
> URL: https://issues.apache.org/jira/browse/IGNITE-11094
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ZK 3.5.4-beta is already supporting SSL [1]. We should add SSL support to ZK
> server connections if Zookeeper SPI used.
> 1.
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (IGNITE-12118) Preload MVCC entries using batch insert into page memory.
[
https://issues.apache.org/jira/browse/IGNITE-12118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-12118:
-
Assignee: Pavel Pereslegin
> Preload MVCC entries using batch insert into page memory.
> -
>
> Key: IGNITE-12118
> URL: https://issues.apache.org/jira/browse/IGNITE-12118
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>
> IGNITE-11584 introduces the ability to insert a collection of data rows into
> the row store (see {{RowStore#addRows}} and
> {{AbstractFreeList#insertDataRows}})).
> This method is on average faster than sequential insertion using {{addRow}}
> and should be used for MVCC preloading ({{mvccPreloadEntries}}) similarly to
> the tx/atomic preloading ({{preloadEntries}}).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12122) Remove setIncludeEventTypes from GridAbstractTest.
Stanilovsky Evgeny created IGNITE-12122: --- Summary: Remove setIncludeEventTypes from GridAbstractTest. Key: IGNITE-12122 URL: https://issues.apache.org/jira/browse/IGNITE-12122 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.7.5 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Attachments: flamegraph-18988.svg Simple cache.put() hot threads measurements shows that GridCacheEventManager::addEvent consumes about 7% of overall time, i suggest to remove this events from GridAbstractTest::getConfiguration and stores only for really requiring tests. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12119) Peer Class Loading has no retries
[
https://issues.apache.org/jira/browse/IGNITE-12119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918462#comment-16918462
]
Ignite TC Bot commented on IGNITE-12119:
{panel:title=Branch: [pull/6821/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4545846&buildTypeId=IgniteTests24Java8_RunAll]
> Peer Class Loading has no retries
> -
>
> Key: IGNITE-12119
> URL: https://issues.apache.org/jira/browse/IGNITE-12119
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> That's it. Peer Class Loading has short timeout and no retries, and if it
> fails, loading of class will not be reattempted.
> I believe this is in part because GridDeploymentClassLoader is a class
> loader. If it throws ClassNotFoundException when asked to load class, JVM
> will take notice and not reattempt to load this class, even if error was
> transient.
> Proposed amendments:
> * Increase timeouts, introduce immediate retries.
> * See if we can report transient class loading issue to JVM.
> * If all failed, we need to mark class loader as invalid when timeout
> occurs, phase out its usage and create a new class loader which will
> reattempt to load this class later.
> Please note that extended waiting in class loader is not recommended because
> it can cause grid to stall.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (IGNITE-12121) Double checkpoint triggering due to incorrect place of update current checkpoint
Anton Kalashnikov created IGNITE-12121: -- Summary: Double checkpoint triggering due to incorrect place of update current checkpoint Key: IGNITE-12121 URL: https://issues.apache.org/jira/browse/IGNITE-12121 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Double checkpoint triggering due to incorrect place of update current checkpoint. This can lead to two ckeckpoints one by one if checkpoint trigger was 'too many dirty pages'. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12120) Change log level in GridCacheWritebehindStore
Sunny Chan created IGNITE-12120:
---
Summary: Change log level in GridCacheWritebehindStore
Key: IGNITE-12120
URL: https://issues.apache.org/jira/browse/IGNITE-12120
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7.5
Reporter: Sunny Chan
In the
[GridCacheWriteBehindStore|https://github.com/apache/ignite/blob/7e73098d4d6e3d5f78326cb11dac7e083a2312dd/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L893],
when the updateStore failed to write to underlying store, it logs this as
error:
{{LT.error(log, e, "Unable to update underlying store: " + store);}}
After this line logged the error, it would return false so that it would retry
the store (by returning false).
While later on in the updatStore function, when the writeCache overflows, it
would log this:
{{log.warning("Failed to update store (value will be lost as current buffer
size is greater " + …}}
then it will remove the failed entry.
I think the severity of the log messages is not right, as the fail update would
still be retried.
So I propose to change the log severity level so that the first one would be a
warn, and second one would be error
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (IGNITE-12116) Cache doesn't support array as key
[ https://issues.apache.org/jira/browse/IGNITE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-12116: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Cache doesn't support array as key > -- > > Key: IGNITE-12116 > URL: https://issues.apache.org/jira/browse/IGNITE-12116 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite cache doesn't support array as key. You couldn't do the base > operations with it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (IGNITE-12116) Cache doesn't support array as key
[ https://issues.apache.org/jira/browse/IGNITE-12116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-12116: Fix Version/s: 2.8 > Cache doesn't support array as key > -- > > Key: IGNITE-12116 > URL: https://issues.apache.org/jira/browse/IGNITE-12116 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite cache doesn't support array as key. You couldn't do the base > operations with it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-12027) NPE on try to read the MinimumNumberOfPartitionCopies metric.
[
https://issues.apache.org/jira/browse/IGNITE-12027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918404#comment-16918404
]
Amelchev Nikita commented on IGNITE-12027:
--
[~NIzhikov], I have fixed some new bugs after merge new master. Could you take
a look at my changes, please?
> NPE on try to read the MinimumNumberOfPartitionCopies metric.
> -
>
> Key: IGNITE-12027
> URL: https://issues.apache.org/jira/browse/IGNITE-12027
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NPE on try to read the MinimumNumberOfPartitionCopies metric before node
> starts.
> Details:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.numberOfPartitionCopies(CacheGroupMetricsImpl.java:218)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.getMinimumNumberOfPartitionCopies(CacheGroupMetricsImpl.java:232)
> at
> org.apache.ignite.internal.util.lang.GridFunc.lambda$nonThrowableSupplier$2(GridFunc.java:3302)
> at
> org.apache.ignite.internal.processors.metric.impl.IntGauge.value(IntGauge.java:45)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.lambda$null$5(OpenCensusMetricExporterSpi.java:152)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.lambda$export$6(OpenCensusMetricExporterSpi.java:141)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.export(OpenCensusMetricExporterSpi.java:137)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.lambda$spiStart$0(PushMetricsExporterAdapter.java:57)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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}
> Reason: {{GridDhtPartitionFullMap partFullMap =
> ctx.topology().partitionMap(false);}} is null.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-12027) NPE on try to read the MinimumNumberOfPartitionCopies metric.
[
https://issues.apache.org/jira/browse/IGNITE-12027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918400#comment-16918400
]
Ignite TC Bot commented on IGNITE-12027:
{panel:title=Branch: [pull/6738/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4545182&buildTypeId=IgniteTests24Java8_RunAll]
> NPE on try to read the MinimumNumberOfPartitionCopies metric.
> -
>
> Key: IGNITE-12027
> URL: https://issues.apache.org/jira/browse/IGNITE-12027
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NPE on try to read the MinimumNumberOfPartitionCopies metric before node
> starts.
> Details:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.numberOfPartitionCopies(CacheGroupMetricsImpl.java:218)
> at
> org.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl.getMinimumNumberOfPartitionCopies(CacheGroupMetricsImpl.java:232)
> at
> org.apache.ignite.internal.util.lang.GridFunc.lambda$nonThrowableSupplier$2(GridFunc.java:3302)
> at
> org.apache.ignite.internal.processors.metric.impl.IntGauge.value(IntGauge.java:45)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.lambda$null$5(OpenCensusMetricExporterSpi.java:152)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.lambda$export$6(OpenCensusMetricExporterSpi.java:141)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> org.apache.ignite.spi.metric.opencensus.OpenCensusMetricExporterSpi.export(OpenCensusMetricExporterSpi.java:137)
> at
> org.apache.ignite.internal.processors.metric.PushMetricsExporterAdapter.lambda$spiStart$0(PushMetricsExporterAdapter.java:57)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> 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}
> Reason: {{GridDhtPartitionFullMap partFullMap =
> ctx.topology().partitionMap(false);}} is null.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing
[ https://issues.apache.org/jira/browse/IGNITE-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918397#comment-16918397 ] Pavel Pereslegin commented on IGNITE-11584: --- [~alex_pl], [~Mmuzaf], [~avinogradov] thanks a lot for the review. I created a ticket for MVCC support (linked). Merged with the latest changes from the master branch and re-checked TC. Ready for merge. > Implement batch insertion of new cache entries in FreeList to improve > rebalancing > - > > Key: IGNITE-11584 > URL: https://issues.apache.org/jira/browse/IGNITE-11584 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-32 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Main goals: > * Implement batch insert operation into FreeList - insert several data rows > at once > * Use batch insertion in the preloader > > Implementation notes: > # Preloader cannot lock multiple cache entries at once, because this may > lead to a deadlock with concurrent batch updates. Therefore, it pre-creates > batch of data rows in the page memory, and then sequentially initializes the > cache entries one by one. > # Batch writing of data rows into data pages uses the free list as usual > because other approaches increase memory fragmentation (for example, using > only "reuse" or "most free" buckets). > # Eviction tracker assumes that only data pages with "heads" of fragmented > data row are tracked, so all other fragments of large data row should be > written on separate data pages (without other data rows which may cause page > tracking). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (IGNITE-11584) Implement batch insertion of new cache entries in FreeList to improve rebalancing
[
https://issues.apache.org/jira/browse/IGNITE-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16918381#comment-16918381
]
Ignite TC Bot commented on IGNITE-11584:
{panel:title=Branch: [pull/6364/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4545553&buildTypeId=IgniteTests24Java8_RunAll]
> Implement batch insertion of new cache entries in FreeList to improve
> rebalancing
> -
>
> Key: IGNITE-11584
> URL: https://issues.apache.org/jira/browse/IGNITE-11584
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-32
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Main goals:
> * Implement batch insert operation into FreeList - insert several data rows
> at once
> * Use batch insertion in the preloader
>
> Implementation notes:
> # Preloader cannot lock multiple cache entries at once, because this may
> lead to a deadlock with concurrent batch updates. Therefore, it pre-creates
> batch of data rows in the page memory, and then sequentially initializes the
> cache entries one by one.
> # Batch writing of data rows into data pages uses the free list as usual
> because other approaches increase memory fragmentation (for example, using
> only "reuse" or "most free" buckets).
> # Eviction tracker assumes that only data pages with "heads" of fragmented
> data row are tracked, so all other fragments of large data row should be
> written on separate data pages (without other data rows which may cause page
> tracking).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
