[jira] [Created] (IGNITE-8613) Web console: investigate E2E tests on Node.js 10
Ilya Borisov created IGNITE-8613: Summary: Web console: investigate E2E tests on Node.js 10 Key: IGNITE-8613 URL: https://issues.apache.org/jira/browse/IGNITE-8613 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Andrey Novikov Web console E2E tests fail spontaneously when run under Node.js 10. We should investigate what causes it: Testcafe incompatibility or something in the web console code. If new, compatible version of Testcafe becomes available, let's update to it as a part of this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8467) minSize filter for transactions utility control.sh doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov reassigned IGNITE-8467:
Assignee: Alexand Polyakov (was: Alexei Scherbakov)
> minSize filter for transactions utility control.sh doesn't work
> ---
>
> Key: IGNITE-8467
> URL: https://issues.apache.org/jira/browse/IGNITE-8467
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexand Polyakov
>Priority: Minor
> Fix For: 2.6
>
>
> I have following output when define control.sh utility with minSize filter
> Looks like it doesn't work.
> {code:java}
> Control utility --tx minDuration 15 minSize 10 order SIZE
> Control utility
> 2018 Copyright(C) Apache Software Foundation
> User:
>
> Matching transactions:
> [16:52:30][:688] TcpDiscoveryNode [id=02f47e9a-efca-4d8c-a49f-3de4ca82d3ee,
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 172.25.1.40],
> sockAddrs=[/172.17.0.1:0, /0:0:0:0:0:0:0:1%lo:0,
> lab40.gridgain.local/172.25.1.40:0, /127.0.0.1:0], discPort=0, order=5,
> intOrder=5, lastExchangeTime=1525960350163, loc=false,
> ver=2.5.1#20180427-sha1:48601cbd, isClient=true]
> Tx: [xid=0f1d25a4361--0831-2c15--0005, label=tx_5,
> state=ACTIVE, duration=16, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
> Tx: [xid=05ad25a4361--0831-2c15--0005, label=tx_6,
> state=ACTIVE, duration=15, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
> Tx: [xid=7b2b25a4361--0831-2c15--0005, label=tx_1,
> state=ACTIVE, duration=20, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
> Tx: [xid=73ab25a4361--0831-2c15--0005, label=tx_2,
> state=ACTIVE, duration=19, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
> Tx: [xid=47ca25a4361--0831-2c15--0005, label=tx_0,
> state=ACTIVE, duration=22, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
> Tx: [xid=b0ac25a4361--0831-2c15--0005, label=tx_4,
> state=ACTIVE, duration=17, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
> Tx: [xid=3a1c25a4361--0831-2c15--0005, label=tx_3,
> state=ACTIVE, duration=18, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[0cd15184]]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-6816) Webconsole: Upgrade to Webpack 4
[ https://issues.apache.org/jira/browse/IGNITE-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-6816: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Webconsole: Upgrade to Webpack 4 > > > Key: IGNITE-6816 > URL: https://issues.apache.org/jira/browse/IGNITE-6816 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Trivial > Fix For: 2.5 > > > As the webconsole frontend app size grows, it takes more and more time to > incrementally rebuild after each source code change in development > environment. Let's investigate this plugin > https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack > build pipeline if it offers measureable performance improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-6816) Webconsole: Upgrade to Webpack 4
[ https://issues.apache.org/jira/browse/IGNITE-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-6816. -- > Webconsole: Upgrade to Webpack 4 > > > Key: IGNITE-6816 > URL: https://issues.apache.org/jira/browse/IGNITE-6816 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Trivial > Fix For: 2.5 > > > As the webconsole frontend app size grows, it takes more and more time to > incrementally rebuild after each source code change in development > environment. Let's investigate this plugin > https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack > build pipeline if it offers measureable performance improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6816) Webconsole: Upgrade to Webpack 4
[ https://issues.apache.org/jira/browse/IGNITE-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490219#comment-16490219 ] Pavel Konstantinov commented on IGNITE-6816: Tested. > Webconsole: Upgrade to Webpack 4 > > > Key: IGNITE-6816 > URL: https://issues.apache.org/jira/browse/IGNITE-6816 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Trivial > Fix For: 2.5 > > > As the webconsole frontend app size grows, it takes more and more time to > incrementally rebuild after each source code change in development > environment. Let's investigate this plugin > https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack > build pipeline if it offers measureable performance improvements. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7894) Web console: extract new design collapsible panels into component
[ https://issues.apache.org/jira/browse/IGNITE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-7894. -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: extract new design collapsible panels into component > - > > Key: IGNITE-7894 > URL: https://issues.apache.org/jira/browse/IGNITE-7894 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.5 > > Attachments: image-2018-03-07-10-39-32-857.png, > image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png > > > Collapsible panels in new design still don't have a reusable component that > encapsulates it's behavior and styles. > Where such panels are/will be used: > 1. Redesigned cluster configuration forms. > !image-2018-03-07-10-42-44-368.png! > 2. Current user profile. > !image-2018-03-07-10-42-01-013.png! > 3. Upcoming queries screen redesign. > !image-2018-03-07-10-39-32-857.png! > New component should: > 1. Have bindings for opened state and opened/closed events. > 2. Have a way to insert buttons to the right of header. > Make sure that there are no leftover unused styles/code left. > What to test when the issue's done: > 1. Panels on user profile page. > 2. Panels on configuration screens should still have lazy panel content > loading. > 3. Legacy validation in clutser configuration / advanced / domain model form. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7894) Web console: extract new design collapsible panels into component
[ https://issues.apache.org/jira/browse/IGNITE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490136#comment-16490136 ] Pavel Konstantinov commented on IGNITE-7894: A smoke test is done. > Web console: extract new design collapsible panels into component > - > > Key: IGNITE-7894 > URL: https://issues.apache.org/jira/browse/IGNITE-7894 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.5 > > Attachments: image-2018-03-07-10-39-32-857.png, > image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png > > > Collapsible panels in new design still don't have a reusable component that > encapsulates it's behavior and styles. > Where such panels are/will be used: > 1. Redesigned cluster configuration forms. > !image-2018-03-07-10-42-44-368.png! > 2. Current user profile. > !image-2018-03-07-10-42-01-013.png! > 3. Upcoming queries screen redesign. > !image-2018-03-07-10-39-32-857.png! > New component should: > 1. Have bindings for opened state and opened/closed events. > 2. Have a way to insert buttons to the right of header. > Make sure that there are no leftover unused styles/code left. > What to test when the issue's done: > 1. Panels on user profile page. > 2. Panels on configuration screens should still have lazy panel content > loading. > 3. Legacy validation in clutser configuration / advanced / domain model form. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489796#comment-16489796
]
Andrew Medvedev commented on IGNITE-8612:
-
PR https://github.com/apache/ignite/pull/4066
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Medvedev updated IGNITE-8612:
Description:
We have got NPE in
org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
several times during 4 minutes period from tx.close() and tx.commit() here
[https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
{{Caused by: java.lang.NullPointerException}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
This could have been IgniteCacheOffheapManager == null, cctx.offheap()
returning null, but I could not reproduce it. To debug this further, a PR with
assert added will be submitted
was:
We have got NPE in
org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
several times during 4 minutes from tx.close() and tx.commit() here
[https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
{{Caused by: java.lang.NullPointerException}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
This could have been IgniteCacheOffheapManager == null, cctx.offheap()
returning null, but I could not reproduce it. To debug this further, a PR with
assert added will be submitted
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes period from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489795#comment-16489795
]
ASF GitHub Bot commented on IGNITE-8612:
GitHub user andrewmed opened a pull request:
https://github.com/apache/ignite/pull/4066
IGNITE-8612 Debugging NPE in GridCacheTtlManager: add assert
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/andrewmed/ignite ignite-8612
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4066.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4066
commit 7554b6fc667954b37cc52feb3ccc23b663defdd2
Author: AMedvedev
Date: 2018-05-24T20:50:54Z
IGNITE-8612 Debugging NPE: add assert
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close() on client
[
https://issues.apache.org/jira/browse/IGNITE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Medvedev updated IGNITE-8612:
Summary: NPE in GridCacheTtlManager#expire on commit() or close() on client
(was: NPE in GridCacheTtlManager#expire on commit() or close())
> NPE in GridCacheTtlManager#expire on commit() or close() on client
> --
>
> Key: IGNITE-8612
> URL: https://issues.apache.org/jira/browse/IGNITE-8612
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrew Medvedev
>Priority: Major
>
> We have got NPE in
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
> several times during 4 minutes from tx.close() and tx.commit() here
> [https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
>
> {{Caused by: java.lang.NullPointerException}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
> {{at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
> {{at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
> This could have been IgniteCacheOffheapManager == null, cctx.offheap()
> returning null, but I could not reproduce it. To debug this further, a PR
> with assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8612) NPE in GridCacheTtlManager#expire on commit() or close()
Andrew Medvedev created IGNITE-8612:
---
Summary: NPE in GridCacheTtlManager#expire on commit() or close()
Key: IGNITE-8612
URL: https://issues.apache.org/jira/browse/IGNITE-8612
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrew Medvedev
We have got NPE in
org.apache.ignite.internal.processors.cache.GridCacheTtlManager#expire(int)
several times during 4 minutes from tx.close() and tx.commit() here
[https://github.com/apache/ignite/blob/40845c67750c300b5568d157ab0ffeaf320802a8/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheTtlManager.java#L203]
{{Caused by: java.lang.NullPointerException}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)}}
{{at
org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:844)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.leave(TransactionProxyImpl.java:136)}}
{{at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:326)}}
This could have been IgniteCacheOffheapManager == null, cctx.offheap()
returning null, but I could not reproduce it. To debug this further, a PR with
assert added will be submitted
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8611) Binary marshaller documentation should cover how data classes can or can't be changed
Stanislav Lukyanov created IGNITE-8611: -- Summary: Binary marshaller documentation should cover how data classes can or can't be changed Key: IGNITE-8611 URL: https://issues.apache.org/jira/browse/IGNITE-8611 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Stanislav Lukyanov Binary marshaller docs (https://apacheignite.readme.io/docs/binary-marshaller) give an idea that a class structure may be changed (fields can be added or removed) and the marshaller will handle such change. However, not all changes are supported. One corner case is when an enum value is stored in the cache: if the order of the enum constants is changed, or if a new constant is added at the start or at the middle of the constants list, it will lead to an error. This is because the enums are stored as ordinals (integers), and the ordinals of an enum depend on the order of values in the code. The task is to update the documentation with the description of data class changes that are incompatible from binary marshallers point of view. At least the enum case should be covered. If more cases are discovered, they should be documented as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications
[
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489681#comment-16489681
]
Prachi Garg commented on IGNITE-8039:
-
[~isapego],
According to the text,
"._You can find more details on both formats below._"
Then, below I see explanation for two approaches - "Full schema approach", and
"Compact footer approach". Do you mean to say "Full schema approach" is
"Legacy"?
> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow
> a client development basing on the spec only, w/o looking at other client
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol
> spec (v.2.4)
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?)
> - what is Object array (type code 23) ? What is the difference between it and
> Objects Wrapped In Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
>
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field
> name".
> - "Repeat for as many times as the total number of schemas you have" ->
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the
> number of fields in the Data Object ?
> Objects Wrapped In Array
>
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not
> primitives)." -> does it mean that in general a complex object (103) must
> always be sent via the Binary Protocol in a wrapper (27)?
> - "Byte array size" -> "Payload size" or "Size of the whole array with
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8459) Searching checkpoint history for WAL rebalance is broken
[
https://issues.apache.org/jira/browse/IGNITE-8459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489676#comment-16489676
]
ASF GitHub Bot commented on IGNITE-8459:
GitHub user Jokser opened a pull request:
https://github.com/apache/ignite/pull/4065
IGNITE-8459 Do first checkpoint after all partitions have been initialized
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8459
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4065.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4065
commit df3fb2a24d4d43771094e56fea6680f23e3790e6
Author: Pavel Kovalenko
Date: 2018-05-18T09:37:13Z
IGNITE-8459 WIP
commit 54e88d22bfd4c0b61593b4a8f0d5c319288593b7
Author: Pavel Kovalenko
Date: 2018-05-18T16:22:01Z
IGNITE-8459 WIP
commit e8aeeea9d6c30df2ee03bfada3a8a399cfef7b6b
Author: Pavel Kovalenko
Date: 2018-05-21T12:42:33Z
IGNITE-8459 WIP
commit 7d58eb9e3c3fa2358c7937ce3f73715d850a33f1
Author: Pavel Kovalenko
Date: 2018-05-24T19:46:24Z
IGNITE-8459 Rework.
commit bd8ef85034bbf7c03d6c8b40b36fa4398a3b23ca
Author: Pavel Kovalenko
Date: 2018-05-24T19:50:11Z
IGNITE-8459 Remove trash.
> Searching checkpoint history for WAL rebalance is broken
>
>
> Key: IGNITE-8459
> URL: https://issues.apache.org/jira/browse/IGNITE-8459
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.6
>
>
> Currently the mechanism to search available checkpoint records in WAL to have
> history for WAL rebalance is broken. It means that WAL (Historical) rebalance
> will never find history for rebalance and full rebalance will be always used.
> This mechanism was broken in
> https://github.com/apache/ignite/commit/ec04cd174ed5476fba83e8682214390736321b37
> by unclear reasons.
> If we swap the following two code blocks (database().beforeExchange() and
> exchCtx if block):
> {noformat}
> /* It is necessary to run database callback before all topology
> callbacks.
>In case of persistent store is enabled we first restore partitions
> presented on disk.
>We need to guarantee that there are no partition state changes
> logged to WAL before this callback
>to make sure that we correctly restored last actual states. */
> cctx.database().beforeExchange(this);
> if (!exchCtx.mergeExchanges()) {
> for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
> if (grp.isLocal() || cacheGroupStopping(grp.groupId()))
> continue;
> // It is possible affinity is not initialized yet if node
> joins to cluster.
> if (grp.affinity().lastVersion().topologyVersion() > 0)
> grp.topology().beforeExchange(this, !centralizedAff &&
> !forceAffReassignment, false);
> }
> }
> {noformat}
> the searching mechanism will start to work correctly. Currently it's unclear
> why it's happened.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8610) Searching checkpoint / WAL history for rebalancing is not properly working in case of local/global WAL disabling
[ https://issues.apache.org/jira/browse/IGNITE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko updated IGNITE-8610: Description: After implementation IGNITE-6411 and IGNITE-8087 we can face with situation when after some checkpoint, WAL was temporarily disabled and enabled again. In this case we can't treat that checkpoint as start point to rebalance, because WAL history after such checkpoint may contain gaps. We should rework our checkpoint / wal history searching mechanism and ignore such checkpoints. was: After implementation IGNITE-6411 and IGNITE-8087 we can face with situation when after some checkpoint, WAL was temporarily disabled and enabled again. In this case we can't treat such checkpoint as start point to rebalance, because WAL history after such checkpoint may contain gaps. We should rework our checkpoint / wal history searching mechanism and ignore such checkpoints. > Searching checkpoint / WAL history for rebalancing is not properly working in > case of local/global WAL disabling > > > Key: IGNITE-8610 > URL: https://issues.apache.org/jira/browse/IGNITE-8610 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.6 > > > After implementation IGNITE-6411 and IGNITE-8087 we can face with situation > when after some checkpoint, WAL was temporarily disabled and enabled again. > In this case we can't treat that checkpoint as start point to rebalance, > because WAL history after such checkpoint may contain gaps. > We should rework our checkpoint / wal history searching mechanism and ignore > such checkpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8610) Searching checkpoint / WAL history for rebalancing is not properly working in case of local/global WAL disabling
Pavel Kovalenko created IGNITE-8610: --- Summary: Searching checkpoint / WAL history for rebalancing is not properly working in case of local/global WAL disabling Key: IGNITE-8610 URL: https://issues.apache.org/jira/browse/IGNITE-8610 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.5 Reporter: Pavel Kovalenko Assignee: Pavel Kovalenko Fix For: 2.6 After implementation IGNITE-6411 and IGNITE-8087 we can face with situation when after some checkpoint, WAL was temporarily disabled and enabled again. In this case we can't treat such checkpoint as start point to rebalance, because WAL history after such checkpoint may contain gaps. We should rework our checkpoint / wal history searching mechanism and ignore such checkpoints. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8513) SQL: Write benchmarks to compare mvcc on/off
[ https://issues.apache.org/jira/browse/IGNITE-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489599#comment-16489599 ] Pavel Kuznetsov commented on IGNITE-8513: - [~gvvinblade] , could you please take a look at the patch? > SQL: Write benchmarks to compare mvcc on/off > > > Key: IGNITE-8513 > URL: https://issues.apache.org/jira/browse/IGNITE-8513 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We need to compare performance with mvcc turned on and off. > Development branch is ignite-4191 > Scope > All benchmarks uses native sql api cache.query(SqlFieldsQuery) > We are using simplified data model: table containing long PK and 1 long value > field. > 1) Measure increased load of messages. > 1 client node and many (4) server nodes. > Benchmark performs updates in single thread. > backups = 0, 2 > 2) Measure contention on mvcc processor. > Many client nodes (4) and 1 server node. > Benchmark performs updates in many threads. Threads use keys from *disjoint* > ranges. > backups = 0 > 3) Measure contention on updates. > 4 client nodes and 2 server nodes. > Benchmark performs updates in many threads. Thread use keys from > *intersecting* ranges. > Exceptions due to write conflicts should be just ignored. > Update keys should be sorted to prevent dead locks in current implementation. > backups = 0 > Common parameters: > atomicity mode = transactional > cache mode = partitioned > persistence = off > some benchmark code can be reused from IGNITE-7988 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8513) SQL: Write benchmarks to compare mvcc on/off
[ https://issues.apache.org/jira/browse/IGNITE-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489596#comment-16489596 ] Pavel Kuznetsov commented on IGNITE-8513: - https://github.com/gridgain/apache-ignite/pull/95 > SQL: Write benchmarks to compare mvcc on/off > > > Key: IGNITE-8513 > URL: https://issues.apache.org/jira/browse/IGNITE-8513 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We need to compare performance with mvcc turned on and off. > Development branch is ignite-4191 > Scope > All benchmarks uses native sql api cache.query(SqlFieldsQuery) > We are using simplified data model: table containing long PK and 1 long value > field. > 1) Measure increased load of messages. > 1 client node and many (4) server nodes. > Benchmark performs updates in single thread. > backups = 0, 2 > 2) Measure contention on mvcc processor. > Many client nodes (4) and 1 server node. > Benchmark performs updates in many threads. Threads use keys from *disjoint* > ranges. > backups = 0 > 3) Measure contention on updates. > 4 client nodes and 2 server nodes. > Benchmark performs updates in many threads. Thread use keys from > *intersecting* ranges. > Exceptions due to write conflicts should be just ignored. > Update keys should be sorted to prevent dead locks in current implementation. > backups = 0 > Common parameters: > atomicity mode = transactional > cache mode = partitioned > persistence = off > some benchmark code can be reused from IGNITE-7988 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8513) SQL: Write benchmarks to compare mvcc on/off
[ https://issues.apache.org/jira/browse/IGNITE-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kuznetsov updated IGNITE-8513: Component/s: sql > SQL: Write benchmarks to compare mvcc on/off > > > Key: IGNITE-8513 > URL: https://issues.apache.org/jira/browse/IGNITE-8513 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We need to compare performance with mvcc turned on and off. > Development branch is ignite-4191 > Scope > All benchmarks uses native sql api cache.query(SqlFieldsQuery) > We are using simplified data model: table containing long PK and 1 long value > field. > 1) Measure increased load of messages. > 1 client node and many (4) server nodes. > Benchmark performs updates in single thread. > backups = 0, 2 > 2) Measure contention on mvcc processor. > Many client nodes (4) and 1 server node. > Benchmark performs updates in many threads. Threads use keys from *disjoint* > ranges. > backups = 0 > 3) Measure contention on updates. > 4 client nodes and 2 server nodes. > Benchmark performs updates in many threads. Thread use keys from > *intersecting* ranges. > Exceptions due to write conflicts should be just ignored. > Update keys should be sorted to prevent dead locks in current implementation. > backups = 0 > Common parameters: > atomicity mode = transactional > cache mode = partitioned > persistence = off > some benchmark code can be reused from IGNITE-7988 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489591#comment-16489591 ] Denis Magda commented on IGNITE-8524: - Ivan, granted you editorials permissions for https://apacheignite-tools.readme.io Check the inbox. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489588#comment-16489588 ] Denis Magda commented on IGNITE-8524: - [~ivan.glukos], didn't know about those capabilities. Let's document all the capabilities of control.sh on this page then: https://apacheignite-tools.readme.io/v2.4/docs/control-script Let's move the consistency check related command to that page too. I'll make a reference from the consistency page to specific sections of the control script page. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8524: --- Assignee: Ivan Rakov (was: Denis Magda) > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8609) SQL: Get rid of syncronization in mvcc processor.
Pavel Kuznetsov created IGNITE-8609: --- Summary: SQL: Get rid of syncronization in mvcc processor. Key: IGNITE-8609 URL: https://issues.apache.org/jira/browse/IGNITE-8609 Project: Ignite Issue Type: Task Components: sql Reporter: Pavel Kuznetsov Assignee: Igor Seliverstov Currently we have to do synchronized actions in org/apache/ignite/internal/managers/communication/GridIoManager.java:1124 (org.apache.ignite.internal.managers.communication.GridIoManager#processRegularMessage) due to fails on nio thread on load. We are able to optimize this code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8524: --- Assignee: Denis Magda (was: Ivan Rakov) > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8589) Prepare Node.JS Thin Client documentation
[ https://issues.apache.org/jira/browse/IGNITE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489479#comment-16489479 ] Denis Magda commented on IGNITE-8589: - [~pavel.petroshenko], I've spotted that there is no word saying how to authenticate from the client side and set up SSL. Let's explain how to do that providing code snippets. Here is a hidden sub-page created for that purpose: https://apacheignite.readme.io/v2.4/docs/security-and-authentication You take Java thin client's security page as a template: https://apacheignite.readme.io/v2.4/docs/java-thin-client-security > Prepare Node.JS Thin Client documentation > - > > Key: IGNITE-8589 > URL: https://issues.apache.org/jira/browse/IGNITE-8589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Pavel Petroshenko >Priority: Major > Fix For: 2.6 > > > The hidden page is presently here: > https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client > Once all the suggestions are resolved, we might split this page into several > pages. I can do this closer to 2.6 release. > [~pavel.petroshenko], [~alexey.kosenchuk], please address the following > suggestions for now: > Installation section: > * Ignite repository has to be used instead of the private one > * The section needs to explain the installation steps once the NPM module is > released. It's fine to put the current installation instructions under > "Installing from Sources" section. > Data Types: > * The term "field" is truly confusing. Does it really imply any possible data > (value, key, element of an array)? Why can't we use the term "value" instead? > * Provide a code snippet that shows how to configure the explicit mapping > * Default mapping has to be documented in place on readme.io (no references > to the private GIT repo) > Configuring Ignite Client > *Failover on a reconnect code snippet. How to pass a list of the endpoints. > General: > * You use CacheClient or just Cache notion to refer to an instance of the > cache class. Let's use one term. I prefer the Cache one or IgniteCache if > it's named this way. > * Add a reference to the examples once they are merged to Ignite repo (see > the latest section on the readme page) > * Add a reference to Node.JS APIs within supported APIs section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8608) .NET: Sign release NuGet packages
Pavel Tupitsyn created IGNITE-8608: -- Summary: .NET: Sign release NuGet packages Key: IGNITE-8608 URL: https://issues.apache.org/jira/browse/IGNITE-8608 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.6 NuGet signed package submissions has been introduced recently: https://blog.nuget.org/20180522/Introducing-signed-package-submissions.html Sign Ignite.NET packages when releasing them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8509) A lot of "Execution timeout" result for Cache 6 suite
[
https://issues.apache.org/jira/browse/IGNITE-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489371#comment-16489371
]
Alexey Kuznetsov edited comment on IGNITE-8509 at 5/24/18 4:49 PM:
---
[~dpavlov] I can pick this ticket up if nobody mind ?
was (Author: alexey kuznetsov):
[~dpavlov] I can pick this ticket up if nobody mind
> A lot of "Execution timeout" result for Cache 6 suite
> -
>
> Key: IGNITE-8509
> URL: https://issues.apache.org/jira/browse/IGNITE-8509
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> *Summary*
> Suite Cache 6 fails with execution timeout fails with
> {code:java}
> [org.apache.ignite:ignite-core] [2018-05-15 02:35:14,143][WARN
> ][grid-timeout-worker-#71656%transactions.TxRollbackOnTimeoutNearCacheTest0%][diagnostic]
> Found long running transaction [startTime=02:32:57.989,
> curTime=02:35:14.136, tx=GridDhtTxRemote
> {code}
> *Please, fefer for more details*
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&page=1&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E]
> *Statistics Cache 6 Suite*
> Recent fails : 42,0% [21 fails / 50 runs];
> Critical recent fails: 10,0% [5 fails / 50 runs];
> Last mounth (15.04 – 15.05)
> Execution timeout: 21,0% [84 fails / 400 runs];
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8509) A lot of "Execution timeout" result for Cache 6 suite
[
https://issues.apache.org/jira/browse/IGNITE-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489371#comment-16489371
]
Alexey Kuznetsov commented on IGNITE-8509:
--
[~dpavlov] I can pick this ticket up if nobody mind
> A lot of "Execution timeout" result for Cache 6 suite
> -
>
> Key: IGNITE-8509
> URL: https://issues.apache.org/jira/browse/IGNITE-8509
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> *Summary*
> Suite Cache 6 fails with execution timeout fails with
> {code:java}
> [org.apache.ignite:ignite-core] [2018-05-15 02:35:14,143][WARN
> ][grid-timeout-worker-#71656%transactions.TxRollbackOnTimeoutNearCacheTest0%][diagnostic]
> Found long running transaction [startTime=02:32:57.989,
> curTime=02:35:14.136, tx=GridDhtTxRemote
> {code}
> *Please, fefer for more details*
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&page=1&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E]
> *Statistics Cache 6 Suite*
> Recent fails : 42,0% [21 fails / 50 runs];
> Critical recent fails: 10,0% [5 fails / 50 runs];
> Last mounth (15.04 – 15.05)
> Execution timeout: 21,0% [84 fails / 400 runs];
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489363#comment-16489363
]
Ilya Kasnacheev commented on IGNITE-8547:
-
[~slukyanov] please review proposed fix!
> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9, 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException,
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
> for (int i = 0; i < 16; i++) {
> final int ii = i;
> Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
> thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And
> that's exactly what OptimizedMarshaller does.
> See also the attached test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489352#comment-16489352
]
ASF GitHub Bot commented on IGNITE-8547:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/4063
IGNITE-8547 Use JVM serialization for enum values with OptimizedMarsh…
…aller, avoid deadlock.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8547
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4063.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4063
commit 4ddb8bd85c7000356badb7bd8daf233491aaa3bf
Author: Ilya Kasnacheev
Date: 2018-05-22T11:32:12Z
IGNITE-8547 Use JVM serialization for enum values with OptimizedMarshaller,
avoid deadlock.
> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException,
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
> for (int i = 0; i < 16; i++) {
> final int ii = i;
> Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
> thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And
> that's exactly what OptimizedMarshaller does.
> See also the attached test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock
[
https://issues.apache.org/jira/browse/IGNITE-8547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489351#comment-16489351
]
ASF GitHub Bot commented on IGNITE-8547:
Github user alamar closed the pull request at:
https://github.com/apache/ignite/pull/4042
> Deserialization of Enum values as anonymous classes may cause deadlock
> --
>
> Key: IGNITE-8547
> URL: https://issues.apache.org/jira/browse/IGNITE-8547
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: test
> Attachments: MarshallerDeadlockMultiJvmTest.java
>
>
> Due to the following problem:
> {code}
> package jvmtest;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> public class LegTypeTest {
> public static void main(String[] args) throws InterruptedException,
> BrokenBarrierException {
> List threadList = new ArrayList<>();
> CyclicBarrier b1 = new CyclicBarrier(16);
> CyclicBarrier b2 = new CyclicBarrier(17);
> for (int i = 0; i < 16; i++) {
> final int ii = i;
> Thread thread = new Thread(() -> {
> try {
> b1.await();
> if (ii % 2 == 0)
> Class.forName("jvmtest.LegTypeTest$E$1");
> if (ii % 2 == 1)
> Class.forName("jvmtest.LegTypeTest$E");
> b2.await();
> } catch (Exception e) {
> e.printStackTrace();
> }
> });
> thread.start();
> threadList.add(thread);
> }
> b2.await();
> for (Thread thread : threadList) {
> thread.join();
> }
> }
> private enum E {
> A("A"),
> B("B") {
> @Override
> public String virtual() {
> return null;
> }
> };
> private String displayString;
> E(String displayString) {
> this.displayString = displayString;
> }
> public String virtual() {
> return displayString;
> }
> }
> }
> {code}
> When doing Class.forName on different enum values deadlock can be caused. And
> that's exactly what OptimizedMarshaller does.
> See also the attached test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration
[ https://issues.apache.org/jira/browse/IGNITE-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489307#comment-16489307 ] Ilya Kasnacheev commented on IGNITE-5789: - See also GridCacheProcessor:751 and GridCacheProcessor:2800 We should *definitely* have a common method here, apply it also to this fix. > After client reconnects to server if server was restarted, client doesn't > create caches defined in client's configuration > - > > Key: IGNITE-5789 > URL: https://issues.apache.org/jira/browse/IGNITE-5789 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Evgenii Zhuravlev >Assignee: vk >Priority: Major > Fix For: 2.6 > > Attachments: ClientReconnectAfterClusterRestartTest.java > > > User with this problem on SO: > https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration
[ https://issues.apache.org/jira/browse/IGNITE-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489302#comment-16489302 ] Ilya Kasnacheev commented on IGNITE-5789: - [~dpavlov] [~vk] I think we have this immediate problem: [02:39:02][Apache.Ignite.Core.Tests.exe] [23-05-2018 23:39:04][INFO ][exchange-worker-#7726][GridCacheProcessor] Started cache [name=template_store*, id=-1227147570, memoryPolicyName=default, mode=LOCAL, atomicity=TRANSACTIONAL, backups=0] "template_store*" cache should not be brought up, since it's a cache template. Nevertheless it is launched after your change. > After client reconnects to server if server was restarted, client doesn't > create caches defined in client's configuration > - > > Key: IGNITE-5789 > URL: https://issues.apache.org/jira/browse/IGNITE-5789 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Evgenii Zhuravlev >Assignee: vk >Priority: Major > Fix For: 2.6 > > Attachments: ClientReconnectAfterClusterRestartTest.java > > > User with this problem on SO: > https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8175) Missed CRC update in Lucene index.
[ https://issues.apache.org/jira/browse/IGNITE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489275#comment-16489275 ] Andrew Mashenkov edited comment on IGNITE-8175 at 5/24/18 3:59 PM: --- I've added a test as described in discussion on UL, but can't make test failed. Probably, it was a Lucene bug that has been fixed in lucene-5.3 [1] [1] https://issues.apache.org/jira/browse/LUCENE-6577 was (Author: amashenkov): I've add a test as described in discussion on UL, but can't make it failed. Probably, it was a Lucene bug that has been fixed in lucene-5.3 [1] [1] https://issues.apache.org/jira/browse/LUCENE-6577 > Missed CRC update in Lucene index. > -- > > Key: IGNITE-8175 > URL: https://issues.apache.org/jira/browse/IGNITE-8175 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.2, 2.3, 2.4 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.6 > > > We've missed CRC update in GridLuceneOutputStream.copyBytes() method. > See for [1] details. > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] > [2] > http://apache-ignite-users.70518.x6.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-td21020.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8175) Missed CRC update in Lucene index.
[ https://issues.apache.org/jira/browse/IGNITE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489275#comment-16489275 ] Andrew Mashenkov commented on IGNITE-8175: -- I've add a test as described in discussion on UL, but can't make it failed. Probably, it was a Lucene bug that has been fixed in lucene-5.3 [1] [1] https://issues.apache.org/jira/browse/LUCENE-6577 > Missed CRC update in Lucene index. > -- > > Key: IGNITE-8175 > URL: https://issues.apache.org/jira/browse/IGNITE-8175 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.2, 2.3, 2.4 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.6 > > > We've missed CRC update in GridLuceneOutputStream.copyBytes() method. > See for [1] details. > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] > [2] > http://apache-ignite-users.70518.x6.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-td21020.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8175) Missed CRC update in Lucene index.
[ https://issues.apache.org/jira/browse/IGNITE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8175: - Description: We've missed CRC update in GridLuceneOutputStream.copyBytes() method. See for [1] details. [1] [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] [2] http://apache-ignite-users.70518.x6.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-td21020.html was: We've missed CRC update in GridLuceneOutputStream.copyBytes() method. See for [1] details. [1] [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] > Missed CRC update in Lucene index. > -- > > Key: IGNITE-8175 > URL: https://issues.apache.org/jira/browse/IGNITE-8175 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.2, 2.3, 2.4 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.6 > > > We've missed CRC update in GridLuceneOutputStream.copyBytes() method. > See for [1] details. > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] > [2] > http://apache-ignite-users.70518.x6.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-td21020.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8605) sqlline can't work with terminal on newer ncurses
[
https://issues.apache.org/jira/browse/IGNITE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-8605:
---
Assignee: Ilya Kasnacheev
> sqlline can't work with terminal on newer ncurses
> -
>
> Key: IGNITE-8605
> URL: https://issues.apache.org/jira/browse/IGNITE-8605
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> On Ubuntu 18.04:
> {code}
> ~/w/incubator-ignite/modules/sqlline% IGNITE_HOME=~/w/incubator-ignite .
> bin/sqlline.sh
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.get(TerminalFactory.java:186)
> at jline.TerminalFactory.get(TerminalFactory.java:192)
> at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
> at sqlline.SqlLine.(SqlLine.java:54)
> at sqlline.SqlLine.start(SqlLine.java:372)
> at sqlline.SqlLine.main(SqlLine.java:265)
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.create(TerminalFactory.java:51)
> at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
> at sqlline.SqlLine.begin(SqlLine.java:639)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> sqlline version 1.3.0
> sqlline>
> ... and then history and command editing won't work
> {code}
> See also https://github.com/jline/jline2/issues/281
> I think we should manually peg jline verison to 2.14.4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8605) sqlline can't work with terminal on newer ncurses
[
https://issues.apache.org/jira/browse/IGNITE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489216#comment-16489216
]
Peter Ivanov commented on IGNITE-8605:
--
I'll look at the issue at May 29
> sqlline can't work with terminal on newer ncurses
> -
>
> Key: IGNITE-8605
> URL: https://issues.apache.org/jira/browse/IGNITE-8605
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> On Ubuntu 18.04:
> {code}
> ~/w/incubator-ignite/modules/sqlline% IGNITE_HOME=~/w/incubator-ignite .
> bin/sqlline.sh
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.get(TerminalFactory.java:186)
> at jline.TerminalFactory.get(TerminalFactory.java:192)
> at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
> at sqlline.SqlLine.(SqlLine.java:54)
> at sqlline.SqlLine.start(SqlLine.java:372)
> at sqlline.SqlLine.main(SqlLine.java:265)
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.create(TerminalFactory.java:51)
> at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
> at sqlline.SqlLine.begin(SqlLine.java:639)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> sqlline version 1.3.0
> sqlline>
> ... and then history and command editing won't work
> {code}
> See also https://github.com/jline/jline2/issues/281
> I think we should manually peg jline verison to 2.14.4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8509) A lot of "Execution timeout" result for Cache 6 suite
[
https://issues.apache.org/jira/browse/IGNITE-8509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489206#comment-16489206
]
Dmitriy Pavlov commented on IGNITE-8509:
I've failed test TxRollbackAsyncTest#testMixedAsyncRollbackTypes with reference
to issue.
> A lot of "Execution timeout" result for Cache 6 suite
> -
>
> Key: IGNITE-8509
> URL: https://issues.apache.org/jira/browse/IGNITE-8509
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> *Summary*
> Suite Cache 6 fails with execution timeout fails with
> {code:java}
> [org.apache.ignite:ignite-core] [2018-05-15 02:35:14,143][WARN
> ][grid-timeout-worker-#71656%transactions.TxRollbackOnTimeoutNearCacheTest0%][diagnostic]
> Found long running transaction [startTime=02:32:57.989,
> curTime=02:35:14.136, tx=GridDhtTxRemote
> {code}
> *Please, fefer for more details*
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&page=1&tab=buildTypeHistoryList&branch_IgniteTests24Java8=%3Cdefault%3E]
> *Statistics Cache 6 Suite*
> Recent fails : 42,0% [21 fails / 50 runs];
> Critical recent fails: 10,0% [5 fails / 50 runs];
> Last mounth (15.04 – 15.05)
> Execution timeout: 21,0% [84 fails / 400 runs];
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:22 PM: - [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in the cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:21 PM: - [~dmagda], please take a look. P. S. In addition to the described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:21 PM: - [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them on the same page? was (Author: ivan.glukos): [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them in the same page? > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov edited comment on IGNITE-8524 at 5/24/18 3:20 PM: - [~dmagda], please take a look. P. S. Except for described consistency check options, ./control.sh --cache subcommand allows to: 1. View existing atomic sequences with ./control.sh --cache seq 2. View list of working caches along with their parameters with ./control.sh --cache caches 3. View info about cache groups with ./control.sh --cache groups These commands doesn't relate to consistency checks, but can be helpful in understanding what's going in cluster. Should I document them in the same page? was (Author: ivan.glukos): [~dmagda], please take a look. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8560) Update index validation utility to use statistical check approach
[
https://issues.apache.org/jira/browse/IGNITE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489194#comment-16489194
]
ASF GitHub Bot commented on IGNITE-8560:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/4051
> Update index validation utility to use statistical check approach
> -
>
> Key: IGNITE-8560
> URL: https://issues.apache.org/jira/browse/IGNITE-8560
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.6
>
>
> Currently, the check index feature of {{control.sh}} scans the full data set
> which has N * logN complexity. On large data sets this takes too long to
> complete.
> To mitigate this, I suggest to add an option
> * to check either first K entries
> * to check each Kth entry
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8560) Update index validation utility to use statistical check approach
[
https://issues.apache.org/jira/browse/IGNITE-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489189#comment-16489189
]
Ivan Rakov commented on IGNITE-8560:
Thanks, merged to master.
> Update index validation utility to use statistical check approach
> -
>
> Key: IGNITE-8560
> URL: https://issues.apache.org/jira/browse/IGNITE-8560
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.6
>
>
> Currently, the check index feature of {{control.sh}} scans the full data set
> which has N * logN complexity. On large data sets this takes too long to
> complete.
> To mitigate this, I suggest to add an option
> * to check either first K entries
> * to check each Kth entry
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8567) [ML] Add Imputer and Binarizer for data preprocessing
[ https://issues.apache.org/jira/browse/IGNITE-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489187#comment-16489187 ] ASF GitHub Bot commented on IGNITE-8567: GitHub user zaleslaw opened a pull request: https://github.com/apache/ignite/pull/4062 IGNITE-8567: Imputer and Binarizer You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8567 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4062.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4062 commit 098d2832b3f4af23c72bc25f43e4ab8a95f2f416 Author: Zinoviev Alexey Date: 2018-04-11T18:40:27Z IGNITE-7829: Added example commit 78f9ea687bff77ec9f6bef87126569cb92cbe745 Author: Zinoviev Alexey Date: 2018-04-13T15:44:26Z Merge branch 'master' of https://github.com/apache/ignite commit 199e17d19ccbde9f15aba5375d834c3930b3a989 Author: Zinoviev Alexey Date: 2018-04-27T10:12:47Z Merge branch 'master' of https://github.com/apache/ignite commit aca9833df4d3cc4a641dd9109daaf628bc85acdf Author: Zinoviev Alexey Date: 2018-05-08T05:29:49Z Merge branch 'master' of https://github.com/apache/ignite commit bb244de762b89d0a1e5606aa282e34d92752595b Author: Zinoviev Alexey Date: 2018-05-16T11:42:06Z Merge branch 'master' of https://github.com/apache/ignite commit a0f6f0fcc54f8a6da36d4b61836719e19a6bbb4a Author: Zinoviev Alexey Date: 2018-05-16T13:21:47Z IGNITE-8511: Added MultiClass Log Regression commit b4cb1a42d35a0da9f8b762207011a46c6f542a20 Author: Zinoviev Alexey Date: 2018-05-16T16:17:39Z Merge branch 'master' of https://github.com/apache/ignite commit eb6178cd8e4a61fa12d4558b4377d53f94029c86 Author: Zinoviev Alexey Date: 2018-05-16T16:18:17Z Merge branch 'master' into ignite-8511 commit 21cb4433728618c06aa8e16fe681772ea25c9b63 Author: Zinoviev Alexey Date: 2018-05-21T07:47:08Z IGNITE-8511: Added MultiClass Log Regression commit 64d96c8c29e290d7ff98c8018056609c3bab83ed Author: Zinoviev Alexey Date: 2018-05-21T07:56:28Z IGNITE-8511: Added MultiClass Log Regression commit e10fb00ed15ac348f097d0eb91abfa4661769025 Author: Zinoviev Alexey Date: 2018-05-23T09:51:13Z IGNITE-8567: Added examples and 2 preprocessors commit a3cf8b5c35b961fd772dabf350f937425822c6ba Author: zaleslaw Date: 2018-05-24T15:05:21Z ignite-8567: Added tests for Imputer/Binarizer preprocessors > [ML] Add Imputer and Binarizer for data preprocessing > - > > Key: IGNITE-8567 > URL: https://issues.apache.org/jira/browse/IGNITE-8567 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > > The imputing with Mean and Most frequent values options can be effectively > distributed. > [http://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.Imputer.html#sklearn.preprocessing.Imputer] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8583) DataStorageMetricsMXBean.getOffHeapSize include checkpoint buffer size, this is not obvious
[ https://issues.apache.org/jira/browse/IGNITE-8583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489183#comment-16489183 ] ASF GitHub Bot commented on IGNITE-8583: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4054 > DataStorageMetricsMXBean.getOffHeapSize include checkpoint buffer size, this > is not obvious > --- > > Key: IGNITE-8583 > URL: https://issues.apache.org/jira/browse/IGNITE-8583 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > > Now DataStorageMetricsMXBean.getOffHeapSize includes checkpoint buffer > inside, on mxbean this is not obvious. > - add new method getUsedCheckpointBufferSize, should show used size. > - should show real size of checkpoint buffer geCheckpointBufferSize -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8607) [.NET] Support metric changes in DataStorageMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8607: --- Summary: [.NET] Support metric changes in DataStorageMetricsMXBean (was: [.NET] Support metrics changes in DataStorageMetricsMXBean) > [.NET] Support metric changes in DataStorageMetricsMXBean > - > > Key: IGNITE-8607 > URL: https://issues.apache.org/jira/browse/IGNITE-8607 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8607) [.NET] Support metrics changes in DataStorageMetricsMXBean
Dmitriy Govorukhin created IGNITE-8607: -- Summary: [.NET] Support metrics changes in DataStorageMetricsMXBean Key: IGNITE-8607 URL: https://issues.apache.org/jira/browse/IGNITE-8607 Project: Ignite Issue Type: Bug Reporter: Dmitriy Govorukhin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8606) Node hangs on next exchange, when no access to marshaller's folder
[
https://issues.apache.org/jira/browse/IGNITE-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-8606:
--
Description:
Exception in log:
{noformat}
2018-05-18 11:12:57.572
[ERROR][tcp-disco-msg-worker-#3%DPL_GRID%DplGridNodeName%][o.a.i.i.MarshallerMappingFileStore]
Failed to write class name to file [platformId=0id=1713316383,
clsName=com.sbt.dpl.gridgain.affinity.DPLIndexAffinityPrimaryFilter,
file=/u01/pprb/work/marshaller/1713316383.classname0]
java.io.FileNotFoundException: /u01/pprb/work/marshaller/1713316383.classname0
(No such file or directory)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at
org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:94)
at
org.apache.ignite.internal.MarshallerMappingFileStore.mergeAndWriteMapping(MarshallerMappingFileStore.java:207)
at
org.apache.ignite.internal.MarshallerContextImpl.onMappingDataReceived(MarshallerContextImpl.java:201)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.processIncomingMappings(GridMarshallerMappingProcessor.java:356)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.onJoiningNodeDataReceived(GridMarshallerMappingProcessor.java:336)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:908)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4220)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
was:
{noformat}
2018-05-18 11:12:57.572
[ERROR][tcp-disco-msg-worker-#3%DPL_GRID%DplGridNodeName%][o.a.i.i.MarshallerMappingFileStore]
Failed to write class name to file [platformId=0id=1713316383,
clsName=com.sbt.dpl.gridgain.affinity.DPLIndexAffinityPrimaryFilter,
file=/u01/pprb/work/marshaller/1713316383.classname0]
java.io.FileNotFoundException: /u01/pprb/work/marshaller/1713316383.classname0
(No such file or directory)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at
org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:94)
at
org.apache.ignite.internal.MarshallerMappingFileStore.mergeAndWriteMapping(MarshallerMappingFileStore.java:207)
at
org.apache.ignite.internal.MarshallerContextImpl.onMappingDataReceived(MarshallerContextImpl.java:201)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.processIncomingMappings(GridMarshallerMappingProcessor.java:356)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.onJoiningNodeDataReceived(GridMarshallerMappingProcessor.java:336)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:908)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4220)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
> Node hangs on next exchange, when no access to marshaller's folder
> ---
>
> Key: IGNITE-8606
> URL: https://issues.apache.org/jira/browse/IGNITE-8606
> Project: Ignite
> I
[jira] [Created] (IGNITE-8606) Node hangs on next exchange, when no access to marshaller's folder
Vladislav Pyatkov created IGNITE-8606:
-
Summary: Node hangs on next exchange, when no access to
marshaller's folder
Key: IGNITE-8606
URL: https://issues.apache.org/jira/browse/IGNITE-8606
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
{noformat}
2018-05-18 11:12:57.572
[ERROR][tcp-disco-msg-worker-#3%DPL_GRID%DplGridNodeName%][o.a.i.i.MarshallerMappingFileStore]
Failed to write class name to file [platformId=0id=1713316383,
clsName=com.sbt.dpl.gridgain.affinity.DPLIndexAffinityPrimaryFilter,
file=/u01/pprb/work/marshaller/1713316383.classname0]
java.io.FileNotFoundException: /u01/pprb/work/marshaller/1713316383.classname0
(No such file or directory)
at java.io.FileOutputStream.open0(Native Method)
at java.io.FileOutputStream.open(FileOutputStream.java:270)
at java.io.FileOutputStream.(FileOutputStream.java:213)
at java.io.FileOutputStream.(FileOutputStream.java:162)
at
org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:94)
at
org.apache.ignite.internal.MarshallerMappingFileStore.mergeAndWriteMapping(MarshallerMappingFileStore.java:207)
at
org.apache.ignite.internal.MarshallerContextImpl.onMappingDataReceived(MarshallerContextImpl.java:201)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.processIncomingMappings(GridMarshallerMappingProcessor.java:356)
at
org.apache.ignite.internal.processors.marshaller.GridMarshallerMappingProcessor.onJoiningNodeDataReceived(GridMarshallerMappingProcessor.java:336)
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.onExchange(GridDiscoveryManager.java:908)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1939)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeAddedMessage(ServerImpl.java:4220)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2744)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8605) sqlline can't work with terminal on newer ncurses
[
https://issues.apache.org/jira/browse/IGNITE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489161#comment-16489161
]
Ilya Kasnacheev commented on IGNITE-8605:
-
[~vveider] please review proposed tooling fix
> sqlline can't work with terminal on newer ncurses
> -
>
> Key: IGNITE-8605
> URL: https://issues.apache.org/jira/browse/IGNITE-8605
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> On Ubuntu 18.04:
> {code}
> ~/w/incubator-ignite/modules/sqlline% IGNITE_HOME=~/w/incubator-ignite .
> bin/sqlline.sh
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.get(TerminalFactory.java:186)
> at jline.TerminalFactory.get(TerminalFactory.java:192)
> at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
> at sqlline.SqlLine.(SqlLine.java:54)
> at sqlline.SqlLine.start(SqlLine.java:372)
> at sqlline.SqlLine.main(SqlLine.java:265)
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.create(TerminalFactory.java:51)
> at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
> at sqlline.SqlLine.begin(SqlLine.java:639)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> sqlline version 1.3.0
> sqlline>
> ... and then history and command editing won't work
> {code}
> See also https://github.com/jline/jline2/issues/281
> I think we should manually peg jline verison to 2.14.4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8605) sqlline can't work with terminal on newer ncurses
[
https://issues.apache.org/jira/browse/IGNITE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489159#comment-16489159
]
ASF GitHub Bot commented on IGNITE-8605:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/4061
IGNITE-8605 Specify jline minor version to fix ncurses issue.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8605
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4061.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4061
commit 4b7251df22be488b5931f98720ee1d4df9dd9d3d
Author: Ilya Kasnacheev
Date: 2018-05-24T14:55:43Z
IGNITE-8605 Specify jline minor version to fix ncurses issue.
> sqlline can't work with terminal on newer ncurses
> -
>
> Key: IGNITE-8605
> URL: https://issues.apache.org/jira/browse/IGNITE-8605
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> On Ubuntu 18.04:
> {code}
> ~/w/incubator-ignite/modules/sqlline% IGNITE_HOME=~/w/incubator-ignite .
> bin/sqlline.sh
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.get(TerminalFactory.java:186)
> at jline.TerminalFactory.get(TerminalFactory.java:192)
> at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
> at sqlline.SqlLine.(SqlLine.java:54)
> at sqlline.SqlLine.start(SqlLine.java:372)
> at sqlline.SqlLine.main(SqlLine.java:265)
> [ERROR] Failed to construct terminal; falling back to unsupported
> java.lang.NumberFormatException: For input string: "0x100"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.valueOf(Integer.java:766)
> at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
> at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
> at jline.UnixTerminal.(UnixTerminal.java:65)
> at jline.UnixTerminal.(UnixTerminal.java:50)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
> at jline.TerminalFactory.create(TerminalFactory.java:102)
> at jline.TerminalFactory.create(TerminalFactory.java:51)
> at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
> at sqlline.SqlLine.begin(SqlLine.java:639)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> sqlline version 1.3.0
> sqlline>
> ... and then history and command editing won't work
> {code}
> See also https://github.com/jline/jline2/issues/281
> I think we should manually peg jline verison to 2.14.4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8605) sqlline can't work with terminal on newer ncurses
Ilya Kasnacheev created IGNITE-8605:
---
Summary: sqlline can't work with terminal on newer ncurses
Key: IGNITE-8605
URL: https://issues.apache.org/jira/browse/IGNITE-8605
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.5
Reporter: Ilya Kasnacheev
On Ubuntu 18.04:
{code}
~/w/incubator-ignite/modules/sqlline% IGNITE_HOME=~/w/incubator-ignite .
bin/sqlline.sh
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
at jline.UnixTerminal.(UnixTerminal.java:65)
at jline.UnixTerminal.(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at jline.TerminalFactory.create(TerminalFactory.java:102)
at jline.TerminalFactory.get(TerminalFactory.java:186)
at jline.TerminalFactory.get(TerminalFactory.java:192)
at sqlline.SqlLineOpts.(SqlLineOpts.java:45)
at sqlline.SqlLine.(SqlLine.java:54)
at sqlline.SqlLine.start(SqlLine.java:372)
at sqlline.SqlLine.main(SqlLine.java:265)
[ERROR] Failed to construct terminal; falling back to unsupported
java.lang.NumberFormatException: For input string: "0x100"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.valueOf(Integer.java:766)
at jline.internal.InfoCmp.parseInfoCmp(InfoCmp.java:59)
at jline.UnixTerminal.parseInfoCmp(UnixTerminal.java:242)
at jline.UnixTerminal.(UnixTerminal.java:65)
at jline.UnixTerminal.(UnixTerminal.java:50)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at jline.TerminalFactory.getFlavor(TerminalFactory.java:211)
at jline.TerminalFactory.create(TerminalFactory.java:102)
at jline.TerminalFactory.create(TerminalFactory.java:51)
at sqlline.SqlLine.getConsoleReader(SqlLine.java:705)
at sqlline.SqlLine.begin(SqlLine.java:639)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265)
sqlline version 1.3.0
sqlline>
... and then history and command editing won't work
{code}
See also https://github.com/jline/jline2/issues/281
I think we should manually peg jline verison to 2.14.4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8524) Document consistency check utilities
[ https://issues.apache.org/jira/browse/IGNITE-8524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489127#comment-16489127 ] Ivan Rakov commented on IGNITE-8524: [~dmagda], please take a look. > Document consistency check utilities > > > Key: IGNITE-8524 > URL: https://issues.apache.org/jira/browse/IGNITE-8524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Ivan Rakov >Priority: Critical > Fix For: 2.5 > > > Ignite 2.5 will go with special consistency check utilities that, for > instance, ensure that the data stays consistent across backups, indexes are > correct and many other things. More details can be taken from here: > * https://issues.apache.org/jira/browse/IGNITE-8277 > * https://issues.apache.org/jira/browse/IGNITE-7467 > Here is an empty page that is created for the documentation: > https://apacheignite.readme.io/docs/consistency-check-utilities -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8604) .NET test failures probably after IGNITE-5789 merge
[
https://issues.apache.org/jira/browse/IGNITE-8604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8604:
---
Issue Type: Test (was: Improvement)
> .NET test failures probably after IGNITE-5789 merge
> ---
>
> Key: IGNITE-8604
> URL: https://issues.apache.org/jira/browse/IGNITE-8604
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> 62 new failed tests in .NET
> {noformat}
> Store.CacheStoreTest
> Current failure:refs/heads/master #254 Changes (8)
> 24 May 18 02:16
> First failure: refs/heads/master #1 No changes 26 Apr
> 18 10:36
> TearDown method failed. HandleRegistry is not empty in grid '' (expected 4,
> actual 5):
> '[2, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
> [3, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
> [4, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
> [5, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]'
>at NUnit.Framework.Assert.Fail(String message, Object[] args)
>at Apache.Ignite.Core.Tests.TestUtils.AssertHandleRegistryHasItems(IIgnite
> grid, Int32 expectedCount, Int32 timeout) in
> c:\BuildAgent\work\c182b70f2dfa6507\modules\platforms\dotnet\Apache.Ignite.Core.Tests\TestUtils.Common.cs:line
> 339
>at Apache.Ignite.Core.Tests.Cache.Store.CacheStoreTest.AfterTests
> {noformat}
> First time these test failed
> https://ci.ignite.apache.org/viewLog.html?buildId=1323959&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> Probably it is caused by merge:
> https://issues.apache.org/jira/browse/IGNITE-5789
> I've tried to revert commit in ignite-5789-1 branch and results:
> https://ci.ignite.apache.org/viewLog.html?buildId=1326520&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNet
> Other test failed, but current tests were passed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5789) After client reconnects to server if server was restarted, client doesn't create caches defined in client's configuration
[ https://issues.apache.org/jira/browse/IGNITE-5789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489118#comment-16489118 ] Dmitriy Pavlov commented on IGNITE-5789: Hi I've created ticket for suspicious test failures in .NET [IGNITE-8604] [~ilyak] coyld you please take a look? If we can't find out solution probably we should revert commit. > After client reconnects to server if server was restarted, client doesn't > create caches defined in client's configuration > - > > Key: IGNITE-5789 > URL: https://issues.apache.org/jira/browse/IGNITE-5789 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Evgenii Zhuravlev >Assignee: vk >Priority: Major > Fix For: 2.6 > > Attachments: ClientReconnectAfterClusterRestartTest.java > > > User with this problem on SO: > https://stackoverflow.com/questions/46053089/ignite-cache-reconnection-issue-cache-is-stopped -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8603) Add JMX-metric to cluster: baseline nodes
Dmitriy Gladkikh created IGNITE-8603:
Summary: Add JMX-metric to cluster: baseline nodes
Key: IGNITE-8603
URL: https://issues.apache.org/jira/browse/IGNITE-8603
Project: Ignite
Issue Type: Improvement
Reporter: Dmitriy Gladkikh
Fix For: 2.6
Need to add a baseline nodes on JMX:
{code:java}
int org.apache.ignite.mxbean.ClusterMetricsMXBean#getBaselineNodes
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8604) .NET test failures probably after IGNITE-5789 merge
Dmitriy Pavlov created IGNITE-8604:
--
Summary: .NET test failures probably after IGNITE-5789 merge
Key: IGNITE-8604
URL: https://issues.apache.org/jira/browse/IGNITE-8604
Project: Ignite
Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Ilya Kasnacheev
62 new failed tests in .NET
{noformat}
Store.CacheStoreTest
Current failure:refs/heads/master #254 Changes (8)
24 May 18 02:16
First failure: refs/heads/master #1 No changes 26 Apr
18 10:36
TearDown method failed. HandleRegistry is not empty in grid '' (expected 4,
actual 5):
'[2, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
[3, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
[4, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]
[5, Apache.Ignite.Core.Impl.Cache.Store.CacheStore]'
at NUnit.Framework.Assert.Fail(String message, Object[] args)
at Apache.Ignite.Core.Tests.TestUtils.AssertHandleRegistryHasItems(IIgnite
grid, Int32 expectedCount, Int32 timeout) in
c:\BuildAgent\work\c182b70f2dfa6507\modules\platforms\dotnet\Apache.Ignite.Core.Tests\TestUtils.Common.cs:line
339
at Apache.Ignite.Core.Tests.Cache.Store.CacheStoreTest.AfterTests
{noformat}
First time these test failed
https://ci.ignite.apache.org/viewLog.html?buildId=1323959&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNet
Probably it is caused by merge:
https://issues.apache.org/jira/browse/IGNITE-5789
I've tried to revert commit in ignite-5789-1 branch and results:
https://ci.ignite.apache.org/viewLog.html?buildId=1326520&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNet
Other test failed, but current tests were passed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8563) WAL file archiver does not propagate file archiving error to error handler
[
https://issues.apache.org/jira/browse/IGNITE-8563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16489055#comment-16489055
]
Andrey Gura commented on IGNITE-8563:
-
Fixed and merged to master branch.
> WAL file archiver does not propagate file archiving error to error handler
> --
>
> Key: IGNITE-8563
> URL: https://issues.apache.org/jira/browse/IGNITE-8563
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.6
>
>
> I observed this error when a disk with WAL archive left out of space:
> {code}
> ...
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:464)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:517)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:940)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:819)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:775)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:189)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:187)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ignite.IgniteException: Runtime failure on row:
> Row@1ec13b23[ key: 4458000681143704309, val:
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2119)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:548)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:480)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:659)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1393)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1257)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1511)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.
[jira] [Commented] (IGNITE-7766) Ignite Queries 2: Test always failed IgniteCacheQueryNodeRestartTxSelfTest.testRestarts
[ https://issues.apache.org/jira/browse/IGNITE-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488983#comment-16488983 ] Dmitriy Pavlov commented on IGNITE-7766: Hi [~ezagumennov], why issue is resolved, but PR is open. Was this change merged? If not, issue should be in Patch Available state > Ignite Queries 2: Test always failed > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > --- > > Key: IGNITE-7766 > URL: https://issues.apache.org/jira/browse/IGNITE-7766 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Dmitriy Pavlov >Assignee: Evgenii Zagumennov >Priority: Major > Labels: MakeTeamcityGreenAgain > >Ignite Queries 2 > IgniteBinaryCacheQueryTestSuite2: > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts (fail rate 76,1%) > IgniteCacheQueryNodeRestartTxSelfTest.testRestarts > Current failure:refs/heads/master #345No changes > 11 Feb 18 03:03 > > junit.framework.AssertionFailedError: On large page size must retry. > > Last runs fails with 100% probability. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8563) WAL file archiver does not propagate file archiving error to error handler
[
https://issues.apache.org/jira/browse/IGNITE-8563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura reassigned IGNITE-8563:
---
Assignee: Andrey Gura
> WAL file archiver does not propagate file archiving error to error handler
> --
>
> Key: IGNITE-8563
> URL: https://issues.apache.org/jira/browse/IGNITE-8563
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Alexey Goncharuk
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.6
>
>
> I observed this error when a disk with WAL archive left out of space:
> {code}
> ...
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:464)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:517)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:940)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:819)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:775)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:189)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:187)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.ignite.IgniteException: Runtime failure on row:
> Row@1ec13b23[ key: 4458000681143704309, val:
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2119)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:548)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:480)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:659)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1393)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1257)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1511)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3602)
> at
> org.apache.ignite.internal.proces
[jira] [Commented] (IGNITE-8584) Provide ability to terminate any thread with enabled test features
[
https://issues.apache.org/jira/browse/IGNITE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488958#comment-16488958
]
Andrey Gura commented on IGNITE-8584:
-
LGTM! Merged to master branch. Thanks for contribution!
> Provide ability to terminate any thread with enabled test features
> --
>
> Key: IGNITE-8584
> URL: https://issues.apache.org/jira/browse/IGNITE-8584
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
> Fix For: 2.6
>
>
> eWe already have {{WorkersControlMXBean}} that provides possibility to
> interrupt thread registered in system workers registry. We also want stop any
> thread in the system for testing purposes.
> Method {{stop(long id)}} should be added that have to find thread by id and
> stop it.
> Example of thread information form thread dump where thread id is bold:
> "tcp-disco-msg-worker-#2" #*62* prio=10 os_prio=0 tid=0x7f2519714800
> nid=0x32b4 runnable [0x7f24a425]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8554) Cache metrics: expose metrics with rebalance info about keys
[ https://issues.apache.org/jira/browse/IGNITE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reassigned IGNITE-8554: --- Assignee: Sergey Chugunov (was: Pavel Konstantinov) > Cache metrics: expose metrics with rebalance info about keys > > > Key: IGNITE-8554 > URL: https://issues.apache.org/jira/browse/IGNITE-8554 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Alexey Kuznetsov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.6 > > > In order to show info about rebalance progress we need to expose > estimatedRebalancingKeys and rebalancedKeys metrics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8451) [ML] Refactor Labeled Dataset: remove unused methods and fields
[ https://issues.apache.org/jira/browse/IGNITE-8451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev reassigned IGNITE-8451: Assignee: Yury Babak (was: Aleksey Zinoviev) > [ML] Refactor Labeled Dataset: remove unused methods and fields > --- > > Key: IGNITE-8451 > URL: https://issues.apache.org/jira/browse/IGNITE-8451 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Yury Babak >Priority: Major > > Remove > * loading from file > * distributed version (we need local version only) > * parent class Dataset and meta-information -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8602) Add support filter label=null for control.sh tx utility
[ https://issues.apache.org/jira/browse/IGNITE-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Sherstobitov updated IGNITE-8602: Description: For now this transactions cannot be separated from other by using filter "label null" > Add support filter label=null for control.sh tx utility > --- > > Key: IGNITE-8602 > URL: https://issues.apache.org/jira/browse/IGNITE-8602 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > > For now this transactions cannot be separated from other by using filter > "label null" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8602) Add support filter label=null for control.sh tx utility
Dmitry Sherstobitov created IGNITE-8602: --- Summary: Add support filter label=null for control.sh tx utility Key: IGNITE-8602 URL: https://issues.apache.org/jira/browse/IGNITE-8602 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Sherstobitov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8601) Add to control.sh tx utility information about transaction start time
Dmitry Sherstobitov created IGNITE-8601: --- Summary: Add to control.sh tx utility information about transaction start time Key: IGNITE-8601 URL: https://issues.apache.org/jira/browse/IGNITE-8601 Project: Ignite Issue Type: Improvement Affects Versions: 2.5 Reporter: Dmitry Sherstobitov This information will be useful -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6612) Wrap ack methods in their own class
[ https://issues.apache.org/jira/browse/IGNITE-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488851#comment-16488851 ] ASF GitHub Bot commented on IGNITE-6612: Github user 1vanan closed the pull request at: https://github.com/apache/ignite/pull/3046 > Wrap ack methods in their own class > --- > > Key: IGNITE-6612 > URL: https://issues.apache.org/jira/browse/IGNITE-6612 > Project: Ignite > Issue Type: Improvement >Affects Versions: None >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Trivial > Labels: refactor > Fix For: 2.6 > > > Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, > “ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, > “ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, > “ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, > “ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. > These methods should be placed in separate class “AckVariousInformation” and > called from the class instance in IgniteKernal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8580) Print page read/write metrics splitted by type
[ https://issues.apache.org/jira/browse/IGNITE-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8580: --- Assignee: Vladimir Ozerov > Print page read/write metrics splitted by type > -- > > Key: IGNITE-8580 > URL: https://issues.apache.org/jira/browse/IGNITE-8580 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.6 > > > Currently it is impossible to track how many pages of a certain type were > read from or written to disk. This might be very useful for performance > tuning and debugging purposes. E.g. excessive page reads may highlight > missing SQL index. > We need to expose total read/write pages metrics splitted by page type (see > org.apache.ignite.internal.processors.cache.persistence.tree.io.PageIO#getType()). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8507) SQL: Print a warning if SQL index inline size is not sufficient
[ https://issues.apache.org/jira/browse/IGNITE-8507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8507: --- Assignee: Vladimir Ozerov > SQL: Print a warning if SQL index inline size is not sufficient > --- > > Key: IGNITE-8507 > URL: https://issues.apache.org/jira/browse/IGNITE-8507 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.6 > > > "Inline size" is very important optimization. When not used secondary index > lookup may become extraordinary slow. > Let's print a warning when certain indexes cannot hold their values in index > pages, so that user can adjust index configuration accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8600) SQL: lazy row materialization
Vladimir Ozerov created IGNITE-8600: --- Summary: SQL: lazy row materialization Key: IGNITE-8600 URL: https://issues.apache.org/jira/browse/IGNITE-8600 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.5 Environment: Currently our index cursor materializes rows as soon as they are encountered in an index page. This is necessary to protect ourselves from concurrent data modification. However, materialized rows might be filtered out later due to additional filters. In addition, there is a chance that only indexed fields is needed by query. We can do the following: 1) Introduce new mode that will return partially materialized rows, with only inline index fields initialized. When some non-initialized attribute is requested, we go to data page and materialize the whole row 2) Enable this mode for MVCC by default 3) Optionally enable this mode for non-MVCC read-only mode through additional flag. Reporter: Vladimir Ozerov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8599) Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge from Direct IO suite
[ https://issues.apache.org/jira/browse/IGNITE-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8599: --- Issue Type: Test (was: Wish) > Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge > from Direct IO suite > --- > > Key: IGNITE-8599 > URL: https://issues.apache.org/jira/browse/IGNITE-8599 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.6 > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails > It falls only in Direct IO > It is necessary to exclude it from direct IO because it gives a lot of load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8599) Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge from Direct IO suite
[ https://issues.apache.org/jira/browse/IGNITE-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8599: --- Description: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails It falls only in Direct IO It is necessary to exclude it from direct IO because it gives a lot of load. was: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails It falls only in Direct IO It is necessary to exclude it from direct IO if it gives a lot of load. > Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge > from Direct IO suite > --- > > Key: IGNITE-8599 > URL: https://issues.apache.org/jira/browse/IGNITE-8599 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.6 > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails > It falls only in Direct IO > It is necessary to exclude it from direct IO because it gives a lot of load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8599) Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge from Direct IO suite
Dmitriy Pavlov created IGNITE-8599: -- Summary: Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge from Direct IO suite Key: IGNITE-8599 URL: https://issues.apache.org/jira/browse/IGNITE-8599 Project: Ignite Issue Type: Improvement Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Fix For: 2.6 https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails It falls only in Direct IO It is necessary to exclude it from direct IO if it gives a lot of load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8599) Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge from Direct IO suite
[ https://issues.apache.org/jira/browse/IGNITE-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8599: --- Issue Type: Wish (was: Improvement) > Remove LocalWalModeChangeDuringRebalancingSelfTest.testWithExchangesMerge > from Direct IO suite > --- > > Key: IGNITE-8599 > URL: https://issues.apache.org/jira/browse/IGNITE-8599 > Project: Ignite > Issue Type: Wish >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Fix For: 2.6 > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6346758468206865681&branch=%3Cdefault%3E&tab=testDetails > It falls only in Direct IO > It is necessary to exclude it from direct IO because it gives a lot of load. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8584) Provide ability to terminate any thread with enabled test features
[
https://issues.apache.org/jira/browse/IGNITE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-8584:
Description:
eWe already have {{WorkersControlMXBean}} that provides possibility to
interrupt thread registered in system workers registry. We also want stop any
thread in the system for testing purposes.
Method {{stop(long id)}} should be added that have to find thread by id and
stop it.
Example of thread information form thread dump where thread id is bold:
"tcp-disco-msg-worker-#2" #*62* prio=10 os_prio=0 tid=0x7f2519714800
nid=0x32b4 runnable [0x7f24a425]
was:
eWe already have {{WorkersControlMXBean}} that provides possibility to
interrupt thread registered in system workers registry. We also want stop any
thread in the system for testing purposes.
Method {{stop(long id)}} should be added that have to find thread by id and
stop it.
Example of thread information form thread dump where thread id is bold:
"tcp-disco-msg-worker-#2" *#62* prio=10 os_prio=0 tid=0x7f2519714800
nid=0x32b4 runnable [0x7f24a425]
> Provide ability to terminate any thread with enabled test features
> --
>
> Key: IGNITE-8584
> URL: https://issues.apache.org/jira/browse/IGNITE-8584
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
> Fix For: 2.6
>
>
> eWe already have {{WorkersControlMXBean}} that provides possibility to
> interrupt thread registered in system workers registry. We also want stop any
> thread in the system for testing purposes.
> Method {{stop(long id)}} should be added that have to find thread by id and
> stop it.
> Example of thread information form thread dump where thread id is bold:
> "tcp-disco-msg-worker-#2" #*62* prio=10 os_prio=0 tid=0x7f2519714800
> nid=0x32b4 runnable [0x7f24a425]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8584) Provide ability to terminate any thread with enabled test features
[
https://issues.apache.org/jira/browse/IGNITE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-8584:
Description:
eWe already have {{WorkersControlMXBean}} that provides possibility to
interrupt thread registered in system workers registry. We also want stop any
thread in the system for testing purposes.
Method {{stop(long id)}} should be added that have to find thread by id and
stop it.
Example of thread information form thread dump where thread id is bold:
"tcp-disco-msg-worker-#2" *#62* prio=10 os_prio=0 tid=0x7f2519714800
nid=0x32b4 runnable [0x7f24a425]
was:
We already have {{WorkersControlMXBean}} that provides possibility to interrupt
thread registered in system workers registry. We also want stop any thread in
the system for testing purposes.
Method {{stop(String tid_hex)}} should be added that have to find thread by id
and stop it.
> Provide ability to terminate any thread with enabled test features
> --
>
> Key: IGNITE-8584
> URL: https://issues.apache.org/jira/browse/IGNITE-8584
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
> Fix For: 2.6
>
>
> eWe already have {{WorkersControlMXBean}} that provides possibility to
> interrupt thread registered in system workers registry. We also want stop any
> thread in the system for testing purposes.
> Method {{stop(long id)}} should be added that have to find thread by id and
> stop it.
> Example of thread information form thread dump where thread id is bold:
> "tcp-disco-msg-worker-#2" *#62* prio=10 os_prio=0 tid=0x7f2519714800
> nid=0x32b4 runnable [0x7f24a425]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8568) Web Console: Add support for "collocated" query mode on Query screen
[ https://issues.apache.org/jira/browse/IGNITE-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488761#comment-16488761 ] Pavel Konstantinov commented on IGNITE-8568: Tested. > Web Console: Add support for "collocated" query mode on Query screen > > > Key: IGNITE-8568 > URL: https://issues.apache.org/jira/browse/IGNITE-8568 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov >Priority: Major > Fix For: 2.6 > > > Ignite SQL engine supports special flag "collocated" that can improve > performance of SQL queries in special situations. > Lets add this flag to Query screen UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8568) Web Console: Add support for "collocated" query mode on Query screen
[ https://issues.apache.org/jira/browse/IGNITE-8568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-8568: -- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web Console: Add support for "collocated" query mode on Query screen > > > Key: IGNITE-8568 > URL: https://issues.apache.org/jira/browse/IGNITE-8568 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.6 > > > Ignite SQL engine supports special flag "collocated" that can improve > performance of SQL queries in special situations. > Lets add this flag to Query screen UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4210) CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose data.
[ https://issues.apache.org/jira/browse/IGNITE-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488759#comment-16488759 ] Dmitriy Pavlov commented on IGNITE-4210: [~agura], could you please take a look? TC run seems to be good, license failure is not related to fix. > CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose > data. > > > Key: IGNITE-4210 > URL: https://issues.apache.org/jira/browse/IGNITE-4210 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Alexey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > org.apache.ignite.internal.processors.cache.distributed.CacheLoadingConcurrentGridStartSelfTest#testLoadCacheFromStore > sometimes have failures. -- 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&focusedCommentId=16488757#comment-16488757
]
Stanislav Lukyanov commented on IGNITE-8550:
This was initially reported on SO:
https://stackoverflow.com/questions/50453761/ignite-and-mysql-unexpected-number-of-updated-entries
> 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: sql
>Reporter: Stanislav Lukyanov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0
[
https://issues.apache.org/jira/browse/IGNITE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488750#comment-16488750
]
Stanislav Lukyanov commented on IGNITE-8550:
To clarify: the issue only causes a false warning message, functionality is not
broken.
> 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: sql
>Reporter: Stanislav Lukyanov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> CacheAbstractJdbcStore.write attempts to execute a merge update if it is
> available, and expects the merge to always return 1 (as the number of updated
> entries is always 1).
> However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE`
> (https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return
> 0 or 2, depending on what was updated:
> {quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if
> the row is inserted as a new row, 2 if an existing row is updated, and 0 if
> an existing row is set to its current values.{quote}
> Because of that, CacheAbstractJdbcStore may report a false warning.
> Need to consider either removing the warning or special-case the MySQL
> dialect to allow to return values other than 1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc
[
https://issues.apache.org/jira/browse/IGNITE-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488740#comment-16488740
]
Ivan Fedotov edited comment on IGNITE-8406 at 5/24/18 10:03 AM:
[~dpavlov], Hello!
Could you please look at this ticket?
It seems to me that javaDoc of IgniteDataStreamer not entirely correct.
Mapping keys to node happens in load0 method[1] which invoked in addData method
while loading data from buffers always happens in flush[2] and tryFlush[3]
methods. Just about same situation in close(boolean) method. So I think minor
javaDoc changes are appropriate here.
Also according to conversation on user list[4] it would be better to explicitly
indicate about listeners.
[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L872]
[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1117]
[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1227]
[4][http://apache-ignite-users.70518.x6.nabble.com/IgniteDataStreamer-flush-returns-before-all-futures-are-completed-td21330.html]
was (Author: ivanan.fed):
[~dpavlov], Hello!
Could you please see at this ticket?
It seems to me that javaDoc of IgniteDataStreamer not entirely correct.
Mapping keys to node happens in load0 method[1] which invoked in addData method
while loading data from buffers always happens in flush[2] and tryFlush[3]
methods. Just about same situation in close(boolean) method. So I think minor
javaDoc changes are appropriate here.
Also according to conversation on user list[4] it would be better to explicitly
indicate about listeners.
[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L872]
[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1117]
[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1227]
[4][http://apache-ignite-users.70518.x6.nabble.com/IgniteDataStreamer-flush-returns-before-all-futures-are-completed-td21330.html]
> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
> Issue Type: Task
> Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Ivan Fedotov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or
> more futures previously returned by {{addData()}} have been completed
> exceptionally. This behavior should be described in {{IgniteDataStreamer}}
> javadoc. Also it's worth noting explicitly that all futures completion upon
> return from {{flush}} does not imply all those future listeners have been
> completed by this moment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc
[
https://issues.apache.org/jira/browse/IGNITE-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16488740#comment-16488740
]
Ivan Fedotov commented on IGNITE-8406:
--
[~dpavlov], Hello!
Could you please see at this ticket?
It seems to me that javaDoc of IgniteDataStreamer not entirely correct.
Mapping keys to node happens in load0 method[1] which invoked in addData method
while loading data from buffers always happens in flush[2] and tryFlush[3]
methods. Just about same situation in close(boolean) method. So I think minor
javaDoc changes are appropriate here.
Also according to conversation on user list[4] it would be better to explicitly
indicate about listeners.
[1][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L872]
[2][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1117]
[3][https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1227]
[4][http://apache-ignite-users.70518.x6.nabble.com/IgniteDataStreamer-flush-returns-before-all-futures-are-completed-td21330.html]
> Update IgniteDataStreamer.flush() javadoc
> -
>
> Key: IGNITE-8406
> URL: https://issues.apache.org/jira/browse/IGNITE-8406
> Project: Ignite
> Issue Type: Task
> Components: streaming
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Ivan Fedotov
>Priority: Minor
> Fix For: 2.6
>
>
> Current {{flush()}} implementation can throw {{CacheException}} if one or
> more futures previously returned by {{addData()}} have been completed
> exceptionally. This behavior should be described in {{IgniteDataStreamer}}
> javadoc. Also it's worth noting explicitly that all futures completion upon
> return from {{flush}} does not imply all those future listeners have been
> completed by this moment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8598) SQL: ability to control partition pruning with explicit affinity column definition
Vladimir Ozerov created IGNITE-8598:
---
Summary: SQL: ability to control partition pruning with explicit
affinity column definition
Key: IGNITE-8598
URL: https://issues.apache.org/jira/browse/IGNITE-8598
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Affinity functions are applicable to keys only. Sometimes users may have
complex affinity calculation logic, so that partition pruning optimization is
not applicable. E.g. this custom {{AffinityKeyMapper}}. However, there is a
chance that partition could be calculated from some attribute of {{value}}.
It would be nice to force our engine to treat some attribute as affinity key
even though it is not marked as {{AffinityKeyMapped}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8597) Direct data load
Vladimir Ozerov created IGNITE-8597: --- Summary: Direct data load Key: IGNITE-8597 URL: https://issues.apache.org/jira/browse/IGNITE-8597 Project: Ignite Issue Type: Task Components: general Reporter: Vladimir Ozerov We should implement optimized data loading mode, which will bypass as much internal Ignite components as possible to improve data loading speed. Raw design: 1) Direct data load must be performed in exclusive mode, i.e. nobody else are allowed to read or write to specific cache/table at this time. I.e. we need to implement distributed table/cache locks. 2) At first we should write to data pages directly skipping free lists, PK hash index and secondary indexes 3) Once loading is finished, we should rebuild free lists and indexes (bottom-up); external merge implementation will be required 4) We should distinguish between initial load and incremental load. The latter would require merge of indexes with previously available data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8597) Direct data load
[ https://issues.apache.org/jira/browse/IGNITE-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8597: Labels: performance (was: ) > Direct data load > > > Key: IGNITE-8597 > URL: https://issues.apache.org/jira/browse/IGNITE-8597 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > We should implement optimized data loading mode, which will bypass as much > internal Ignite components as possible to improve data loading speed. > Raw design: > 1) Direct data load must be performed in exclusive mode, i.e. nobody else are > allowed to read or write to specific cache/table at this time. I.e. we need > to implement distributed table/cache locks. > 2) At first we should write to data pages directly skipping free lists, PK > hash index and secondary indexes > 3) Once loading is finished, we should rebuild free lists and indexes > (bottom-up); external merge implementation will be required > 4) We should distinguish between initial load and incremental load. The > latter would require merge of indexes with previously available data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8596) SQL: remove unnecessary index lookups when query parallelism is enabled
[
https://issues.apache.org/jira/browse/IGNITE-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8596:
Labels: performance (was: )
> SQL: remove unnecessary index lookups when query parallelism is enabled
> ---
>
> Key: IGNITE-8596
> URL: https://issues.apache.org/jira/browse/IGNITE-8596
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor#onQueryRequest}}
> method. If table is segmented, we will submit as many SQL requests as much
> segments. But consider a case when target cache partition(s) is already
> defined by user or derived through partition pruning. In this case most of
> segments will not contain useful information and return empty result set. At
> the same time these queries may impose index or data page scans, thus
> consuming resources without a reason.
> To mitigate the problem we should not submit SQL requests to segments we are
> not interested in.
> Note that it is not sufficient to simply skip SQL requests on mapper, because
> reducer expects separate response for every message. We should fix both local
> mapper logic as well as protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8596) SQL: remove unnecessary index lookups when query parallelism is enabled
Vladimir Ozerov created IGNITE-8596:
---
Summary: SQL: remove unnecessary index lookups when query
parallelism is enabled
Key: IGNITE-8596
URL: https://issues.apache.org/jira/browse/IGNITE-8596
Project: Ignite
Issue Type: Task
Components: sql
Affects Versions: 2.5
Reporter: Vladimir Ozerov
Fix For: 2.6
See
{{org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor#onQueryRequest}}
method. If table is segmented, we will submit as many SQL requests as much
segments. But consider a case when target cache partition(s) is already defined
by user or derived through partition pruning. In this case most of segments
will not contain useful information and return empty result set. At the same
time these queries may impose index or data page scans, thus consuming
resources without a reason.
To mitigate the problem we should not submit SQL requests to segments we are
not interested in.
Note that it is not sufficient to simply skip SQL requests on mapper, because
reducer expects separate response for every message. We should fix both local
mapper logic as well as protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8584) Provide ability to terminate any thread with enabled test features
[
https://issues.apache.org/jira/browse/IGNITE-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura updated IGNITE-8584:
Description:
We already have {{WorkersControlMXBean}} that provides possibility to interrupt
thread registered in system workers registry. We also want stop any thread in
the system for testing purposes.
Method {{stop(String tid_hex)}} should be added that have to find thread by id
and stop it.
was:
We already have {{WorkersControlMXBean}} that provides possibility to interrupt
thread registered in system workers registry. We also want stop any thread in
the system for testing purposes.
Method {{stop(String threadName)}} should be added that have to find thread by
name and stop it.
> Provide ability to terminate any thread with enabled test features
> --
>
> Key: IGNITE-8584
> URL: https://issues.apache.org/jira/browse/IGNITE-8584
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey Gura
>Assignee: Dmitriy Sorokin
>Priority: Major
> Fix For: 2.6
>
>
> We already have {{WorkersControlMXBean}} that provides possibility to
> interrupt thread registered in system workers registry. We also want stop any
> thread in the system for testing purposes.
> Method {{stop(String tid_hex)}} should be added that have to find thread by
> id and stop it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8595) SQL: Ability to cancel DDL operations
Vladimir Ozerov created IGNITE-8595:
---
Summary: SQL: Ability to cancel DDL operations
Key: IGNITE-8595
URL: https://issues.apache.org/jira/browse/IGNITE-8595
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.6
At the moment it is impossible to cancel DDL operations. Suppose that you
started {{CREATE INDEX}} on very heavy table. It took hours to finish, and you
would like to stop it because it is 9:00AM, and users are about to execute many
queries and {{CREATE INDEX}} will slow them down or even block.
It should be possible to stop DDL operations in the same way it is done for
{{SELECT}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8595) SQL: Ability to cancel DDL operations
[
https://issues.apache.org/jira/browse/IGNITE-8595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8595:
Labels: usability (was: )
> SQL: Ability to cancel DDL operations
> -
>
> Key: IGNITE-8595
> URL: https://issues.apache.org/jira/browse/IGNITE-8595
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: usability
> Fix For: 2.6
>
>
> At the moment it is impossible to cancel DDL operations. Suppose that you
> started {{CREATE INDEX}} on very heavy table. It took hours to finish, and
> you would like to stop it because it is 9:00AM, and users are about to
> execute many queries and {{CREATE INDEX}} will slow them down or even block.
> It should be possible to stop DDL operations in the same way it is done for
> {{SELECT}} queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8594) Make error messages in validate_indexes command report more informative
Ivan Rakov created IGNITE-8594:
--
Summary: Make error messages in validate_indexes command report
more informative
Key: IGNITE-8594
URL: https://issues.apache.org/jira/browse/IGNITE-8594
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Rakov
Assignee: Ivan Rakov
Fix For: 2.6
In case index is broken and contains links to missing items in data pages,
validate_indexes command will show "Item not found" messages in report:
{noformat}
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 65
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 15
SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
60
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
15
{noformat}
It would be better to explain what is happening: key is present in SQL index,
but missing in corresponding data page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8594) Make error messages in validate_indexes command report more informative
[
https://issues.apache.org/jira/browse/IGNITE-8594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-8594:
---
Description:
In case index is broken and contains links to missing items in data pages,
validate_indexes command will show "Item not found" messages in report:
{noformat}
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 65
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 15
SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
60
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
15
{noformat}
It would be better to explain what is happening: key is present in SQL index,
but is missing in corresponding data page.
was:
In case index is broken and contains links to missing items in data pages,
validate_indexes command will show "Item not found" messages in report:
{noformat}
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 65
IndexValidationIssue [key=null, cacheName=cache_group_1_028, idxName=_key_PK],
class java.lang.IllegalStateException: Item not found: 15
SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
60
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
65
IndexValidationIssue [key=null, cacheName=cache_group_1_028,
idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not found:
15
{noformat}
It would be better to explain what is happening: key is present in SQL index,
but missing in corresponding data page.
> Make error messages in validate_indexes command report more informative
> ---
>
> Key: IGNITE-8594
> URL: https://issues.apache.org/jira/browse/IGNITE-8594
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.6
>
>
> In case index is broken and contains links to missing items in data pages,
> validate_indexes command will show "Item not found" messages in report:
> {noformat}
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=_key_PK], class java.lang.IllegalStateException: Item not found: 15
> SQL Index [cache=cache_group_1_028, idx=LONG__VAL_IDX]
> ValidateIndexesPartitionResult [consistentId=node2, sqlIdxName=LONG__VAL_IDX]
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 60
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 65
> IndexValidationIssue [key=null, cacheName=cache_group_1_028,
> idxName=LONG__VAL_IDX], class java.lang.IllegalStateException: Item not
> found: 15
> {noformat}
> It would be better to explain what is happening: key is present in SQL index,
> but is missing in corresponding data page.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8591) SQL: Sort links on index pages in physical page order before row access
[ https://issues.apache.org/jira/browse/IGNITE-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8591: Labels: performance (was: ) > SQL: Sort links on index pages in physical page order before row access > --- > > Key: IGNITE-8591 > URL: https://issues.apache.org/jira/browse/IGNITE-8591 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.6 > > > When index page match condition, we eagerly read all matched data rows. This > leads to a number of random disk reads.as Ignite use heap-organized storage. > We can pre-sort all matched row links in accordance to their physical > location, and then read them in batch. This will give us two important > advantages: > 1) Data reads will be more sequential, this is especially important for HDDs > 2) This could decrease number of page reads in case of dense data placement, > because there will be less evictions. > In future we should expand this optimization to several index pages in the > same way it is done in major databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8591) SQL: Sort links on index pages in physical page order before row access
[ https://issues.apache.org/jira/browse/IGNITE-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8591: Description: When index page match condition, we eagerly read all matched data rows. This leads to a number of random disk reads.as Ignite use heap-organized storage. We can pre-sort all matched row links in accordance to their physical location, and then read them in batch. This will give us two important advantages: 1) Data reads will be more sequential, this is especially important for HDDs 2) This could decrease number of page reads in case of dense data placement, because there will be less evictions. In future we should expand this optimization to several index pages in the same way it is done in major databases. > SQL: Sort links on index pages in physical page order before row access > --- > > Key: IGNITE-8591 > URL: https://issues.apache.org/jira/browse/IGNITE-8591 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.6 > > > When index page match condition, we eagerly read all matched data rows. This > leads to a number of random disk reads.as Ignite use heap-organized storage. > We can pre-sort all matched row links in accordance to their physical > location, and then read them in batch. This will give us two important > advantages: > 1) Data reads will be more sequential, this is especially important for HDDs > 2) This could decrease number of page reads in case of dense data placement, > because there will be less evictions. > In future we should expand this optimization to several index pages in the > same way it is done in major databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8593) The semaphore's isBroken function doesn't work properly.
Mo created IGNITE-8593:
--
Summary: The semaphore's isBroken function doesn't work properly.
Key: IGNITE-8593
URL: https://issues.apache.org/jira/browse/IGNITE-8593
Project: Ignite
Issue Type: Bug
Components: data structures
Affects Versions: 2.4
Reporter: Mo
Scenario: Three servers (s1,s2,s3) two clients (c1,c2).
A semaphore with one permit is created.
Config: {{Release acquired permits if node, that owned them, left topology: set
to false}}
# c2 acquires the permit.
# Network failure happens, isolating c2 from the rest of nodes for a period of
time.
# Network heals.
# c2 releases the permit.
# c2 acquires the permit.
# Calling semaphore.isBroken() returns false on both c1 and c2.
# c1 tries to acquire the permit but fails.
# Now calling isBroken() returns true on both c1 and c2.
I think isBroken() should return true before a client tries to acquire a
permit, and then fails (i.e., in step 6) rather than after acquiring a permit
fails, as in the latter case, what purpose does the isBroken() function serves?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8592) Network partitions lead to two independent clusters
Mo created IGNITE-8592:
--
Summary: Network partitions lead to two independent clusters
Key: IGNITE-8592
URL: https://issues.apache.org/jira/browse/IGNITE-8592
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Mo
Creating a network partition in a replicated Ignite cluster leads to creating
two independent clusters, each of which would operate independently from the
other, even after the network partition is healed.
Setup: 3 servers (s1,s2,s3) two clients (c1,c2).
A partition created \{(s1,s2,c1),(s3,c2)}.
--> At this point two independent clusters form; one containing s1 and s2,
while the other containing s3. The two never rejoin even after the partition is
healed.
This creates different kinds of problems for the different data structure
ignite provides, such as the cache (stale reads, and data unavailability),
atomic types (atomicref and long ) ... etc.
These are the settings used for the replicated cache:
cfg.setCacheMode(CacheMode.REPLICATED);
cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
cfg.setReadFromBackup(false);
cfg.setPartitionLossPolicy(PartitionLossPolicy.READ_ONLY_SAFE);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
