[jira] [Resolved] (IGNITE-1201) Create tests for Web Console Agent
[ https://issues.apache.org/jira/browse/IGNITE-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-1201. Resolution: Fixed > Create tests for Web Console Agent > -- > > Key: IGNITE-1201 > URL: https://issues.apache.org/jira/browse/IGNITE-1201 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Sergey Evdokimov >Assignee: Andrey Novikov >Priority: Major > Attachments: ignite-843_4abc9f1_ignite-1201.patch > > > Need tests for Web Control Center Agent. > Tests should simulate Web Control Center requests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-1201) Create tests for Web Console Agent
[ https://issues.apache.org/jira/browse/IGNITE-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-1201. -- > Create tests for Web Console Agent > -- > > Key: IGNITE-1201 > URL: https://issues.apache.org/jira/browse/IGNITE-1201 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Sergey Evdokimov >Assignee: Andrey Novikov >Priority: Major > Attachments: ignite-843_4abc9f1_ignite-1201.patch > > > Need tests for Web Control Center Agent. > Tests should simulate Web Control Center requests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4596) Web console: Add flag to disable demo cluster on agent.
[ https://issues.apache.org/jira/browse/IGNITE-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-4596: -- Assignee: (was: Andrey Novikov) > Web console: Add flag to disable demo cluster on agent. > --- > > Key: IGNITE-4596 > URL: https://issues.apache.org/jira/browse/IGNITE-4596 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 1.8 >Reporter: Andrey Novikov >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5737) Web Console: make cluster a root configuration entity
[ https://issues.apache.org/jira/browse/IGNITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-5737: - Fix Version/s: 2.7 > Web Console: make cluster a root configuration entity > - > > Key: IGNITE-5737 > URL: https://issues.apache.org/jira/browse/IGNITE-5737 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > > It has been agreed upon to make cluster a root entity for configuration > screens. That means that all caches/igfs/models will not be shared among > clusters and be owned by a single cluster instead of current many to many > relation. > Backend requirements: > 1. Implement REST endpoints to manage clusters. > Frontend requirements: > 1. Remove cluster selection from cluster edit screens. > 2. Remove cluster selection from basic/caches/igfss/models screens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527159#comment-16527159 ] Alexey Kuznetsov commented on IGNITE-8519: -- Looks good. Merged to master. > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, image-2018-06-28-15-22-23-245.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8519. > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, image-2018-06-28-15-22-23-245.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-8519: - Fix Version/s: 2.7 > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.7 > > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, image-2018-06-28-15-22-23-245.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5737) Web Console: make cluster a root configuration entity
[ https://issues.apache.org/jira/browse/IGNITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-5737. -- > Web Console: make cluster a root configuration entity > - > > Key: IGNITE-5737 > URL: https://issues.apache.org/jira/browse/IGNITE-5737 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > > It has been agreed upon to make cluster a root entity for configuration > screens. That means that all caches/igfs/models will not be shared among > clusters and be owned by a single cluster instead of current many to many > relation. > Backend requirements: > 1. Implement REST endpoints to manage clusters. > Frontend requirements: > 1. Remove cluster selection from cluster edit screens. > 2. Remove cluster selection from basic/caches/igfss/models screens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5737) Web Console: make cluster a root configuration entity
[ https://issues.apache.org/jira/browse/IGNITE-5737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16527158#comment-16527158 ] Andrey Novikov commented on IGNITE-5737: Reviewed. Looks good. Merged to master > Web Console: make cluster a root configuration entity > - > > Key: IGNITE-5737 > URL: https://issues.apache.org/jira/browse/IGNITE-5737 > Project: Ignite > Issue Type: Sub-task > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > > It has been agreed upon to make cluster a root entity for configuration > screens. That means that all caches/igfs/models will not be shared among > clusters and be owned by a single cluster instead of current many to many > relation. > Backend requirements: > 1. Implement REST endpoints to manage clusters. > Frontend requirements: > 1. Remove cluster selection from cluster edit screens. > 2. Remove cluster selection from basic/caches/igfss/models screens. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-5476) Web Console: backend API updates for basic configuration
[
https://issues.apache.org/jira/browse/IGNITE-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov closed IGNITE-5476.
--
> Web Console: backend API updates for basic configuration
>
>
> Key: IGNITE-5476
> URL: https://issues.apache.org/jira/browse/IGNITE-5476
> Project: Ignite
> Issue Type: Task
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Major
>
> New basic layout page will benefit greatly from several change at the backend
> level:
> 1. Remove caches to clusters two-side relation.
> 2. Add a new API method that will create/update cluster and it's caches. It
> will accept a {cluster: {...}, caches: [...]} object as parameter and will
> throw if any of internal create/update operation fails. This will save a lot
> of involved code that does roughly the same on the frontend.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7294) Web console: show warning on start in case of wrong version of MongoDb installed on host
[ https://issues.apache.org/jira/browse/IGNITE-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-7294: -- Assignee: (was: Andrey Novikov) > Web console: show warning on start in case of wrong version of MongoDb > installed on host > > > Key: IGNITE-7294 > URL: https://issues.apache.org/jira/browse/IGNITE-7294 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > Currently, we have no verification of version of MongoDB it may lead to > various issues at runtime. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8539) Web Console: add additional checks to prevent unauthorized web-socket connection.
[ https://issues.apache.org/jira/browse/IGNITE-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-8539. Resolution: Won't Fix I think this was already fixed. > Web Console: add additional checks to prevent unauthorized web-socket > connection. > - > > Key: IGNITE-8539 > URL: https://issues.apache.org/jira/browse/IGNITE-8539 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.7 > > > We should add additional check to prevent unauthorized web-socket connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8539) Web Console: add additional checks to prevent unauthorized web-socket connection.
[ https://issues.apache.org/jira/browse/IGNITE-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8539. -- > Web Console: add additional checks to prevent unauthorized web-socket > connection. > - > > Key: IGNITE-8539 > URL: https://issues.apache.org/jira/browse/IGNITE-8539 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.7 > > > We should add additional check to prevent unauthorized web-socket connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8081) Document Kubernetes RBAC configuration to avoid 403 exception
[ https://issues.apache.org/jira/browse/IGNITE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526728#comment-16526728 ] Denis Magda commented on IGNITE-8081: - In progress: https://apacheignite.readme.io/v2.5/docs/rbac-authorization > Document Kubernetes RBAC configuration to avoid 403 exception > - > > Key: IGNITE-8081 > URL: https://issues.apache.org/jira/browse/IGNITE-8081 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Denis Magda >Priority: Critical > Fix For: 2.7 > > > It's reported by the users that sometimes Ignite Kubernetes IP finder fails > to join the cluster due to security issues. To prevent the exception > happening we need to document how to set up a Service Account for Ignite pods: > https://stackoverflow.com/questions/49395481/how-to-setmasterurl-in-ignite-xml-config-for-kubernetes-ipfinder/49405879#49405879 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526622#comment-16526622
]
Evgenii Zhuravlev commented on IGNITE-8426:
---
Here is the new TC run for this suite and it looks good:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=pull%2F4249%2Fhead=buildTypeStatusDiv
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7782) Thin Client lib: Python
[ https://issues.apache.org/jira/browse/IGNITE-7782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526591#comment-16526591 ] ASF GitHub Bot commented on IGNITE-7782: GitHub user dmelnichuk opened a pull request: https://github.com/apache/ignite/pull/4278 IGNITE-7782 Thin Client lib: Python (initial implementation) Please review this preliminary version of Ignite binary API client library, written in Python 3. What is done: - all API operations implemented, - code is mostly tested (pytest, ~90% covered), - setuptools integration, 100% PyPI-ready, - documentation provided (Sphinx/autodoc). What is **not** yet done: - complex object datatype support, - authentication and authorization support, - throughly tested SQL operations, - improved data checking and error reporting, - … Tested with Python 3.4 and 3.6, Ignite 2.5. You can merge this pull request into a Git repository by running: $ git pull https://github.com/nobitlost/ignite ignite-7782 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4278.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 #4278 commit 4b444dff62c04b97bc2cdb0676ad52880374 Author: ekaterina-nbl Date: 2018-03-20T21:12:21Z initial implementation commit d1e8014c80f698028d23e09cafd7ea190ac3e929 Author: ekaterina-nbl Date: 2018-03-20T21:32:52Z initial implementation commit f79229e233ffa7bff1e7c22f04749924af6d712a Author: ekaterina-nbl Date: 2018-03-22T09:39:32Z initial implementation commit 658d60b58840080b664e02815f4ba6aac76e5804 Author: ekaterina-nbl Date: 2018-03-22T16:52:18Z minor update commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb Author: ekaterina-nbl Date: 2018-03-25T13:33:27Z api spec commit d9729585f5a901977e2a2e40e86a2b715fab79fa Author: alexey-nbl Date: 2018-03-25T21:27:11Z link to api_spec added commit ea847eba62e556fa81cbf9838ffe17af60f464e4 Author: ekaterina-nbl Date: 2018-03-31T22:07:50Z error types modified commit c2ad53fe625cc3a05155eeef318421538830 Author: ekaterina-nbl Date: 2018-03-31T23:41:56Z client states commit 6d2233864b4d891361d38a7143846570bd6c0ef6 Author: ekaterina-nbl Date: 2018-04-01T13:11:27Z object types improvement commit 52fbc5f87143da068596141cb59b17b684fd2c1f Author: ekaterina-nbl Date: 2018-04-02T16:59:52Z complex objects commit cae5a28e7e0d610434debcc140738e2f48d061cf Author: ekaterina-nbl Date: 2018-04-02T20:13:00Z object types improvement commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d Author: ekaterina-nbl Date: 2018-04-02T21:21:26Z client states commit fdbb8f86b32fe4c038d38620a80921be3038f31f Author: alexey-nbl Date: 2018-04-03T08:26:04Z Ignite client states described commit 04b946885db0ea2f6fe56a75e28302641dad5f61 Author: alexey-nbl Date: 2018-04-03T09:35:49Z minor update commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e Author: alexey-nbl Date: 2018-04-03T12:47:54Z Update ObjectType.js commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa Author: ekaterina-nbl Date: 2018-04-03T13:46:19Z minor updates + api spec commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd Author: alexey-nbl Date: 2018-04-04T14:34:52Z Update ObjectType.js commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2 Author: alexey-nbl Date: 2018-04-04T15:14:00Z Update ObjectType.js commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67 Author: ekaterina-nbl Date: 2018-04-08T17:16:43Z sql queries, key value ops commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65 Author: alexey-nbl Date: 2018-04-08T18:31:47Z Update IgniteClient.js commit 04137bf5ec3b7077e194edd0100a01bb43f7933a Author: alexey-nbl Date: 2018-04-08T18:37:04Z Update CacheConfiguration.js commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3 Author: alexey-nbl Date: 2018-04-08T19:11:11Z Update ObjectType.js commit 756b908c9dc38ae497e4d7d740f836dabed93e48 Author: alexey-nbl Date: 2018-04-08T22:41:54Z Update CacheClient.js commit e96ffee17298dd25d26a7029738132478271cf92 Author: ekaterina-nbl Date: 2018-04-08T23:23:33Z object array, minor updates commit c050e671f74232c4efc41f51c2018d08b152cbbc Author: alexey-nbl Date: 2018-04-09T21:04:35Z Update CacheClient.js commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2 Author: alexey-nbl Date: 2018-04-09T22:43:50Z Update ObjectType.js commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4 Author: alexey-nbl Date: 2018-04-10T11:50:13Z Update CacheClient.js commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2 Author: ekaterina-nbl Date: 2018-04-10T13:21:16Z cache key value operations tests commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99 Author:
[jira] [Commented] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526584#comment-16526584 ] Andrew Mashenkov commented on IGNITE-8892: -- Seems, we can get rid of keepAll flag and allCol collection as most likely noone use future result. TC test looks fine. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-8869: Assignee: Ivan Daschinskiy > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8869) PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-8869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526549#comment-16526549 ] ASF GitHub Bot commented on IGNITE-8869: GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/4277 IGNITE-8869: Retrieves nodes directly from topology history You can merge this pull request into a Git repository by running: $ git pull https://github.com/ivandasch/ignite ignite-8869 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4277.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 #4277 commit 50034302a6ac9ac38a5f347b6f26b0b43715eb39 Author: Ivan Daschinskiy Date: 2018-06-26T15:10:58Z IGNITE-8869: Explicitly fail hanging test. commit e28fb94ad1add6484ba474ca4e3d8756df50700e Author: Ivan Daschinskiy Date: 2018-06-28T10:25:02Z Merge branch 'master' into ignite-8869 commit 80bb9084251d11f95b90bdfc94929083be40aa87 Author: Ivan Daschinskiy Date: 2018-06-28T17:02:18Z IGNITE-8869: Retrieve nodes without discoveryCache. > PartitionsExchangeOnDiscoveryHistoryOverflowTest hangs on TeamCity > -- > > Key: IGNITE-8869 > URL: https://issues.apache.org/jira/browse/IGNITE-8869 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Ivan Daschinskiy >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.7 > > > After introduction of ExhangeLatches, > PartitionsExchangeOnDiscoveryHistoryOverflowTest will hangs permanently. In > current implementation, ExchangeLatchManager retrieves alive nodes from > discoveryCache with specific affinity topology version and fails because of a > too short discovery history. This causes fail of exchange-worker and > therefore NoOpFailureHandler leaves node in hanging state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8738) Improve coordinator change information
[
https://issues.apache.org/jira/browse/IGNITE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526548#comment-16526548
]
Alexey Goncharuk commented on IGNITE-8738:
--
[~ezagumennov], I think it would be useful if the output will be consistent on
all nodes. Currently, if nodes leave grid in parallel, node A may print
coordinator change C1->C2->C3 for topology events E2, E3, while some other node
may print coordinator.
Please add a method {{oldestServerNode}} to disco cache which will be similar
to {{oldestAliveServerNode}}, but it should not filter nodes by alive flag and
use it in the print output.
> Improve coordinator change information
> --
>
> Key: IGNITE-8738
> URL: https://issues.apache.org/jira/browse/IGNITE-8738
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Evgenii Zagumennov
>Priority: Major
>
> When topology changes and coordinator is also changed, we need to print out
> this alongside with topology information.
> An example of such message:
> {{Coordinator changed [prev=node.tostring(), cur=node.tostr()]}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526526#comment-16526526
]
Ryabov Dmitrii commented on IGNITE-2313:
[~agoncharuk], it throws exception only inside transaction, so to use it we
must call {{withAllowAtomicOpsInTx}} before transaction.
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reopened IGNITE-2313:
--
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526494#comment-16526494
]
Alexey Goncharuk commented on IGNITE-2313:
--
[~SomeFire], apparently, the change does not work - the method
{{withAllowAtomicOpsInTx}} itself throws an exception if it is called on an
atomic cache.
Can you estimate how long a fix will take? If it takes more than a day, I will
have to revert the change.
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.7
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8895) Update yardstick libraries
Dmitry Sherstobitov created IGNITE-8895: --- Summary: Update yardstick libraries Key: IGNITE-8895 URL: https://issues.apache.org/jira/browse/IGNITE-8895 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Dmitry Sherstobitov There is some conflicts in yardstick libraries for now ||yardstick||core||problem|| |jline-0.9.94.jar|bin/include/sqlline/jline-2.4.3.jar|./sqlline.sh unable to start if yardstick libraries in path| -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8823) Incorrect transaction state in tx manager
[
https://issues.apache.org/jira/browse/IGNITE-8823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526490#comment-16526490
]
Andrey Kuznetsov commented on IGNITE-8823:
--
{{IgfsAbstractSelfTest#testCreateConsistencyMultithreaded}} cannot pass due to
an assertion failure in {{IgniteTxManager.removeTxReturn}}. The resolution of
[1] revealed the failure previously masked since the moment when the test was
reenabled, see [2]. Possible values that break the assertion are
{{Boolean.TRUE}} and {{null}}. Failures are flaky but frequent enough on master
currently.
[1] https://issues.apache.org/jira/browse/IGNITE-8789
[2] https://issues.apache.org/jira/browse/IGNITE-3998
> Incorrect transaction state in tx manager
> -
>
> Key: IGNITE-8823
> URL: https://issues.apache.org/jira/browse/IGNITE-8823
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
>
> Reproducable by test
> {{org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest#testCreateConsistencyMultithreaded}}:
> {noformat}
> 18:34:40,701][SEVERE][sys-stripe-0-#44%ignite%][GridCacheIoManager] Failed
> processing message [senderId=e273c3f8-02ed-4201-9ac8-09f9ab6a1d31,
> msg=GridNearTxPrepareResponse [pending=[],
> futId=b4df8831461-9735f9d5-79a0-47a3-a951-e62a03af71ef, miniId=1,
> dhtVer=GridCacheVersion [topVer=140816081, order=1529336085358, nodeOrder=3],
> writeVer=GridCacheVersion [topVer=140816081, order=1529336085360,
> nodeOrder=3], ownedVals=null, retVal=GridCacheReturn [v=null, cacheObj=null,
> success=true, invokeRes=true, loc=true, cacheId=0], clientRemapVer=null,
> super=GridDistributedTxPrepareResponse
> [txState=IgniteTxImplicitSingleStateImpl [init=true, recovery=false],
> part=-1, err=null, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=140816081, order=1529336085224, nodeOrder=1], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0]
> java.lang.AssertionError: true instead of GridCacheReturnCompletableWrapper
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1098)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.ackBackup(GridNearTxFinishFuture.java:533)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:500)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:310)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:288)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:78)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
>
[jira] [Commented] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs
[
https://issues.apache.org/jira/browse/IGNITE-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526468#comment-16526468
]
Andrey Aleksandrov commented on IGNITE-7119:
[~kuaw26] Could you please add the information about this to readme.io? Looks
like it wasn't done.
> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8858) Client node may not stop
[
https://issues.apache.org/jira/browse/IGNITE-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526461#comment-16526461
]
Alexey Goncharuk commented on IGNITE-8858:
--
I've triggered a full TC re-run.
> Client node may not stop
>
>
> Key: IGNITE-8858
> URL: https://issues.apache.org/jira/browse/IGNITE-8858
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Karachentsev
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.7
>
>
> There is possible case when client node is not stopped and blocked on waiting
> when SocketReader will be completed. Looks like interruption was lost, and
> the only place where it could happen is in unmarshaling message from input
> stream.
> The way to overcome/fix it is to check if InterruptedException was in cause
> of IgniteCheckedException and repeatedly interrupt reader on stop.
>
> {noformat}
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1245)
> - locked <0x00041016a140> (a
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader)
> at java.lang.Thread.join(Thread.java:1319)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4604)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStop(ClientImpl.java:315)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStop(TcpDiscoverySpi.java:2061)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.stopSpi(GridManagerAdapter.java:330)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.stop(GridDiscoveryManager.java:1608)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2216)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x000410065e80> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:365)
> at org.apache.ignite.Ignition.stop(Ignition.java:229)
> at org.apache.ignite.internal.IgniteKernal.close(IgniteKernal.java:3417)
> "tcp-client-disco-sock-reader-#35%Default%" #746 prio=5 os_prio=0
> tid=0x7f6090561800 nid=0x3441 in Object.wait() [0x7f60f23d8000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$SocketReader.body(ClientImpl.java:1006)
> - locked <0x00041016a2e0> (a java.lang.Object)
> 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-8493) GridToStringBuilder fails with NPE deals with primitive arrays operations.
[
https://issues.apache.org/jira/browse/IGNITE-8493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526456#comment-16526456
]
Alexey Goncharuk commented on IGNITE-8493:
--
[~zstan], note that with your fix the array length is limited, but the user has
no clue that the array was cut. I think you should add {{... and X more}} to
the array print output if the array length is cut.
> GridToStringBuilder fails with NPE deals with primitive arrays operations.
> --
>
> Key: IGNITE-8493
> URL: https://issues.apache.org/jira/browse/IGNITE-8493
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.7
>
>
> GridToStringBuilder#arrayToString fails with NPE, if input is a primitive
> array.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526457#comment-16526457
]
Evgenii Zhuravlev commented on IGNITE-8426:
---
[~EdShangGG], Thank you for your review! I will re-run TC again after changes
and check it
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526455#comment-16526455
]
Eduard Shangareev commented on IGNITE-8426:
---
Looks good for me. Thank you, [~ezhuravl].
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8619) 'Remote node could not start' in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526445#comment-16526445 ] Peter Ivanov commented on IGNITE-8619: -- [~ivanan.fed], I'm sorry I'm not good at Java. Can you show what exact command is constructed [here|https://github.com/apache/ignite/blob/219bc81b730ea3ba078b61f96c9dab354496c22b/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L257]? > 'Remote node could not start' in ssh connection > --- > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8860) IgniteDiscoveryThread marker interface should be restored on RingMessageWorker class
[ https://issues.apache.org/jira/browse/IGNITE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526443#comment-16526443 ] Alexey Goncharuk commented on IGNITE-8860: -- Re-checked the tests, look good to me. Merged to master. > IgniteDiscoveryThread marker interface should be restored on > RingMessageWorker class > > > Key: IGNITE-8860 > URL: https://issues.apache.org/jira/browse/IGNITE-8860 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Sergey Chugunov >Assignee: Andrey Kuznetsov >Priority: Major > Fix For: 2.7 > > > It seems that *IgniteDiscoveryThread* interface was removed from > *ServerImpl.RingMessageWorker* class. > It should be restored as it is used to prevent deadlocks on updates of > BinaryMetadata. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526434#comment-16526434
]
Evgenii Zhuravlev commented on IGNITE-8426:
---
[~agoncharuk], added stopping of LongJVMPauseDetector on node stop
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8894) Provide information about coordinator in control.sh output
[ https://issues.apache.org/jira/browse/IGNITE-8894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-8894: --- Fix Version/s: 2.7 > Provide information about coordinator in control.sh output > -- > > Key: IGNITE-8894 > URL: https://issues.apache.org/jira/browse/IGNITE-8894 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.7 > > > Information about coordinator can be added in an existing command (i.e. > --state, --baseline) > either a new command can be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8894) Provide information about coordinator in control.sh output
[ https://issues.apache.org/jira/browse/IGNITE-8894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev updated IGNITE-8894: --- Affects Version/s: 2.5 > Provide information about coordinator in control.sh output > -- > > Key: IGNITE-8894 > URL: https://issues.apache.org/jira/browse/IGNITE-8894 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.7 > > > Information about coordinator can be added in an existing command (i.e. > --state, --baseline) > either a new command can be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8894) Provide information about coordinator in control.sh output
Sergey Kosarev created IGNITE-8894: -- Summary: Provide information about coordinator in control.sh output Key: IGNITE-8894 URL: https://issues.apache.org/jira/browse/IGNITE-8894 Project: Ignite Issue Type: Improvement Reporter: Sergey Kosarev Assignee: Sergey Kosarev Information about coordinator can be added in an existing command (i.e. --state, --baseline) either a new command can be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8619) 'Remote node could not start' in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526418#comment-16526418 ] Ivan Fedotov edited comment on IGNITE-8619 at 6/28/18 3:22 PM: --- [~vveider], I tested locally several hundred times and tests were green until ssh disconnected per timeout, so I made a conclusion that problem may be with TC enviroment. I think that we can be on 100% sure or not, when we change timeout on one agent and run test on this agent on TC for several hundred times. P.S. Remote node starts via shell command in StartNodeCallableImpl [class|https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L269]. was (Author: ivanan.fed): [~vveider], I tested locally several hundred times and tests were green until ssh disconnected per timeout, so I made a conclusion that problem may be with TC enviroment. I think that we can be on 100% sure or not, when we change timeout on one agent and run test on this agent on TC for several hundred times. P.S. Remote node starts via shell command in StartNodeCallableImpl class [1]. [1]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L269 > 'Remote node could not start' in ssh connection > --- > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8619) 'Remote node could not start' in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526418#comment-16526418 ] Ivan Fedotov edited comment on IGNITE-8619 at 6/28/18 3:20 PM: --- [~vveider], I tested locally several hundred times and tests were green until ssh disconnected per timeout, so I made a conclusion that problem may be with TC enviroment. I think that we can be on 100% sure or not, when we change timeout on one agent and run test on this agent on TC for several hundred times. P.S. Remote node starts via shell command in StartNodeCallableImpl class [1]. [1]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L269 was (Author: ivanan.fed): [~vveider], I tested locally several hundred times and tests were green until ssh disconnected per timeout, so I made a conclusion that problem may be with TC enviroment. I think that we can be on 100% sure or not, when we change timeout on one agent and run test on this agent on TC for several hundred times. P.S. Remote node starts via shell command in StartNodeCallableImpl class [1]. [1]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L269 > 'Remote node could not start' in ssh connection > --- > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8619) 'Remote node could not start' in ssh connection
[ https://issues.apache.org/jira/browse/IGNITE-8619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526418#comment-16526418 ] Ivan Fedotov commented on IGNITE-8619: -- [~vveider], I tested locally several hundred times and tests were green until ssh disconnected per timeout, so I made a conclusion that problem may be with TC enviroment. I think that we can be on 100% sure or not, when we change timeout on one agent and run test on this agent on TC for several hundred times. P.S. Remote node starts via shell command in StartNodeCallableImpl class [1]. [1]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L269 > 'Remote node could not start' in ssh connection > --- > > Key: IGNITE-8619 > URL: https://issues.apache.org/jira/browse/IGNITE-8619 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > > Now there is a problem with launch remote node via ssh. Initially was an > assumption that it's due to remote process has not enough time to write > information into log: > [IGNITE-8085|https://issues.apache.org/jira/browse/IGNITE-8085]. But this > correction didn't fix [TeamCity > |https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=testDetails]. > > So it's necessary to make launch remote node via ssh always succesful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526409#comment-16526409
]
Evgenii Zhuravlev commented on IGNITE-8426:
---
[~EdShangGG] Here is the TC run with this test:
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Basic1_IgniteTests24Java8=pull%2F4249%2Fhead=buildTypeStatusDiv
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526407#comment-16526407
]
Alexey Goncharuk commented on IGNITE-8426:
--
[~ezhuravl], after your fix, if I start and shut down Ignite nodes in a loop, I
will end up with multiple daemon threads started, but not stopped, each of them
printing out the same output to the log + this is a major resource leak in
tests.
Please fix the thread lifecycle.
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8495) CPP Thin: Implement thin client start and connection establishment
[ https://issues.apache.org/jira/browse/IGNITE-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526402#comment-16526402 ] Igor Sapego commented on IGNITE-8495: - Fixed. > CPP Thin: Implement thin client start and connection establishment > -- > > Key: IGNITE-8495 > URL: https://issues.apache.org/jira/browse/IGNITE-8495 > Project: Ignite > Issue Type: Sub-task > Components: platforms >Affects Versions: 2.4 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > > Need to implement basic functionality for C++ thin client - configuration, > starting, connection to server, handshake. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8893) Blinking node in baseline may corrupt own WAL records
Dmitry Sherstobitov created IGNITE-8893:
---
Summary: Blinking node in baseline may corrupt own WAL records
Key: IGNITE-8893
URL: https://issues.apache.org/jira/browse/IGNITE-8893
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Dmitry Sherstobitov
# Start cluster, load data
# Start additional node that not in BLT
# Repeat 10 times: kill 1 node in baseline and 1 node not in baseline, start
node in blt and node not in BLT
Node in baseline in some moment may unable to start because of corrupted WAL:
Notice that there is no loading on cluster at all - so there is no reason to
corrupt WAL, rebalance should be interruptible.
Also there is another scenario that may case same error (but also may cause JVM
crash)
# Start cluster, load data, start nodes
# Repeat 10 times: kill 1 node in baseline, clean LFS, start node again, while
rebalance blink node that should rebalance data to previously killed node
Node that should rebalance data to cleaned node may corrupt own WAL. But this
second scenario has configuration "error" - number of backups in each case is
1. So obviously 2 nodes blinking actually may cause data loss.
{code:java}
[2018-06-28 17:33:39,583][ERROR][wal-file-archiver%null-#63][root] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler,
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.AssertionError: lastArchived=757, current=42]]
java.lang.AssertionError: lastArchived=757, current=42
at
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileArchiver.body(FileWriteAheadLogManager.java:1629)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8014) Node.js client: basic/minimal version
[ https://issues.apache.org/jira/browse/IGNITE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kosenchuk resolved IGNITE-8014. -- Resolution: Fixed > Node.js client: basic/minimal version > - > > Key: IGNITE-8014 > URL: https://issues.apache.org/jira/browse/IGNITE-8014 > Project: Ignite > Issue Type: Sub-task > Components: thin client >Reporter: Alexey Kosenchuk >Assignee: Alexey Kosenchuk >Priority: Major > > Develop the first basic/minimal version - for initial review/feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8203) Interrupting task can cause node fail with PersistenceStorageIOException.
[ https://issues.apache.org/jira/browse/IGNITE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526379#comment-16526379 ] Sergey Chugunov commented on IGNITE-8203: - [~alex_pl], I reviewed new implementation, it looks logical to me. If [~agoncharuk] and/or [~ivan.glukos] don't have other comments we should proceed with merging. > Interrupting task can cause node fail with PersistenceStorageIOException. > -- > > Key: IGNITE-8203 > URL: https://issues.apache.org/jira/browse/IGNITE-8203 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Ivan Daschinskiy >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.7 > > Attachments: GridFailNodesOnCanceledTaskTest.java > > > Interrupting task with simple cache operations (i.e. get, put) can cause > PersistenceStorageIOException. Main cause of this failure is lack of proper > handling InterruptedException in FilePageStore.init() etc. This cause a throw > of ClosedByInterruptException by FileChannel.write() and so on. > PersistenceStorageIOException is a critical failure and typically makes a > node to stop. As a workaround, I would suggest to enable AsyncFileIO by > default until the fix was available. > A reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov reassigned IGNITE-8892: Assignee: Andrew Mashenkov > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-4718) Add section in documentation on what actions may cause deadlock
[ https://issues.apache.org/jira/browse/IGNITE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-4718: --- Assignee: (was: Denis Magda) > Add section in documentation on what actions may cause deadlock > --- > > Key: IGNITE-4718 > URL: https://issues.apache.org/jira/browse/IGNITE-4718 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 1.8 >Reporter: Dmitry Karachentsev >Priority: Minor > Fix For: 2.7 > > > Ignite has number of common cases, where wrong usage of API may lead to > deadlocks, starvations, cluster hangs, and they should be properly > documented. > For example, cache operations is not allowed in CacheEntryProcessor, > ContinuousQuery's remote filter, etc. And in some callbacks it's possible to > use cache API if they annotated with @IgniteAsyncCallback. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-5922) Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than PublicThreadPoolSize
[ https://issues.apache.org/jira/browse/IGNITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-5922: --- Assignee: (was: Denis Magda) > Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than > PublicThreadPoolSize > -- > > Key: IGNITE-5922 > URL: https://issues.apache.org/jira/browse/IGNITE-5922 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Priority: Minor > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7614) Documentation: How to access data from key-value that was inserted from SQL
[ https://issues.apache.org/jira/browse/IGNITE-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526354#comment-16526354 ] Denis Magda commented on IGNITE-7614: - Duplicate of IGNITE-7728 > Documentation: How to access data from key-value that was inserted from SQL > --- > > Key: IGNITE-7614 > URL: https://issues.apache.org/jira/browse/IGNITE-7614 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7614) Documentation: How to access data from key-value that was inserted from SQL
[ https://issues.apache.org/jira/browse/IGNITE-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-7614. --- > Documentation: How to access data from key-value that was inserted from SQL > --- > > Key: IGNITE-7614 > URL: https://issues.apache.org/jira/browse/IGNITE-7614 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7614) Documentation: How to access data from key-value that was inserted from SQL
[ https://issues.apache.org/jira/browse/IGNITE-7614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-7614. - Resolution: Duplicate > Documentation: How to access data from key-value that was inserted from SQL > --- > > Key: IGNITE-7614 > URL: https://issues.apache.org/jira/browse/IGNITE-7614 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Denis Magda >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7556) Docs should feature specifying SQL key more prominently
[
https://issues.apache.org/jira/browse/IGNITE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-7556:
---
Assignee: Artem Budnikov (was: Denis Magda)
> Docs should feature specifying SQL key more prominently
> ---
>
> Key: IGNITE-7556
> URL: https://issues.apache.org/jira/browse/IGNITE-7556
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Ilya Kasnacheev
>Assignee: Artem Budnikov
>Priority: Minor
> Fix For: 2.7
>
>
> Descriptions on [https://apacheignite-sql.readme.io/docs/schema-and-indexes]
> are not DML-friendly
> After reading this page and [https://apacheignite-sql.readme.io/docs/insert],
> one would likely still unable to write working INSERT because there won't be
> primary key in it.
> Their only chance is to spot _key reference in infoblock, or infer usability
> of setKeyFields() with single key type. Both are unlikely, leading to
> questions such as
> [https://stackoverflow.com/questions/48460214/how-do-i-read-data-from-ignite-kv-storage-using-jdbc]
> see {{Key is missing from query}}
> Such problems are hard to debug. They can be avoided if all examples of
> QueryEntities in docs will contain setKeyFields, and INSERT docs page will
> refer to _key field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7728) Put together a doc that shows how to blend SQL with k/v APIs
[ https://issues.apache.org/jira/browse/IGNITE-7728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7728: --- Assignee: Artem Budnikov (was: Denis Magda) > Put together a doc that shows how to blend SQL with k/v APIs > > > Key: IGNITE-7728 > URL: https://issues.apache.org/jira/browse/IGNITE-7728 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Artem Budnikov >Priority: Blocker > Fix For: 2.7 > > > More and more people start blending SQL with key-value APIs in Ignite. > Usually, they create tables/caches with DDL and wish to use key-value later > as well: > [https://stackoverflow.com/questions/48795533/how-do-i-read-data-from-cache-using-javaapi-after-i-put-it-through-jdbc] > https://stackoverflow.com/questions/49834964/mixing-apache-ignite-binaryobject-with-sql-tables/49864396#49864396 > > We already have a project that demonstrates this approach: > [https://github.com/dmagda/ignite_world_demo] > > Put together a doc that points out to it and elaborates on this topic. The > doc needs to explain how tables are mapped to the caches, columns to types as > discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/write-through-when-using-SQL-updates-td29767.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7730) Improve WAL history size documentation
[
https://issues.apache.org/jira/browse/IGNITE-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-7730:
---
Assignee: Artem Budnikov (was: Denis Magda)
> Improve WAL history size documentation
> --
>
> Key: IGNITE-7730
> URL: https://issues.apache.org/jira/browse/IGNITE-7730
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
>
> Until IGNITE-6552 is not implemented, we have only ability to configure WAL
> hist. size in checkpoints.
> It is needed to improve description for this parameter.
> I've added draft notes to wiki
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-Estimatingdiskspace
> about ways how wer can estimate WAL sizes without exact bytes/time
> specification:
> {panel}
> WAL Work max used size: walSegmentSize * walSegments = 640Mb (default)
> in case Default WAL mode - this size is used always,
> in case other modes best case is 1 segment * walSegmentSize
> WAL Work+WAL Archive max size may be estimated by
> 1. average load or
> 2. by maximum size.
> 1st way is applicable if checkpoints are triggered mostly by timer trigger.
> Wal size = 2*Average load(bytes/sec) * trigger interval (sec) * walHistSize
> (number of checkpoints)
> Where 2 multiplier coming from physical & logical WAL Records.
> 2nd way: Checkpoint is triggered by segments max dirty pages percent. Use
> persisted data regions max sizes:
> sum(Max configured DataRegionConfiguration.maxSize) * 75% - est. maximum data
> volume to be writen on 1 checkpoint.
> Overall WAL size (before archiving) = 2* est. data volume * walHistSize = 1,5
> * sum(DataRegionConfiguration.maxSize) * walHistSize
> Note applying WAL compressor may significiantly reduce archive size.
> {panel}
> One more note from [~ivan.glukos] on dev.list we need to include. It is
> answer to question how user can determine if segment from archive folder can
> be safely removed:
> {quote}
> By the way: WAL compression is already implemented that way. If there
> are any ".zip" segments in archive dir, they are free to delete.
> This can be a safe workaround for users who experience lack of free
> space - just delete compressed segments. We should mention it in
> documentation for 2.4 release.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526318#comment-16526318 ] Andrew Mashenkov edited comment on IGNITE-8892 at 6/28/18 2:22 PM: --- So, the issue here is ScanQuery.keepAll to true by default. This bug affects all type of queries. Cache.iterator() works fine as it explicitly disabled keepAll flag. There is no workaround as keepAll flag is internal feature and can't be set from user side. was (Author: amashenkov): So, the issue here is we set ScanQuery.keepAll to true by default. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8718) Documentation about using of the C++ BinaryWriter/BinaryReader should be updated
[
https://issues.apache.org/jira/browse/IGNITE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-8718:
---
Assignee: Artem Budnikov
> Documentation about using of the C++ BinaryWriter/BinaryReader should be
> updated
>
>
> Key: IGNITE-8718
> URL: https://issues.apache.org/jira/browse/IGNITE-8718
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: c++
> Fix For: 2.7
>
>
> The usage that should be documented:
> 1)In case if you get some writer from BinaryWriter then you started writing
> session. Until method close will not be called for this writer you can't get
> another writer.
>
> For example, next code isn't correct:
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session - error
> {code}
> Should be:
>
> {code:java}
> BinaryMapWriter field1Writer = writer.WriteMap int64_t>("field1", MapType::HASH_MAP); //here you start writing session
> //do something
> field1Writer.Close() //here you end writing session
> BinaryMapWriter field2Writer = writer.WriteMap int64_t>("field2", MapType::HASH_MAP); //here you start another writing
> session
> //do something
> field2Writer.Close() //here you end another writing session
> {code}
>
> 2) In case if you get some reader from BinaryWriter then you started reading
> session. Until something will not be read from this reader you can't get
> another reader.
>
> For example, next code isn't correct:
>
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session - error
> {code}
> Should be for example:
> {code:java}
> BinaryMapReader field1Reader = reader.ReadMap int64_t>("field1"); //start reading session
> ...
> field1Reader.GetNext(key, val); //reading done
> ...
> BinaryMapReader field2Reader = reader.ReadMap int64_t>("field2"); //start another read session
> ...
> field2Reader.GetNext(key, val); //reading done
> ...{code}
>
>
>
> In the case of the writer, it looks like expected. In case of the reader, it
> looks a little bit confusing.
>
> These two behaviors should be described in the documentation as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8756) SQL: CREATE/ALTER USER documentation should contain information about case sensitivity of username
[
https://issues.apache.org/jira/browse/IGNITE-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-8756:
---
Assignee: Artem Budnikov
> SQL: CREATE/ALTER USER documentation should contain information about case
> sensitivity of username
> --
>
> Key: IGNITE-8756
> URL: https://issues.apache.org/jira/browse/IGNITE-8756
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, sql
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Labels: doc
> Fix For: 2.7
>
>
> Now documentation contains next:
> https://apacheignite-sql.readme.io/docs/create-user#section-description
> For instance, if {{test}} was set as a username then:
> * You can use {{Test}}, {{TEst}}, {{TEST}} and other combinations from JDBC
> and ODBC.
> * You have to use {{TEST}} as the username from Ignite's native SQL APIs
> designed for Java, .NET and other programming languages.
> But next behavior exists:
> When you create the user in quotes ("test") using SQL as next:
> CREATE USER "test" WITH PASSWORD 'test'
> It will be created as it was set (in this case it will be test)
> If you create the user without quotes (test) using SQL as next:
> CREATE USER test WITH PASSWORD 'test'
> then username will be stored in uppercase (TEST).
> The same situation with ALTER USER.
> The documentation should be updated to clear that SQL supports case sensitive
> data too (using quotas).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8833) IgniteCache.isLocalLocked method has unexpected behivior in case of several nodes started in one JVM in different threads
[
https://issues.apache.org/jira/browse/IGNITE-8833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda reassigned IGNITE-8833:
---
Assignee: Artem Budnikov
> IgniteCache.isLocalLocked method has unexpected behivior in case of several
> nodes started in one JVM in different threads
> -
>
> Key: IGNITE-8833
> URL: https://issues.apache.org/jira/browse/IGNITE-8833
> Project: Ignite
> Issue Type: Bug
> Components: cache, documentation
>Affects Versions: 2.5
>Reporter: Andrey Aleksandrov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: ThreadLockedTest.java
>
>
> According to specification:
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#isLocalLocked-K-boolean-]
> Checks if specified key is locked.This is a local in-VM operation and does
> not involve any network trips or access to persistent storage in any way.
> Parameters:
> {{key}} - Key to check.
> {{byCurrThread}} - If {{true}} method will check that current thread owns a
> lock on this key, other vise will check that any thread on any node owns a
> lock on this key.
> Returns:{{True}} if lock is owned by some node.
> In the attached test we start one node in the main thread and another node
> from the second thread. In second node we take a lock but in main thread
> isLocalLocked shows that no thread held the lock.
> However tryLock works ok. So the behavior of the isLocalLocked method should
> be described in this case or fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526318#comment-16526318 ] Andrew Mashenkov commented on IGNITE-8892: -- So, the issue here is we set ScanQuery.keepAll to true by default. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526303#comment-16526303 ] Andrew Mashenkov commented on IGNITE-8892: -- I've found the root cause. We have a collection that never cleared: GridCacheQueryFutureAdapter.allCol and it is reachable from GC root while GridCacheDistributedQueryFuture is reachable. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526301#comment-16526301
]
Eduard Shangareev commented on IGNITE-8426:
---
Can I see it on some TC Run?
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526296#comment-16526296
]
Roman Guseinov commented on IGNITE-7993:
[~vkulichenko] , thank you. Sure, I will create a reproducer and rise a new
ticket.
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.7
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint
[
https://issues.apache.org/jira/browse/IGNITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526290#comment-16526290
]
Nikolay Izhikov commented on IGNITE-6055:
-
Latest Run All -
https://ci.ignite.apache.org/viewLog.html?buildId=1432235=buildResultsDiv=IgniteTests24Java8_RunAll
> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sql-engine
> Fix For: 2.7
>
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore
> it. First, it affects semantics. E.g., one can insert a string with greater
> length into a cache/table without any problems. Second, it limits efficiency
> of our default configuration. E.g., index inline cannot be applied to
> {{String}} data type as we cannot guess it's length.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526289#comment-16526289
]
Evgenii Zhuravlev edited comment on IGNITE-8426 at 6/28/18 1:03 PM:
[~EdShangGG], There is a config file for JUL in Ignite sources, so, I will need
to remove it for reproducing this error right from source code. I don't think
that it's a good idea. I've implemented another one - added debug message that
LongJVMPauseDetector was started successfully. If we see this message in
GridLogger, then it was configured properly. Please check
LongJVMPauseDetectorTest.
was (Author: ezhuravl):
[~EdShangGG], There is a config file for JUL in Ignite, so, I will need to
remove it for reproducing this error right from source code. I don't think that
it's a good idea. I've implemented another one - added debug message that
LongJVMPauseDetector was started successfully. If we see this message in
GridLogger, then it was configured properly. Please check
LongJVMPauseDetectorTest.
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8426) Some classes creates JavaLogger directly which lead to SEVERE message in logs if JUL config file is missing
[
https://issues.apache.org/jira/browse/IGNITE-8426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526289#comment-16526289
]
Evgenii Zhuravlev commented on IGNITE-8426:
---
[~EdShangGG], There is a config file for JUL in Ignite, so, I will need to
remove it for reproducing this error right from source code. I don't think that
it's a good idea. I've implemented another one - added debug message that
LongJVMPauseDetector was started successfully. If we see this message in
GridLogger, then it was configured properly. Please check
LongJVMPauseDetectorTest.
> Some classes creates JavaLogger directly which lead to SEVERE message in logs
> if JUL config file is missing
> ---
>
> Key: IGNITE-8426
> URL: https://issues.apache.org/jira/browse/IGNITE-8426
> Project: Ignite
> Issue Type: Bug
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Blocker
> Fix For: 2.7
>
>
> Here is the error message:
> SEVERE: Failed to resolve default logging config file:
> config/java.util.logging.properties
> For example, problem code is placed in LongJVMPauseDetector and
> IgniteJdbcDriver classes.
> Reproducer:
> IgniteConfiguration configuration = new IgniteConfiguration();
> configuration.setGridLogger(new
> Slf4jLogger(LoggerFactory.getLogger("ignite")));
> Ignition.start(configuration);
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled
[
https://issues.apache.org/jira/browse/IGNITE-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526276#comment-16526276
]
Valentin Kulichenko commented on IGNITE-7993:
-
[~guseinov], I'm OK with the changes then. Please create the ticket for next
step improvements.
> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.7
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid
> stripedPool thread pool size (must be greater than 0), actual value: 0
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8892: - Description: Seems, iterating over query iterator (ScanQuery at least, but may be other affected as well) on client node cause memory leakage. The use case is quite simple. Start server and client. Put much data into cache, then iterate over all entries via ScanQuery. Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs map contains to many GridCacheDistributedQueryFuture futures. I've put 15kk entries into cache and client failed with OOM after iterating over 10kk entry. In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. We have to check # if these futures removed from map correctly. # we don't create unnecessary futures. PFA repro. was: Seems, iterating over query iterator (ScanQuery at least, but may be other affected as well) on client node cause memory leakage. The use case is quite simple. Start server and client. Put much data into cache, then iterate over all entries via ScanQuery. Looks like Ignite fails with OOM due GridCacheDistributedQueryManager.futs map contains to many GridCacheDistributedQueryFuture futures. I've put 15kk entries into cache and client failed with OOM after iterating over 10kk entry. In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. We have to check # if these futures removed from map correctly. # we don't create unnecessary futures. PFA repro. > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like JVM crashed due to OOM as GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
[ https://issues.apache.org/jira/browse/IGNITE-8892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-8892: - Labels: OutOfMemoryError (was: ) > Iterating over large dataset via ScanQuery can fails with OOME. > --- > > Key: IGNITE-8892 > URL: https://issues.apache.org/jira/browse/IGNITE-8892 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrew Mashenkov >Priority: Critical > Labels: OutOfMemoryError > Fix For: 2.7 > > Attachments: ScanQueryOOM.java > > > Seems, iterating over query iterator (ScanQuery at least, but may be other > affected as well) on client node cause memory leakage. > The use case is quite simple. > Start server and client. Put much data into cache, then iterate over all > entries via ScanQuery. > Looks like Ignite fails with OOM due GridCacheDistributedQueryManager.futs > map contains to many GridCacheDistributedQueryFuture futures. > I've put 15kk entries into cache and client failed with OOM after iterating > over 10kk entry. > In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. > We have to check > # if these futures removed from map correctly. > # we don't create unnecessary futures. > PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8892) Iterating over large dataset via ScanQuery can fails with OOME.
Andrew Mashenkov created IGNITE-8892: Summary: Iterating over large dataset via ScanQuery can fails with OOME. Key: IGNITE-8892 URL: https://issues.apache.org/jira/browse/IGNITE-8892 Project: Ignite Issue Type: Bug Components: cache Reporter: Andrew Mashenkov Fix For: 2.7 Attachments: ScanQueryOOM.java Seems, iterating over query iterator (ScanQuery at least, but may be other affected as well) on client node cause memory leakage. The use case is quite simple. Start server and client. Put much data into cache, then iterate over all entries via ScanQuery. Looks like Ignite fails with OOM due GridCacheDistributedQueryManager.futs map contains to many GridCacheDistributedQueryFuture futures. I've put 15kk entries into cache and client failed with OOM after iterating over 10kk entry. In heapdump I observer 2*10^9 GridCacheDistributedQueryFuture futures. We have to check # if these futures removed from map correctly. # we don't create unnecessary futures. PFA repro. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8888) Possible data loss durring restaring of the nodes with empty pds
[ https://issues.apache.org/jira/browse/IGNITE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduard Shangareev reassigned IGNITE-: - Assignee: Alexey Stelmak > Possible data loss durring restaring of the nodes with empty pds > > > Key: IGNITE- > URL: https://issues.apache.org/jira/browse/IGNITE- > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.7 > > Attachments: reproducer.java > > > Case: > 1)Start 3 data nodes and activate the cluster with cache with 1 backup and > PartitionLossPolicy.READ_ONLY_SAFE. > 2)Start client and add the data to your cache. Stop the client > 3)Stop DN2 and clear it pds and val > 4)Start DN2. Rebalance will start. > 5)During rebalance stop DN3. > 6)Start DN3. > At this moment some partitions from DN2 marked as LOST and cache size will be > less than expected. > 7) Run resetLostPartitions(caches). > Now all partitions on DN2 marked as OWNING but cache size is still less than > expected. > Workaround: > after step 6 do: > 7)force rebalance using deactivate/activate methods. > 8)wait for completion of rebalance > Now cache size is expected but some partitions from DN2 marked as LOST > 9)Run resetLostPartitions(caches). > Now cache size is OK and all partitions from DN2 marked as OWNING. > However, looks like without force rebalance we have data loss here. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526192#comment-16526192
]
Anton Vinogradov commented on IGNITE-640:
-
[~aakhmedov]
1) gate.enter() operates on readLock, which means it guarantee that all
operations will be finished before we'll perform some critical operation with
writeLock.
2) Better case is to use structures I listed as is.
I expect no changes at these classes, except names.
Even having that IGNITE-7823 almost ready to be merged I think that we can
rename classes as a part of this issue, this should not cause real problems at
merge.
3) Since we decided how to fix IGNITE-5553 it's a good idea to "merge" Multimap
and Set.
Both will be eventually "fixed" at IGNITE-5553.
So, as far as I understand we agreed that Multimap should be implemented based
on IgniteSet.
Common parts will be extracted to abstract classes and same datastructures will
be used.
Correct?
P.s. In case you see some more optimisation of IgniteSet (except onheap
duplication removal), let's discuss them.
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.7
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
>
[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations
[
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526139#comment-16526139
]
Dmitriy Govorukhin commented on IGNITE-6846:
[~Alexey Kuznetsov] I am working on the review, try to leave comments in the
near future if they will.
> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Labels: iep-6
> Fix For: 2.7
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations
> like {{get}}, {{put}} and {{remove}}, but nothing for
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-8519: - Attachment: image-2018-06-28-15-22-03-186.png > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, image-2018-06-28-15-22-23-245.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526088#comment-16526088 ] Ilya Borisov edited comment on IGNITE-8519 at 6/28/18 8:22 AM: --- !image-2018-06-28-15-21-46-532.png! !image-2018-06-28-15-22-23-245.png! was (Author: klaster_1): !image-2018-06-28-15-21-46-532.png! !image-2018-06-28-15-22-03-186.png! > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, image-2018-06-28-15-22-23-245.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526088#comment-16526088 ] Ilya Borisov commented on IGNITE-8519: -- !image-2018-06-28-15-21-46-532.png! !image-2018-06-28-15-22-03-186.png! > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > image-2018-06-28-15-22-03-186.png, modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-8519: Assignee: Alexey Kuznetsov (was: Ilya Borisov) [~kuaw26] please review. > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8519) Web Console: Refactor to from Font Awesome to svg icons "Change token" panel on Profile screen
[ https://issues.apache.org/jira/browse/IGNITE-8519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-8519: - Attachment: image-2018-06-28-15-21-46-532.png > Web Console: Refactor to from Font Awesome to svg icons "Change token" panel > on Profile screen > -- > > Key: IGNITE-8519 > URL: https://issues.apache.org/jira/browse/IGNITE-8519 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Attachments: Security Token.png, image-2018-06-28-15-21-46-532.png, > modal.png > > > We are constantly refactoring FontAwesome to svg icons. > Lets refactor "Change token" on Profile screen and in the modal window > !modal.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8678) Web Console: Sign-up and sign-in screen cleanup
[ https://issues.apache.org/jira/browse/IGNITE-8678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8678. -- > Web Console: Sign-up and sign-in screen cleanup > --- > > Key: IGNITE-8678 > URL: https://issues.apache.org/jira/browse/IGNITE-8678 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.7 > > > Remove the gray line above the sign-in and sign-up buttons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
