[jira] [Updated] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6825:
Component/s: sql
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Blocker
> Fix For: 2.4
>
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
> at
> ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction$FindUnknownMapFunctionPred
[jira] [Assigned] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-6825:
---
Assignee: Vladimir Ozerov
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.4
>
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
> at
> ru.sbt.deposit_pf_api.comparato
[jira] [Updated] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6825:
Fix Version/s: 2.4
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Major
> Fix For: 2.4
>
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
> at
> ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction$FindUnknownMapFunctionPred
[jira] [Updated] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6825:
Priority: Major (was: Blocker)
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Major
> Fix For: 2.4
>
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
> at
> ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction$FindUnknownMa
[jira] [Commented] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237177#comment-16237177
]
Vladimir Ozerov commented on IGNITE-6825:
-
Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=928807
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Blocker
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
> at
> ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
> at
> ru.sbt.deposit_pf_api.comparators.
[jira] [Commented] (IGNITE-6825) Unhandled interruption in GridH2Table
[
https://issues.apache.org/jira/browse/IGNITE-6825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237175#comment-16237175
]
ASF GitHub Bot commented on IGNITE-6825:
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/2976
IGNITE-6825
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6825
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2976.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2976
commit f6399b46770a11beb0fb131bf0ce87162f052f1e
Author: devozerov
Date: 2017-11-03T06:45:44Z
IGNITE-6825: SQL: Fixed GridH2Table unlock in case of interrupt.
> Unhandled interruption in GridH2Table
> -
>
> Key: IGNITE-6825
> URL: https://issues.apache.org/jira/browse/IGNITE-6825
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Blocker
>
> In GridH2Table.lock(Ses, excl, force) method we:
> 1) put session in sessions table;
> 2) add lock in H2 session locks
> 3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
> lock.lockInterruptiblu() it got interruption - session with lock still alive
> in GridH2Table sessions map but no really lock acquired and when session will
> trying to unlock all acquired locks it will try to unlock it too and we get
> exception:
> {noformat}
> [ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to run map query on local node.
>
> org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
> at
> org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
> at
> com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
> at
> com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbst
[jira] [Created] (IGNITE-6825) Unhandled interruption in GridH2Table
Alexander Belyak created IGNITE-6825:
Summary: Unhandled interruption in GridH2Table
Key: IGNITE-6825
URL: https://issues.apache.org/jira/browse/IGNITE-6825
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Blocker
In GridH2Table.lock(Ses, excl, force) method we:
1) put session in sessions table;
2) add lock in H2 session locks
3) try to Lock(excl), but if in GridH2Table.lock(excl):277 while thread in
lock.lockInterruptiblu() it got interruption - session with lock still alive in
GridH2Table sessions map but no really lock acquired and when session will
trying to unlock all acquired locks it will try to unlock it too and we get
exception:
{noformat}
[ERROR][pub-#3855%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
Failed to run map query on local node.
org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:970)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1029)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1008)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:660)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:506)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:145)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:143)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2066)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1273)
at
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:733)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1214)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$9.iterator(IgniteH2Indexing.java:1256)
at
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at
com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.IgniteCacheQueryExecutor.iterator(IgniteCacheQueryExecutor.java:131)
at
com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:58)
at
com.sbt.dpl.gridgain.collection.dataselectors.executor.cachequery.impl.SqlQueryExecutor.iterator(SqlQueryExecutor.java:23)
at
com.sbt.dpl.gridgain.collection.dataselectors.impl.H2IndexesDataSelector.binaryIterator(H2IndexesDataSelector.java:142)
at
com.sbt.dpl.gridgain.collection.dataselectors.AbstractDataSelector.getIterator(AbstractDataSelector.java:110)
at
com.sbt.dpl.gridgain.collection.dataselectors.IndexesSwitchSelectDataSelector.getIterator(IndexesSwitchSelectDataSelector.java:106)
at
com.sbt.dpl.gridgain.collection.base.GGAbstractCollectionWithDataSelector.iterator(GGAbstractCollectionWithDataSelector.java:390)
at
ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:846)
at
ru.sbt.deposit_pf_api.comparators.EntityService.findDepositByProduct(EntityService.java:807)
at
ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObjectInner(EntityService.java:1350)
at
ru.sbt.deposit_pf_api.comparators.EntityService.getDepositByObject(EntityService.java:1169)
at
ru.sbt.deposit_pf_api.comparators.EntityService.getGroupingObject(EntityService.java:1098)
at
ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction$FindUnknownMapFunctionPredicate.apply(UnknownClassMapFunction.java:183)
at
ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction$FindUnknownMapFunctionPredicate.apply(UnknownClassMapFunction.java:1)
at ru.sbt.deposit_pf_api.CollectionUtils.filter(CollectionUtils.java:55)
at
ru.sbt.deposit_pf_api.comparators.UnknownClassMapFunction.map(UnknownClassMapFunction.java:91)
[jira] [Updated] (IGNITE-6248) Check Java 7 builds for compatibility with Ignite and update documentation
[ https://issues.apache.org/jira/browse/IGNITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Karachentsev updated IGNITE-6248: Fix Version/s: 2.4 > Check Java 7 builds for compatibility with Ignite and update documentation > -- > > Key: IGNITE-6248 > URL: https://issues.apache.org/jira/browse/IGNITE-6248 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Dmitry Karachentsev >Priority: Major > Labels: usability > Fix For: 2.4 > > > According to these threads on SO and user list, some old Java 7 versions > doesn't compatible with Ignite since version 2.1 anymore: > http://apache-ignite-users.70518.x6.nabble.com/Caused-by-org-h2-jdbc-JdbcSQLException-General-error-quot-java-lang-IllegalMonitorStateException-Attt-td15684.html > https://stackoverflow.com/questions/45911616/datastreamer-does-not-work-well/45972341#45972341 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237016#comment-16237016 ] Dmitriy Setrakyan commented on IGNITE-6679: --- We cannot throw exceptions from deprecated methods. They should work as expected. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6824) Web Console: migrate from angularjs 1.5 to angular 1.6
Alexander Kalinin created IGNITE-6824: - Summary: Web Console: migrate from angularjs 1.5 to angular 1.6 Key: IGNITE-6824 URL: https://issues.apache.org/jira/browse/IGNITE-6824 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: wizards Reporter: Alexander Kalinin Assignee: Alexander Kalinin Priority: Minor Fix For: 2.4 angularjs 1.5 version is legacy, let's migrate to last stable version 1.6 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237012#comment-16237012
]
Dmitriy Setrakyan commented on IGNITE-6814:
---
The OutOfMemoryException should look as following:
{code}
Out of memory in data region [name= region_name, initSize=N, maxSize=N,
persistenceEnabled={true|false}]. Try the following:
^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
^-- Enable eviction or expiration policies
{code}
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N,
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> or
>^-- Enable eviction or expiration policies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237006#comment-16237006
]
Dmitriy Setrakyan commented on IGNITE-6814:
---
Looks good. Let's change {{persistenceEnabled}} -> {{persistence}}
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N,
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> or
>^-- Enable eviction or expiration policies.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6814:
Description:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accumulate maximum size of all the data regions defined cluster-wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
heap=1.8GB, ]
{code}
* Print detailed memory configuration below {{Topology Snapshot}} message
following this format:
{code}
Data Regions Configured:
^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
{code}
Example:
{code}
Data Regions Configured:
^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
persistenceEnabled=false]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence.
{code}
Out of memory in data region Region_Name [initSize=N, maxSize=N,
persistenceEnabled={true|false}]. Do one of the following:
^-- Increase maximum size (DataRegionConfiguration.maxSize)
^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled) or
^-- Enable eviction or expiration policies.
{code}
was:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accumulate maximum size of all the data regions defined cluster-wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
heap=1.8GB, ]
{code}
* Print detailed memory configuration below {{Topology Snapshot}} message
following this format:
{code}
Data Regions Configured:
^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
{code}
Example:
{code}
Data Regions Configured:
^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
persistenceEnabled=false]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> {code}
> Out of memory in data region Region_Name [initSize=N, maxSize=N,
> persistenceEnabled={true|false}]. Do one of the following:
>^-- Increase maximum size (DataRegionConfiguration.maxSize)
>^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> or
>^-- Enable evic
[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6814:
Description:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accumulate maximum size of all the data regions defined cluster-wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
heap=1.8GB, ]
{code}
* Print detailed memory configuration below {{Topology Snapshot}} message
following this format:
{code}
Data Regions Configured:
^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
{code}
Example:
{code}
Data Regions Configured:
^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
persistenceEnabled=false]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
was:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accumulate maximum size of all the data regions defined cluster-wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
heap=1.8GB, ]
{code}
* Print detailed memory configuration below {{Topology Snapshot}} message
following this format:
{code}
Data Regions Configured:
^-- Data_Region_Name [initialSize=N, maxSize=N, persistenceEnabled={true|false}]
{code}
Example:
{code}
Data Regions Configured:
^-- Default [initialSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
^-- RegionalMetrics [initialSize=500MB, maxSize=15.0 GB,
persistenceEnabled=false]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initSize=N, maxSize=N, persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initSize=500MB, maxSize=15.0 GB,
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> All this is covered in official docs:
> https://apacheignite.readme.io/docs#section-data-regions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6814:
Description:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accumulate maximum size of all the data regions defined cluster-wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
heap=1.8GB, ]
{code}
* Print detailed memory configuration below {{Topology Snapshot}} message
following this format:
{code}
Data Regions Configured:
^-- Data_Region_Name [initialSize=N, maxSize=N, persistenceEnabled={true|false}]
{code}
Example:
{code}
Data Regions Configured:
^-- Default [initialSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
^-- RegionalMetrics [initialSize=500MB, maxSize=15.0 GB,
persistenceEnabled=false]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
was:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accummulate maximum size of all the data regions defined cluster wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
off-heap={total_max_offheap_requested}, heap=1.8GB, ]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accumulate maximum size of all the data regions defined cluster-wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4, off-heap={N},
> heap=1.8GB, ]
> {code}
> * Print detailed memory configuration below {{Topology Snapshot}} message
> following this format:
> {code}
> Data Regions Configured:
> ^-- Data_Region_Name [initialSize=N, maxSize=N,
> persistenceEnabled={true|false}]
> {code}
> Example:
> {code}
> Data Regions Configured:
>^-- Default [initialSize=100MB, maxSize=5.0 GB, persistenceEnabled=true]
>^-- RegionalMetrics [initialSize=500MB, maxSize=15.0 GB,
> persistenceEnabled=false]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> All this is covered in official docs:
> https://apacheignite.readme.io/docs#section-data-regions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6814:
Description:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accummulate maximum size of all the data regions defined cluster wide:
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
off-heap={total_max_offheap_requested}, heap=1.8GB, ]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
was:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accummulate maximum size of all the data regions defined cluster wide
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
off-heap={total_max_offheap_requested}, heap=1.8GB, ]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accummulate maximum size of all the data regions defined cluster wide:
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
> off-heap={total_max_offheap_requested}, heap=1.8GB, ]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> All this is covered in official docs:
> https://apacheignite.readme.io/docs#section-data-regions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6814) Detailed memory consumption on start and OOM reporting
[
https://issues.apache.org/jira/browse/IGNITE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6814:
Description:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
accummulate maximum size of all the data regions defined cluster wide
{code}
Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
off-heap={total_max_offheap_requested}, heap=1.8GB, ]
{code}
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
was:
Presently Ignite allocates 20% of RAM on a node startup, however, the user
doesn't see automatically chosen memory settings. Also, if there a node runs
out of RAM and throws an OOM error there are no hints on why this happened and
how to fix it.
Suggestions:
* Print out memory settings on startup for every data region set up (maximum
size, initial size, etc.)
* Provide guidelines on how to overcome OOM when it happens. Specify a data
region name with all its current parameters and suggest three possible things -
tweak maximum memory, setup eviction policies or enable Ignite persistence. All
this is covered in official docs:
https://apacheignite.readme.io/docs#section-data-regions
> Detailed memory consumption on start and OOM reporting
> --
>
> Key: IGNITE-6814
> URL: https://issues.apache.org/jira/browse/IGNITE-6814
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.0
>Reporter: Denis Magda
>Priority: Critical
> Labels: usability
> Fix For: 2.4
>
>
> Presently Ignite allocates 20% of RAM on a node startup, however, the user
> doesn't see automatically chosen memory settings. Also, if there a node runs
> out of RAM and throws an OOM error there are no hints on why this happened
> and how to fix it.
> Suggestions:
> * Add {{off-heap}} field to {{Topology Snapshot}} message. The field will
> accummulate maximum size of all the data regions defined cluster wide
> {code}
> Topology snapshot [ver=1, servers=1, clients=0, CPUs=4,
> off-heap={total_max_offheap_requested}, heap=1.8GB, ]
> {code}
> * Provide guidelines on how to overcome OOM when it happens. Specify a data
> region name with all its current parameters and suggest three possible things
> - tweak maximum memory, setup eviction policies or enable Ignite persistence.
> All this is covered in official docs:
> https://apacheignite.readme.io/docs#section-data-regions
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form
[ https://issues.apache.org/jira/browse/IGNITE-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg closed IGNITE-6717. --- > Hashcode/equals is not needed for custom keys serialized into a binary form > --- > > Key: IGNITE-6717 > URL: https://issues.apache.org/jira/browse/IGNITE-6717 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.3 > > > It turns out that hashCode/equals implementation is no longer required for > custom complex keys if a key is serialized to the binary form. Discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506 > The marshaller calculates the hash code automatically. This info has to be > added to the binary marshaller page: > https://apacheignite.readme.io/docs/binary-marshaller -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6717) Hashcode/equals is not needed for custom keys serialized into a binary form
[ https://issues.apache.org/jira/browse/IGNITE-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg resolved IGNITE-6717. - Resolution: Fixed Fixed minor issues. > Hashcode/equals is not needed for custom keys serialized into a binary form > --- > > Key: IGNITE-6717 > URL: https://issues.apache.org/jira/browse/IGNITE-6717 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.3 > > > It turns out that hashCode/equals implementation is no longer required for > custom complex keys if a key is serialized to the binary form. Discussed here: > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-3-troubles-with-key-value-APIs-in-the-cluster-configured-with-DDL-td23501.html#a23506 > The marshaller calculates the hash code automatically. This info has to be > added to the binary marshaller page: > https://apacheignite.readme.io/docs/binary-marshaller -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6686) Document SQL Data Types
[ https://issues.apache.org/jira/browse/IGNITE-6686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236517#comment-16236517 ] Denis Magda commented on IGNITE-6686: - [~ptupitsyn], I'll find a way how to split it once Vladimir does the final review and populates missing parts. > Document SQL Data Types > --- > > Key: IGNITE-6686 > URL: https://issues.apache.org/jira/browse/IGNITE-6686 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.3 > > > The data types page should include all SQL types supported and how they > mapped to a language or driver specific type. Presently the types are > represented in a tabular format: > https://apacheignite-sql.readme.io/v2.3/docs/data-types > Guys, please help to fill out langage/drivers specific columns: > # [~ptupitsyn] - .NET data types. > # [~isapego] - C++ and ODBC data type. > # [~al.psc] - JDBC and JAVA data types. > [~vozerov], please suggest what to do with these few types below. They > supported by H2 but I'm not sure how Ignite deals with them: > http://www.h2database.com/html/datatypes.html#identity_type > http://www.h2database.com/html/datatypes.html#binary_type > http://www.h2database.com/html/datatypes.html#other_type > http://www.h2database.com/html/datatypes.html#varchar_ignorecase_type > http://www.h2database.com/html/datatypes.html#blob_type > http://www.h2database.com/html/datatypes.html#clob_type > http://www.h2database.com/html/datatypes.html#array_type > http://www.h2database.com/html/datatypes.html#enum_type -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6374) Web Console SQL doesn't work with 2.2.0 RC1
[
https://issues.apache.org/jira/browse/IGNITE-6374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-6374:
Component/s: wizards
> Web Console SQL doesn't work with 2.2.0 RC1
> ---
>
> Key: IGNITE-6374
> URL: https://issues.apache.org/jira/browse/IGNITE-6374
> Project: Ignite
> Issue Type: Bug
> Components: wizards
>Affects Versions: 2.2
>Reporter: Denis Magda
>Assignee: Pavel Konstantinov
>Priority: Blocker
> Labels: important
> Fix For: 2.3
>
>
> Start a couple of nodes using 2.2.0-rc1 binary bundle:
> {code}
> ./ignite.sh ../examples/config/example-ignite.xml
> {code}
> Preload data using SQLLine tool and the SQL script as described here:
> https://github.com/dmagda/ignite_world_demo
> Go to Web Console SQL tab and send the simplest query possible:
> {code}
> select * from city
> {code}
> To get the exception like that:
> {code}
> [14:42:33,440][SEVERE][rest-#54%null%][GridTaskCommandHandler] Failed to
> execute task [name=o.a.i.i.v.compute.VisorGatewayTask, clientId=null]
> class org.apache.ignite.IgniteCheckedException: Failed to find constructor
> for task argument
> [taskName=org.apache.ignite.internal.visor.query.VisorQueryTask, argsCnt=8,
> args=[SQL_PUBLIC_CITY, select * from city, false, false, false, false, 100,
> false]]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7229)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:382)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:352)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:268)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:91)
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:157)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: Failed to find
> constructor for task argument
> [taskName=org.apache.ignite.internal.visor.query.VisorQueryTask, argsCnt=8,
> args=[SQL_PUBLIC_CITY, select * from city, false, false, false, false, 100,
> false]]
> at
> org.apache.ignite.internal.visor.compute.VisorGatewayTask$VisorGatewayJob.execute(VisorGatewayTask.java:400)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6608)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1115)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1385)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:640)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:749)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskPro
[jira] [Commented] (IGNITE-6607) Thin client: protocol documentation
[ https://issues.apache.org/jira/browse/IGNITE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236444#comment-16236444 ] Denis Magda commented on IGNITE-6607: - The protocol APIs have to be documented on readme.io. Ignite wiki is good for implementation details. > Thin client: protocol documentation > --- > > Key: IGNITE-6607 > URL: https://issues.apache.org/jira/browse/IGNITE-6607 > Project: Ignite > Issue Type: Task > Components: documentation, platforms >Affects Versions: 2.3 >Reporter: Pavel Tupitsyn >Priority: Major > Fix For: 2.4 > > > Document thin client protocol on Ignite wiki: > https://cwiki.apache.org/confluence/display/IGNITE/Design+Documents > * Common message format (length, flags) > * Data types (endianness, strings, etc) > * Request/Response format for each message type > * How to connect -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16236358#comment-16236358 ] ASF GitHub Bot commented on IGNITE-6626: Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/2848 > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > Attachments: IGNITE_6626.patch > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-358) Read external split from V2 Context and V1 Reporter #getInputSplit
[ https://issues.apache.org/jira/browse/IGNITE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Dudkov reassigned IGNITE-358: Assignee: Konstantin Dudkov > Read external split from V2 Context and V1 Reporter #getInputSplit > -- > > Key: IGNITE-358 > URL: https://issues.apache.org/jira/browse/IGNITE-358 > Project: Ignite > Issue Type: Task > Components: hadoop >Affects Versions: sprint-1 >Reporter: Vladimir Ozerov >Assignee: Konstantin Dudkov >Priority: Major > > Migrated from GG JIRA (GG-8755). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6823) Sporadic Redis python and php examples failures
[
https://issues.apache.org/jira/browse/IGNITE-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ksenia Rybakova updated IGNITE-6823:
Description:
Sporadic Redis python and php examples failures
python:
{noformat}
['python3', 'examples/redis/redis-example.py']
Traceback (most recent call last):
File "examples/redis/redis-example.py", line 30, in
r.set('k1', 1)
File "c:\program files\python34\lib\site-packages\redis\client.py", line
1171, in set
return self.execute_command('SET', *pieces)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 668,
in execute_command
return self.parse_response(connection, command_name, **options)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 680,
in parse_response
response = connection.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
624, in read_response
response = self._parser.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
292, in read_response
(str(byte), str(response)))
redis.exceptions.InvalidResponse: Protocol Error: E, b'RROR'
Command '['python3', 'examples/redis/redis-example.py']' returned non-zero exit
status 1
{noformat}
php:
{noformat}
['php', 'examples/redis/redis-example.php']
>>> Successfully connected to Redis.
>>> Couldn't connected to Redis.Unknown response prefix: 'E'.
>>> [tcp://localhost:11211]
{noformat}
was:
Sporadic Redis python examples failure
{noformat}
['python3', 'examples/redis/redis-example.py']
Traceback (most recent call last):
File "examples/redis/redis-example.py", line 30, in
r.set('k1', 1)
File "c:\program files\python34\lib\site-packages\redis\client.py", line
1171, in set
return self.execute_command('SET', *pieces)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 668,
in execute_command
return self.parse_response(connection, command_name, **options)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 680,
in parse_response
response = connection.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
624, in read_response
response = self._parser.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
292, in read_response
(str(byte), str(response)))
redis.exceptions.InvalidResponse: Protocol Error: E, b'RROR'
Command '['python3', 'examples/redis/redis-example.py']' returned non-zero exit
status 1
{noformat}
and Redis php
{noformat}
['php', 'examples/redis/redis-example.php']
>>> Successfully connected to Redis.
>>> Couldn't connected to Redis.Unknown response prefix: 'E'.
>>> [tcp://localhost:11211]
{noformat}
> Sporadic Redis python and php examples failures
> ---
>
> Key: IGNITE-6823
> URL: https://issues.apache.org/jira/browse/IGNITE-6823
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.1
>Reporter: Ksenia Rybakova
>Priority: Normal
>
> Sporadic Redis python and php examples failures
> python:
> {noformat}
> ['python3', 'examples/redis/redis-example.py']
> Traceback (most recent call last):
> File "examples/redis/redis-example.py", line 30, in
> r.set('k1', 1)
> File "c:\program files\python34\lib\site-packages\redis\client.py", line
> 1171, in set
> return self.execute_command('SET', *pieces)
> File "c:\program files\python34\lib\site-packages\redis\client.py", line
> 668, in execute_command
> return self.parse_response(connection, command_name, **options)
> File "c:\program files\python34\lib\site-packages\redis\client.py", line
> 680, in parse_response
> response = connection.read_response()
> File "c:\program files\python34\lib\site-packages\redis\connection.py",
> line 624, in read_response
> response = self._parser.read_response()
> File "c:\program files\python34\lib\site-packages\redis\connection.py",
> line 292, in read_response
> (str(byte), str(response)))
> redis.exceptions.InvalidResponse: Protocol Error: E, b'RROR'
> Command '['python3', 'examples/redis/redis-example.py']' returned non-zero
> exit status 1
> {noformat}
> php:
> {noformat}
> ['php', 'examples/redis/redis-example.php']
> >>> Successfully connected to Redis.
> >>> Couldn't connected to Redis.Unknown response prefix: 'E'.
> >>> [tcp://localhost:11211]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6823) Sporadic Redis python and php examples failures
Ksenia Rybakova created IGNITE-6823:
---
Summary: Sporadic Redis python and php examples failures
Key: IGNITE-6823
URL: https://issues.apache.org/jira/browse/IGNITE-6823
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Affects Versions: 2.1
Reporter: Ksenia Rybakova
Priority: Normal
Sporadic Redis python examples failure
{noformat}
['python3', 'examples/redis/redis-example.py']
Traceback (most recent call last):
File "examples/redis/redis-example.py", line 30, in
r.set('k1', 1)
File "c:\program files\python34\lib\site-packages\redis\client.py", line
1171, in set
return self.execute_command('SET', *pieces)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 668,
in execute_command
return self.parse_response(connection, command_name, **options)
File "c:\program files\python34\lib\site-packages\redis\client.py", line 680,
in parse_response
response = connection.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
624, in read_response
response = self._parser.read_response()
File "c:\program files\python34\lib\site-packages\redis\connection.py", line
292, in read_response
(str(byte), str(response)))
redis.exceptions.InvalidResponse: Protocol Error: E, b'RROR'
Command '['python3', 'examples/redis/redis-example.py']' returned non-zero exit
status 1
{noformat}
and Redis php
{noformat}
['php', 'examples/redis/redis-example.php']
>>> Successfully connected to Redis.
>>> Couldn't connected to Redis.Unknown response prefix: 'E'.
>>> [tcp://localhost:11211]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer
[ https://issues.apache.org/jira/browse/IGNITE-5343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235866#comment-16235866 ] Pavel Tupitsyn commented on IGNITE-5343: UnmanagedUtils and UnmanagedCallbacks refactored to a new mechanism. Ignite starts without any C++ calls. > .NET: Interoperate with JVM directly, get rid of C++ layer > -- > > Key: IGNITE-5343 > URL: https://issues.apache.org/jira/browse/IGNITE-5343 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, xplat > > We can work with JNI directly using P/Invoke, there is no real need for C++ > layer. > Advantages of removing C++ layer: > * *No MSVC++ 2010 dependency* > * *No build tools required for development* > * Simplify and speed up the build procedure > * No embedded libraries > * Easier crossplatform support (IGNITE-2662) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235843#comment-16235843 ] Andrew Mashenkov edited comment on IGNITE-6649 at 11/2/17 2:51 PM: --- 1. Added eviction factory support for near caches. 2. Getter and setter methods use Factory interface that already implements Serializable. But I add a note to make it clear for user who implements his own factory. 3. Added cache configuration consistency tests. 4. Also, I revert back some changes that can break compatibility with prev. versions as EvictionPolicy can't be fully replaced with factory until 3.0 version Waiting for TC tests. was (Author: amashenkov): 1. Added eviction factory support for near caches. 2. Getter and setter method used Factory interface that already implements Serializable. But I add a note to make it clear for user who implements his own factory. 3. Added cache configuration consistency tests. 4. Also, I revert back some changes that can break compatibility with prev. versions as EvictionPolicy can't be fully replaced with factory until 3.0 version Waiting for TC tests. > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.4 > > Attachments: EvictionPolicyTest.java > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.pu
[jira] [Commented] (IGNITE-6649) Add EvictionPolicy factory support in IgniteConfiguration.
[ https://issues.apache.org/jira/browse/IGNITE-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235843#comment-16235843 ] Andrew Mashenkov commented on IGNITE-6649: -- 1. Added eviction factory support for near caches. 2. Getter and setter method used Factory interface that already implements Serializable. But I add a note to make it clear for user who implements his own factory. 3. Added cache configuration consistency tests. 4. Also, I revert back some changes that can break compatibility with prev. versions as EvictionPolicy can't be fully replaced with factory until 3.0 version Waiting for TC tests. > Add EvictionPolicy factory support in IgniteConfiguration. > -- > > Key: IGNITE-6649 > URL: https://issues.apache.org/jira/browse/IGNITE-6649 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.4 > > Attachments: EvictionPolicyTest.java > > > For now the only way to set EvictionPolicy to IgniteConfiguration is to use > EvictionPolicy instance. > That looks error prone as user can easily share instance between caches or > cache reincarnations and got unexpected results. > E.g. it can cause an AssertionError if EvictionPolicy is reused. > Steps to reproduce. > 1. Create CacheConfiguration object that will be reused. > 2. Create and fill a cache. > 3. Destroy cache and create cache again with same CacheConfiguration object. > 4. One of next put can fails with stacktrace below. > The error is throws when EvictionPolicy tries to evict entries from cache > that has just been destroyed. > Also, EvictionPolicy object can be implicitly holds by some user objects > (together with IgniteConfiguration) that can cause memory leak. > java.lang.AssertionError > at > org.apache.ignite.internal.processors.cache.CacheEvictableEntryImpl.evict(CacheEvictableEntryImpl.java:71) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink0(LruEvictionPolicy.java:275) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.shrink(LruEvictionPolicy.java:250) > at > org.apache.ignite.cache.eviction.lru.LruEvictionPolicy.onEntryAccessed(LruEvictionPolicy.java:161) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.notifyPolicy(GridCacheEvictionManager.java:1393) > at > org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(GridCacheEvictionManager.java:825) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(GridDhtAtomicCache.java:3058) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1952) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1730) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:264) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:209) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1245) > at > org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:680) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2328) > at > org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2305) > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1379) > > UPD: See discussion here [1]. > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/CacheConfiguration-reusage-issues-with-EvictionPolicy-enabled-td23437.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235838#comment-16235838 ] Vladimir Ozerov commented on IGNITE-6626: - New test run with fixed problem: https://ci.ignite.apache.org/viewQueued.html?itemId=927476 > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > Attachments: IGNITE_6626.patch > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6128) Binary: offsets might be skipped for constant-length fields
[
https://issues.apache.org/jira/browse/IGNITE-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita reassigned IGNITE-6128:
---
Assignee: Amelchev Nikita
> Binary: offsets might be skipped for constant-length fields
> ---
>
> Key: IGNITE-6128
> URL: https://issues.apache.org/jira/browse/IGNITE-6128
> Project: Ignite
> Issue Type: Task
> Components: binary
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: iep-2, performance
>
> Currently we write offsets for every field. It could take 1, 2 or 4 bytes
> depending on the data length of the object. Now suppose we have the following
> class:
> {code}
> class MyClass {
> int a;
> String c;
> long b;
> int d;
> int e;
> }
> {code}
> Fields are always sorted in alphabetical order, so we will write them as
> follows {{[a, b, c, d, e]}}, and their offsets would always be {{[0, 5, 14,
> X, X+5]}}. As you see, instead of writing 5 offsets, it is enough to write
> only one offset of a field, which follows another variable-length field. The
> rest offsets could be saved to metadata.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235782#comment-16235782 ] Alexey Goncharuk commented on IGNITE-6679: -- Pavel is right, we cannot remove methods from the public API. The methods should be deprecated. I would also return 0 from them rather than throwing an exception because this may break or make inefficient monitoring tools attached to these metrics. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6272) .NET: Propagate multiple services deployment
[
https://issues.apache.org/jira/browse/IGNITE-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235726#comment-16235726
]
Vladimir Ozerov commented on IGNITE-6272:
-
[~alexey.tank2], [~ptupitsyn], looks good to me, except of one thing - please
confirm the binary compatibility is not broken by a new field
{{ServiceDeploymentException._failedCfgs}}.
> .NET: Propagate multiple services deployment
>
>
> Key: IGNITE-6272
> URL: https://issues.apache.org/jira/browse/IGNITE-6272
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Denis Mekhanikov
>Assignee: Alexey Popov
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.4
>
>
> Multiple services deployment support should be propagated to .NET:
> * {{IgniteServices.deployAll}}
> * {{IgniteServices.deployAllAsync}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6822) IgfsMapReduceExample raise exception in multi nodes run
[
https://issues.apache.org/jira/browse/IGNITE-6822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Chetaev updated IGNITE-6822:
Attachment: example.log
grid.o.a.i.e.igfs.IgfsNodeStartup.1.log
grid.o.a.i.e.igfs.IgfsNodeStartup.2.log
grid.o.a.i.e.igfs.IgfsNodeStartup.3.log
> IgfsMapReduceExample raise exception in multi nodes run
> ---
>
> Key: IGNITE-6822
> URL: https://issues.apache.org/jira/browse/IGNITE-6822
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Reporter: Aleksey Chetaev
>Priority: Minor
> Attachments: example.log, grid.o.a.i.e.igfs.IgfsNodeStartup.1.log,
> grid.o.a.i.e.igfs.IgfsNodeStartup.2.log,
> grid.o.a.i.e.igfs.IgfsNodeStartup.3.log
>
>
> All logs in attachments.
> Exception:
> {code:java}
> class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
> interrupted
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7538)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.fileLock(MarshallerMappingFileStore.java:254)
> at
> org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:95)
> at
> org.apache.ignite.internal.MappingStoreTask.run(MappingStoreTask.java:57)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6822) IgfsMapReduceExample raise exception in multi nodes run
Aleksey Chetaev created IGNITE-6822:
---
Summary: IgfsMapReduceExample raise exception in multi nodes run
Key: IGNITE-6822
URL: https://issues.apache.org/jira/browse/IGNITE-6822
Project: Ignite
Issue Type: Bug
Security Level: Public (Viewable by anyone)
Reporter: Aleksey Chetaev
Priority: Minor
All logs in attachments.
Exception:
{code:java}
class org.apache.ignite.internal.IgniteInterruptedCheckedException: sleep
interrupted
at org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:7538)
at
org.apache.ignite.internal.MarshallerMappingFileStore.fileLock(MarshallerMappingFileStore.java:254)
at
org.apache.ignite.internal.MarshallerMappingFileStore.writeMapping(MarshallerMappingFileStore.java:95)
at org.apache.ignite.internal.MappingStoreTask.run(MappingStoreTask.java:57)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6687)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
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)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235693#comment-16235693 ] Vladimir Ozerov commented on IGNITE-6626: - See attached patch. > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > Attachments: IGNITE_6626.patch > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6626) SQL: Avoid materializing rows when possible
[
https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6626:
Attachment: IGNITE_6626.patch
Some SQL tests fail. E.g. run {{IgniteSqlSplitterSelfTest}}. Root cause: newly
introduced {{GridH2FilteredRow}} cannot be compared with other rows.
Looks like our {{BPlusTree}} lacks important piece of functionality: ability to
filter out rows on IO level before they are materialized. We need to implement
it before moving forward.
> SQL: Avoid materializing rows when possible
> ---
>
> Key: IGNITE-6626
> URL: https://issues.apache.org/jira/browse/IGNITE-6626
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
> Fix For: 2.4
>
> Attachments: IGNITE_6626.patch
>
>
> We need to filter backup keys during query execution. Currently to achieve
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement row filtering on B+Tree level and avoid their
> materialization.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235675#comment-16235675 ] Anton Vinogradov commented on IGNITE-6679: -- [~NSAmelchev] 1) We need approval by [~sboikov] or [~agoncharuk], that these metrics become useless 2) We should mark them as @Deprecated and cause exception throw in case of usage attempt. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235667#comment-16235667 ] Pavel Tupitsyn edited comment on IGNITE-6679 at 11/2/17 12:44 PM: -- [~NSAmelchev], we can't break compilation between minor releases. Instead of removing methods we should deprecate them. was (Author: ptupitsyn): Changes look good to me, but we can't release this in 2.4. We can't break compilation between minor releases. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235667#comment-16235667 ] Pavel Tupitsyn commented on IGNITE-6679: Changes look good to me, but we can't release this in 2.4. We can't break compilation between minor releases. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-6679: Fix Version/s: 2.4 > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > Fix For: 2.4 > > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6679) Clean up some deprecated cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235657#comment-16235657 ] Amelchev Nikita commented on IGNITE-6679: - [~avinogradov], [~ptupitsyn] I have removed deprecated metrics. Please, [review|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-390]. [Tests|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2962%2Fhead] look good. > Clean up some deprecated cache metrics > --- > > Key: IGNITE-6679 > URL: https://issues.apache.org/jira/browse/IGNITE-6679 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Sergey Puchnin >Assignee: Amelchev Nikita > Labels: Newbie > > An old optimistic serializable mode implementation was removed in 2.0 but > some cache metrics still present in CacheMetrics interface. > Need to clean up and remove these metrics: > *TxCommitQueueSize* > *TxPrepareQueueSize* > *TxStartVersionCountsSize* > *TxDhtCommitQueueSize* > *TxDhtPrepareQueueSize* > *TxDhtStartVersionCountsSize* > An algorithm for page eviction was changed and metric > *DhtEvictQueueCurrentSize* should be removed also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6691) Run ServiceTopologyCallable from GridServiceProcessor.serviceTopology in management pool
[ https://issues.apache.org/jira/browse/IGNITE-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgenii Zhuravlev resolved IGNITE-6691. --- Resolution: Duplicate Fix Version/s: (was: 2.4) was already fixed in this issue https://issues.apache.org/jira/browse/IGNITE-4802 > Run ServiceTopologyCallable from GridServiceProcessor.serviceTopology in > management pool > > > Key: IGNITE-6691 > URL: https://issues.apache.org/jira/browse/IGNITE-6691 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Affects Versions: 2.1 >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > > Now this job runs in the public pool. It could lead to starvation when > service invoked from any job that runs in public pool. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5544) Ignite Cache: floating failure in testBackupRestore
[
https://issues.apache.org/jira/browse/IGNITE-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235635#comment-16235635
]
Stanilovsky Evgeny commented on IGNITE-5544:
run it 50 times, seems all ok now, assertion not found.
> Ignite Cache: floating failure in testBackupRestore
> ---
>
> Key: IGNITE-5544
> URL: https://issues.apache.org/jira/browse/IGNITE-5544
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-3580536643752440720&tab=testDetails
> Success rate on TC - 83%
> http://ci.ignite.apache.org/viewLog.html?buildId=674133&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache#testNameId-3580536643752440720
> GridCacheReplicatedLocalStoreSelfTest.testBackupRestorePrimary
> testBackupRestorePrimary
> Has floating failure
> Can be reproduced locally with run until failure, 7-10 runs required:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractLocalStoreSelfTest.testBackupRestore(GridCacheAbstractLocalStoreSelfTest.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractLocalStoreSelfTest.testBackupRestorePrimary(GridCacheAbstractLocalStoreSelfTest.java:285)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-5544) Ignite Cache: floating failure in testBackupRestore
[
https://issues.apache.org/jira/browse/IGNITE-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny resolved IGNITE-5544.
Resolution: Cannot Reproduce
> Ignite Cache: floating failure in testBackupRestore
> ---
>
> Key: IGNITE-5544
> URL: https://issues.apache.org/jira/browse/IGNITE-5544
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, test-fail
>
> http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-3580536643752440720&tab=testDetails
> Success rate on TC - 83%
> http://ci.ignite.apache.org/viewLog.html?buildId=674133&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCache#testNameId-3580536643752440720
> GridCacheReplicatedLocalStoreSelfTest.testBackupRestorePrimary
> testBackupRestorePrimary
> Has floating failure
> Can be reproduced locally with run until failure, 7-10 runs required:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractLocalStoreSelfTest.testBackupRestore(GridCacheAbstractLocalStoreSelfTest.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAbstractLocalStoreSelfTest.testBackupRestorePrimary(GridCacheAbstractLocalStoreSelfTest.java:285)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-6801) Ignite Kafka Connector certification with Confluent
[ https://issues.apache.org/jira/browse/IGNITE-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin closed IGNITE-6801. > Ignite Kafka Connector certification with Confluent > --- > > Key: IGNITE-6801 > URL: https://issues.apache.org/jira/browse/IGNITE-6801 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.2 > Environment: >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Fix For: 2.4 > > Original Estimate: 336h > Remaining Estimate: 336h > > Certifying Ignite Kafka connector with Confluent will give Ignite Community > benefits like: > * TBD (I will put the benefits here after I confirm them) > A certified connector must be coded according to [these > requirements](https://www.confluent.io/wp-content/uploads/Partner-Dev-Guide-for-Kafka-Connect.pdf), > reviewed and approved by Confluent. > The existing ignite-kafka module does not comply with the requirements. > The purpose of this task to develop a certified version of the connector. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6801) Ignite Kafka Connector certification with Confluent
[ https://issues.apache.org/jira/browse/IGNITE-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin resolved IGNITE-6801. -- Resolution: Won't Do After discussing priorities, it was decided to keep existing ignite-kafka module as is. > Ignite Kafka Connector certification with Confluent > --- > > Key: IGNITE-6801 > URL: https://issues.apache.org/jira/browse/IGNITE-6801 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.2 > Environment: >Reporter: Alexey Kukushkin >Assignee: Alexey Kukushkin >Priority: Major > Fix For: 2.4 > > Original Estimate: 336h > Remaining Estimate: 336h > > Certifying Ignite Kafka connector with Confluent will give Ignite Community > benefits like: > * TBD (I will put the benefits here after I confirm them) > A certified connector must be coded according to [these > requirements](https://www.confluent.io/wp-content/uploads/Partner-Dev-Guide-for-Kafka-Connect.pdf), > reviewed and approved by Confluent. > The existing ignite-kafka module does not comply with the requirements. > The purpose of this task to develop a certified version of the connector. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6626: Comment: was deleted (was: Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=890225) > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235601#comment-16235601 ] Vladimir Ozerov edited comment on IGNITE-6626 at 11/2/17 11:44 AM: --- New test run: https://ci.ignite.apache.org/viewQueued.html?itemId=927364 was (Author: vozerov): https://ci.ignite.apache.org/viewQueued.html?itemId=927364 > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6626) SQL: Avoid materializing rows when possible
[ https://issues.apache.org/jira/browse/IGNITE-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235601#comment-16235601 ] Vladimir Ozerov commented on IGNITE-6626: - https://ci.ignite.apache.org/viewQueued.html?itemId=927364 > SQL: Avoid materializing rows when possible > --- > > Key: IGNITE-6626 > URL: https://issues.apache.org/jira/browse/IGNITE-6626 > Project: Ignite > Issue Type: Task > Components: cache, sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > Fix For: 2.4 > > > We need to filter backup keys during query execution. Currently to achieve > this we do the following: > 1) Get row link > 2) Materialize the row (!!!) > 3) Create H2 row (H2 wrapping) > 4) Then get key from H2 row (unwrapping) > 5) Calculate partition through affinity function > What it might look like: > 1) Get row link > 2) Get partition from link > This ticket is to implement row filtering on B+Tree level and avoid their > materialization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors
[ https://issues.apache.org/jira/browse/IGNITE-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235596#comment-16235596 ] ASF GitHub Bot commented on IGNITE-6690: Github user apopovgg closed the pull request at: https://github.com/apache/ignite/pull/2971 > DiscoverySpi: Clientmode Ignite should not fail on handshake errors > --- > > Key: IGNITE-6690 > URL: https://issues.apache.org/jira/browse/IGNITE-6690 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: general >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov >Priority: Major > Labels: discovery > Fix For: 2.4 > > > Ignite in Client mode should not fail on handshake unmarshalling errors. It > should go to the next IP/port from ipFinder list > http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin
[ https://issues.apache.org/jira/browse/IGNITE-6816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-6816: - Assignee: Andrey Novikov (was: Alexander Kalinin) Andrey, I've implemented dll with webpack. Please review > Webconsole: investigate/integrate Webpack dll-plugin > > > Key: IGNITE-6816 > URL: https://issues.apache.org/jira/browse/IGNITE-6816 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov > > As the webconsole frontend app size grows, it takes more and more time to > incrementally rebuild after each source code change in development > environment. Let's investigate this plugin > https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack > build pipeline if it offers measureable performance improvements. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6821) Add test for cross-cache transactions between in-memory and persistent caches
Alexey Goncharuk created IGNITE-6821: Summary: Add test for cross-cache transactions between in-memory and persistent caches Key: IGNITE-6821 URL: https://issues.apache.org/jira/browse/IGNITE-6821 Project: Ignite Issue Type: Test Security Level: Public (Viewable by anyone) Components: 2.3 Affects Versions: 2.4 Reporter: Alexey Goncharuk Assignee: Ivan Rakov Priority: Major Need to add tests that will make sure that we do not log data records for persistence-disabled caches and can successfully recover for persistence-enabled caches when a transaction hits both caches. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6820) Add data regions to data structures configuration
Alexey Goncharuk created IGNITE-6820: Summary: Add data regions to data structures configuration Key: IGNITE-6820 URL: https://issues.apache.org/jira/browse/IGNITE-6820 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Components: cache Affects Versions: 2.3 Reporter: Alexey Goncharuk Priority: Major Fix For: 2.4 Data structures configuration has cache group name but misses data region name. This makes it tricky to move data structures to a different data region. More specifically, it's hard to have default data region with persistence disabled but configure data structures to be persistent. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6640) Introduction of models import/export
[ https://issues.apache.org/jira/browse/IGNITE-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235475#comment-16235475 ] ASF GitHub Bot commented on IGNITE-6640: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2968 > Introduction of models import/export > > > Key: IGNITE-6640 > URL: https://issues.apache.org/jira/browse/IGNITE-6640 > Project: Ignite > Issue Type: New Feature > Security Level: Public(Viewable by anyone) > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak >Priority: Major > Fix For: 2.4 > > > We need to add basic import/export functionality for ml models. We will start > from simple binary save to file and load from file. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6809) Use MPSC queue in striped pool
[ https://issues.apache.org/jira/browse/IGNITE-6809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-6809: - Component/s: general > Use MPSC queue in striped pool > -- > > Key: IGNITE-6809 > URL: https://issues.apache.org/jira/browse/IGNITE-6809 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: general >Affects Versions: 2.3 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Normal > Labels: performance > Fix For: 2.4 > > > Use MPSC queue in striped pool > Let's start from [MP-SC concurrent linked queue implementation based on > Dmitry > Vyukov's|http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6324) transactional cache data partially available after crash.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235443#comment-16235443 ] Dmitriy Govorukhin commented on IGNITE-6324: [~agoncharuk] Please review my changes, [TC result|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2961%2Fhead] > transactional cache data partially available after crash. > - > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 1.9, 2.1 >Reporter: Stanilovsky Evgeny >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.4 > > Attachments: InterruptCommitedThreadTest.java > > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors
[ https://issues.apache.org/jira/browse/IGNITE-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235378#comment-16235378 ] ASF GitHub Bot commented on IGNITE-6690: GitHub user apopovgg opened a pull request: https://github.com/apache/ignite/pull/2971 IGNITE-6690 DiscoverySpi: Clientmode Ignite should not fail on handshake errors test fixes You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6690 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2971.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2971 commit 224e2343c12ad80417eb1094a67b63f3ec56c2a7 Author: apopov Date: 2017-11-02T07:22:28Z fixed tests broken by IGNITE-6690 and IGNITE-5860 incompatibility commit 126a25ef8f3125415c743acaea0b5e47fe1f047b Author: apopov Date: 2017-11-02T08:22:03Z fixed tests broken by IGNITE-6690 and IGNITE-5860 incompatibility > DiscoverySpi: Clientmode Ignite should not fail on handshake errors > --- > > Key: IGNITE-6690 > URL: https://issues.apache.org/jira/browse/IGNITE-6690 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: general >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov >Priority: Major > Labels: discovery > Fix For: 2.4 > > > Ignite in Client mode should not fail on handshake unmarshalling errors. It > should go to the next IP/port from ipFinder list > http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6819) Better test coverage for PagesList basic functionality
Sergey Chugunov created IGNITE-6819: --- Summary: Better test coverage for PagesList basic functionality Key: IGNITE-6819 URL: https://issues.apache.org/jira/browse/IGNITE-6819 Project: Ignite Issue Type: Test Security Level: Public (Viewable by anyone) Reporter: Sergey Chugunov Assignee: Sergey Chugunov Priority: Major Working on IGNITE-6641 I faced an issue that serious bug introduced to PagesListNodeIO didn't cause obvious test failures and was spotted by chance from memory leak test failures. It means that test coverage of pages management code base lacks tests for invariants that has to be preserved in any use cases. We need to introduce such tests starting with set of tests verifying that certain pages go to certain buckets on data entries put/remove operations. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6817) CME in GridCacheIoManager.cacheHandlers access
[
https://issues.apache.org/jira/browse/IGNITE-6817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Belyak updated IGNITE-6817:
-
Priority: Major (was: Trivial)
> CME in GridCacheIoManager.cacheHandlers access
> --
>
> Key: IGNITE-6817
> URL: https://issues.apache.org/jira/browse/IGNITE-6817
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: general
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Major
>
> Got exception:
> {noformat}
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1437)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1471)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1469)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:355)
>at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> becouse in GridCacheIoManager.handleMessage access to
> GridCacheIoManager.cacheHandles protected by GridCacheIoManager.rw.readLock,
> but in GridCacheIoManager.addHandler same collection modify without
> rw.writeLock accuiring and idxClsHandlers is just HashMap in
> GridCacheioManager.MessageHandlers class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6818) In case of incoming communication connection ping the old one if it's alive
Dmitry Karachentsev created IGNITE-6818: --- Summary: In case of incoming communication connection ping the old one if it's alive Key: IGNITE-6818 URL: https://issues.apache.org/jira/browse/IGNITE-6818 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Affects Versions: 2.3 Reporter: Dmitry Karachentsev Assignee: Dmitry Karachentsev Priority: Critical Fix For: 2.4 Assume the following scenario: 1. Client opens connection to the server. 2. Server checks that it is a first connection to that node and accepts it. 3. By some reason firewall starts rejecting client messages with TCP reset flag set. 4. Client closes connection, but server doesn't know about it. 5. Client tries connect again. 6. Server rejects new connection, because it already has connection to that node. Possible fix: on step 6 server must check old connection if it's alive by sending some communication message and check response. If old connection is dead - close it and accept new one. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors
[ https://issues.apache.org/jira/browse/IGNITE-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235306#comment-16235306 ] Alexey Popov commented on IGNITE-6690: -- Tests were broken by https://issues.apache.org/jira/browse/IGNITE-5860 changes. IGNITE-5860 reverses the order of connection attempts to ipFinder IP lists. > DiscoverySpi: Clientmode Ignite should not fail on handshake errors > --- > > Key: IGNITE-6690 > URL: https://issues.apache.org/jira/browse/IGNITE-6690 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: general >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov >Priority: Major > Labels: discovery > Fix For: 2.4 > > > Ignite in Client mode should not fail on handshake unmarshalling errors. It > should go to the next IP/port from ipFinder list > http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
