[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.
[ https://issues.apache.org/jira/browse/IGNITE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396575#comment-16396575 ] Vyacheslav Daradur commented on IGNITE-5357: [~NIzhikov], thank you so much. Latest ci.build: https://ci.ignite.apache.org/viewLog.html?buildId=1134466 > Replicated cache reads load balancing. > -- > > Key: IGNITE-5357 > URL: https://issues.apache.org/jira/browse/IGNITE-5357 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Currently all read requests from client node to replicated cache will go > through primary node for key. > Need to select random affinity node in topology and send request here (only > if readFromBackups=true) > If where are server nodes collocated on same host with client, must select > target node from them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7927) Web console: failed to execute query in demo
[ https://issues.apache.org/jira/browse/IGNITE-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-7927: --- Description: If I set 'Allow non-collocated joins' option for demo query {code} SELECT p.name, count(*) AS cnt FROM "ParkingCache".Parking p INNER JOIN "CarCache".Car c ON (p.id) = (c.parkingId) GROUP BY P.NAME {code} then I got the following error {code} Error: Failed to prepare distributed join query: join condition does not use index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME] {code} Please add necessary indices was: If I set 'Allow non-collocated joins' then I got the following error {code} Error: Failed to prepare distributed join query: join condition does not use index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME] {code} Please add necessary indices > Web console: failed to execute query in demo > > > Key: IGNITE-7927 > URL: https://issues.apache.org/jira/browse/IGNITE-7927 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > If I set 'Allow non-collocated joins' option for demo query > {code} > SELECT p.name, count(*) AS cnt > FROM "ParkingCache".Parking p > INNER JOIN "CarCache".Car c > ON (p.id) = (c.parkingId) > GROUP BY P.NAME > {code} > then I got the following error > {code} > Error: Failed to prepare distributed join query: join condition does not use > index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS > __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ > INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ > */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME] > {code} > Please add necessary indices -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7927) Web console: failed to execute query in demo
[ https://issues.apache.org/jira/browse/IGNITE-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7927: - Assignee: Vasiliy Sisko > Web console: failed to execute query in demo > > > Key: IGNITE-7927 > URL: https://issues.apache.org/jira/browse/IGNITE-7927 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Major > > If I set 'Allow non-collocated joins' option for demo query > {code} > SELECT p.name, count(*) AS cnt > FROM "ParkingCache".Parking p > INNER JOIN "CarCache".Car c > ON (p.id) = (c.parkingId) > GROUP BY P.NAME > {code} > then I got the following error > {code} > Error: Failed to prepare distributed join query: join condition does not use > index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS > __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ > INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ > */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME] > {code} > Please add necessary indices -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7927) Web console: failed to execute query in demo
Pavel Konstantinov created IGNITE-7927: -- Summary: Web console: failed to execute query in demo Key: IGNITE-7927 URL: https://issues.apache.org/jira/browse/IGNITE-7927 Project: Ignite Issue Type: Bug Reporter: Pavel Konstantinov If I set 'Allow non-collocated joins' then I got the following error {code} Error: Failed to prepare distributed join query: join condition does not use index [joinedCache=CarCache, plan=SELECT P__Z0.NAME AS __C0_0, COUNT(*) AS __C0_1 FROM "ParkingCache".PARKING P__Z0 /* "ParkingCache".PARKING.__SCAN_ */ INNER JOIN "CarCache".CAR C__Z1 /* batched:broadcast "CarCache".CAR.__SCAN_ */ ON 1=1 WHERE P__Z0.ID = C__Z1.PARKINGID GROUP BY P__Z0.NAME] {code} Please add necessary indices -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7926) Web console: demo faled to start under java 9
[ https://issues.apache.org/jira/browse/IGNITE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-7926: - Assignee: Vasiliy Sisko > Web console: demo faled to start under java 9 > - > > Key: IGNITE-7926 > URL: https://issues.apache.org/jira/browse/IGNITE-7926 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Pavel Konstantinov >Assignee: Vasiliy Sisko >Priority: Minor > Fix For: 2.5 > > > We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7926) Web console: demo faled to start under java 9
Pavel Konstantinov created IGNITE-7926: -- Summary: Web console: demo faled to start under java 9 Key: IGNITE-7926 URL: https://issues.apache.org/jira/browse/IGNITE-7926 Project: Ignite Issue Type: Bug Affects Versions: 2.4 Reporter: Pavel Konstantinov Fix For: 2.5 We need to add support for Java 9 to web console demo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4191) SQL: support transactions
[ https://issues.apache.org/jira/browse/IGNITE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396496#comment-16396496 ] Khaerul Rizal Damanik commented on IGNITE-4191: --- Hi Ignite Master, Is there any progress of this ticket? Or there are some patch for this ticket? I really need this features so much. > 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 >Priority: Major > 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 (v7.6.3#76005)
[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16396278#comment-16396278 ] Turik Campbell commented on IGNITE-7916: My Github email is presently [ad...@techbysample.com.|mailto:ad...@techbysample.com.] It's seems that Team City is stripping the domain from my GIT hub email address. Does Team City only read the email address? ... Can it be setup to use the Github username? My Github username is techbysample. > GA Grid examples should be ready for auto run on TeamCity > - > > Key: IGNITE-7916 > URL: https://issues.apache.org/jira/browse/IGNITE-7916 > Project: Ignite > Issue Type: Bug > Components: examples, ml >Reporter: Yury Babak >Assignee: Turik Campbell >Priority: Critical > Labels: MakeTeamcityGreenAgain > > If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, > this examples will return exit code 1. TeamCity think that it's a error and > mark stop whole build of examples package. > That behavior should be changed. If we don't have required system properties > we should not return exit code 1 or maybe set and use some default values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7917) Thin client: document missing data types
[ https://issues.apache.org/jira/browse/IGNITE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395798#comment-16395798 ] Denis Magda commented on IGNITE-7917: - [~pgarg], please document the missed types. > Thin client: document missing data types > > > Key: IGNITE-7917 > URL: https://issues.apache.org/jira/browse/IGNITE-7917 > Project: Ignite > Issue Type: Task > Components: documentation, thin client >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.5 > > > Docs page: > https://apacheignite.readme.io/docs/binary-client-protocol#data-format > Missing data types: > COL = 24 > ENUM = 28 > ENUM_ARR = 29 > DECIMAL = 30 > DECIMAL_ARR = 31 > TIMESTAMP = 33 > TIMESTAMP_ARR = 34 > TIME = 36 > TIME_ARR = 37 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7917) Thin client: document missing data types
[ https://issues.apache.org/jira/browse/IGNITE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-7917: --- Assignee: Prachi Garg > Thin client: document missing data types > > > Key: IGNITE-7917 > URL: https://issues.apache.org/jira/browse/IGNITE-7917 > Project: Ignite > Issue Type: Task > Components: documentation, thin client >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.5 > > > Docs page: > https://apacheignite.readme.io/docs/binary-client-protocol#data-format > Missing data types: > COL = 24 > ENUM = 28 > ENUM_ARR = 29 > DECIMAL = 30 > DECIMAL_ARR = 31 > TIMESTAMP = 33 > TIMESTAMP_ARR = 34 > TIME = 36 > TIME_ARR = 37 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7925) Rewrite MemoryEventStorageSpi and remove ConcurrentLinkedDeque8 usages
Andrey Gura created IGNITE-7925: --- Summary: Rewrite MemoryEventStorageSpi and remove ConcurrentLinkedDeque8 usages Key: IGNITE-7925 URL: https://issues.apache.org/jira/browse/IGNITE-7925 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura {{MemoryEventStorageSpi}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{peekx}} methods. Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7924) Rewrite IgfsServer and remove ConcurrentLinkedDeque8 usages
Andrey Gura created IGNITE-7924: --- Summary: Rewrite IgfsServer and remove ConcurrentLinkedDeque8 usages Key: IGNITE-7924 URL: https://issues.apache.org/jira/browse/IGNITE-7924 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura {{IgfsServer}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{addx}} methods. Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7923) Rewrite IgfsPerBlockLruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usage
Andrey Gura created IGNITE-7923: --- Summary: Rewrite IgfsPerBlockLruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usage Key: IGNITE-7923 URL: https://issues.apache.org/jira/browse/IGNITE-7923 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura {{IgfsPerBlockLruEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7921) Rewrite FifoEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages
[ https://issues.apache.org/jira/browse/IGNITE-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-7921: Description: {{FifoEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. was: {{FifoEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. > Rewrite FifoEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages > --- > > Key: IGNITE-7921 > URL: https://issues.apache.org/jira/browse/IGNITE-7921 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Priority: Major > > {{FifoEvictionPolicy}} should be rewritten without outdated > {{ConcurrentLinkedDeque8}}. > At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to > usages of {{unlinkx}} and {{offerLastx}} methods. > Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7922) Rewrite LruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages
[ https://issues.apache.org/jira/browse/IGNITE-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-7922: Description: {{LruEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. was: {{LruEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. > Rewrite LruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages > -- > > Key: IGNITE-7922 > URL: https://issues.apache.org/jira/browse/IGNITE-7922 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Gura >Priority: Major > > {{LruEvictionPolicy}} should be rewritten without outdated > {{ConcurrentLinkedDeque8}}. > At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to > usages of {{unlinkx}} and {{offerLastx}} methods. > Use {{FastSizeDeque}} wrapper in order to get rid of {{sizex}} calls. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7922) Rewrite LruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages
Andrey Gura created IGNITE-7922: --- Summary: Rewrite LruEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages Key: IGNITE-7922 URL: https://issues.apache.org/jira/browse/IGNITE-7922 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura {{LruEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7921) Rewrite FifoEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages
Andrey Gura created IGNITE-7921: --- Summary: Rewrite FifoEvictionPolicy and get rid of ConcurrentLinkedDeque8 usages Key: IGNITE-7921 URL: https://issues.apache.org/jira/browse/IGNITE-7921 Project: Ignite Issue Type: Improvement Reporter: Andrey Gura {{FifoEvictionPolicy}} should be rewritten without outdated {{ConcurrentLinkedDeque8}}. At present we can't just remove usages of {{ConcurrentLinkedDeque8}} due to usages of {{unlinkx}} and {{offerLastx}} methods. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange
[ https://issues.apache.org/jira/browse/IGNITE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395639#comment-16395639 ] ASF GitHub Bot commented on IGNITE-6827: GitHub user ascherbakoff opened a pull request: https://github.com/apache/ignite/pull/3624 IGNITE-6827 IGNITE-6827 Configurable rollback for long running transactions before partition exchange. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6827-2 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3624.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 #3624 commit 99a05f50be24a6dbebe6e9a3cd57513a1dbeb4fb Author: Aleksei ScherbakovDate: 2017-12-06T11:26:44Z IGNITE-6827 wip. commit 1e7ee0f0fd10e21b36cc57e1499358dd46c616b7 Author: Aleksei Scherbakov Date: 2017-12-06T14:34:25Z IGNITE-6827 wip. commit 0b0c0ff5f736b6cb299bf8ee32d6705d3c2adfb2 Author: Aleksei Scherbakov Date: 2017-12-06T14:47:13Z IGNITE-6827 wip. commit 2e7e7a2eca9b45ca1488403d86c28df055d215a7 Author: Aleksei Scherbakov Date: 2017-12-06T15:01:37Z IGNITE-6827 wip. commit 50dbdb8f14751f470f605884f195256531f4176f Author: Aleksei Scherbakov Date: 2017-12-06T15:04:40Z IGNITE-6827 wip. commit 4da15f51af7302dc70fa5ee705042dec36cb120b Author: Aleksei Scherbakov Date: 2017-12-06T16:46:22Z IGNITE-6827 wip. commit bc024837e12627a011c8a1b43f30783bb3b08f2d Author: Aleksei Scherbakov Date: 2017-12-06T17:11:04Z IGNITE-6827 wip. commit 8f5693361b018ee78ca7b6fd9a9e4d88017a87ea Author: ascherbakoff Date: 2017-12-06T21:05:42Z IGNITE-6827 wip. commit c4b9fab158769fb21e7dbbb641746868698a6652 Author: Aleksei Scherbakov Date: 2017-12-07T11:23:25Z IGNITE-6827 wip. commit f0a6113798df0e20e2d3b4a5573a5c722a2fd948 Author: Aleksei Scherbakov Date: 2017-12-07T11:27:16Z IGNITE-6827 wip. commit 5d9d22c7cb27c39516d0340ab72fa0a4f56e004b Author: Aleksei Scherbakov Date: 2017-12-07T11:46:21Z IGNITE-6827 wip. commit a008c220923d95155285b3408945f6e2c94104e5 Author: Aleksei Scherbakov Date: 2017-12-07T13:47:40Z IGNITE-6827 wip. commit f0ba7bd90ab16f0933353901fd73586e998443ba Author: Aleksei Scherbakov Date: 2017-12-07T14:05:14Z IGNITE-6827 wip. commit 7c6542553f041339f712bbde1541aa54c9418ed9 Author: Aleksei Scherbakov Date: 2017-12-07T17:10:24Z IGNITE-6827 wip. commit 91545f3bc98fc6c58d42d87fc0edd70abcb398d6 Author: Aleksei Scherbakov Date: 2017-12-07T17:21:46Z IGNITE-6827 wip. commit 663889d8c242c2681524cd11878838fb8b2f11ab Author: Aleksei Scherbakov Date: 2017-12-08T10:28:49Z IGNITE-6827 wip. commit 7da5e9582a995c39d0fa9cc6aa7e42d44eaf2d3f Author: Aleksei Scherbakov Date: 2017-12-08T16:22:23Z IGNITE-6827 wip. commit 65023a5b4983b871e0a8522e1493c285ab75b07d Author: Aleksei Scherbakov Date: 2017-12-08T16:28:21Z IGNITE-6827 wip. commit 5951ff5e2a72293577392aea84582f8831c37163 Author: Aleksei Scherbakov Date: 2017-12-08T16:52:50Z IGNITE-6827 wip. commit 35aeeb2bf0f671569979e1782832a1371c479791 Author: Aleksei Scherbakov Date: 2017-12-08T17:19:12Z IGNITE-6827 wip. commit fb9779e12ecaa27a1a00a2eac97747f2e7175c32 Author: ascherbakoff Date: 2017-12-09T13:31:29Z IGNITE-6827 wip. commit 327eb805aad6f2608e6af8032a9a5e7c67c47c20 Author: ascherbakoff Date: 2017-12-09T13:32:03Z IGNITE-6827 wip. commit 00f9b695d46886c89087b0061701a42429abb05e Author: ascherbakoff Date: 2017-12-09T14:06:07Z IGNITE-6827 wip. commit 5cd8fa0a34c34529cde58f859a6fd82955c3d57c Author: ascherbakoff Date: 2017-12-09T14:29:38Z IGNITE-6827 wip. commit 27f38f24992e2eb2d1418e503a3cd39b581dd2e0 Author: ascherbakoff Date: 2017-12-09T14:54:04Z IGNITE-6827 wip. commit 9d47569d4a28125fefb4781c70855ca14a2c1c6c Author: ascherbakoff Date: 2017-12-09T15:09:04Z IGNITE-6827 wip. commit 50a545a01cb1d7a3c015196dd4384d77010fdee3 Author: ascherbakoff Date: 2017-12-09T15:25:07Z IGNITE-6827 wip. commit 0b90e453bd6036528ccf6723340220dc4acde4be Author: ascherbakoff
[jira] [Commented] (IGNITE-5580) Improve node failure cause information
[ https://issues.apache.org/jira/browse/IGNITE-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395634#comment-16395634 ] Andrey Gura commented on IGNITE-5580: - [~SomeFire], [~agoncharuk], I think that issue scope is too broad and it should be separated to different issue on order to make scope management easier. Anyway I have some comments about this changes: * Events gathering approach is too specific and can be generalized because, I believe, it can be used by other components. * {{latestEventsString()}} method on {{DiscoverySpi}} looks strange for me. Moreover, this method does too many things: retrieves events and makes string. * {{ConcurrentLinkedQueue}} isn't good choice for event storage. Method {{size()}} has O( n) complexity and contention is possible on event adding/removing. IMO, circular buffer is more suitable data structure in this case. * Events gathering is always switched on. I think we should provide possibility to switch on/off this feature at runtime. We can start discussion here or on dev list. [~agoncharuk] I think that existing IEPs don't fit to this problem and new IEP should be initiated. > Improve node failure cause information > -- > > Key: IGNITE-5580 > URL: https://issues.apache.org/jira/browse/IGNITE-5580 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Ryabov Dmitrii >Priority: Major > Labels: observability > Fix For: 2.5 > > > When a node fails, we do not print out any information about the root cause > of this failure. This makes it extremely hard to investigate the failure > causes - I need to find a previous node for the failed node and check the > logs on the previous node. > I suggest that we add extensive information about the reason of the node > failure and the sequence of events that led to this, e.g.: > [time] [NODE] Sending a message to next node - failed _because_ - write > timeout, read timeout, ...? > [time] [NODE] Connection check - failed - why? Connection refused, handshake > timed out, ...? > ... > [time] [NODE] Decided to drop the node because of the sequence above > Maybe we do not need to print out this information always, but we do need > this when troubleshooting logger is enabled. > Also, DiscoverySpi should collect a set of latest important events and dump > these events in case of local node segmentation. This will allow users to > match the events in the cluster and events on local node and get to the > bottom of the failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7765) walSegmentSize can be negative in config
[ https://issues.apache.org/jira/browse/IGNITE-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395571#comment-16395571 ] ASF GitHub Bot commented on IGNITE-7765: GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/3623 IGNITE-7765 ensure that walSegmentSize doesn't overflow You can merge this pull request into a Git repository by running: $ git pull https://github.com/ivandasch/ignite ignite-7765 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3623.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 #3623 commit 6e2adf9335885d3132be7712bb48e9c408b111b2 Author: Ivan DaschinskiyDate: 2018-03-12T16:08:48Z IGNITE-7765 ensure that walSegmentSize doesn't overflow > walSegmentSize can be negative in config > > > Key: IGNITE-7765 > URL: https://issues.apache.org/jira/browse/IGNITE-7765 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.2 >Reporter: Alexander Belyak >Assignee: Ivan Daschinskiy >Priority: Trivial > Fix For: 2.5 > > > Grid use default (64Mb) DataStorageConfiguration.walSegmentSize without > warnings if negative value specified, for example if in xml specified > something like > (overflow) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6140) JDBC thin: implement DataSource interface
[ https://issues.apache.org/jira/browse/IGNITE-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6140: Fix Version/s: 2.5 > JDBC thin: implement DataSource interface > - > > Key: IGNITE-6140 > URL: https://issues.apache.org/jira/browse/IGNITE-6140 > Project: Ignite > Issue Type: Task > Components: jdbc >Affects Versions: 2.1 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.5 > > > Implemented {{DataSource}} interface is required for JDBC compliance. > Also it us useful for external connection pool implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5357) Replicated cache reads load balancing.
[ https://issues.apache.org/jira/browse/IGNITE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395446#comment-16395446 ] Nikolay Izhikov commented on IGNITE-5357: - [~ascherbakov] I've reviewed update PR one more time. looks good to me. [~daradurvs] Please, provide TC link for current PR changes. > Replicated cache reads load balancing. > -- > > Key: IGNITE-5357 > URL: https://issues.apache.org/jira/browse/IGNITE-5357 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Alexei Scherbakov >Assignee: Vyacheslav Daradur >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Currently all read requests from client node to replicated cache will go > through primary node for key. > Need to select random affinity node in topology and send request here (only > if readFromBackups=true) > If where are server nodes collocated on same host with client, must select > target node from them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed
[ https://issues.apache.org/jira/browse/IGNITE-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395417#comment-16395417 ] Dmitriy Pavlov commented on IGNITE-7756: Hi [~vozerov], kindly reminder, please respond. > Streamer fails if IgniteUuid is indexed > --- > > Key: IGNITE-7756 > URL: https://issues.apache.org/jira/browse/IGNITE-7756 > Project: Ignite > Issue Type: Bug > Components: streaming >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.5 > > > IgniteDataStreamer are failed to put data to the cache if IgniteUuid is > IndexedType. > Spark tests in IGNITE-7227 are failed because of this issue. > Reproducer: > {code:java} > public void testStreamer() throws Exception { > Ignite client = grid("client"); > CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE"); > ccfg.setIndexedTypes(IgniteUuid.class, String.class); > client.createCache(ccfg); > try(IgniteDataStreamercache = > client.dataStreamer("UUID_CACHE")) { > for(Integer i=0; i<2; i++) > cache.addData(IgniteUuid.randomUuid(), i.toString()); > } > } > {code} > Exception stack trace: > {noformat} > [23:43:35] (err) Failed to execute compound future reducer: > GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, > cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to > execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, > lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class > org.apache.ignite.IgniteCheckedException: DataStreamer request failed > [node=57961924-82ec-4d56-81eb-1a4109a0] > at > org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344) > at > org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554) > at > org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182) > at > org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125) > at > org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089) > at > org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499) > at java.lang.Thread.run(Thread.java:748) > Caused by: class org.apache.ignite.IgniteException: Failed to set initial > value for cache entry > at > org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59) > at > org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89) > ... 6 more > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update > index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, > actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl] > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954) > at > org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877) > at > org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207) > at > org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345) > at > org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527) > at >
[jira] [Commented] (IGNITE-7773) .NET: Add getRebalanceClearingPartitionsLeft JMX metric
[ https://issues.apache.org/jira/browse/IGNITE-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395386#comment-16395386 ] ASF GitHub Bot commented on IGNITE-7773: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3613 > .NET: Add getRebalanceClearingPartitionsLeft JMX metric > --- > > Key: IGNITE-7773 > URL: https://issues.apache.org/jira/browse/IGNITE-7773 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Pavel Kovalenko >Assignee: Alexey Goncharuk >Priority: Major > Labels: .NET, MakeTeamcityGreenAgain > Fix For: 2.5 > > > New metric is introduced in IGNITE-6113 . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes
[ https://issues.apache.org/jira/browse/IGNITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395377#comment-16395377 ] Denis Mekhanikov commented on IGNITE-7794: -- TC run results: https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3620%2Fhead > Marshaller mappings are not saved to disk on joining nodes > -- > > Key: IGNITE-7794 > URL: https://issues.apache.org/jira/browse/IGNITE-7794 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.5 > > Attachments: GridMarshallerMappingConsistencyTest.java > > > Find attached test class. > When a node connects to a cluster, that already has some marshaller mappings, > they are not saved to disk on the joining node. It may result in "Unknown > pair" error, if a cluster has persistence enabled, and a nodes without needed > mappings start and try to read persisted data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7920) Research local crash recovery speed after stop in the middle of checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395366#comment-16395366 ] Dmitriy Pavlov commented on IGNITE-7920: It is required to check if WAL iterator uses underlying buffer to read entries. It is also required to check if some information may be cached during restore, to avoid read twice. > Research local crash recovery speed after stop in the middle of checkpoint > -- > > Key: IGNITE-7920 > URL: https://issues.apache.org/jira/browse/IGNITE-7920 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > When using Ignite as a database on one node, I observed that the recovery > time using the WAL exceeds the time between checkpoints. > Ignite logs message that it is restored after stopping in the middle of the > checkpoint > I use the frequency of CP - setCheckpointFrequency (60 * 1000), but at server > with HDD and heavy IO load. At least 16 minutes required to restore Ignite > after stop. > Server monitoring states that high rate of IOPS ocurred and it is constraint > (there is plenty of CPU/RAM) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7920) Research local crash recovery speed after stop in the middle of checkpoint
Dmitriy Pavlov created IGNITE-7920: -- Summary: Research local crash recovery speed after stop in the middle of checkpoint Key: IGNITE-7920 URL: https://issues.apache.org/jira/browse/IGNITE-7920 Project: Ignite Issue Type: Task Components: persistence Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov When using Ignite as a database on one node, I observed that the recovery time using the WAL exceeds the time between checkpoints. Ignite logs message that it is restored after stopping in the middle of the checkpoint I use the frequency of CP - setCheckpointFrequency (60 * 1000), but at server with HDD and heavy IO load. At least 16 minutes required to restore Ignite after stop. Server monitoring states that high rate of IOPS ocurred and it is constraint (there is plenty of CPU/RAM) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7770) Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 removal
[ https://issues.apache.org/jira/browse/IGNITE-7770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395335#comment-16395335 ] ASF GitHub Bot commented on IGNITE-7770: GitHub user andrey-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/3622 IGNITE-7770 For TC tests only You can merge this pull request into a Git repository by running: $ git pull https://github.com/andrey-kuznetsov/ignite ignite-7770-0 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3622.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 #3622 commit 17726182fdb1a1cfa23c30732a3522d06f3fd423 Author: Andrey KuznetsovDate: 2018-03-12T14:43:42Z IGNITE-7770 Check for incomplete GFA unblock. > Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 > removal > > > Key: IGNITE-7770 > URL: https://issues.apache.org/jira/browse/IGNITE-7770 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain, Muted_test > Fix For: 2.5 > > > Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 > removal > After appying IGNITE-7518 Get rid of org.jsr166.LongAdder8, > IgniteCacheTestSuite6: > TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations (fail rate > 38,6%) > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3733584033131292028=%3Cdefault%3E=testDetails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura reassigned IGNITE-7912: --- Assignee: Ivan Daschinskiy > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Assignee: Ivan Daschinskiy >Priority: Minor > > We have to erase wal archive because wal archive can grow large and we must > have safe way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16395315#comment-16395315 ] Taras Ledkov commented on IGNITE-7029: -- [~vozerov], fixed. Please take a look. > 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, sql >Affects Versions: 2.3 >Reporter: Valentin Kulichenko >Assignee: Taras Ledkov >Priority: Major > > 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 (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7765) walSegmentSize can be negative in config
[ https://issues.apache.org/jira/browse/IGNITE-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura reassigned IGNITE-7765: --- Assignee: Ivan Daschinskiy > walSegmentSize can be negative in config > > > Key: IGNITE-7765 > URL: https://issues.apache.org/jira/browse/IGNITE-7765 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.2 >Reporter: Alexander Belyak >Assignee: Ivan Daschinskiy >Priority: Trivial > Fix For: 2.5 > > > Grid use default (64Mb) DataStorageConfiguration.walSegmentSize without > warnings if negative value specified, for example if in xml specified > something like > (overflow) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7765) walSegmentSize can be negative in config
[ https://issues.apache.org/jira/browse/IGNITE-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-7765: Fix Version/s: 2.5 > walSegmentSize can be negative in config > > > Key: IGNITE-7765 > URL: https://issues.apache.org/jira/browse/IGNITE-7765 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.2 >Reporter: Alexander Belyak >Priority: Trivial > Fix For: 2.5 > > > Grid use default (64Mb) DataStorageConfiguration.walSegmentSize without > warnings if negative value specified, for example if in xml specified > something like > (overflow) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7741) Fix javadoc for QR factorization
[ https://issues.apache.org/jira/browse/IGNITE-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak reassigned IGNITE-7741: -- Assignee: (was: Yury Babak) > Fix javadoc for QR factorization > > > Key: IGNITE-7741 > URL: https://issues.apache.org/jira/browse/IGNITE-7741 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Priority: Minor > > Wrong javadoc for QR factorization. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7757) Unable to create a new cache via REST in special case
[ https://issues.apache.org/jira/browse/IGNITE-7757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395239#comment-16395239 ] Andrey Gura commented on IGNITE-7757: - [~pkonstantinov] Could you please describe expected behaviour for this case? > Unable to create a new cache via REST in special case > - > > Key: IGNITE-7757 > URL: https://issues.apache.org/jira/browse/IGNITE-7757 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Konstantinov >Priority: Major > > 1. try to start a new cache with non-existing data region > {code} > localhost:8080/ignite?cmd=getorcreate=cache1= > {code} > You will get correct error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} > 2. then edit your request and make it correct and try again > {code} > localhost:8080/ignite?cmd=getorcreate=cache1 > {code} > You will get the same error message > {code} > "Failed to handle request: [req=GET_OR_CREATE_CACHE, err=Requested DataRegion > is not configured: ]" > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7319) Memory leak during creating/destroying local cache
[ https://issues.apache.org/jira/browse/IGNITE-7319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7319: -- Attachment: Demo.java > Memory leak during creating/destroying local cache > -- > > Key: IGNITE-7319 > URL: https://issues.apache.org/jira/browse/IGNITE-7319 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.5 > > Attachments: Demo.java > > > The following code creates local caches: > {code} > private IgniteCachecreateLocalCache(String name) { > CacheConfiguration cCfg = new > CacheConfiguration<>(); > cCfg.setName(name); > cCfg.setGroupName("localCaches"); // without group leak is much > bigger! > cCfg.setStoreKeepBinary(true); > cCfg.setCacheMode(CacheMode.LOCAL); > cCfg.setOnheapCacheEnabled(false); > cCfg.setCopyOnRead(false); > cCfg.setBackups(0); > cCfg.setWriteBehindEnabled(false); > cCfg.setReadThrough(false); > cCfg.setReadFromBackup(false); > cCfg.setQueryEntities(); > return ignite.createCache(cCfg).withKeepBinary(); > } > {code} > The caches are placed in the queue and are picked up by the worker thread > which just destroys them after removing from the queue. > This setup seems to generate a memory leak of about 1GB per day. > When looking at heap dump, I see all space is occupied by instances of > java.util.concurrent.ConcurrentSkipListMap$Node. > User list: > http://apache-ignite-users.70518.x6.nabble.com/Memory-leak-in-GridCachePartitionExchangeManager-tt18995.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7741) Fix javadoc for QR factorization
[ https://issues.apache.org/jira/browse/IGNITE-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak reassigned IGNITE-7741: -- Assignee: Yury Babak > Fix javadoc for QR factorization > > > Key: IGNITE-7741 > URL: https://issues.apache.org/jira/browse/IGNITE-7741 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Minor > > Wrong javadoc for QR factorization. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7383) Failed to restore memory after cluster restart and activating from outdated node
[ https://issues.apache.org/jira/browse/IGNITE-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395211#comment-16395211 ] Ilya Lantukh commented on IGNITE-7383: -- This problem is more fundamental. We don't have any ability to decide which stored configuration is more up-to-date and should be applied, so we simply enforce configuration from activated node. If we want to change it in future, we have to introduce some kind of versioning mechanic for stored configurations. > Failed to restore memory after cluster restart and activating from outdated > node > > > Key: IGNITE-7383 > URL: https://issues.apache.org/jira/browse/IGNITE-7383 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3 >Reporter: Alexandr Kuramshin >Assignee: Alexandr Kuramshin >Priority: Major > > Do the following steps for reproducing the problem: > 1) start nodes 0-1-2 > 2) stop node 2 > 3) create a new cache and put some data into it > 4) stop remaining nodes 0-1 > 5) start nodes 0-1-2 > 6) activate the cluster from the node 2 > Then 2 different results could be taken depending on which node is > coordinator: > a) node 2 is a coordinator: > {noformat} > Failed to activate node components > [nodeId=42d762c7-b1e0-4283-939b-aeeb3c70, client=false, > topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]] > class org.apache.ignite.IgniteCheckedException: Failed to find cache group > descriptor [grpId=3119] > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544) > at > org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279) > at > org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > {noformat} > and activation will be failed. > b) node 2 is NOT a coordinator: > we will get an error from the previous version, but the activation process > will not be failed and then we will take "Failed to wait PME" after a number > of assertions > {noformat} > Failed to process message [senderId=a940742f-bf17-41b4-bfc2-728bee72, > messageType=class > o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage] > java.lang.AssertionError: -2100569601 > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:733) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:2877) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1935) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1810) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1798) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353) > at > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1798) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484) > at >
[jira] [Commented] (IGNITE-7876) [ML] Adopt SVM Linear Binary Classification Model and Trainer to the new Partitioned Dataset
[ https://issues.apache.org/jira/browse/IGNITE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395167#comment-16395167 ] ASF GitHub Bot commented on IGNITE-7876: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3607 > [ML] Adopt SVM Linear Binary Classification Model and Trainer to the new > Partitioned Dataset > > > Key: IGNITE-7876 > URL: https://issues.apache.org/jira/browse/IGNITE-7876 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7881) Add tests for using TreeMap/TreeSet in cache key
[ https://issues.apache.org/jira/browse/IGNITE-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395145#comment-16395145 ] Andrey Gura commented on IGNITE-7881: - [~ilyak] Thanks for your contribution! > Add tests for using TreeMap/TreeSet in cache key > > > Key: IGNITE-7881 > URL: https://issues.apache.org/jira/browse/IGNITE-7881 > Project: Ignite > Issue Type: Task > Components: binary, cache >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.5 > > > It came to our attention that in Ignite 1.x, [Binary]TreeMap/TreeSet could > not be used in cache keys without configuration or code changes, since > equality won't work correctly for them. > It was since fixed by IGNITE-4558, but test cases won't hurt to nail this > behaviour fast. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7881) Add tests for using TreeMap/TreeSet in cache key
[ https://issues.apache.org/jira/browse/IGNITE-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395143#comment-16395143 ] Andrey Gura commented on IGNITE-7881: - [~dpavlov] This change adds a couple tests and doesn't affect other tests. > Add tests for using TreeMap/TreeSet in cache key > > > Key: IGNITE-7881 > URL: https://issues.apache.org/jira/browse/IGNITE-7881 > Project: Ignite > Issue Type: Task > Components: binary, cache >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.5 > > > It came to our attention that in Ignite 1.x, [Binary]TreeMap/TreeSet could > not be used in cache keys without configuration or code changes, since > equality won't work correctly for them. > It was since fixed by IGNITE-4558, but test cases won't hurt to nail this > behaviour fast. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both
[ https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395134#comment-16395134 ] Ivan Rakov commented on IGNITE-7902: I guess, we can just throw checked exception from IgniteCacheDatabaseSharedManager#validateConfiguration if swap and persistence are both configured. > Enable either swap space or persistence but not both > - > > Key: IGNITE-7902 > URL: https://issues.apache.org/jira/browse/IGNITE-7902 > Project: Ignite > Issue Type: Task >Reporter: Prachi Garg >Assignee: Ivan Rakov >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Enabling both swap and persistence at the same time for a data region does > not make sense. An exception should be thrown in this case. > See discussion - > http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7918: -- Attachment: MemLeak-Ignite.png > Huge memory leak when data streamer used together with local cache > -- > > Key: IGNITE-7918 > URL: https://issues.apache.org/jira/browse/IGNITE-7918 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Zbyszek B >Priority: Blocker > Attachments: Demo.java, MemLeak-Ignite.png, MemLeak-Ignite.txt > > > Dear Igniters, > We observe huge memory leak when data streamer used together with local cache. > In the attached demo producer produces local cache with single binary object > and passes this to the queue. Consumer picks up the cache from the queue, > constructs different binary object from it, adds it to global partitioned > cache and destroys local cache. > This design causes a significant leak - the whole heap it takes within > minutes (no matter if this is 4G or 24G). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7918: -- Description: Dear Igniters, We observe huge memory leak when data streamer used together with local cache. In the attached demo producer produces local cache with single binary object and passes this to the queue. Consumer picks up the cache from the queue, constructs different binary object from it, adds it to global partitioned cache and destroys local cache. This design causes a significant leak - the whole heap it takes within minutes (no matter if this is 4G or 24G). was: Dear Igniters, We observe huge memory leak when data streamer used together with local cache. In the attached demo producer produces local cache with single binary object and passes this to queue. Consumer picks up the cache from the queue, constructs different binary object from it, adds it to global partitioned cache and destroys local cache. This design causes a significant leak - the whole heap it takes within minutes (no matter if this is 4G or 24G). > Huge memory leak when data streamer used together with local cache > -- > > Key: IGNITE-7918 > URL: https://issues.apache.org/jira/browse/IGNITE-7918 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Zbyszek B >Priority: Blocker > Attachments: Demo.java, MemLeak-Ignite.txt > > > Dear Igniters, > We observe huge memory leak when data streamer used together with local cache. > In the attached demo producer produces local cache with single binary object > and passes this to the queue. Consumer picks up the cache from the queue, > constructs different binary object from it, adds it to global partitioned > cache and destroys local cache. > This design causes a significant leak - the whole heap it takes within > minutes (no matter if this is 4G or 24G). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7902) Enable either swap space or persistence but not both
[ https://issues.apache.org/jira/browse/IGNITE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov updated IGNITE-7902: --- Labels: newbie (was: ) > Enable either swap space or persistence but not both > - > > Key: IGNITE-7902 > URL: https://issues.apache.org/jira/browse/IGNITE-7902 > Project: Ignite > Issue Type: Task >Reporter: Prachi Garg >Assignee: Ivan Rakov >Priority: Major > Labels: newbie > Fix For: 2.5 > > > Enabling both swap and persistence at the same time for a data region does > not make sense. An exception should be thrown in this case. > See discussion - > http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7919) Handle IO errors while checkpointing, rework.
Stanilovsky Evgeny created IGNITE-7919: -- Summary: Handle IO errors while checkpointing, rework. Key: IGNITE-7919 URL: https://issues.apache.org/jira/browse/IGNITE-7919 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.4 Reporter: Stanilovsky Evgeny Assignee: Pavel Kovalenko Fix from [1] not fully covers IO exceptions case. Suppose we can obtain exception here: {code:java} GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin {code} [1] https://issues.apache.org/jira/browse/IGNITE-6832 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7878) Ignite Platform .NET Long Running: Stable failed with execution timeout
[ https://issues.apache.org/jira/browse/IGNITE-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov reassigned IGNITE-7878: -- Assignee: Dmitriy Pavlov > Ignite Platform .NET Long Running: Stable failed with execution timeout > - > > Key: IGNITE-7878 > URL: https://issues.apache.org/jira/browse/IGNITE-7878 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Labels: MakeTeamcityGreenAgain > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformNetLongRunning=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E > First failure changes > https://ci.ignite.apache.org/viewLog.html?buildId=1120409=buildChangesDiv=IgniteTests24Java8_IgnitePlatformNetLongRunning > {noformat} > 15:10:35] :[Apache.Ignite.Core.Tests.exe] > Apache.Ignite.Core.Tests.IgniteStartStopTest.TestStartDefault (1h:19m:50s) > [15:10:35] : > [Apache.Ignite.Core.Tests.IgniteStartStopTest.TestStartDefault] [Test Error > Output] > [04-03-2018 12:10:35][INFO ][main][IgniteKernal] > >>>__ > >>> / _/ ___/ |/ / _/_ __/ __/ > >>> _/ // (7 7// / / / / _/ > >>> /___/\___/_/|_/___/ /_/ /___/ > >>> > >>> ver. 2.5.0-SNAPSHOT#19700101-sha1:DEV > >>> 2018 Copyright(C) Apache Software Foundation > >>> > >>> Ignite documentation: http://ignite.apache.org > [04-03-2018 12:10:35][INFO ][main][IgniteKernal] Config URL: > file:/C:/BuildAgent/work/bd85361428dcdb1/modules/platforms/dotnet/Apache.Ignite.Core.Tests/bin/Debug/Config/Compute/compute-grid2.xml > [04-03-2018 12:10:35][INFO ][main][IgniteKernal] IgniteConfiguration > [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, callbackPoolSize=8, > stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4, igfsPoolSize=8, > dataStreamerPoolSize=8, utilityCachePoolSize=8, > utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8, > igniteHome=C:\BuildAgent\work\bd85361428dcdb1, > igniteWorkDir=C:\BuildAgent\work\bd85361428dcdb1\work, > mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@5965d37, > nodeId=7cb3b3f7-bd11-4f02-b579-7871ca2063ca, > marsh=org.apache.ignite.internal.binary.BinaryMarshaller@f7d76a5, > marshLocJobs=false, daemon=false, p2pEnabled=false, netTimeout=5000, > sndRetryDelay=1000, sndRetryCnt=3, metricsHistSize=1, > metricsUpdateFreq=2000, metricsExpTime=9223372036854775807, > discoSpi=TcpDiscoverySpi [addrRslvr=null, sockTimeout=0, ackTimeout=0, > marsh=null, reconCnt=10, reconDelay=2000, maxAckTimeout=60, > forceSrvMode=false, clientReconnectDisabled=false], segPlc=STOP, > segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true, > segChkFreq=1, commSpi=TcpCommunicationSpi [connectGate=null, > connPlc=null, enableForcibleNodeKill=false, enableTroubleshootingLog=false, > srvLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2@75d9f436, > locAddr=null, locHost=null, locPort=47100, locPortRange=100, shmemPort=-1, > directBuf=true, directSndBuf=false, idleConnTimeout=60, connTimeout=5000, > maxConnTimeout=60, reconCnt=10, sockSndBuf=32768, sockRcvBuf=32768, > msgQueueLimit=0, slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, > usePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true, > filterReachableAddresses=false, ackSndThreshold=32, unackedMsgsBufSize=0, > sockWriteTimeout=2000, lsnr=null, boundTcpPort=-1, boundTcpShmemPort=-1, > selectorsCnt=4, selectorSpins=0, addrRslvr=null, > ctxInitLatch=java.util.concurrent.CountDownLatch@760bcec6[Count = 1], > stopping=false, > metricsLsnr=org.apache.ignite.spi.communication.tcp.TcpCommunicationMetricsListener@51912f3a], > evtSpi=org.apache.ignite.spi.eventstorage.NoopEventStorageSpi@35bda3f3, > colSpi=NoopCollisionSpi [], deploySpi=LocalDeploymentSpi [lsnr=null], > indexingSpi=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@fff9936, > addrRslvr=null, clientMode=false, rebalanceThreadPoolSize=1, > txCfg=org.apache.ignite.configuration.TransactionConfiguration@272a1bf1, > cacheSanityCheckEnabled=true, discoStartupDelay=6, deployMode=SHARED, > p2pMissedCacheSize=100, locHost=null, timeSrvPortBase=31100, > timeSrvPortRange=100, failureDetectionTimeout=1, > clientFailureDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null, > connectorCfg=org.apache.ignite.configuration.ConnectorConfiguration@7f9a18d1, > odbcCfg=null, warmupClos=null, atomicCfg=AtomicConfiguration > [seqReserveSize=1000, cacheMode=PARTITIONED, backups=1, aff=null, > grpName=null], classLdr=null, sslCtxFactory=null, > platformCfg=PlatformDotNetConfiguration [binaryCfg=null], binaryCfg=null, > memCfg=null, pstCfg=null,
[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7918: -- Attachment: (was: MemLeak-Ignite.png) > Huge memory leak when data streamer used together with local cache > -- > > Key: IGNITE-7918 > URL: https://issues.apache.org/jira/browse/IGNITE-7918 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Zbyszek B >Priority: Blocker > Attachments: Demo.java, MemLeak-Ignite.txt > > > Dear Igniters, > We observe huge memory leak when data streamer used together with local cache. > In the attached demo producer produces local cache with single binary object > and passes this to queue. Consumer picks up the cache from the queue, > constructs different binary object from it, adds it to global partitioned > cache and destroys local cache. > This design causes a significant leak - the whole heap it takes within > minutes (no matter if this is 4G or 24G). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7918: -- Attachment: MemLeak-Ignite.png > Huge memory leak when data streamer used together with local cache > -- > > Key: IGNITE-7918 > URL: https://issues.apache.org/jira/browse/IGNITE-7918 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Zbyszek B >Priority: Blocker > Attachments: Demo.java, MemLeak-Ignite.png, MemLeak-Ignite.txt > > > Dear Igniters, > We observe huge memory leak when data streamer used together with local cache. > In the attached demo producer produces local cache with single binary object > and passes this to queue. Consumer picks up the cache from the queue, > constructs different binary object from it, adds it to global partitioned > cache and destroys local cache. > This design causes a significant leak - the whole heap it takes within > minutes (no matter if this is 4G or 24G). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zbyszek B updated IGNITE-7918: -- Attachment: MemLeak-Ignite.txt Demo.java > Huge memory leak when data streamer used together with local cache > -- > > Key: IGNITE-7918 > URL: https://issues.apache.org/jira/browse/IGNITE-7918 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.3 >Reporter: Zbyszek B >Priority: Blocker > Attachments: Demo.java, MemLeak-Ignite.png, MemLeak-Ignite.txt > > > Dear Igniters, > We observe huge memory leak when data streamer used together with local cache. > In the attached demo producer produces local cache with single binary object > and passes this to queue. Consumer picks up the cache from the queue, > constructs different binary object from it, adds it to global partitioned > cache and destroys local cache. > This design causes a significant leak - the whole heap it takes within > minutes (no matter if this is 4G or 24G). > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395087#comment-16395087 ] Zbyszek B commented on IGNITE-7918: --- {noformat} C:\Dev>"C:\Program Files\Java\jdk1.8.0_111\bin\java" -Xmx4G -XX:+UseG1GC "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2017.2.5\lib\ide a_rt.jar=52512:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2017.2.5\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_111\jre \lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Jav a\jdk1.8.0_111\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\jaccess.jar;C:\P rogram Files\Java\jdk1.8.0_111\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ex t\nashorn.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\ jdk1.8.0_111\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\ext\zipfs.jar;C:\ Program Files\Java\jdk1.8.0_111\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\jfr.jar;C:\Prog ram Files\Java\jdk1.8.0_111\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\management-agent.j ar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_111\jre\lib\rt. jar;C:\Dev\IgniteMemLeak4\out\production\IgniteDemo;C:\Dev\IgniteMemLeak4\lib\2.3\cache-api-1.0.0.jar;C:\Dev\IgniteMemLeak4\lib\2.3\commons-codec-1.6.jar;C:\Dev \IgniteMemLeak4\lib\2.3\h2-1.4.195.jar;C:\Dev\IgniteMemLeak4\lib\2.3\ignite-core-2.3.0.jar;C:\Dev\IgniteMemLeak4\lib\2.3\ignite-indexing-2.3.0.jar;C:\Dev\Ignite MemLeak4\lib\2.3\lucene-analyzers-common-5.5.2.jar;C:\Dev\IgniteMemLeak4\lib\2.3\lucene-core-5.5.2.jar;C:\Dev\IgniteMemLeak4\lib\2.3\lucene-queryparser-5.5.2.ja r" leak.Demo >>> Starting Ignite on MyLeakingNode; work directory C:\Users\user1\ignite ... Mar 11, 2018 5:24:06 PM java.util.logging.LogManager$RootLogger log SEVERE: Failed to resolve default logging config file: config/java.util.logging.properties [17:24:06] __ [17:24:06] / _/ ___/ |/ / _/_ __/ __/ [17:24:06] _/ // (7 7 // / / / / _/ [17:24:06] /___/\___/_/|_/___/ /_/ /___/ [17:24:06] [17:24:06] ver. 2.3.0#20171028-sha1:8add7fd5 [17:24:06] 2017 Copyright(C) Apache Software Foundation [17:24:06] [17:24:06] Ignite documentation: http://ignite.apache.org [17:24:06] [17:24:06] Quiet mode. [17:24:06] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or "-v" to ignite.{sh|bat} [17:24:06] [17:24:06] OS: Windows 7 6.1 amd64 [17:24:06] VM information: Java(TM) SE Runtime Environment 1.8.0_111-b14 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.111-b14 [17:24:06] Initial heap size is 256MB (should be no less than 512MB, use -Xms512m -Xmx512m). [17:24:06] Configured plugins: [17:24:06] ^-- None [17:24:06] [17:24:06] Security status [authentication=off, tls/ssl=off] [17:24:08] Performance suggestions for grid (fix if possible) [17:24:08] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true [17:24:08] ^-- Set max direct memory size if getting 'OOME: Direct buffer memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options) [17:24:08] ^-- Disable processing of calls to System.gc() (add '-XX:+DisableExplicitGC' to JVM options) [17:24:08] Refer to this page for more performance suggestions: https://apacheignite.readme.io/docs/jvm-and-system-tuning [17:24:08] [17:24:08] To start Console Management & Monitoring run ignitevisorcmd.{sh|bat} [17:24:08] [17:24:08] Ignite node started OK (id=991d7791) [17:24:08] Topology snapshot [ver=1, servers=1, clients=0, CPUs=8, heap=4.0GB] >>> Ignite started on MyLeakingNode (991d7791-5cc8-4765-82a4-6aff1a6e74c6) >>> successfully! Mar 11, 2018 11:35:28 PM org.apache.ignite.logger.java.JavaLogger error SEVERE: TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in order to prevent cluster wide instability. java.lang.OutOfMemoryError: Java heap space at org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.serverNodes(TcpDiscoveryNodesRing.java:608) at org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNodesRing.coordinator(TcpDiscoveryNodesRing.java:439) at org.apache.ignite.spi.discovery.tcp.ServerImpl.resolveCoordinator(ServerImpl.java:1491) at org.apache.ignite.spi.discovery.tcp.ServerImpl.resolveCoordinator(ServerImpl.java:1472) at
[jira] [Commented] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[ https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395086#comment-16395086 ] Zbyszek B commented on IGNITE-7918: --- {code:java} package leak; import org.apache.ignite.*; import org.apache.ignite.binary.BinaryObject; import org.apache.ignite.binary.BinaryObjectBuilder; import org.apache.ignite.cache.CacheMode; import org.apache.ignite.cache.CachePeekMode; import org.apache.ignite.cache.QueryEntity; import org.apache.ignite.cluster.ClusterNode; import org.apache.ignite.configuration.CacheConfiguration; import org.apache.ignite.configuration.IgniteConfiguration; import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi; import java.io.BufferedReader; import java.io.File; import java.io.InputStreamReader; import java.text.SimpleDateFormat; import java.util.*; import java.util.concurrent.*; import java.util.concurrent.atomic.AtomicLong; import java.util.stream.Collectors; import java.util.stream.IntStream; import java.util.stream.Stream; public class Demo { private final static Ignite ignite = createIgnite(); private final static AtomicLong producedCount = new AtomicLong(); private final static AtomicLong consumedCount = new AtomicLong(); private final static int numOfLocalFields = 10; private static BinaryObject localPrototype = createLocalPrototype(); // prototype of local cache entity with all fields set to null private final static int numOfGlobalFields = 5; private final static List globalFields = globalFields(); private static BinaryObject globalPrototype = createGlobalPrototype(); // prototype of cluster-wide cache entity with all fields set to null private static final IgniteCacheglobalCache = getOrCreateGlobalCache(); private final static String ID = "id"; private final static boolean useLocalCacheToCauseMemLeak = true; private final static BlockingQueue queue = new LinkedBlockingQueue<>(10); public static void main(String[] args) throws Exception { CompletableFuture.runAsync(Demo::runProducer); CompletableFuture.runAsync(Demo::runConsumer); BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); do { String input = br.readLine(); if ("q".equals(input)) { System.out.println("Exit!"); System.exit(0); } else { String timestamp = new SimpleDateFormat("HH:mm:ss").format(new Date()); System.out.println(String.format("[%s] Queue size: %d", timestamp, queue.size())); System.out.println(String.format("[%s] Local caches produced: %d", timestamp, producedCount.longValue())); System.out.println(String.format("[%s] Local caches consumed %d", timestamp, consumedCount.longValue())); System.out.println(String.format("[%s] Global cache size: %d", timestamp, globalCache.size(CachePeekMode.ALL))); } } while (true); } private static void runProducer() { do { long cacheId = producedCount.incrementAndGet(); try { BinaryObject bObj = createLocalObject(1); if (useLocalCacheToCauseMemLeak) { IgniteCache cache = createLocalCache(cacheId); cache.put(bObj.field(ID), bObj); queue.put(cache); } else { Map cache = new HashMap<>(); cache.put(bObj.field(ID), bObj); queue.put(cache); } } catch (Exception e) { System.out.println(e.toString()); System.exit(1); } } while (true); } private static List getSQLSelectRow(BinaryObject localObject) { List res = new ArrayList<>(); for (String f : globalFields) { res.add(localObject.field(f)); } return res; } @SuppressWarnings("unchecked") private static void runConsumer() { do { try { final Object taken = queue.take(); final List globalSQLRows = new ArrayList<>(); // Note: In practice rows are generated by executing SqlFieldsQuery against local cache; here omitted for sake of simplicity. if (taken instanceof IgniteCache) { final IgniteCache
cache = IgniteCache.class.cast(taken); cache.forEach(e -> { globalSQLRows.add(getSQLSelectRow(e.getValue())); }); cache.destroy(); } else if (taken instanceof Map) { final Map cache = Map.class.cast(taken); cache.forEach((k, v) -> { globalSQLRows.add(getSQLSelectRow(v)); }); } consumedCount.incrementAndGet(); final IgniteDataStreamer globalStreamer = createGlobalStreamer(globalCache); for (List row : globalSQLRows) { final BinaryObjectBuilder globalBuilder = globalPrototype.toBuilder(); for (int i = 0; i < globalFields.size(); i++) { globalBuilder.setField(globalFields.get(i), row.get(i)); } final BinaryObject gObj = globalBuilder.build(); globalStreamer.addData(gObj.field(ID), gObj); } globalStreamer.flush(); globalStreamer.close(); } catch (Exception e) { System.out.println(e.toString()); System.exit(1); } } while (true); } private static Ignite createIgnite() { IgniteConfiguration iCfg = new IgniteConfiguration(); TcpCommunicationSpi tcpCommunication = new TcpCommunicationSpi(); tcpCommunication.setMessageQueueLimit(1024); // to get rid of the
[jira] [Created] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
Zbyszek B created IGNITE-7918: - Summary: Huge memory leak when data streamer used together with local cache Key: IGNITE-7918 URL: https://issues.apache.org/jira/browse/IGNITE-7918 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.3 Reporter: Zbyszek B Dear Igniters, We observe huge memory leak when data streamer used together with local cache. In the attached demo producer produces local cache with single binary object and passes this to queue. Consumer picks up the cache from the queue, constructs different binary object from it, adds it to global partitioned cache and destroys local cache. This design causes a significant leak - the whole heap it takes within minutes (no matter if this is 4G or 24G). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7917) Thin client: document missing data types
Vladimir Ozerov created IGNITE-7917: --- Summary: Thin client: document missing data types Key: IGNITE-7917 URL: https://issues.apache.org/jira/browse/IGNITE-7917 Project: Ignite Issue Type: Task Components: documentation, thin client Reporter: Vladimir Ozerov Fix For: 2.5 Docs page: https://apacheignite.readme.io/docs/binary-client-protocol#data-format Missing data types: COL = 24 ENUM = 28 ENUM_ARR = 29 DECIMAL = 30 DECIMAL_ARR = 31 TIMESTAMP = 33 TIMESTAMP_ARR = 34 TIME = 36 TIME_ARR = 37 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395078#comment-16395078 ] Dmitriy Pavlov commented on IGNITE-7916: Hi [~netmille], is admin is your VCS user? If so, could you please make sure TC user is matched with github user, please see VCS usernames in your profile: https://ci.ignite.apache.org/profile.html?item=vcsUsernames > GA Grid examples should be ready for auto run on TeamCity > - > > Key: IGNITE-7916 > URL: https://issues.apache.org/jira/browse/IGNITE-7916 > Project: Ignite > Issue Type: Bug > Components: examples, ml >Reporter: Yury Babak >Assignee: Turik Campbell >Priority: Critical > Labels: MakeTeamcityGreenAgain > > If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, > this examples will return exit code 1. TeamCity think that it's a error and > mark stop whole build of examples package. > That behavior should be changed. If we don't have required system properties > we should not return exit code 1 or maybe set and use some default values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7914) Add transaction debugging support in control.sh
[ https://issues.apache.org/jira/browse/IGNITE-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kosarev reassigned IGNITE-7914: -- Assignee: Sergey Kosarev > Add transaction debugging support in control.sh > --- > > Key: IGNITE-7914 > URL: https://issues.apache.org/jira/browse/IGNITE-7914 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Alexei Scherbakov >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.5 > > > Detailed description in IGNITE-7910, paragraph 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-7916: --- Labels: MakeTeamcityGreenAgain (was: ) > GA Grid examples should be ready for auto run on TeamCity > - > > Key: IGNITE-7916 > URL: https://issues.apache.org/jira/browse/IGNITE-7916 > Project: Ignite > Issue Type: Bug > Components: examples, ml >Reporter: Yury Babak >Assignee: Turik Campbell >Priority: Critical > Labels: MakeTeamcityGreenAgain > > If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, > this examples will return exit code 1. TeamCity think that it's a error and > mark stop whole build of examples package. > That behavior should be changed. If we don't have required system properties > we should not return exit code 1 or maybe set and use some default values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7916) GA Grid examples should be ready for auto run on TeamCity
Yury Babak created IGNITE-7916: -- Summary: GA Grid examples should be ready for auto run on TeamCity Key: IGNITE-7916 URL: https://issues.apache.org/jira/browse/IGNITE-7916 Project: Ignite Issue Type: Bug Components: examples, ml Reporter: Yury Babak Assignee: Turik Campbell If we start examples MovieGAExample or OptimizeMakeChangeGAExample on TC, this examples will return exit code 1. TeamCity think that it's a error and mark stop whole build of examples package. That behavior should be changed. If we don't have required system properties we should not return exit code 1 or maybe set and use some default values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7915) Add transaction debugging support in JMX
Alexei Scherbakov created IGNITE-7915: - Summary: Add transaction debugging support in JMX Key: IGNITE-7915 URL: https://issues.apache.org/jira/browse/IGNITE-7915 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Detailed description in IGNITE-7910, paragraph 4. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7914) Add transaction debugging support in control.sh
Alexei Scherbakov created IGNITE-7914: - Summary: Add transaction debugging support in control.sh Key: IGNITE-7914 URL: https://issues.apache.org/jira/browse/IGNITE-7914 Project: Ignite Issue Type: Improvement Affects Versions: 2.3 Reporter: Alexei Scherbakov Fix For: 2.5 Detailed description in IGNITE-7910, paragraph 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7904) ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException
[ https://issues.apache.org/jira/browse/IGNITE-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-7904: --- Summary: ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() throws IgniteException (was: ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result()) > ComputeTaskFuture.get() throws incorrect exception if ComputeTask.result() > throws IgniteException > - > > Key: IGNITE-7904 > URL: https://issues.apache.org/jira/browse/IGNITE-7904 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > ComputeTask.result() javadoc says: "Throws: IgniteException - If handling a > job result caused an error effectively rejecting a failover. This exception > will be thrown out of ComputeTaskFuture.get() method." > However, GridFutureAdapter calls IgniteUtils.cast(Throwable) on the exception > before throwing it from get(), and the latter method trims the stack trace to > the first occurence of an IgniteCheckedException. Because of that, get() > throws not the IgniteException thrown from the ComputeTask.result() but one > of its causes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Filatov updated IGNITE-7912: --- Description: We have to erase wal archive because wal archive can grow large and we must have safe way to remove unused segments to free disk space. (was: control.sh script should show used WAL-segments to prevent erase it. We have to erase wal archive because wal archive can grow large and we must have safe way to remove unused segments to free disk space.) > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Priority: Minor > > We have to erase wal archive because wal archive can grow large and we must > have safe way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7913) Current implementation of Internal Diagnostics may cause OOM on server nodes.
Alexei Scherbakov created IGNITE-7913: - Summary: Current implementation of Internal Diagnostics may cause OOM on server nodes. Key: IGNITE-7913 URL: https://issues.apache.org/jira/browse/IGNITE-7913 Project: Ignite Issue Type: Improvement Affects Versions: 2.3 Reporter: Alexei Scherbakov Fix For: 2.5 If many transactions are active in grid, Internal Diagnostics can cause OOM on server nodes serving IgniteDiagnosticMessage because of heap buffering. See the stack trace demonstrating the issue: {noformat} at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1012) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:762) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:710) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:818) at java.lang.String.valueOf(String.java:2994) at org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101) at org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1267) at java.lang.String.valueOf(String.java:2994) at java.lang.StringBuilder.append(StringBuilder.java:131) at java.util.AbstractMap.toString(AbstractMap.java:559) at java.lang.String.valueOf(String.java:2994) at org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101) at org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:864) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxRemoteStateImpl.toString(IgniteTxRemoteStateImpl.java:180) at java.lang.String.valueOf(String.java:2994) at org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101) at org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783) at org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.toString(GridDistributedTxRemoteAdapter.java:926) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxRemote.toString(GridDhtTxRemote.java:373) at java.lang.String.valueOf(String.java:2994) at org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101) at org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826) at org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter$TxFinishFuture.toString(IgniteTxAdapter.java:2405) at java.lang.String.valueOf(String.java:2994) at java.lang.StringBuilder.append(StringBuilder.java:131) at java.util.AbstractCollection.toString(AbstractCollection.java:462) at java.lang.String.valueOf(String.java:2994) at java.lang.StringBuilder.append(StringBuilder.java:131) at
[jira] [Updated] (IGNITE-7912) control.sh script should show used WAL-segments
[ https://issues.apache.org/jira/browse/IGNITE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Filatov updated IGNITE-7912: --- Description: control.sh script should show used WAL-segments to prevent erase it. We have to erase wal archive because wal archive can grow large and we must have safe way to remove unused segments to free disk space. (was: control.sh script should show used WAL-segments to prevent erase it.) > control.sh script should show used WAL-segments > --- > > Key: IGNITE-7912 > URL: https://issues.apache.org/jira/browse/IGNITE-7912 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Filatov >Priority: Minor > > control.sh script should show used WAL-segments to prevent erase it. We have > to erase wal archive because wal archive can grow large and we must have safe > way to remove unused segments to free disk space. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7912) control.sh script should show used WAL-segments
Sergey Filatov created IGNITE-7912: -- Summary: control.sh script should show used WAL-segments Key: IGNITE-7912 URL: https://issues.apache.org/jira/browse/IGNITE-7912 Project: Ignite Issue Type: Improvement Reporter: Sergey Filatov control.sh script should show used WAL-segments to prevent erase it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes
[ https://issues.apache.org/jira/browse/IGNITE-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394975#comment-16394975 ] Denis Mekhanikov commented on IGNITE-7794: -- Fix is ready: [https://github.com/apache/ignite/pull/3620] Please review. > Marshaller mappings are not saved to disk on joining nodes > -- > > Key: IGNITE-7794 > URL: https://issues.apache.org/jira/browse/IGNITE-7794 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.5 > > Attachments: GridMarshallerMappingConsistencyTest.java > > > Find attached test class. > When a node connects to a cluster, that already has some marshaller mappings, > they are not saved to disk on the joining node. It may result in "Unknown > pair" error, if a cluster has persistence enabled, and a nodes without needed > mappings start and try to read persisted data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7911) TX SQL: restrict usages of unsupported APIs and configuration parameters
Vladimir Ozerov created IGNITE-7911: --- Summary: TX SQL: restrict usages of unsupported APIs and configuration parameters Key: IGNITE-7911 URL: https://issues.apache.org/jira/browse/IGNITE-7911 Project: Ignite Issue Type: Task Components: cache, sql Reporter: Vladimir Ozerov Assignee: Alexander Paschenko Fix For: 2.5 We need to make sure that when MVCC flag is enabled, users get correct exception in case of invalid configurations and/or API usages. Two general rules should apply 1) SQL and cache operations cannot be mixed in the same transactions because they still use different APIs. This restriction will be removed in future when native cache API is reworked to new locking logic. 2) If configuration is invalid or not-yet-supported API is called, user gets correct exception instead of invalid result. All listed cases must be covered with tests. Checklist: 1) Cache configuration 1.1) Cache store is not allowed for TX caches 1.2) Expiry policy is not allowed for TX caches 1.3) Interceptors are not allowed for TX caches 2) Cache API unsupported operations - throw UnsupportedOperationException and create relevant ticket (if one doesn't exist): 2.1) withExpiryPolicy 2.2) Continuous queries 2.3) "clear" method family 2.4) "lock" method family 2.5) "load" method family 2.6) "peek" method family 2.7) "evict" method family 3) Cache API consistency - make sure that these operations use consistent snapshot assigned to transaction (as with other operations). If this is the case - do nothing; if this is not the case - throw UnsupportedOperationException and create a ticket (if one doesn't exist) 3.1) Scan queries 3.2) "size" method family 3.3) Iterator methods (iterator, localEntries) 4) Mixed native API and SQL usage is restricted and proper IgniteException is thrown. When snapshot is requested for the first time we should mark transation as either "SQL" or "native". If any SQL query is executed on "native" transaction or vice versa throw an exception (IllegalStateException? IgniteException?) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7583) SQL TX: Change secondary indexes structure
[ https://issues.apache.org/jira/browse/IGNITE-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7583: Fix Version/s: 2.5 > SQL TX: Change secondary indexes structure > -- > > Key: IGNITE-7583 > URL: https://issues.apache.org/jira/browse/IGNITE-7583 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Igor Seliverstov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.5 > > > We need to change: > * rows with the same key and different versions should be placed in a tree > ordered by version decending > * move next version from BTree leafs to data rows > * filters according to next logic: the row is visible if leaf version is > less than assigned and not active and max_version of referenced row is NA or > heigher than assigned or active -- This message was sent by Atlassian JIRA (v7.6.3#76005)