[jira] [Commented] (IGNITE-12033) .Net callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901539#comment-16901539
]
Pavel Tupitsyn commented on IGNITE-12033:
-
See the reply in the User List thread. Known issue, and the same thing will
happen in Java, this is not an Ignite.NET bug.
[~ilyak] I propose to close this.
> .Net callbacks from striped pool due to async/await may hang cluster
>
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .net
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (IGNITE-12033) .Net callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-12033:
---
Assignee: Pavel Tupitsyn
> .Net callbacks from striped pool due to async/await may hang cluster
>
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .net
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901302#comment-16901302
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 5:23 PM:
--
Thank you, Pavel, for the review!
So, I propose to change the formula as follows:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
was (Author: slava.koptilin):
Thank you, Pavel, for the review!
So, I propose to change the equation as follows:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901302#comment-16901302
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 5:23 PM:
--
Thank you, Pavel, for the review!
So, I would propose to change the formula as follows:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
was (Author: slava.koptilin):
Thank you, Pavel, for the review!
So, I propose to change the formula as follows:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901302#comment-16901302
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 5:22 PM:
--
Thank you, Pavel, for the review!
So, I propose to change the equation as follows:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
was (Author: slava.koptilin):
Thank you, Pavel, for the review!
So, I propose to change the equation as follows:
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /*one page per bucket*/);
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901302#comment-16901302
]
Vyacheslav Koptilin commented on IGNITE-12042:
--
Thank you, Pavel, for the review!
So, I propose to change the equation as follows:
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /*one page per bucket*/);
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.systemPageSize() - data row pages}}
{{nonEmptyPages * (8.0 * 1.5 / pageMem.pageSize() + 1) - nonEmptyPages +
linkPages (multiplied by 1.5)}}
{{256 - additional pages reserved for buckets of FreeList}}
{{What do you think, [~xtern] [~ivan.glukos]? I am ready to update the PR and
re-run TC. :)}}
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12047) senderNodeId is absent in StatusCheckMessage
Denis Chudov created IGNITE-12047:
-
Summary: senderNodeId is absent in StatusCheckMessage
Key: IGNITE-12047
URL: https://issues.apache.org/jira/browse/IGNITE-12047
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
Assignee: Denis Chudov
Fix For: 2.8
TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized
{code:java}
[2019-07-29
02:42:11,609][ERROR][tcp-disco-sock-reader-[]-#21611%tcp.TcpDiscoveryCoordinatorFailureTest4%][TcpDiscoverySpi]
Failed to initialize connection (this can happen due to short time network
problems and can be ignored if does not affect node discovery)
[sock=Socket[addr=/127.0.0.1,port=44033,localport=47504]]
java.net.SocketTimeoutException: Read timed out at
java.net.SocketInputStream.socketRead0(Native Method) at
java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at
java.net.SocketInputStream.read(SocketInputStream.java:171) at
java.net.SocketInputStream.read(SocketInputStream.java:141) at
java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at
java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at
java.io.BufferedInputStream.read(BufferedInputStream.java:345) at
org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:6464)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:60)
Exception in thread
"disco-pool-#62924%tcp.TcpDiscoveryCoordinatorFailureTest4%" Exception in
thread "disco-pool-#62925%tcp.TcpDiscoveryCoordinatorFailureTest4%"
java.lang.AssertionError at
org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723) at
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
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) java.lang.AssertionError at
org.apache.ignite.spi.discovery.tcp.ServerImpl.pingNode(ServerImpl.java:723) at
org.apache.ignite.spi.discovery.tcp.ServerImpl.access$4000(ServerImpl.java:195)
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker$8.run(ServerImpl.java:5598)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[ https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901250#comment-16901250 ] Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 4:39 PM: --- [~slava.koptilin], > _Hmm... nonEmptyPages * (coeff + 1) = nonEmptyPages * coef + nonEmptyPages = > linkPages + nonEmptyPages_ Sorry, my bad, I missed +1. Thanks for explanation. was (Author: xtern): [~slava.koptilin], _Hmm... nonEmptyPages * (coeff + 1) = nonEmptyPages * coef + nonEmptyPages = linkPages + nonEmptyPages_ Sorry, my bad, I missed +1. Thanks for explanation. > Atempt to remove entries from fully populated data region may result in > IgineOutOfMemoryException > - > > Key: IGNITE-12042 > URL: https://issues.apache.org/jira/browse/IGNITE-12042 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing entries from non-persistent data region may require allocating a new > data page in order to move a tracked page from one bucket of the free-list to > another one. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[ https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901250#comment-16901250 ] Pavel Pereslegin commented on IGNITE-12042: --- [~slava.koptilin], _Hmm... nonEmptyPages * (coeff + 1) = nonEmptyPages * coef + nonEmptyPages = linkPages + nonEmptyPages_ Sorry, my bad, I missed +1. Thanks for explanation. > Atempt to remove entries from fully populated data region may result in > IgineOutOfMemoryException > - > > Key: IGNITE-12042 > URL: https://issues.apache.org/jira/browse/IGNITE-12042 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing entries from non-persistent data region may require allocating a new > data page in order to move a tracked page from one bucket of the free-list to > another one. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901230#comment-16901230
]
Vyacheslav Koptilin commented on IGNITE-12042:
--
> I don't see in PR (+nonEmptyPages), I just see linkPages:
{{>(nonEmptyPages * (8.0 / pageMem.pageSize() + 1)}}
Hmm... {{nonEmptyPages * (coeff + 1) = nonEmptyPages * coef + nonEmptyPages =
linkPages + nonEmptyPages}}
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901186#comment-16901186
]
Pavel Pereslegin commented on IGNITE-12042:
---
[~slava.koptilin],
_totalPages < datarowPages + linkPages + *nonEmptyPages* + additionalPages_
I don't see in PR (+nonEmptyPages), I just see linkPages:
{{(nonEmptyPages * (8.0 / pageMem.pageSize() + 1)* 1.5}}
Or I still missing something? :)
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-9562) Destroyed cache that resurrected on a old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901162#comment-16901162
]
Eduard Shangareev commented on IGNITE-9562:
---
The proper solution is moving cache configuration to metastore. There was
implemented a workaround to not get the cluster to hang.
We don’t allow nodes with caches which don’t exist in running cluster and the
nodes have data on disk.
To allow the nodes join, you need to remove directories with absent caches or
start the nodes first.
> Destroyed cache that resurrected on a old offline node breaks PME
> -
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
> Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
> at
>
[jira] [Commented] (IGNITE-9562) Destroyed cache that resurrected on a old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901157#comment-16901157
]
Ignite TC Bot commented on IGNITE-9562:
---
{panel:title=Branch: [pull/6748/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=4467734buildTypeId=IgniteTests24Java8_RunAll]
> Destroyed cache that resurrected on a old offline node breaks PME
> -
>
> Key: IGNITE-9562
> URL: https://issues.apache.org/jira/browse/IGNITE-9562
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Eduard Shangareev
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Given:
> 2 nodes, persistence enabled.
> 1) Stop 1 node
> 2) Destroy cache through client
> 3) Start stopped node
> When the stopped node joins to cluster it starts all caches that it has seen
> before stopping.
> If that cache was cluster-widely destroyed it leads to breaking the crash
> recovery process or PME.
> Root cause - we don't start/collect caches from the stopped node on another
> part of a cluster.
> In case of PARTITIONED cache mode that scenario breaks crash recovery:
> {noformat}
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:696)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.updateLocal(GridDhtPartitionTopologyImpl.java:2449)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.afterStateRestored(GridDhtPartitionTopologyImpl.java:679)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restorePartitionStates(GridCacheDatabaseSharedManager.java:2445)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:2321)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1568)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:1308)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1255)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:766)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2577)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2457)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> In case of REPLICATED cache mode that scenario breaks PME coordinator process:
> {noformat}
> [2018-09-12
> 18:50:36,407][ERROR][sys-#148%distributed.CacheStopAndRessurectOnOldNodeTest0%][GridCacheIoManager]
> Failed to process message [senderId=4b6fd0d4-b756-4a9f-90ca-f0ee2511,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: 3080586
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:3621)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2439)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:137)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2261)
> at
>
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901152#comment-16901152
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 3:11 PM:
--
[~xtern]
> Or am I missing something?
Yep, we are calculating total pages. To be more precise:
{{datarowPages}} = {{datarow.size() / pageMem.systemPageSize()}}
{{linkPages + nonEmptyPages }}= {{nonEmptyPages * (8.0 / pageMem.pageSize() +
*1*)}}
{{additionalPages}} = {{256 // one page per bucket}}
So,
*totalPages* < {{datarowPages + linkPages + nonEmptyPages + additionalPages}}
> AFAIK each data page has overhead
{{> (see AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row
required 8 bytes more on each page)}}
{{> therefore, these calculations for data row are very approximate.}}
That is the reason why we have the multiplier - 1.5
was (Author: slava.koptilin):
[~xtern]
> Or am I missing something?
Yep, we are calculating total pages. To be more precise:
{{datarowPages}} = {{datarow.size() / pageMem.systemPageSize()}}
{{linkPages + nonEmptyPages }}= {{nonEmptyPages * (8.0 / pageMem.pageSize() +
*1*)}}
{{additionalPages}} = {{256 // one page per bucket}}
So,
*totalPages* < {{datarowPages + linkPages + nonEmptyPages + additionalPages}}
{\{> AFAIK each data page has overhead }}
{{> (see AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row
required 8 bytes more on each page)}}
{{> therefore, these calculations for data row are very approximate.}}
That is the reason why we have the multiplier - 1.5
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901152#comment-16901152
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 3:10 PM:
--
[~xtern]
> Or am I missing something?
Yep, we are calculating total pages. To be more precise:
{{datarowPages}} = {{datarow.size() / pageMem.systemPageSize()}}
{{linkPages + nonEmptyPages }}= {{nonEmptyPages * (8.0 / pageMem.pageSize() +
*1*)}}
{{additionalPages}} = {{256 // one page per bucket}}
So,
*totalPages* < {{datarowPages + linkPages + nonEmptyPages + additionalPages}}
{\{> AFAIK each data page has overhead }}
{{> (see AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row
required 8 bytes more on each page)}}
{{> therefore, these calculations for data row are very approximate.}}
That is the reason why we have the multiplier - 1.5
was (Author: slava.koptilin):
[~xtern]
> Or am I missing something?
Yep, we are calculating total pages. To be more precise:
{{datarowPages}} = {{datarow.size() / pageMem.systemPageSize()}}
{{linkPages + nonEmptyPages }}= {{nonEmptyPages * (8.0 / pageMem.pageSize() +
*1*)}}
{{additionalPages}} = 256 // one page per bucket
So,
*totalPages* < {{datarowPages + linkPages + nonEmptyPages + additionalPages}}
{{> AFAIK each data page has overhead }}
{{> (see AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row
required 8 bytes more on each page)}}
{{> therefore, these calculations for data row are very approximate.}}
That is the reason why we have the multiplier - 1.5
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901152#comment-16901152
]
Vyacheslav Koptilin commented on IGNITE-12042:
--
[~xtern]
> Or am I missing something?
Yep, we are calculating total pages. To be more precise:
{{datarowPages}} = {{datarow.size() / pageMem.systemPageSize()}}
{{linkPages + nonEmptyPages }}= {{nonEmptyPages * (8.0 / pageMem.pageSize() +
*1*)}}
{{additionalPages}} = 256 // one page per bucket
So,
*totalPages* < {{datarowPages + linkPages + nonEmptyPages + additionalPages}}
{{> AFAIK each data page has overhead }}
{{> (see AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row
required 8 bytes more on each page)}}
{{> therefore, these calculations for data row are very approximate.}}
That is the reason why we have the multiplier - 1.5
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901131#comment-16901131
]
Pavel Pereslegin commented on IGNITE-12042:
---
[~slava.koptilin],
Yes, if we will take into account row size this should fix a possible leak
after OOME for very large entries.
But from my point of view, any OOME is unrecoverable.
Btw, I looked at the calculations more closely and I have a question.
As I understand, we want to be sure that pagemem have enough free space to
store:
1. data row
2. pages required for store links to pages (8 bytes per link)
3. 256 more pages
So
{{*freePages* < datarowPages + linkPages + 256}}
But in proposed changes
{{*totalPages* < datarowPages + linkPages + 256}}
Or am I missing something?
AFAIK each data page has overhead (see
AbstractDataPageIO.MIN_DATA_PAGE_OVERHEAD, fragmented data row required 8 bytes
more on each page) therefore, these calculations for data row are very
approximate.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-6957) Reduce excessive int boxing when accessing cache by ID
[ https://issues.apache.org/jira/browse/IGNITE-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901099#comment-16901099 ] Ivan Bessonov commented on IGNITE-6957: --- [~mstepachev] looks good, please proceed with merge. > Reduce excessive int boxing when accessing cache by ID > -- > > Key: IGNITE-6957 > URL: https://issues.apache.org/jira/browse/IGNITE-6957 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 2.3 >Reporter: Alexey Goncharuk >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Attachments: 2017-11-20_12-01-31.png > > Time Spent: 53h 20m > Remaining Estimate: 0h > > We have a number of places which lead to a large number of Integer > allocations when having a large number of caches and partitions. See the > image attached. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12046) [IEP-35] LongMetric interface contains redundant methods.
Andrey Gura created IGNITE-12046:
Summary: [IEP-35] LongMetric interface contains redundant methods.
Key: IGNITE-12046
URL: https://issues.apache.org/jira/browse/IGNITE-12046
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Andrey Gura
Fix For: 2.8
The following methods on {{LongMetric}} interface a redundant and have the same
functionality:
* {{get}}
* {{longValue}}
Mentioned methods should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900999#comment-16900999
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/6/19 1:05 PM:
--
> If the user uses default failure handler all these cases are unrecoverable.
Yep, we are talking about the case when a custom failure handler is used.
> Check will not catch a problem (if datarow is big enough) - throwing OOME
>from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
In my opinion, this should be avoided. We need to take into account the size
of the data row:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 /
pageMem.pageSize() + 1) * 1.5 + 256 /*one page per bucket*/);
{code}
WDYT?
(By the way, the initial goal of this change is reserving pages for internal
data structures: {{PagesListNodeIO}}, {{PagesListMetaIO}})
was (Author: slava.koptilin):
> If the user uses default failure handler all these cases are unrecoverable.
Yep, we are talking about the case when a custom failure handler is used.
> Check will not catch a problem (if datarow is big enough) - throwing OOME
>from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
In my opinion, this should be avoided. We need to take into account the size of
the data row:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 /
pageMem.pageSize() + 1) * 1.5 + 256 /*one page per bucket*/);
{code}
WDYT?
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900999#comment-16900999
]
Vyacheslav Koptilin commented on IGNITE-12042:
--
> If the user uses default failure handler all these cases are unrecoverable.
Yep, we are talking about the case when a custom failure handler is used.
> Check will not catch a problem (if datarow is big enough) - throwing OOME
>from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
In my opinion, this should be avoided. We need to take into account the size of
the data row:
{code:java}
boolean oomThreshold = (memorySize / pageMem.systemPageSize()) <
(datarow.size() / pageMem.systemPageSize() + nonEmptyPages * (8.0 /
pageMem.pageSize() + 1) * 1.5 + 256 /*one page per bucket*/);
{code}
WDYT?
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[ https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900995#comment-16900995 ] Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 12:46 PM: [~slava.koptilin], I think it would be even better to perform this check from PageMemoryNoStoreImpl#allocatePage for flags = FLAG_DATA, if possible. WDYT? was (Author: xtern): [~slava.koptilin], I think it would be even better to perform this check from PageMemoryImpl#allocatePage for flags = FLAG_DATA, if possible. WDYT? > Atempt to remove entries from fully populated data region may result in > IgineOutOfMemoryException > - > > Key: IGNITE-12042 > URL: https://issues.apache.org/jira/browse/IGNITE-12042 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing entries from non-persistent data region may require allocating a new > data page in order to move a tracked page from one bucket of the free-list to > another one. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[ https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900995#comment-16900995 ] Pavel Pereslegin commented on IGNITE-12042: --- [~slava.koptilin], I think it would be even better to perform this check from PageMemoryImpl#allocatePage for flags = FLAG_DATA, if possible. WDYT? > Atempt to remove entries from fully populated data region may result in > IgineOutOfMemoryException > - > > Key: IGNITE-12042 > URL: https://issues.apache.org/jira/browse/IGNITE-12042 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Removing entries from non-persistent data region may require allocating a new > data page in order to move a tracked page from one bucket of the free-list to > another one. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11925) [IEP-35] Migrage QueryMetrics
[ https://issues.apache.org/jira/browse/IGNITE-11925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-11925: - Fix Version/s: 2.8 > [IEP-35] Migrage QueryMetrics > - > > Key: IGNITE-11925 > URL: https://issues.apache.org/jira/browse/IGNITE-11925 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > After merging of IGNITE-11848 we should migrate `QueryMetrics` to the new > metric framework. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Gura reassigned IGNITE-11687:
Assignee: Dmitriy Govorukhin (was: Andrey Gura)
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Govorukhin
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 12:08 PM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see significant difference here, even with the proposed patch we can
prepare really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If the user configures custom failure handler case 1 and 2 are recoverable.
With 2 a memory leak is possible, but how can a user understand what was the
case?
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see significant difference here, even with the proposed patch we can
prepare really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If the user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 12:02 PM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see significant difference here, even with the proposed patch we can
prepare really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If the user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only
> one page was written, for example, and after that OutOfMemoryException was
> thrown by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If the user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 11:54 AM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only
> one page was written, for example, and after that OutOfMemoryException was
> thrown by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If the user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 11:53 AM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {{ensureFreeSpaceForInsert}} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {{PageMemoryNoStoreImpl#allocatePage}} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{{PageMemoryNoStoreImpl#allocatePage}}, but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {ensureFreeSpaceForInsert} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{PageMemoryNoStoreImpl#allocatePage}, but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 11:51 AM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see the difference here, even with the proposed patch we can prepare
really large data rows and will go in one of the following situations:
1. Check {ensureFreeSpaceForInsert} will catch a problem - throwing OOME from
DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if data row is big enough) - throwing OOME
from {PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if data row is big enough) - no OOME in
{PageMemoryNoStoreImpl#allocatePage}, but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but
with 2 a memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only
> one page was written, for example, and after that OutOfMemoryException was
> thrown by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see difference here, even with the proposed patch we can prepare really
large data rows and will go in one of the following situations:
1. Check (\{ensureFreeSpaceForInsert}) will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if datarow is big enough) - throwing OOME
from
{PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if datarow is big enough) - no OOME in
\{PageMemoryNoStoreImpl#allocatePage}
but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but a
memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-11985) .NET: CompiledQuery.Compile does not work with string parameters
[
https://issues.apache.org/jira/browse/IGNITE-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-11985:
Fix Version/s: 2.8
> .NET: CompiledQuery.Compile does not work with string parameters
>
>
> Key: IGNITE-11985
> URL: https://issues.apache.org/jira/browse/IGNITE-11985
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4, 2.5, 2.6, 2.7, 2.7.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
>
> String parameters always produce an exception, example:
> {code}
> CompiledQuery.Compile((string empName) => persons.Where(x => x.Value.Name ==
> empName))
> {code}
> Result:
> {code}
> System.InvalidOperationException: Error compiling query: entire LINQ
> expression should be specified within lambda passed to Compile method. Part
> of the query can't be outside the Compile method call.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin edited comment on IGNITE-12042 at 8/6/19 11:48 AM:
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only
> one page was written, for example, and after that OutOfMemoryException was
> thrown by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see difference here, even with the proposed patch we can prepare really
large data rows and will go in one of the following situations:
1. Check (\{ensureFreeSpaceForInsert}) will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if datarow is big enough) - throwing OOME
from
{PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if datarow is big enough) - no OOME in
\{PageMemoryNoStoreImpl#allocatePage}
but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but a
memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
was (Author: xtern):
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see difference here, even with the proposed patch we can prepare really
large data rows and will go in one of the following situations:
1. Check ({ensureFreeSpaceForInsert}}) will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if datarow is big enough) - throwing OOME
from {PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if datarow is big enough) - no OOME in
{PageMemoryNoStoreImpl#allocatePage} but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but a
memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900927#comment-16900927
]
Pavel Pereslegin commented on IGNITE-12042:
---
[~slava.koptilin],
> _Let's assume the size of an entry is greater than the page size and only one
> page was written, for example, and after that OutOfMemoryException was thrown
> by allocateDataPage()._
> _So, we have partially-written entry, and I am not sure it is a recoverable
> case._
I don't see difference here, even with the proposed patch we can prepare really
large data rows and will go in one of the following situations:
1. Check ({ensureFreeSpaceForInsert}}) will catch a problem - throwing OOME
from DatabaseSharedManager#ensureFreeSpaceForInsert.
2. Check will not catch a problem (if datarow is big enough) - throwing OOME
from {PageMemoryNoStoreImpl#allocatePage} (entry is partially written).
3. Check will not catch a problem (if datarow is big enough) - no OOME in
{PageMemoryNoStoreImpl#allocatePage} but we got OOME when clear() is called.
If a user configures custom failure handler case 1 and 2 are recoverable, but a
memory leak is possible.
If the user uses default failure handler all these cases are unrecoverable.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (IGNITE-11985) .NET: CompiledQuery.Compile does not work with string parameters
[
https://issues.apache.org/jira/browse/IGNITE-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-11985.
-
Resolution: Fixed
> .NET: CompiledQuery.Compile does not work with string parameters
>
>
> Key: IGNITE-11985
> URL: https://issues.apache.org/jira/browse/IGNITE-11985
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4, 2.5, 2.6, 2.7, 2.7.5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> String parameters always produce an exception, example:
> {code}
> CompiledQuery.Compile((string empName) => persons.Where(x => x.Value.Name ==
> empName))
> {code}
> Result:
> {code}
> System.InvalidOperationException: Error compiling query: entire LINQ
> expression should be specified within lambda passed to Compile method. Part
> of the query can't be outside the Compile method call.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900861#comment-16900861
]
Vyacheslav Koptilin commented on IGNITE-12042:
--
Hi [~xtern],
Well, technically it can be done in that way. I have only one following
concern. Let's assume the size of an entry is greater than the page size and
only one page was written, for example, and after that OutOfMemoryException was
thrown by allocateDataPage().
So, we have partially-written entry, and I am not sure it is a recoverable case.
It seems to me, the proposed change
(\{{IgniteCacheDatabaseSharedManager#ensureFreeSpaceForInsert}}) is a more
predictable way to handle this case, moreover it allows to use cache.get() and
cache.remove() operations even if {{IgniteOutOfMemoryException}} was thrown.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-6957) Reduce excessive int boxing when accessing cache by ID
[ https://issues.apache.org/jira/browse/IGNITE-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900802#comment-16900802 ] Stepachev Maksim commented on IGNITE-6957: -- Hi, I added IntMap for Integers and fixed contains calls. > Reduce excessive int boxing when accessing cache by ID > -- > > Key: IGNITE-6957 > URL: https://issues.apache.org/jira/browse/IGNITE-6957 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 2.3 >Reporter: Alexey Goncharuk >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Attachments: 2017-11-20_12-01-31.png > > Time Spent: 53h 20m > Remaining Estimate: 0h > > We have a number of places which lead to a large number of Integer > allocations when having a large number of caches and partitions. See the > image attached. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-6957) Reduce excessive int boxing when accessing cache by ID
[
https://issues.apache.org/jira/browse/IGNITE-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900801#comment-16900801
]
Ignite TC Bot commented on IGNITE-6957:
---
{panel:title=Branch: [pull/6536/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=4464956buildTypeId=IgniteTests24Java8_RunAll]
> Reduce excessive int boxing when accessing cache by ID
> --
>
> Key: IGNITE-6957
> URL: https://issues.apache.org/jira/browse/IGNITE-6957
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.8
>
> Attachments: 2017-11-20_12-01-31.png
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> We have a number of places which lead to a large number of Integer
> allocations when having a large number of caches and partitions. See the
> image attached.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12042) Atempt to remove entries from fully populated data region may result in IgineOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-12042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900773#comment-16900773
]
Pavel Pereslegin commented on IGNITE-12042:
---
Hello [~slava.koptilin].
Thank you - now this test is falling for me too.
Can we perform this check (ensureFreeSpaceForInsert) *only* when we
*allocating* a new page in free list (AbstractFreeList#allocateDataPage)? Will
it be more "accurate"?
We can throw OOME in "allocateDataPage" and handle it (re-throw) in RowStore
with failure handler.
AFAIK {{ensureFreeSpace}} cannot be performed in such a way because of
deadlocks but this check can.
> Atempt to remove entries from fully populated data region may result in
> IgineOutOfMemoryException
> -
>
> Key: IGNITE-12042
> URL: https://issues.apache.org/jira/browse/IGNITE-12042
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Removing entries from non-persistent data region may require allocating a new
> data page in order to move a tracked page from one bucket of the free-list to
> another one.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900771#comment-16900771 ] Sergey Antonov commented on IGNITE-11256: - [~gvvinblade] Could your review my changes related with datastreamer please? > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[
https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900765#comment-16900765
]
Ignite TC Bot commented on IGNITE-11256:
{panel:title=Branch: [pull/6423/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=4465635buildTypeId=IgniteTests24Java8_RunAll]
> Implement read-only mode for grid
> -
>
> Key: IGNITE-11256
> URL: https://issues.apache.org/jira/browse/IGNITE-11256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Should be triggered from control.sh utility.
> Useful for maintenance work, for example checking partition consistency
> (idle_verify)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-9694) Add tests to check that reading queries are not blocked on exchange events that don't change data visibility
[ https://issues.apache.org/jira/browse/IGNITE-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900712#comment-16900712 ] Ivan Bessonov commented on IGNITE-9694: --- [~Pavlukhin] nope, they're not done yet. It would be cool if someone actually implemented required optimizations or at least rechecked it the results in the table are still valid. I have no plans for that in the nearest future. > Add tests to check that reading queries are not blocked on exchange events > that don't change data visibility > > > Key: IGNITE-9694 > URL: https://issues.apache.org/jira/browse/IGNITE-9694 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > > In current implementation there might be situations where reading operation > waits, for example, exchange of client join event. Such events should not > block read operations. > In theory - the only operation that has to block reading (except for writing) > is "node left" for server (or baseline server in case of persistent setup). > Table shows current state of blocking, covered by test in this ticket: > > Partitioned cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| (x)| > (/)| (/)| > |Get All| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| > (x)| (/)| (/)| > |Scan| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (x)| (x)| (x)| (x)| (/)| (x)| (/)| (/)| > (/)| (/)| (/)| > Replicated cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| (x)| > (/)| (/)| > |Get All| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| > (x)| (/)| (/)| > |Scan| (x)| (x)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| (/)| > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-9694) Add tests to check that reading queries are not blocked on exchange events that don't change data visibility
[ https://issues.apache.org/jira/browse/IGNITE-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900701#comment-16900701 ] Ivan Pavlukhin commented on IGNITE-9694: [~ibessonov] as the ticket is resolved can substasks be resolved as well? > Add tests to check that reading queries are not blocked on exchange events > that don't change data visibility > > > Key: IGNITE-9694 > URL: https://issues.apache.org/jira/browse/IGNITE-9694 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > > In current implementation there might be situations where reading operation > waits, for example, exchange of client join event. Such events should not > block read operations. > In theory - the only operation that has to block reading (except for writing) > is "node left" for server (or baseline server in case of persistent setup). > Table shows current state of blocking, covered by test in this ticket: > > Partitioned cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| (x)| > (/)| (/)| > |Get All| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| > (x)| (/)| (/)| > |Scan| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (x)| (x)| (x)| (x)| (/)| (x)| (/)| (/)| > (/)| (/)| (/)| > Replicated cache: > || ||Start > Client||Stop > Client||Start > Server||Stop > Server||Start > Baseline||Stop > Baseline||Add > Baseline||Start > Cache||Stop > Cache||Create > Sql Index||Drop > Sql Index|| > |Get| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| (x)| > (/)| (/)| > |Get All| (x)| (x)| (x)| (x)| (/)| (x)| (x)| (x)| > (x)| (/)| (/)| > |Scan| (x)| (x)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| > |Sql Query| (/)| (/)| (/)| (/)| (/)| (/)| (/)| (/)| > (/)| (/)| (/)| > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
