[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270346#comment-16270346 ] Roman Kondakov commented on IGNITE-7044: [~dmagda], [~pgarg], please review the documentation for the PARALLEL option in the CREATE INDEX command: https://dash.readme.io/project/apacheignite-sql/v2.3/docs/create-index_24_hidden > SQL: Documentation for the PARALLEL statement in the CREATE INDEX command > - > > Key: IGNITE-7044 > URL: https://issues.apache.org/jira/browse/IGNITE-7044 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.1 >Reporter: Roman Kondakov >Assignee: Denis Magda > Fix For: 2.4 > > > Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7064) Web console: implement mechanism to manage E2E tests environment
[ https://issues.apache.org/jira/browse/IGNITE-7064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-7064: - Summary: Web console: implement mechanism to manage E2E tests environment (was: Web console: implement mechanism to) > Web console: implement mechanism to manage E2E tests environment > > > Key: IGNITE-7064 > URL: https://issues.apache.org/jira/browse/IGNITE-7064 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > Most of E2E tests require complex DB/web-agent/Ignite cluster state > management. Let's implement tools to help with that, maybe something easy at > first, like DB state. Web console backend already has a similar mechanism we > can reuse. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7064) Web console: implement mechanism to
Ilya Borisov created IGNITE-7064: Summary: Web console: implement mechanism to Key: IGNITE-7064 URL: https://issues.apache.org/jira/browse/IGNITE-7064 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Alexander Kalinin Priority: Minor Most of E2E tests require complex DB/web-agent/Ignite cluster state management. Let's implement tools to help with that, maybe something easy at first, like DB state. Web console backend already has a similar mechanism we can reuse. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)
[ https://issues.apache.org/jira/browse/IGNITE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270277#comment-16270277 ] Alexander Kalinin commented on IGNITE-4398: --- [~anovikov] Moved header cache stuff to upper level > Web console: incorrect authentication under IE 11 (windows 10) > -- > > Key: IGNITE-4398 > URL: https://issues.apache.org/jira/browse/IGNITE-4398 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov > Time Spent: 0.1m > Remaining Estimate: 0h > > To reproduce: > 1) log in as User1 > 2) create some cluster and save > 3) log out > 4) log in as User2 > You will see the cluster from User1. > Note: IE specific only -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts
[ https://issues.apache.org/jira/browse/IGNITE-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270273#comment-16270273 ] ASF GitHub Bot commented on IGNITE-7043: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3103 > Incorrect method name suggested when page eviction starts > - > > Key: IGNITE-7043 > URL: https://issues.apache.org/jira/browse/IGNITE-7043 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Trivial > > Reported via gitter: > WARNING: Page evictions started, this will affect storage performance > (consider increasing DataStorageConfiguration#setPageCacheSize). > since there is no such setting (field/property) setPageCacheSize (ver. > 2.3.0#20171028-sha1:8add7fd5) > The actual method is DataRegionConfiguration.setMaxSize. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)
[ https://issues.apache.org/jira/browse/IGNITE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-4398: - Assignee: Andrey Novikov (was: Alexander Kalinin) Implemented caching as described here: https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate > Web console: incorrect authentication under IE 11 (windows 10) > -- > > Key: IGNITE-4398 > URL: https://issues.apache.org/jira/browse/IGNITE-4398 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov > Time Spent: 0.1m > Remaining Estimate: 0h > > To reproduce: > 1) log in as User1 > 2) create some cluster and save > 3) log out > 4) log in as User2 > You will see the cluster from User1. > Note: IE specific only -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)
[ https://issues.apache.org/jira/browse/IGNITE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16270187#comment-16270187 ] Alexander Kalinin edited comment on IGNITE-4398 at 11/29/17 5:42 AM: - Implemented caching as described here: https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate, Please review was (Author: alexdel): Implemented caching as described here: https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate > Web console: incorrect authentication under IE 11 (windows 10) > -- > > Key: IGNITE-4398 > URL: https://issues.apache.org/jira/browse/IGNITE-4398 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov > Time Spent: 0.1m > Remaining Estimate: 0h > > To reproduce: > 1) log in as User1 > 2) create some cluster and save > 3) log out > 4) log in as User2 > You will see the cluster from User1. > Note: IE specific only -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console
[ https://issues.apache.org/jira/browse/IGNITE-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-4835: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) Please review once again. Everything should work fine. > Add ability to start rebalancing from management console > > > Key: IGNITE-4835 > URL: https://issues.apache.org/jira/browse/IGNITE-4835 > Project: Ignite > Issue Type: New Feature > Components: wizards >Affects Versions: 1.9 >Reporter: Alexandr Fedotov >Assignee: Pavel Konstantinov >Priority: Minor > > Management console should allow for starting rebalancing manually. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7063) Web console: improve error handling in case of custom SMTP server
Pavel Konstantinov created IGNITE-7063: -- Summary: Web console: improve error handling in case of custom SMTP server Key: IGNITE-7063 URL: https://issues.apache.org/jira/browse/IGNITE-7063 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Add an error message in case if settings.json can't be read (contains error) Add an error message in case if 'forgot password' message failed to be sent -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)
[ https://issues.apache.org/jira/browse/IGNITE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov reassigned IGNITE-4398: -- Assignee: Alexander Kalinin (was: Andrey Novikov) Please, take a look. https://stackoverflow.com/questions/39404588/prevent-cache-when-serving-a-json-response-in-node-js-api/39407519 > Web console: incorrect authentication under IE 11 (windows 10) > -- > > Key: IGNITE-4398 > URL: https://issues.apache.org/jira/browse/IGNITE-4398 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexander Kalinin > Time Spent: 0.1m > Remaining Estimate: 0h > > To reproduce: > 1) log in as User1 > 2) create some cluster and save > 3) log out > 4) log in as User2 > You will see the cluster from User1. > Note: IE specific only -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky
[ https://issues.apache.org/jira/browse/IGNITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269874#comment-16269874 ] Sunny Chan edited comment on IGNITE-5960 at 11/29/17 1:24 AM: -- [~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux of our problem. From our application prospective we did this: # Setup a cache with a pair of node # Setup continuous query, and update entries in the cache that would trigger the CQ # Remove one node forcefully (e.g. kill -9). The thread that update entries should continue in the background # Now restart the killed node and you will find the continuous query no longer gets any event even the update continuous. was (Author: sunnychanclsa): [~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux of our problem. From our application prospective we did this: # Setup a cache with a pair of node # Setup continuous query, and update entries in the cache that would trigger the CQ # Remove one node forcefully (e.g. kill -9). The entries update to cache should continue in the background # Now restart the killed node and you will find the continuous query no longer gets any event even the update continuous. > Ignite Continuous Query (Queries 3): > CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic > is flaky > - > > Key: IGNITE-5960 > URL: https://issues.apache.org/jira/browse/IGNITE-5960 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergey Chugunov >Assignee: Alexey Kuznetsov > Labels: MakeTeamcityGreenAgain, test-failure > Fix For: 2.4 > > > According to [TC > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E] > test is flaky. > It is possible to reproduce it locally, sample run shows 9 failed tests out > of 30 overall executed. > Test fails with jUnit assertion check: > {noformat} > junit.framework.AssertionFailedError: > Expected :1 > Actual :0 > > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky
[ https://issues.apache.org/jira/browse/IGNITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269874#comment-16269874 ] Sunny Chan commented on IGNITE-5960: [~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux of our problem. From our application prospective we did this: # Setup a cache with a pair of node # Setup continuous query, and update entries in the cache that would trigger the CQ # Remove one node forcefully (e.g. kill -9). The entries update to cache should continue in the background # Now restart the killed node and you will find the continuous query no longer gets any event even the update continuous. > Ignite Continuous Query (Queries 3): > CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic > is flaky > - > > Key: IGNITE-5960 > URL: https://issues.apache.org/jira/browse/IGNITE-5960 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergey Chugunov >Assignee: Alexey Kuznetsov > Labels: MakeTeamcityGreenAgain, test-failure > Fix For: 2.4 > > > According to [TC > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E] > test is flaky. > It is possible to reproduce it locally, sample run shows 9 failed tests out > of 30 overall executed. > Test fails with jUnit assertion check: > {noformat} > junit.framework.AssertionFailedError: > Expected :1 > Actual :0 > > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7062) Ignite page with video resources and recording
Denis Magda created IGNITE-7062: --- Summary: Ignite page with video resources and recording Key: IGNITE-7062 URL: https://issues.apache.org/jira/browse/IGNITE-7062 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Assignee: Prachi Garg Fix For: 2.4 There is a plenty of recordings of Ignite meetups, webinars and conference talks available on the Internet. Some of them introduce basic components and capabilities, some share best practices and pitfalls while the other share use cases. Generally, it's beneficial for both Ignite community and users to gather and expose the most useful ones under a special video recording section. For instance, we might consider these talks to be added right away: * Ignite use case: https://youtu.be/1D8hyLWMtfM * Ignite essentials: https://www.youtube.com/watch?v=G22L2KW9gEQ * Kubernetes: https://www.youtube.com/watch?v=igDB0wyodr8 Instead of creating a new page for this purpose I would rework the screencasts' page combining all the media content there: https://ignite.apache.org/screencasts.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7061) Rework Features menu and page
[ https://issues.apache.org/jira/browse/IGNITE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7061: Description: The features menu and the page [1] is overloaded and confusing. As a technical guy, I feel lost trying to grasp what’s important and what’s secondary. That deters me from digging into the project. Rework the menu and page in accordance with this discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html All the changes are incorporated in this SVN branch: https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061 [1] https://ignite.apache.org/features.html was: The features menu and the page [1] is overloaded and confusing. As a technical guy, I feel lost trying to grasp what’s important and what’s secondary. That deters me from digging into the project. Rework the menu and page in accordance with this discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html [1] https://ignite.apache.org/features.html > Rework Features menu and page > - > > Key: IGNITE-7061 > URL: https://issues.apache.org/jira/browse/IGNITE-7061 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Assignee: Denis Magda > Fix For: 2.4 > > > The features menu and the page [1] is overloaded and confusing. As a > technical guy, I feel lost trying to grasp what’s important and what’s > secondary. That deters me from digging into the project. > Rework the menu and page in accordance with this discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html > All the changes are incorporated in this SVN branch: > https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061 > [1] https://ignite.apache.org/features.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7061) Rework Features menu and page
[ https://issues.apache.org/jira/browse/IGNITE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7061: --- Assignee: Denis Magda > Rework Features menu and page > - > > Key: IGNITE-7061 > URL: https://issues.apache.org/jira/browse/IGNITE-7061 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Assignee: Denis Magda > Fix For: 2.4 > > > The features menu and the page [1] is overloaded and confusing. As a > technical guy, I feel lost trying to grasp what’s important and what’s > secondary. That deters me from digging into the project. > Rework the menu and page in accordance with this discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html > [1] https://ignite.apache.org/features.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7061) Rework Features menu and page
Denis Magda created IGNITE-7061: --- Summary: Rework Features menu and page Key: IGNITE-7061 URL: https://issues.apache.org/jira/browse/IGNITE-7061 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 The features menu and the page [1] is overloaded and confusing. As a technical guy, I feel lost trying to grasp what’s important and what’s secondary. That deters me from digging into the project. Rework the menu and page in accordance with this discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html [1] https://ignite.apache.org/features.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7060) Prepare Architecture section for the site
Denis Magda created IGNITE-7060: --- Summary: Prepare Architecture section for the site Key: IGNITE-7060 URL: https://issues.apache.org/jira/browse/IGNITE-7060 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 In addition to the features, it's useful to introduce Ignite architecture right in the Features menu covering the following: * Overview * Clustering and Deployment * Distributed Database * Durable Memory -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7059) Improve Collocated Processing page on the site
[ https://issues.apache.org/jira/browse/IGNITE-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7059: Summary: Improve Collocated Processing page on the site (was: Expand Collocated Processing page on the site) > Improve Collocated Processing page on the site > -- > > Key: IGNITE-7059 > URL: https://issues.apache.org/jira/browse/IGNITE-7059 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda > Fix For: 2.4 > > > Presently the collocated processing [1] covers general aspects of this > paradigm. Elaborate more on the following: > * How it's related to SQL > * How it's related to compute grid and ML > * As for compute grid, mention that it allows broadcast or run computations > on concrete nodes as well. > [1] https://ignite.apache.org/collocatedprocessing.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7059) Expand Collocated Processing page on the site
Denis Magda created IGNITE-7059: --- Summary: Expand Collocated Processing page on the site Key: IGNITE-7059 URL: https://issues.apache.org/jira/browse/IGNITE-7059 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 Presently the collocated processing [1] covers general aspects of this paradigm. Elaborate more on the following: * How it's related to SQL * How it's related to compute grid and ML * As for compute grid, mention that it allows broadcast or run computations on concrete nodes as well. [1] https://ignite.apache.org/collocatedprocessing.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7058) Make out a site page for ACID Transactions
Denis Magda created IGNITE-7058: --- Summary: Make out a site page for ACID Transactions Key: IGNITE-7058 URL: https://issues.apache.org/jira/browse/IGNITE-7058 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 ACID transactions are a major feature of Ignite and have to be exposed under the Features menu on the site. Make out the page covering the following: * 2Phase Commit Protocol * Pessimistic and Optimistic Modes * Deadlock detection -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7057) Create Key-Value Page for the site
Denis Magda created IGNITE-7057: --- Summary: Create Key-Value Page for the site Key: IGNITE-7057 URL: https://issues.apache.org/jira/browse/IGNITE-7057 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 Prepare a page to describe Ignite key-value APIs. The page will go to the Features menu and should cover the following: * Scope of K/V APIs. * JCache * Benefits of JCache * How to combine K/V and SQL APIs * Examples Rework existing data grid and key-value store pages: https://ignite.apache.org/features/datagrid.html https://ignite.apache.org/use-cases/database/key-value-store.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7056) Prepare Multi-Language support page for the site
Denis Magda created IGNITE-7056: --- Summary: Prepare Multi-Language support page for the site Key: IGNITE-7056 URL: https://issues.apache.org/jira/browse/IGNITE-7056 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Fix For: 2.4 Prepare Ignite's multi-language page that will go under the features menu. The page should encompass the following: * Java, .NET and C++ native APIs. * Supported drivers and protocols that can be used in various languages. * A couple of examples. Update the image by combining Java, NET and C++ logos. Remove the pages below setting up a redirect the multi-languages page: https://ignite.apache.org/features/java.html https://ignite.apache.org/features/dotnet.html https://ignite.apache.org/features/cpp.html https://ignite.apache.org/features/clientprotos.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269807#comment-16269807 ] Valentin Kulichenko commented on IGNITE-3084: - I'm OK with upgrading to 2.2.0. > Spark Data Frames Support in Apache Ignite > -- > > Key: IGNITE-3084 > URL: https://issues.apache.org/jira/browse/IGNITE-3084 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Nikolay Izhikov > Labels: bigdata > Fix For: 2.4 > > > Apache Spark already benefits from integration with Apache Ignite. The latter > provides shared RDDs, an implementation of Spark RDD, that help Spark to > share a state between Spark workers and execute SQL queries much faster. The > next logical step is to enable support for modern Spark Data Frames API in a > similar way. > As a contributor, you will be fully in charge of the integration of Spark > Data Frame API and Apache Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7056) Prepare Multi-Language support page for the site
[ https://issues.apache.org/jira/browse/IGNITE-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7056: --- Assignee: Denis Magda > Prepare Multi-Language support page for the site > > > Key: IGNITE-7056 > URL: https://issues.apache.org/jira/browse/IGNITE-7056 > Project: Ignite > Issue Type: Task > Components: site >Reporter: Denis Magda >Assignee: Denis Magda > Fix For: 2.4 > > > Prepare Ignite's multi-language page that will go under the features menu. > The page should encompass the following: > * Java, .NET and C++ native APIs. > * Supported drivers and protocols that can be used in various languages. > * A couple of examples. > Update the image by combining Java, NET and C++ logos. > Remove the pages below setting up a redirect the multi-languages page: > https://ignite.apache.org/features/java.html > https://ignite.apache.org/features/dotnet.html > https://ignite.apache.org/features/cpp.html > https://ignite.apache.org/features/clientprotos.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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=16269747#comment-16269747 ] Valentin Kulichenko commented on IGNITE-6846: - [~Alexey Kuznetsov], here are my comments. 1. Makes sense. 2. Metrics for total number of invocations should be incremented. 3. Correct. 4. This sounds like a weird case, how do you update multiple entries with one entry processor invocation? 5. Correct. And this does not depend on what entry processor returns. 6. How does regular 'remove' metric behaves in this case? I think similar 'invoke' metric should be consistent with that one. 7. Can you draft the API and present it here? > 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.4 > > > {{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 (v6.4.14#64029)
[jira] [Created] (IGNITE-7055) Text query for a particular field not working
Valentin Kulichenko created IGNITE-7055: --- Summary: Text query for a particular field not working Key: IGNITE-7055 URL: https://issues.apache.org/jira/browse/IGNITE-7055 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.3 Reporter: Valentin Kulichenko Lucene queries allow to specify a specific field name to search in [1], however this doesn't seem to work in latest versions of Ignite. To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field expression: {code} QueryCursor> masters = cache.query(new TextQuery (Person.class, "resume:Master")); {code} This query returns empty result. [1] http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense
[ https://issues.apache.org/jira/browse/IGNITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-6390: Assignee: Andrey Novikov (was: Dmitriy Shabalin) [~alexeinov] fixed issues, pls review it > [IGNITE-6390] Web console: Implement component for cluster selection on pages > where it make sense > - > > Key: IGNITE-6390 > URL: https://issues.apache.org/jira/browse/IGNITE-6390 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Andrey Novikov > Fix For: 2.4 > > > 1. add cluster-selector to pages. > 2. add update information of cluster data in page after change cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7040) Web console: Invalid user table height
[ https://issues.apache.org/jira/browse/IGNITE-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-7040: Assignee: Dmitriy Shabalin (was: Andrey Novikov) > Web console: Invalid user table height > -- > > Key: IGNITE-7040 > URL: https://issues.apache.org/jira/browse/IGNITE-7040 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Dmitriy Shabalin > > # Filter user list (f.e. to 2 rows) > # Change period of showed activity metrics. > Height of table changed to maximum available but show only filtered rows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense
[ https://issues.apache.org/jira/browse/IGNITE-6390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-6390: Assignee: Dmitriy Shabalin (was: Ilya Borisov) > [IGNITE-6390] Web console: Implement component for cluster selection on pages > where it make sense > - > > Key: IGNITE-6390 > URL: https://issues.apache.org/jira/browse/IGNITE-6390 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Dmitriy Shabalin > Fix For: 2.4 > > > 1. add cluster-selector to pages. > 2. add update information of cluster data in page after change cluster. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (IGNITE-7040) Web console: Invalid user table height
[ https://issues.apache.org/jira/browse/IGNITE-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin updated IGNITE-7040: - Comment: was deleted (was: [~anovikov] fixed issues, pls review it.) > Web console: Invalid user table height > -- > > Key: IGNITE-7040 > URL: https://issues.apache.org/jira/browse/IGNITE-7040 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Dmitriy Shabalin > > # Filter user list (f.e. to 2 rows) > # Change period of showed activity metrics. > Height of table changed to maximum available but show only filtered rows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7040) Web console: Invalid user table height
[ https://issues.apache.org/jira/browse/IGNITE-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Shabalin reassigned IGNITE-7040: Assignee: Andrey Novikov (was: Dmitriy Shabalin) [~anovikov] fixed issues, pls review it. > Web console: Invalid user table height > -- > > Key: IGNITE-7040 > URL: https://issues.apache.org/jira/browse/IGNITE-7040 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Andrey Novikov > > # Filter user list (f.e. to 2 rows) > # Change period of showed activity metrics. > Height of table changed to maximum available but show only filtered rows. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5733) Activate/deactivate cluster through http-rest api
[ https://issues.apache.org/jira/browse/IGNITE-5733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-5733: Labels: usability (was: ) > Activate/deactivate cluster through http-rest api > - > > Key: IGNITE-5733 > URL: https://issues.apache.org/jira/browse/IGNITE-5733 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Critical > Labels: usability > Fix For: 2.4 > > > Need to add command to get/set cluster active flag into http rest api. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6994) Need to document PartitionLossPolicy
[ https://issues.apache.org/jira/browse/IGNITE-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6994: Priority: Critical (was: Major) > Need to document PartitionLossPolicy > > > Key: IGNITE-6994 > URL: https://issues.apache.org/jira/browse/IGNITE-6994 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Critical > Labels: documentation > Fix For: 2.4 > > > Since 2.0 we have a feature that makes cache(s) unavailable in case of data > loss; exact behavior is controlled by {{PartitionLossPolicy}}: > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html > However, there is no mentioning in documentation about this. Need to provide > explanation of how and when it should be used and provide configuration > examples. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6698) Document CREATE TABLE "DATA_REGION" option
[ https://issues.apache.org/jira/browse/IGNITE-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-6698. --- > Document CREATE TABLE "DATA_REGION" option > -- > > Key: IGNITE-6698 > URL: https://issues.apache.org/jira/browse/IGNITE-6698 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Denis Magda >Priority: Critical > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6950) Update documentation for user facing CREATE TABLE params
[ https://issues.apache.org/jira/browse/IGNITE-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-6950. --- > Update documentation for user facing CREATE TABLE params > > > Key: IGNITE-6950 > URL: https://issues.apache.org/jira/browse/IGNITE-6950 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Affects Versions: 2.4 >Reporter: Alexander Paschenko >Assignee: Denis Magda > Fix For: 2.4 > > > Changes to documentation should be made to reflect additional spelling for > some {{CREATE TABLE}} params added in IGNITE-6270. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269415#comment-16269415 ] Denis Magda commented on IGNITE-6948: - [~kirill.shirokov], thanks for the documentation! I've tweaked it a little bit. [~pgarg], please do a final review. Read through {INLINE_SIZE} parameter description [1] and index inlining section [2]. [1] https://apacheignite-sql.readme.io/v2.3/docs/create-index_24_hidden#section-parameters [2] https://apacheignite-sql.readme.io/v2.3/docs/create-index_24_hidden#section-index-inlining > SQL: Document new INLINE_SIZE option in CREATE INDEX command > > > Key: IGNITE-6948 > URL: https://issues.apache.org/jira/browse/IGNITE-6948 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Kirill Shirokov >Assignee: Denis Magda > Fix For: 2.4 > > > INLINE_SIZE is optional and accepts positive integer values. To specify the > default inline size user should omit the option. > The corresponding documentation page is at: > https://apacheignite-sql.readme.io/docs/create-index -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7054) S3 IP finder: support client side encryption
Valentin Kulichenko created IGNITE-7054: --- Summary: S3 IP finder: support client side encryption Key: IGNITE-7054 URL: https://issues.apache.org/jira/browse/IGNITE-7054 Project: Ignite Issue Type: Improvement Components: s3 Affects Versions: 2.3 Reporter: Valentin Kulichenko Fix For: 2.4 In case client side encryption [1] is used, it may be required to use {{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need to add this option to the S3 IP finder, along with any applicable configuration parameters. [1] http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7053) S3 IP finder: support server side encryption
Valentin Kulichenko created IGNITE-7053: --- Summary: S3 IP finder: support server side encryption Key: IGNITE-7053 URL: https://issues.apache.org/jira/browse/IGNITE-7053 Project: Ignite Issue Type: Improvement Components: s3 Affects Versions: 2.3 Reporter: Valentin Kulichenko Fix For: 2.4 In case server side encryption [1] is used, it may be required to specify the algorithm in request headers when saving information in a bucket (can be done via {{ObjectMetadata#setSSEAlgorithm}} method). To support this we need to add corresponding configuration property to the S3 IP finder. [1] http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address
Valentin Kulichenko created IGNITE-7052: --- Summary: S3 IP finder: add an ability to provide endpoint address Key: IGNITE-7052 URL: https://issues.apache.org/jira/browse/IGNITE-7052 Project: Ignite Issue Type: Improvement Components: s3 Affects Versions: 2.3 Reporter: Valentin Kulichenko Fix For: 2.4 By default S3 client detects region automatically by sending special request to {{us-west-1}}. In case environment is restricted to some other region, this leads to connection timeout exception. The issue can be solved by providing a specific region endpoint via {{AmazonS3Client#setEndpoint}} method. To support this we need to add {{endpoint}} configuration property to the IP finder. List of S3 region endpoints: http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE
[ https://issues.apache.org/jira/browse/IGNITE-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6937: Description: Normally in SQL world readers do not block writers. This is how our SELECT operations should work by default. But we need to add a support for {{SELECT ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. In this mode we lock entries as usual, but then send data back to the caller. First page can be returned directly in our {{LockResponse}}. Next pages should be requested in separate requests. With this approach {{SELECT ,,, FOR UPDATE}} will require only single round-trip to both lock and read data in case of small updates. Update {{SELECT}} statement syntax once this feature is supported: https://apacheignite-sql.readme.io/docs/select was: Normally in SQL world readers do not block writers. This is how our SELECT operations should work by default. But we need to add a support for {{SELECT ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. In this mode we lock entries as usual, but then send data back to the caller. First page can be returned directly in our {{LockResponse}}. Next pages should be requested in separate requests. With this approach {{SELECT ,,, FOR UPDATE}} will require only single round-trip to both lock and read data in case of small updates. > SQL TX: Support SELECT FOR UPDATE > - > > Key: IGNITE-6937 > URL: https://issues.apache.org/jira/browse/IGNITE-6937 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov > Labels: iep-3 > Fix For: 2.4 > > > Normally in SQL world readers do not block writers. This is how our SELECT > operations should work by default. But we need to add a support for {{SELECT > ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. > In this mode we lock entries as usual, but then send data back to the caller. > First page can be returned directly in our {{LockResponse}}. Next pages > should be requested in separate requests. With this approach {{SELECT ,,, FOR > UPDATE}} will require only single round-trip to both lock and read data in > case of small updates. > Update {{SELECT}} statement syntax once this feature is supported: > https://apacheignite-sql.readme.io/docs/select -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7029) Add an ability to provide multiple connection addresses for thin JDBC driver
[ https://issues.apache.org/jira/browse/IGNITE-7029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269089#comment-16269089 ] Blackfield commented on IGNITE-7029: IGNITE-6942 covers the failover feature. This ticket asks for load balancing feature implemented as well. > Add an ability to provide multiple connection addresses for thin JDBC driver > > > Key: IGNITE-7029 > URL: https://issues.apache.org/jira/browse/IGNITE-7029 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.3 >Reporter: Valentin Kulichenko > > Currently we allow only to provide one address when connecting via thin JDBC > driver. This has to issues: > * If node driver is connected to goes down, the driver stops working. > * Driver has to always go though the same node - this is a bottleneck. > As a simple solution we can allow to provide multiple addresses, like MySQL > does for example: > https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7051) SQL Rename table support
Blackfield created IGNITE-7051: -- Summary: SQL Rename table support Key: IGNITE-7051 URL: https://issues.apache.org/jira/browse/IGNITE-7051 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.3 Reporter: Blackfield Use case was discussed at length here: http://apache-ignite-users.70518.x6.nabble.com/Continuous-update-Data-Grid-Cache-td2075.html#a17641 Currently, we have to load data to second table, the client then has to change their query to query this new table. Drop the old table. The latest suggestion in the above thread to "load new data set in the same cache and remove old entries once preloading is finished" is not feasible since for large table and table scan query (thus requires whole dataset to be loaded), it will take a while to load everything - thus increasing the downtime. Table rename support will reduce the downtime greatly. Ref: Postgresql and H2 syntax ALTER TABLE TmpTable RENAME TO Table1; Then, one would wrap it within transaction (It appears that this is slated for 2.4/2.5?) to drop old table, rename temp table to original table. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7050) Add support for spring3
Mikhail Cherkasov created IGNITE-7050: - Summary: Add support for spring3 Key: IGNITE-7050 URL: https://issues.apache.org/jira/browse/IGNITE-7050 Project: Ignite Issue Type: Improvement Affects Versions: 2.3 Environment: there are still users who use spring3 and hence can't use ignite which depends on spring4. I think we can create separate modules which Reporter: Mikhail Cherkasov Assignee: Mikhail Cherkasov Fix For: 2.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7049) Optimistic transaction is not properly rolled back if timed out before sending prepare response.
Alexei Scherbakov created IGNITE-7049: - Summary: Optimistic transaction is not properly rolled back if timed out before sending prepare response. Key: IGNITE-7049 URL: https://issues.apache.org/jira/browse/IGNITE-7049 Project: Ignite Issue Type: Bug Affects Versions: 2.3 Reporter: Alexei Scherbakov Fix For: 2.4 Reproducer: {noformat} /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.apache.ignite.internal.processors.cache.transactions; import org.apache.ignite.Ignite; import org.apache.ignite.cluster.ClusterNode; import org.apache.ignite.configuration.CacheConfiguration; import org.apache.ignite.configuration.IgniteConfiguration; import org.apache.ignite.internal.TestRecordingCommunicationSpi; import org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareResponse; import org.apache.ignite.internal.util.typedef.G; import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi; import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder; import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest; import org.apache.ignite.transactions.Transaction; import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL; import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC; import static org.apache.ignite.transactions.TransactionConcurrency.OPTIMISTIC; import static org.apache.ignite.transactions.TransactionIsolation.SERIALIZABLE; /** * Tests an ability to eagerly rollback timed out optimistic transactions. */ public class TxRollbackOnTimeoutOptimisticTest extends GridCommonAbstractTest { /** */ private static final String CACHE_NAME = "test"; /** IP finder. */ private static final TcpDiscoveryVmIpFinder IP_FINDER = new TcpDiscoveryVmIpFinder(true); /** */ private static final int GRID_CNT = 3; /** {@inheritDoc} */ @Override protected IgniteConfiguration getConfiguration(String igniteInstanceName) throws Exception { IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName); ((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(IP_FINDER); TestRecordingCommunicationSpi commSpi = new TestRecordingCommunicationSpi(); cfg.setCommunicationSpi(commSpi); boolean client = "client".equals(igniteInstanceName); cfg.setClientMode(client); if (!client) { CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME); ccfg.setAtomicityMode(TRANSACTIONAL); ccfg.setBackups(2); ccfg.setWriteSynchronizationMode(FULL_SYNC); cfg.setCacheConfiguration(ccfg); } return cfg; } /** * @return Near cache flag. */ protected boolean nearCacheEnabled() { return false; } /** {@inheritDoc} */ @Override protected void beforeTest() throws Exception { super.beforeTest(); startGridsMultiThreaded(GRID_CNT); } /** {@inheritDoc} */ @Override protected void afterTest() throws Exception { super.afterTest(); stopAllGrids(); } /** */ public void testOptimisticTimeout() throws Exception { final Ignite client = startGrid("client"); assertNotNull(client.cache(CACHE_NAME)); final ClusterNode n0 = client.affinity(CACHE_NAME).mapKeyToNode(0); final Ignite prim = G.ignite(n0.id()); for (Ignite ignite : G.allGrids()) { if (ignite == prim) continue; final TestRecordingCommunicationSpi spi = (TestRecordingCommunicationSpi)ignite.configuration().getCommunicationSpi(); spi.blockMessages(GridDhtTxPrepareResponse.class, prim.name()); } final int val = 0; try { multithreaded(new Runnable() { @Override public void run() { try (Transaction txOpt = client.transactions().txStart(OPTIMISTIC, SERIALIZABLE, 300, 1)) { client.cache(CACHE_NAME).put(val, val); txOpt.commit();
[jira] [Updated] (IGNITE-3478) Multi-version concurrency control
[ https://issues.apache.org/jira/browse/IGNITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-3478: Fix Version/s: 2.5 > Multi-version concurrency control > - > > Key: IGNITE-3478 > URL: https://issues.apache.org/jira/browse/IGNITE-3478 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Alexey Goncharuk > Labels: important > Fix For: 2.5 > > > Current Ignite SQL does not take into account transaction boundaries. For > example, if a transaction atomically changes balance of two accounts, then a > concurrent SQL query can see partially committed transaction. This works for > data analytics, but does not work for more strict and demanding scenarios. > It would be perfect if we had a mode which ensures transaction boundaries are > taken into account for SQL query. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4191) SQL: support transactions
[ https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-4191: Fix Version/s: 2.5 > SQL: support transactions > - > > Key: IGNITE-4191 > URL: https://issues.apache.org/jira/browse/IGNITE-4191 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Denis Magda > Labels: iep-3, important > Fix For: 2.5 > > > Presently there is no any way to execute data modification statements and > SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML > API. > This can be fully supported once MVCC is ready and released. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7048) Cache get fails on node not in BaselineTopology.
[ https://issues.apache.org/jira/browse/IGNITE-7048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-7048: Component/s: persistence > Cache get fails on node not in BaselineTopology. > > > Key: IGNITE-7048 > URL: https://issues.apache.org/jira/browse/IGNITE-7048 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Sergey Chugunov > Fix For: 2.4 > > > As an example take a look at > IgnitePdsBinaryMetadataOnClusterRestartTest::testMixedMetadataIsRestoredOnRestart. > When reading data for check from node not in BaselineTopology it fails with > the following assertion: > {noformat}java.lang.AssertionError: result = true, persistenceEnabled = true, > partitionState = EVICTED > at > org.apache.ignite.internal.processors.cache.GridCacheContext.allowFastLocalRead(GridCacheContext.java:2044) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:321) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:211) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:203) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1392) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:470) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:468) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:757) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:468) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4545) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4526) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1343) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:828) > at > org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:662) > at > org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.examineStaticMetadata(IgnitePdsBinaryMetadataOnClusterRestartTest.java:145) > at > org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.testMixedMetadataIsRestoredOnRestart(IgnitePdsBinaryMetadataOnClusterRestartTest.java:334) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The problem with the test is that in method > *GridCacheProcessor::prepareCacheStart* flag *affNode* is calculated ignoring > information about BaselineTopology distribution. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts
[ https://issues.apache.org/jira/browse/IGNITE-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16269018#comment-16269018 ] Ivan Rakov commented on IGNITE-7043: Looks good, please merge. > Incorrect method name suggested when page eviction starts > - > > Key: IGNITE-7043 > URL: https://issues.apache.org/jira/browse/IGNITE-7043 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Trivial > > Reported via gitter: > WARNING: Page evictions started, this will affect storage performance > (consider increasing DataStorageConfiguration#setPageCacheSize). > since there is no such setting (field/property) setPageCacheSize (ver. > 2.3.0#20171028-sha1:8add7fd5) > The actual method is DataRegionConfiguration.setMaxSize. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7048) Cache get fails on node not in BaselineTopology.
Sergey Chugunov created IGNITE-7048: --- Summary: Cache get fails on node not in BaselineTopology. Key: IGNITE-7048 URL: https://issues.apache.org/jira/browse/IGNITE-7048 Project: Ignite Issue Type: Bug Reporter: Sergey Chugunov Fix For: 2.4 As an example take a look at IgnitePdsBinaryMetadataOnClusterRestartTest::testMixedMetadataIsRestoredOnRestart. When reading data for check from node not in BaselineTopology it fails with the following assertion: {noformat}java.lang.AssertionError: result = true, persistenceEnabled = true, partitionState = EVICTED at org.apache.ignite.internal.processors.cache.GridCacheContext.allowFastLocalRead(GridCacheContext.java:2044) at org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:321) at org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:211) at org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:203) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1392) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:470) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:468) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:757) at org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:468) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4545) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4526) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1343) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:828) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:662) at org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.examineStaticMetadata(IgnitePdsBinaryMetadataOnClusterRestartTest.java:145) at org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.testMixedMetadataIsRestoredOnRestart(IgnitePdsBinaryMetadataOnClusterRestartTest.java:334) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at junit.framework.TestCase.runTest(TestCase.java:176) at org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) at org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) at org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) at java.lang.Thread.run(Thread.java:745) {noformat} The problem with the test is that in method *GridCacheProcessor::prepareCacheStart* flag *affNode* is calculated ignoring information about BaselineTopology distribution. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS
[ https://issues.apache.org/jira/browse/IGNITE-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268927#comment-16268927 ] ASF GitHub Bot commented on IGNITE-7013: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3091 > .NET: Ignite does not start on macOS > > > Key: IGNITE-7013 > URL: https://issues.apache.org/jira/browse/IGNITE-7013 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, xplat > Fix For: 2.4 > > > Looks like dlopen code is incorrect for macOS: > {code} > Unhandled Exception: System.DllNotFoundException: Unable to load DLL > 'libcoreclr.so': The specified module or one of its dependencies could not be > found. > (Exception from HRESULT: 0x8007007E) >at > Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String > filename, Int32 flags) >at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String > simpleName) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg) >at ignite_nuget_test.Program.Main(String[] args) in > /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17 > {code} > Steps to reproduce: > {code} > git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git > cd ignite-dotnetcore-demo > dotnet run > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-7013) .NET: Ignite does not start on macOS
[ https://issues.apache.org/jira/browse/IGNITE-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-7013. Resolution: Fixed > .NET: Ignite does not start on macOS > > > Key: IGNITE-7013 > URL: https://issues.apache.org/jira/browse/IGNITE-7013 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, xplat > Fix For: 2.4 > > > Looks like dlopen code is incorrect for macOS: > {code} > Unhandled Exception: System.DllNotFoundException: Unable to load DLL > 'libcoreclr.so': The specified module or one of its dependencies could not be > found. > (Exception from HRESULT: 0x8007007E) >at > Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String > filename, Int32 flags) >at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String > simpleName) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg) >at ignite_nuget_test.Program.Main(String[] args) in > /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17 > {code} > Steps to reproduce: > {code} > git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git > cd ignite-dotnetcore-demo > dotnet run > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS
[ https://issues.apache.org/jira/browse/IGNITE-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268925#comment-16268925 ] Pavel Tupitsyn commented on IGNITE-7013: TC is fine, merged to master: {{0b849abce4514ffe949915c85b15ad6aae23ee33}}. > .NET: Ignite does not start on macOS > > > Key: IGNITE-7013 > URL: https://issues.apache.org/jira/browse/IGNITE-7013 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, xplat > Fix For: 2.4 > > > Looks like dlopen code is incorrect for macOS: > {code} > Unhandled Exception: System.DllNotFoundException: Unable to load DLL > 'libcoreclr.so': The specified module or one of its dependencies could not be > found. > (Exception from HRESULT: 0x8007007E) >at > Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String > filename, Int32 flags) >at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String > simpleName) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, > ILogger log) >at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg) >at ignite_nuget_test.Program.Main(String[] args) in > /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17 > {code} > Steps to reproduce: > {code} > git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git > cd ignite-dotnetcore-demo > dotnet run > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6919) Web console: incorrect character in tab name under IE11
[ https://issues.apache.org/jira/browse/IGNITE-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6919: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Web console: incorrect character in tab name under IE11 > --- > > Key: IGNITE-6919 > URL: https://issues.apache.org/jira/browse/IGNITE-6919 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Trivial > Fix For: 2.4 > > Attachments: screenshot-1.png > > > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)
[ https://issues.apache.org/jira/browse/IGNITE-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-4398: Assignee: Andrey Novikov (was: Alexey Kuznetsov) [~anovikov] Please review. > Web console: incorrect authentication under IE 11 (windows 10) > -- > > Key: IGNITE-4398 > URL: https://issues.apache.org/jira/browse/IGNITE-4398 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Andrey Novikov > Time Spent: 0.1m > Remaining Estimate: 0h > > To reproduce: > 1) log in as User1 > 2) create some cluster and save > 3) log out > 4) log in as User2 > You will see the cluster from User1. > Note: IE specific only -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4452) Web console: add execution time to results panel on Queries screen
[ https://issues.apache.org/jira/browse/IGNITE-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-4452: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) It seems, that issue was already fixed in IGNITE-4454. > Web console: add execution time to results panel on Queries screen > -- > > Key: IGNITE-4452 > URL: https://issues.apache.org/jira/browse/IGNITE-4452 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Trivial > Fix For: 2.4 > > Attachments: screenshot-1.png > > > I think it may be useful to know query last execution time, especially if we > have a Refresh rate possibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-4452) Web console: add execution time to results panel on Queries screen
[ https://issues.apache.org/jira/browse/IGNITE-4452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-4452: - Fix Version/s: 2.4 > Web console: add execution time to results panel on Queries screen > -- > > Key: IGNITE-4452 > URL: https://issues.apache.org/jira/browse/IGNITE-4452 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov >Priority: Trivial > Fix For: 2.4 > > Attachments: screenshot-1.png > > > I think it may be useful to know query last execution time, especially if we > have a Refresh rate possibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7047) NPE at org.jsr166.ConcurrentLinkedHashMap.replace
Alexey Popov created IGNITE-7047: Summary: NPE at org.jsr166.ConcurrentLinkedHashMap.replace Key: IGNITE-7047 URL: https://issues.apache.org/jira/browse/IGNITE-7047 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.1 Reporter: Alexey Popov Assignee: Alexey Popov NPE happens sometimes at heavy load after receiving GridDhtTxOnePhaseCommitAckRequest, no more details ERROR 11/25/17 17:39:28 [::sys-stripe-2-#3%null%] cache.GridCacheIoManager> Failed processing message [senderId=0393e394-09a9-4c02-b33e-fb4d99c3539f, msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersi on [topVer=123129570, order=1511649564004, nodeOrder=2]], super=GridCacheMessage [msgId=95, depInfo=null, err=null, skipPrepare=false]]] java.lang.NullPointerException at org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126) at org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097) at org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483) at java.lang.Thread.run(Thread.java:745) ERROR 11/25/17 17:39:28 [::sys-stripe-14-#15%null%] cache.GridCacheIoManager> Failed processing message [senderId=52c4ced0-49f3-4075-9b2f-7d619adf6d33, msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion [topVer=123129570, order=1511649564004, nodeOrder=4]], super=GridCacheMessage [msgId=97, depInfo=null, err=null, skipPrepare=false]]] java.lang.NullPointerException at org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
[jira] [Commented] (IGNITE-6945) SQL: optionally do not copy offheap rows for local SqlQuery
[ https://issues.apache.org/jira/browse/IGNITE-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268822#comment-16268822 ] Vladimir Ozerov commented on IGNITE-6945: - [~tledkov-gridgain], my comments: 1) BinaryObjectOffheapImpl: I think it is illegal to "copy" object this way. We should copy data from offheap to heap and return BinaryObjectImpl. 2) Usage of GridCloseableCursor and/or Closeable is bad idea, because this may lead to unexpected calls to "close" in future. Let's define separate interface for this. 3) Why do we push flag to CacheOperationContext? Looks wrong to me, as it doesn't relate to cache. This is indexing stuff, GridH2QueryContext should be enough. 4) H2Tree.compare - why do we cleanup temp row in one place, but do not do this after another getRow() call below? 5) Is it possible to remove all current changes from BPlusTree and perform close in H2 classes? It looks strange that we call unrelated unlocks in all tree types just to support local SQL queries. You can do that as follows: define a kind of registry of binary objects to be closed; pass it to BPlusTree when cursor is created; use it inside H2LeafIO and H2ExtrasLeadIO classes to track pages to be unlocked. Will that work? Ideally, there should be no changes to BPlusTree and CacheDataRow. > SQL: optionally do not copy offheap rows for local SqlQuery > --- > > Key: IGNITE-6945 > URL: https://issues.apache.org/jira/browse/IGNITE-6945 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Fix For: 2.4 > > > Currently when iterating over rows we eagerly materialize them [1]. If key or > value are large enough, we could loose a lot of time on offheap-heap copying. > To partially mitigate this, we can do the following: > 1) Add new flag {{SqlQuery.localNoCopy}} which is applicable only for local > queries. > 2) When enabled we will not copy final {{_KEY}} and {{_VAL}} columns to heap. > but rather wrap them into {{BinaryOffheapObjectImpl}} > 3) These rows must be released when query iterator switches to the next row. > [1] {{H2RowFactory.getRow}} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
[ https://issues.apache.org/jira/browse/IGNITE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-6186: - Description: The method is not thread-safe unless actual parameter is currentThread. Let future state is a list of listeners and two concurrent threads are removing two adjacent non-root listener nodes from list simultaneously by calling {{unregisterWaiter()}}. Then data race is possible: one of these listeners can survive its removal. If the listener is a thread waiting for completion in {{get0()}} then this race leads at worst case to 1 extra call to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an arbitrary listener, and its {{apply()}} will be called twice. To be precise, this Jira issue does not relate to any existing bug, but it eliminates fragile construct that can explode on future chages/refactorings. was: The method is not thread-safe unless actual parameter is currentThread. Let future state is a list of listeners and two concurrent threads are removing two adjacent non-root listener nodes from list simultaneously by calling {{unregisterWaiter()}}. Then data race is possible: one of these listeners can survive its removal. If the listener is a thread waiting for completion in {{get0()}} then this race leads at worst case to 1 extra call to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an arbitrary listener, and its {{apply()}} will be called twice. > Remove redundant parameter of GridFutureAdapter::unregisterWaiter() > --- > > Key: IGNITE-6186 > URL: https://issues.apache.org/jira/browse/IGNITE-6186 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Minor > > The method is not thread-safe unless actual parameter is currentThread. > Let future state is a list of listeners and two concurrent threads are > removing two adjacent non-root listener nodes from list simultaneously by > calling {{unregisterWaiter()}}. Then data race is possible: one of these > listeners can survive its removal. If the listener is a thread waiting for > completion in {{get0()}} then this race leads at worst case to 1 extra call > to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an > arbitrary listener, and its {{apply()}} will be called twice. > To be precise, this Jira issue does not relate to any existing bug, but it > eliminates fragile construct that can explode on future chages/refactorings. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception
[ https://issues.apache.org/jira/browse/IGNITE-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Shirokov updated IGNITE-7046: Description: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: {noformat} /** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCachec = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } {noformat} ...will result in NPE instead of an Ignite exception explaining the appropriate cause. was: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: {{/** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCache
c = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } }}} ...will result in NPE instead of an Ignite exception explaining the appropriate cause. > Client queries should throw a correct exception > --- > > Key: IGNITE-7046 > URL: https://issues.apache.org/jira/browse/IGNITE-7046 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 >Reporter: Kirill Shirokov > > The following test being added to > org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: > {noformat} > /** > * Method verifies that in the case of client query index is not used and > a correct exception is thrown. > * > * @throws Exception If failed. > */ > public void testClientOnlyNodeIndexException() throws Exception { > try { > Ignite g = startGrid("client"); > IgniteCache
c = jcache(g, Integer.class, > Integer.class); > try { > List cres = c.query(new SqlFieldsQuery("select > count(*) from Integer") > .setLocal(true)).getAll(); > } > catch (IgniteException e) { > throw e; // FIXME: put an exception-checking code here > instead of throw > } > } > finally { > stopGrid("client"); > } > } > {noformat} > ...will result in NPE instead of an Ignite exception explaining the > appropriate cause. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception
[ https://issues.apache.org/jira/browse/IGNITE-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Shirokov updated IGNITE-7046: Description: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: {noformat} /** * Verifies that in the case of client query the index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCachec = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } {noformat} ...will result in NPE instead of an Ignite exception explaining the appropriate cause. was: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: {noformat} /** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCache
c = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } {noformat} ...will result in NPE instead of an Ignite exception explaining the appropriate cause. > Client queries should throw a correct exception > --- > > Key: IGNITE-7046 > URL: https://issues.apache.org/jira/browse/IGNITE-7046 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 >Reporter: Kirill Shirokov > > The following test being added to > org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: > {noformat} > /** > * Verifies that in the case of client query the index is not used and a > correct exception is thrown. > * > * @throws Exception If failed. > */ > public void testClientOnlyNodeIndexException() throws Exception { > try { > Ignite g = startGrid("client"); > IgniteCache
c = jcache(g, Integer.class, > Integer.class); > try { > List cres = c.query(new SqlFieldsQuery("select > count(*) from Integer") > .setLocal(true)).getAll(); > } > catch (IgniteException e) { > throw e; // FIXME: put an exception-checking code here > instead of throw > } > } > finally { > stopGrid("client"); > } > } > {noformat} > ...will result in NPE instead of an Ignite exception explaining the > appropriate cause. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception
[ https://issues.apache.org/jira/browse/IGNITE-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Shirokov updated IGNITE-7046: Description: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: {{/** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCachec = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } }}} ...will result in NPE instead of an Ignite exception explaining the appropriate cause. was: The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: /** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCache
c = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } ...will result in NPE instead of an Ignite exception explaining the appropriate cause. > Client queries should throw a correct exception > --- > > Key: IGNITE-7046 > URL: https://issues.apache.org/jira/browse/IGNITE-7046 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 >Reporter: Kirill Shirokov > > The following test being added to > org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: > {{/** > * Method verifies that in the case of client query index is not used and > a correct exception is thrown. > * > * @throws Exception If failed. > */ > public void testClientOnlyNodeIndexException() throws Exception { > try { > Ignite g = startGrid("client"); > IgniteCache
c = jcache(g, Integer.class, > Integer.class); > try { > List cres = c.query(new SqlFieldsQuery("select > count(*) from Integer") > .setLocal(true)).getAll(); > } > catch (IgniteException e) { > throw e; // FIXME: put an exception-checking code here > instead of throw > } > } > finally { > stopGrid("client"); > } > }}} > ...will result in NPE instead of an Ignite exception explaining the > appropriate cause. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7046) Client queries should throw a correct exception
Kirill Shirokov created IGNITE-7046: --- Summary: Client queries should throw a correct exception Key: IGNITE-7046 URL: https://issues.apache.org/jira/browse/IGNITE-7046 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.3 Reporter: Kirill Shirokov The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: /** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCachec = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } ...will result in NPE instead of an Ignite exception explaining the appropriate cause. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7045) Client queries should throw a correct exception
Kirill Shirokov created IGNITE-7045: --- Summary: Client queries should throw a correct exception Key: IGNITE-7045 URL: https://issues.apache.org/jira/browse/IGNITE-7045 Project: Ignite Issue Type: Bug Components: sql Affects Versions: 2.3 Reporter: Kirill Shirokov The following test being added to org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest: /** * Method verifies that in the case of client query index is not used and a correct exception is thrown. * * @throws Exception If failed. */ public void testClientOnlyNodeIndexException() throws Exception { try { Ignite g = startGrid("client"); IgniteCachec = jcache(g, Integer.class, Integer.class); try { List cres = c.query(new SqlFieldsQuery("select count(*) from Integer") .setLocal(true)).getAll(); } catch (IgniteException e) { throw e; // FIXME: put an exception-checking code here instead of throw } } finally { stopGrid("client"); } } ...will result in NPE instead of an Ignite exception explaining the appropriate cause. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion
[ https://issues.apache.org/jira/browse/IGNITE-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268759#comment-16268759 ] Ryabov Dmitrii commented on IGNITE-602: --- [~agura], what is current status of tests and ticket? > [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by > infinite recursion > > > Key: IGNITE-602 > URL: https://issues.apache.org/jira/browse/IGNITE-602 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Artem Shutak >Assignee: Ryabov Dmitrii > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.4 > > > See test > org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention > and related TODO in same source file. > Also take a look at > http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring > Test should be unmuted on TC after fix. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov updated IGNITE-7044: --- External issue URL: (was: https://issues.apache.org/jira/browse/IGNITE-6406) > SQL: Documentation for the PARALLEL statement in the CREATE INDEX command > - > > Key: IGNITE-7044 > URL: https://issues.apache.org/jira/browse/IGNITE-7044 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.1 >Reporter: Roman Kondakov >Assignee: Roman Kondakov > Fix For: 2.4 > > > Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
Roman Kondakov created IGNITE-7044: -- Summary: SQL: Documentation for the PARALLEL statement in the CREATE INDEX command Key: IGNITE-7044 URL: https://issues.apache.org/jira/browse/IGNITE-7044 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.1 Reporter: Roman Kondakov Assignee: Roman Kondakov Fix For: 2.4 Add a documentation for the PARALLEL option in the CREATE INDEX command. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6952) Deserialization failures on AIX
[ https://issues.apache.org/jira/browse/IGNITE-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-6952: --- Assignee: (was: Vladimir Ozerov) > Deserialization failures on AIX > > > Key: IGNITE-6952 > URL: https://issues.apache.org/jira/browse/IGNITE-6952 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Denis Magda >Priority: Critical > Fix For: 2.4 > > > Ignite fails on AIX with the following stack trace: > {code} > GridConnectionBytesVerifyFilter], accepted=true]]] > java.lang.IllegalArgumentException: null > at java.nio.Buffer.position(Buffer.java:255) ~[?:1.8.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1587) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1542) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readLongArray(DirectByteBufferStreamImplV2.java:1013) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.DirectMessageReader.readLongArray(DirectMessageReader.java:212) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.GridLongList.readFrom(GridLongList.java:558) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readCollection(DirectByteBufferStreamImplV2.java:1244) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.DirectMessageReader.readCollection(DirectMessageReader.java:333) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CacheGroupAffinityMessage.readFrom(CacheGroupAffinityMessage.java:292) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMap(DirectByteBufferStreamImplV2.java:1294) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.DirectMessageReader.readMap(DirectMessageReader.java:345) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsFullMessage.readFrom(GridDhtPartitionsFullMessage.java:645) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.direct.DirectMessageReader.readMessage(DirectMessageReader.java:311) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:262) > ~[ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:90) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:133) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3388) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175) > [ignite-core-2.3.0.jar:2.3.0] > at > org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1261) > [ignite-core-2.3.0.jar:2.3.0] > at >
[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads
[ https://issues.apache.org/jira/browse/IGNITE-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268697#comment-16268697 ] ASF GitHub Bot commented on IGNITE-6406: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3014 > SQL: CREATE INDEX should fill index from multiple threads > - > > Key: IGNITE-6406 > URL: https://issues.apache.org/jira/browse/IGNITE-6406 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > Labels: iep-1, performance > Fix For: 2.4 > > > Currently when {{CREATE INDEX}} command is executed, we fill new index from a > single thread. Low CPU, long create time. We can trade off CPU vs time by > adding more threads. > Probably number of threads should be specified in {{CREATE INDEX}} command as > a hint. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts
[ https://issues.apache.org/jira/browse/IGNITE-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268675#comment-16268675 ] ASF GitHub Bot commented on IGNITE-7043: GitHub user alamar opened a pull request: https://github.com/apache/ignite/pull/3103 IGNITE-7043 Fix method name suggested when page eviction starts You can merge this pull request into a Git repository by running: $ git pull https://github.com/alamar/ignite patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3103.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 #3103 commit 40700bbba66528e8c42da66f28bcc07f634dbb20 Author: Ilya KasnacheevDate: 2017-11-28T12:49:23Z IGNITE-7043 Fix method name suggested when page eviction starts > Incorrect method name suggested when page eviction starts > - > > Key: IGNITE-7043 > URL: https://issues.apache.org/jira/browse/IGNITE-7043 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Trivial > > Reported via gitter: > WARNING: Page evictions started, this will affect storage performance > (consider increasing DataStorageConfiguration#setPageCacheSize). > since there is no such setting (field/property) setPageCacheSize (ver. > 2.3.0#20171028-sha1:8add7fd5) > The actual method is DataRegionConfiguration.setMaxSize. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7043) Incorrect method name suggested when page eviction starts
Ilya Kasnacheev created IGNITE-7043: --- Summary: Incorrect method name suggested when page eviction starts Key: IGNITE-7043 URL: https://issues.apache.org/jira/browse/IGNITE-7043 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.3 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Priority: Trivial Reported via gitter: WARNING: Page evictions started, this will affect storage performance (consider increasing DataStorageConfiguration#setPageCacheSize). since there is no such setting (field/property) setPageCacheSize (ver. 2.3.0#20171028-sha1:8add7fd5) The actual method is DataRegionConfiguration.setMaxSize. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (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=16264488#comment-16264488 ] Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 12:10 PM: - While implementing the task i rely on the following 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. If there was no old value, associated with a key, then 'invoke read-only' metric is incremented. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). Do you think its correct? was (Author: alexey kuznetsov): While implementing the task i rely on the following 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). Do you think its correct? > 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.4 > > > {{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 (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4192) SQL TX: JDBC driver support
[ https://issues.apache.org/jira/browse/IGNITE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Paschenko reassigned IGNITE-4192: --- Assignee: Alexander Paschenko > SQL TX: JDBC driver support > --- > > Key: IGNITE-4192 > URL: https://issues.apache.org/jira/browse/IGNITE-4192 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Denis Magda >Assignee: Alexander Paschenko > Labels: iep-3 > Fix For: 2.4 > > > To support execution of DML and SELECT statements inside of a transaction > started from JDBC driver side. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
[ https://issues.apache.org/jira/browse/IGNITE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Kuznetsov updated IGNITE-6186: - Description: The method is not thread-safe unless actual parameter is currentThread. Let future state is a list of listeners and two concurrent threads are removing two adjacent non-root listener nodes from list simultaneously by calling {{unregisterWaiter()}}. Then data race is possible: one of these listeners can survive its removal. If the listener is a thread waiting for completion in {{get0()}} then this race leads at worst case to 1 extra call to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an arbitrary listener, and its {{apply()}} will be called twice. was:The method is not thread-safe unless actual parameter is currentThread. > Remove redundant parameter of GridFutureAdapter::unregisterWaiter() > --- > > Key: IGNITE-6186 > URL: https://issues.apache.org/jira/browse/IGNITE-6186 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Andrey Kuznetsov >Assignee: Andrey Kuznetsov >Priority: Minor > > The method is not thread-safe unless actual parameter is currentThread. > Let future state is a list of listeners and two concurrent threads are > removing two adjacent non-root listener nodes from list simultaneously by > calling {{unregisterWaiter()}}. Then data race is possible: one of these > listeners can survive its removal. If the listener is a thread waiting for > completion in {{get0()}} then this race leads at worst case to 1 extra call > to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an > arbitrary listener, and its {{apply()}} will be called twice. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky
[ https://issues.apache.org/jira/browse/IGNITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268579#comment-16268579 ] Alexey Kuznetsov edited comment on IGNITE-5960 at 11/28/17 11:16 AM: - [~sunnychanclsa] Can you provide reproducer of your problem, so that i can see the steps you described above? was (Author: alexey kuznetsov): [~sunnychanclsa]Can you provide reproducer of your problem, so that i can see the steps you described above? > Ignite Continuous Query (Queries 3): > CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic > is flaky > - > > Key: IGNITE-5960 > URL: https://issues.apache.org/jira/browse/IGNITE-5960 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergey Chugunov >Assignee: Alexey Kuznetsov > Labels: MakeTeamcityGreenAgain, test-failure > Fix For: 2.4 > > > According to [TC > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E] > test is flaky. > It is possible to reproduce it locally, sample run shows 9 failed tests out > of 30 overall executed. > Test fails with jUnit assertion check: > {noformat} > junit.framework.AssertionFailedError: > Expected :1 > Actual :0 > > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268582#comment-16268582 ] Nikolay Izhikov commented on IGNITE-425: TC run after merge with latest master - https://ci.ignite.apache.org/viewLog.html?buildId=965950=buildResultsDiv=Ignite20Tests_RunAll > Introduce transformers for continuous queries > - > > Key: IGNITE-425 > URL: https://issues.apache.org/jira/browse/IGNITE-425 > Project: Ignite > Issue Type: Sub-task > Components: cache >Affects Versions: 2.2 >Reporter: Yakov Zhdanov >Assignee: Nikolay Izhikov > Fix For: 2.4 > > > Currently if updated entry passes the filter, it is sent to node initiated > the query entirely. It would be good to provide user with the ability to > transform entry and, for example, select only fields that are important. This > may bring huge economy to traffic and lower GC pressure as well. > Possible signatures will be: > {noformat} > public final class ContinuousQuery{..} // T is a type transformer > transforms to > public ContinuousQuery setLocalListener(Listener locLsnr) {..} // > Probably, we will have to introduce new listener type, since user may want to > wipe out key as well. > /* new method to add */ > public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer > factory) { ..} > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky
[ https://issues.apache.org/jira/browse/IGNITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268579#comment-16268579 ] Alexey Kuznetsov commented on IGNITE-5960: -- [~sunnychanclsa]Can you provide reproducer of your problem, so that i can see the steps you described above? > Ignite Continuous Query (Queries 3): > CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic > is flaky > - > > Key: IGNITE-5960 > URL: https://issues.apache.org/jira/browse/IGNITE-5960 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Sergey Chugunov >Assignee: Alexey Kuznetsov > Labels: MakeTeamcityGreenAgain, test-failure > Fix For: 2.4 > > > According to [TC > history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E] > test is flaky. > It is possible to reproduce it locally, sample run shows 9 failed tests out > of 30 overall executed. > Test fails with jUnit assertion check: > {noformat} > junit.framework.AssertionFailedError: > Expected :1 > Actual :0 > > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.failNotEquals(Assert.java:329) > at junit.framework.Assert.assertEquals(Assert.java:78) > at junit.framework.Assert.assertEquals(Assert.java:234) > at junit.framework.Assert.assertEquals(Assert.java:241) > at junit.framework.TestCase.assertEquals(TestCase.java:409) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385) > at > org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at junit.framework.TestCase.runTest(TestCase.java:176) > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000) > at > org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132) > at > org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform
[ https://issues.apache.org/jira/browse/IGNITE-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268559#comment-16268559 ] Anton Vinogradov commented on IGNITE-6015: -- [~andrey-kuznetsov] That's not acceptable case. We need successful run :) Master now seems to be green, please try again. > Test fail in Ignite Cache 2: > GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform > -- > > Key: IGNITE-6015 > URL: https://issues.apache.org/jira/browse/IGNITE-6015 > Project: Ignite > Issue Type: Test >Affects Versions: 2.1 >Reporter: Dmitriy Govorukhin >Assignee: Andrey Kuznetsov > Labels: MakeTeamcityGreenAgain > Fix For: 2.4 > > > {code} > java.util.concurrent.TimeoutException: Test has been timed out > [test=testGetAndTransform, timeout=30] > at > org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at junit.framework.TestSuite.runTest(TestSuite.java:255) > at junit.framework.TestSuite.run(TestSuite.java:250) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82) > at > org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at
[jira] [Comment Edited] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy
[ https://issues.apache.org/jira/browse/IGNITE-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268532#comment-16268532 ] Pavel Konstantinov edited comment on IGNITE-7041 at 11/28/17 10:51 AM: --- Already has a fix in branch https://issues.apache.org/jira/browse/IGNITE-6995 was (Author: pkonstantinov): Already fixed in issue https://issues.apache.org/jira/browse/IGNITE-6995 > Web Console: Incorrect code generation in case if cache has eviction policy > and near cache with eviction policy > --- > > Key: IGNITE-7041 > URL: https://issues.apache.org/jira/browse/IGNITE-7041 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov > > In case if cache has eviction policy and also near cache configuration with > eviction policy then generated code contains an error - the same variable is > used to define two different eviction policy types > {code} > public static CacheConfiguration cacheDepartmentCache() throws Exception { > CacheConfiguration ccfg = new CacheConfiguration(); > > . > LruEvictionPolicy evictionPlc = new LruEvictionPolicy(); > evictionPlc.setBatchSize(5); > evictionPlc.setMaxSize(100); > ccfg.setEvictionPolicy(evictionPlc); > > . > NearCacheConfiguration nearConfiguration = new > NearCacheConfiguration(); > nearConfiguration.setNearStartSize(4545); > evictionPlc = new SortedEvictionPolicy();- THIS ROW IS > INCORRECT > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7042) Test written in scala doesn't executed on TC
Nikolay Izhikov created IGNITE-7042: --- Summary: Test written in scala doesn't executed on TC Key: IGNITE-7042 URL: https://issues.apache.org/jira/browse/IGNITE-7042 Project: Ignite Issue Type: Bug Components: spark Affects Versions: 2.3 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Priority: Minor Fix For: 2.4 Tests from module `spark` and `spark_2.10` written in scala don't executes on TC. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (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=16264488#comment-16264488 ] Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 10:39 AM: - While implementing the task i rely on the following 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). Do you think its correct? was (Author: alexey kuznetsov): While implementing the task i rely on the following 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). Do you think its correct? > 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.4 > > > {{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 (v6.4.14#64029)
[jira] [Comment Edited] (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=16264488#comment-16264488 ] Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 10:39 AM: - While implementing the task i rely on the following 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). Do you think its correct? was (Author: alexey kuznetsov): 1)When entry is updated, both 'invoke update' and get\put\remove metrics can be updated. 2)When entry processor is invoked, but cache entry isn't affected, then invoke metric isn't incremented. 3)'invoke update' metrics incremented only when cache entry value is changed(or removed) by entry processor(not just when entry processor is invoked). 4)If entry processor process(...) is called once, and multiple entries(perhaps on different nodes) are affected, then local invoke metric is incremented only once, cluster global metric is incremented once, local metrics on other nodes are zero. 5)Read-only 'invoke' metric is incremented if processor invoke operation is called without executing entry.setValue(...) (even calling entry.getValue() can be omit), processor can return non-null value.Also, cache might be empty while processor invocation. 6)'invoke removal' metric is incremented only if old cache value exists and removal succeedes. 7)The following metrics are going to be added : total number of invokes, number of invoke updates, number of invoke removals, number of read-only invokes, min\max\avg number of invocations(all invocations). > 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.4 > > > {{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 (v6.4.14#64029)
[jira] [Commented] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy
[ https://issues.apache.org/jira/browse/IGNITE-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268532#comment-16268532 ] Pavel Konstantinov commented on IGNITE-7041: Already fixed in issue https://issues.apache.org/jira/browse/IGNITE-6995 > Web Console: Incorrect code generation in case if cache has eviction policy > and near cache with eviction policy > --- > > Key: IGNITE-7041 > URL: https://issues.apache.org/jira/browse/IGNITE-7041 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov > > In case if cache has eviction policy and also near cache configuration with > eviction policy then generated code contains an error - the same variable is > used to define two different eviction policy types > {code} > public static CacheConfiguration cacheDepartmentCache() throws Exception { > CacheConfiguration ccfg = new CacheConfiguration(); > > . > LruEvictionPolicy evictionPlc = new LruEvictionPolicy(); > evictionPlc.setBatchSize(5); > evictionPlc.setMaxSize(100); > ccfg.setEvictionPolicy(evictionPlc); > > . > NearCacheConfiguration nearConfiguration = new > NearCacheConfiguration(); > nearConfiguration.setNearStartSize(4545); > evictionPlc = new SortedEvictionPolicy();- THIS ROW IS > INCORRECT > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy
Pavel Konstantinov created IGNITE-7041: -- Summary: Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy Key: IGNITE-7041 URL: https://issues.apache.org/jira/browse/IGNITE-7041 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov In case if cache has eviction policy and also near cache configuration with eviction policy then generated code contains an error - the same variable is used to define two different eviction policy types {code} public static CacheConfiguration cacheDepartmentCache() throws Exception { CacheConfiguration ccfg = new CacheConfiguration(); . LruEvictionPolicy evictionPlc = new LruEvictionPolicy(); evictionPlc.setBatchSize(5); evictionPlc.setMaxSize(100); ccfg.setEvictionPolicy(evictionPlc); . NearCacheConfiguration nearConfiguration = new NearCacheConfiguration(); nearConfiguration.setNearStartSize(4545); evictionPlc = new SortedEvictionPolicy();- THIS ROW IS INCORRECT {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite
[ https://issues.apache.org/jira/browse/IGNITE-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268523#comment-16268523 ] Nikolay Izhikov commented on IGNITE-3084: - We can't have IgniteCatalog for 2.1 version of spark. So I propose to update spark dependencies for module {{spark}} to 2.2.0 in this task. 1. To setup IgniteCatalog we need to override `SharedState.externalCatalog` val. So spark can lookup Ignite tables. 2. externalCatalog is null while SharedState instance initialized. [https://docs.scala-lang.org/tutorials/FAQ/initialization-order.html] 3. externalCatalog is used in internal initializer - [SharedState.scala|https://github.com/apache/spark/blob/v2.1.2/sql/core/src/main/scala/org/apache/spark/sql/internal/SharedState.scala#L96] 4. In 2.2.0 version SharedState.scala fixed in the way that allow override of externalCatalog - [SharedState-2.2.0|https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/internal/SharedState.scala#L93] {code:scala} { val defaultDbDefinition = CatalogDatabase( SessionCatalog.DEFAULT_DATABASE, "default database", warehousePath, Map()) if (!externalCatalog.databaseExists(SessionCatalog.DEFAULT_DATABASE)) { // <-- Problem is here! externalCatalog == null if we override it. externalCatalog.createDatabase(defaultDbDefinition, ignoreIfExists = true) } } {code} > Spark Data Frames Support in Apache Ignite > -- > > Key: IGNITE-3084 > URL: https://issues.apache.org/jira/browse/IGNITE-3084 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Nikolay Izhikov > Labels: bigdata > Fix For: 2.4 > > > Apache Spark already benefits from integration with Apache Ignite. The latter > provides shared RDDs, an implementation of Spark RDD, that help Spark to > share a state between Spark workers and execute SQL queries much faster. The > next logical step is to enable support for modern Spark Data Frames API in a > similar way. > As a contributor, you will be fully in charge of the integration of Spark > Data Frame API and Apache Ignite. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.
[ https://issues.apache.org/jira/browse/IGNITE-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268519#comment-16268519 ] Vasiliy Sisko commented on IGNITE-6995: --- Implemented configuration of eviction policy by factory. > Visor CMD: Actualize showed grid/cache configuration. > - > > Key: IGNITE-6995 > URL: https://issues.apache.org/jira/browse/IGNITE-6995 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko > > Actualise in accordance to IGNITE-6649 changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.
[ https://issues.apache.org/jira/browse/IGNITE-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-6995: - Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Visor CMD: Actualize showed grid/cache configuration. > - > > Key: IGNITE-6995 > URL: https://issues.apache.org/jira/browse/IGNITE-6995 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > > Actualise in accordance to IGNITE-6649 changes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7011) Web console: add more tests
[ https://issues.apache.org/jira/browse/IGNITE-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-7011: - Description: Web console does not have enough test coverage, let's fix that. Rough plan: 1. Choose E2E testing framework. 2. Investigate/implement mechanism for reproducible test environment (backend DB, running web-agent and Ignite clusters). 3. Write some reproducible tests. 4. Setup CI. was:Web console does not have enough test coverage, let's fix that. > Web console: add more tests > --- > > Key: IGNITE-7011 > URL: https://issues.apache.org/jira/browse/IGNITE-7011 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > Web console does not have enough test coverage, let's fix that. > Rough plan: > 1. Choose E2E testing framework. > 2. Investigate/implement mechanism for reproducible test environment (backend > DB, running web-agent and Ignite clusters). > 3. Write some reproducible tests. > 4. Setup CI. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7012) Web console: investigate E2E tests
[ https://issues.apache.org/jira/browse/IGNITE-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-7012: - Description: Investigate what tools we can use to implement E2E tests and try some of them out. I think that testcafe will be a good start: https://github.com/DevExpress/testcafe https://github.com/DevExpress/testcafe-angular-selectors http://devexpress.github.io/testcafe/documentation/test-api/authentication/user-roles.html was: Investigate what tools we can use to implement E2E tests and try some of them out. I think that testcafe will be a good start: https://github.com/DevExpress/testcafe https://github.com/DevExpress/testcafe-angular-selectors > Web console: investigate E2E tests > -- > > Key: IGNITE-7012 > URL: https://issues.apache.org/jira/browse/IGNITE-7012 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > > Investigate what tools we can use to implement E2E tests and try some of them > out. I think that testcafe will be a good start: > https://github.com/DevExpress/testcafe > https://github.com/DevExpress/testcafe-angular-selectors > http://devexpress.github.io/testcafe/documentation/test-api/authentication/user-roles.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on
[ https://issues.apache.org/jira/browse/IGNITE-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-4454: Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Merged to master. > Web console: add information on query panel UI about node query was executed > on > > > Key: IGNITE-4454 > URL: https://issues.apache.org/jira/browse/IGNITE-4454 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.4 > > > Currently we show only query text and do not show node in case of 'Execute > on selected node' -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16268459#comment-16268459 ] Michael Griggs commented on IGNITE-6069: It is essential that server nodes must need to be stopped in order to deploy a new service. This implies that we have peer-class loading for Service interfaces and implementations. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6987) Visor CMD: Config command should show client connector pool size.
[ https://issues.apache.org/jira/browse/IGNITE-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6987: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good. Please test in branch ignite-6987. > Visor CMD: Config command should show client connector pool size. > - > > Key: IGNITE-6987 > URL: https://issues.apache.org/jira/browse/IGNITE-6987 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > Now show size for deprecated SqlConnectorConfiguration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.
[ https://issues.apache.org/jira/browse/IGNITE-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-6999: Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Looks good for me. Please test. > Add a flag for Visor batch mode to output only command results without > additional info. > --- > > Key: IGNITE-6999 > URL: https://issues.apache.org/jira/browse/IGNITE-6999 > Project: Ignite > Issue Type: New Feature > Components: visor >Affects Versions: 2.1 >Reporter: Alexandr Fedotov >Assignee: Pavel Konstantinov > Fix For: 2.4 > > > Currently, in batch mode, Visor Command Line simply run supplied commands one > by one as if they were entered from the keyboard which results in a quite > verbose output. > A new flag should be introduced like {{--silent}} to suppress additional info > output and left only output related directly to the executed commands. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7024) Introduce some kind of network compression
[ https://issues.apache.org/jira/browse/IGNITE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-7024: --- Fix Version/s: 2.4 > Introduce some kind of network compression > -- > > Key: IGNITE-7024 > URL: https://issues.apache.org/jira/browse/IGNITE-7024 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita > Fix For: 2.4 > > > Introduce some kind of pluggable compression at network level > The main idea is using in-line compression and writes encoded bytes in > network channel by bytes array buffer. It allows us avoiding expensive > memory allocation. > A solution may be implemented at TcpCommunicationSpi level. > For example, introduce Compressor interface which will allow us to describe > our compression strategy, for example, exclude some small messages, choose > compression algorithm and other… -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7024) Introduce some kind of network compression
[ https://issues.apache.org/jira/browse/IGNITE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur updated IGNITE-7024: --- Affects Version/s: 2.3 > Introduce some kind of network compression > -- > > Key: IGNITE-7024 > URL: https://issues.apache.org/jira/browse/IGNITE-7024 > Project: Ignite > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita > Fix For: 2.4 > > > Introduce some kind of pluggable compression at network level > The main idea is using in-line compression and writes encoded bytes in > network channel by bytes array buffer. It allows us avoiding expensive > memory allocation. > A solution may be implemented at TcpCommunicationSpi level. > For example, introduce Compressor interface which will allow us to describe > our compression strategy, for example, exclude some small messages, choose > compression algorithm and other… -- This message was sent by Atlassian JIRA (v6.4.14#64029)