[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:
-
Ignite Flags: (was: Docs Required)
> 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
> 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] [Assigned] (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 reassigned IGNITE-10985:
Assignee: Vladimir Ozerov (was: Alexander Lapin)
> 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
> 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-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=16754705#comment-16754705
]
Vladimir Ozerov commented on IGNITE-5:
--
Implemented. Test run:
https://ci.ignite.apache.org/viewQueued.html?itemId=2940188
> 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] [Updated] (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:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5:
-
Labels: performance (was: )
> 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] [Updated] (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:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5:
-
Ignite Flags: (was: Docs Required)
> 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] [Assigned] (IGNITE-10489) Web console: validation messages are shown twice in configuration
[ https://issues.apache.org/jira/browse/IGNITE-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10489: - Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good to me. Merged to master. > Web console: validation messages are shown twice in configuration > - > > Key: IGNITE-10489 > URL: https://issues.apache.org/jira/browse/IGNITE-10489 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-11-30-14-59-19-188.png > > Time Spent: 50m > Remaining Estimate: 0h > > What happens: > When validation is triggered for any form in configuration, _two_ validation > messages are shown simultaneously: one under the input and another in tooltip. > !image-2018-11-30-14-59-19-188.png! > What should happen: > Tooltip-style validation messages should not be visible on configuration > screens. > The issues is caused by IGNITE-9811. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11115) Binary: rework thread-local binary context to avoid set() operation
Vladimir Ozerov created IGNITE-5:
Summary: 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
Fix For: 2.8
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-11112) control.sh incorrect work with the key '--force'.
[
https://issues.apache.org/jira/browse/IGNITE-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754700#comment-16754700
]
Igor Akkuratov commented on IGNITE-2:
-
"-force" option was used instead of "–force". That has been interpreted as
consistent id. After that empty response was returned.
> control.sh incorrect work with the key '--force'.
> -
>
> Key: IGNITE-2
> URL: https://issues.apache.org/jira/browse/IGNITE-2
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Andrey Kalinin
>Priority: Major
>
> control.sh --wal delete with the key --force produces the error
> control.sh --host --wal delete --force
> {code:java}
> Control utility [ver. 2.5.1-p142#20181016-sha1:f983e74f]
> 2018 Copyright(C) Apache Software Foundation
> User: ***
>
> Warning: the command will delete unused WAL segments.
> Press 'y' to continue . . . Error: Task map operation produced no mapped
> jobs: GridTaskSessionImpl
> [taskName=org.apache.ignite.internal.visor.misc.VisorWalTask,
> dep=GridDeployment [...]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:528)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:318)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:99)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:174)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (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=16754689#comment-16754689 ] Ilya Borisov edited comment on IGNITE-11101 at 1/29/19 7:40 AM: [~pkonstantinov] issue #1 (no error message) is caused by the way form-field-size handles validation. I have an idea how to prevent this class of issues, but it will require major refactoring of inputs, so I'm inclined to ignore the for now. On a side note, [Firefox does not restrict text input into number fields by design|https://stackoverflow.com/a/49923874/333777], but it will validate the value. was (Author: klaster_1): [~pkonstantinov] issue #1 (no error message) is caused by the way form-field-size handles validation. I have an idea how to prevent this class of issues, but it will require major refactoring of inputs, so I'm inclined to ignore the for now. > 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: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > 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-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=16754689#comment-16754689 ] Ilya Borisov edited comment on IGNITE-11101 at 1/29/19 7:37 AM: [~pkonstantinov] issue #1 (no error message) is caused by the way form-field-size handles validation. I have an idea how to prevent this class of issues, but it will require major refactoring of inputs, so I'm inclined to ignore the for now. was (Author: klaster_1): [~pkonstantinov] issue #1 (no error message) is caused by the way form-field-size checks validation. I have an idea how to prevent this class of issues, but it will require major refactoring of inputs, so I'm inclined to ignore the for now. > 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: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > 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=16754689#comment-16754689 ] Ilya Borisov commented on IGNITE-11101: --- [~pkonstantinov] issue #1 (no error message) is caused by the way form-field-size checks validation. I have an idea how to prevent this class of issues, but it will require major refactoring of inputs, so I'm inclined to ignore the for now. > 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: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > 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-10421) MVCC: Assertion in checkpointer thread.
[
https://issues.apache.org/jira/browse/IGNITE-10421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754684#comment-16754684
]
Ignite TC Bot commented on IGNITE-10421:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2934044]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDisconnectAfterNetworkTimeout -
0,0% fails in last 418 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2934129buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Assertion in checkpointer thread.
> ---
>
> Key: IGNITE-10421
> URL: https://issues.apache.org/jira/browse/IGNITE-10421
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, persistence
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: WAL, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Reproducers:
> * {{WalModeChangeAdvancedSelfTest#testJoin}} with enabled MVCC.
> * {{IgniteDynamicCacheStartFailWithPersistenceTest}}
> {noformat}
> [2018-11-27
> 14:56:47,548][ERROR][db-checkpoint-thread-#358%srv_3%][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=class
> o.a.i.IgniteCheckedException: Compound exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3957)
> 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)
> Suppressed: java.lang.AssertionError: off=3000,
> allocated=1000, pageId=00020002,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=4000,
> allocated=1000, pageId=00020003,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.writeInternal(FilePageStoreManager.java:520)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4022)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3930)
> ... 3 more
> Suppressed: java.lang.AssertionError: off=2000,
> allocated=1000, pageId=00020001,
> file=/home/gridgain/Documents/work/incubator-ignite/work/db/node02-20092321-f30d-498f-8609-21ff87e4d104/TxLog/index.bin
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.write(FilePageStore.java:550)
> at
>
[jira] [Commented] (IGNITE-10654) Report in case of creating index with already existing fields collection.
[
https://issues.apache.org/jira/browse/IGNITE-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754674#comment-16754674
]
Stanilovsky Evgeny commented on IGNITE-10654:
-
[~ascherbakov] what do u think ?
> Report in case of creating index with already existing fields collection.
> -
>
> Key: IGNITE-10654
> URL: https://issues.apache.org/jira/browse/IGNITE-10654
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
>
> Report in log if new index creating with already existing fields collection.
> for example, need to log warn here:
> {code:java}
> cache.query(new SqlFieldsQuery("create index \"idx1\" on Val(keyStr,
> keyLong)"));
> cache.query(new SqlFieldsQuery("create index \"idx3\" on Val(keyStr,
> keyLong)"));
> {code}
--
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=16754665#comment-16754665 ] Ilya Borisov commented on IGNITE-11101: --- [~pkonstantinov] issue #2 was probably fixed in IGNITE-10489. > 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: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > 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] [Assigned] (IGNITE-10489) Web console: validation messages are shown twice in configuration
[ https://issues.apache.org/jira/browse/IGNITE-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-10489: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: validation messages are shown twice in configuration > - > > Key: IGNITE-10489 > URL: https://issues.apache.org/jira/browse/IGNITE-10489 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-11-30-14-59-19-188.png > > Time Spent: 50m > Remaining Estimate: 0h > > What happens: > When validation is triggered for any form in configuration, _two_ validation > messages are shown simultaneously: one under the input and another in tooltip. > !image-2018-11-30-14-59-19-188.png! > What should happen: > Tooltip-style validation messages should not be visible on configuration > screens. > The issues is caused by IGNITE-9811. -- 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=16754655#comment-16754655
]
Ignite TC Bot commented on IGNITE-10749:
{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=2936720buildTypeId=IgniteTests24Java8_RunAll]
> 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-10786) MVCC: Flaky test IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
[
https://issues.apache.org/jira/browse/IGNITE-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754635#comment-16754635
]
Ignite TC Bot commented on IGNITE-10786:
{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=2930450buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Flaky test
> IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
>
>
> Key: IGNITE-10786
> URL: https://issues.apache.org/jira/browse/IGNITE-10786
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance}}
> is flaky when MVCC is enabled. We should investigate it.
> {noformat}
> [2018-12-21 02:26:51,592][ERROR][main][root] Test failed.
> java.lang.AssertionError:
> node=cache.IgniteClusterActivateDeactivateTestWithPersistence0, key=12
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance(IgniteClusterActivateDeactivateTestWithPersistence.java:425)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2115)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11034: - Assignee: Andrey Novikov (was: Pavel Konstantinov) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h 43m > Remaining Estimate: 17m > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10876) "Affinity changes (coordinator) applied" can be executed in parallel
[
https://issues.apache.org/jira/browse/IGNITE-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754649#comment-16754649
]
Ignite TC Bot commented on IGNITE-10876:
{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=2930450buildTypeId=IgniteTests24Java8_RunAll]
> "Affinity changes (coordinator) applied" can be executed in parallel
>
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There is for loop over all cache groups which execution N*P operations in
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 80% of time in a loop
> for (CacheGroupContext grp : cctx.cache().cacheGroups()){
> GridDhtPartitionTopology top = grp != null ? grp.topology() :
> cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());
> top.beforeExchange(this, true, true);
> }
> I believe we can execute it in parallel
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754624#comment-16754624 ] Pavel Konstantinov commented on IGNITE-11034: - A smoke test is done. > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h 43m > Remaining Estimate: 17m > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754621#comment-16754621
]
Ignite TC Bot commented on IGNITE-10347:
{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=2931066buildTypeId=IgniteTests24Java8_RunAll]
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (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=16754586#comment-16754586 ] Ilya Borisov edited comment on IGNITE-4 at 1/29/19 4:25 AM: I've fixed the bug that was preventing red color on hover. [~alexdel] please review. was (Author: klaster_1): I've fixed the bug that was preventing red color on hover. > 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: Alexander Kalinin >Priority: Minor > Time Spent: 10m > 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] [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 ] Ilya Borisov reassigned IGNITE-4: - Assignee: Alexander Kalinin (was: Ilya Borisov) I've fixed the bug that was preventing red color on hover. > 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: Alexander Kalinin >Priority: Minor > Time Spent: 10m > 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-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 ] Ilya Borisov updated IGNITE-4: -- Description: Add hover state (red icon color) to icons in the left menu, like the "Download agent" link. (was: Add hover state (red icon color) to icons in the left menu, like the "Contact" link.) > 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: Ilya Borisov >Priority: Minor > > 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] [Assigned] (IGNITE-11017) Visor CMD: Doesn't show correct cacheSize metrics
[ https://issues.apache.org/jira/browse/IGNITE-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11017: -- Assignee: Vasiliy Sisko (was: Pavel Konstantinov) > Visor CMD: Doesn't show correct cacheSize metrics > - > > Key: IGNITE-11017 > URL: https://issues.apache.org/jira/browse/IGNITE-11017 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vasiliy Sisko >Priority: Major > > VisorCache doesn't show cacheSize() on the caches screen nevertheless > VisorCache object contains cacheSize. > org.apache.ignite.cache.CacheMetrics#getCacheSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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 ] Ilya Borisov updated IGNITE-4: -- Component/s: wizards > 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: Ilya Borisov >Priority: Minor > > Add hover state (red icon color) to icons in the left menu, like the > "Contact" link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11114) Web console: add onhover state to the icons in the left menu
Ilya Borisov created IGNITE-4: - Summary: 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 Reporter: Ilya Borisov Assignee: Ilya Borisov Add hover state (red icon color) to icons in the left menu, like the "Contact" link. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11017) Visor CMD: Doesn't show correct cacheSize metrics
[ https://issues.apache.org/jira/browse/IGNITE-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11017: -- Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Visor CMD: Doesn't show correct cacheSize metrics > - > > Key: IGNITE-11017 > URL: https://issues.apache.org/jira/browse/IGNITE-11017 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Pavel Konstantinov >Priority: Major > > VisorCache doesn't show cacheSize() on the caches screen nevertheless > VisorCache object contains cacheSize. > org.apache.ignite.cache.CacheMetrics#getCacheSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11098) Web console: font cleanup
[ https://issues.apache.org/jira/browse/IGNITE-11098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754577#comment-16754577 ] Ilya Borisov commented on IGNITE-11098: --- What was done: 1. Removed Roboto font declarations from all components. 2. Removed Roboto Bold font preload. It was used as a fix in IGNITE-9789, but I removed bold from "Demo Mode" in demo mode permanent notification, so preload is no longer needed. 3. Global font is set by --sans-serif-font CSS variable on root element (body or :root). > Web console: font cleanup > - > > Key: IGNITE-11098 > URL: https://issues.apache.org/jira/browse/IGNITE-11098 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Time Spent: 1h 35m > Remaining Estimate: 0h > > Web console font should be set in a single place. > Places to check: > 1. SCSS variables passed into Bootstrap. > 2. Component styles that explicitly use Roboto font (they should not). > 3. Font preload meta tags. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11098) Web console: font cleanup
[ https://issues.apache.org/jira/browse/IGNITE-11098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11098: - Assignee: Alexander Kalinin (was: Ilya Borisov) [~alexdel] please review. > Web console: font cleanup > - > > Key: IGNITE-11098 > URL: https://issues.apache.org/jira/browse/IGNITE-11098 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Time Spent: 1h 35m > Remaining Estimate: 0h > > Web console font should be set in a single place. > Places to check: > 1. SCSS variables passed into Bootstrap. > 2. Component styles that explicitly use Roboto font (they should not). > 3. Font preload meta tags. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754570#comment-16754570 ] Ilya Borisov commented on IGNITE-11034: --- [~pkonstantinov] please do a smoke test, there were some unexpected regressions (landing carousel images went missing, but I fixed that). > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h 43m > Remaining Estimate: 17m > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11034: - Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h 43m > Remaining Estimate: 17m > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11017) Visor CMD: Doesn't show correct cacheSize metrics
[ https://issues.apache.org/jira/browse/IGNITE-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754561#comment-16754561 ] Vasiliy Sisko commented on IGNITE-11017: *Cache size* metric is shown in the next places: # *Total entries* column in aggregated table. # *Total entries* in header table when -a flag of cache command is used. # *Primary* part of *Size* column in by node table of cache metrics. > Visor CMD: Doesn't show correct cacheSize metrics > - > > Key: IGNITE-11017 > URL: https://issues.apache.org/jira/browse/IGNITE-11017 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Vasiliy Sisko >Priority: Major > > VisorCache doesn't show cacheSize() on the caches screen nevertheless > VisorCache object contains cacheSize. > org.apache.ignite.cache.CacheMetrics#getCacheSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754534#comment-16754534
]
Ilya Borisov commented on IGNITE-9879:
--
[~pkonstantinov] please test.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 9.5h
> Remaining Estimate: 6.5h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov reassigned IGNITE-9879:
Assignee: Pavel Konstantinov (was: Andrey Novikov)
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 9.5h
> Remaining Estimate: 6.5h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10786) MVCC: Flaky test IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
[
https://issues.apache.org/jira/browse/IGNITE-10786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754512#comment-16754512
]
Ignite TC Bot commented on IGNITE-10786:
{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=2930450buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Flaky test
> IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance
>
>
> Key: IGNITE-10786
> URL: https://issues.apache.org/jira/browse/IGNITE-10786
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test
> {{IgniteClusterActivateDeactivateTestWithPersistence#testDeactivateDuringEvictionAndRebalance}}
> is flaky when MVCC is enabled. We should investigate it.
> {noformat}
> [2018-12-21 02:26:51,592][ERROR][main][root] Test failed.
> java.lang.AssertionError:
> node=cache.IgniteClusterActivateDeactivateTestWithPersistence0, key=12
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:621)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance(IgniteClusterActivateDeactivateTestWithPersistence.java:425)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2115)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5983) REST: Memory policy metrics should be available via REST.
[ https://issues.apache.org/jira/browse/IGNITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754496#comment-16754496 ] Roman Shtykh commented on IGNITE-5983: -- [~amashenkov] Thank you for the explanation! Now I see what you mean, and fixed the issue. Please have a look. > REST: Memory policy metrics should be available via REST. > - > > Key: IGNITE-5983 > URL: https://issues.apache.org/jira/browse/IGNITE-5983 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > For now it is possible to get some of cache metrics via REST, but not memory > metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754396#comment-16754396
]
Ignite TC Bot commented on IGNITE-8841:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2934593]]
* IgniteBinaryCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodesWithPersistence
- 0,0% fails in last 428 master runs.
{color:#d04437}Java Client{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2934520]]
* IgniteClientTestSuite:
JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway - 0,0% fails
in last 432 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2934617buildTypeId=IgniteTests24Java8_RunAll]
> MVCC TX: Read transactions remap when coordinator fails.
>
>
> Key: IGNITE-8841
> URL: https://issues.apache.org/jira/browse/IGNITE-8841
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: failover
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment read transactions that don't acquire topology lock will be
> forcibly rolled back on topology change as read tx can be in fly while
> topology being change.
> This is done to prevent having active transaction with stale snapshots on
> new topology in cases of TX coordinator or Near node were lost.
>
> It would be nice to remap it somehow until they locked a topology or at least
> throw some meaningful exception to user.
> For example, it is possible to obtain a new "write" mvcc version from the
> new coordinator and use this version for all further writes while using "old"
> version for reads. In this case we need to change visibility rules a little:
> "old" version should see "own" updates made by "new" "write" version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[
https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754348#comment-16754348
]
Konstantin Bolyandra edited comment on IGNITE-10920 at 1/28/19 8:59 PM:
[~ascherbakov], thanks for review.
# Done.
# Studiyng JOL benchark revelead what proposed optimization was almost useless
because main heap consumer was Object overhead due to many instances of
ArrayLists. I tried to remove many instances by storing node primary-backup
order in char[] array, because partition count couldn't exceed 2 bytes. Also it
seems good because of strong locality. Such optimization has diminishing
returns in case of many backups, so I disabled it for replicated caches. Please
check PR for details. TC run is in progress. Below JOL affinity cache heap size
calculation results for configuration with 32768 partitions and 32 nodes added
to topology, it shows almost 4x heap size reduction:
{noformat}
Heap usage [optimized=false, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
1115802 42 47500664 [Ljava.lang.Object;
1 16 16 java.lang.Object
1115802 24 26779248 java.util.ArrayList
93 24 2232 java.util.Collections$UnmodifiableRandomAccessList
1 48 48 java.util.concurrent.ConcurrentSkipListMap
3 32 96 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
24 24 576 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
2231913 74288360 (total)
Heap usage [optimized=true, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
99963 144 14457240 [C
31 24327 754160 [Ljava.util.HashMap$Node;
62 85 5328 [Lorg.apache.ignite.cluster.ClusterNode;
99664 16 1594624 java.lang.Integer
1 16 16 java.lang.Object
62 48 2976 java.util.HashMap
99901 32 3196832 java.util.HashMap$Node
1 48 48 java.util.concurrent.ConcurrentSkipListMap
4 32 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
32 24 768 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
62 32 1984
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$1
31 32 992
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$2
31 20020576 (total)
Optimization: optimized=20020576, deoptimized=74288360 rate: 3.71
{noformat}
was (Author: kbolyandra):
[~ascherbakov], thanks for review.
# Done.
# Studiyng JOL benchark revelead what proposed optimization was almost useless
because main heap consumer was Object overhead due to many instances of
ArrayLists. I tried to remove many instances by storing node primary-backup
order in char[] array, because partition count couldn't exceed 2 bytes. Also it
seems good because of strong locality. Such optimization has diminishing
returns in case of many backups, so I disabled for replicated caches. Please
check PR for details. TC run is in progress. Below JOL affinity cache heap size
calculation results for configuration with 32768 partitions and 32 nodes added
to topology, it shows almost 4x heap size reduction:
{noformat}
Heap usage [optimized=false, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
1115802 42 47500664 [Ljava.lang.Object;
1 16 16 java.lang.Object
1115802 24 26779248 java.util.ArrayList
93 24 2232 java.util.Collections$UnmodifiableRandomAccessList
1 48 48 java.util.concurrent.ConcurrentSkipListMap
3 32 96 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
24 24 576 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
2231913 74288360 (total)
Heap usage [optimized=true, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
99963 144 14457240 [C
31 24327 754160 [Ljava.util.HashMap$Node;
62 85 5328 [Lorg.apache.ignite.cluster.ClusterNode;
99664 16 1594624 java.lang.Integer
1 16 16 java.lang.Object
62 48 2976 java.util.HashMap
99901 32 3196832 java.util.HashMap$Node
1 48 48 java.util.concurrent.ConcurrentSkipListMap
4 32 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
32 24 768 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
62 32 1984
[jira] [Commented] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[
https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754348#comment-16754348
]
Konstantin Bolyandra commented on IGNITE-10920:
---
[~ascherbakov], thanks for review.
# Done.
# Studiyng JOL benchark revelead what proposed optimization was almost useless
because main heap consumer was Object overhead due to many instances of
ArrayLists. I tried to remove many instances by storing node primary-backup
order in char[] array, because partition count couldn't exceed 2 bytes. Also it
seems good because of strong locality. Such optimization has diminishing
returns in case of many backups, so I disabled for replicated caches. Please
check PR for details. TC run is in progress. Below JOL affinity cache heap size
calculation results for configuration with 32768 partitions and 32 nodes added
to topology, it shows almost 4x heap size reduction:
{noformat}
Heap usage [optimized=false, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
1115802 42 47500664 [Ljava.lang.Object;
1 16 16 java.lang.Object
1115802 24 26779248 java.util.ArrayList
93 24 2232 java.util.Collections$UnmodifiableRandomAccessList
1 48 48 java.util.concurrent.ConcurrentSkipListMap
3 32 96 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
24 24 576 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
2231913 74288360 (total)
Heap usage [optimized=true, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
99963 144 14457240 [C
31 24327 754160 [Ljava.util.HashMap$Node;
62 85 5328 [Lorg.apache.ignite.cluster.ClusterNode;
99664 16 1594624 java.lang.Integer
1 16 16 java.lang.Object
62 48 2976 java.util.HashMap
99901 32 3196832 java.util.HashMap$Node
1 48 48 java.util.concurrent.ConcurrentSkipListMap
4 32 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
32 24 768 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
62 32 1984
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$1
31 32 992
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$2
31 20020576 (total)
Optimization: optimized=20020576, deoptimized=74288360 rate: 3.71
{noformat}
> Optimize HistoryAffinityAssignment heap usage.
> --
>
> Key: IGNITE-10920
> URL: https://issues.apache.org/jira/browse/IGNITE-10920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With large topology and large amount of caches/partitions many server
> discovery events may quickly produce large affinity history, eating gigabytes
> of heap.
> Solution: implement some kind of a compression for affinity cache map.
> On example, affinity history could be stored as delta to some previous
> version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[
https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-10920:
---
Comment: was deleted
(was: {noformat}
Heap usage [optimized=false, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
1115802 42 47500664 [Ljava.lang.Object;
1 16 16 java.lang.Object
1115802 24 26779248 java.util.ArrayList
93 24 2232 java.util.Collections$UnmodifiableRandomAccessList
1 48 48 java.util.concurrent.ConcurrentSkipListMap
3 32 96 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
24 24 576 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
2231913 74288360 (total)
]
Heap usage [optimized=true, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
99963 144 14457240 [C
31 24327 754160 [Ljava.util.HashMap$Node;
62 85 5328 [Lorg.apache.ignite.cluster.ClusterNode;
99664 16 1594624 java.lang.Integer
1 16 16 java.lang.Object
62 48 2976 java.util.HashMap
99901 32 3196832 java.util.HashMap$Node
1 48 48 java.util.concurrent.ConcurrentSkipListMap
4 32 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
32 24 768 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
62 32 1984
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$1
31 32 992
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$2
31 20020576 (total)
]
Optimization: optimized=20020576, deoptimized=74288360 rate: 3.71{noformat}
)
> Optimize HistoryAffinityAssignment heap usage.
> --
>
> Key: IGNITE-10920
> URL: https://issues.apache.org/jira/browse/IGNITE-10920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With large topology and large amount of caches/partitions many server
> discovery events may quickly produce large affinity history, eating gigabytes
> of heap.
> Solution: implement some kind of a compression for affinity cache map.
> On example, affinity history could be stored as delta to some previous
> version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10920) Optimize HistoryAffinityAssignment heap usage.
[
https://issues.apache.org/jira/browse/IGNITE-10920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754341#comment-16754341
]
Alexei Scherbakov commented on IGNITE-10920:
{noformat}
Heap usage [optimized=false, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
1115802 42 47500664 [Ljava.lang.Object;
1 16 16 java.lang.Object
1115802 24 26779248 java.util.ArrayList
93 24 2232 java.util.Collections$UnmodifiableRandomAccessList
1 48 48 java.util.concurrent.ConcurrentSkipListMap
3 32 96 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
24 24 576 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
2231913 74288360 (total)
]
Heap usage [optimized=true, parts=32768, nodeCnt=32, backups=2, footprint:
COUNT AVG SUM DESCRIPTION
99963 144 14457240 [C
31 24327 754160 [Ljava.util.HashMap$Node;
62 85 5328 [Lorg.apache.ignite.cluster.ClusterNode;
99664 16 1594624 java.lang.Integer
1 16 16 java.lang.Object
62 48 2976 java.util.HashMap
99901 32 3196832 java.util.HashMap$Node
1 48 48 java.util.concurrent.ConcurrentSkipListMap
4 32 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex
32 24 768 java.util.concurrent.ConcurrentSkipListMap$Index
63 24 1512 java.util.concurrent.ConcurrentSkipListMap$Node
62 24 1488
org.apache.ignite.internal.processors.affinity.AffinityTopologyVersion
62 40 2480
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment
62 32 1984
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$1
31 32 992
org.apache.ignite.internal.processors.affinity.HistoryAffinityAssignment$2
31 20020576 (total)
]
Optimization: optimized=20020576, deoptimized=74288360 rate: 3.71{noformat}
> Optimize HistoryAffinityAssignment heap usage.
> --
>
> Key: IGNITE-10920
> URL: https://issues.apache.org/jira/browse/IGNITE-10920
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With large topology and large amount of caches/partitions many server
> discovery events may quickly produce large affinity history, eating gigabytes
> of heap.
> Solution: implement some kind of a compression for affinity cache map.
> On example, affinity history could be stored as delta to some previous
> version.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11113) JVM 9-11 startup parameters have to be mentioned in every section of getting started
[ https://issues.apache.org/jira/browse/IGNITE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3: - Reporter: Denis Magda (was: Artem Budnikov) > JVM 9-11 startup parameters have to be mentioned in every section of getting > started > > > Key: IGNITE-3 > URL: https://issues.apache.org/jira/browse/IGNITE-3 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Priority: Blocker > > Ignite.sh fails on Mac OS with JDK 11. The following startup parameters [1] > have to be mentioned in callout blocks of every section in the getting > started guide [2] where it's explained how to start a node with ignite.sh or > launch an application. > The user has to know how to: > * Fix ignite.sh/ignite.bat to make them workable > * What to do in an IDEA like IntellijIdean and Eclipse to make examples and > apps workable > [1] > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > [2] https://apacheignite.readme.io/docs/getting-started -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11113) JVM 9-11 startup parameters have to be mentioned in every section of getting started
[ https://issues.apache.org/jira/browse/IGNITE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-3: Assignee: Artem Budnikov > JVM 9-11 startup parameters have to be mentioned in every section of getting > started > > > Key: IGNITE-3 > URL: https://issues.apache.org/jira/browse/IGNITE-3 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Blocker > > Ignite.sh fails on Mac OS with JDK 11. The following startup parameters [1] > have to be mentioned in callout blocks of every section in the getting > started guide [2] where it's explained how to start a node with ignite.sh or > launch an application. > The user has to know how to: > * Fix ignite.sh/ignite.bat to make them workable > * What to do in an IDEA like IntellijIdean and Eclipse to make examples and > apps workable > [1] > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > [2] https://apacheignite.readme.io/docs/getting-started -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11113) JVM 9-11 startup parameters have to be mentioned in every section of getting started
Denis Magda created IGNITE-3: Summary: JVM 9-11 startup parameters have to be mentioned in every section of getting started Key: IGNITE-3 URL: https://issues.apache.org/jira/browse/IGNITE-3 Project: Ignite Issue Type: Task Components: documentation Reporter: Artem Budnikov Ignite.sh fails on Mac OS with JDK 11. The following startup parameters [1] have to be mentioned in callout blocks of every section in the getting started guide [2] where it's explained how to start a node with ignite.sh or launch an application. The user has to know how to: * Fix ignite.sh/ignite.bat to make them workable * What to do in an IDEA like IntellijIdean and Eclipse to make examples and apps workable [1] https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 [2] https://apacheignite.readme.io/docs/getting-started -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754201#comment-16754201
]
Eduard Shangareev commented on IGNITE-10758:
[~oignatenko], I have only one suggestion - revert adding extra space in
ServiceDeploymentDiscoveryListenerNotificationOrderTest.
Everything else looks good.
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10995) GridDhtPartitionSupplier::handleDemandMessage suppress errors
[
https://issues.apache.org/jira/browse/IGNITE-10995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-10995:
--
Fix Version/s: 2.8
> GridDhtPartitionSupplier::handleDemandMessage suppress errors
> -
>
> Key: IGNITE-10995
> URL: https://issues.apache.org/jira/browse/IGNITE-10995
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
> Attachments: Screenshot 2019-01-20 at 23.19.08.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scenario:
> # Cluster with data
> # Triggered historical rebalance
> In this case if OOM occurs on supplier there is no failHandler triggered and
> cluster is alive with inconsistent data (target node have MOVING partitions,
> supplier do nothing)
> Target rebalance node log:
> {code:java}
> [15:00:31,418][WARNING][sys-#86][GridDhtPartitionDemander] Rebalancing from
> node cancelled [grp=cache_group_4, topVer=AffinityTopologyVersion [topVer=17,
> minorTopVer=0], supplier=4cbc66d3-9d2c-4396-8366-2839a8d0cdb6, topic=5]].
> Supplier has failed with error: java.lang.OutOfMemoryError: Java heap
> space{code}
> Supplier stack trace:
> !Screenshot 2019-01-20 at 23.19.08.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10995) GridDhtPartitionSupplier::handleDemandMessage suppress errors
[
https://issues.apache.org/jira/browse/IGNITE-10995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754197#comment-16754197
]
Alexey Goncharuk commented on IGNITE-10995:
---
[~mstepachev], a few comments:
1) Please change the error message passed in to the failure handler to be the
same as the one being logged ("Failed to continue supplying [" +
supplyRoutineInfo(topicId, nodeId, demandMsg) + "]")
2) No need to override {{getIgniteInstanceName}} method, instead use this
method in the test to determine the node you want to work with
3) Is there any reason why you used {{FSYNC}} WAL mode for this test? This mode
is quite slow and unless specifically needed, we stick with default one
> GridDhtPartitionSupplier::handleDemandMessage suppress errors
> -
>
> Key: IGNITE-10995
> URL: https://issues.apache.org/jira/browse/IGNITE-10995
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Stepachev Maksim
>Priority: Major
> Attachments: Screenshot 2019-01-20 at 23.19.08.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scenario:
> # Cluster with data
> # Triggered historical rebalance
> In this case if OOM occurs on supplier there is no failHandler triggered and
> cluster is alive with inconsistent data (target node have MOVING partitions,
> supplier do nothing)
> Target rebalance node log:
> {code:java}
> [15:00:31,418][WARNING][sys-#86][GridDhtPartitionDemander] Rebalancing from
> node cancelled [grp=cache_group_4, topVer=AffinityTopologyVersion [topVer=17,
> minorTopVer=0], supplier=4cbc66d3-9d2c-4396-8366-2839a8d0cdb6, topic=5]].
> Supplier has failed with error: java.lang.OutOfMemoryError: Java heap
> space{code}
> Supplier stack trace:
> !Screenshot 2019-01-20 at 23.19.08.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754147#comment-16754147
]
Roman Kondakov commented on IGNITE-10755:
-
[~gvvinblade], I made fixes proposed by yours. Patch is ready for review. Tests
look good.
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754145#comment-16754145
]
Ignite TC Bot commented on IGNITE-10755:
{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=2929946buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (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:all-tabpanel
]
Moldachev Sergey updated IGNITE-8550:
-
Comment: was deleted
(was: [Team City Run::All Build |
https://ci.ignite.apache.org/viewLog.html?buildId=2932544])
> 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-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=16754093#comment-16754093
]
Roman Kondakov commented on IGNITE-10764:
-
[~Pavlukhin], could you please clarify the reason of the test failures? Is it
caused by the big size of the transaction and small timeout? And on some weak
agents transactions were were not able to acquire all needed locks within
timeout? And there is no any other reason why are locks are not acquired in
time, right?
> 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] [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=16754087#comment-16754087
]
Moldachev Sergey commented on IGNITE-8550:
--
[Team City Run::All Build |
https://ci.ignite.apache.org/viewLog.html?buildId=2932544]
> 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-11029) Public API for edge-chasing deadlock detection configuration
[
https://issues.apache.org/jira/browse/IGNITE-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754084#comment-16754084
]
Andrew Mashenkov commented on IGNITE-11029:
---
[~Pavlukhin], "2.8.0" is the correct one.
> Public API for edge-chasing deadlock detection configuration
>
>
> Key: IGNITE-11029
> URL: https://issues.apache.org/jira/browse/IGNITE-11029
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As deadlock detection introduce overhead during transaction processing some
> configuration means should be introduced. Following aspects should be
> addressed:
> 1. Turning detection on/off.
> 2. Adjusting a timeout before starting actual detection.
> It is proposed to introduce single property in {{TransactionConfiguration}}
> to address both concerns.
> Also it is desired that configuration is consistent across all cluster nodes
> (detection turned off on even one node can lead to undetected deadlocks).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9927) Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
[
https://issues.apache.org/jira/browse/IGNITE-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754082#comment-16754082
]
Andrew Mashenkov commented on IGNITE-9927:
--
I've found newValue is the value that passed to backups. So, PR is ok, we just
have to add missed newValue() call.
Thanks.
> Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
> ---
>
> Key: IGNITE-9927
> URL: https://issues.apache.org/jira/browse/IGNITE-9927
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This test was reworked significantly as a part of IGNITE-7953. Unfortunately
> it led to a number of failures appearing from time to time. The goal of this
> ticket is to get rid of these failures.
> Changes from {{51a202a4c48220fa919f47147bd4889033cd35a8}} commit should be
> applied to the test before starting investigation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11112) control.sh incorrect work with the key '--force'.
Andrey Kalinin created IGNITE-2:
---
Summary: control.sh incorrect work with the key '--force'.
Key: IGNITE-2
URL: https://issues.apache.org/jira/browse/IGNITE-2
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrey Kalinin
control.sh --wal delete with the key --force produces the error
control.sh --host --wal delete --force
{code:java}
Control utility [ver. 2.5.1-p142#20181016-sha1:f983e74f]
2018 Copyright(C) Apache Software Foundation
User: ***
Warning: the command will delete unused WAL segments.
Press 'y' to continue . . . Error: Task map operation produced no mapped jobs:
GridTaskSessionImpl
[taskName=org.apache.ignite.internal.visor.misc.VisorWalTask,
dep=GridDeployment [...]
at
org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:528)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
at
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
at
org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:318)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:99)
at
org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:174)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
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)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10995) GridDhtPartitionSupplier::handleDemandMessage suppress errors
[
https://issues.apache.org/jira/browse/IGNITE-10995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754049#comment-16754049
]
Ignite TC Bot commented on IGNITE-10995:
{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=2910173buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtPartitionSupplier::handleDemandMessage suppress errors
> -
>
> Key: IGNITE-10995
> URL: https://issues.apache.org/jira/browse/IGNITE-10995
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Sherstobitov
>Assignee: Stepachev Maksim
>Priority: Major
> Attachments: Screenshot 2019-01-20 at 23.19.08.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scenario:
> # Cluster with data
> # Triggered historical rebalance
> In this case if OOM occurs on supplier there is no failHandler triggered and
> cluster is alive with inconsistent data (target node have MOVING partitions,
> supplier do nothing)
> Target rebalance node log:
> {code:java}
> [15:00:31,418][WARNING][sys-#86][GridDhtPartitionDemander] Rebalancing from
> node cancelled [grp=cache_group_4, topVer=AffinityTopologyVersion [topVer=17,
> minorTopVer=0], supplier=4cbc66d3-9d2c-4396-8366-2839a8d0cdb6, topic=5]].
> Supplier has failed with error: java.lang.OutOfMemoryError: Java heap
> space{code}
> Supplier stack trace:
> !Screenshot 2019-01-20 at 23.19.08.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
[
https://issues.apache.org/jira/browse/IGNITE-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16754042#comment-16754042
]
Ivan Pavlukhin commented on IGNITE-11029:
-
[~amashenkov] Thank you for your comment! I have made {{detectionStartDelay}}
non-volatile. Also, it is still unclear for me which version should we treat as
minimal for {{deadlockTimeout}} configuration property. Should it be 2.8.0 or
2.7.1? Or should it be something different?
> Public API for edge-chasing deadlock detection configuration
>
>
> Key: IGNITE-11029
> URL: https://issues.apache.org/jira/browse/IGNITE-11029
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As deadlock detection introduce overhead during transaction processing some
> configuration means should be introduced. Following aspects should be
> addressed:
> 1. Turning detection on/off.
> 2. Adjusting a timeout before starting actual detection.
> It is proposed to introduce single property in {{TransactionConfiguration}}
> to address both concerns.
> Also it is desired that configuration is consistent across all cluster nodes
> (detection turned off on even one node can lead to undetected deadlocks).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11050) Potential deadlock caused by DhtColocatedLockFuture#map being called inside topology read lock
[
https://issues.apache.org/jira/browse/IGNITE-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11050:
--
Labels: MakeTeamcityGreenAgain (was: )
> Potential deadlock caused by DhtColocatedLockFuture#map being called inside
> topology read lock
> --
>
> Key: IGNITE-11050
> URL: https://issues.apache.org/jira/browse/IGNITE-11050
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> I observed the following stacktrace on TC during tests analysis:
> {code}
> Thread
> [name="exchange-worker-#18471%near.GridCachePartitionedNodeRestartTest0%",
> id=23715, state=WAITING, blockCnt=860, waitCnt=775]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2bfb6b49,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock0(StripedCompositeReadWriteLock.java:173)
> at
> o.a.i.i.util.StripedCompositeReadWriteLock$WriteLock.lock(StripedCompositeReadWriteLock.java:142)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:925)
> at
> o.a.i.i.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:826)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:70)
> at
> o.a.i.i.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:89)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:1019)
> at
> o.a.i.i.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:544)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.txUnlock(IgniteTxManager.java:1764)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.unlockMultiple(IgniteTxManager.java:1775)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1347)
> at
> o.a.i.i.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1075)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3602)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:440)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:390)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3833)
> at
> o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.rollbackNearTxLocalAsync(GridNearTxLocal.java:3784)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4409)
> at
> o.a.i.i.processors.cache.GridCacheAdapter$53.applyx(GridCacheAdapter.java:4399)
> at o.a.i.i.util.lang.IgniteClosureX.apply(IgniteClosureX.java:38)
> at
> o.a.i.i.util.future.GridFutureChainListener.applyCallback(GridFutureChainListener.java:78)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:70)
> at
> o.a.i.i.util.future.GridFutureChainListener.apply(GridFutureChainListener.java:30)
> at
> o.a.i.i.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> o.a.i.i.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> o.a.i.i.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478)
> at
>
[jira] [Updated] (IGNITE-11111) DistributedMetaStorage doesn't work on Zookeeper SPI
[ https://issues.apache.org/jira/browse/IGNITE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-1: --- Summary: DistributedMetaStorage doesn't work on Zookeeper SPI (was: DistributedMetaStoragePersistentTest doesn't work on Zookeeper SPI) > DistributedMetaStorage doesn't work on Zookeeper SPI > > > Key: IGNITE-1 > URL: https://issues.apache.org/jira/browse/IGNITE-1 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > Accepting of joining node data is implemented in #collectGridNodeData which > is wrong, because this method is invoked on coordinator only in case of > Zookeeper SPI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11072) [ML] Prepare an example of model inference in SQL
[ https://issues.apache.org/jira/browse/IGNITE-11072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-11072: Ignite Flags: (was: Docs Required) > [ML] Prepare an example of model inference in SQL > - > > Key: IGNITE-11072 > URL: https://issues.apache.org/jira/browse/IGNITE-11072 > Project: Ignite > Issue Type: Improvement > Components: ml >Affects Versions: 2.8 >Reporter: Anton Dmitriev >Assignee: Anton Dmitriev >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Machine learning model lifecycle assumes training followed by inference. The > inference is relatively simple procedure that is essentially a predefined > function call. The predefined function, or model in other words, can be > chosen from internal storage and be called directly from SQL. It will > significantly simplify usage of existing models. > > The goal of this task is to prepare an example that demonstrates how to do it > using existing functionality (With model storage prepared in IGNITE-10287 and > Liner Regression prepared in IGNITE-7438). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8894) Provide information about coordinator in control.sh output
[ https://issues.apache.org/jira/browse/IGNITE-8894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753999#comment-16753999 ] Pavel Voronkin commented on IGNITE-8894: Looks good for me. > Provide information about coordinator in control.sh output > -- > > Key: IGNITE-8894 > URL: https://issues.apache.org/jira/browse/IGNITE-8894 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Information about coordinator can be added in an existing command (i.e. > --state, --baseline) > either a new command can be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11111) DistributedMetaStoragePersistentTest doesn't work on Zookeeper SPI
Ivan Bessonov created IGNITE-1: -- Summary: DistributedMetaStoragePersistentTest doesn't work on Zookeeper SPI Key: IGNITE-1 URL: https://issues.apache.org/jira/browse/IGNITE-1 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Accepting of joining node data is implemented in #collectGridNodeData which is wrong, because this method is invoked on coordinator only in case of Zookeeper SPI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
[
https://issues.apache.org/jira/browse/IGNITE-11029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753975#comment-16753975
]
Andrew Mashenkov commented on IGNITE-11029:
---
[~Pavlukhin],
I've just one note: Seems, there is no need to mark
DeadlockDetectionManager.detectionStartDelay as volatile until you are going to
change its state concurrently. DeadlockDetectionManager is fully initialized
(start() method called) before node join a grid.
PR looks good.
> Public API for edge-chasing deadlock detection configuration
>
>
> Key: IGNITE-11029
> URL: https://issues.apache.org/jira/browse/IGNITE-11029
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As deadlock detection introduce overhead during transaction processing some
> configuration means should be introduced. Following aspects should be
> addressed:
> 1. Turning detection on/off.
> 2. Adjusting a timeout before starting actual detection.
> It is proposed to introduce single property in {{TransactionConfiguration}}
> to address both concerns.
> Also it is desired that configuration is consistent across all cluster nodes
> (detection turned off on even one node can lead to undetected deadlocks).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller
[ https://issues.apache.org/jira/browse/IGNITE-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753973#comment-16753973 ] Eduard Shangareev commented on IGNITE-7718: --- [~vozerov], [~pvinokurov], hi guys. Any update here? > Collections.singleton() and Collections.singletonMap() are not properly > serialized by binary marshaller > --- > > Key: IGNITE-7718 > URL: https://issues.apache.org/jira/browse/IGNITE-7718 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Pavel Vinokurov >Assignee: Pavel Vinokurov >Priority: Major > > After desialization collections obtained by Collections.singleton() and > Collections.singletonMap() does not return collection of binary objects, but > rather collection of deserialized objects. -- 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 ] Ivan Bessonov updated IGNITE-11108: --- Summary: Zookeeper validates joining nodes differently (was: Zookeeper handles DataBags differently) > 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: Eduard Shangareev >Priority: Major > > 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-11108) Zookeeper validates joining nodes differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semen Boikov reassigned IGNITE-11108: - Assignee: Semen Boikov (was: Eduard Shangareev) > 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 > > 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-11110) UnsupportedOperationException: null when stopping grid
Jens Borgland created IGNITE-0:
--
Summary: UnsupportedOperationException: null when stopping grid
Key: IGNITE-0
URL: https://issues.apache.org/jira/browse/IGNITE-0
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Jens Borgland
After upgrading to 2.7 we've started getting these errors when stopping grids:
{noformat}
java.lang.UnsupportedOperationException: null
at
org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1551)
~[ignite-core-2.7.0.jar:2.7.0]
at
org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:264)
~[ignite-core-2.7.0.jar:2.7.0]
at
org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2356)
~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2228)
~[ignite-core-2.7.0.jar:2.7.0]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2612)
~[ignite-core-2.7.0.jar:2.7.0]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2575)
~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:379)
~[ignite-core-2.7.0.jar:2.7.0]
at org.apache.ignite.Ignition.stop(Ignition.java:225)
~[ignite-core-2.7.0.jar:2.7.0]
at
org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3568)
~[ignite-core-2.7.0.jar:2.7.0]
{noformat}
At first glance it looks likely that it was introduced with commit
[d04d764|https://github.com/apache/ignite/commit/d04d76440ce86873de7aebc8c03d39484cd1e3e5]
(the {{GridJobProcessor}} still calls {{clear()}} on maps).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11109) DistributedMetaStorageTest should be moved into different test suite
Ivan Bessonov created IGNITE-11109: -- Summary: DistributedMetaStorageTest should be moved into different test suite Key: IGNITE-11109 URL: https://issues.apache.org/jira/browse/IGNITE-11109 Project: Ignite Issue Type: Test Reporter: Ivan Bessonov Assignee: Ivan Bessonov DistributedMetaStorageTest should be moved into different test suite: https://ci.ignite.apache.org/viewLog.html?buildId=2930324=buildResultsDiv=IgniteTests24Java8_DiskPageCompressions#testNameId5631188409568136213 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11108) Zookeeper handles DataBags differently
[ https://issues.apache.org/jira/browse/IGNITE-11108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11108: --- Description: 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. was:Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery suite I found that GridComponent#validateNode(ClusterNode, JoiningNodeDiscoveryData) is never invoked so node validation might work incorrectly. > Zookeeper handles DataBags differently > -- > > Key: IGNITE-11108 > URL: https://issues.apache.org/jira/browse/IGNITE-11108 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Eduard Shangareev >Priority: Major > > 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-11108) Zookeeper handles DataBags differently
Ivan Bessonov created IGNITE-11108: -- Summary: Zookeeper handles DataBags differently Key: IGNITE-11108 URL: https://issues.apache.org/jira/browse/IGNITE-11108 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Eduard Shangareev Trying to run DistributedMetaStoragePersistentTest in Zookeeper Discovery suite I found that GridComponent#validateNode(ClusterNode, JoiningNodeDiscoveryData) is never invoked so node validation might work incorrectly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10918) Implement C++ thin client benchmarks
[
https://issues.apache.org/jira/browse/IGNITE-10918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-10918:
-
Description:
We need the following list of benchmarks:
{noformat}
IgniteThinGetBenchmark
IgniteThinGetTxBenchmark
IgniteThinPutAllBenchmark
IgniteThinPutAllTxBenchmark
IgniteThinPutGetBenchmark
IgniteThinPutTxBenchmark
{noformat}
You can find examples of benchmarks in attachment.
was:
We need the following list of benchmarks:
{noformat}
IgniteThinGetBenchmark
IgniteThinGetTxBenchmark
IgniteThinPutAllBenchmark
IgniteThinPutAllTxBenchmark
IgniteThinPutGetBenchmark
IgniteThinPutTxBenchmark
{noformat}
You can find examples of benchmarks in attachment.
> Implement C++ thin client benchmarks
> -
>
> Key: IGNITE-10918
> URL: https://issues.apache.org/jira/browse/IGNITE-10918
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Suntsov
>Assignee: Igor Sapego
>Priority: Major
> Attachments: put.cpp
>
>
> We need the following list of benchmarks:
> {noformat}
> IgniteThinGetBenchmark
> IgniteThinGetTxBenchmark
> IgniteThinPutAllBenchmark
> IgniteThinPutAllTxBenchmark
> IgniteThinPutGetBenchmark
> IgniteThinPutTxBenchmark
> {noformat}
> You can find examples of benchmarks in attachment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11107) MVCC: IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs sometimes
Roman Kondakov created IGNITE-11107:
---
Summary: MVCC:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs
sometimes
Key: IGNITE-11107
URL: https://issues.apache.org/jira/browse/IGNITE-11107
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Sometimes
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes hangs
on PME. Some partitions have not changed their state from {{RENTING}} to
{{OWNING}}.
{noformat}
[2019-01-27 07:20:23,420][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Finished waiting for topology map update
[igniteInstanceName=distributed.IgniteCachePartitionLossPolicySelfTest4, p=0,
duration=1415ms]
[2019-01-27 07:20:23,421][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Waiting for correct partition state part=2, should be OWNING [state=RENTING],
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default
[2019-01-27 07:20:25,023][WARN
][test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%][root]
Waiting for correct partition state part=13, should be OWNING [state=RENTING],
node=distributed.IgniteCachePartitionLossPolicySelfTest4, cache=default
Thread
[name="test-runner-#32729%distributed.IgniteCachePartitionLossPolicySelfTest%",
id=35714, state=RUNNABLE, blockCnt=93, waitCnt=1033]
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:454)
at o.a.i.i.util.IgniteUtils.dumpThreads(IgniteUtils.java:1370)
at
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:792)
at
o.a.i.testframework.junits.common.GridCommonAbstractTest.awaitPartitionMapExchange(GridCommonAbstractTest.java:569)
at
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:560)
at
o.a.i.i.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeAfterKillTwoNodes(IgniteCachePartitionLossPolicySelfTest.java:258)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10879) Create suite of Cassandra Cache Store tests, add to TC
[ https://issues.apache.org/jira/browse/IGNITE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753942#comment-16753942 ] Ilya Kasnacheev commented on IGNITE-10879: -- [~dpavlov] I have added this suite to Run All. > Create suite of Cassandra Cache Store tests, add to TC > -- > > Key: IGNITE-10879 > URL: https://issues.apache.org/jira/browse/IGNITE-10879 > Project: Ignite > Issue Type: Sub-task > Components: cassandra >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Time Spent: 20m > Remaining Estimate: 0h > > Currently, they're not running in TC at all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753939#comment-16753939
]
Konstantin Bolyandra commented on IGNITE-10978:
---
[~ilyak]
Done
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Dmitriy Pavlov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10879) Create suite of Cassandra Cache Store tests, add to TC
[
https://issues.apache.org/jira/browse/IGNITE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753938#comment-16753938
]
Ignite TC Bot commented on IGNITE-10879:
{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=2882455buildTypeId=IgniteTests24Java8_RunAll]
> Create suite of Cassandra Cache Store tests, add to TC
> --
>
> Key: IGNITE-10879
> URL: https://issues.apache.org/jira/browse/IGNITE-10879
> Project: Ignite
> Issue Type: Sub-task
> Components: cassandra
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, they're not running in TC at all
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11106) MVCC: Test CacheMvccVacuumTest.testStartStopVacuumPersistence fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-11106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov updated IGNITE-11106:
Labels: mvcc_stabilization_stage_1 (was: )
> MVCC: Test CacheMvccVacuumTest.testStartStopVacuumPersistence fails
> sporadically
>
>
> Key: IGNITE-11106
> URL: https://issues.apache.org/jira/browse/IGNITE-11106
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: mvcc_stabilization_stage_1
>
> Test CacheMvccVacuumTest.testStartStopVacuumPersistence
> [fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=77684316754382=TEST_STATUS_DESC_IgniteTests24Java8=__all_branches__=50]
> sporadically. Looks like sometimes vacuum starts on non-activated cluster.
> It should be investigated.
> Stack trace:
> {noformat}
> junit.framework.AssertionFailedError: Expected: but was: [GridWorker
> [name=vacuum-scheduler, igniteInstanceName=mvcc.CacheMvccVacuumTest0,
> finished=false, heartbeatTs=1547451366552, hashCode=1061063110,
> interrupted=false,
> runner=vacuum-scheduler-#40457%mvcc.CacheMvccVacuumTest0%], GridWorker
> [name=vacuum-cleaner, igniteInstanceName=mvcc.CacheMvccVacuumTest0,
> finished=false, heartbeatTs=1547451366552, hashCode=706935731,
> interrupted=false, runner=vacuum-cleaner-#40458%mvcc.CacheMvccVacuumTest0%],
> GridWorker [name=vacuum-cleaner,
> igniteInstanceName=mvcc.CacheMvccVacuumTest0, finished=false,
> heartbeatTs=1547451366552, hashCode=507659668, interrupted=false,
> runner=vacuum-cleaner-#40459%mvcc.CacheMvccVacuumTest0%]]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertNull(Assert.java:277)
> at junit.framework.Assert.assertNull(Assert.java:268)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.ensureNoVacuum(CacheMvccVacuumTest.java:196)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.testStartStopVacuumPersistence(CacheMvccVacuumTest.java:128)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin edited comment on IGNITE-10766 at 1/28/19 11:41 AM:
---
Tests are not reproduced locally. Enabled in the patch. Checked tests:
* {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}}
*
{{GridCachePartitionsStateValidationTest.testPartitionCountersConsistencyOnExchange}}
with MVCC
was (Author: pavlukhin):
Tests are not reproduced locally. Enabled in the patch. Checked tests:
* {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}}
*
{{GridCachePartitionsStateValidationTest.testPartitionCountersConsistencyOnExchange}}
> 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-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin commented on IGNITE-10766:
-
Tests are not reproduced locally. Enabled in patch.
> 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] [Comment Edited] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin edited comment on IGNITE-10766 at 1/28/19 11:41 AM:
---
Tests are not reproduced locally. Enabled in the patch. Checked tests:
* {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}}
*
{{GridCachePartitionsStateValidationTest.testPartitionCountersConsistencyOnExchange}}
was (Author: pavlukhin):
Tests are not reproduced locally. Enabled in the patch. Checked tests:
* {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}}
*
> 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-10455) MVCC: Tx timeout can cause update counters inconsistency.
[
https://issues.apache.org/jira/browse/IGNITE-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753930#comment-16753930
]
Ivan Pavlukhin commented on IGNITE-10455:
-
Test in the issue run many transactions with very small tx timeout. As a result
active snapshots leak occurs in {{MvccProcessorImpl}}: transaction is rolled
back when snapshot request is in fly, as a result transaction does not send an
acknowledge that it is completed to MVCC coordinator.
Checking that transaction is still active upon receiving snapshot and sending
an ack to coordinator if it is already aborted can fix the problem.
> MVCC: Tx timeout can cause update counters inconsistency.
> --
>
> Key: IGNITE-10455
> URL: https://issues.apache.org/jira/browse/IGNITE-10455
> 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
>
>
> When transaction is rolled back on backup on prepare step, it could lead to
> update counters inconsistency between primary and backup. We need to fix
> backup counters update.
> Reproducer: {{TxWithSmallTimeoutAndContentionOneKeyTest#test}} with enabled
> MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10455) MVCC: Tx timeout can cause update counters inconsistency.
[
https://issues.apache.org/jira/browse/IGNITE-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753930#comment-16753930
]
Ivan Pavlukhin edited comment on IGNITE-10455 at 1/28/19 11:47 AM:
---
Test in the issue run many transactions with very small tx timeout. As a result
active snapshots leak occurs in {{MvccProcessorImpl}}: transaction is rolled
back when snapshot request is in fly, as a result transaction does not send an
acknowledge that it is completed to MVCC coordinator.
Checking that transaction is still active upon receiving a snapshot and sending
an ack to the coordinator if it is already aborted can fix the problem.
was (Author: pavlukhin):
Test in the issue run many transactions with very small tx timeout. As a result
active snapshots leak occurs in {{MvccProcessorImpl}}: transaction is rolled
back when snapshot request is in fly, as a result transaction does not send an
acknowledge that it is completed to MVCC coordinator.
Checking that transaction is still active upon receiving snapshot and sending
an ack to coordinator if it is already aborted can fix the problem.
> MVCC: Tx timeout can cause update counters inconsistency.
> --
>
> Key: IGNITE-10455
> URL: https://issues.apache.org/jira/browse/IGNITE-10455
> 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
>
>
> When transaction is rolled back on backup on prepare step, it could lead to
> update counters inconsistency between primary and backup. We need to fix
> backup counters update.
> Reproducer: {{TxWithSmallTimeoutAndContentionOneKeyTest#test}} with enabled
> MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11106) MVCC: Test CacheMvccVacuumTest.testStartStopVacuumPersistence fails sporadically
Roman Kondakov created IGNITE-11106:
---
Summary: MVCC: Test
CacheMvccVacuumTest.testStartStopVacuumPersistence fails sporadically
Key: IGNITE-11106
URL: https://issues.apache.org/jira/browse/IGNITE-11106
Project: Ignite
Issue Type: Bug
Components: mvcc
Reporter: Roman Kondakov
Test CacheMvccVacuumTest.testStartStopVacuumPersistence
[fails|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=77684316754382=TEST_STATUS_DESC_IgniteTests24Java8=__all_branches__=50]
sporadically. Looks like sometimes vacuum starts on non-activated cluster. It
should be investigated.
Stack trace:
{noformat}
junit.framework.AssertionFailedError: Expected: but was: [GridWorker
[name=vacuum-scheduler, igniteInstanceName=mvcc.CacheMvccVacuumTest0,
finished=false, heartbeatTs=1547451366552, hashCode=1061063110,
interrupted=false, runner=vacuum-scheduler-#40457%mvcc.CacheMvccVacuumTest0%],
GridWorker [name=vacuum-cleaner, igniteInstanceName=mvcc.CacheMvccVacuumTest0,
finished=false, heartbeatTs=1547451366552, hashCode=706935731,
interrupted=false, runner=vacuum-cleaner-#40458%mvcc.CacheMvccVacuumTest0%],
GridWorker [name=vacuum-cleaner, igniteInstanceName=mvcc.CacheMvccVacuumTest0,
finished=false, heartbeatTs=1547451366552, hashCode=507659668,
interrupted=false, runner=vacuum-cleaner-#40459%mvcc.CacheMvccVacuumTest0%]]
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertNull(Assert.java:277)
at junit.framework.Assert.assertNull(Assert.java:268)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.ensureNoVacuum(CacheMvccVacuumTest.java:196)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccVacuumTest.testStartStopVacuumPersistence(CacheMvccVacuumTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10978) Remove unused tests marked with unclear todo
[
https://issues.apache.org/jira/browse/IGNITE-10978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753918#comment-16753918
]
Ilya Kasnacheev commented on IGNITE-10978:
--
[~kbolyandra] Test classes run test methods from its parent abstract class.
Yes, please remove GridCacheOnCopyFlagAbstractSelfTest also as [~agoncharuk]
doesn't see any need for it.
> Remove unused tests marked with unclear todo
>
>
> Key: IGNITE-10978
> URL: https://issues.apache.org/jira/browse/IGNITE-10978
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.7
>Reporter: Dmitriy Pavlov
>Assignee: Konstantin Bolyandra
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> IgniteCacheTestSuite3
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheDeploymentOffHeapValuesSelfTest.class,
> ignoredTests);
> IgniteCacheInterceptorSelfTestSuite
> // TODO GG-11141.
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagTxPartitionedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagReplicatedSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagLocalSelfTest.class,
> ignoredTests);
> //
> GridTestUtils.addTestIfNeeded(suite,GridCacheOnCopyFlagAtomicSelfTest.class,
> ignoredTests);
> {noformat}
> Test classes not used, so there is no reason to keep it
--
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=16753925#comment-16753925 ] Dmitriy Pavlov commented on IGNITE-11084: - LGTM, merged to master, [~aealeksandrov] thank you for contribution. > 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] [Comment Edited] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin edited comment on IGNITE-10766 at 1/28/19 11:40 AM:
---
Tests are not reproduced locally. Enabled in the patch. Checked tests:
* {{CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed}}
*
was (Author: pavlukhin):
Tests are not reproduced locally. Enabled in the patch. Checked tests:
> 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] [Comment Edited] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin edited comment on IGNITE-10766 at 1/28/19 11:40 AM:
---
Tests are not reproduced locally. Enabled in the patch. Checked tests:
was (Author: pavlukhin):
Tests are not reproduced locally. Enabled in the patch.
> 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] [Comment Edited] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753922#comment-16753922
]
Ivan Pavlukhin edited comment on IGNITE-10766 at 1/28/19 11:39 AM:
---
Tests are not reproduced locally. Enabled in the patch.
was (Author: pavlukhin):
Tests are not reproduced locally. Enabled in patch.
> 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-11084) Change copyrights to 2019
[ https://issues.apache.org/jira/browse/IGNITE-11084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753921#comment-16753921 ] Andrey Aleksandrov commented on IGNITE-11084: - [~dpavlov] I merged the changes that were mentioned by you. 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: 10m > 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] [Assigned] (IGNITE-10766) MVCC: CacheMvccTxRecoveryTest.testCountersNeighborcastServerFailed fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-10766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-10766:
---
Assignee: Ivan Pavlukhin
> 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
>
>
> {{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] [Updated] (IGNITE-11087) GridJobCheckpointCleanupSelfTest.testCheckpointCleanup is flaky
[
https://issues.apache.org/jira/browse/IGNITE-11087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Kulagin updated IGNITE-11087:
-
Description:
The method of remove a checkpoint is sometimes not called or is called once
more. Test has a very low fail rate, 1 per 366 runs on
[TeamCity|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7655052229521669617=testDetails_IgniteTests24Java8=%3Cdefault%3E]
and 1 per 412 on TC Bot. On local machine approximately 1 failure per 100
runs. Logs in the attachment.
Test is flaky for a long time. Before replacing IP Finder in IGNITE-10555, test
was slower, which made fail rate even less.
{code:java}
[2019-01-25 14:49:03,050][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at
org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){code}
[^#removeCheckpoint isn't called.txt]
^_^
{code:java}
[2019-01-25 14:50:03,282][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: expected:<-1> but was:<0>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at
org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){code}
[^#removeCheckpoint is called once more.txt]
was:
The method of remove a checkpoint is sometimes not called or is called once
more. Test has a very low fail rate, 0 per 360 runs on TC and 1 per 412 on TC
Bot. On local machine approximately 1 failure per 100 runs. Logs in the
attachment.
Test is flaky for a long time. Before replacing IP Finder in IGNITE-10555, test
was slower, which made fail rate even less.
{code:java}
[2019-01-25 14:49:03,050][ERROR][main][root] Test failed.
junit.framework.AssertionFailedError: expected:<1> but was:<0>
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.Assert.failNotEquals(Assert.java:329)
at junit.framework.Assert.assertEquals(Assert.java:78)
at junit.framework.Assert.assertEquals(Assert.java:234)
at junit.framework.Assert.assertEquals(Assert.java:241)
at
org.apache.ignite.internal.GridJobCheckpointCleanupSelfTest.testCheckpointCleanup(GridJobCheckpointCleanupSelfTest.java:88)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){code}
[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=16753915#comment-16753915 ] Ilya Kasnacheev commented on IGNITE-11004: -- LGTM if it is OK that initializeLocalAddresses no longer checks discoveryClientMode() that it used to. > 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] [Created] (IGNITE-11105) [TC Bot] Support Teamcity servers aliases
Dmitriy Pavlov created IGNITE-11105: --- Summary: [TC Bot] Support Teamcity servers aliases Key: IGNITE-11105 URL: https://issues.apache.org/jira/browse/IGNITE-11105 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Implement feature of aliasing TeamCity builds bat. Alias will act as a pointer to the real name of a server. It is necessary for a feature of linking builds with separate JIRA projects and/or GitHub forks without duplicating of all builds database. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11104) Remove Java 7 leftovers from IgniteSystemProperties
Ilya Kasnacheev created IGNITE-11104: Summary: Remove Java 7 leftovers from IgniteSystemProperties Key: IGNITE-11104 URL: https://issues.apache.org/jira/browse/IGNITE-11104 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.7 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev IGNITE_FORCE_START_JAVA7 can no longer do anything useful, for example. Should remove it right away since it's noop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10918) Implement C++ thin client benchmarks
[
https://issues.apache.org/jira/browse/IGNITE-10918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-10918:
Assignee: Igor Sapego
> Implement C++ thin client benchmarks
> -
>
> Key: IGNITE-10918
> URL: https://issues.apache.org/jira/browse/IGNITE-10918
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Suntsov
>Assignee: Igor Sapego
>Priority: Major
> Attachments: put.cpp
>
>
> We need the following list of benchmarks:
> {noformat}
> IgniteThinGetBenchmark
> IgniteThinGetTxBenchmark
> IgniteThinPutAllBenchmark
> IgniteThinPutAllTxBenchmark
> IgniteThinPutGetBenchmark
> IgniteThinPutTxBenchmark
> {noformat}
> You can find examples of benchmarks in attachment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (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:all-tabpanel
]
Moldachev Sergey reassigned IGNITE-8550:
Assignee: Moldachev Sergey
> 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
>
>
> 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-10876) "Affinity changes (coordinator) applied" can be executed in parallel
[
https://issues.apache.org/jira/browse/IGNITE-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Voronkin reassigned IGNITE-10876:
---
Assignee: Pavel Voronkin
> "Affinity changes (coordinator) applied" can be executed in parallel
>
>
> Key: IGNITE-10876
> URL: https://issues.apache.org/jira/browse/IGNITE-10876
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
>
> There is for loop over all cache groups which execution N*P operations in
> exchange worker where N is number of cache groups, P is number of partitions.
> We spend 80% of time in a loop
> for (CacheGroupContext grp : cctx.cache().cacheGroups()){
> GridDhtPartitionTopology top = grp != null ? grp.topology() :
> cctx.exchange().clientTopology(grp.groupId(), events().discoveryCache());
> top.beforeExchange(this, true, true);
> }
> I believe we can execute it in parallel
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10879) Create suite of Cassandra Cache Store tests, add to TC
[ https://issues.apache.org/jira/browse/IGNITE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753890#comment-16753890 ] Dmitriy Pavlov commented on IGNITE-10879: - LGTM, I'm pretty sure MVCC Cache 9 failure is not related, but it is better to double-check it anyway. > Create suite of Cassandra Cache Store tests, add to TC > -- > > Key: IGNITE-10879 > URL: https://issues.apache.org/jira/browse/IGNITE-10879 > Project: Ignite > Issue Type: Sub-task > Components: cassandra >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Time Spent: 20m > Remaining Estimate: 0h > > Currently, they're not running in TC at all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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 updated IGNITE-11101: Description: You should use Firefox Configuration - Cluster - Advanced - Data storage configuration Enter a literal value into System region / Initial size Save !screenshot-1.png! was: You should use Firefox Configuration - Cluster - Advanced - Data storage configuration Enter a literal value into System region / Initial size Save > 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: Ilya Borisov >Priority: Major > Attachments: screenshot-1.png > > > You should use Firefox > Configuration - Cluster - Advanced - Data storage configuration > Enter a literal value into System region / Initial size > Save > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11034: -- Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h 40m > Remaining Estimate: 20m > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
