[jira] [Commented] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
[ https://issues.apache.org/jira/browse/IGNITE-12883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080260#comment-17080260 ] Pavel Tupitsyn commented on IGNITE-12883: - [~isapego] please review > .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental > - > > Key: IGNITE-12883 > URL: https://issues.apache.org/jira/browse/IGNITE-12883 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > PlatformNearCache is not actually "Near" - it just mirrors cache entries that > are present on current node in CLR heap for faster access. Those entries can > be primary, backup, or near. > PlatformCache seems to be a better name. > Rename: > * `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` > * `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` > * `CacheConfiguration.PlatformNearConfiguration` -> > `CacheConfiguration.PlatformCacheConfiguration` > Mark all new platform (near) cache APIs with `[IgniteExperimental]` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
[ https://issues.apache.org/jira/browse/IGNITE-12883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12883: Description: PlatformNearCache is not actually "Near" - it just mirrors cache entries that are present on current node in CLR heap for faster access. Those entries can be primary, backup, or near. PlatformCache seems to be a better name. Rename: * `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` * `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` * `CacheConfiguration.PlatformNearConfiguration` -> `CacheConfiguration.PlatformCacheConfiguration` Mark all new platform (near) cache APIs with `[IgniteExperimental]` was: PlatformNearCache is not actually "Near" - it just mirrors cache entries that are present on current node in CLR heap for faster access. Those entries can be primary, backup, or near. PlatformCache seems to be a better name. Rename: `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` `CacheConfiguration.PlatformNearConfiguration` -> `CacheConfiguration.PlatformCacheConfiguration` Mark all new platform (near) cache APIs with `[IgniteExperimental]` > .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental > - > > Key: IGNITE-12883 > URL: https://issues.apache.org/jira/browse/IGNITE-12883 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > PlatformNearCache is not actually "Near" - it just mirrors cache entries that > are present on current node in CLR heap for faster access. Those entries can > be primary, backup, or near. > PlatformCache seems to be a better name. > Rename: > * `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` > * `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` > * `CacheConfiguration.PlatformNearConfiguration` -> > `CacheConfiguration.PlatformCacheConfiguration` > Mark all new platform (near) cache APIs with `[IgniteExperimental]` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[ https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080244#comment-17080244 ] Pavel Tupitsyn commented on IGNITE-12882: - Merged to master: e0a846cb7cde548e3d8d625c8c1159adf3968f30 > .NET: Serve local Scan queries directly from platform near cache > > > Key: IGNITE-12882 > URL: https://issues.apache.org/jira/browse/IGNITE-12882 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Scan queries with Local flag and non-null Partition can be executed directly > against Platform Near Cache, avoiding Java calls. > Partition must be reserved before iteration to guarantee that it is local and > does not move away while we iterate. Failed reservation should cause an > exception - can’t do a local query for a non-local partition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[
https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12882:
Comment: was deleted
(was: {panel:title=Branch: [pull/7653/head] Base: [master] : Possible Blockers
(113)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207953]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207992]]
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208018]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208002]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208006]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207982]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207952]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207981]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207983]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207944]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207951]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208003]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207925]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207949]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207956]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207967]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207978]]
{color:#d04437}Platform .NET{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207998]]
{color:#d04437}Start Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207943]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208004]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207942]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207958]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207994]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207962]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207999]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208022]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208012]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207936]]
{color:#d04437}Thin Client: Java{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207935]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207984]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207939]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207977]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208024]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207988]]
{color:#d04437}Basic 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207957]]
{color:#d04437}MVCC PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208021]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207987]]
{color:#d04437}MVCC Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208016]]
{color:#d04437}Cache 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207979]]
{color:#d04437}ZooKeeper
[jira] [Commented] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[
https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17080162#comment-17080162
]
Ignite TC Bot commented on IGNITE-12882:
{panel:title=Branch: [pull/7653/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5209247]]
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5209236]]
* IgniteCacheTestSuite5:
IgniteCacheGroupsPartitionLossPolicySelfTest.testReadWriteAll - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5209267]]
{color:#d04437}Cache 3{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5209234]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheInterceptorTransactionalRebalanceTest.testRebalanceUpdate - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheInterceptorTransactionalRebalanceTest.testGetAndPut - 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=5209283buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Serve local Scan queries directly from platform near cache
>
>
> Key: IGNITE-12882
> URL: https://issues.apache.org/jira/browse/IGNITE-12882
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Scan queries with Local flag and non-null Partition can be executed directly
> against Platform Near Cache, avoiding Java calls.
> Partition must be reserved before iteration to guarantee that it is local and
> does not move away while we iterate. Failed reservation should cause an
> exception - can’t do a local query for a non-local partition.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li reassigned IGNITE-12852: - Assignee: YuJue Li > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.8.1 > > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[
https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079960#comment-17079960
]
Ignite TC Bot commented on IGNITE-12882:
{panel:title=Branch: [pull/7653/head] Base: [master] : Possible Blockers
(113)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207953]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207992]]
{color:#d04437}MVCC Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208018]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208002]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208006]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207982]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207952]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207981]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207983]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207944]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207951]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208003]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207925]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207949]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207956]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207967]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207978]]
{color:#d04437}Platform .NET{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207998]]
{color:#d04437}Start Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207943]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208004]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207942]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207958]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207994]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207962]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207999]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208022]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208012]]
{color:#d04437}JDBC Driver{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207936]]
{color:#d04437}Thin Client: Java{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207935]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207984]]
{color:#d04437}Queries 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207939]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207977]]
{color:#d04437}MVCC PDS 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208024]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207988]]
{color:#d04437}Basic 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207957]]
{color:#d04437}MVCC PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208021]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207987]]
{color:#d04437}MVCC Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5208016]]
{color:#d04437}Cache 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=5207979]]
[jira] [Created] (IGNITE-12883) .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental
Pavel Tupitsyn created IGNITE-12883: --- Summary: .NET: Rename PlatformNearCache to PlatformCache, mark as Experimental Key: IGNITE-12883 URL: https://issues.apache.org/jira/browse/IGNITE-12883 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.9 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.9 PlatformNearCache is not actually "Near" - it just mirrors cache entries that are present on current node in CLR heap for faster access. Those entries can be primary, backup, or near. PlatformCache seems to be a better name. Rename: `PlatformNearCacheConfiguration` -> `PlatformCacheConfiguration` `CachePeekMode.PlatformNear` -> `CachePeekMode.Platform` `CacheConfiguration.PlatformNearConfiguration` -> `CacheConfiguration.PlatformCacheConfiguration` Mark all new platform (near) cache APIs with `[IgniteExperimental]` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[ https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079636#comment-17079636 ] Igor Sapego commented on IGNITE-12882: -- [~ptupitsyn] Looks good to me. > .NET: Serve local Scan queries directly from platform near cache > > > Key: IGNITE-12882 > URL: https://issues.apache.org/jira/browse/IGNITE-12882 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Scan queries with Local flag and non-null Partition can be executed directly > against Platform Near Cache, avoiding Java calls. > Partition must be reserved before iteration to guarantee that it is local and > does not move away while we iterate. Failed reservation should cause an > exception - can’t do a local query for a non-local partition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
[ https://issues.apache.org/jira/browse/IGNITE-12882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079632#comment-17079632 ] Pavel Tupitsyn commented on IGNITE-12882: - [~isapego] PR ready, please review > .NET: Serve local Scan queries directly from platform near cache > > > Key: IGNITE-12882 > URL: https://issues.apache.org/jira/browse/IGNITE-12882 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.9 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Scan queries with Local flag and non-null Partition can be executed directly > against Platform Near Cache, avoiding Java calls. > Partition must be reserved before iteration to guarantee that it is local and > does not move away while we iterate. Failed reservation should cause an > exception - can’t do a local query for a non-local partition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12882) .NET: Serve local Scan queries directly from platform near cache
Pavel Tupitsyn created IGNITE-12882: --- Summary: .NET: Serve local Scan queries directly from platform near cache Key: IGNITE-12882 URL: https://issues.apache.org/jira/browse/IGNITE-12882 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.9 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.9 Scan queries with Local flag and non-null Partition can be executed directly against Platform Near Cache, avoiding Java calls. Partition must be reserved before iteration to guarantee that it is local and does not move away while we iterate. Failed reservation should cause an exception - can’t do a local query for a non-local partition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-7369) .NET: Thin client: Transactions
[ https://issues.apache.org/jira/browse/IGNITE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Stronchinskiy reassigned IGNITE-7369: Assignee: Sergey Stronchinskiy (was: Pavel Tupitsyn) > .NET: Thin client: Transactions > --- > > Key: IGNITE-7369 > URL: https://issues.apache.org/jira/browse/IGNITE-7369 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Sergey Stronchinskiy >Priority: Major > Labels: .NET, iep-34 > Fix For: 2.9 > > > Implement transactions in thin client protocol and .NET thin client. > Main issue: Ignite transactions are tied to a specific thread. > See how JDBC works around this by starting a dedicated thread. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12670) .NET: Calculate IAffinity.GetPartition locally for default affinity
[ https://issues.apache.org/jira/browse/IGNITE-12670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12670: Description: For default affinity we already know how to calculate partition on .NET side, see `ClientRendezvousAffinityFunction`. This is faster than serializing the key and calling Java. (was: For default affinity we already know how to calculate partition on .NET side, see `ClientRendezvousAffinityFunction`. This is faster than serializing the key and calling Java. Aside from other things, Near Cache depends on GetPartition for some use cases, so that will get faster too.) > .NET: Calculate IAffinity.GetPartition locally for default affinity > --- > > Key: IGNITE-12670 > URL: https://issues.apache.org/jira/browse/IGNITE-12670 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > For default affinity we already know how to calculate partition on .NET side, > see `ClientRendezvousAffinityFunction`. This is faster than serializing the > key and calling Java. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12807) Key and Value fields with same name and SQL DML
[
https://issues.apache.org/jira/browse/IGNITE-12807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12807:
--
Description:
Key/Value API allows both the Key and Value have fields with same name. This is
a very popular arrangement since most users are ready to sacrifice extra memory
footprint for the sake of having a self-sufficient value entity.
Using SQL DML to update such an entry will update only the key field, leaving
the value field unchanged. This is a huge usability issue for the mixed K/V and
SQL API apps.
h1. Proposal
h2. Requirements
h3. Example Data Model
Consider a business domain entity *Person \{ id: int, passportNo: String, name:
String }*
When designing an Ignite app the development team decided to map the Person
entity to Ignite data model as:
* *PersonKey \{ id: int, passportNo: String }*
* *Person \{ passportNo: String, name: String }*
h3. Public API
* *Cache API*: add new method {{setKeyValueFields(keyValueFields:
Set): QueryEntity}} to {{QueryEntity}}
** The method marks Cache API Key and Entity fields that SQL API must
initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
** It is still possible to use Cache API to initialize the fields marked with
{{setKeyValueFields}} to different values. SQL SELECT statement returns value
of such a field from the Key entity.
** The method accepts a set of field names and returns the declaring class
instance for chaining.
** The method throws {{ArgumentException}} if the Key and Value types are
available and the field types are different within the Key and Value entities.
* *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}}
statement's additional parameters list.
** The parameter'value is a space-separated list of field names with the
semantics equivalent to that of the {{setKeyValueFields}} method described
above.
** The parameter can be specified only if both the {{KEY_TYPE}} and
{{VALUE_TYPE}} parameters are specified
h3. Use Cases
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in QueryEntity-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:java}
new CacheConfiguration("CACHE")
.setQueryEntities(Collections.singleton(
new QueryEntity(PersonKey.class, Person.class)
.addQueryField("id", int.class.getName(), null)
.addQueryField("passportNo", String.class.getName(), null)
.addQueryField("name", String.class.getName(), null)
.setKeyFields(Collections.singleton("id"))
.setKeyValueFields(Collections.singleton("passportNo"))
));
{code}
** AND the user runs this SQL statement to insert an entry to the cache:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in QueryEntity-Defined Cache
* GIVEN a Person cache from the previous use case
** AND the user adds an entry with different passportNo field values to the
cache:
{code:java}
final PersonKey K = new PersonKey(1, "1");
final Person V = new Person("2", "Name1");
cache.put(K, V);
{code}
* WHEN the user runs this SQL to get the enty:
{code:sql}
SELECT ID, PASSPORTNO, NAME FROM " + CACHE.Person {code}
* THEN the retrieved PASSPORTNO is that of the Key: "1"
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in SQL-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:sql}
CREATE TABLE Person (
id int,
passportNo varchar,
name varchar,
PRIMARY KEY(id, passportNo)
) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
{code}
** AND the user runs this SQL statement to insert an entry to the cache:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in SQL-Defined Cache
* GIVEN a Person cache from the previous use case
** AND the user adds an entry with different passportNo field values to the
cache:
{code:java}
[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] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[
https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079478#comment-17079478
]
Dmitriy Sorokin commented on IGNITE-12764:
--
[~tledkov-gridgain], I don't mind fixing the code style at the
{{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}, but I don’t quite understand
what you mean? Can you assist to me by marking the wrong code points on last
commit
[5c9db78|https://github.com/apache/ignite/pull/7615/commits/5c9db786a46e783f22eefc4b93952de5dfcdf725]?
> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly
> here. Column type does not matter between UUID and VARCHAR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7609) .NET: FieldsQueryCursor should expose data types too
[
https://issues.apache.org/jira/browse/IGNITE-7609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079438#comment-17079438
]
Sergey Stronchinskiy commented on IGNITE-7609:
--
[~ptupitsyn], Thank you!
> .NET: FieldsQueryCursor should expose data types too
>
>
> Key: IGNITE-7609
> URL: https://issues.apache.org/jira/browse/IGNITE-7609
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> See IGNITE-7607 for Java, add same thing to .NET:
> {code}
> public interface IFieldsQueryCursor
> {
> ...
> IList FieldTypes
> }
> {code}
> T could be string or Type, needs investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079410#comment-17079410 ] Pavel Tupitsyn commented on IGNITE-12825: - Breaking change - moved to 3.0 > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12879) Refactor test configuration of discovery messages interceptors.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Description:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It will help to clarify the purpose of the methods.
It's needed to add the ability to configure multiple DiscoveryHook instances
through TestTcpDiscoverySpi for discovery messages interception. It helps to
avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
current approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
was:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It helps to clarify the purpose of the methods.
It's needed to add the ability to configure multiple DiscoveryHook instances
through TestTcpDiscoverySpi for discovery messages interception. It helps to
avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
current approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
> Refactor test configuration of discovery messages interceptors.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It will help to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12825: Fix Version/s: 3.0 > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, sbcf > Fix For: 3.0 > > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7609) .NET: FieldsQueryCursor should expose data types too
[
https://issues.apache.org/jira/browse/IGNITE-7609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-7609:
---
Fix Version/s: 2.9
> .NET: FieldsQueryCursor should expose data types too
>
>
> Key: IGNITE-7609
> URL: https://issues.apache.org/jira/browse/IGNITE-7609
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> See IGNITE-7607 for Java, add same thing to .NET:
> {code}
> public interface IFieldsQueryCursor
> {
> ...
> IList FieldTypes
> }
> {code}
> T could be string or Type, needs investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7609) .NET: FieldsQueryCursor should expose data types too
[
https://issues.apache.org/jira/browse/IGNITE-7609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079408#comment-17079408
]
Pavel Tupitsyn commented on IGNITE-7609:
[~GuruStron] looks good to me. Merged to master:
6e0b1f6577a011e194295b110869acc4534ac5af
> .NET: FieldsQueryCursor should expose data types too
>
>
> Key: IGNITE-7609
> URL: https://issues.apache.org/jira/browse/IGNITE-7609
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Major
> Labels: .NET
> Time Spent: 3h
> Remaining Estimate: 0h
>
> See IGNITE-7607 for Java, add same thing to .NET:
> {code}
> public interface IFieldsQueryCursor
> {
> ...
> IList FieldTypes
> }
> {code}
> T could be string or Type, needs investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12879) Refactor test configuration of discovery messages interceptors.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Summary: Refactor test configuration of discovery messages interceptors.
(was: Refactor test configuration of discovery messages interception.)
> Refactor test configuration of discovery messages interceptors.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It helps to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12879) Refactor test configuration of discovery messages interception.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Summary: Refactor test configuration of discovery messages interception.
(was: Refactor test discovery messages interception configuration.)
> Refactor test configuration of discovery messages interception.
> ---
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It helps to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[ https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-12875: --- Description: Current "EVT_CLUSTER_STATE" event is propagated only when transition is finished, but it's impossible to track the start of "state transition". For example, it makes no sense to invoke "deactivate" while someone else is invoking "read_only" state transition at the same time. Also this events might be useful for custom tools to monitor state of the cluster and have more information about it. > Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event > -- > > Key: IGNITE-12875 > URL: https://issues.apache.org/jira/browse/IGNITE-12875 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Current "EVT_CLUSTER_STATE" event is propagated only when transition is > finished, but it's impossible to track the start of "state transition". > For example, it makes no sense to invoke "deactivate" while someone else is > invoking "read_only" state transition at the same time. > Also this events might be useful for custom tools to monitor state of the > cluster and have more information about it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12881) Add test discovery messages interception configuration through TestTcpDiscoverySpi.
[
https://issues.apache.org/jira/browse/IGNITE-12881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov resolved IGNITE-12881.
-
Resolution: Won't Fix
> Add test discovery messages interception configuration through
> TestTcpDiscoverySpi.
> ---
>
> Key: IGNITE-12881
> URL: https://issues.apache.org/jira/browse/IGNITE-12881
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12760) Prevent AssertionError on message unmarshalling, when classLoaderId contains id of node that already left
[
https://issues.apache.org/jira/browse/IGNITE-12760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12760:
--
Ignite Flags: (was: Release Notes Required)
> Prevent AssertionError on message unmarshalling, when classLoaderId contains
> id of node that already left
> -
>
> Key: IGNITE-12760
> URL: https://issues.apache.org/jira/browse/IGNITE-12760
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following assertion error triggers failure handler and crashes the node. Can
> possibly crash the whole cluster.
> {code:java}
> 2020-02-18
> 14:34:09.775\[ERROR]\[query-#146129%DPL_GRID%DplGridNodeName%]\[o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message \[senderId=727757ed-4ad4-4779-bda9-081525725cce,
> msg=GridCacheQueryRequest \[id=178,
> cacheName=com.sbt.tokenization.data.entity.KEKEntity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=727757ed-4ad4-4779-bda9-081525725cce, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion \[topVer=97, minorTopVer=0], sendTimestamp=-1,
> receiveTimestamp=-1, super=GridCacheIdMessage \[cacheId=-1129073400,
> super=GridCacheMessage \[msgId=179, depInfo=GridDeploymentInfoBean
> \[clsLdrId=c32670e3071-d30ee64b-0833-45d4-abbe-fb6282669caa, depMode=SHARED,
> userVer=0, locDepOwner=false, participants=null],
> lastAffChangedTopVer=AffinityTopologyVersion \[topVer=8, minorTopVer=6],
> err=null, skipPrepare=false
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1576)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1565)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:130)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1092)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> There is no fair reproducer for now, but it seems that we should prevent such
> situation in general like following:
> 1) check the correctness of the message before it will be sent - inside of
> GridCacheDeploymentManager#prepare. If we have the corresponding class loader
> on local node, we can try to fix message and replace wrong class loader with
> local one.
> 2) log suspicious deployments which we receive from
> GridDeploymentManager#deploy - maybe we have obsolete deployments in caches.
> 3) possibly we can remove this assertion, we should have this class on sender
> node and use it as class loader id, and if we don't, we will receive
> exception on finishUnmarshall (Failed to peer load class) and try to process
> this situation with GridCacheIoManager#processFailedMessage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12879) Refactor test discovery messages interception configuration.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Description:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It helps to clarify the purpose of the methods.
It's needed to add the ability to configure multiple DiscoveryHook instances
through TestTcpDiscoverySpi for discovery messages interception. It helps to
avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
current approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
was:
It's needed to change DiscoveryHook class method naming to the following:
{code:java}
public void beforeDiscovery(DiscoverySpiCustomMessage msg)
public void afterDiscovery(DiscoverySpiCustomMessage msg)
{code}
It helps to clarify the purpose of the methods.
> Refactor test discovery messages interception configuration.
>
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It helps to clarify the purpose of the methods.
> It's needed to add the ability to configure multiple DiscoveryHook instances
> through TestTcpDiscoverySpi for discovery messages interception. It helps to
> avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
> current approach is as follows:
> {code:java}
> TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
> @Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
> super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
> discoveryHook));
> }
> };
> spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12879) Refactor test discovery messages interception configuration.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12879:
Summary: Refactor test discovery messages interception configuration.
(was: Change DiscoveryHook methods naming.)
> Refactor test discovery messages interception configuration.
>
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It helps to clarify the purpose of the methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12625) Thin client: Marshaling/unmarshaling of objects performed twice
[
https://issues.apache.org/jira/browse/IGNITE-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-12625:
--
Assignee: Aleksey Plekhanov
> Thin client: Marshaling/unmarshaling of objects performed twice
> ---
>
> Key: IGNITE-12625
> URL: https://issues.apache.org/jira/browse/IGNITE-12625
> Project: Ignite
> Issue Type: Bug
> Components: binary, thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> For each thin client cache operation marshaling/unmarshaling of objects
> performed twice. For example, cache "put" operation marshal object on the
> client-side, then unmarshal object (with keep binaries) on the server-side
> and marshal it again before putting it to the cache. It causes some
> undesirable effects. For example, references to the same binary object in a
> collection ( {{new ArrayList(Arrays.asList(person, person))}} ) deserialized
> as different objects. Also, with binary object full byte array of this object
> is marshaled, but object takes only some part of this array, it causes size
> overhead for storing these objects.
> To avoid double marshalling we could pass byte array from request content to
> cache directly (for example using {{CacheObject}}), but we don't have object
> size in thin client protocol, so in any case, we need to traverse the
> objects. Also, we don't have the ability to get {{CacheObject}} from the
> cache now, so such an approach will only work in one way, for "put"
> operations, but not for "get" operations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=17079339#comment-17079339 ] Glenn Wiebe commented on IGNITE-12849: -- Thanks Alexey. The two attachments implement two functional changes: 1. These Vectorizers create DenseVectors as opposed to SparseVectors that the standard BinaryObjectVectorizer ALWAYS does. 2. The standard BOV implementation only has a String-based extraction coordinate option, I wanted the ability to have either. (My use case has hundreds of chemical properties, i.e. long, complicated field names that are hard to deal with - both type and or read such a long list) I am sure I probably could have done this in one class, but for some reason that I don't recall, I have the two (Integer & String implementations of this DenseBinaryObjectVectorizer). Regards, Glenn > 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.9 > > Attachments: DenseIntBinaryObjectVectorizer.java, > DenseStringBinaryObjectVectorizer.java > > > 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-12879) Change DiscoveryHook methods naming.
[
https://issues.apache.org/jira/browse/IGNITE-12879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079331#comment-17079331
]
Ignite TC Bot commented on IGNITE-12879:
{panel:title=Branch: [pull/7647/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=5205648buildTypeId=IgniteTests24Java8_RunAll]
> Change DiscoveryHook methods naming.
>
>
> Key: IGNITE-12879
> URL: https://issues.apache.org/jira/browse/IGNITE-12879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's needed to change DiscoveryHook class method naming to the following:
> {code:java}
> public void beforeDiscovery(DiscoverySpiCustomMessage msg)
> public void afterDiscovery(DiscoverySpiCustomMessage msg)
> {code}
> It helps to clarify the purpose of the methods.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (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 ] Glenn Wiebe updated IGNITE-12849: - Attachment: DenseStringBinaryObjectVectorizer.java DenseIntBinaryObjectVectorizer.java > 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.9 > > Attachments: DenseIntBinaryObjectVectorizer.java, > DenseStringBinaryObjectVectorizer.java > > > 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] [Updated] (IGNITE-12760) Prevent AssertionError on message unmarshalling, when classLoaderId contains id of node that already left
[
https://issues.apache.org/jira/browse/IGNITE-12760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12760:
--
Fix Version/s: 2.9
> Prevent AssertionError on message unmarshalling, when classLoaderId contains
> id of node that already left
> -
>
> Key: IGNITE-12760
> URL: https://issues.apache.org/jira/browse/IGNITE-12760
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Following assertion error triggers failure handler and crashes the node. Can
> possibly crash the whole cluster.
> {code:java}
> 2020-02-18
> 14:34:09.775\[ERROR]\[query-#146129%DPL_GRID%DplGridNodeName%]\[o.a.i.i.p.cache.GridCacheIoManager]
> Failed to process message \[senderId=727757ed-4ad4-4779-bda9-081525725cce,
> msg=GridCacheQueryRequest \[id=178,
> cacheName=com.sbt.tokenization.data.entity.KEKEntity_DPL_union-module,
> type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
> rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
> incMeta=false, all=false, keepBinary=true,
> subjId=727757ed-4ad4-4779-bda9-081525725cce, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion \[topVer=97, minorTopVer=0], sendTimestamp=-1,
> receiveTimestamp=-1, super=GridCacheIdMessage \[cacheId=-1129073400,
> super=GridCacheMessage \[msgId=179, depInfo=GridDeploymentInfoBean
> \[clsLdrId=c32670e3071-d30ee64b-0833-45d4-abbe-fb6282669caa, depMode=SHARED,
> userVer=0, locDepOwner=false, participants=null],
> lastAffChangedTopVer=AffinityTopologyVersion \[topVer=8, minorTopVer=6],
> err=null, skipPrepare=false
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1576)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1565)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:130)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1092)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){code}
> There is no fair reproducer for now, but it seems that we should prevent such
> situation in general like following:
> 1) check the correctness of the message before it will be sent - inside of
> GridCacheDeploymentManager#prepare. If we have the corresponding class loader
> on local node, we can try to fix message and replace wrong class loader with
> local one.
> 2) log suspicious deployments which we receive from
> GridDeploymentManager#deploy - maybe we have obsolete deployments in caches.
> 3) possibly we can remove this assertion, we should have this class on sender
> node and use it as class loader id, and if we don't, we will receive
> exception on finishUnmarshall (Failed to peer load class) and try to process
> this situation with GridCacheIoManager#processFailedMessage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12875) Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
[
https://issues.apache.org/jira/browse/IGNITE-12875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079233#comment-17079233
]
Ignite TC Bot commented on IGNITE-12875:
{panel:title=Branch: [pull/7642/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=5202506buildTypeId=IgniteTests24Java8_RunAll]
> Implement "EVT_CLUSTER_STATE_CHANGE_STARTED" event
> --
>
> Key: IGNITE-12875
> URL: https://issues.apache.org/jira/browse/IGNITE-12875
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12438) Extend communication protocol to establish client-server connection
[
https://issues.apache.org/jira/browse/IGNITE-12438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079232#comment-17079232
]
Ignite TC Bot commented on IGNITE-12438:
{panel:title=Branch: [pull/7639/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=5201750buildTypeId=IgniteTests24Java8_RunAll]
> Extend communication protocol to establish client-server connection
> ---
>
> Key: IGNITE-12438
> URL: https://issues.apache.org/jira/browse/IGNITE-12438
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Recently there was quite a lot of questions related to thick clients
> connectivity issues when the clients are deployed in a k8s pod [1]. The
> general issue here is clients reporting network address which are not
> reachable from server nodes. At the same time, the clients can connect to
> server nodes.
> An idea of how to fix this is as follows:
> * Make sure that think clients discovery SPI always maintains a connection
> to a server node (this should be already implemented)
> * (Optionally) detect when a client has only one-way connectivity with the
> server nodes. This part should be investigated. We need this to avoid server
> nodes attempt to connect to a client and send communication request to the
> client node faster
> * When a server attempts to establish a connection with a client, check if
> client is unreachable or the previous connection attempt failed. If so, send
> a discovery message to the client to force a client-server connection. In
> this case, server will be able to send the original message via the newly
> established connection.
> [1]
> https://stackoverflow.com/questions/59192075/ignite-communicationspi-questions-in-paas-environment/59232504
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12870) Fix test JdbcThinTransactionsLeaksMvccTest after connection manager refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079213#comment-17079213
]
Ignite TC Bot commented on IGNITE-12870:
{panel:title=Branch: [pull/7632/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=5199262buildTypeId=IgniteTests24Java8_RunAll]
> Fix test JdbcThinTransactionsLeaksMvccTest after connection manager
> refactoring
> ---
>
> Key: IGNITE-12870
> URL: https://issues.apache.org/jira/browse/IGNITE-12870
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test {{JdbcThinTransactionsLeaksMvccTest#testLeaks}} is broken by the
> patch IGNITE-12804. The method {{detachedConnectionCount}} must be change to
> check used connection after connection manager refactoring.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (IGNITE-12825) Serialize Java and .NET dates using same calendars
[ https://issues.apache.org/jira/browse/IGNITE-12825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin reopened IGNITE-12825: --- Assignee: Pavel Tupitsyn (was: Nikolay Izhikov) [~nizhikov], this ticket depends on resolving IGNITE-12824, where I suggested allowing writing local dates to Ignite caches. The attached patch already implements this ticket together with IGNITE-12824. I see that [~ptupitsyn] is working on IGNITE-12824 so I am re-opening this ticket and re-assigning this ticket to [~ptupitsyn] > Serialize Java and .NET dates using same calendars > -- > > Key: IGNITE-12825 > URL: https://issues.apache.org/jira/browse/IGNITE-12825 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.8 >Reporter: Alexey Kukushkin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, sbcf > Attachments: ignite-12825-vs-2.8.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Java and .NET use different calendars for dates serialization. That results > in some dates written using Java API deserialized into different dates using > .NET API and vise versa. For example, 1-Jan-1992 00:00:00 MSK written using > Java API will be read as 31-Dec-1991 1:00:00 MSK using .NET API. > Java and .NET API must use same calendars for dates serialization. > +*Note:*+ > Java uses IANA Time Zone database ([https://www.iana.org/time-zones]) stored > locally that could be manually updated using Timezone Updater Tool > ([https://www.oracle.com/technetwork/java/javase/documentation/tzupdater-readme-136440.html]) > .NET uses its own calendars that cannot be manually updated. > For all the Java/.NET calendar differences I saw the Java version was valid > and .NET version was not. > We need to use IANA time zone database in .NET as well and, if possible, > provide a mechanism to update the time zone database -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12807) Key and Value fields with same name and SQL DML
[
https://issues.apache.org/jira/browse/IGNITE-12807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079190#comment-17079190
]
Alexey Kukushkin commented on IGNITE-12807:
---
Hi [~nizhikov], I added the Proposal section to the problem description that I
believe answers your question.
> Key and Value fields with same name and SQL DML
> ---
>
> Key: IGNITE-12807
> URL: https://issues.apache.org/jira/browse/IGNITE-12807
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12807-vs-2.8.patch
>
>
> Key/Value API allows both the Key and Value have fields with same name. This
> is a very popular arrangement since most users are ready to sacrifice extra
> memory footprint for the sake of having a self-sufficient value entity.
> Using SQL DML to update such an entry will update only the key field, leaving
> the value field unchanged. This is a huge usability issue for the mixed K/V
> and SQL API apps.
> h1. Proposal
> h2. Requirements
> h3. Example Data Model
> Consider a business domain entity *Person \{ id: int, passportNo: String,
> name: String }*
> When designing an Ignite app the development team decided to map the Person
> entity to Ignite data model as:
> * *PersonKey \{ id: int, passportNo: String }*
> * *Person \{ passportNo: String, name: String }*
> h3. Public API
> * *Cache API*: add new method {{setKeyValueFields(keyValueFields:
> Set): QueryEntity}} to {{QueryEntity}}
> ** The method marks Cache API Key and Entity fields that SQL API must
> initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
> ** It is still possible to use Cache API to initialize the fields marked
> with {{setKeyValueFields}} to different values. SQL SELECT statement returns
> value of such a field from the Key entity.
> ** The method accepts a set of field names and returns the declaring class
> instance for chaining.
> ** The method throws {{ArgumentException}} if the Key and Value types are
> available and the field types are different within the Key and Value entities.
> * *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}}
> statement's additional parameters list.
> ** The parameter'value is a space-separated list of field names with the
> semantics equivalent to that of the {{setKeyValueFields}} method described
> above.
> ** The parameter can be specified only if both the {{KEY_TYPE}} and
> {{VALUE_TYPE}} parameters are specified
> h3. Use Cases
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both
> Fields in QueryEntity-Defined Cache
> * GIVEN a Person cache from the example data model configured like this in
> Ignite:
> {code:java}
> new CacheConfiguration("CACHE")
> .setQueryEntities(Collections.singleton(
> new QueryEntity(PersonKey.class, Person.class)
> .addQueryField("id", int.class.getName(), null)
> .addQueryField("passportNo", String.class.getName(), null)
> .addQueryField("name", String.class.getName(), null)
> .setKeyFields(Collections.singleton("id"))
> .setKeyValueFields(Collections.singleton("passportNo"))
> ));
> {code}
> ** AND the user runs this SQL statement to insert an entry to the cache:
> {code:sql}
> INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
> {code}
> * WHEN the user gets the entity using Cache API:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> Person v = cache.get(K);
> {code}
> * THEN the *passportNo* field is initialized to the same value within the
> key and value entities:
> {code:java}
> assertEquals(K.passportNo, v.passportNo);
> {code}
> h4. Querying Key and Value Fields With Same Name and Different Values Returns
> Value from the Key in QueryEntity-Defined Cache
> * GIVEN a Person cache from the previous use case
> ** AND the user adds an entry with different passportNo field values to the
> cache:
> {code:java}
> final PersonKey K = new PersonKey(1, "1");
> final Person V = new Person("2", "Name1");
> cache.put(K, V);
> {code}
> * WHEN the user runs this SQL to get the enty:
> {code:sql}
> SELECT ID, PASSPORTNO, NAME FROM " + CACHE.Person {code}
> * THEN the retrieved PASSPORTNO is that of the Key: "1"
> h4. Inserting Into Key and Value Fields With Same Name Initializes Both
> Fields in SQL-Defined Cache
> * GIVEN a Person cache from the example data model configured like this in
> Ignite:
> {code:sql}
> CREATE TABLE Person (
> id int,
> passportNo varchar,
> name varchar,
> PRIMARY KEY(id, passportNo)
> ) WITH "key_type=PersonKey, value_type=Person,
[jira] [Updated] (IGNITE-12807) Key and Value fields with same name and SQL DML
[
https://issues.apache.org/jira/browse/IGNITE-12807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-12807:
--
Description:
Key/Value API allows both the Key and Value have fields with same name. This is
a very popular arrangement since most users are ready to sacrifice extra memory
footprint for the sake of having a self-sufficient value entity.
Using SQL DML to update such an entry will update only the key field, leaving
the value field unchanged. This is a huge usability issue for the mixed K/V and
SQL API apps.
h1. Proposal
h2. Requirements
h3. Example Data Model
Consider a business domain entity *Person \{ id: int, passportNo: String, name:
String }*
When designing an Ignite app the development team decided to map the Person
entity to Ignite data model as:
* *PersonKey \{ id: int, passportNo: String }*
* *Person \{ passportNo: String, name: String }*
h3. Public API
* *Cache API*: add new method {{setKeyValueFields(keyValueFields:
Set): QueryEntity}} to {{QueryEntity}}
** The method marks Cache API Key and Entity fields that SQL API must
initialize (on INSERT/MERGE) and update (on UPDATE/MERGE) together.
** It is still possible to use Cache API to initialize the fields marked with
{{setKeyValueFields}} to different values. SQL SELECT statement returns value
of such a field from the Key entity.
** The method accepts a set of field names and returns the declaring class
instance for chaining.
** The method throws {{ArgumentException}} if the Key and Value types are
available and the field types are different within the Key and Value entities.
* *SQL API*: add {{KEY_VALUE_FIELDS}} parameter to {{CREATE TABLE}}
statement's additional parameters list.
** The parameter'value is a space-separated list of field names with the
semantics equivalent to that of the {{setKeyValueFields}} method described
above.
** The parameter can be specified only if both the {{KEY_TYPE}} and
{{VALUE_TYPE}} parameters are specified
h3. Use Cases
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in QueryEntity-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:java}
new CacheConfiguration("CACHE")
.setQueryEntities(Collections.singleton(
new QueryEntity(PersonKey.class, Person.class)
.addQueryField("id", int.class.getName(), null)
.addQueryField("passportNo", String.class.getName(), null)
.addQueryField("name", String.class.getName(), null)
.setKeyFields(Collections.singleton("id"))
.setKeyValueFields(Collections.singleton("passportNo"))
));
{code}
** AND the user runs this SQL statement to insert an entry to the cache:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in QueryEntity-Defined Cache
* GIVEN a Person cache from the previous use case
** AND the user adds an entry with different passportNo field values to the
cache:
{code:java}
final PersonKey K = new PersonKey(1, "1");
final Person V = new Person("2", "Name1");
cache.put(K, V);
{code}
* WHEN the user runs this SQL to get the enty:
{code:sql}
SELECT ID, PASSPORTNO, NAME FROM " + CACHE.Person {code}
* THEN the retrieved PASSPORTNO is that of the Key: "1"
h4. Inserting Into Key and Value Fields With Same Name Initializes Both Fields
in SQL-Defined Cache
* GIVEN a Person cache from the example data model configured like this in
Ignite:
{code:sql}
CREATE TABLE Person (
id int,
passportNo varchar,
name varchar,
PRIMARY KEY(id, passportNo)
) WITH "key_type=PersonKey, value_type=Person, key_value_fields=passportNo"
{code}
** AND the user runs this SQL statement to insert an entry to the cache:
{code:sql}
INSERT INTO CACHE.Person (ID, PASSPORTNO, NAME) VALUES (1, '1', 'Name1')
{code}
* WHEN the user gets the entity using Cache API:
{code:java}
final PersonKey K = new PersonKey(1, "1");
Person v = cache.get(K);
{code}
* THEN the *passportNo* field is initialized to the same value within the key
and value entities:
{code:java}
assertEquals(K.passportNo, v.passportNo);
{code}
h4. Querying Key and Value Fields With Same Name and Different Values Returns
Value from the Key in SQL-Defined Cache
* GIVEN a Person cache from the previous use case
** AND the user adds an entry with different passportNo field values to the
cache:
{code:java}
[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[
https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079184#comment-17079184
]
Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:54 AM:
-
[~cyberdemon], the path is OK with me.
Please fix codestyle (empty lines) at the
{{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}
was (Author: tledkov-gridgain):
[~cyberdemon], the path is OK with me.
Please fix codestyle at the {{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}
> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly
> here. Column type does not matter between UUID and VARCHAR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[
https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079184#comment-17079184
]
Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:54 AM:
-
[~cyberdemon], the path is OK with me.
Please fix codestyle at the {{JdbcSqlStreamingTest#JdbcSqlStreamingTest}}
was (Author: tledkov-gridgain):
[~cyberdemon], the path is OK with me.
> Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
> --
>
> Key: IGNITE-12764
> URL: https://issues.apache.org/jira/browse/IGNITE-12764
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Ilya Kasnacheev
>Assignee: Dmitriy Sorokin
>Priority: Blocker
> Fix For: 2.8.1
>
> Attachments: SqlMain.java
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID())
> happily worked in 2.7.6 but will fail on 2.8.0 with:
> Exception in thread "main" java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: null
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Suspected reason is that function RANDOM_UUID() is not processed correctly
> here. Column type does not matter between UUID and VARCHAR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079184#comment-17079184 ] Taras Ledkov commented on IGNITE-12764: --- [~cyberdemon]m the path is OK with me. > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
[ https://issues.apache.org/jira/browse/IGNITE-12764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079184#comment-17079184 ] Taras Ledkov edited comment on IGNITE-12764 at 4/9/20, 10:52 AM: - [~cyberdemon], the path is OK with me. was (Author: tledkov-gridgain): [~cyberdemon]m the path is OK with me. > Regression: Thin JDBC streaming fails/BatchUpdateException if function is used > -- > > Key: IGNITE-12764 > URL: https://issues.apache.org/jira/browse/IGNITE-12764 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Dmitriy Sorokin >Priority: Blocker > Fix For: 2.8.1 > > Attachments: SqlMain.java > > Time Spent: 1h 40m > Remaining Estimate: 0h > > insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) > happily worked in 2.7.6 but will fail on 2.8.0 with: > Exception in thread "main" java.sql.BatchUpdateException: class > org.apache.ignite.IgniteCheckedException: null > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) > at java.base/java.lang.Thread.run(Thread.java:834) > Suspected reason is that function RANDOM_UUID() is not processed correctly > here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12846) Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description in binary release
[
https://issues.apache.org/jira/browse/IGNITE-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-12846:
-
Fix Version/s: 2.8.1
> 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
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.8.1
>
>
> 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}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
>
> {code}
> Expected:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
> [Some description]
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12846) Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description in binary release
[
https://issues.apache.org/jira/browse/IGNITE-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev reassigned IGNITE-12846:
Assignee: Alexey Zinoviev
> 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
>Assignee: Alexey Zinoviev
>Priority: Major
>
> 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}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
>
> {code}
> Expected:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
> [Some description]
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=17079121#comment-17079121 ] Alexey Zinoviev commented on IGNITE-12849: -- [~ggwiebe] I don't know your case, sorry. I didn't face with that case. Maybe if you share your test code (if it's not a secret) I could understand. > 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.9 > > > 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] [Issue Comment Deleted] (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:
--
Comment: was deleted
(was: [~ilyak], I think no.
As far as i know not constant values aren't supported in streaming mode. Needs
to investigation.)
> 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] [Commented] (IGNITE-11494) Change message log message in case of too small IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
[
https://issues.apache.org/jira/browse/IGNITE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079114#comment-17079114
]
Ignite TC Bot commented on IGNITE-11494:
{panel:title=Branch: [pull/7629/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=5204275buildTypeId=IgniteTests24Java8_RunAll]
> Change message log message in case of too small
> IGNITE_SQL_MERGE_TABLE_MAX_SIZE parameter
> -
>
> Key: IGNITE-11494
> URL: https://issues.apache.org/jira/browse/IGNITE-11494
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Evgenii Zhuravlev
>Assignee: Nikita Alemaskin
>Priority: Major
> Labels: newbie, usability
> Attachments:
> master_ee07f34e52_IGNITE-11494-large_set_logging_improving.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Message "Fetched result set was too large." should be changed to some
> recommendations regarding IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12383) [ML] Add more distances between two Vectors
[ https://issues.apache.org/jira/browse/IGNITE-12383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-12383: - Fix Version/s: 2.9 > [ML] Add more distances between two Vectors > --- > > Key: IGNITE-12383 > URL: https://issues.apache.org/jira/browse/IGNITE-12383 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Alexey Zinoviev >Assignee: Ravil Galeyev >Priority: Minor > Labels: newbie > Fix For: 2.9 > > Time Spent: 2h > Remaining Estimate: 0h > > Currently, we support > * Hamming > * Manhattan > * Euclidean > Please have a look and propose the next implementations for distance > calculation between two points as > # [http://en.wikipedia.org/wiki/Chebyshev_distance] > # [http://en.wikipedia.org/wiki/Cosine_similarity] > # [http://en.wikipedia.org/wiki/Minkowski_distance] (the common case for > Manhattan and Euclidean) > # [http://en.wikipedia.org/wiki/Jaccard_index] (Tanimoto) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12881) Add test discovery messages interception configuration through TestTcpDiscoverySpi.
PetrovMikhail created IGNITE-12881:
--
Summary: Add test discovery messages interception configuration
through TestTcpDiscoverySpi.
Key: IGNITE-12881
URL: https://issues.apache.org/jira/browse/IGNITE-12881
Project: Ignite
Issue Type: Improvement
Reporter: PetrovMikhail
Assignee: PetrovMikhail
It's needed to add the ability to configure multiple DiscoveryHook instances
through TestTcpDiscoverySpi for discovery messages interception. It helps to
avoid redefinition of the TestTcpDiscoverySpi and its reconfiguration. The
current approach is as follows:
{code:java}
TcpDiscoverySpi spi = new TestTcpDiscoverySpi() {
@Override public void setListener(@Nullable DiscoverySpiListener lsnr) {
super.setListener(DiscoverySpiListenerWrapper.wrap(lsnr,
discoveryHook));
}
};
spi.setIpFinder(((TcpDiscoverySpi)cfg.getDiscoverySpi()).getIpFinder());
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-9740:
Fix Version/s: (was: 2.9)
2.8.1
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.8.1
>
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9740) [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up to IGNITE-9711)
[
https://issues.apache.org/jira/browse/IGNITE-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Zinoviev updated IGNITE-9740:
Affects Version/s: (was: 2.6)
> [ML] Remove IgniteThread wrapper from ml unit test EvaluatorTest (follow up
> to IGNITE-9711)
> ---
>
> Key: IGNITE-9740
> URL: https://issues.apache.org/jira/browse/IGNITE-9740
> Project: Ignite
> Issue Type: Bug
> Components: ml
>Reporter: Oleg Ignatenko
>Assignee: Alexey Zinoviev
>Priority: Critical
> Fix For: 2.9
>
>
> [EvaluatorTest|https://github.com/apache/ignite/blob/master/modules/ml/src/test/java/org/apache/ignite/ml/selection/scoring/evaluator/EvaluatorTest.java]
> involves {{IgniteThread}} which is in fact not needed there and should be
> removed.
> {{IgniteThread}} usage is a remainder / copy-paste from older tests and
> examples that were using API requiring it. This API has been removed and
> there is no need for wrapping like that anymore. For the reference on how to
> perform suggested cleanup check changes made to ml examples per IGNITE-9711.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10782: - Priority: Critical (was: Major) > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Affects Versions: 2.7 >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.9 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10782: - Fix Version/s: (was: 2.9) 2.8.1 > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.8.1 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10782) javadoc description for ml.math.exceptions.preprocessing and ml.selection.scoring.evaluator
[ https://issues.apache.org/jira/browse/IGNITE-10782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Zinoviev updated IGNITE-10782: - Affects Version/s: (was: 2.7) > javadoc description for ml.math.exceptions.preprocessing and > ml.selection.scoring.evaluator > --- > > Key: IGNITE-10782 > URL: https://issues.apache.org/jira/browse/IGNITE-10782 > Project: Ignite > Issue Type: Bug > Components: documentation, ml >Reporter: Stepan Pilschikov >Assignee: Alexey Zinoviev >Priority: Critical > Fix For: 2.9 > > > Need to add modules description for > - org.apache.ignite.ml.math.exceptions.preprocessing > - org.apache.ignite.ml.selection.scoring.evaluator > Located in ignite/docs/overview-summary.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12835) Thin client: compute support
[ https://issues.apache.org/jira/browse/IGNITE-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079088#comment-17079088 ] Denis Garus commented on IGNITE-12835: -- [~alex_pl] LGTM Thanks! > Thin client: compute support > > > Key: IGNITE-12835 > URL: https://issues.apache.org/jira/browse/IGNITE-12835 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-42 > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add compute grid functionality to thin clients. > As a first step execution of task by task name should be added. > Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12877) "restorePartitionStates" always logs all meta pages into WAL
[
https://issues.apache.org/jira/browse/IGNITE-12877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-12877:
--
Component/s: persistence
> "restorePartitionStates" always logs all meta pages into WAL
>
>
> Key: IGNITE-12877
> URL: https://issues.apache.org/jira/browse/IGNITE-12877
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> 2020-01-31T21:09:27,203 [INFO
> ][main][org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager]
> - Finished applying WAL changes [updatesApplied=11897, time=183531 ms]
> 2020-01-31T21:09:27,203 [INFO
> ][main][org.apache.ignite.internal.processors.cache.GridCacheProcessor] -
> Restoring partition state for local groups. 2020-01-31T21:17:49,692 [INFO
> ][main][org.apache.ignite.internal.processors.cache.GridCacheProcessor] -
> Finished restoring partition state for local groups [groupsProcessed=32,
> partitionsProcessed=9310, time=502498ms] {noformat}
> Main issue is that
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager#updateState
> unconditionally returns true. "stateId" is pretty much always not equal to
> "-1".
> UPDATE: that wasn’t the only problem, please look in the fix itself for more
> details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12877) "restorePartitionStates" always logs all meta pages into WAL
[
https://issues.apache.org/jira/browse/IGNITE-12877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079077#comment-17079077
]
Ignite TC Bot commented on IGNITE-12877:
{panel:title=Branch: [pull/7644/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=5202993buildTypeId=IgniteTests24Java8_RunAll]
> "restorePartitionStates" always logs all meta pages into WAL
>
>
> Key: IGNITE-12877
> URL: https://issues.apache.org/jira/browse/IGNITE-12877
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> 2020-01-31T21:09:27,203 [INFO
> ][main][org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager]
> - Finished applying WAL changes [updatesApplied=11897, time=183531 ms]
> 2020-01-31T21:09:27,203 [INFO
> ][main][org.apache.ignite.internal.processors.cache.GridCacheProcessor] -
> Restoring partition state for local groups. 2020-01-31T21:17:49,692 [INFO
> ][main][org.apache.ignite.internal.processors.cache.GridCacheProcessor] -
> Finished restoring partition state for local groups [groupsProcessed=32,
> partitionsProcessed=9310, time=502498ms] {noformat}
> Main issue is that
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager#updateState
> unconditionally returns true. "stateId" is pretty much always not equal to
> "-1".
> UPDATE: that wasn’t the only problem, please look in the fix itself for more
> details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12874) Possible NPE in GridDiscoveryManager#cacheGroupAffinityNode
[ https://issues.apache.org/jira/browse/IGNITE-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17079071#comment-17079071 ] Vyacheslav Koptilin commented on IGNITE-12874: -- Hi [~ibessonov], The proposed change looks good to me. Merged to master. Thank you for your contribution! > Possible NPE in GridDiscoveryManager#cacheGroupAffinityNode > --- > > Key: IGNITE-12874 > URL: https://issues.apache.org/jira/browse/IGNITE-12874 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > If "grpId" is invalid then method will throw NPE instead of returning false. -- 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=17079033#comment-17079033
]
Sergey Chugunov commented on IGNITE-12793:
--
[~macrergate],
Sure, I'll take a look at the reproducer today.
> 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.8, 2.7.6
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: ignite-12793-threaddump.txt
>
>
> 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
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
> at
>
[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=17079020#comment-17079020
]
Sergey Kosarev commented on IGNITE-12793:
-
[~sergey-chugunov], can you look at this please?
> 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.8, 2.7.6
>Reporter: Sergey Kosarev
>Priority: Major
> Attachments: ignite-12793-threaddump.txt
>
>
> 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
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
> at
>
[jira] [Resolved] (IGNITE-12878) Improve logging for async writing of Binary Metadata
[ https://issues.apache.org/jira/browse/IGNITE-12878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov resolved IGNITE-12878. -- Resolution: Won't Fix Inspection of code revealed that all necessary logging entries were implemented under IGNITE-12099 > Improve logging for async writing of Binary Metadata > > > Key: IGNITE-12878 > URL: https://issues.apache.org/jira/browse/IGNITE-12878 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > > New implementation of writing binary metadata outside of discovery thread was > introduced in IGNITE-12099 but sufficient debug logging was missing. > To provide enough information in case of debugging we need to add necessary > logging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12876) Test to cover deadlock fix between checkpoint, entry update and ttl-cleanup threads
[ https://issues.apache.org/jira/browse/IGNITE-12876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-12876: - Fix Version/s: (was: 2.8.1) 2.9 > Test to cover deadlock fix between checkpoint, entry update and ttl-cleanup > threads > --- > > Key: IGNITE-12876 > URL: https://issues.apache.org/jira/browse/IGNITE-12876 > Project: Ignite > Issue Type: Test >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-12594 ticked fixed deadlock between several threads that was > reproducible with low probability in unrelated tests. > To improve test coverage of the fix new test dedicated for the deadlock > situation is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12878) Improve logging for async writing of Binary Metadata
[ https://issues.apache.org/jira/browse/IGNITE-12878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-12878: - Fix Version/s: (was: 2.8.1) 2.9 > Improve logging for async writing of Binary Metadata > > > Key: IGNITE-12878 > URL: https://issues.apache.org/jira/browse/IGNITE-12878 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.9 > > > New implementation of writing binary metadata outside of discovery thread was > introduced in IGNITE-12099 but sufficient debug logging was missing. > To provide enough information in case of debugging we need to add necessary > logging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12874) Possible NPE in GridDiscoveryManager#cacheGroupAffinityNode
[
https://issues.apache.org/jira/browse/IGNITE-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17078957#comment-17078957
]
Ignite TC Bot commented on IGNITE-12874:
{panel:title=Branch: [pull/7641/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=5201982buildTypeId=IgniteTests24Java8_RunAll]
> Possible NPE in GridDiscoveryManager#cacheGroupAffinityNode
> ---
>
> Key: IGNITE-12874
> URL: https://issues.apache.org/jira/browse/IGNITE-12874
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If "grpId" is invalid then method will throw NPE instead of returning false.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
