[jira] [Closed] (IGNITE-4229) Loading configuration from XML into Web Console for further editing
[ https://issues.apache.org/jira/browse/IGNITE-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-4229. > Loading configuration from XML into Web Console for further editing > --- > > Key: IGNITE-4229 > URL: https://issues.apache.org/jira/browse/IGNITE-4229 > Project: Ignite > Issue Type: Wish > Components: wizards >Reporter: Alexandr Kuramshin >Assignee: Ilya Borisov >Priority: Minor > Labels: console > > It would be great to have ability of loading an external XML into Console as > the initial configuration and then get editing. > At this point it's only allowed to create a configuration from scratch and > then export to the XML. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-4229) Loading configuration from XML into Web Console for further editing
[ https://issues.apache.org/jira/browse/IGNITE-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-4229. -- Resolution: Won't Fix This issue is very hard to implement due to IgniteConfiguration as a very complex class with a lot of places where arbitrary user classes could be used. > Loading configuration from XML into Web Console for further editing > --- > > Key: IGNITE-4229 > URL: https://issues.apache.org/jira/browse/IGNITE-4229 > Project: Ignite > Issue Type: Wish > Components: wizards >Reporter: Alexandr Kuramshin >Assignee: Ilya Borisov >Priority: Minor > Labels: console > > It would be great to have ability of loading an external XML into Console as > the initial configuration and then get editing. > At this point it's only allowed to create a configuration from scratch and > then export to the XML. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10735) Web console: use rxjs EMPTY instead of empty
[ https://issues.apache.org/jira/browse/IGNITE-10735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10735: - Assignee: (was: Ilya Borisov) > Web console: use rxjs EMPTY instead of empty > > > Key: IGNITE-10735 > URL: https://issues.apache.org/jira/browse/IGNITE-10735 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Priority: Minor > > RxJS 6 [has > deprecated|https://rxjs-dev.firebaseapp.com/api/index/function/empty] empty, > EMPTY constant should be used instead, so let's do that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11714) Web console: multiple select items overflow
[ https://issues.apache.org/jira/browse/IGNITE-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-11714: - Assignee: (was: Ilya Borisov) > Web console: multiple select items overflow > --- > > Key: IGNITE-11714 > URL: https://issues.apache.org/jira/browse/IGNITE-11714 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Priority: Minor > Attachments: image-2019-04-10-16-00-55-734.png > > > *What happens:* > !image-2019-04-10-16-00-55-734.png! > *Expected behavior:* > Overflow is handled gracefully, value is contained in control. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11376) Web console: frontend cold build speed improvements
[ https://issues.apache.org/jira/browse/IGNITE-11376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-11376. --- Resolution: Won't Fix > Web console: frontend cold build speed improvements > --- > > Key: IGNITE-11376 > URL: https://issues.apache.org/jira/browse/IGNITE-11376 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 4h > Time Spent: 0.8h > Remaining Estimate: 3.2h > > *The issue:* > Frontend cold build takes considerable time (~46s on my machine), which is > rather annoying. > *What to do:* > 1. Try both of these Webpack plugins and benchmark cold build results: > https://github.com/amireh/happypack > https://github.com/webpack-contrib/thread-loader > 2. If we deem build time reduction considerable enough and no additional > issues arise (like loader compatibility), add either of plugins to web > console Webpack configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-11376) Web console: frontend cold build speed improvements
[ https://issues.apache.org/jira/browse/IGNITE-11376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-11376. - Current speed of build is acceptable. > Web console: frontend cold build speed improvements > --- > > Key: IGNITE-11376 > URL: https://issues.apache.org/jira/browse/IGNITE-11376 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 4h > Time Spent: 0.8h > Remaining Estimate: 3.2h > > *The issue:* > Frontend cold build takes considerable time (~46s on my machine), which is > rather annoying. > *What to do:* > 1. Try both of these Webpack plugins and benchmark cold build results: > https://github.com/amireh/happypack > https://github.com/webpack-contrib/thread-loader > 2. If we deem build time reduction considerable enough and no additional > issues arise (like loader compatibility), add either of plugins to web > console Webpack configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-7837) Web console: list-editable new item button behaves incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov closed IGNITE-7837.
Not relative any more.
> Web console: list-editable new item button behaves incorrectly
> --
>
> Key: IGNITE-7837
> URL: https://issues.apache.org/jira/browse/IGNITE-7837
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> *How to reproduce:*
> # Open advanced configuration, domain model editing.
> # Open query section, add one alias, click elsewhere.
> # Click on added alias to enter edit mode again.
> # Click on "Add new alias to query".
>
> *What happens:*
> First alias edit form closes, but new alias is not added.
>
> *What should happen:*
> First alias edit form should close, another (second) alias should be added,
> second alias should be in edit mode.
>
> *Notes:*
> I did some research on the issue, the possible cause of the issue lies either
> in {{on-focus-out directive}} (used inside {{list-editable}}) or
> {{list-editable}} directive, or both. If the {{delete this._cache[idx]}}
> expression in {{stopEditView}} method of {{list-editable}} component
> controller is wrapped with a {{$timeout(..., 150)}} everything works as
> expected, except that 150ms of added delay makes UX perceptibly worse.
>
> *What to do:*
> Investigate the cause of the issue described above and fix the incorrect
> behavior, preferably not the way described in notes section.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-7837) Web console: list-editable new item button behaves incorrectly
[
https://issues.apache.org/jira/browse/IGNITE-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov resolved IGNITE-7837.
--
Resolution: Won't Fix
> Web console: list-editable new item button behaves incorrectly
> --
>
> Key: IGNITE-7837
> URL: https://issues.apache.org/jira/browse/IGNITE-7837
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> *How to reproduce:*
> # Open advanced configuration, domain model editing.
> # Open query section, add one alias, click elsewhere.
> # Click on added alias to enter edit mode again.
> # Click on "Add new alias to query".
>
> *What happens:*
> First alias edit form closes, but new alias is not added.
>
> *What should happen:*
> First alias edit form should close, another (second) alias should be added,
> second alias should be in edit mode.
>
> *Notes:*
> I did some research on the issue, the possible cause of the issue lies either
> in {{on-focus-out directive}} (used inside {{list-editable}}) or
> {{list-editable}} directive, or both. If the {{delete this._cache[idx]}}
> expression in {{stopEditView}} method of {{list-editable}} component
> controller is wrapped with a {{$timeout(..., 150)}} everything works as
> expected, except that 150ms of added delay makes UX perceptibly worse.
>
> *What to do:*
> Investigate the cause of the issue described above and fix the incorrect
> behavior, preferably not the way described in notes section.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-9190) Web console: align babel-env and "unsupported browsers" browser list
[ https://issues.apache.org/jira/browse/IGNITE-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9190. > Web console: align babel-env and "unsupported browsers" browser list > > > Key: IGNITE-9190 > URL: https://issues.apache.org/jira/browse/IGNITE-9190 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > IGNITE-9028 introduced a set of supported browsers because that's how > babel-env works and these versions are different from what's used in > browser-update config. I suggest to alias browser versions between babel-env > and browser-update. Unfortunately, browser-update does not support > [browserlist|https://github.com/browserslist/browserslist] notation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-9190) Web console: align babel-env and "unsupported browsers" browser list
[ https://issues.apache.org/jira/browse/IGNITE-9190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9190. -- Resolution: Won't Fix Not relative any more. > Web console: align babel-env and "unsupported browsers" browser list > > > Key: IGNITE-9190 > URL: https://issues.apache.org/jira/browse/IGNITE-9190 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > > IGNITE-9028 introduced a set of supported browsers because that's how > babel-env works and these versions are different from what's used in > browser-update config. I suggest to alias browser versions between babel-env > and browser-update. Unfortunately, browser-update does not support > [browserlist|https://github.com/browserslist/browserslist] notation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-8916) Web Console: Replace font-awesome icons
[ https://issues.apache.org/jira/browse/IGNITE-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8916. > Web Console: Replace font-awesome icons > --- > > Key: IGNITE-8916 > URL: https://issues.apache.org/jira/browse/IGNITE-8916 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Minor > Attachments: font-awesome.png > > > Replace font-awesome icons to svg icons + and -. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-8916) Web Console: Replace font-awesome icons
[ https://issues.apache.org/jira/browse/IGNITE-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-8916. -- Resolution: Won't Fix We replaced major part of font-awesome icons with svg. > Web Console: Replace font-awesome icons > --- > > Key: IGNITE-8916 > URL: https://issues.apache.org/jira/browse/IGNITE-8916 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Ilya Borisov >Priority: Minor > Attachments: font-awesome.png > > > Replace font-awesome icons to svg icons + and -. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9480) SQL: Introduce H2 LocalResult factory
[ https://issues.apache.org/jira/browse/IGNITE-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-9480: Labels: h2-limitation (was: ) > SQL: Introduce H2 LocalResult factory > - > > Key: IGNITE-9480 > URL: https://issues.apache.org/jira/browse/IGNITE-9480 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.6 >Reporter: Taras Ledkov >Priority: Major > Labels: h2-limitation > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > H2 collects query result at the instance of `LocalResult` for queries results > that not be gathered lazy. This causes an OOME error on large result sets. > We have to introduce way to use our own implementation of the query result's > container. > Suggestion fix: > - H2 simple refactoring: make `LocalResult` interface and H2 default > implementation `LocalResultImpl` > - Add H2 configurable `LocalResultFactory` to setup custom implementation of > the `LocalResult. > - Create Ignite implementation of `LocalResultFactory` & `LocalResult` to > track allocated memory, swap results to external storage etc. > H2 issue: > [#1405|https://github.com/h2database/h2database/issues/1405#issuecomment-417631253] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10855) Performance problems while running SQL query involving JOINS and ORDER BY eventually leading to heap OOME.
[ https://issues.apache.org/jira/browse/IGNITE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-10855: - Component/s: h2-limitation > Performance problems while running SQL query involving JOINS and ORDER BY > eventually leading to heap OOME. > -- > > Key: IGNITE-10855 > URL: https://issues.apache.org/jira/browse/IGNITE-10855 > Project: Ignite > Issue Type: Bug > Components: cache, h2-limitation, sql >Affects Versions: 2.7 >Reporter: Gourav Agrawal >Priority: Blocker > Fix For: None > > > To simplify our use-case, we created two caches using the SQL query and > loaded data consisting of about 4 million records and 60k records > approximately, in the respective caches with INDEX created on all the > columns. Ignite is set up to run on a single node, meaning all the data is > present on the same node. The query used for testing/the one we are facing > issue with is of the type - > _SELECT * FROM CACHE1 C1, CACHE2 C2 WHERE C1.JOINCol = C2.JOINCol AND > C1.COL1 = 'someValue' ORDER BY C1.COL2_ > The above query execution leads to the Ignite thread memory rising > extensively, eventually leading to heap OOME. When the heap memory was > increased to about 14GB, we were able to get the results back, but the > processing time of the query was too long, about 2-4 minutes ( with CPUs =2). > We ran an EXPLAIN for the above query and found out that INDEX was created on > COL1 for C1 cache and on JOINCol for C2 cache. There was no index on the > sorted column. We think the problem of 'slow querying and huge heap memory > requirement' is because of the absence of an index in the sorted column. > Whenever there is a condition present in the WHERE clause ( in our example > C1.COL1='someValue'), Ignite is using an INDEX for that column and there is > no INDEX being created on the ORDER BY column. > And for our use-case, it is imperative that we have a condition in the where > clause ( to filter out the data) and a join condition apart from the order by > clause. > We tried the multiple column indexing strategy on the COL1, COL2 as per our > use case. > In case of a composite index with the order as (COL1, COL2), INDEX was > created only for the COL1. > While for the composite index order as (COL2, COL1), INDEX was getting > created for both COL1 and COL2 and the results were index sorted. ( But only > in case of the absence of an INDEX for COL1, it looks for the ORDER BY clause > column and uses a composite index). But, if we don't have a separate INDEX > for COL1, it again poses a problem as COL1 is something which is heavily used > for filtering in all other queries. So an INDEX on COL1 is necessary. > To summarize, In case there is a condition present in the WHERE clause, > Ignite uses the WHERE clause column for indexing, and therefore there is no > INDEX in the sorting column, resulting in severe query performance, which can > eventually lead us to our system going down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-5289) SQL: forbid recursive WITH queries
[ https://issues.apache.org/jira/browse/IGNITE-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-5289: Labels: h2-limitation sql-engine (was: sql-engine) > SQL: forbid recursive WITH queries > -- > > Key: IGNITE-5289 > URL: https://issues.apache.org/jira/browse/IGNITE-5289 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Paschenko >Priority: Major > Labels: h2-limitation, sql-engine > > Recursive queries starting with WITH keyword must be explicitly forbidden. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11473) SQL: check convert to ENUM type by functions CAST, CONVERT throws sane exception
[ https://issues.apache.org/jira/browse/IGNITE-11473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11473: - Labels: h2-limitation (was: ) > SQL: check convert to ENUM type by functions CAST, CONVERT throws sane > exception > > > Key: IGNITE-11473 > URL: https://issues.apache.org/jira/browse/IGNITE-11473 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Taras Ledkov >Priority: Major > Labels: h2-limitation > > CAST and CONVERT functions have the bug at the H2. > It is fixed at H2 1.4.198. > We have to check that the functions throws sane exception after H2 is > upgraded. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10598) H2 ConnectionManager drop ThreadLocal logic
[ https://issues.apache.org/jira/browse/IGNITE-10598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-10598: - Labels: h2-limitation (was: ) > H2 ConnectionManager drop ThreadLocal logic > --- > > Key: IGNITE-10598 > URL: https://issues.apache.org/jira/browse/IGNITE-10598 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.7 >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Labels: h2-limitation > > Looks like we have to change H2 connection management after the patch > IGNITE-9171 is applied. Caching H2 connection in ThreadLocal doesn't make > sense because connections are shared between thread in fact. > Drop ThreadLocal connection cache simplifies connection management. We > haven't check thread state to close connection. > The solution needs in good performance analysis & benchmark to be sure that > contention on concurrent collection of H2 connections doesn't affect query > performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11341) SQL: Enable lazy mode by default
[ https://issues.apache.org/jira/browse/IGNITE-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-11341: - Labels: h2-limitation (was: ) > SQL: Enable lazy mode by default > > > Key: IGNITE-11341 > URL: https://issues.apache.org/jira/browse/IGNITE-11341 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Critical > Labels: h2-limitation > > We redesigned lazy mode, so that now it doesn't spawn new thread and has the > same performance as old "eager" mode (IGNITE-9171). However, we didn't enable > it by default because H2 1.4.197 contains several bugs causing query engine > slowdown in some cases when lazy mode is set. These issues are resolved in H2 > master and will become available as a part of the next release (presumably > 1.4.198). > We need to make lazy mode enabled by default once new version is available > (IGNITE-10801). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7526) SQL: Introduce memory region for reducer merge results with disk offload
[ https://issues.apache.org/jira/browse/IGNITE-7526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-7526: Labels: h2-limitation sql-stability (was: sql-stability) > SQL: Introduce memory region for reducer merge results with disk offload > > > Key: IGNITE-7526 > URL: https://issues.apache.org/jira/browse/IGNITE-7526 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Major > Labels: h2-limitation, sql-stability > Time Spent: 10m > Remaining Estimate: 0h > > Currently all results received from map nodes are stored inside reducer's > heap memory. What is worse, in case of complex queries, such as having sorts > or groupings, need to collect all results from mappers first before final > processing could be applied. In case of big results set (or intermediate > results) this could easily lead to OOME on reducer. > To mitigate this we should introduce special memory area where intermediate > results could be stored. All final processing should be stored in the same > area as well. This area should be of limited size and should be able to > offload results to disk in case of overflow. > We could start with our B+Tree and free list and store results in some K-V > form. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11444) SQL: MERGE USING must throw clear exception with UNSUPPORTED error code
[
https://issues.apache.org/jira/browse/IGNITE-11444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11444:
-
Labels: h2-limitation (was: )
> SQL: MERGE USING must throw clear exception with UNSUPPORTED error code
> ---
>
> Key: IGNITE-11444
> URL: https://issues.apache.org/jira/browse/IGNITE-11444
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Priority: Major
> Labels: h2-limitation
>
> The unsupported SQL statement MERGE USING throws unclear exception because H2
> uses internal _ROWID_ column at MERGE USING implementation. Ignite tables
> doesn't contain _ROWID_ column.
> {code}
> Caused by: org.h2.jdbc.JdbcSQLException: Column count does not match; SQL
> statement:
> SELECT _ROWID_ FROM PARENT AS P WHERE (((P.ID = S.ID)
> AND (1 = 1))
> AND (S.ID = P.ID)) [21002-197]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.message.DbException.get(DbException.java:144)
> at org.h2.command.dml.MergeUsing.prepare(MergeUsing.java:403)
> at org.h2.command.Parser.prepareCommand(Parser.java:283)
> at org.h2.engine.Session.prepareLocal(Session.java:611)
> at org.h2.engine.Session.prepareCommand(Session.java:549)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1247)
> at
> org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:76)
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnection.java:694)
> at
> org.apache.ignite.internal.processors.query.h2.ConnectionManager.prepareStatementNoCache(ConnectionManager.java:363)
> at
> org.apache.ignite.internal.processors.query.h2.QueryParser.parseH2(QueryParser.java:264)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9616) SQL: Introduce H2 factory for holder of aggregate result
[
https://issues.apache.org/jira/browse/IGNITE-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-9616:
Labels: h2-limitation (was: )
> SQL: Introduce H2 factory for holder of aggregate result
>
>
> Key: IGNITE-9616
> URL: https://issues.apache.org/jira/browse/IGNITE-9616
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.6
>Reporter: Taras Ledkov
>Priority: Major
> Labels: h2-limitation
>
> H2 collects aggregate results at the simple HashMap (groups set and values
> set).
> This causes an OOME error on large groups set and large group size with
> {{DISTINCT}}.
> We have to introduce way to use our own implementation of the aggregate
> result's container.
> H2 issue:
> [#1433|https://github.com/h2database/h2database/issues/1433#issuecomment-421045128]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11891) Multi-column index - query out of memory
[
https://issues.apache.org/jira/browse/IGNITE-11891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11891:
-
Labels: h2-limitation performance (was: performance)
> Multi-column index - query out of memory
>
>
> Key: IGNITE-11891
> URL: https://issues.apache.org/jira/browse/IGNITE-11891
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: João Fonseca
>Priority: Major
> Labels: h2-limitation, performance
>
> My application uses a table for logging events. Something like:
>
> {noformat}
> create table event (
> id bigint not null,
> level varchar(8) not null,
> timestamp bigint not null,
> message varchar(4096) not null,
> primary key (id)
> ) ;
> {noformat}
> I have two indexes:
>
> {noformat}
> create index index_event_timestamp on event (timestamp desc)
> create index index_event_level on event (level, timestamp desc)
> {noformat}
> The idea is to support both the following queries:
>
> {noformat}
> select * from event order by timestamp desc limit 25
> select * from event where level = 'WARNING' order by timestamp desc limit 25
> {noformat}
> Once the table size increases to several million records, the second query
> generates OOM on the server. From what I can see (from the explain results),
> the index_event_level is used to fetch records with WARNING level, but the
> timestamp column available with the index is not used in the "order by"
> clause. The server attempts to fetch all records and then sort them by
> timestamp, despite the index already doing this...
> I removed the second index as a work-around, and the query runs faster on the
> first index - it scans index_event_timestamp, and retrieves the records with
> level=WARNING. It's smart to realize that the scan results are already sorted
> correctly.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-6202) SQL: support hash join
[ https://issues.apache.org/jira/browse/IGNITE-6202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-6202: Labels: h2-limitation performance sql-engine (was: performance sql-engine) > SQL: support hash join > -- > > Key: IGNITE-6202 > URL: https://issues.apache.org/jira/browse/IGNITE-6202 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Priority: Major > Labels: h2-limitation, performance, sql-engine > > Justification is the same as for IGNITE-6201 (merge joins). If join is > equijoin, and participating attributes are not sorted in advance, then > instead of executing nested loops, we can do the following: > 1) Get the table with smaller number of entries > 2) Build a hash table from target attribute to the list of matching entries > 3) Iterate over larger table and perform lookup into hash table > Note that this operation might be memory-intensive in case smaller table is > large enough still. For this reason we should provide a mechanism to avoid > out-of-memory errors. Let's avoid spilling to disk in the first iteration, > and try to set a kind of hard limit on how much data can be kept in memory. > If we see that this limit cannot be satisfied, then fallback to nested loops. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11448) SQL: Wrong results of select with aggregates in subquery
[
https://issues.apache.org/jira/browse/IGNITE-11448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-11448:
-
Labels: h2-limitation (was: )
> SQL: Wrong results of select with aggregates in subquery
>
>
> Key: IGNITE-11448
> URL: https://issues.apache.org/jira/browse/IGNITE-11448
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Roman Kondakov
>Priority: Major
> Labels: h2-limitation
> Attachments: Subquery reproducer
>
>
> Subqueries with aggregates may return wrong results due to incorrect
> splitting.
> Let's consider a table {{person}}:
> {noformat}
> SELECT id, firstName FROM person:
> [1, firstName1],
> [2, firstName2],
> [3, firstName3],
> [4, firstName4],
> [5, firstName5],
> [6, firstName6],
> [7, firstName7],
> [8, firstName8],
> [9, firstName9],
> [10, firstName10]
> {noformat}
> The result of query {{SELECT COUNT(\*) FROM person}} is {{10}}, which is
> correct.
> The result of query {{SELECT * FROM person WHERE id = 10}} is {{[10,
> firstName10]}}, which is also correct.
> But the result of the query {{SELECT * FROM person WHERE id = (SELECT
> COUNT(\*) FROM person)}} is {{[1, firstName1]}} which is completely wrong.
> The root cause of this behavior is the incorrect query splitting. The latest
> query is split into these parts:
> Map:
> {noformat}
> SELECT
> __Z0.ID __C0_0,
> __Z0.FIRSTNAME __C0_1
> FROM PUBLIC.PERSON __Z0
> WHERE __Z0.ID = (SELECT
> COUNT(*)
> FROM PUBLIC.PERSON __Z1)
> {noformat}
> Reduce:
> {noformat}
> SELECT
> __C0_0 ID,
> __C0_1 FIRSTNAME
> FROM PUBLIC.__T0
> {noformat}
> As we can see, aggregate {{COUNT(\*)}} is calculated locally on each map node
> instead of calculating a single global aggregate and then using it in
> predicate.
> Reproducer is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-3911) Unable to add user defined aggregate to H2
[ https://issues.apache.org/jira/browse/IGNITE-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-3911: Labels: h2-limitation (was: ) > Unable to add user defined aggregate to H2 > -- > > Key: IGNITE-3911 > URL: https://issues.apache.org/jira/browse/IGNITE-3911 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Tolstokulakov Nikolay >Priority: Major > Labels: h2-limitation > Time Spent: 20m > Remaining Estimate: 0h > > It is possible to add user defined function (@QuerySqlFunction annotation) > for H2 SQL, but it is not possible to add user defined aggregate. For > consistency I suggest create new annotation @QuerySqlAggregateClass -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941307#comment-16941307
]
Denis A. Magda commented on IGNITE-12032:
-
[~isapego], could you please do a final review round?
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Assignee: Lev Agafonov
>Priority: Minor
> Labels: newbie, usability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>
> 04)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>
> oServer.java:2389)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>
> 6)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)*
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node,
> so, we shouldn't print exception in the log. We should replace it with
> something like INFO message about ODBC client disconnection.
> Thread from user list:
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10554) .NET: Jars are not copied to target dir under .NET Core
[
https://issues.apache.org/jira/browse/IGNITE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-10554:
Description:
We use PowerShell script to update post-build event in the target project and
copy jar files to target directory during build.
However, this no longer works with .NET Core.
nuspec file should be updated with new format, see example from
https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
{code}
ContentFilesExample
1.0.0
nuget
nuget
false
A content v2 example package.
contentv2 contentFiles
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
in .NET Core 3.0:
??The dotnet build command now copies NuGet dependencies for your application
from the NuGet cache to the build output folder??
In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR files
are resolved.
In 3.0 this does not work anymore, we should find a way to copy JAR files to
the output folder.
Test cases:
* .NET 4.x
* .NET Core 2.x, 3.x Windows & Linux
* LINQPad
* Binary zip distribution (examples, .NET Core examples)
was:
We use PowerShell script to update post-build event in the target project and
copy jar files to target directory during build.
However, this no longer works with .NET Core.
nuspec file should be updated with new format, see example from
https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
{code}
ContentFilesExample
1.0.0
nuget
nuget
false
A content v2 example package.
contentv2 contentFiles
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
in .NET Core 3.0:
??The dotnet build command now copies NuGet dependencies for your application
from the NuGet cache to the build output folder??
In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR files
are resolved.
In 3.0 this does not work anymore, we should find a way to copy JAR files to
the output folder.
Test cases:
* .NET 4.x
* .NET Core 2.x, 3.x Windows & Linux
* LINQPad
> .NET: Jars are not copied to target dir under .NET Core
> ---
>
> Key: IGNITE-10554
> URL: https://issues.apache.org/jira/browse/IGNITE-10554
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.8
>
>
> We use PowerShell script to update post-build event in the target project and
> copy jar files to target directory during build.
> However, this no longer works with .NET Core.
> nuspec file should be updated with new format, see example from
> https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
> {code}
>
>
>
> ContentFilesExample
> 1.0.0
> nuget
> nuget
> false
> A content v2 example package.
> contentv2 contentFiles
>
>
>
>
>
>
> copyToOutput="true" />
>
>
> {code}
> *UPDATE: this breaks NuGet package usage completely under .NET Core 3.0*
> [NuGet behavior has
> changed|https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
> in .NET Core 3.0:
> ??The dotnet build command now copies NuGet dependencies for your application
> from the NuGet cache to the build output folder??
> In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR
> files are resolved.
> In 3.0 this does not work anymore, we should find a way to copy JAR files to
> the output folder.
> Test cases:
> * .NET 4.x
> * .NET Core 2.x, 3.x Windows & Linux
> * LINQPad
> * Binary zip distribution (examples, .NET Core examples)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10554) .NET: Jars are not copied to target dir under .NET Core
[
https://issues.apache.org/jira/browse/IGNITE-10554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-10554:
Description:
We use PowerShell script to update post-build event in the target project and
copy jar files to target directory during build.
However, this no longer works with .NET Core.
nuspec file should be updated with new format, see example from
https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
{code}
ContentFilesExample
1.0.0
nuget
nuget
false
A content v2 example package.
contentv2 contentFiles
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
in .NET Core 3.0:
??The dotnet build command now copies NuGet dependencies for your application
from the NuGet cache to the build output folder??
In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR files
are resolved.
In 3.0 this does not work anymore, we should find a way to copy JAR files to
the output folder.
Test cases:
* .NET 4.x
* .NET Core 2.x, 3.x Windows & Linux
* LINQPad
was:
We use PowerShell script to update post-build event in the target project and
copy jar files to target directory during build.
However, this no longer works with .NET Core.
nuspec file should be updated with new format, see example from
https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
{code}
ContentFilesExample
1.0.0
nuget
nuget
false
A content v2 example package.
contentv2 contentFiles
https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
in .NET Core 3.0:
??The dotnet build command now copies NuGet dependencies for your application
from the NuGet cache to the build output folder??
In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR files
are resolved.
In 3.0 this does not work anymore, we should find a way to copy JAR files to
the output folder.
> .NET: Jars are not copied to target dir under .NET Core
> ---
>
> Key: IGNITE-10554
> URL: https://issues.apache.org/jira/browse/IGNITE-10554
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.8
>
>
> We use PowerShell script to update post-build event in the target project and
> copy jar files to target directory during build.
> However, this no longer works with .NET Core.
> nuspec file should be updated with new format, see example from
> https://github.com/NuGet/Samples/blob/master/ContentFilesExample/authoring/ContentFilesExample.nuspec:
> {code}
>
>
>
> ContentFilesExample
> 1.0.0
> nuget
> nuget
> false
> A content v2 example package.
> contentv2 contentFiles
>
>
>
>
>
>
> copyToOutput="true" />
>
>
> {code}
> *UPDATE: this breaks NuGet package usage completely under .NET Core 3.0*
> [NuGet behavior has
> changed|https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#build-copies-dependencies]
> in .NET Core 3.0:
> ??The dotnet build command now copies NuGet dependencies for your application
> from the NuGet cache to the build output folder??
> In .NET Core 2.x dependencies are used directly from NuGet cache, so JAR
> files are resolved.
> In 3.0 this does not work anymore, we should find a way to copy JAR files to
> the output folder.
> Test cases:
> * .NET 4.x
> * .NET Core 2.x, 3.x Windows & Linux
> * LINQPad
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12249) Concurrency guarantees for TransactionView
[
https://issues.apache.org/jira/browse/IGNITE-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12249:
-
Summary: Concurrency guarantees for TransactionView (was: Concurrent
guarantees for TransactionView)
> Concurrency guarantees for TransactionView
> --
>
> Key: IGNITE-12249
> URL: https://issues.apache.org/jira/browse/IGNITE-12249
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
>
> Currently, {{TransactionView#keysCount}} and {{TransactionView#cacheIds}}
> works with Collections that not provides concurrent guarantees.
> We should research the possibility to provide consistent transaction view for
> these data structures.
> Performance of the transaction engine can be limitation here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12249) Concurrent guarantees for TransactionView
Nikolay Izhikov created IGNITE-12249:
Summary: Concurrent guarantees for TransactionView
Key: IGNITE-12249
URL: https://issues.apache.org/jira/browse/IGNITE-12249
Project: Ignite
Issue Type: Bug
Reporter: Nikolay Izhikov
Currently, {{TransactionView#keysCount}} and {{TransactionView#cacheIds}} works
with Collections that not provides concurrent guarantees.
We should research the possibility to provide consistent transaction view for
these data structures.
Performance of the transaction engine can be limitation here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12238) RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
[
https://issues.apache.org/jira/browse/IGNITE-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941097#comment-16941097
]
Andrey N. Gura commented on IGNITE-12238:
-
MErged to master branch
> RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
> ---
>
> Key: IGNITE-12238
> URL: https://issues.apache.org/jira/browse/IGNITE-12238
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{RobinHoodBackwardShiftHashMap}} has bug that can be reproduced only on big
> endinan architectures. In order to reproduce the problem run the following
> tests:
> * {{RobinHoodBackwardShiftHashMapTest.testCollisionOnRemove}}
> * {{testRandomOpsPutRemove}}
> The problem is {{setIdealBucket()}} method writes {{long}} value to the
> offheap memory, while {{getIdealBucket()}} reads {{int}} value. For little
> endian architectures it works because meaningful 4 bytes will written first
> to the memory and leading zero bytes will be rewriteen by the next operation.
> On big endian architecture always 4 zero bytes will be written to the memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12238) RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
[
https://issues.apache.org/jira/browse/IGNITE-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-12238:
Release Note: (was: Merged to master branch)
> RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
> ---
>
> Key: IGNITE-12238
> URL: https://issues.apache.org/jira/browse/IGNITE-12238
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{RobinHoodBackwardShiftHashMap}} has bug that can be reproduced only on big
> endinan architectures. In order to reproduce the problem run the following
> tests:
> * {{RobinHoodBackwardShiftHashMapTest.testCollisionOnRemove}}
> * {{testRandomOpsPutRemove}}
> The problem is {{setIdealBucket()}} method writes {{long}} value to the
> offheap memory, while {{getIdealBucket()}} reads {{int}} value. For little
> endian architectures it works because meaningful 4 bytes will written first
> to the memory and leading zero bytes will be rewriteen by the next operation.
> On big endian architecture always 4 zero bytes will be written to the memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12238) RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
[
https://issues.apache.org/jira/browse/IGNITE-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941091#comment-16941091
]
Ignite TC Bot commented on IGNITE-12238:
{panel:title=Branch: [pull/6921/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4641839&buildTypeId=IgniteTests24Java8_RunAll]
> RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
> ---
>
> Key: IGNITE-12238
> URL: https://issues.apache.org/jira/browse/IGNITE-12238
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RobinHoodBackwardShiftHashMap}} has bug that can be reproduced only on big
> endinan architectures. In order to reproduce the problem run the following
> tests:
> * {{RobinHoodBackwardShiftHashMapTest.testCollisionOnRemove}}
> * {{testRandomOpsPutRemove}}
> The problem is {{setIdealBucket()}} method writes {{long}} value to the
> offheap memory, while {{getIdealBucket()}} reads {{int}} value. For little
> endian architectures it works because meaningful 4 bytes will written first
> to the memory and leading zero bytes will be rewriteen by the next operation.
> On big endian architecture always 4 zero bytes will be written to the memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12241) Found long running cache future and cluster is not responding
[
https://issues.apache.org/jira/browse/IGNITE-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941089#comment-16941089
]
Andrey N. Gura commented on IGNITE-12241:
-
[~gangaiah.yadav], Did you try to reproduce it on the latest release? 2.6
version is outdated and will not get any fixes.
> Found long running cache future and cluster is not responding
> -
>
> Key: IGNITE-12241
> URL: https://issues.apache.org/jira/browse/IGNITE-12241
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Gangaiah
>Priority: Blocker
>
> Cluster is not responding... Client able to connect but not responding while
> doing cache operations.. We have found only 'Found long running cache future'
> in logs, Below are logs
> [2019-09-27T11:42:53,314][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:23.356, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594757419, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,315][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:38.851, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594757421, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,315][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:33.772, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594757420, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,316][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:31:23.319, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594524109, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,316][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:32.730, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594524108, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,316][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:15.783, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594524107, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
> [2019-09-27T11:42:53,316][WARN
> ][grid-timeout-worker-#263%EDIFCustomer_DR%][diagnostic] Found long running
> cache future [startTime=11:30:27.037, curTime=11:42:53.288,
> fut=GridDhtAtomicSingleUpdateFuture [allUpdated=true,
> super=GridDhtAtomicAbstractUpdateFuture [futId=594406845, resCnt=0,
> addedReader=false, dhtRes=\{b2fbba87-149d-4a75-b479-042c3bd62f0a=[res=false,
> size=1, nearSize=0]}]]]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11981) [IEP-35] Create MU shortcut instead of static import of MetricUtils
[
https://issues.apache.org/jira/browse/IGNITE-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941083#comment-16941083
]
Andrey N. Gura commented on IGNITE-11981:
-
[~avinogradov] I don't understand what are you talk about. Could you please
refer to the concrete class and incorrect static call usages please?
> [IEP-35] Create MU shortcut instead of static import of MetricUtils
> ---
>
> Key: IGNITE-11981
> URL: https://issues.apache.org/jira/browse/IGNITE-11981
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Minor
> Labels: IEP-35
>
> More Ignite-way of coding is the usage of short cut classes.
> We should use MU instead of static import of {{MetricUtils}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941082#comment-16941082 ] Alexei Scherbakov commented on IGNITE-12209: [~nizhikov] Looks good. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941079#comment-16941079 ] Nikolay Izhikov commented on IGNITE-12209: -- > Or we talking only about IgniteTxState#cacheIds? I've added try catch for a cacheIds. Please, take a look. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12238) RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
[
https://issues.apache.org/jira/browse/IGNITE-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941077#comment-16941077
]
Alexey Goncharuk commented on IGNITE-12238:
---
Good catch! The changes look good to me.
> RobinHoodBackwardShiftHashMap works incorrectly on big endian architectures
> ---
>
> Key: IGNITE-12238
> URL: https://issues.apache.org/jira/browse/IGNITE-12238
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RobinHoodBackwardShiftHashMap}} has bug that can be reproduced only on big
> endinan architectures. In order to reproduce the problem run the following
> tests:
> * {{RobinHoodBackwardShiftHashMapTest.testCollisionOnRemove}}
> * {{testRandomOpsPutRemove}}
> The problem is {{setIdealBucket()}} method writes {{long}} value to the
> offheap memory, while {{getIdealBucket()}} reads {{int}} value. For little
> endian architectures it works because meaningful 4 bytes will written first
> to the memory and leading zero bytes will be rewriteen by the next operation.
> On big endian architecture always 4 zero bytes will be written to the memory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12248) Apache Calcite based query execution engine
Igor Seliverstov created IGNITE-12248: - Summary: Apache Calcite based query execution engine Key: IGNITE-12248 URL: https://issues.apache.org/jira/browse/IGNITE-12248 Project: Ignite Issue Type: Task Components: sql Reporter: Igor Seliverstov Assignee: Igor Seliverstov Currently used H2 based query execution engine has a number of critical limitations Which do not allow to execute an arbitrary query. The ticket aims to show potential of a new, Calcite based, execution engine which may act not worse than current one on co-located queries, provide a boost for queries, using distributed joins, and provide an ability to execute arbitrary queries, requiring more than one map-reduce step in execution flow. [IEP link|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130028084] [Dev list thread|http://apache-ignite-developers.2346864.n4.nabble.com/New-SQL-execution-engine-td43724.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941029#comment-16941029 ] Alexey Kuznetsov commented on IGNITE-12192: --- [~sdarlington] Looks good to me. > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12232) NPE while node join processing
[
https://issues.apache.org/jira/browse/IGNITE-12232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940975#comment-16940975
]
Ignite TC Bot commented on IGNITE-12232:
{panel:title=Branch: [pull/6911/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4635678&buildTypeId=IgniteTests24Java8_RunAll]
> NPE while node join processing
> --
>
> Key: IGNITE-12232
> URL: https://issues.apache.org/jira/browse/IGNITE-12232
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: PetrovMikhail
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ServerImpl.RingMessageWorker#processNodeAddedMessage method throws npe
> exception in case DiscoverySpiNodeAuthenticator#authenticateNode returns null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-12242) .NET: Add tests for Thin Client async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-12242.
-
Resolution: Fixed
> .NET: Add tests for Thin Client async continuation behavior
> ---
>
> Key: IGNITE-12242
> URL: https://issues.apache.org/jira/browse/IGNITE-12242
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add a test to verify that Thin Client async operation continuations run on
> Thread Pool threads, and not on socket reader thread.
> The behavior is correct right now thanks to {{ContWith}} usage in
> {{DoOutInOpAsync}}, but this is an easy mistake to make, so tests are
> important.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12054) [Umbrella][Spark] Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12054: - Summary: [Umbrella][Spark] Upgrade Spark module to 2.4 (was: [Umbrella] Upgrade Spark module to 2.4) > [Umbrella][Spark] Upgrade Spark module to 2.4 > - > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Alexey Zinoviev >Priority: Blocker > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12242) .NET: Add tests for Thin Client async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-12242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940960#comment-16940960
]
Pavel Tupitsyn commented on IGNITE-12242:
-
Merged to master: 5e336d0d9f0ad6d5fd033fa6a8325eee363916dd
> .NET: Add tests for Thin Client async continuation behavior
> ---
>
> Key: IGNITE-12242
> URL: https://issues.apache.org/jira/browse/IGNITE-12242
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add a test to verify that Thin Client async operation continuations run on
> Thread Pool threads, and not on socket reader thread.
> The behavior is correct right now thanks to {{ContWith}} usage in
> {{DoOutInOpAsync}}, but this is an easy mistake to make, so tests are
> important.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12245) [Spark] Support of Null Handling in JOIN condition
[
https://issues.apache.org/jira/browse/IGNITE-12245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-12245:
-
Description:
Also, in Spark was fixed bug with incorrect null handling on columns in codition
https://issues.apache.org/jira/browse/SPARK-21479
It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the
previous migration from 2.2 to 2.3)
Also, in Spark was fixed bug with incorrect null handling on columns in codition
https://issues.apache.org/jira/browse/SPARK-21479
It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the
previous migration from 2.2 to 2.3)
I made experiment with Spark code for version 2.3 it generates the next plan
== Parsed Logical Plan ==
'Project 'jt1.id AS id1#28, 'jt1.val1, 'jt2.id AS id2#29, 'jt2.val2
+- 'Join LeftOuter, ('jt1.val1 = 'jt2.val2)
:- 'UnresolvedRelation `jt1`
+- 'UnresolvedRelation `jt2`
== Analyzed Logical Plan ==
id1: string, val1: string, id2: string, val2: string
Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
+- Join LeftOuter, (val1#11 = val2#25)
:- SubqueryAlias jt1
: +- Relationid#10,val1#11 csv
+- SubqueryAlias jt2
+- Relationid#24,val2#25 csv
== Optimized Logical Plan ==
Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
+- Join LeftOuter, (val1#11 = val2#25)
:- Relationid#10,val1#11 csv
+- Relationid#24,val2#25 csv
The 2.4 generates
== Parsed Logical Plan ==
'Project 'jt1.id AS id1#28, 'jt1.val1, 'jt2.id AS id2#29, 'jt2.val2
+- 'Join LeftOuter, ('jt1.val1 = 'jt2.val2)
:- 'UnresolvedRelation `jt1`
+- 'UnresolvedRelation `jt2`
== Analyzed Logical Plan ==
id1: string, val1: string, id2: string, val2: string
Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
+- Join LeftOuter, (val1#11 = val2#25)
:- SubqueryAlias `jt1`
: +- Relationid#10,val1#11 csv
+- SubqueryAlias `jt2`
+- Relationid#24,val2#25 csv
== Optimized Logical Plan ==
Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
+- Join LeftOuter, (val1#11 = val2#25)
:- Relationid#10,val1#11 csv
+- Filter isnotnull(val2#25)
+- Relationid#24,val2#25 csv
The +- Filter isnotnull(val2#25) is added in optimized logical plan
But in reality it doesn't work properly (and doesn't filter in Spark), but wow!
It works for Ignite (because we honestly work with Spark plan)
If you enable next option
.config("ignite.disableSparkSQLOptimization", "true") - the behaviour will be
the same in Ignite and Spark and will not add the filter
The best approach for Spark 2.4 - disableSparkOptimization before fixing on
Spark side (I could create a bug for this)
was:
Also, in Spark was fixed bug with incorrect null handling on columns in codition
https://issues.apache.org/jira/browse/SPARK-21479
It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the
previous migration from 2.2 to 2.3)
> [Spark] Support of Null Handling in JOIN condition
> --
>
> Key: IGNITE-12245
> URL: https://issues.apache.org/jira/browse/IGNITE-12245
> Project: Ignite
> Issue Type: Sub-task
> Components: spark
>Affects Versions: 2.8
>Reporter: Alexey Zinoviev
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.8
>
>
> Also, in Spark was fixed bug with incorrect null handling on columns in
> codition
> https://issues.apache.org/jira/browse/SPARK-21479
> It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the
> previous migration from 2.2 to 2.3)
>
> Also, in Spark was fixed bug with incorrect null handling on columns in
> codition
> https://issues.apache.org/jira/browse/SPARK-21479
> It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the
> previous migration from 2.2 to 2.3)
>
>
> I made experiment with Spark code for version 2.3 it generates the next plan
> == Parsed Logical Plan ==
> 'Project 'jt1.id AS id1#28, 'jt1.val1, 'jt2.id AS id2#29, 'jt2.val2
> +- 'Join LeftOuter, ('jt1.val1 = 'jt2.val2)
> :- 'UnresolvedRelation `jt1`
> +- 'UnresolvedRelation `jt2`
> == Analyzed Logical Plan ==
> id1: string, val1: string, id2: string, val2: string
> Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
> +- Join LeftOuter, (val1#11 = val2#25)
> :- SubqueryAlias jt1
> : +- Relationid#10,val1#11 csv
> +- SubqueryAlias jt2
> +- Relationid#24,val2#25 csv
> == Optimized Logical Plan ==
> Project id#10 AS id1#28, val1#11, id#24 AS id2#29, val2#25
> +- Join LeftOuter, (val1#11 = val2#25)
> :- Relationid#10,val1#11 csv
> +- Relationid#24,val2#25 csv
>
> The 2.4 generates
> == Parsed Logical Plan ==
> 'Project 'jt1.id AS id1#28, 'jt1.val1, 'jt2.id AS id2#29, 'jt2.val2
> +- 'Join LeftOuter, ('jt1.val1 = 'jt2.val2)
> :- 'UnresolvedRelation `jt1`
> +- 'UnresolvedRelation `jt2`
> == Analyzed Logical Plan ==
> id1: string, val1: string, id
[jira] [Updated] (IGNITE-12054) [Umbrella] Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12054: - Summary: [Umbrella] Upgrade Spark module to 2.4 (was: Upgrade Spark module to 2.4) > [Umbrella] Upgrade Spark module to 2.4 > -- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Alexey Zinoviev >Priority: Blocker > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12247) [Spark] Add initial support of Spark 2.4
Alexey Zinoviev created IGNITE-12247: Summary: [Spark] Add initial support of Spark 2.4 Key: IGNITE-12247 URL: https://issues.apache.org/jira/browse/IGNITE-12247 Project: Ignite Issue Type: Sub-task Components: spark Affects Versions: 2.8 Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.8 This solution provides the initial support of spark 2.4 with copied codebase from spark and with initial support of ExternalCatalog refactoring -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12246) [Spark] Add support of changes in External Catalog
Alexey Zinoviev created IGNITE-12246: Summary: [Spark] Add support of changes in External Catalog Key: IGNITE-12246 URL: https://issues.apache.org/jira/browse/IGNITE-12246 Project: Ignite Issue Type: Sub-task Components: spark Affects Versions: 2.8 Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.8 It leads to problems with schemas For example, next tests are muted now in Spark 2.4 "Additional features for IgniteSparkSession" and "Should allow Spark SQL to create a table" "Should disallow creation of tables in non-PUBLIC schemas" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12245) [Spark] Support of Null Handling in JOIN condition
Alexey Zinoviev created IGNITE-12245: Summary: [Spark] Support of Null Handling in JOIN condition Key: IGNITE-12245 URL: https://issues.apache.org/jira/browse/IGNITE-12245 Project: Ignite Issue Type: Sub-task Components: spark Affects Versions: 2.8 Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.8 Also, in Spark was fixed bug with incorrect null handling on columns in codition https://issues.apache.org/jira/browse/SPARK-21479 It leads to IgniteOptimizationJoinSpec fixes (the same thing was in the previous migration from 2.2 to 2.3) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12244) [Spark] Fix test with Multiple Joins
Alexey Zinoviev created IGNITE-12244: Summary: [Spark] Fix test with Multiple Joins Key: IGNITE-12244 URL: https://issues.apache.org/jira/browse/IGNITE-12244 Project: Ignite Issue Type: Sub-task Components: spark Affects Versions: 2.8 Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.8 Fix test "JOIN 3 TABLE" after investigation in strange join plan generation in spark 2.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12243) [Spark] Add support of HAVING without GROUP BY
[ https://issues.apache.org/jira/browse/IGNITE-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12243: - Description: Also the semantic of Having support was changed in Spark [https://github.com/apache/spark/pull/22696/files] https://issues.apache.org/jira/browse/SPARK-25708 Now Having could be a legal operation without GroupBY Rewrite the test "SELECT id FROM city HAVING id > 1" was: Also the semantic of Having support was changed in Spark [https://github.com/apache/spark/pull/22696/files] https://issues.apache.org/jira/browse/SPARK-25708 Now Having could be a legal operation without GroupBY > [Spark] Add support of HAVING without GROUP BY > -- > > Key: IGNITE-12243 > URL: https://issues.apache.org/jira/browse/IGNITE-12243 > Project: Ignite > Issue Type: Sub-task > Components: spark >Affects Versions: 2.8 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Also the semantic of Having support was changed in Spark > [https://github.com/apache/spark/pull/22696/files] > https://issues.apache.org/jira/browse/SPARK-25708 > Now Having could be a legal operation without GroupBY > > Rewrite the test "SELECT id FROM city HAVING id > 1" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12243) [Spark] Add support of HAVING without GROUP BY
[ https://issues.apache.org/jira/browse/IGNITE-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12243: - Description: Also the semantic of Having support was changed in Spark [https://github.com/apache/spark/pull/22696/files] https://issues.apache.org/jira/browse/SPARK-25708 Now Having could be a legal operation without GroupBY > [Spark] Add support of HAVING without GROUP BY > -- > > Key: IGNITE-12243 > URL: https://issues.apache.org/jira/browse/IGNITE-12243 > Project: Ignite > Issue Type: Sub-task > Components: spark >Affects Versions: 2.8 >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Also the semantic of Having support was changed in Spark > [https://github.com/apache/spark/pull/22696/files] > https://issues.apache.org/jira/browse/SPARK-25708 > Now Having could be a legal operation without GroupBY -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12243) [Spark] Add support of HAVING without GROUP BY
Alexey Zinoviev created IGNITE-12243: Summary: [Spark] Add support of HAVING without GROUP BY Key: IGNITE-12243 URL: https://issues.apache.org/jira/browse/IGNITE-12243 Project: Ignite Issue Type: Sub-task Components: spark Affects Versions: 2.8 Reporter: Alexey Zinoviev Assignee: Alexey Zinoviev Fix For: 2.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12054) Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12054: - Issue Type: New Feature (was: Task) > Upgrade Spark module to 2.4 > --- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Alexey Zinoviev >Priority: Blocker > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[ https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-11125: --- Assignee: (was: Ivan Pavlukhin) > Use alternative column instead of special _key for indexes. > --- > > Key: IGNITE-11125 > URL: https://issues.apache.org/jira/browse/IGNITE-11125 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we can have the same columns for sorted inline indexes twice > because in part cases use alternative columns for another case special column > _key. To avoid duplicate the same columns need to use alternative columns > (real columns) always. > > For example for > CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY > (ID1 DESC, ID2)) > CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) > > will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY* instead > of ID2 DESC, ID1, MY_VAL DESC > > > The task may be better to do together with > [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, > seems, both of them required compatibility changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[ https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-11125: --- Assignee: Ivan Pavlukhin > Use alternative column instead of special _key for indexes. > --- > > Key: IGNITE-11125 > URL: https://issues.apache.org/jira/browse/IGNITE-11125 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Ivan Pavlukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we can have the same columns for sorted inline indexes twice > because in part cases use alternative columns for another case special column > _key. To avoid duplicate the same columns need to use alternative columns > (real columns) always. > > For example for > CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY > (ID1 DESC, ID2)) > CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) > > will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY* instead > of ID2 DESC, ID1, MY_VAL DESC > > > The task may be better to do together with > [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, > seems, both of them required compatibility changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11125) Use alternative column instead of special _key for indexes.
[ https://issues.apache.org/jira/browse/IGNITE-11125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-11125: --- Assignee: (was: Yury Gerzhedovich) > Use alternative column instead of special _key for indexes. > --- > > Key: IGNITE-11125 > URL: https://issues.apache.org/jira/browse/IGNITE-11125 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently we can have the same columns for sorted inline indexes twice > because in part cases use alternative columns for another case special column > _key. To avoid duplicate the same columns need to use alternative columns > (real columns) always. > > For example for > CREATE TABLE PUBLIC.DFLT_CACHE (ID1 INT, ID2 INT, MY_VAL VARCHAR, PRIMARY KEY > (ID1 DESC, ID2)) > CREATE INDEX IDX_1 ON PUBLIC.DFLT_CACHE(ID2 DESC, ID1, MY_VAL DESC) > > will be use the follow columns ID2 DESC, ID1, MY_VAL DESC, *_KEY* instead > of ID2 DESC, ID1, MY_VAL DESC > > > The task may be better to do together with > [IGNITE-11250|https://issues.apache.org/jira/browse/IGNITE-11250], due to, > seems, both of them required compatibility changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12096) Ignite memory metrics incorrect on cache usage contraction
[
https://issues.apache.org/jira/browse/IGNITE-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Cassidy updated IGNITE-12096:
---
Description:
When using the Ignite metrics API to measure available memory, the usage
figures appear to be accurate while memory is being consumed - but when memory
is freed the metrics do not drop. They appear to report that memory has not
been freed up, even though it has.
A reliable estimate of memory consumption is very important for solutions that
don't use native persistence - as this is the only controllable way of avoiding
a critical OOM condition.
Reproducer below. This affects Ignite 2.7+.
{{}}{{import org.apache.ignite.failure.NoOpFailureHandler; }}
{{import org.junit.Test; }}
{{public class MemoryTest2 { }}
{{ private static final String CACHE_NAME = "cache"; }}
{{ private static final String DEFAULT_MEMORY_REGION = "Default_Region"; }}
{{ private static final long MEM_SIZE = 100L * 1024 * 1024; }}
{{ @Test }}
{{ public void testOOM() throws InterruptedException { }}
{{ try (Ignite ignite = startIgnite("IgniteMemoryMonitorTest1")) { }}
{{ fillDataRegion(ignite); }}
{{ CacheConfiguration cfg = new }}
{{CacheConfiguration<>(CACHE_NAME); }}
{{ cfg.setStatisticsEnabled(true); }}
{{ IgniteCache cache = }}
{{ignite.getOrCreateCache(cfg); }}
{{ // Clear all entries from the cache to free up memory }}
{{ memUsed(ignite); }}
{{ cache.clear(); }}
{{ cache.removeAll(); }}
{{ cache.put("Key", "Value"); }}
{{ memUsed(ignite); }}
{{ cache.destroy(); }}
{{ Thread.sleep(5000); }}
{{ // Should now report close to 0% but reports 59% still }}
{{ memUsed(ignite); }}
{{ } }}
{{ } }}
{{ }}
{{ private Ignite startIgnite(String instanceName) { }}
{{ IgniteConfiguration cfg = new IgniteConfiguration(); }}
{{ cfg.setIgniteInstanceName(instanceName); }}
{{ cfg.setDataStorageConfiguration(createDataStorageConfiguration()); }}
{{ cfg.setFailureHandler(new NoOpFailureHandler()); }}
{{ return Ignition.start(cfg); }}
{{ } }}
{{ private DataStorageConfiguration createDataStorageConfiguration() { }}
{{ return new DataStorageConfiguration() }}
{{ .setDefaultDataRegionConfiguration( }}
{{ new DataRegionConfiguration() }}
{{ .setName(DEFAULT_MEMORY_REGION) }}
{{ .setInitialSize(MEM_SIZE) }}
{{ .setMaxSize(MEM_SIZE) }}
{{ .setMetricsEnabled(true)); }}
{{ } }}
{{ private void fillDataRegion(Ignite ignite) { }}
{{ byte[] megabyte = new byte[1024 * 1024]; }}
{{ IgniteCache cache = }}
{{ ignite.getOrCreateCache(CACHE_NAME); }}
{{ for (int i = 0; i < 50; i++) { }}
{{ cache.put(i, megabyte); }}
{{ memUsed(ignite); }}
{{ } }}
{{ } }}
{{ private void memUsed(Ignite ignite) { }}
{{ DataRegionConfiguration defaultDataRegionCfg = }}
{{ignite.configuration() }}
{{ .getDataStorageConfiguration() }}
{{ .getDefaultDataRegionConfiguration(); }}
{{ String regionName = defaultDataRegionCfg.getName(); }}
{{ DataRegionMetrics metrics = ignite.dataRegionMetrics(regionName); }}
{{ float usedMem = metrics.getPagesFillFactor() * }}
{{metrics.getTotalAllocatedPages() * metrics.getPageSize(); }}
{{ float pctUsed = 100 * usedMem / defaultDataRegionCfg.getMaxSize(); }}
{{ System.out.println("Memory used: " + pctUsed + "%"); }}
{{ } }}
{{} }}
was:
When using the Ignite metrics API to measure available memory, the usage
figures appear to be accurate while memory is being consumed - but when memory
is freed the metrics do not drop. They appear to report that memory has not
been freed up, even though it has.
Reproducer below. This affects Ignite 2.7+.
{{}}{{import org.apache.ignite.failure.NoOpFailureHandler; }}
{{import org.junit.Test; }}
{{public class MemoryTest2 { }}
{{ private static final String CACHE_NAME = "cache"; }}
{{ private static final String DEFAULT_MEMORY_REGION = "Default_Region"; }}
{{ private static final long MEM_SIZE = 100L * 1024 * 1024; }}
{{ @Test }}
{{ public void testOOM() throws InterruptedException { }}
{{ try (Ignite ignite = startIgnite("IgniteMemoryMonitorTest1")) { }}
{{ fillDataRegion(ignite); }}
{{ CacheConfiguration cfg = new }}
{{CacheConfiguration<>(CACHE_NAME); }}
{{ cfg.setStatisticsEnabled(true); }}
{{ IgniteCache cache = }}
{{ignite.getOrCreateCache(cfg); }}
{{ // Clear all entries from the c
[jira] [Updated] (IGNITE-12226) Improve BinaryObjectException message
[
https://issues.apache.org/jira/browse/IGNITE-12226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12226:
--
Component/s: binary
> Improve BinaryObjectException message
> -
>
> Key: IGNITE-12226
> URL: https://issues.apache.org/jira/browse/IGNITE-12226
> Project: Ignite
> Issue Type: Improvement
> Components: binary
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We are getting the following exception in case of different type IDs:
> {noformat}
> org.apache.ignite.binary.BinaryObjectException: Failed to get field because
> type ID of passed object differs from type ID this BinaryField belongs to
> [expected=-635374417, actual=1778229603]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue(GridH2KeyValueRowOnheap.java:106)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:350)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:56)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4614)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4534)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$1300(BPlusTree.java:92)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:296)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4967)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:276)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4952)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:161)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:348)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2450)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2203)
> {noformat}
> This message isn't informative. We should print more detailes about types,
> for example classname, class structure (if applicable), which field in class
> we tried to read.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[
https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940904#comment-16940904
]
Nikolay Izhikov commented on IGNITE-12209:
--
> I would add try ... catch block to avoid issues.
We should wrap every execution of every method to try catch blocks if we
follow this kind of logic.
> Writing a code on assumption what this will not happen is bad.
> In fact, both can fail if something will change if future in underlying
> implementation.
What, exactly, "will not happen"?
execution of {{size()}} can't fail because of Collection contract.
If it throws an exception it a bug that will lead to specific system view error.
> Transaction system view
> ---
>
> Key: IGNITE-12209
> URL: https://issues.apache.org/jira/browse/IGNITE-12209
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> IGNITE-12145 finished
> We should add transactions to the system views.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940887#comment-16940887 ] Alexei Scherbakov commented on IGNITE-12209: allEntries has multiple implementations. What one are you talking about ? Are you sure all implementations are safe ? In fact, both can fail if something will change if future in underlying implementation. Writing a code on assumption what this will not happen is bad. I would add try ... catch block to avoid issues. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12242) .NET: Add tests for Thin Client async continuation behavior
Pavel Tupitsyn created IGNITE-12242:
---
Summary: .NET: Add tests for Thin Client async continuation
behavior
Key: IGNITE-12242
URL: https://issues.apache.org/jira/browse/IGNITE-12242
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
Add a test to verify that Thin Client async operation continuations run on
Thread Pool threads, and not on socket reader thread.
The behavior is correct right now thanks to {{ContWith}} usage in
{{DoOutInOpAsync}}, but this is an easy mistake to make, so tests are important.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12209) Transaction system view
[
https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940847#comment-16940847
]
Nikolay Izhikov edited comment on IGNITE-12209 at 9/30/19 10:49 AM:
[~ascherbakov]
> AFAIK call of the size can't fail.
> There are absolutely no guarantee this would always work.
Did you mean the execution of size can fail?
Or we talking only about {{IgniteTxState#cacheIds}}?
What kind of guarantees do you want to see?
was (Author: nizhikov):
> AFAIK call of the size can't fail.
> There are absolutely no guarantee this would always work.
Did you mean the execution of size can fail?
Or we talking only about {{IgniteTxState#cacheIds}}?
What kind of guarantees do you want to see?
> Transaction system view
> ---
>
> Key: IGNITE-12209
> URL: https://issues.apache.org/jira/browse/IGNITE-12209
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> IGNITE-12145 finished
> We should add transactions to the system views.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[
https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940847#comment-16940847
]
Nikolay Izhikov commented on IGNITE-12209:
--
> AFAIK call of the size can't fail.
> There are absolutely no guarantee this would always work.
Did you mean the execution of size can fail?
Or we talking only about {{IgniteTxState#cacheIds}}?
What kind of guarantees do you want to see?
> Transaction system view
> ---
>
> Key: IGNITE-12209
> URL: https://issues.apache.org/jira/browse/IGNITE-12209
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> IGNITE-12145 finished
> We should add transactions to the system views.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940834#comment-16940834 ] Alexei Scherbakov commented on IGNITE-12209: [~nizhikov] There are absolutely no guarantee this would always work. Having catch block is 100% safe. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[
https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940816#comment-16940816
]
Nikolay Izhikov commented on IGNITE-12209:
--
[~ascherbakov]
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#allEntries
AFAIK call of the {{size}} can't fail.
I've added {{null}} check, because some implementation can return null.
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#cacheIds
As I can see, {{cacheIds}} is add only collection.
I've added {{null}} check.
I think we can cache current size of the cache id and simply iterate over
{{cacheIds}} values.
Please, take a look at the current implementation
> Transaction system view
> ---
>
> Key: IGNITE-12209
> URL: https://issues.apache.org/jira/browse/IGNITE-12209
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> IGNITE-12145 finished
> We should add transactions to the system views.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11992) Improvements for new security approach
[ https://issues.apache.org/jira/browse/IGNITE-11992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim updated IGNITE-11992: -- Description: 1. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 2. The GridRestProcessor does tasks outside "withContext" section. As result context loses. 3. The GridRestProcessor isn't client, we can't read security subject from node attribute. We should transmit secCtx for fake nodes and secSubjId for real. In additional: Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and CacheQueryReadEvent. "Gets security subject ID initiated this task event, if available. This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET task event. Subject ID will be set either to node ID or client ID initiated task execution." by: "Gets security subject ID initiated this task event if IgniteSecurity is enabled, otherwise returns null." was: 1. The visor tasks lost permission. The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses context. 3. The GridRestProcessor does tasks outside "withContext" section. As result context loses. 4. The GridRestProcessor isn't client, we can't read security subject from node attribute. We should transmit secCtx for fake nodes and secSubjId for real. > Improvements for new security approach > -- > > Key: IGNITE-11992 > URL: https://issues.apache.org/jira/browse/IGNITE-11992 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 1. The visor tasks lost permission. > The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses > context. > 2. The GridRestProcessor does tasks outside "withContext" section. As result > context loses. > 3. The GridRestProcessor isn't client, we can't read security subject from > node attribute. > We should transmit secCtx for fake nodes and secSubjId for real. > In additional: > Change a java docs for TaskEvent, CacheEvent, CacheQueryExecutedEvent and > CacheQueryReadEvent. > "Gets security subject ID initiated this task event, if available. > This property is not available for GridEventType#EVT_TASK_SESSION_ATTR_SET > task event. > Subject ID will be set either to node ID or client ID initiated task > execution." > by: > "Gets security subject ID initiated this task event if IgniteSecurity is > enabled, otherwise returns null." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-12174:
-
Attachment: GeospatialIndexBug.java
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.6
> Environment: Ignite modules
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
> Attachments: GeospatialIndexBug.java
>
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12174) NPE during expiration of spatial data when durable memory is active
[
https://issues.apache.org/jira/browse/IGNITE-12174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Schäfer updated IGNITE-12174:
-
Attachment: (was: IgniteBug.java)
> NPE during expiration of spatial data when durable memory is active
> ---
>
> Key: IGNITE-12174
> URL: https://issues.apache.org/jira/browse/IGNITE-12174
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8, 2.7.6
> Environment: Ignite modules
> * ignite-core
> * ignite-indexing
> * ignite-geospatial
> Durable memory activated
> Geospatial indexing in use
>Reporter: Jan Schäfer
>Priority: Major
>
> I get a NullPointerException when I restart my Ignite instance with durable
> memory activated and geospatial data in use:
> {code:java}
> SEVERE: Critical system error detected. Will be handled accordingly to
> configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false,
> timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]SEVERE:
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION,
> err=java.lang.NullPointerException]]java.lang.NullPointerException at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.remove(GridH2SpatialIndex.java:249)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2SpatialIndex.removex(GridH2SpatialIndex.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.remove(GridH2Table.java:525)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.remove(IgniteH2Indexing.java:801)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.remove(GridQueryProcessor.java:2557)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.remove(GridCacheQueryManager.java:435)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishRemove(IgniteCacheOffheapManagerImpl.java:2736)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2713)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.remove(GridCacheOffheapManager.java:2131)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:663)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4441)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4134)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:61)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:52)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2413)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:980)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:150)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> java.lang.Thread.run(Thread.java:748)
> {code}
> Minimal reproducing code sample is attached:
> # start IgniteBug one time
> # wait some seconds
> # start IgniteBug a second time
> # see NullPointerException from above
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12192) visorcmd hangs if you ^D to quit
[ https://issues.apache.org/jira/browse/IGNITE-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940786#comment-16940786 ] Stephen Darlington commented on IGNITE-12192: - The attached patch ([GitHub Pull Request #6877|https://github.com/apache/ignite/pull/6877]) offers a third way: when it falls out of the main loop, disconnect from the cluster if it's connected. > visorcmd hangs if you ^D to quit > > > Key: IGNITE-12192 > URL: https://issues.apache.org/jira/browse/IGNITE-12192 > Project: Ignite > Issue Type: Bug > Components: visor >Affects Versions: 2.7.5 >Reporter: Stephen Darlington >Assignee: Stephen Darlington >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > You can exit most Unix utilities by pressing ^D. However, if you do that in > ignitevisorcmd when you're connected to a cluster, the process hangs. You > have to press ^C to quit. (It does work as expected if you close the > connection first.) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Description: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any up to date version of spring. Fixing this would require updating that's the reason I'm puting this as Improvement. was: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any up to date version of spring. Fixing this would require updating wich is why I'm puting this as Improvement. > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any up to date version of spring. Fixing > this would require updating that's the reason I'm > puting this as Improvement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Issue Type: Improvement (was: Bug) > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any updated version of spring. Fixing this > would require updating -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Description: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any updated version of spring. Fixing this would require updating was: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any updated version of spring > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any updated version of spring. Fixing this > would require updating -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Description: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any up to date version of spring. Fixing this would require updating wich is why I'm puting this as Improvement. was: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any updated version of spring. Fixing this would require updating > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any up to date version of spring. Fixing > this would require updating wich is why I'm puting > this as Improvement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Issue Type: Bug (was: Improvement) > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any updated version of spring -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Issue Type: Improvement (was: Bug) > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Improvement > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any updated version of spring -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12236) RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in IgniteRepositoryFactory
[ https://issues.apache.org/jira/browse/IGNITE-12236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thibaut updated IGNITE-12236: - Description: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor This prevents using ignite with any updated version of spring was: Hello, org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy does not override org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy since this commit [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] this results in a thrown exception in org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > RepositoryFactorySupport#getQueryLookupStrategy no longer overriden in > IgniteRepositoryFactory > -- > > Key: IGNITE-12236 > URL: https://issues.apache.org/jira/browse/IGNITE-12236 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8, 2.7.6 >Reporter: Thibaut >Priority: Major > > Hello, > org.apache.ignite.springdata20.repository.support.IgniteRepositoryFactory#getQueryLookupStrategy > does not override > org.springframework.data.repository.core.support.RepositoryFactorySupport#getQueryLookupStrategy > since this commit > [https://github.com/spring-projects/spring-data-commons/commit/a6215fbe0f5c9a254cddacb12763737f2c286ad5] > > this results in a thrown exception in > org.springframework.data.repository.core.support.RepositoryFactorySupport.QueryExecutorMethodInterceptor#QueryExecutorMethodInterceptor > > This prevents using ignite with any updated version of spring -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12201) distributed sql join not working as mentioned in documentation
[
https://issues.apache.org/jira/browse/IGNITE-12201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940749#comment-16940749
]
Ivan Pavlukhin commented on IGNITE-12201:
-
Hi [~shm],
I suppose that a confusing term in
[documentation|https://apacheignite-sql.readme.io/docs/distributed-joins] is
_cross-table joins_. In test coverage we have a test checking that CROSS JOIN
with distributedJoins=true throws an exception. And seems that it is impossible
to setup indexes for CROSS JOIN. Otherwise you need N-1 replicated tables.
> distributed sql join not working as mentioned in documentation
> --
>
> Key: IGNITE-12201
> URL: https://issues.apache.org/jira/browse/IGNITE-12201
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
> Environment: Kubernetes on RHEL 7.6
>Reporter: shivakumar
>Priority: Major
> Attachments: distributed_sql_error.txt
>
>
> I am trying to do a simple cross join on two tables with non-collocated data
> (without affinity key),
> This non-collocated distributed join always fails with the error message:
>
> *"java.sql.SQLException: javax.cache.CacheException: Failed to prepare
> distributed join query: join condition does not use index "*
>
> If I create one of the tables in replicated mode and another one in
> partitioned mode this Join operation works but documentation mentions that
> Ignite supports non-collocated joins without any condition.
> And we tried with 3 tables and 1 in replicated and other 2 in partitioned
> then we observed that it failed.
> we are running the Join operations with *distributedJoins=true.*
> *We observed that if there are N tables in Join operation then (N-1) should
> be in replicated mode, is our understanding right?*
> *If our understanding is correct then to do Join operation the dimensioning
> of cluster increases by many folds which can't be used in a production
> environment.*
> *To reproduce:*
> *Ignite with 4 node cluster with native persistence enabled.*
> *create the following tables*
> {quote} {{CREATE TABLE City (}}{quote}
> {quote} {{ id LONG PRIMARY KEY, name VARCHAR)}}{quote}
> {quote} {{ WITH "backup=1";}}{quote}
> {quote} {{}}{quote}
> {quote} {{CREATE TABLE Person (}}
> {{ id LONG, name VARCHAR, city_id LONG, PRIMARY KEY (id, city_id))}}
> {{ WITH "backups=1";}}
> {{}}
> {{CREATE INDEX idx_city_name ON City (name);}}
> {{}}
> {{CREATE INDEX idx_person_name ON Person (name);}}
>
> {{INSERT INTO City (id, name) VALUES (1, 'Forest Hill');}}
> {{INSERT INTO City (id, name) VALUES (2, 'Denver');}}
> {{INSERT INTO City (id, name) VALUES (3, 'St. Petersburg');}}
> {{}}
> {{INSERT INTO Person (id, name, city_id) VALUES (1, 'John Doe', 3);}}
> {{INSERT INTO Person (id, name, city_id) VALUES (2, 'Jane Roe', 2);}}
> {{INSERT INTO Person (id, name, city_id) VALUES (3, 'Mary Major', 1);}}
> {{INSERT INTO Person (id, name, city_id) VALUES (4, 'Richard Miles', 2);}} {{
> }}{quote}
> Query to be run:
> {quote}select * from City c, Person p;{color:#66}
> {color}{quote}
> {quote}or
> {color:#80}*SELECT*{color} * *{color:#80}FROM{color}* City
> *{color:#80}AS{color}* c *{color:#80}CROSS{color}*
> *{color:#80}join{color}* Person *{color:#80}AS{color}* p;{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11992) Improvements for new security approach
[ https://issues.apache.org/jira/browse/IGNITE-11992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940737#comment-16940737 ] Stepachev Maksim commented on IGNITE-11992: --- [~garus.d.g], please look the pull-request. > Improvements for new security approach > -- > > Key: IGNITE-11992 > URL: https://issues.apache.org/jira/browse/IGNITE-11992 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.8 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 1. The visor tasks lost permission. > The method VisorQueryUtils#scheduleQueryStart makes a new thread and loses > context. > 3. The GridRestProcessor does tasks outside "withContext" section. As result > context loses. > 4. The GridRestProcessor isn't client, we can't read security subject from > node attribute. > We should transmit secCtx for fake nodes and secSubjId for real. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12220) Allow to use cache-related permissions both at system and per-cache levels
[
https://issues.apache.org/jira/browse/IGNITE-12220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940735#comment-16940735
]
Stepachev Maksim commented on IGNITE-12220:
---
[~RyzhovSV], Looks good for me.
> Allow to use cache-related permissions both at system and per-cache levels
> --
>
> Key: IGNITE-12220
> URL: https://issues.apache.org/jira/browse/IGNITE-12220
> Project: Ignite
> Issue Type: Task
> Components: security
>Affects Versions: 2.7.6
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, {{CACHE_CREATE}} and {{CACHE_DESTROY}} permissions are enforced to
> be system-level permissions, see for instance
> {{SecurityPermissionSetBuilder#appendCachePermissions}}. This looks
> inflexible: Ignite Security implementations are not able to manage cache
> creation and deletion permissions on per-cache basis (unlike get/put/remove
> permissions). All such limitations should be found and removed in order to
> allow all {{CACHE_*}} permissions to be set both at system and per-cache
> levels.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940709#comment-16940709 ] Alexei Scherbakov edited comment on IGNITE-12209 at 9/30/19 7:37 AM: - [~nizhikov] Note what org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#allEntries and org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#cacheIds are unsynchronized and tx state can be concurrently updated if a transaction enlists keys in the moment of view producing. So current implementation is unsafe but probably will work somehow. I suggest to enclose methods in try .. catch(Throwable) to implement fallback in case something goes wrong. was (Author: ascherbakov): [~nizhikov] Note what org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#allEntries and org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#cacheIds are unsynchronized and can be concurrently updated if a transaction enlists keys in the moment of view producing. So current implementation is unsafe but probably will work somehow. I suggest to enclose methods in try .. catch(Throwable) to implement fallback in case something goes wrong. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940709#comment-16940709 ] Alexei Scherbakov commented on IGNITE-12209: [~nizhikov] Note what org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#allEntries and org.apache.ignite.internal.processors.cache.transactions.IgniteTxState#cacheIds are unsynchronized and can be concurrently updated if a transaction enlists keys in the moment of view producing. So current implementation is unsafe but probably will work somehow. I suggest to enclose methods in try .. catch(Throwable) to implement fallback in case something goes wrong. > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12209) Transaction system view
[ https://issues.apache.org/jira/browse/IGNITE-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16940698#comment-16940698 ] Denis Garus commented on IGNITE-12209: -- LGFM > Transaction system view > --- > > Key: IGNITE-12209 > URL: https://issues.apache.org/jira/browse/IGNITE-12209 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add transactions to the system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
