[jira] [Resolved] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RangerZhou resolved IGNITE-12798. - Resolution: Resolved > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12798) Failed to start continuous query when use client node in IDEA
[ https://issues.apache.org/jira/browse/IGNITE-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072389#comment-17072389 ] RangerZhou commented on IGNITE-12798: - Hi [~Pavlukhin], You are right, the root cause is not enable peer class loading. Thanks !!! > Failed to start continuous query when use client node in IDEA > - > > Key: IGNITE-12798 > URL: https://issues.apache.org/jira/browse/IGNITE-12798 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: RangerZhou >Priority: Major > Attachments: Exception.log, Exception01.png, Exception02.png, > Exception03.png, TOFListener.png > > > I start ignite server by ./ignite.sh, start a ignite client by java code, and > execute a continuous query with java in IDEA, but exception like this: > Exception in thread "main" javax.cache.CacheException: Failed to start > continuous query. > Caused by: class org.apache.ignite.IgniteCheckedException: TOFListener > But if I start server node by java code in IDEA ( Ignition.start() ), the > continuous query is ok. > My client code as below: > > !TOFListener.png! > The exception screenshots: > !Exception01.png! > !Exception02.png! > !Exception03.png! > The exception uploaded the attachment -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072220#comment-17072220
]
Sergey Kosarev commented on IGNITE-12793:
-
[~sergey-chugunov], I've reproduced the problem on master.
See my commit:
[https://github.com/macrergate/ignite/commit/9a7d2d27af30018a5f6faccb39176a35243ccfa2]
> Deadlock in the System Pool on Metadata processing
> --
>
> Key: IGNITE-12793
> URL: https://issues.apache.org/jira/browse/IGNITE-12793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: Sergey Kosarev
>Priority: Major
>
> I've recently tried to apply Ilya's idea
> (https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread
> pools and tried to set system pool to 3 in my own tests.
> It caused deadlock on a client node and I think it can happen not only on
> such small pool values.
> Details are following:
> I'm not using persistence currently (if it matters).
> On the client note I use ignite compute to call a job on every server node
> (there are 3 server nodes in the tests).
> Then I've found in logs:
> {{[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773] {grid-timeout-worker-#8}
> [WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
> task completed in last 3ms, is system thread pool size large enough?)
> [10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]}}
> I see in threaddumps that all 3 system pool workers do the same - processing
> of job responses:
> {{ "sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
> waiting on condition [0x7b91d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
> at
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
> at
> org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
> at
>
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[
https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072110#comment-17072110
]
Ignite TC Bot commented on IGNITE-12710:
{panel:title=Branch: [pull/7461/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5173263buildTypeId=IgniteTests24Java8_RunAll]
> Extension log in rebuild indexes to search problems
> ---
>
> Key: IGNITE-12710
> URL: https://issues.apache.org/jira/browse/IGNITE-12710
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We should have the ability to get extended information about rebuild indexes:
> cache, cache id, cache group, cache group id, index name, index type, index
> size.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072082#comment-17072082
]
Sarunas Valaskevicius edited comment on IGNITE-12850 at 3/31/20, 7:24 PM:
--
Please can you also suggest a short-term workaround as well as a proper fix?
I found that if I delete metastorage persistence directory ignite starts ok -
why is it hardcoded to persistence true? what problems would I see if I deleted
the metastorage before starting the node?
was (Author: sarunas):
Please can you also suggest a short-term workaround as well as a proper fix?
I found that if I delete metastorage persistence directory ignite starts ok -
why is it hardcoded to persistence true? what problems would I see if I delete
metastorage before starting the node?
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates base line topology history with gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> –
> it seems that ignite 2.8.0 would suffer from the same issue - by looking at
> the code
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072082#comment-17072082
]
Sarunas Valaskevicius commented on IGNITE-12850:
Please can you also suggest a short-term workaround as well as a proper fix?
I found that if I delete metastorage persistence directory ignite starts ok -
why is it hardcoded to persistence true? what problems would I see if I delete
metastorage before starting the node?
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates base line topology history with gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> –
> it seems that ignite 2.8.0 would suffer from the same issue - by looking at
> the code
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarunas Valaskevicius updated IGNITE-12850:
---
Description:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history item, and generates base line topology history with gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
–
it seems that ignite 2.8.0 would suffer from the same issue - by looking at
the code
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
was:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history item, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
–
it seems that ignite 2.8.0 would suffer from the same issue - by looking at
the code
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates
[jira] [Updated] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarunas Valaskevicius updated IGNITE-12850:
---
Description:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history item, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
–
it seems that ignite 2.8.0 would suffer from the same issue - by looking at
the code
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
was:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
--
it seems that ignite 2.8.0 would suffer from the same issue - by looking at the
code
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history item, and generates
[jira] [Updated] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarunas Valaskevicius updated IGNITE-12850:
---
Description:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
--
it seems that ignite 2.8.0 would suffer from the same issue - by looking at the
code
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
was:
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history, and generates base line topology with history in gaps
> # from that point, it is impossible to start the node as
[jira] [Updated] (IGNITE-12850) Ignite node cannot be started (metastorage history loading fails)
[
https://issues.apache.org/jira/browse/IGNITE-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarunas Valaskevicius updated IGNITE-12850:
---
Summary: Ignite node cannot be started (metastorage history loading fails)
(was: Ignite cannot start (metastorage history loading fails))
> Ignite node cannot be started (metastorage history loading fails)
> -
>
> Key: IGNITE-12850
> URL: https://issues.apache.org/jira/browse/IGNITE-12850
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: Sarunas Valaskevicius
>Priority: Blocker
>
> # metastorage is using persistence
> # when a node is ready to write, writeBaselineTopology is called with null
> history, and generates base line topology with history in gaps
> # from that point, it is impossible to start the node as
> `{color:#569e16}restoreHistory{color}` throws an exception when it is
> processing the gap
> {code:java}
> 2020-03-21_00:00:03.867 [fapi-main-0] INFO
> o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
> BaselineTopology[id=9]
> 2020-03-21_00:00:03.904 [fapi-main-0] ERROR
> o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
> node will be stopped and close connections
> org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology
> history has failed, expected history item not found for id=8
> at
> org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12850) Ignite cannot start (metastorage history loading fails)
Sarunas Valaskevicius created IGNITE-12850:
--
Summary: Ignite cannot start (metastorage history loading fails)
Key: IGNITE-12850
URL: https://issues.apache.org/jira/browse/IGNITE-12850
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7.6
Reporter: Sarunas Valaskevicius
# metastorage is using persistence
# when a node is ready to write, writeBaselineTopology is called with null
history, and generates base line topology with history in gaps
# from that point, it is impossible to start the node as
`{color:#569e16}restoreHistory{color}` throws an exception when it is
processing the gap
{code:java}
2020-03-21_00:00:03.867 [fapi-main-0] INFO
o.a.i.i.p.c.GridClusterStateProcessor:117 <> - Restoring history for
BaselineTopology[id=9]
2020-03-21_00:00:03.904 [fapi-main-0] ERROR
o.a.ignite.internal.IgniteKernal:137 <> - Exception during start processors,
node will be stopped and close connections
org.apache.ignite.IgniteCheckedException: Restoring of BaselineTopology history
has failed, expected history item not found for id=8
at
org.apache.ignite.internal.processors.cluster.BaselineTopologyHistory.restoreHistory(BaselineTopologyHistory.java:54)
at
org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.onReadyForRead(GridClusterStateProcessor.java:223)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:409)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:675)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4730)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1048)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2038)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12848) SQL: H2Connection leaks on INSERT
[
https://issues.apache.org/jira/browse/IGNITE-12848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17072042#comment-17072042
]
Ilya Kasnacheev commented on IGNITE-12848:
--
Is it possible that it is related in any way to IGNITE-12764?
> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> H2 connection leaks on INSERT query when one row is inserted and not constant
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after
> {{DmlUtils#processSelectResult}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12849) Add New BinaryObject Vectorizer for SparseVectors and Integer Coordinates
[ https://issues.apache.org/jira/browse/IGNITE-12849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev reassigned IGNITE-12849: Assignee: Alexey Zinoviev > Add New BinaryObject Vectorizer for SparseVectors and Integer Coordinates > - > > Key: IGNITE-12849 > URL: https://issues.apache.org/jira/browse/IGNITE-12849 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Glenn Wiebe >Assignee: Alexey Zinoviev >Priority: Minor > Fix For: 2.8 > > > A. DenseVector-based BinaryObjectVectorizer > When using existing caches as a source of Datasets, the > BinaryObjectVectorizer is used. > The existing BinaryObjectVectorizer only supports the creation of a > SparseVector. > The LUDecomposition utility that supports gaussian factorization for models > like GMM have a "Singularity indicator" for which a SparseVector and its null > handling will set a matrix column calculation to be zero/0.0 which is below > the minimum check value (1e-11) and thus indicate a matrix is not square. > This null handling of the SparseMatrix will restrict the use of some > algorithms like Gaussian Mixture Models where any Vector dimension that is > null will incorrectly signal that a matrix is not square. > It would be great if we could: > - Have a BinaryObjectVectorizer that uses a DenseMatrix to eliminate this > singularity trigger and enable use of GMM Trainer. > B. CacheBasedDatasets not treated as Temporary Cache > When using a cache-based dataset, the close() method destroys the Ignite > cache. This means that there is no ability to re-use the data loaded into > this dataset. > It would be great if we could: > - Not destroy the Ignite Cache holding the dataset on close (of one step in > an ML processing flow) > - Allow for "attaching" to this prior, pre-calculated dataset in subsequent > use. > C. Vector Visibility > Vectors (unlike other value types, e.g. BinaryObjects) are not visible in > standard mechanisms, like the Ignite Web Console, where the toString() method > does not present any information about the embedded vector values. > It would be great if we could: > - have a Vector.toString() method implementation that presented some > information about what is actually in the Vector. > I have implemented the above items and have used them at a customer where I > needed these capabilities (or at least it dramatically reduced the cost and > increased the value of the solution). > It would be great if the community was supportive of this > expansion/improvement of the Ignite ML library. > Thanks, > Glenn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12849) Add New BinaryObject Vectorizer for SparseVectors and Integer Coordinates
Glenn Wiebe created IGNITE-12849: Summary: Add New BinaryObject Vectorizer for SparseVectors and Integer Coordinates Key: IGNITE-12849 URL: https://issues.apache.org/jira/browse/IGNITE-12849 Project: Ignite Issue Type: New Feature Components: ml Affects Versions: 2.8 Reporter: Glenn Wiebe Fix For: 2.8 A. DenseVector-based BinaryObjectVectorizer When using existing caches as a source of Datasets, the BinaryObjectVectorizer is used. The existing BinaryObjectVectorizer only supports the creation of a SparseVector. The LUDecomposition utility that supports gaussian factorization for models like GMM have a "Singularity indicator" for which a SparseVector and its null handling will set a matrix column calculation to be zero/0.0 which is below the minimum check value (1e-11) and thus indicate a matrix is not square. This null handling of the SparseMatrix will restrict the use of some algorithms like Gaussian Mixture Models where any Vector dimension that is null will incorrectly signal that a matrix is not square. It would be great if we could: - Have a BinaryObjectVectorizer that uses a DenseMatrix to eliminate this singularity trigger and enable use of GMM Trainer. B. CacheBasedDatasets not treated as Temporary Cache When using a cache-based dataset, the close() method destroys the Ignite cache. This means that there is no ability to re-use the data loaded into this dataset. It would be great if we could: - Not destroy the Ignite Cache holding the dataset on close (of one step in an ML processing flow) - Allow for "attaching" to this prior, pre-calculated dataset in subsequent use. C. Vector Visibility Vectors (unlike other value types, e.g. BinaryObjects) are not visible in standard mechanisms, like the Ignite Web Console, where the toString() method does not present any information about the embedded vector values. It would be great if we could: - have a Vector.toString() method implementation that presented some information about what is actually in the Vector. I have implemented the above items and have used them at a customer where I needed these capabilities (or at least it dramatically reduced the cost and increased the value of the solution). It would be great if the community was supportive of this expansion/improvement of the Ignite ML library. Thanks, Glenn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[
https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071981#comment-17071981
]
Ignite TC Bot commented on IGNITE-12710:
{panel:title=Branch: [pull/7461/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5173991]]
* IgnitePdsTestSuite:
IgnitePdsDataRegionMetricsTest.testMemoryUsageMultipleNodes - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5173263buildTypeId=IgniteTests24Java8_RunAll]
> Extension log in rebuild indexes to search problems
> ---
>
> Key: IGNITE-12710
> URL: https://issues.apache.org/jira/browse/IGNITE-12710
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We should have the ability to get extended information about rebuild indexes:
> cache, cache id, cache group, cache group id, index name, index type, index
> size.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12827:
Assignee: (was: Nikolay Izhikov)
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12827:
Assignee: Nikolay Izhikov
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-12827:
Assignee: (was: Nikolay Izhikov)
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12827-vs-2.8.patch
>
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12759) Getting a SecurityContext from GridSecurityProcessor
[ https://issues.apache.org/jira/browse/IGNITE-12759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071813#comment-17071813 ] Denis Garus commented on IGNITE-12759: -- [~ivan.glukos] I've done. Thank you! > Getting a SecurityContext from GridSecurityProcessor > > > Key: IGNITE-12759 > URL: https://issues.apache.org/jira/browse/IGNITE-12759 > Project: Ignite > Issue Type: Improvement > Components: security >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-41 > Time Spent: 1.5h > Remaining Estimate: 0h > > Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID > subjId)_ method and use this method to get the actual security context. > h4. Backward compatibility > The logic of getting security context for Ignite: > # Try to get a security context using _ClusterNode_ attributes (as it works > now); > # Get a security context through _GridSecurityProcessor_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12848) SQL: H2Connection leaks on INSERT
[
https://issues.apache.org/jira/browse/IGNITE-12848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12848:
--
Description:
H2 connection leaks on INSERT query when one row is inserted and not constant
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
*Root cause:*
Query cursor isn't closed at the
{{IgniteH2Indexing#executeUpdateNonTransactional}} after
{{DmlUtils#processSelectResult}}.
was:
H2 connection leaks on INSERT query when one row is inserted and not constant
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
*Root cause:*
Query cursor isn't closed at the IgniteH2Indexing#executeUpdateNonTransactional
after {{DmlUtils#processSelectResult}}.
> SQL: H2Connection leaks on INSERT
> -
>
> Key: IGNITE-12848
> URL: https://issues.apache.org/jira/browse/IGNITE-12848
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.8.1
>
>
> H2 connection leaks on INSERT query when one row is inserted and not constant
> values are used:
> e.g.:
> {{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
> *Root cause:*
> Query cursor isn't closed at the
> {{IgniteH2Indexing#executeUpdateNonTransactional}} after
> {{DmlUtils#processSelectResult}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12848) SQL: H2Connection leaks on INSERT
Taras Ledkov created IGNITE-12848:
-
Summary: SQL: H2Connection leaks on INSERT
Key: IGNITE-12848
URL: https://issues.apache.org/jira/browse/IGNITE-12848
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.8
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.8.1
H2 connection leaks on INSERT query when one row is inserted and not constant
values are used:
e.g.:
{{INSERT INTO T VALUES(1, CURRENT_TIMESTAM());}}
*Root cause:*
Query cursor isn't closed at the IgniteH2Indexing#executeUpdateNonTransactional
after {{DmlUtils#processSelectResult}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071748#comment-17071748 ] Sergey Antonov commented on IGNITE-12710: - [~amashenkov] Fixed. Please take a look again! > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071696#comment-17071696
]
Petr Vanek commented on IGNITE-12809:
-
I can confirm this issue found independently (after few hard hours of debugging)
page size = 1
{code:java}
['rowid', 'Job_Level', 'Country', 'Hired_This_Period', 'Termination_Category',
'Next_Supervisory_Organization', 'Years_Since_Last_Promotion', 'Is_URM',
'Is_New_Hire', 'Active_Status', 'Supervisory_Organization', 'Is_Manager',
'Length_Of_Service_In_Partial_Years', 'Company', 'Ethnicity',
'Promoted_This_Period', 'Terminated_This_Period', 'Location', 'Org_Level_3',
'Direct_Reports', 'Previous_Supervisory_Organization', 'Job_Profile',
'Org_Level_4', 'Org_Level_2', 'Manager_With_Direct_Reports', 'Total',
'Employee_ID', 'Termination_Reason', 'Gender', 'Generation',
'Management_Level', 'Last_Promotion_Date_Not_Null', 'Is_High_Potential',
'High_Performer', 'Cost_Center', 'Super_Org_Changed_This_Period', 'Region',
'Default']
[0, '', '29247e57dbaf46fb855b224e03170bc7', 'False', '', 'foo bar', 0.0,
'False', 'False', 'True', 'e7cec85c883510141fe9675b17071655', 'False', 4.67,
'1fdc602538c0103b356a57fb88e300cd', '', 'False', 'False',
'f5799b99ca2246d9bcf405fbc0a96b1d', '', 0.0, 'foo bar',
'9ffb8c8210d4468ca8dc94190eba3b7d', '', '', 'False', 'Benchmark', '25095', '',
'd3afbf8074e549ffb070962128e1105a', '5f3a7924cc4110001e208ee6e17b0127',
'7a379eea3b0c4a10a2b50663b2bd15e4', 'False', 'False', 'False',
'5acc0ad52f7843b0a4905aa6d30380de', 'False',
'e8a0e6689604438bbd4e47e46ff15025', (datetime.datetime(2019, 6, 1, 2, 0), 0)]
[1, '', 'e7cec85c883510141fe9675b17071655', 'False', 4.67,
'1fdc602538c0103b356a57fb88e300cd', '', 'False', 'False',
'f5799b99ca2246d9bcf405fbc0a96b1d', '', 0.0,
'29247e57dbaf46fb855b224e03170bc7', 'foo bar',
'9ffb8c8210d4468ca8dc94190eba3b7d', '', '', 'False', 'Benchmark', '25094', '',
'9cce3bec2d0d420283f76f51b928d885', '5f3a7924cc4110001e208ee6e17b0127',
'False', '7a379eea3b0c4a10a2b50663b2bd15e4', 'False', 'False', 'False',
'5acc0ad52f7843b0a4905aa6d30380de', 'False',
'e8a0e6689604438bbd4e47e46ff15025', (datetime.datetime(2019, 6, 1, 2, 0), 0),
'', 'foo bar', 0.0, 'False', 'False', 'True']
{code}
correct structure (page size > 2)
{code:java}
['rowid', 'Job_Level', 'Country', 'Hired_This_Period', 'Termination_Category',
'Next_Supervisory_Organization', 'Years_Since_Last_Promotion', 'Is_URM',
'Is_New_Hire', 'Active_Status', 'Supervisory_Organization', 'Is_Manager',
'Length_Of_Service_In_Partial_Years', 'Company', 'Ethnicity',
'Promoted_This_Period', 'Terminated_This_Period', 'Location', 'Org_Level_3',
'Direct_Reports', 'Previous_Supervisory_Organization', 'Job_Profile',
'Org_Level_4', 'Org_Level_2', 'Manager_With_Direct_Reports', 'Total',
'Employee_ID', 'Termination_Reason', 'Gender', 'Generation',
'Management_Level', 'Last_Promotion_Date_Not_Null', 'Is_High_Potential',
'High_Performer', 'Cost_Center', 'Super_Org_Changed_This_Period', 'Region',
'Default']
[0, '', '29247e57dbaf46fb855b224e03170bc7', 'False', '', 'foo bar', 0.0,
'False', 'False', 'True', 'e7cec85c883510141fe9675b17071655', 'False', 4.67,
'1fdc602538c0103b356a57fb88e300cd', '', 'False', 'False',
'f5799b99ca2246d9bcf405fbc0a96b1d', '', 0.0, 'foo bar',
'9ffb8c8210d4468ca8dc94190eba3b7d', '', '', 'False', 'Benchmark', '25095', '',
'd3afbf8074e549ffb070962128e1105a', '5f3a7924cc4110001e208ee6e17b0127',
'7a379eea3b0c4a10a2b50663b2bd15e4', 'False', 'False', 'False',
'5acc0ad52f7843b0a4905aa6d30380de', 'False',
'e8a0e6689604438bbd4e47e46ff15025', (datetime.datetime(2019, 6, 1, 2, 0), 0)]
[1, '', '29247e57dbaf46fb855b224e03170bc7', 'False', '', 'foo bar', 0.0,
'False', 'False', 'True', 'e7cec85c883510141fe9675b17071655', 'False', 4.67,
'1fdc602538c0103b356a57fb88e300cd', '', 'False', 'False',
'f5799b99ca2246d9bcf405fbc0a96b1d', '', 0.0, 'foo bar',
'9ffb8c8210d4468ca8dc94190eba3b7d', '', '', 'False', 'Benchmark', '25094', '',
'9cce3bec2d0d420283f76f51b928d885', '5f3a7924cc4110001e208ee6e17b0127',
'7a379eea3b0c4a10a2b50663b2bd15e4', 'False', 'False', 'False',
'5acc0ad52f7843b0a4905aa6d30380de', 'False',
'e8a0e6689604438bbd4e47e46ff15025', (datetime.datetime(2019, 6, 1, 2, 0),
0)]{code}
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: python
> Attachments: reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then,
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071664#comment-17071664 ] Andrey Mashenkov commented on IGNITE-12710: --- [~antonovsergey93], PR look better, you are on right way. Let's improve it a bit and remove statistic gathering logic (together with rowFilter) from GridCacheMapEntry into SchemaIndexCachePartitionWorker. to make GridCacheMapEntry code as simple as possible. > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12841) @Override must be on the same line as a method
[
https://issues.apache.org/jira/browse/IGNITE-12841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071659#comment-17071659
]
Ignite TC Bot commented on IGNITE-12841:
{panel:title=Branch: [pull/7578/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5170216buildTypeId=IgniteTests24Java8_RunAll]
> @Override must be on the same line as a method
> --
>
> Key: IGNITE-12841
> URL: https://issues.apache.org/jira/browse/IGNITE-12841
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Oleg Ostanin
>Priority: Trivial
> Labels: newbie
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Right now, there are many places where codestyle broken.
> {noformat}
> /** {@inheritDoc} */
> @Override
> public boolean registerClassName(byte platformId, int typeId, String
> clsName) throws IgniteCheckedException {
> return registerClassName(platformId, typeId, clsName, false);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12847) Incorrect query result
[
https://issues.apache.org/jira/browse/IGNITE-12847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Melchakov updated IGNITE-12847:
--
Description:
This two queries should return same result.
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
{code}
and
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND e.deptno IN ( 10, 20, 30 );
{code}
*But in first case there are no results.*
In second case a have this one:
{code:java}
+++---+---+
| DEPTNO | DNAME | EMPNO | ENAME |
+++---+---+
| 10 | ACCOUNTING | 7839 | KING |
+++---+---+
{code}
*This issue is not reproduces on apache ignite 2.7.6*
Example data:
{code:java}
CREATE TABLE dept (deptno LONG,dname VARCHAR,loc VARCHAR,CONSTRAINT pk_dept
PRIMARY KEY (deptno));
CREATE TABLE emp (empno LONG,ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate
DATE,sal LONG,comm LONG,deptno LONG,CONSTRAINT pk_emp PRIMARY KEY (empno));
INSERT INTO dept (deptno, dname, loc) VALUES (10,'ACCOUNTING', 'NEW
YORK');INSERT INTO dept (deptno, dname, loc) VALUES(20,'RESEARCH', 'DALLAS');
INSERT INTO dept (deptno, dname, loc) VALUES(30,'SALES', 'CHICAGO');INSERT INTO
emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7839,'KING','PRESIDENT',NULL,to_date('17-11-1981', 'dd-mm-'),
5000,NULL, 10);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7698,'BLAKE','MANAGER',7839,to_date('1-5-1981', 'dd-mm-'), 2850,
NULL, 30);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7782,'CLARK','MANAGER',7839,to_date('9-6-1981', 'dd-mm-'),
2450,NULL, 10);
{code}
Reproduces both in sqlline.sh and IntelliJ IDEA SQL command console
Command for docker:
{code:java}
docker run -it --name \
-p 47500:47500 \
-p 47501:47501 \
-p 10800:10800 \
-e
"CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml;
apacheignite/ignite:2.8.0
{code}
was:
This two queries should return same result.
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
{code}
and
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND e.deptno IN ( 10, 20, 30 );
{code}
*But in first case there are no results.*
In second case a have this one:
{code:java}
+++---+---+
| DEPTNO | DNAME | EMPNO | ENAME |
+++---+---+
| 10 | ACCOUNTING | 7839 | KING |
+++---+---+
{code}
*This issue is not reproduces on apache ignite 2.7.6*
Example data:
{code:java}
CREATE TABLE dept (deptno LONG,dname VARCHAR,loc VARCHAR,CONSTRAINT pk_dept
PRIMARY KEY (deptno));
CREATE TABLE emp (empno LONG,ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate
DATE,sal LONG,comm LONG,deptno LONG,CONSTRAINT pk_emp PRIMARY KEY (empno));
INSERT INTO dept (deptno, dname, loc) VALUES (10,'ACCOUNTING', 'NEW
YORK');INSERT INTO dept (deptno, dname, loc) VALUES(20,'RESEARCH', 'DALLAS');
INSERT INTO dept (deptno, dname, loc) VALUES(30,'SALES', 'CHICAGO');INSERT INTO
emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7839,'KING','PRESIDENT',NULL,to_date('17-11-1981', 'dd-mm-'),
5000,NULL, 10);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7698,'BLAKE','MANAGER',7839,to_date('1-5-1981', 'dd-mm-'), 2850,
NULL, 30);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7782,'CLARK','MANAGER',7839,to_date('9-6-1981', 'dd-mm-'),
2450,NULL, 10);
{code}
Environment:
apache ignite 2.8.0, docker image: apacheignite/ignite:2.8.0
was:
* apache ignite 2.8.0
* docker image: apacheignite/ignite:2.8.0
* Reproduces both in sqlline.sh and IntelliJ IDEA SQL command console
Command for docker:
{code:java}
docker run -it --name \
-p 47500:47500 \
-p 47501:47501 \
-p 10800:10800 \
-e
"CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml;
apacheignite/ignite:2.8.0
{code}
> Incorrect query result
> ---
>
> Key: IGNITE-12847
> URL: https://issues.apache.org/jira/browse/IGNITE-12847
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
> Environment: apache ignite 2.8.0, docker image:
>
[jira] [Updated] (IGNITE-12847) Incorrect query result
[
https://issues.apache.org/jira/browse/IGNITE-12847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Melchakov updated IGNITE-12847:
--
Description:
This two queries should return same result.
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
{code}
and
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND e.deptno IN ( 10, 20, 30 );
{code}
*But in first case there are no results.*
In second case a have this one:
{code:java}
+++---+---+
| DEPTNO | DNAME | EMPNO | ENAME |
+++---+---+
| 10 | ACCOUNTING | 7839 | KING |
+++---+---+
{code}
*This issue is not reproduces on apache ignite 2.7.6*
Example data:
{code:java}
CREATE TABLE dept (deptno LONG,dname VARCHAR,loc VARCHAR,CONSTRAINT pk_dept
PRIMARY KEY (deptno));
CREATE TABLE emp (empno LONG,ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate
DATE,sal LONG,comm LONG,deptno LONG,CONSTRAINT pk_emp PRIMARY KEY (empno));
INSERT INTO dept (deptno, dname, loc) VALUES (10,'ACCOUNTING', 'NEW
YORK');INSERT INTO dept (deptno, dname, loc) VALUES(20,'RESEARCH', 'DALLAS');
INSERT INTO dept (deptno, dname, loc) VALUES(30,'SALES', 'CHICAGO');INSERT INTO
emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7839,'KING','PRESIDENT',NULL,to_date('17-11-1981', 'dd-mm-'),
5000,NULL, 10);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7698,'BLAKE','MANAGER',7839,to_date('1-5-1981', 'dd-mm-'), 2850,
NULL, 30);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7782,'CLARK','MANAGER',7839,to_date('9-6-1981', 'dd-mm-'),
2450,NULL, 10);
{code}
was:
This two queries should return same result.
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
{code}
and
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND e.deptno IN ( 10, 20, 30 );
{code}
*But in first case there are no results.*
In second case a have this one:
{{+++---+---+}}
{{| DEPTNO | DNAME | EMPNO | ENAME |}}
{{+++---+---+}}
{{| 10 | ACCOUNTING | 7839 | KING |}}
{{+++---+---+}}
*This issue is not reproduces on apache ignite 2.7.6*
Example data:
{code:java}
CREATE TABLE dept (deptno LONG,dname VARCHAR,loc VARCHAR,CONSTRAINT pk_dept
PRIMARY KEY (deptno));
CREATE TABLE emp (empno LONG,ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate
DATE,sal LONG,comm LONG,deptno LONG,CONSTRAINT pk_emp PRIMARY KEY (empno));
INSERT INTO dept (deptno, dname, loc) VALUES (10,'ACCOUNTING', 'NEW
YORK');INSERT INTO dept (deptno, dname, loc) VALUES(20,'RESEARCH', 'DALLAS');
INSERT INTO dept (deptno, dname, loc) VALUES(30,'SALES', 'CHICAGO');INSERT INTO
emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7839,'KING','PRESIDENT',NULL,to_date('17-11-1981', 'dd-mm-'),
5000,NULL, 10);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7698,'BLAKE','MANAGER',7839,to_date('1-5-1981', 'dd-mm-'), 2850,
NULL, 30);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7782,'CLARK','MANAGER',7839,to_date('9-6-1981', 'dd-mm-'),
2450,NULL, 10);
{code}
> Incorrect query result
> ---
>
> Key: IGNITE-12847
> URL: https://issues.apache.org/jira/browse/IGNITE-12847
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
> Environment: * apache ignite 2.8.0
> * docker image: apacheignite/ignite:2.8.0
> * Reproduces both in sqlline.sh and IntelliJ IDEA SQL command console
> Command for docker:
>
> {code:java}
> docker run -it --name \
> -p 47500:47500 \
> -p 47501:47501 \
> -p 10800:10800 \
> -e
> "CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml;
> apacheignite/ignite:2.8.0
> {code}
>
>
>Reporter: Alexey Melchakov
>Priority: Major
>
> This two queries should return same result.
> {code:java}
> SELECT d.deptno, d.dname, e.empno,
> e.ename FROM emp e
> INNER JOIN dept d
> ON ( e.deptno = d.deptno )
> WHERE EXISTS (SELECT 1 FROM emp t
> WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
> {code}
> and
> {code:java}
> SELECT d.deptno, d.dname, e.empno,
> e.ename FROM emp
[jira] [Created] (IGNITE-12847) Incorrect query result
Alexey Melchakov created IGNITE-12847:
-
Summary: Incorrect query result
Key: IGNITE-12847
URL: https://issues.apache.org/jira/browse/IGNITE-12847
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.8
Environment: * apache ignite 2.8.0
* docker image: apacheignite/ignite:2.8.0
* Reproduces both in sqlline.sh and IntelliJ IDEA SQL command console
Command for docker:
{code:java}
docker run -it --name \
-p 47500:47500 \
-p 47501:47501 \
-p 10800:10800 \
-e
"CONFIG_URI=https://raw.githubusercontent.com/apache/ignite/master/examples/config/example-cache.xml;
apacheignite/ignite:2.8.0
{code}
Reporter: Alexey Melchakov
This two queries should return same result.
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND d.deptno IN ( 10, 20, 30 );
{code}
and
{code:java}
SELECT d.deptno, d.dname, e.empno,
e.ename FROM emp e
INNER JOIN dept d
ON ( e.deptno = d.deptno )
WHERE EXISTS (SELECT 1 FROM emp t
WHERE t.mgr = e.empno) AND e.deptno IN ( 10, 20, 30 );
{code}
*But in first case there are no results.*
In second case a have this one:
{{+++---+---+}}
{{| DEPTNO | DNAME | EMPNO | ENAME |}}
{{+++---+---+}}
{{| 10 | ACCOUNTING | 7839 | KING |}}
{{+++---+---+}}
*This issue is not reproduces on apache ignite 2.7.6*
Example data:
{code:java}
CREATE TABLE dept (deptno LONG,dname VARCHAR,loc VARCHAR,CONSTRAINT pk_dept
PRIMARY KEY (deptno));
CREATE TABLE emp (empno LONG,ename VARCHAR, job VARCHAR, mgr INTEGER, hiredate
DATE,sal LONG,comm LONG,deptno LONG,CONSTRAINT pk_emp PRIMARY KEY (empno));
INSERT INTO dept (deptno, dname, loc) VALUES (10,'ACCOUNTING', 'NEW
YORK');INSERT INTO dept (deptno, dname, loc) VALUES(20,'RESEARCH', 'DALLAS');
INSERT INTO dept (deptno, dname, loc) VALUES(30,'SALES', 'CHICAGO');INSERT INTO
emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7839,'KING','PRESIDENT',NULL,to_date('17-11-1981', 'dd-mm-'),
5000,NULL, 10);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7698,'BLAKE','MANAGER',7839,to_date('1-5-1981', 'dd-mm-'), 2850,
NULL, 30);
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno)
VALUES(7782,'CLARK','MANAGER',7839,to_date('9-6-1981', 'dd-mm-'),
2450,NULL, 10);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12844) Too many caches can block discovery
[ https://issues.apache.org/jira/browse/IGNITE-12844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071632#comment-17071632 ] Ivan Bessonov commented on IGNITE-12844: [~fi1ipx] code looks good, thank you! > Too many caches can block discovery > --- > > Key: IGNITE-12844 > URL: https://issues.apache.org/jira/browse/IGNITE-12844 > Project: Ignite > Issue Type: Bug >Reporter: Philipp Masharov >Assignee: Philipp Masharov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Several thousand caches send metrics in each discovery message. > Check implementation of `TcpDiscoveryMetricsUpdateMessage` > This behavior increases processing time and raises message size. As a > result, the discovery worker is busy and the queue pool is growing. > We need to notify about the possible issue and print a suggestion, for > example, `-DIGNITE_DISCOVERY_DISABLE_CACHE_METRICS_UPDATE=true` if it can > help. Assumes to print WARN message once, for example, if > TcpDiscoveryMetricsUpdateMessage consists of more than 500 > CacheMetricsSnaphot instances. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12846) Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description in binary release
Stepan Pilschikov created IGNITE-12846:
--
Summary: Docs: ml package org.apache.ignite.ml.knn.utils.indices
have no description in binary release
Key: IGNITE-12846
URL: https://issues.apache.org/jira/browse/IGNITE-12846
Project: Ignite
Issue Type: Bug
Components: documentation
Affects Versions: 2.8
Reporter: Stepan Pilschikov
apache-ignite-2.8.0-bin/docs/javadoc/overview-summary.html does not contain
description block for org.apache.ignite.ml.knn.utils.indices
Actual:
{code}
org.apache.ignite.ml.knn.utils.indices
{code}
Expected:
{code}
org.apache.ignite.ml.knn.utils.indices
[Some description]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12845) GridNioServer can infinitely lose some events
[
https://issues.apache.org/jira/browse/IGNITE-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071597#comment-17071597
]
Aleksey Plekhanov commented on IGNITE-12845:
[~antonovsergey93], sorry, for JDK 8 it's inside derived class implementation
(KQueueSelectorImpl for Mac OS, for example), but later it was moved to
SelectorImpl (at least since JDK 11)
> GridNioServer can infinitely lose some events
> --
>
> Key: IGNITE-12845
> URL: https://issues.apache.org/jira/browse/IGNITE-12845
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
> {{GridNioServer}} can lose some events for a channel (depending on JDK
> version and OS). It can lead to connected applications hang. Reproducer:
> {code:java}
> public void testConcurrentLoad() throws Exception {
> startGrid(0);
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> GridTestUtils.runMultiThreaded(
> () -> {
> for (int i = 0; i < 1000; i++)
> cache.put(i, i);
> }, 5, "run-async");
> }
> }
> {code}
> This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13,
> 14), hangs on some Linux environments (for example passed more than 100 times
> on desktop Linux system with JDK 8, but hangs on team-city agents with JDK 8,
> 11) and never hanged (passed more than 100 times) on windows system, but
> passes on all systems and JDK versions when system property
> {{IGNITE_NO_SELECTOR_OPTS = true}} is set.
>
> The root cause: optimized {{SelectedSelectionKeySet}} always returns
> {{false}} for {{contains()}} method. The {{contains()}} method used by
> {{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
> {code:java}
> if (selectedKeys.contains(ski)) {
> if (ski.translateAndUpdateReadyOps(rOps)) {
> return 1;
> }
> } else {
> ski.translateAndSetReadyOps(rOps);
> if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
> selectedKeys.add(ski);
> return 1;
> }
> }
> {code}
> So, for fair implementation, if a selection key is contained in the selected
> keys set, then ready operations flags are updated, but for
> {{SelectedSelectionKeySet}} ready operations flags will be always overridden
> and new selector key will be added even if it's already contained in the set.
> Some {{SelectorImpl}} implementations can pass several events for one
> selector key to {{processReadyEvents}} method (for example, MacOs
> implementation {{KQueueSelectorImpl}} works in such a way). In this case,
> duplicated selector keys will be added to {{selectedKeys}} and all events
> except last will be lost.
> Two bad things happen in {{GridNioServer}} due to described above reasons:
> # Some event flags are lost and the worker doesn't process corresponding
> action (for attached reproducer "channel is ready for reading" event is lost
> and the workers never read the channel after some point in time).
> # Duplicated selector keys with the same event flags (for attached
> reproducer it's "channel is ready for writing" event, this duplication leads
> to wrong processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which
> will be {{false}} in some cases, but at the same time selector key's
> {{interestedOps}} will contain {{OP_WRITE}} operation and this operation
> never be excluded)
> Possible solutions:
> * Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
> will solve all problems but can be resource consuming)
> * Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when
> adding {{OP_WRITE}} to {{interestedOps}} (for example in
> {{AbstractNioClientWorker.registerWrite()}} method). In this case, some
> "channel is ready for reading" events (but not data) still can be lost, but
> not infinitely, and eventually data will be read. If events will be reordered
> (first "channel is ready for writing", after it "channel is ready for
> reading") then write to the channel will be only processed after all data
> will be read.
> * Exclude {{OP_WRITE}} from {{interestedOps}} even if
> {{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
> requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
> This solution has the same shortcomings as the previous one.
> * Hybrid approach. Use some probabilistic implementation for {{contains}}
> method (bloom filter or just check the last element) and use one of two
> previous solutions as a workaround, for cases
[jira] [Updated] (IGNITE-12845) GridNioServer can infinitely lose some events
[
https://issues.apache.org/jira/browse/IGNITE-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12845:
---
Description:
With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
{{GridNioServer}} can lose some events for a channel (depending on JDK version
and OS). It can lead to connected applications hang. Reproducer:
{code:java}
public void testConcurrentLoad() throws Exception {
startGrid(0);
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
GridTestUtils.runMultiThreaded(
() -> {
for (int i = 0; i < 1000; i++)
cache.put(i, i);
}, 5, "run-async");
}
}
{code}
This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13, 14),
hangs on some Linux environments (for example passed more than 100 times on
desktop Linux system with JDK 8, but hangs on team-city agents with JDK 8, 11)
and never hanged (passed more than 100 times) on windows system, but passes on
all systems and JDK versions when system property {{IGNITE_NO_SELECTOR_OPTS =
true}} is set.
The root cause: optimized {{SelectedSelectionKeySet}} always returns {{false}}
for {{contains()}} method. The {{contains()}} method used by
{{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
{code:java}
if (selectedKeys.contains(ski)) {
if (ski.translateAndUpdateReadyOps(rOps)) {
return 1;
}
} else {
ski.translateAndSetReadyOps(rOps);
if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
selectedKeys.add(ski);
return 1;
}
}
{code}
So, for fair implementation, if a selection key is contained in the selected
keys set, then ready operations flags are updated, but for
{{SelectedSelectionKeySet}} ready operations flags will be always overridden
and new selector key will be added even if it's already contained in the set.
Some {{SelectorImpl}} implementations can pass several events for one selector
key to {{processReadyEvents}} method (for example, MacOs implementation
{{KQueueSelectorImpl}} works in such a way). In this case, duplicated selector
keys will be added to {{selectedKeys}} and all events except last will be lost.
Two bad things happen in {{GridNioServer}} due to described above reasons:
# Some event flags are lost and the worker doesn't process corresponding
action (for attached reproducer "channel is ready for reading" event is lost
and the workers never read the channel after some point in time).
# Duplicated selector keys with the same event flags (for attached reproducer
it's "channel is ready for writing" event, this duplication leads to wrong
processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which will be
{{false}} in some cases, but at the same time selector key's {{interestedOps}}
will contain {{OP_WRITE}} operation and this operation never be excluded)
Possible solutions:
* Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
will solve all problems but can be resource consuming)
* Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when adding
{{OP_WRITE}} to {{interestedOps}} (for example in
{{AbstractNioClientWorker.registerWrite()}} method). In this case, some
"channel is ready for reading" events (but not data) still can be lost, but not
infinitely, and eventually data will be read. If events will be reordered
(first "channel is ready for writing", after it "channel is ready for reading")
then write to the channel will be only processed after all data will be read.
* Exclude {{OP_WRITE}} from {{interestedOps}} even if
{{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
This solution has the same shortcomings as the previous one.
* Hybrid approach. Use some probabilistic implementation for {{contains}}
method (bloom filter or just check the last element) and use one of two
previous solutions as a workaround, for cases when we incorrectly return
{{false}} for {{contains}}.
was:
With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
{{GridNioServer}} can lose some events for a channel (depending on JDK version
and OS). It can lead to connected applications hang. Reproducer:
{code:java}
public void testConcurrentLoad() throws Exception {
startGrid(0);
try (IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
ClientCache cache =
client.getOrCreateCache(DEFAULT_CACHE_NAME);
GridTestUtils.runMultiThreaded(
() -> {
for (int i = 0; i < 1000; i++)
[jira] [Commented] (IGNITE-12845) GridNioServer can infinitely lose some events
[
https://issues.apache.org/jira/browse/IGNITE-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071590#comment-17071590
]
Sergey Antonov commented on IGNITE-12845:
-
[~alex_pl] I didn't find any {{Set#contains(Object)}} usages in
{{sun.nio.ch.SelectorImpl}} in jdk8 (1.8.0_191).
> GridNioServer can infinitely lose some events
> --
>
> Key: IGNITE-12845
> URL: https://issues.apache.org/jira/browse/IGNITE-12845
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
> {{GridNioServer}} can lose some events for a channel (depending on JDK
> version and OS). It can lead to connected applications hang. Reproducer:
> {code:java}
> public void testConcurrentLoad() throws Exception {
> startGrid(0);
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> GridTestUtils.runMultiThreaded(
> () -> {
> for (int i = 0; i < 1000; i++)
> cache.put(i, i);
> }, 5, "run-async");
> }
> }
> {code}
> This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13,
> 14), hangs on some Linux environments (for example passed more than 100 times
> on desktop Linux system with JDK 8, but hangs on team-city agents with JDK 8,
> 11) and never hanged (passed more than 100 times) on windows system, but
> passes on all systems and JDK versions when system property
> {{IGNITE_NO_SELECTOR_OPTS = true}} is set.
>
> The root cause: optimized {{SelectedSelectionKeySet}} always returns
> {{false}} for {{contains()}} method. The {{contains()}} method used by
> {{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
> {code:java}
> if (selectedKeys.contains(ski)) {
> if (ski.translateAndUpdateReadyOps(rOps)) {
> return 1;
> }
> } else {
> ski.translateAndSetReadyOps(rOps);
> if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
> selectedKeys.add(ski);
> return 1;
> }
> }
> {code}
> So, for fair implementation, if a selection key is contained in the selected
> keys set, then ready operations flags are updated, but for
> {{SelectedSelectionKeySet}} ready operations flags will be always overridden
> and new selector key will be added even if it's already contained in the set.
> Some {{SelectorImpl}} implementations can pass several events for one
> selector key to {{processReadyEvents}} method (for example, MacOs
> implementation {{KQueueSelectorImpl}} works in such a way). In this case,
> duplicated selector keys will be added to {{selectedKeys}} and all events
> except last will be lost.
> Two bad things happen in {{GridNioServer}} due to described above reasons:
> # Some event flags are lost and the worker doesn't process corresponding
> action (for attached reproducer "channel is ready for reading" event is lost
> and the workers never read the channel after some point in time).
> # Duplicated selector keys with the same event flags (for attached
> reproducer it's "channel is ready for writing" event, this duplication leads
> to wrong processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which
> will be {{false}} in some cases, but at the same time selector key's
> {{interestedOps}} will contain {{OP_WRITE}} operation and this operation
> never be excluded)
> Possible solutions:
> * Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
> will solve all problems but can be resource consuming)
> * Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when
> adding {{OP_WRITE}} to {{interestedOps}} (for example in
> {{AbstractNioClientWorker.registerWrite()}} method). In this case, some
> "channel is ready for reading" events (but not data) still can be lost, but
> not infinitely, and eventually data will be read.
> * Exclude {{OP_WRITE}} from {{interestedOps}} even if
> {{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
> requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
> This solution has the same shortcomings as the previous one.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled
[
https://issues.apache.org/jira/browse/IGNITE-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071588#comment-17071588
]
Anton Vinogradov commented on IGNITE-12739:
---
[~vladsz83],
Some comments
1) {{grid(0).cache("tx") and grid(1).cache("tx")}} should be always used via
variables.
2) {{cache = grid(0).cache("tx"); cache = grid(1).cache("tx");}}
Variables should be final. Lets name them cache0 and cache1.
3) {{assertEquals(2, grid(1).cache("tx").get(key)); assertEquals(2,
grid(0).cache("tx").get(key));}}
Lets just check each node.
4) We should also test/fix getAll (GridPartitionedGetFuture case).
5)
{noformat}
if (forcePrimary)
affNodes = Collections.singletonList(affNodes.get(0));
ClusterNode affNode = cctx.selectAffinityNodeBalanced(affNodes,
getInvalidNodes(), part, canRemap);
{noformat}
See no reason to perform selectAffinityNodeBalanced when forcePrimary.
Better to set affNode via "forcePrimary ? ... : ...".
> Optimistic serializable transactions may fail infinitely when read-through is
> enabled
> -
>
> Key: IGNITE-12739
> URL: https://issues.apache.org/jira/browse/IGNITE-12739
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Attachments: ReplicatedOptimisticTxTest.java
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In current design it is possible that the same key-value pair will be stored
> with different versions on primary and backup nodes. For example, a
> read-through is invoked separately on primary backup and values are stored
> with node local version.
> With this precondition, if an optimistic serializable transaction is started
> from a backup node, the serializable check version is read from backup, but
> validated on primary node, which will fail the transaction with optimistic
> read/write conflict exception until the versions are overwritten to the same
> value (for example, via a pessimistic transaction).
> While we need to additionally investigate whether we want to change the
> read-through logic to ensure the same value and version on all nodes, this
> particular scenario should be fixed by always enforcing reading from a
> primary node inside an optimistic serializable transaction.
> The reproducer is attached. A known workaround is to disable read load
> balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12828) Intermittent [Failed to notify direct custom event listener] exception on node shutdown
[
https://issues.apache.org/jira/browse/IGNITE-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PetrovMikhail reassigned IGNITE-12828:
--
Assignee: PetrovMikhail (was: Ilya Shishkov)
> Intermittent [Failed to notify direct custom event listener] exception on
> node shutdown
> ---
>
> Key: IGNITE-12828
> URL: https://issues.apache.org/jira/browse/IGNITE-12828
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: PetrovMikhail
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12828-vs-2.8.patch
>
>
> +*Reproducer*+:
> Run a server node
> Run a client node that:
> * Creates cache "cache1"
> * Deploys a grid service that starts a continuous query against "cache1" in
> method init()
> * Leaves the cluster
> +*Actual result*+
> Intermittent exception in the client node:
> {noformat}
> [16:54:38,758][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
> Failed to notify direct custom event listener: StartRoutineDiscoveryMessage
> [startReqData=StartRequestData
> [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@63ae71a9,
> clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler
> [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@594bf5b8,
> cacheName=CALC_REQUESTS, rmtFilter=null, rmtFilterDep=null, internal=false,
> notifyExisting=false, oldValRequired=true, sync=false, ignoreExpired=true,
> taskHash=0, skipPrimaryCheck=false, locOnly=false, keepBinary=true,
> ackBuf=null, cacheId=-1608655250, initTopVer=null, nodeLeft=false,
> ignoreClsNotFound=false, nodeId=null, routineId=null], bufSize=1, interval=0,
> autoUnsubscribe=true], keepBinary=true,
> routineId=021dd2ce-3d8a-41c1-a4d0-b625ea1284f4]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
> at
> org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1424)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$400(GridContinuousProcessor.java:110)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:202)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$2.onCustomEvent(GridContinuousProcessor.java:193)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:722)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:601)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2683)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2721)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:745)
> [16:54:39,725][SEVERE][disco-notifier-worker-#43%CashFlowCluster_16b67e98563f4cfbac95ae055a00e67f%][GridDiscoveryManager]
> Failed to notify direct custom event listener: StartRoutineDiscoveryMessage
> [startReqData=StartRequestData
> [prjPred=sbt.cashflow.grid.services.cachefactory.ignite.NodeAttributeFilter@7462c96c,
> clsName=null, depInfo=null, hnd=CacheContinuousQueryHandler
> [returnValTrans=o.a.i.i.processors.cache.query.continuous.CacheContinuousQueryHandler$1@6451dd70,
> cacheName=DISTRIBUTED_REQUESTS, rmtFilter=null, rmtFilterDep=null,
> internal=false, notifyExisting=false, oldValRequired=true, sync=false,
> ignoreExpired=true, taskHash=0, skipPrimaryCheck=false, locOnly=false,
> keepBinary=true, ackBuf=null, cacheId=1419803136, initTopVer=null,
> nodeLeft=false, ignoreClsNotFound=false, nodeId=null, routineId=null],
> bufSize=1, interval=0, autoUnsubscribe=true], keepBinary=true,
> routineId=1fca5f04-d220-49ac-850a-0d4527e22eef]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:82)
> at
> org.apache.ignite.internal.processors.continuous.StartRoutineDiscoveryMessage.addUpdateCounters(StartRoutineDiscoveryMessage.java:96)
> at
>
[jira] [Comment Edited] (IGNITE-12809) Python client returns fields in wrong order since the 2 row when fields_count>10
[
https://issues.apache.org/jira/browse/IGNITE-12809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070795#comment-17070795
]
Stanilovsky Evgeny edited comment on IGNITE-12809 at 3/31/20, 7:23 AM:
---
[~oleg-ostanin] [~oleg-a-ostanin] hello, may be you can check it ? I spend some
time and looks like [~ezhuravl] approach correct.
was (Author: zstan):
[~oleg-ostanin] hello, may be you can check it ? I spend some time and looks
like [~ezhuravl] approach correct.
> Python client returns fields in wrong order since the 2 row when
> fields_count>10
>
>
> Key: IGNITE-12809
> URL: https://issues.apache.org/jira/browse/IGNITE-12809
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: python
> Attachments: reproducer.py
>
>
> Reproducer attached.
> If result set is bigger than a page size(1 by default) and there are more
> than 10 fields in an object, then, for all rows after the first query column
> order will be wrong. Looks like column order is being sorted as a string
> instead of number.
> The reason for that is a sorting in api/sql.py:
> https://github.com/apache/ignite/blob/master/modules/platforms/python/pyignite/api/sql.py#L445
> If you remove it, everything will work fine. We need to make sure that this
> is the right solution for this issue.
> Output from reproducer:
> {code:java}
> ['CODE', 'NAME', 'CONTINENT', 'REGION', 'SURFACEAREA', 'INDEPYEAR',
> 'POPULATION', 'LIFEEXPECTANCY', 'GNP', 'GNPOLD', 'LOCALNAME',
> 'GOVERNMENTFORM', 'HEADOFSTATE', 'CAPITAL', 'CODE2']
> ['CHN', 'China', 'Asia', 'Eastern Asia', Decimal('9.5729E+6'), -1523,
> 1277558000, Decimal('71.4'), Decimal('982268'), Decimal('917719'),
> 'Zhongquo', 'PeoplesRepublic', 'Jiang Zemin', 1891, 'CN']
> ['IND', 'India', 'Bharat/India', 'Federal Republic', 'Kocheril Raman
> Narayanan', 1109, 'IN', 'Asia', 'Southern and Central Asia',
> Decimal('3287263'), 1947, 1013662000, Decimal('62.5'), Decimal('447114'),
> Decimal('430572')]
> ['USA', 'United States', 'United States', 'Federal Republic', 'George W.
> Bush', 3813, 'US', 'North America', 'North America', Decimal('9.36352E+6'),
> 1776, 278357000, Decimal('77.1'), Decimal('8.5107E+6'), Decimal('8.1109E+6')]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12813) [IEP-39] Management API to cancel scan queries.
[ https://issues.apache.org/jira/browse/IGNITE-12813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-12813: Assignee: Nikolay Izhikov > [IEP-39] Management API to cancel scan queries. > --- > > Key: IGNITE-12813 > URL: https://issues.apache.org/jira/browse/IGNITE-12813 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-39 > > Ignite provides many API to deploy and execute user-provided code on the > server nodes inside the same JVM as the Ignite process runs. > Ignite has many APIs that allocate many resources on the server nodes, also. > In case of some buggy code that consumes many system resources(CPU, RAM, > flood network) or heavy query the whole cluster can become unstable. > We should provide to the cluster administrator the ability to stop any user > deployed task. > JMX beans to cancel listed tasks should be introduced: > * scan queries > In the scope of IEP-35 System view API introduced. > A new API should use the same identifier that is used in corresponding System > View. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12815) [IEP-39] Management API to cancel SQL queries.
[
https://issues.apache.org/jira/browse/IGNITE-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071494#comment-17071494
]
Ignite TC Bot commented on IGNITE-12815:
{panel:title=Branch: [pull/7580/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5170338buildTypeId=IgniteTests24Java8_RunAll]
> [IEP-39] Management API to cancel SQL queries.
> --
>
> Key: IGNITE-12815
> URL: https://issues.apache.org/jira/browse/IGNITE-12815
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-39
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Ignite provides many API to deploy and execute user-provided code on the
> server nodes inside the same JVM as the Ignite process runs.
> Ignite has many APIs that allocate many resources on the server nodes, also.
> In case of some buggy code that consumes many system resources(CPU, RAM,
> flood network) or heavy query the whole cluster can become unstable.
> We should provide to the cluster administrator the ability to stop any user
> deployed task.
> JMX beans to cancel listed tasks should be introduced:
> * SQL queries.
> In the scope of IEP-35 System view API introduced.
> A new API should use the same identifier that is used in corresponding System
> View.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
