[jira] [Assigned] (IGNITE-11443) usability improvements for INDEXES system SQL view
[ https://issues.apache.org/jira/browse/IGNITE-11443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-11443: -- Assignee: Yury Gerzhedovich > usability improvements for INDEXES system SQL view > -- > > Key: IGNITE-11443 > URL: https://issues.apache.org/jira/browse/IGNITE-11443 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > > For all views need to: > 1) move cache and cache group attributes to the beginning to form consistent > hierarchy: cache group -> cache -> table -> index > 2) columns GROUP_ID and GROUP_NAME should be renamed to CACHE_GROUP_ID and > CACHE_GROUP_NAME respectively -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[ https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786482#comment-16786482 ] Yury Gerzhedovich commented on IGNITE-11434: [~vozerov], [~tledkov-gridgain], What reason to have PRIMARY_KEY column? We can have complex PK, when few columns will be part of PK. Moreover if we will have we don't know position the column in the PK. May be such information should be placed in INDEX view? > SQL: Create a view with list of existing COLUMNS > > > Key: IGNITE-11434 > URL: https://issues.apache.org/jira/browse/IGNITE-11434 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Need to expose SQL system view with COLUMNS information. > Need to investigate more deeper which of information should be there. > > As start point we can take > [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11497) Web console: index.html is cached
[ https://issues.apache.org/jira/browse/IGNITE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reassigned IGNITE-11497: --- Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) > Web console: index.html is cached > - > > Key: IGNITE-11497 > URL: https://issues.apache.org/jira/browse/IGNITE-11497 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Major > > Some users, including [~pkonstantinov], reported cache-related issues for a > long while. According to [this > article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], > it might have to do with index.html caching, so let's disabled caching for > this particular file. > What to do: > Disable index.html caching. > Acceptance criteria: > With "disable cache" option turned off in web inspector, index.html should > always be loaded from server. Here's a convoluted scenario: > 1. Build docker image of web console > 2. Open a tab (A), open web inspector on network tab, ensure caching is > enabled, go to web console. > 3. Build the image again. > 4. Open another tab (B), open web inspector on network tab, ensure caching is > not disabled, go to web console; index.html should not reported cache usage, > js/css assets should have file names different from same files in inspector > of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11497) Web console: index.html is cached
[ https://issues.apache.org/jira/browse/IGNITE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786472#comment-16786472 ] Pavel Konstantinov commented on IGNITE-11497: - Looks like works right > Web console: index.html is cached > - > > Key: IGNITE-11497 > URL: https://issues.apache.org/jira/browse/IGNITE-11497 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Major > > Some users, including [~pkonstantinov], reported cache-related issues for a > long while. According to [this > article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], > it might have to do with index.html caching, so let's disabled caching for > this particular file. > What to do: > Disable index.html caching. > Acceptance criteria: > With "disable cache" option turned off in web inspector, index.html should > always be loaded from server. Here's a convoluted scenario: > 1. Build docker image of web console > 2. Open a tab (A), open web inspector on network tab, ensure caching is > enabled, go to web console. > 3. Build the image again. > 4. Open another tab (B), open web inspector on network tab, ensure caching is > not disabled, go to web console; index.html should not reported cache usage, > js/css assets should have file names different from same files in inspector > of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11500) Web Console: All emails to user should have template
Andrey Novikov created IGNITE-11500: --- Summary: Web Console: All emails to user should have template Key: IGNITE-11500 URL: https://issues.apache.org/jira/browse/IGNITE-11500 Project: Ignite Issue Type: Improvement Components: wizards Affects Versions: 2.7 Reporter: Andrey Novikov Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-5254) Add web-console folder structure description
[ https://issues.apache.org/jira/browse/IGNITE-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-5254. Resolution: Won't Fix Ticket is out of date. > Add web-console folder structure description > > > Key: IGNITE-5254 > URL: https://issues.apache.org/jira/browse/IGNITE-5254 > Project: Ignite > Issue Type: Task > Components: UI, wizards >Affects Versions: 2.0 >Reporter: Dmitriy Shabalin >Assignee: Andrey Novikov >Priority: Major > > structure example > Web Console Frontend > -- components > -- -- index.js [web-console.components] > -- -- some-component > -- -- -- index.js (imports) > -- -- -- controller.js > -- -- -- directive.js > -- -- -- service.js > -- -- -- style.scss > -- -- -- template.tpl.pug (components template) > -- filters > -- -- index.js [web-console.filters] > -- -- some filter.js > -- models > -- -- index.js [web-console.models] > -- ignite_modules > -- -- index.js (states, deps) [web-console.modules] > -- -- components > -- -- -- index.js [web-console.modules.components] > -- -- pages > -- -- -- index.js [web-console.modules.pages] > -- -- -- page_1 > -- -- -- -- index.js (imports) > -- -- -- -- components > -- -- -- -- -- some-page-component > -- -- -- -- -- -- index.js (imports) > -- -- -- -- -- -- decorator.js > -- -- -- -- style.scss > > -- services > -- -- index.js [web-console.services] > -- -- some service.js > -- -- some services group > -- -- -- some service1.js > -- -- -- some service2.js > -- pages > -- -- index.js (imports) [web-console.pages] > -- -- page_1 > -- -- -- index.js (states, deps) [web-console.pages.page_1] > -- -- -- template.tpl.pug (page template) > -- -- -- components > -- -- -- -- index.js (imports) > -- -- -- -- some-page-component > -- -- -- -- -- index.js (imports) > -- -- -- -- -- controller.js > -- -- -- -- -- directive.js > -- -- -- -- -- service.js > -- -- -- -- -- template.tpl.pug > -- -- -- -- -- models > -- -- -- -- -- -- index.js (imports) > -- -- -- services > -- -- -- -- some page service.js > -- index.tpl.pug (index page) > -- index.js (app enter point, bootstraps app component) [web-console] > -- variables.scss > -- vendors.js > -- style.scss -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8613) Web console: investigate E2E tests on Node.js 10
[ https://issues.apache.org/jira/browse/IGNITE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-8613. Resolution: Fixed > Web console: investigate E2E tests on Node.js 10 > > > Key: IGNITE-8613 > URL: https://issues.apache.org/jira/browse/IGNITE-8613 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Web console E2E tests fail spontaneously when run under Node.js 10. We should > investigate what causes it: Testcafe incompatibility or something in the web > console code. If new, compatible version of Testcafe becomes available, let's > update to it as a part of this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8613) Web console: investigate E2E tests on Node.js 10
[ https://issues.apache.org/jira/browse/IGNITE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8613. -- > Web console: investigate E2E tests on Node.js 10 > > > Key: IGNITE-8613 > URL: https://issues.apache.org/jira/browse/IGNITE-8613 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Web console E2E tests fail spontaneously when run under Node.js 10. We should > investigate what causes it: Testcafe incompatibility or something in the web > console code. If new, compatible version of Testcafe becomes available, let's > update to it as a part of this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11498) SQL: Rework DML data distribution logic
Vladimir Ozerov created IGNITE-11498:
Summary: SQL: Rework DML data distribution logic
Key: IGNITE-11498
URL: https://issues.apache.org/jira/browse/IGNITE-11498
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Current DML implementation has a number of problems:
1) We fetch the whole data set to originator's node. There is
"skipDmlOnReducer" flag to avoid this in some cases, but it is still in
experimental state, and is not enabled by default
2) Updates are deadlock-prone: we update entries in batches equal to
{{SqlFieldsQuery.pageSize}}. So we can deadlock easily with concurrent cache
operations
3) We have very strange re-try logic. It is not clear why it is needed in the
first place provided that DML is not transactional and no guarantees are needed.
Proposal:
# Implement proper routing logic: if a request could be executed on data nodes
bypassing skipping reducer, do this. Otherwise fetch all data to reducer. This
decision should be made in absolutely the same way as for MVCC (see
{{GridNearTxQueryEnlistFuture}} as a starting point)
# Distribute updates to primary data node in batches, but apply them one by
one, similar to data streamer with {{allowOverwrite=false}}. Do not do any
partition state or {{AffinityTopologyVersion}} checks, since DML is not
transactional. Return and aggregate update counts back.
# Remove or at least rethink retry logic. Why do we need it in the first place?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11499) SQL: DML should not use batches by default
Vladimir Ozerov created IGNITE-11499:
Summary: SQL: DML should not use batches by default
Key: IGNITE-11499
URL: https://issues.apache.org/jira/browse/IGNITE-11499
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
Currently DML apply updates in batches equal to {{SqlFieldsQuery.pageSize}}.
This is prone to deadlocks. Instead, we should apply updates one-by-one by
default. Proposal:
# Introduce {{SqlFieldsQuery.updateBatchSize}} property, set it to {{1}} by
default
# Print a warning about deadlock to log if it is greater than 1
# Add it to JDBC and ODBC drivers
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-11205) Cache (Restarts) 1 flaky tests
[ https://issues.apache.org/jira/browse/IGNITE-11205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim closed IGNITE-11205. - > Cache (Restarts) 1 flaky tests > -- > > Key: IGNITE-11205 > URL: https://issues.apache.org/jira/browse/IGNITE-11205 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[
https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov updated IGNITE-11496:
--
Description:
I've tried to run some long-running queries from WC(more than a couple of
minutes) and I've faced a behavior when the query was canceled without clicking
on the cancel button.
I've opened different browser tabs at this moment, maybe it could be the reason.
{code}
javax.cache.CacheException: Failed to run reduce query locally.
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:883)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$7.iterator(IgniteH2Indexing.java:1494)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.visor.query.VisorQueryHolder.getIterator(VisorQueryHolder.java:97)
at
org.apache.ignite.internal.visor.query.VisorQueryFetchFirstPageTask$VisorQueryFetchFirstPageJob.run(VisorQueryFetchFirstPageTask.java:85)
at
org.apache.ignite.internal.visor.query.VisorQueryFetchFirstPageTask$VisorQueryFetchFirstPageJob.run(VisorQueryFetchFirstPageTask.java:51)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6750)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.cache.query.QueryCancelledException: The
query was cancelled while executing.
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1240)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1303)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1281)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:835)
... 20 more
{code}
was:
I've tried to run some long-running queries from WC(more than a couple of
minutes) and I've faced a behavior when the query was canceled without clicking
on the cancel button.
I've opened different browser tabs at this moment, maybe it could be the reason.
> Long running SQL queries could be randomly canceled from WC
> ---
>
> Key: IGNITE-11496
> URL: https://issues.apache.org/jira/browse/IGNITE-11496
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.5
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>Priority: Major
>
> I've tried to run some long-running queries from WC(more than a couple of
> minutes) and I've faced a behavior when the query was canceled without
> clicking on the cancel button.
> I've opened different browser tabs at this moment, maybe it could be the
> reason.
> {code}
> javax.cache.CacheException: Failed to run reduce query locally.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:883)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$7.iterator(IgniteH2Indexing.java:1494)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.visor.query.VisorQueryHolder.getIterator(VisorQueryHolder.java:97)
> at
>
[jira] [Updated] (IGNITE-11497) Web console: index.html is cached
[ https://issues.apache.org/jira/browse/IGNITE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11497: -- Ignite Flags: (was: Docs Required) > Web console: index.html is cached > - > > Key: IGNITE-11497 > URL: https://issues.apache.org/jira/browse/IGNITE-11497 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Major > > Some users, including [~pkonstantinov], reported cache-related issues for a > long while. According to [this > article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], > it might have to do with index.html caching, so let's disabled caching for > this particular file. > What to do: > Disable index.html caching. > Acceptance criteria: > With "disable cache" option turned off in web inspector, index.html should > always be loaded from server. Here's a convoluted scenario: > 1. Build docker image of web console > 2. Open a tab (A), open web inspector on network tab, ensure caching is > enabled, go to web console. > 3. Build the image again. > 4. Open another tab (B), open web inspector on network tab, ensure caching is > not disabled, go to web console; index.html should not reported cache usage, > js/css assets should have file names different from same files in inspector > of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11497) Web console: index.html is cached
Ilya Borisov created IGNITE-11497: - Summary: Web console: index.html is cached Key: IGNITE-11497 URL: https://issues.apache.org/jira/browse/IGNITE-11497 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Some users, including [~pkonstantinov], reported cache-related issues for a long while. According to [this article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], it might have to do with index.html caching, so let's disabled caching for this particular file. What to do: Disable index.html caching. Acceptance criteria: With "disable cache" option turned off in web inspector, index.html should always be loaded from server. Here's a convoluted scenario: 1. Build docker image of web console 2. Open a tab (A), open web inspector on network tab, ensure caching is enabled, go to web console. 3. Build the image again. 4. Open another tab (B), open web inspector on network tab, ensure caching is not disabled, go to web console; index.html should not reported cache usage, js/css assets should have file names different from same files in inspector of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11497) Web console: index.html is cached
[ https://issues.apache.org/jira/browse/IGNITE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786330#comment-16786330 ] Ilya Borisov commented on IGNITE-11497: --- [~pkonstantinov] please test. > Web console: index.html is cached > - > > Key: IGNITE-11497 > URL: https://issues.apache.org/jira/browse/IGNITE-11497 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Major > > Some users, including [~pkonstantinov], reported cache-related issues for a > long while. According to [this > article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], > it might have to do with index.html caching, so let's disabled caching for > this particular file. > What to do: > Disable index.html caching. > Acceptance criteria: > With "disable cache" option turned off in web inspector, index.html should > always be loaded from server. Here's a convoluted scenario: > 1. Build docker image of web console > 2. Open a tab (A), open web inspector on network tab, ensure caching is > enabled, go to web console. > 3. Build the image again. > 4. Open another tab (B), open web inspector on network tab, ensure caching is > not disabled, go to web console; index.html should not reported cache usage, > js/css assets should have file names different from same files in inspector > of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11497) Web console: index.html is cached
[ https://issues.apache.org/jira/browse/IGNITE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11497: - Assignee: Pavel Konstantinov (was: Ilya Borisov) > Web console: index.html is cached > - > > Key: IGNITE-11497 > URL: https://issues.apache.org/jira/browse/IGNITE-11497 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Major > > Some users, including [~pkonstantinov], reported cache-related issues for a > long while. According to [this > article|https://blog.cronobo.com/2018/03/17/how-to-configure-caching-with-single-page-apps.html], > it might have to do with index.html caching, so let's disabled caching for > this particular file. > What to do: > Disable index.html caching. > Acceptance criteria: > With "disable cache" option turned off in web inspector, index.html should > always be loaded from server. Here's a convoluted scenario: > 1. Build docker image of web console > 2. Open a tab (A), open web inspector on network tab, ensure caching is > enabled, go to web console. > 3. Build the image again. > 4. Open another tab (B), open web inspector on network tab, ensure caching is > not disabled, go to web console; index.html should not reported cache usage, > js/css assets should have file names different from same files in inspector > of browser tab A. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11496: -- Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Vasiliy Sisko >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Ignite Flags: (was: Docs Required) > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-11496: - Assignee: Alexey Kuznetsov > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Assignee: Alexey Kuznetsov >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Component/s: wizards > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
[ https://issues.apache.org/jira/browse/IGNITE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11496: --- Affects Version/s: 2.5 > Long running SQL queries could be randomly canceled from WC > --- > > Key: IGNITE-11496 > URL: https://issues.apache.org/jira/browse/IGNITE-11496 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Evgenii Zhuravlev >Priority: Major > > I've tried to run some long-running queries from WC(more than a couple of > minutes) and I've faced a behavior when the query was canceled without > clicking on the cancel button. > I've opened different browser tabs at this moment, maybe it could be the > reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11496) Long running SQL queries could be randomly canceled from WC
Evgenii Zhuravlev created IGNITE-11496: -- Summary: Long running SQL queries could be randomly canceled from WC Key: IGNITE-11496 URL: https://issues.apache.org/jira/browse/IGNITE-11496 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev I've tried to run some long-running queries from WC(more than a couple of minutes) and I've faced a behavior when the query was canceled without clicking on the cancel button. I've opened different browser tabs at this moment, maybe it could be the reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5962) Increase max length of index name
[
https://issues.apache.org/jira/browse/IGNITE-5962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786215#comment-16786215
]
Ignite TC Bot commented on IGNITE-5962:
---
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests 0 TIMEOUT , Out Of Memory Error ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3251268]]
{color:#d04437}SPI{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3251250]]
{color:#d04437}MVCC Cache{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=3251266]]
{color:#d04437}Cache (Restarts) 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3251281]]
{color:#d04437}Cache 1{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=3251283]]
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3251288]]
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=3251284]]
{color:#d04437}MVCC Cache 1{color} [[tests 0 TIMEOUT , Out Of Memory Error ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=3251321]]
{color:#d04437}PDS 1{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3251301]]
{color:#d04437}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3251331]]
* IgnitePdsMvccTestSuite2: IgnitePdsRebalancingOnNotStableTopologyTest.test -
0,0% fails in last 448 master runs.
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 4 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3251316]]
* ZookeeperDiscoverySpiTestSuite4:
IgniteCachePutRetryTransactionalSelfTest.testGetAndPut - 0,0% fails in last 432
master runs.
* ZookeeperDiscoverySpiTestSuite4:
IgniteCachePutRetryTransactionalSelfTest.testInvoke - 0,0% fails in last 432
master runs.
{color:#d04437}PDS (Indexing){color} [[tests 75 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=3251299]]
* IgnitePdsWithIndexingTestSuite:
IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes - 3,0% fails in last 437
master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGroupIndexes
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testRandomPutGetRemove
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGroupIndexes2
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRandomUniqueMultipleObjects
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testGradualRandomPutAllRemoveAll
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRandomNonUniqueMultipleObjects
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgnitePdsSingleNodeWithIndexingAndGroupPutGetPersistenceSelfTest.testPutGetRemoveMultipleForward
- 0,2% fails in last 437 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testPutGetRemoveMultipleBackward - 0,2%
fails in last 438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testRandomPut - 0,2% fails in last 438
master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testPutPrimaryUniqueSecondaryDuplicates
- 0,2% fails in last 438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testPutGetMultipleObjects - 0,2% fails
in last 438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testPutGetSimple - 0,2% fails in last
438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testOverwriteNormalSizeAfterSmallerSize
- 0,2% fails in last 438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testPutDoesNotTriggerRead - 0,2% fails
in last 438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testRandomRemove - 0,2% fails in last
438 master runs.
* IgnitePdsWithIndexingTestSuite:
IgniteDbMultiNodeWithIndexingPutGetTest.testSizeClear - 0,2% fails in last 438
master runs.
* IgnitePdsWithIndexingTestSuite:
[jira] [Updated] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11494: --- Labels: usability (was: ) > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11495) document IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE parameter
Evgenii Zhuravlev created IGNITE-11495: -- Summary: document IGNITE_SQL_MERGE_TABLE_PREFETCH_SIZE parameter Key: IGNITE-11495 URL: https://issues.apache.org/jira/browse/IGNITE-11495 Project: Ignite Issue Type: Improvement Components: documentation, sql Affects Versions: 2.7 Reporter: Evgenii Zhuravlev Assignee: Artem Budnikov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[ https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev updated IGNITE-11494: --- Affects Version/s: 2.7 > Change message log message in case of too small > IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter > - > > Key: IGNITE-11494 > URL: https://issues.apache.org/jira/browse/IGNITE-11494 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Evgenii Zhuravlev >Priority: Major > Labels: usability > > Message "Fetched result set was too large." should be changed to some > recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
Evgenii Zhuravlev created IGNITE-11494: -- Summary: Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter Key: IGNITE-11494 URL: https://issues.apache.org/jira/browse/IGNITE-11494 Project: Ignite Issue Type: Improvement Components: sql Reporter: Evgenii Zhuravlev Message "Fetched result set was too large." should be changed to some recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11487) Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
[ https://issues.apache.org/jira/browse/IGNITE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786150#comment-16786150 ] Denis Magda commented on IGNITE-11487: -- [~ezhuravl], [~vozerov], please share more details explaining how to document this parameter the best way. [~Artem Budnikov], could you please take over? This should be a short paragraph here: https://apacheignite-sql.readme.io/docs/performance-and-debugging > Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property > - > > Key: IGNITE-11487 > URL: https://issues.apache.org/jira/browse/IGNITE-11487 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11487) Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
[ https://issues.apache.org/jira/browse/IGNITE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-11487: - Priority: Critical (was: Major) > Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property > - > > Key: IGNITE-11487 > URL: https://issues.apache.org/jira/browse/IGNITE-11487 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11487) Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
[ https://issues.apache.org/jira/browse/IGNITE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-11487: Assignee: Artem Budnikov (was: Prachi Garg) > Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property > - > > Key: IGNITE-11487 > URL: https://issues.apache.org/jira/browse/IGNITE-11487 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7935) Add batch update operation to PageMemory and Persistence
[ https://issues.apache.org/jira/browse/IGNITE-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-7935: - Labels: iep-16 iep-32 (was: iep-16) > Add batch update operation to PageMemory and Persistence > > > Key: IGNITE-7935 > URL: https://issues.apache.org/jira/browse/IGNITE-7935 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Ilya Lantukh >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-16, iep-32 > > Updating each key-value pair independently is very inefficient when data > arrives in batches (examples: cache.putAll(...), dataStreamer, preloading). > Our internal data structures (B+ tree, FreeList) can be used more efficiently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10561) MVCC: Fix MVCC cache rebalance.
[
https://issues.apache.org/jira/browse/IGNITE-10561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785797#comment-16785797
]
Roman Kondakov commented on IGNITE-10561:
-
[~amashenkov], patch looks good for me.
> MVCC: Fix MVCC cache rebalance.
> ---
>
> Key: IGNITE-10561
> URL: https://issues.apache.org/jira/browse/IGNITE-10561
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unexpected transaction state may be observed on some nodes after rebalance.
> Reproducer: {{GridCacheRebalancingSyncSelfTest#testComplexRebalancing}}
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=149236, crdVer=1544033736224,
> cntr=800063, opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:931)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:251)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:213)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.testComplexRebalancing(GridCacheRebalancingSyncSelfTest.java:588)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccSnapshotSearchRow [res=null, snapshot=MvccSnapshotResponse
> [futId=149236, crdVer=1544033736224, cntr=800063, opCntr=1073741823,
> txs=null, cleanupVer=0, tracking=0]], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1035)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2849)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:695)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2024)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:933)
> at
>
[jira] [Updated] (IGNITE-11441) ignite-sys-cache present in SQL schemas
[ https://issues.apache.org/jira/browse/IGNITE-11441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11441: -- Ignite Flags: (was: Docs Required) > ignite-sys-cache present in SQL schemas > --- > > Key: IGNITE-11441 > URL: https://issues.apache.org/jira/browse/IGNITE-11441 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Investigate why ignite-sys-cache (and possible other caches without > configured QueryEntity) are displayed in schemas. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11152) IgniteTxManager.idMap possible memory leak
[
https://issues.apache.org/jira/browse/IGNITE-11152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785772#comment-16785772
]
Roman Kondakov commented on IGNITE-11152:
-
[~amashenkov], {{IgniteTxHeuristicCheckedException}} is thrown on Dht and
Remote nodes after the near transaction is already committed, so there is no
need to cleanup tx manager after this exception.
{{IgniteInterruptedCheckedException}} is thrown when tx is waiting on {{get()}}
method of {{NearEnlistFuture}} or chained {{PostLock}} future. So if this
waiting is interrupted, anyway we have a finish future which will cleanup tx
manager on it's finish.
> IgniteTxManager.idMap possible memory leak
> --
>
> Key: IGNITE-11152
> URL: https://issues.apache.org/jira/browse/IGNITE-11152
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Stepachev Maksim
>Assignee: Roman Kondakov
>Priority: Major
> Labels: memory-leak, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> CacheContinuousQueryAsyncFailoverMvccTxSelfTest.testMultiThreadedFailover
> sometimes finished with OMM.
> Heapdump analyze showed that leak happened in IgniteTxManager.idMap, this map
> contains *2_097_152* instances of GridNearTxLocal with *ACTIVE state* and
> *without* finishFut *and prepFut.*
>
> {code:java}
> while (!updated) {
> try {
> prevVal = (Integer)qryClnCache.getAndPut(key, val);
> updated = true;
> }
> catch (CacheException e) {
> assertSame(atomicityMode(), CacheAtomicityMode.TRANSACTIONAL_SNAPSHOT);
> }
> }
> {code}
>
>
> Possible the CacheException is common and may hide wrong cases. Change it at
> specific (ignite-10976).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11215) MVCC: JVM crash in MVCC PDS 1 suite
[
https://issues.apache.org/jira/browse/IGNITE-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785744#comment-16785744
]
Andrew Mashenkov commented on IGNITE-11215:
---
Seems, Vacuum should run cleanup() method inside busyLock section to prevent a
race b\w cache stop\destroy.
I've made a PR and trigger mass test on TC.
> MVCC: JVM crash in MVCC PDS 1 suite
> ---
>
> Key: IGNITE-11215
> URL: https://issues.apache.org/jira/browse/IGNITE-11215
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: mvcc_stabilization_stage_1
> Attachments: hs_err_pid429215.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes JVM crash
> [occurs|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeHistoryList=failed]
> in {{vacuum-cleaner}} thread in {{ExplicitWalDeltaConsistencyTest}}.
> See attached crash report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11431) SQL: Create a view with list of existing SCHEMAS
[
https://issues.apache.org/jira/browse/IGNITE-11431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785743#comment-16785743
]
Yury Gerzhedovich commented on IGNITE-11431:
[~vozerov], Vladimir in case ticket IGNITE-11441 will be merged earlier then
this ticket, need to remerge with master and fix some test related to check set
of available schemas. So please don't merge it if IGNITE-11441 merged and don't
have new BOT vise.
> SQL: Create a view with list of existing SCHEMAS
>
>
> Key: IGNITE-11431
> URL: https://issues.apache.org/jira/browse/IGNITE-11431
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to create a system view of currently available SQL schemas.
> Minimal required information is Schema name
> May be considered the follow info:
> 1) flag system or user schema
> 2) number of usages a schema.
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11428) Schemas don't show in Dbeaver
[ https://issues.apache.org/jira/browse/IGNITE-11428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785741#comment-16785741 ] Yury Gerzhedovich commented on IGNITE-11428: [~vozerov], Vladimir in case ticket IGNITE-11441 will be merged earlier then this ticket, need to remerge with master and fix some test related to check set of available schemas. So please don't merge it if IGNITE-11441 merged and don't have new BOT vise. > Schemas don't show in Dbeaver > - > > Key: IGNITE-11428 > URL: https://issues.apache.org/jira/browse/IGNITE-11428 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > At Database navigator tab we can see just single schema PUBLIC. Need to add > to jdbc driver support show all schemas except INFORMATIONAL, due to it H2 > schema and contains incorrect information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11258) JDBC Thin: update connection setup logic.
[
https://issues.apache.org/jira/browse/IGNITE-11258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785726#comment-16785726
]
Ignite TC Bot commented on IGNITE-11258:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3247861buildTypeId=IgniteTests24Java8_RunAll]
> JDBC Thin: update connection setup logic.
> -
>
> Key: IGNITE-11258
> URL: https://issues.apache.org/jira/browse/IGNITE-11258
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-23
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> # On thin client startup it connects to *all* *nodes* provided by user by
> client configuration.
> # Upon handshake server returns its UUID to client.
> # By the end of the startup procedure, client have open connections to all
> available server nodes and the following mapping (*nodeMap*): [UUID =>
> Connection].
> Connection to all nodes helps to identify available nodes, but can lead to
> significant delay, when thin client is used on a large cluster with a long IP
> list provided by user. To lower this delay, asynchronous establishment of
> connections can be used.
> For more information see [IEP-23: Best Effort
> Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11340) SQL: Add OOME tests to separate suite
[
https://issues.apache.org/jira/browse/IGNITE-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785733#comment-16785733
]
Taras Ledkov commented on IGNITE-11340:
---
[~vozerov], I tune the test setup:
- don't use data streamer on loading;
- reduce KEYS count;
- decrease remote nodes heap size.
Tests are OK.
Please take a look.
> SQL: Add OOME tests to separate suite
> -
>
> Key: IGNITE-11340
> URL: https://issues.apache.org/jira/browse/IGNITE-11340
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{IgniteQueryOOMTestSuite}} was added as a part of IGNITE-9171. We need to
> add this suite to TC and make sure it is executed on regular basis.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11215) MVCC: JVM crash in MVCC PDS 1 suite
[
https://issues.apache.org/jira/browse/IGNITE-11215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-11215:
-
Assignee: Andrew Mashenkov
> MVCC: JVM crash in MVCC PDS 1 suite
> ---
>
> Key: IGNITE-11215
> URL: https://issues.apache.org/jira/browse/IGNITE-11215
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: mvcc_stabilization_stage_1
> Attachments: hs_err_pid429215.log
>
>
> Sometimes JVM crash
> [occurs|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_MvccPds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeHistoryList=failed]
> in {{vacuum-cleaner}} thread in {{ExplicitWalDeltaConsistencyTest}}.
> See attached crash report.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11492) Add cluster activation to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785707#comment-16785707 ] Ilya Kasnacheev commented on IGNITE-11492: -- I've amended ticket description. > Add cluster activation to FailureHandler > > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > -New event EVT_CLUSTER_ACTIVATION_FAILED should be added. > The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced.- > Let's add handling of non-critical events to FailureHandler, one of which is > failed cluster activation, meaning that PME happened successfully and caches > started but some auxiliary processing like services threw exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11492) Add cluster activation to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11492: - Description: -New event EVT_CLUSTER_ACTIVATION_FAILED should be added. The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced.- Let's add handling of non-critical events to FailureHandler, one of which is failed cluster activation, meaning that PME happened successfully and caches started but some auxiliary processing like services threw exception. was: New event EVT_CLUSTER_ACTIVATION_FAILED should be added. The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced. > Add cluster activation to FailureHandler > > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > -New event EVT_CLUSTER_ACTIVATION_FAILED should be added. > The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced.- > Let's add handling of non-critical events to FailureHandler, one of which is > failed cluster activation, meaning that PME happened successfully and caches > started but some auxiliary processing like services threw exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11492) Add cluster activation to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11492: - Description: -New event EVT_CLUSTER_ACTIVATION_FAILED should be added.- -The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced.- Let's add handling of non-critical events to FailureHandler, one of which is failed cluster activation, meaning that PME happened successfully and caches started but some auxiliary processing like services threw exception. was: -New event EVT_CLUSTER_ACTIVATION_FAILED should be added. The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced.- Let's add handling of non-critical events to FailureHandler, one of which is failed cluster activation, meaning that PME happened successfully and caches started but some auxiliary processing like services threw exception. > Add cluster activation to FailureHandler > > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > -New event EVT_CLUSTER_ACTIVATION_FAILED should be added.- > -The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced.- > Let's add handling of non-critical events to FailureHandler, one of which is > failed cluster activation, meaning that PME happened successfully and caches > started but some auxiliary processing like services threw exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11492) Add cluster activation to FailureHandler
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11492: - Summary: Add cluster activation to FailureHandler (was: Add cluster activation failed event) > Add cluster activation to FailureHandler > > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > New event EVT_CLUSTER_ACTIVATION_FAILED should be added. > The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10669) NPE in freelist.PagesList.findTailIndex
[
https://issues.apache.org/jira/browse/IGNITE-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785697#comment-16785697
]
Ignite TC Bot commented on IGNITE-10669:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3205418buildTypeId=IgniteTests24Java8_RunAll]
> NPE in freelist.PagesList.findTailIndex
> ---
>
> Key: IGNITE-10669
> URL: https://issues.apache.org/jira/browse/IGNITE-10669
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.7
> Environment: Windows
>Reporter: ARomantsov
>Assignee: Pavel Kovalenko
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Run node with 1 cache and put to it.
> Kill node and try run back - it broken on start
> {code:java}
> [22:40:10,916][INFO][main][GridCacheDatabaseSharedManager] Applying lost
> cache updates since last checkpoint record [lastMarked=FileWALPointer [idx=2,
> fileOff=14706, len=21409],
> lastCheckpointId=2f9202e9-c9d7-47ca-9dcc-299a959bb2e0]
> [22:40:10,922][SEVERE][main][IgniteKernal] Exception during start processors,
> node will be stopped and close connections
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.findTailIndex(PagesList.java:502)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.updateTail(PagesList.java:458)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.mergeNoNext(PagesList.java:1330)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.removeDataPage(PagesList.java:1281)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:305)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList$RemoveRowHandler.run(AbstractFreeList.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:279)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:256)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.removeDataRowByLink(AbstractFreeList.java:571)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetastorageRowStore.removeRow(MetastorageRowStore.java:57)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.putData(MetaStorage.java:253)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.applyUpdate(MetaStorage.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLogicalUpdates(GridCacheDatabaseSharedManager.java:2420)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.startMemoryRestore(GridCacheDatabaseSharedManager.java:1909)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1056)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1076)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:962)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:861)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:731)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:700)
> at org.apache.ignite.Ignition.start(Ignition.java:348)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:301)
> [22:40:10,922][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.findTailIndex(PagesList.java:502)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.updateTail(PagesList.java:458)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.mergeNoNext(PagesList.java:1330)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.removeDataPage(PagesList.java:1281)
> at
>
[jira] [Updated] (IGNITE-11451) SQL system view for IO indexes statistics
[ https://issues.apache.org/jira/browse/IGNITE-11451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-11451: --- Summary: SQL system view for IO indexes statistics (was: SQL system view for IO indexes statisitcs) > SQL system view for IO indexes statistics > - > > Key: IGNITE-11451 > URL: https://issues.apache.org/jira/browse/IGNITE-11451 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: iep-29 > Fix For: 1.8 > > > Need to expose system SQL views to be able view IO statistics for SQL indexes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11493) Test CheckpointFreeListTest#testFreeListRestoredCorrectly always fails in DiskCompression suite
Sergey Chugunov created IGNITE-11493:
Summary: Test CheckpointFreeListTest#testFreeListRestoredCorrectly
always fails in DiskCompression suite
Key: IGNITE-11493
URL: https://issues.apache.org/jira/browse/IGNITE-11493
Project: Ignite
Issue Type: Bug
Reporter: Sergey Chugunov
Test fails with the following NullPointerException in logs:
{code}
[2019-03-06
16:05:24,353][ERROR][exchange-worker-#94%client%][IgniteTestResources] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteCheckedException: null]]
class org.apache.ignite.IgniteCheckedException: null
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7323)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2948)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2769)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.CacheCompressionManager.start0(CacheCompressionManager.java:55)
at
org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.initCacheContext(GridCacheProcessor.java:2534)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2344)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2270)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:2141)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$5(GridCacheProcessor.java:2094)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:2138)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:2093)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:2039)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:951)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:810)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2920)
... 3 more
{code}
Root cause of it is that CacheManager when initializing CacheContext on client
tries to start GridCompressionManager which doesn't make sense on client node.
We should either exclude compression manager from cache context on client or
not start it during initialization phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785638#comment-16785638
]
Taras Ledkov edited comment on IGNITE-11434 at 3/6/19 1:40 PM:
---
[~vozerov], [~jooger] I'm OK with the field
{{PRIMARY_KEY: boolean}}
What do you think about display any information about exists index(es) for a
column?
Field: {{INDEXED: boolean}} - *true* when the column is used at an index (or
used as the first column at an index)?
I guess we have to add filed
{{SQL_TYPE : short}} to simplify the JDBC columns metadata generation and use
this view to generate JDBC metadata,.
was (Author: tledkov-gridgain):
[~vozerov], [~jooger] I'm OK with the field
{{PRIMARY_KEY: boolean}}
What do you think about display any information about exists index(es) for a
column?
Field: {{INDEXED: boolean}} - *true* when the column is used at an index (or
used as the first column at an index)?
I guess we have to add filed
{{SQL_TYPE : short }} to simplify the JDBC columns metadata generation and use
this view to generate JDBC metadata,.
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785638#comment-16785638
]
Taras Ledkov commented on IGNITE-11434:
---
[~vozerov], [~jooger] I'm OK with the field
{{PRIMARY_KEY: boolean}}
What do you think about display any information about exists index(es) for a
column?
Field: {{INDEXED: boolean}} - *true* when the column is used at an index (or
used as the first column at an index)?
I guess we have to add filed
{{SQL_TYPE : short }} to simplify the JDBC columns metadata generation and use
this view to generate JDBC metadata,.
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785626#comment-16785626
]
Vladimir Ozerov commented on IGNITE-11434:
--
[~tledkov-gridgain], [~jooger], I am not sure we should expose {{DISPLAY_SIZE}}
at the moment.
Could you please clarify the meaning of {{COLUMN_KEY}}? Why can't it be just
{{PRIMARY_KEY: boolean}}?
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2
[
https://issues.apache.org/jira/browse/IGNITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785599#comment-16785599
]
Taras Ledkov commented on IGNITE-5250:
--
[~vozerov],
1. Thanks for comment. I move the check into
{{UpdatePlanBuilder#verifyDmlColumns}}
Bulk update is available only from JDBC driver that supports only SQL primitive
types and doesn't support composite java object.
2. Fixed.
> Unhelpful exception when value of wrong type is passed to H2
>
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key,
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL
> query.
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
> ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY
> VARCHAR=(?4,)) [90003-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at org.h2.table.Column.convert(Column.java:167)
>
[jira] [Commented] (IGNITE-11492) Add cluster activation failed event
[ https://issues.apache.org/jira/browse/IGNITE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785609#comment-16785609 ] Igor Belyakov commented on IGNITE-11492: Implementation details should be discussed with [~agoncharuk] and [~ilyak]. > Add cluster activation failed event > --- > > Key: IGNITE-11492 > URL: https://issues.apache.org/jira/browse/IGNITE-11492 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Belyakov >Priority: Major > Fix For: 2.8 > > > New event EVT_CLUSTER_ACTIVATION_FAILED should be added. > The fail event should contain information about the cause of the failure. If > needed, a new class for this event should be introduced. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11492) Add cluster activation failed event
Igor Belyakov created IGNITE-11492: -- Summary: Add cluster activation failed event Key: IGNITE-11492 URL: https://issues.apache.org/jira/browse/IGNITE-11492 Project: Ignite Issue Type: Improvement Reporter: Igor Belyakov Fix For: 2.8 New event EVT_CLUSTER_ACTIVATION_FAILED should be added. The fail event should contain information about the cause of the failure. If needed, a new class for this event should be introduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11464) Support Automatic modules for ignite-indexing: bypass or fix Lucene, fix queries and visor package conflicts
[
https://issues.apache.org/jira/browse/IGNITE-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785600#comment-16785600
]
Ignite TC Bot commented on IGNITE-11464:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}_Licenses Headers_{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3248952]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3232869buildTypeId=IgniteTests24Java8_RunAll]
> Support Automatic modules for ignite-indexing: bypass or fix Lucene, fix
> queries and visor package conflicts
>
>
> Key: IGNITE-11464
> URL: https://issues.apache.org/jira/browse/IGNITE-11464
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: the unnamed module reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: the unnamed module reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
>
> C:\projects\incubator-ignite\modules\dev-utils\ignite-modules-test\src\test\java\module-info.java:18:
> error: module ignite_modules_test reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> module ignite_modules_test
> {noformat}
>
> Some of these errors probably can be fixed by workarounds for dependencies:
> 2 errors coming from duplicate packages declared in code and indexing:
> - error: module ignite.core reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> - error: module ignite.core reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5250) Unhelpful exception when value of wrong type is passed to H2
[
https://issues.apache.org/jira/browse/IGNITE-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785592#comment-16785592
]
Ignite TC Bot commented on IGNITE-5250:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3240387buildTypeId=IgniteTests24Java8_RunAll]
> Unhelpful exception when value of wrong type is passed to H2
>
>
> Key: IGNITE-5250
> URL: https://issues.apache.org/jira/browse/IGNITE-5250
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Attachments: ExampleNodeStartup.java
>
>
> For instance, if an SQL schema defined this way:
> {code}
> cfg.setIndexedTypes(AffinityKey.class, Person.class);
> {code}
> and then, by some reason, the users confuses the type of the key passing
> {{int}} instead of {{AffinityKey}}
> {code}
> SqlFieldsQuery query = new SqlFieldsQuery("INSERT INTO Person (_key,
> id, name, country ) " +
> "VALUES ( ? , ? , ? , ?)");
> // Setting the key of a wrong type (AffinityKey instance must be used
> instead).
> query.setArgs(100, 1000, "John", "Canada");
> // Getting not user friendly exception.
> cache.query(query).getAll();
> {code}
> he will get an exception that doesn't point out to the exact root cause:
> {noformat}
> Caused by: class org.apache.ignite.IgniteException: Failed to execute SQL
> query.
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:365)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.doInsert(DmlStatementsProcessor.java:836)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:378)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:173)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsTwoStep(DmlStatementsProcessor.java:207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1657)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1701)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1699)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2129)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1706)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:783)
> ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to execute
> SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1224)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1276)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.access$1300(IgniteH2Indexing.java:239)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1079)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$4.iterator(IgniteH2Indexing.java:1067)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor$3.iterator(DmlStatementsProcessor.java:362)
> ... 18 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "100"; SQL statement:
> SELECT
> TABLE._KEY,
> TABLE.ID,
> TABLE.NAME,
> TABLE.COUNTRY
> FROM TABLE(_KEY OTHER=(?1,), ID BIGINT=(?2,), NAME VARCHAR=(?3,), COUNTRY
> VARCHAR=(?4,)) [90003-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at org.h2.table.Column.convert(Column.java:167)
[jira] [Updated] (IGNITE-10674) Remove MARSH_CLASS_NAME=BinaryMarshaller from tests
[ https://issues.apache.org/jira/browse/IGNITE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10674: Fix Version/s: 2.8 > Remove MARSH_CLASS_NAME=BinaryMarshaller from tests > --- > > Key: IGNITE-10674 > URL: https://issues.apache.org/jira/browse/IGNITE-10674 > Project: Ignite > Issue Type: Test > Components: binary >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: test > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We have quite a few tests which set MARSH_CLASS_NAME to BinaryMarshaller. > It is pointless because BinaryMarshaller seems to be default. > Hibernate suites even have "Binary" suites which are never ran and which sole > difference is that they set this property. > We should probably remove such code from tests and tests/suites which are not > needed anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10674) Remove MARSH_CLASS_NAME=BinaryMarshaller from tests
[ https://issues.apache.org/jira/browse/IGNITE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785590#comment-16785590 ] Dmitriy Pavlov commented on IGNITE-10674: - [~ilyak], LGTM, thank you for finalizing this change! > Remove MARSH_CLASS_NAME=BinaryMarshaller from tests > --- > > Key: IGNITE-10674 > URL: https://issues.apache.org/jira/browse/IGNITE-10674 > Project: Ignite > Issue Type: Test > Components: binary >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > We have quite a few tests which set MARSH_CLASS_NAME to BinaryMarshaller. > It is pointless because BinaryMarshaller seems to be default. > Hibernate suites even have "Binary" suites which are never ran and which sole > difference is that they set this property. > We should probably remove such code from tests and tests/suites which are not > needed anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10161) Be able to cancel any query by query id
[
https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785584#comment-16785584
]
Yury Gerzhedovich commented on IGNITE-10161:
[~vozerov], after discussing and clarify all questions I've prepared new path.
Could you please check it again.
Results:
2) Keep it as is.
6) Created separate task to merge all listeners for the TOPIC
7) Rewrite logic
9) Add realization onDisconnected method, howere don;t change anything else,
due to we already have exception in case node is unavailable.
> Be able to cancel any query by query id
> ---
>
> Key: IGNITE-10161
> URL: https://issues.apache.org/jira/browse/IGNITE-10161
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY \{ASYNC} '<_query_id>'_*
> _ASYNC_ is optional parameter which return control immediately without
> waiting real cancellation will be done.
> By default, without ASYNC parameter, the request is blocking untill
> cancellation is not done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10161) Be able to cancel any query by query id
[
https://issues.apache.org/jira/browse/IGNITE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785584#comment-16785584
]
Yury Gerzhedovich edited comment on IGNITE-10161 at 3/6/19 12:40 PM:
-
[~vozerov], after discussing and clarify all questions I've prepared new path.
Could you please check it again.
Results:
2) Keep it as is.
6) Created separate task to merge all listeners for the TOPIC
7) Rewrite logic
9) Add realization onDisconnected method, howere don;t change anything else,
due to we already have exception in case node is unavailable.
Waiting a BOT vise.
was (Author: jooger):
[~vozerov], after discussing and clarify all questions I've prepared new path.
Could you please check it again.
Results:
2) Keep it as is.
6) Created separate task to merge all listeners for the TOPIC
7) Rewrite logic
9) Add realization onDisconnected method, howere don;t change anything else,
due to we already have exception in case node is unavailable.
> Be able to cancel any query by query id
> ---
>
> Key: IGNITE-10161
> URL: https://issues.apache.org/jira/browse/IGNITE-10161
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> User should be able to cancel any query by query id through SQL command.
> SQL syntax: *KILL QUERY \{ASYNC} '<_query_id>'_*
> _ASYNC_ is optional parameter which return control immediately without
> waiting real cancellation will be done.
> By default, without ASYNC parameter, the request is blocking untill
> cancellation is not done.
> Query should be canceled together with its parts on all nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10674) Remove MARSH_CLASS_NAME=BinaryMarshaller from tests
[ https://issues.apache.org/jira/browse/IGNITE-10674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785577#comment-16785577 ] Ilya Kasnacheev commented on IGNITE-10674: -- [~dpavlov] please review proposed change. > Remove MARSH_CLASS_NAME=BinaryMarshaller from tests > --- > > Key: IGNITE-10674 > URL: https://issues.apache.org/jira/browse/IGNITE-10674 > Project: Ignite > Issue Type: Test > Components: binary >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > We have quite a few tests which set MARSH_CLASS_NAME to BinaryMarshaller. > It is pointless because BinaryMarshaller seems to be default. > Hibernate suites even have "Binary" suites which are never ran and which sole > difference is that they set this property. > We should probably remove such code from tests and tests/suites which are not > needed anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11491) [TC Bot] Adapt TC bot to AI CI git proxy: Build may be started without freshest changes
Dmitriy Pavlov created IGNITE-11491: --- Summary: [TC Bot] Adapt TC bot to AI CI git proxy: Build may be started without freshest changes Key: IGNITE-11491 URL: https://issues.apache.org/jira/browse/IGNITE-11491 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov If Ignite developer - pushes new fixes into the branch and - quite fast activates build or rebuild of changes from that branch, the last commit may be invisible by TeamCity because of git proxy sync lag. This lag ~ 1 minute. It is necessary to research opportunities to check if a triggered build is fresh or not, display it in the Bot or/and (better) warn a user if TC does not see required commit yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11465) Multiple client leave/join events may wipe affinity assignment history and cause transactions fail
[
https://issues.apache.org/jira/browse/IGNITE-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785570#comment-16785570
]
Ivan Rakov commented on IGNITE-11465:
-
[~antonovsergey93], [~ascherbakov], please take a look again.
> Multiple client leave/join events may wipe affinity assignment history and
> cause transactions fail
> --
>
> Key: IGNITE-11465
> URL: https://issues.apache.org/jira/browse/IGNITE-11465
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
> assignments. However, flood of client joins/leaves may wipe it out entirely
> and cause fail/hang of transaction that was started before the flood due to
> the following exception:
> {code:java}
> if (cache == null || cache.topologyVersion().compareTo(topVer) >
> 0) {
> throw new IllegalStateException("Getting affinity for
> topology version earlier than affinity is " +
> "calculated [locNode=" + ctx.discovery().localNode() +
> ", grp=" + cacheOrGrpName +
> ", topVer=" + topVer +
> ", head=" + head.get().topologyVersion() +
> ", history=" + affCache.keySet() +
> ']');
> }
> {code}
> History is limited in order to prevent JVM heap overflow. At the same time,
> only "server event" affinity assignments are heavy: "client event"
> assignments are just shallow copies of "server event" assignments.
> I suggest to limit history by the number of "server event" assignments.
> Also, considering the provided fix, I don't see any need to keep 500 items in
> history. I propose to change history size to 50.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11465) Multiple client leave/join events may wipe affinity assignment history and cause transactions fail
[
https://issues.apache.org/jira/browse/IGNITE-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785568#comment-16785568
]
Ignite TC Bot commented on IGNITE-11465:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3247621buildTypeId=IgniteTests24Java8_RunAll]
> Multiple client leave/join events may wipe affinity assignment history and
> cause transactions fail
> --
>
> Key: IGNITE-11465
> URL: https://issues.apache.org/jira/browse/IGNITE-11465
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
> assignments. However, flood of client joins/leaves may wipe it out entirely
> and cause fail/hang of transaction that was started before the flood due to
> the following exception:
> {code:java}
> if (cache == null || cache.topologyVersion().compareTo(topVer) >
> 0) {
> throw new IllegalStateException("Getting affinity for
> topology version earlier than affinity is " +
> "calculated [locNode=" + ctx.discovery().localNode() +
> ", grp=" + cacheOrGrpName +
> ", topVer=" + topVer +
> ", head=" + head.get().topologyVersion() +
> ", history=" + affCache.keySet() +
> ']');
> }
> {code}
> History is limited in order to prevent JVM heap overflow. At the same time,
> only "server event" affinity assignments are heavy: "client event"
> assignments are just shallow copies of "server event" assignments.
> I suggest to limit history by the number of "server event" assignments.
> Also, considering the provided fix, I don't see any need to keep 500 items in
> history. I propose to change history size to 50.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785559#comment-16785559
]
Ignite TC Bot commented on IGNITE-10414:
{panel:title=- Run :: SQL: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *- Run :: SQL*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3248310buildTypeId=IgniteTests24Java8_RunAllSql]
> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
>
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
> Error:
> {code:java}
> (err) DDL operation failureSchemaOperationException [code=3, msg=Table
> already exists: CITY]
> at
> org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Exception in thread "main" javax.cache.CacheException: Table already exists:
> CITY
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Table already
> exists: CITY
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
>
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785552#comment-16785552
]
Taras Ledkov commented on IGNITE-11434:
---
[~jooger], you are right.
1. I guess we can use H2 {{Column.getColumnId() - DEFAULT_COLUMNS_COUNT}} for
column ordinal.
2. Looks like the {{COLUMN_KEY}} is strange for Ignite. We can replace is with
any useful information about a column and indexes relation.
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[ https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785544#comment-16785544 ] Yury Gerzhedovich edited comment on IGNITE-11434 at 3/6/19 11:57 AM: - [~tledkov-gridgain], It looks good for me, except absent ordinal_position column, which will be useful as reference to the column, e.g. for describe columns and their order for indexes, also I don't understand semantic for COLUMN KEY column was (Author: jooger): [~tledkov-gridgain], It looks good for me, except absent ordinal_position column, which will be useful as reference to the column, e.g. for describe columns and their order for indexes. > SQL: Create a view with list of existing COLUMNS > > > Key: IGNITE-11434 > URL: https://issues.apache.org/jira/browse/IGNITE-11434 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Need to expose SQL system view with COLUMNS information. > Need to investigate more deeper which of information should be there. > > As start point we can take > [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[ https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785544#comment-16785544 ] Yury Gerzhedovich commented on IGNITE-11434: [~tledkov-gridgain], It looks good for me, except absent ordinal_position column, which will be useful as reference to the column, e.g. for describe columns and their order for indexes. > SQL: Create a view with list of existing COLUMNS > > > Key: IGNITE-11434 > URL: https://issues.apache.org/jira/browse/IGNITE-11434 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Major > Labels: iep-29 > Time Spent: 10m > Remaining Estimate: 0h > > Need to expose SQL system view with COLUMNS information. > Need to investigate more deeper which of information should be there. > > As start point we can take > [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785534#comment-16785534
]
Taras Ledkov edited comment on IGNITE-11434 at 3/6/19 11:37 AM:
My proposal the set of columns for {{COLUMNS}} view:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_NAME | string | Columns name |
| DATA_TYPE | string | SQL data type |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| COLUMN_KEY | string | null / PK / MUL according with MySQL semantic |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
was (Author: tledkov-gridgain):
My proposal the set of columns of {{COLUMNS}} view:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_NAME | string | Columns name |
| DATA_TYPE | string | SQL data type |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| COLUMN_KEY | string | null / PK / MUL according with MySQL semantic |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785534#comment-16785534
]
Taras Ledkov commented on IGNITE-11434:
---
My proposal the set of columns of {{COLUMNS}} view:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_NAME | string | Columns name |
| DATA_TYPE | string | SQL data type |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| COLUMN_KEY | string | null / PK / MUL according with MySQL semantic |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11464) Support Automatic modules for ignite-indexing: bypass or fix Lucene, fix queries and visor package conflicts
[
https://issues.apache.org/jira/browse/IGNITE-11464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-11464:
Fix Version/s: 2.8
> Support Automatic modules for ignite-indexing: bypass or fix Lucene, fix
> queries and visor package conflicts
>
>
> Key: IGNITE-11464
> URL: https://issues.apache.org/jira/browse/IGNITE-11464
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> error: the unnamed module reads package org.apache.lucene.search from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.document from both
> lucene.sandbox and lucene.core
> error: the unnamed module reads package org.apache.lucene.analysis.standard
> from both lucene.core and lucene.analyzers.common
> error: the unnamed module reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> error: the unnamed module reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
>
> C:\projects\incubator-ignite\modules\dev-utils\ignite-modules-test\src\test\java\module-info.java:18:
> error: module ignite_modules_test reads package org.apache.lucene.search
> from both lucene.sandbox and lucene.core
> module ignite_modules_test
> {noformat}
>
> Some of these errors probably can be fixed by workarounds for dependencies:
> 2 errors coming from duplicate packages declared in code and indexing:
> - error: module ignite.core reads package
> org.apache.ignite.internal.processors.cache.query from both ignite.indexing
> and ignite.core
> - error: module ignite.core reads package
> org.apache.ignite.internal.visor.verify from both ignite.indexing and
> ignite.core
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11465) Multiple client leave/join events may wipe affinity assignment history and cause transactions fail
[
https://issues.apache.org/jira/browse/IGNITE-11465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785506#comment-16785506
]
Ignite TC Bot commented on IGNITE-11465:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3247569]]
* GridCacheStopSelfTest.testStopMultithreaded (last started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3247621buildTypeId=IgniteTests24Java8_RunAll]
> Multiple client leave/join events may wipe affinity assignment history and
> cause transactions fail
> --
>
> Key: IGNITE-11465
> URL: https://issues.apache.org/jira/browse/IGNITE-11465
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We keep history of GridAffinityAssignmentCache#MAX_HIST_SIZE affinity
> assignments. However, flood of client joins/leaves may wipe it out entirely
> and cause fail/hang of transaction that was started before the flood due to
> the following exception:
> {code:java}
> if (cache == null || cache.topologyVersion().compareTo(topVer) >
> 0) {
> throw new IllegalStateException("Getting affinity for
> topology version earlier than affinity is " +
> "calculated [locNode=" + ctx.discovery().localNode() +
> ", grp=" + cacheOrGrpName +
> ", topVer=" + topVer +
> ", head=" + head.get().topologyVersion() +
> ", history=" + affCache.keySet() +
> ']');
> }
> {code}
> History is limited in order to prevent JVM heap overflow. At the same time,
> only "server event" affinity assignments are heavy: "client event"
> assignments are just shallow copies of "server event" assignments.
> I suggest to limit history by the number of "server event" assignments.
> Also, considering the provided fix, I don't see any need to keep 500 items in
> history. I propose to change history size to 50.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Issue Type: Improvement (was: Bug) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Summary: Introduce a way to enable system data region metrics in configuration (was: DataStorageConfiguration.metricsEnabled flag is ignored) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime or in a specific `DataRegionConfiguration`. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Priority: Minor (was: Major) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Minor > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10414) IF NOT EXISTS in CREATE TABLE doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-10414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785482#comment-16785482
]
Pavel Kuznetsov commented on IGNITE-10414:
--
Merge with master introduced new test for Indexes system view which was broken
with this fix. I've fixed this test, scheduling RunAllSql to verify that.
> IF NOT EXISTS in CREATE TABLE doesn't work
> --
>
> Key: IGNITE-10414
> URL: https://issues.apache.org/jira/browse/IGNITE-10414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.4, 2.6, 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
>
> {code:java}
>Ignite ignite = Ignition.start();
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> ignite.getOrCreateCache("test").query(new SqlFieldsQuery("CREATE
> TABLE IF NOT EXISTS City(id LONG PRIMARY KEY,"
> + " name VARCHAR) WITH \"template=replicated\""));
> {code}
> Error:
> {code:java}
> (err) DDL operation failureSchemaOperationException [code=3, msg=Table
> already exists: CITY]
> at
> org.apache.ignite.internal.processors.query.QueryUtils.checkQueryEntityConflicts(QueryUtils.java:1214)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:351)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2677)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$0(GridQueryProcessor.java:2183)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2203)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2164)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2125)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:685)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Exception in thread "main" javax.cache.CacheException: Table already exists:
> CITY
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:636)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:388)
> at
> org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:40)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Table already
> exists: CITY
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:642)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:503)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1981)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1896)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2174)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2169)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
>
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Currently system data region metrics can be only enabled at runtime. It would be convenient to have a configuration property, that will enable metrics for system data region, just like for any other data region. was:Currently system data region metrics can be only enabled in runtime. > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled at runtime. > It would be convenient to have a configuration property, that will enable > metrics for system data region, just like for any other data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) Introduce a way to enable system data region metrics in configuration
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Currently system data region metrics can be only enabled in runtime. (was: Data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime or in a specific `DataRegionConfiguration`. Expected behaviour: `metricsEnabled` flag shouldn't be ignored.) > Introduce a way to enable system data region metrics in configuration > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Currently system data region metrics can be only enabled in runtime. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11490) DataStorageConfiguration.metricsEnabled flag is ignored
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Description: Data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime or in a specific `DataRegionConfiguration`. Expected behaviour: `metricsEnabled` flag shouldn't be ignored. was: System data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime. Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system data region. > DataStorageConfiguration.metricsEnabled flag is ignored > --- > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > Data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime or in a specific `DataRegionConfiguration`. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10250) Ignite Queue hangs after several read/write operations
[
https://issues.apache.org/jira/browse/IGNITE-10250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785484#comment-16785484
]
Alexey Goncharuk commented on IGNITE-10250:
---
[~xtern], [~sergey-chugunov] thanks, merged to master!
> Ignite Queue hangs after several read/write operations
> --
>
> Key: IGNITE-10250
> URL: https://issues.apache.org/jira/browse/IGNITE-10250
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.7
>Reporter: Anton Dmitriev
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.8
>
>
> Ignite Queue hangs after several read/write operations. Code to reproduce:
> {code:java}
> try (Ignite ignite = Ignition.start()) {
> IgniteQueue queue = ignite.queue("TEST_QUEUE", 1, new
> CollectionConfiguration());
> new Thread(() -> {
> for (int i = 0;; i++) {
> queue.put(i);
> System.out.println("Put: " + i);
> }
> }).start();
> new Thread(() -> {
> for (int i = 0;; i++) {
> queue.take();
> System.out.println("Take: " + i);
> }
> }).start();
> Thread.currentThread().join();
> }
> {code}
> *UPDATE AFTER REVIEW*
> [~xtern], thank you for investigating this issue, great job!
> Unfortunately this hang has a deeper roots and highlights another bug we have
> in continuous queries over atomic caches.
> Operations of modifying queue header (which results in invoking of CQ
> listener and subsequent call to onHeaderChange callback) are performed on a
> single key (*queueKey*, see *GridAtomicCacheQueueImpl*) so even if they are
> called from different threads they should remain serialized.
> But in case of atomic cache on single node CQ listeners are called
> synchronously from the same thread that is making operation on the queue and
> they are called outside of section where locks on GridCacheMapEntries objects
> are held (see method *GridDhtAtomicCache::updateAllAsyncInternal0* and stack
> trace below) which breaks guarantee of serialized invocation of listeners.
> So we need to fix this behavior of ATOMIC caches and the issue with queues
> will disappear without any changes in *onHeaderChanged* callback.
> Stack trace of the call looks like this:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheQueueAdapter.onHeaderChanged(GridCacheQueueAdapter.java:517)
> at
> org.apache.ignite.internal.processors.cache.datastructures.CacheDataStructuresManager$1.onUpdated(CacheDataStructuresManager.java:305)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyLocalListener(CacheContinuousQueryHandler.java:946)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:877)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$600(CacheContinuousQueryHandler.java:85)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:437)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$2$1.apply(CacheContinuousQueryHandler.java:432)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:560)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.onDone(GridDhtAtomicAbstractUpdateFuture.java:62)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:452)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:396)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1874)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
[jira] [Updated] (IGNITE-11490) DataStorageConfiguration.metricsEnabled flag is ignored
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Summary: DataStorageConfiguration.metricsEnabled flag is ignored (was: System data region metrics are disabled regardless of metricsEnabled flag) > DataStorageConfiguration.metricsEnabled flag is ignored > --- > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > System data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system > data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10663) Cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Description:
The main idea is to provide special "read from cache" mode which will read a
value from primary and all backups and will check that values are the same.
In case values differ they should be fixed according to the appropriate
strategy.
ToDo list:
1) {{cache.withConsistency().get(key)}} should guarantee values will be checked
across the topology and fixed if necessary.
2) LWW (Last Write Wins) strategy should be used for validation.
3) Since LWW and any other strategy do not guarantee that the correct value
will be chosen.
We have to record the event contains all values and the chosen one.
was:
The main idea is to provide special "read from cache" mode which will read a
value from primary and all backups and will check that values are the same.
In case values differ they should be fixed according to the appropriate
strategy.
{{cache.withConsistencyCheck().get(key)}} should guarantee values will be
checked across the topology and fixed if necessary.
LWW (Last Write Wins) strategy should be used for validation.
Since LWW and any other strategy do not guarantee that the correct value will
be chosen.
We have to record the event contains all values and the chosen one.
The event will allow to
- got we have an inconsistent state situation
- investigate which value is correct manually and refix if necessary
> Cache mode allows reads with consistency check and fix
> --
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10561) MVCC: Fix MVCC cache rebalance.
[
https://issues.apache.org/jira/browse/IGNITE-10561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785446#comment-16785446
]
Andrew Mashenkov commented on IGNITE-10561:
---
[~rkondakov],TC look ok.
Would you please review PR once again?
> MVCC: Fix MVCC cache rebalance.
> ---
>
> Key: IGNITE-10561
> URL: https://issues.apache.org/jira/browse/IGNITE-10561
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unexpected transaction state may be observed on some nodes after rebalance.
> Reproducer: {{GridCacheRebalancingSyncSelfTest#testComplexRebalancing}}
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=149236, crdVer=1544033736224,
> cntr=800063, opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:931)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:251)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:213)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.testComplexRebalancing(GridCacheRebalancingSyncSelfTest.java:588)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccSnapshotSearchRow [res=null, snapshot=MvccSnapshotResponse
> [futId=149236, crdVer=1544033736224, cntr=800063, opCntr=1073741823,
> txs=null, cleanupVer=0, tracking=0]], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1035)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2849)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:695)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2024)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:933)
> at
>
[jira] [Commented] (IGNITE-10561) MVCC: Fix MVCC cache rebalance.
[
https://issues.apache.org/jira/browse/IGNITE-10561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785442#comment-16785442
]
Ignite TC Bot commented on IGNITE-10561:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3243337buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Fix MVCC cache rebalance.
> ---
>
> Key: IGNITE-10561
> URL: https://issues.apache.org/jira/browse/IGNITE-10561
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Critical
> Labels: failover, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unexpected transaction state may be observed on some nodes after rebalance.
> Reproducer: {{GridCacheRebalancingSyncSelfTest#testComplexRebalancing}}
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on bounds: [lower=MvccSnapshotSearchRow [res=null,
> snapshot=MvccSnapshotResponse [futId=149236, crdVer=1544033736224,
> cntr=800063, opCntr=1073741823, txs=null, cleanupVer=0, tracking=0]],
> upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:931)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:640)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:251)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.checkData(GridCacheRebalancingSyncSelfTest.java:213)
> at
> org.apache.ignite.internal.processors.cache.distributed.rebalancing.GridCacheRebalancingSyncSelfTest.testComplexRebalancing(GridCacheRebalancingSyncSelfTest.java:588)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on
> bounds: [lower=MvccSnapshotSearchRow [res=null, snapshot=MvccSnapshotResponse
> [futId=149236, crdVer=1544033736224, cntr=800063, opCntr=1073741823,
> txs=null, cleanupVer=0, tracking=0]], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.iterate(BPlusTree.java:1035)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccFind(IgniteCacheOffheapManagerImpl.java:2849)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccRead(IgniteCacheOffheapManagerImpl.java:695)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:2024)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:807)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:399)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:277)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:259)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:182)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:918)
> at
>
[jira] [Updated] (IGNITE-11490) System data region metrics are disabled regardless of metricsEnabled flag
[ https://issues.apache.org/jira/browse/IGNITE-11490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov updated IGNITE-11490: -- Labels: metrics usability (was: ) > System data region metrics are disabled regardless of metricsEnabled flag > - > > Key: IGNITE-11490 > URL: https://issues.apache.org/jira/browse/IGNITE-11490 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Denis Mekhanikov >Priority: Major > Labels: metrics, usability > > System data region metrics are disabled regardless of value of > `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be > enabled explicitly at runtime. > Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system > data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11490) System data region metrics are disabled regardless of metricsEnabled flag
Denis Mekhanikov created IGNITE-11490: - Summary: System data region metrics are disabled regardless of metricsEnabled flag Key: IGNITE-11490 URL: https://issues.apache.org/jira/browse/IGNITE-11490 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Denis Mekhanikov System data region metrics are disabled regardless of value of `DataStorageConfiguration.metricsEnabled` flag. Memory metrics can only be enabled explicitly at runtime. Expected behaviour: `metricsEnabled` flag shouldn't be ignored for the system data region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11489) merge IO message listener for GridTopic.TOPIC_QUERY into single listener
Yury Gerzhedovich created IGNITE-11489: -- Summary: merge IO message listener for GridTopic.TOPIC_QUERY into single listener Key: IGNITE-11489 URL: https://issues.apache.org/jira/browse/IGNITE-11489 Project: Ignite Issue Type: Task Components: sql Reporter: Yury Gerzhedovich Fix For: 2.8 As of now we have few IO listeners for GridTopic.TOPIC_QUERY. It lead to spread of logic and we can't check that no any not expected messages received. Need to merge it to single listeners or have different topics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11391) Test on free list is freezes sometimes
[ https://issues.apache.org/jira/browse/IGNITE-11391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11391: -- Ignite Flags: (was: Docs Required) > Test on free list is freezes sometimes > -- > > Key: IGNITE-11391 > URL: https://issues.apache.org/jira/browse/IGNITE-11391 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > CheckpointFreeListTest#testRestoreFreeListCorrectlyAfterRandomStop - freezed > sometimes > CheckpointFreeListTest.testFreeListRestoredCorrectly - flaky -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11488) GridServiceProcessorBatchDeploySelfTest test fails sporadically
Andrew Mashenkov created IGNITE-11488:
-
Summary: GridServiceProcessorBatchDeploySelfTest test fails
sporadically
Key: IGNITE-11488
URL: https://issues.apache.org/jira/browse/IGNITE-11488
Project: Ignite
Issue Type: Test
Components: managed services
Reporter: Andrew Mashenkov
GridServiceProcessorBatchDeploySelfTest.testCancelAllTopologyChange test fails
on TC sporadically with ConcurrentModificationException.
Let's add synchronization to certain toString method.
{noformat}
[super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.IgniteException: null]]
class org.apache.ignite.IgniteException: null
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1081)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:993)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:703)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:662)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentTask.toString(ServiceDeploymentTask.java:854)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.service.ServiceDeploymentManager$ServicesDeploymentWorker.body(ServiceDeploymentManager.java:502)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
at java.util.HashMap$EntryIterator.next(HashMap.java:1476)
at java.util.HashMap$EntryIterator.next(HashMap.java:1474)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.addMap(GridToStringBuilder.java:923)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:846)
at
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl0(GridToStringBuilder.java:1065)
... 9 more{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11384) Introduce an ability of services hot redeployment via DeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-11384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785391#comment-16785391 ] Alexey Goncharuk commented on IGNITE-11384: --- Looks good to me. [~vozerov], do you have any comments? > Introduce an ability of services hot redeployment via DeploymentSpi > --- > > Key: IGNITE-11384 > URL: https://issues.apache.org/jira/browse/IGNITE-11384 > Project: Ignite > Issue Type: Sub-task > Components: managed services >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur >Priority: Major > Labels: iep-17 > Fix For: 2.8 > > > We can integrate service processor with DeploymentSpi to introduce an > opportunity of services hot redeployment. For this change, the service > processor should try to get and use registered classloader registered for the > service's class in DeploymentSpi. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
