[jira] [Updated] (IGNITE-12032) Server node prints exception when ODBC driver disconnects
[
https://issues.apache.org/jira/browse/IGNITE-12032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-12032:
-
Fix Version/s: 2.7.6
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Priority: Major
> Labels: newbie, usability
> Fix For: 2.7.6
>
>
> Whenever a process using ODBC clients is finished, it's printing in the
> node logs this exception:
> {code:java}
> *[07:45:19,559][SEVERE][grid-nio-worker-client-listener-1-#30][ClientListenerProcessor]
>
> Failed to process selector key [s
> es=GridSelectorNioSessionImpl [worker=ByteBufferNioClientWorker
> [readBuf=java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192
> ], super=AbstractNioClientWorker [idx=1, bytesRcvd=0, bytesSent=0,
> bytesRcvd0=0, bytesSent0=0, select=true, super=GridWo
> rker [name=grid-nio-worker-client-listener-1, igniteInstanceName=null,
> finished=false, heartbeatTs=1564289118230, hashCo
> de=1829856117, interrupted=false,
> runner=grid-nio-worker-client-listener-1-#30]]], writeBuf=null,
> readBuf=null, inRecove
> ry=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/0:0:0:0:0:0:0:1:10800, rmtAddr=/0:0:0:0:0:0:0:1:63697, cre
> ateTime=1564289116225, closeTime=0, bytesSent=1346, bytesRcvd=588,
> bytesSent0=0, bytesRcvd0=0, sndSchedTime=156428911623
> 5, lastSndTime=1564289116235, lastRcvTime=1564289116235, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioAsyn
> cNotifyFilter, GridNioCodecFilter [parser=ClientListenerBufferedParser,
> directMode=false]], accepted=true, markedForClos
> e=false]]]
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:11
>
> 04)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNi
>
> oServer.java:2389)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:215
>
> 6)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1797)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)*
> {code}
> It's absolutely normal behavior when ODBC client disconnects from the node,
> so, we shouldn't print exception in the log. We should replace it with
> something like INFO message about ODBC client disconnection.
> Thread from user list:
> http://apache-ignite-users.70518.x6.nabble.com/exceptions-in-Ignite-node-when-a-thin-client-process-ends-td28970.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (IGNITE-6611) Optionally disable binary metadata for type
[
https://issues.apache.org/jira/browse/IGNITE-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-6611:
Fix Version/s: 3.0
> Optionally disable binary metadata for type
> ---
>
> Key: IGNITE-6611
> URL: https://issues.apache.org/jira/browse/IGNITE-6611
> Project: Ignite
> Issue Type: Task
> Components: binary
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 3.0
>
>
> We need to introduce special metadata mode for type - without metadata. This
> way we will have a kind of "flexible" type with no restrictions. This will be
> especially useful for SQL-related types where schema changes are possible
> (e.g. ADD COLUMN -> DROP COLUMN).
> Public part should be exposed to:
> 1) {{BinaryTypeConfiguration}}
> 2) {{BinaryType}} - add a flag here.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-6611) Optionally disable binary metadata for type
[
https://issues.apache.org/jira/browse/IGNITE-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903383#comment-16903383
]
Denis Magda commented on IGNITE-6611:
-
This is to be addressed in Ignite 3.0 that will go with a new API and the
storage format separated from the serialization approach.
> Optionally disable binary metadata for type
> ---
>
> Key: IGNITE-6611
> URL: https://issues.apache.org/jira/browse/IGNITE-6611
> Project: Ignite
> Issue Type: Task
> Components: binary
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Priority: Major
>
> We need to introduce special metadata mode for type - without metadata. This
> way we will have a kind of "flexible" type with no restrictions. This will be
> especially useful for SQL-related types where schema changes are possible
> (e.g. ADD COLUMN -> DROP COLUMN).
> Public part should be exposed to:
> 1) {{BinaryTypeConfiguration}}
> 2) {{BinaryType}} - add a flag here.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[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=16903271#comment-16903271
]
Pavel Tupitsyn commented on IGNITE-12033:
-
[~dmagda] yes, that's what I propose.
The discussion is continued on Dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> .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
> Fix For: 2.7.6
>
>
> 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] [Commented] (IGNITE-12054) Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903210#comment-16903210 ] Denis Magda commented on IGNITE-12054: -- Raised to the BLOCKER as long as our Data Frames integration doesn't work with the latest Spark version. > Upgrade Spark module to 2.4 > --- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.7.5 >Reporter: Denis Magda >Priority: Blocker > Fix For: 2.7.6 > > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-12054) Upgrade Spark module to 2.4
[ https://issues.apache.org/jira/browse/IGNITE-12054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-12054: - Priority: Blocker (was: Major) > Upgrade Spark module to 2.4 > --- > > Key: IGNITE-12054 > URL: https://issues.apache.org/jira/browse/IGNITE-12054 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.7.5 >Reporter: Denis Magda >Priority: Blocker > Fix For: 2.7.6 > > > Users can't use APIs that are already available in Spark 2.4: > https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite > Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as > a separate module that can support multiple Spark versions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12054) Upgrade Spark module to 2.4
Denis Magda created IGNITE-12054: Summary: Upgrade Spark module to 2.4 Key: IGNITE-12054 URL: https://issues.apache.org/jira/browse/IGNITE-12054 Project: Ignite Issue Type: Task Components: spark Affects Versions: 2.7.5 Reporter: Denis Magda Fix For: 2.7.6 Users can't use APIs that are already available in Spark 2.4: https://stackoverflow.com/questions/57392143/persisting-spark-dataframe-to-ignite Let's upgrade Spark from 2.3 to 2.4 until we extract the Spark Integration as a separate module that can support multiple Spark versions. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (IGNITE-11953) BTree corruption caused by byte array values
[
https://issues.apache.org/jira/browse/IGNITE-11953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-11953:
-
Fix Version/s: (was: 2.8)
2.7.6
> BTree corruption caused by byte array values
>
>
> Key: IGNITE-11953
> URL: https://issues.apache.org/jira/browse/IGNITE-11953
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.7.6
>
>
> In some cases for caches with cache group, we can get BTree corruption
> exception.
> {code}
> 09:53:58,890][SEVERE][sys-stripe-10-#11][] Critical system error detected.
> Will be handled accordingly to configured handler [hnd=CustomFailureHandler
> [ignoreCriticalErrors=false, disabled=false][StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0]], failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=class o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing
> a transaction has produced runtime exception]]class
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
> Committing a transaction has produced runtime exception
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:922)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.localFinish(GridDhtTxLocalAdapter.java:799)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.localFinish(GridDhtTxLocal.java:608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finishTx(GridDhtTxLocal.java:478)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitDhtLocalAsync(GridDhtTxLocal.java:535)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:1055)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:931)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:887)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$200(IgniteTxHandler.java:117)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:209)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1568)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1196)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:504)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=427,
> val=Grkg1DUF3yQE6tC9Se50mi5w.T, hasValBytes=true], hash=1872857770,
> cacheId=-420893003]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1811)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1620)
> at
>
[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=16903193#comment-16903193
]
Denis Magda commented on IGNITE-12033:
--
[~ptupitsyn], let's fix it in Java instead?
> .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
> Fix For: 2.7.6
>
>
> 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] [Updated] (IGNITE-9562) Destroyed cache that resurrected on an old offline node breaks PME
[
https://issues.apache.org/jira/browse/IGNITE-9562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9562:
---
Summary: Destroyed cache that resurrected on an old offline node breaks PME
(was: Destroyed cache that resurrected on a old offline node breaks PME)
> Destroyed cache that resurrected on an 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
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2249)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
>
[jira] [Commented] (IGNITE-12052) GridDhtTxPrepareFuture should print transaction in case of assertion error
[
https://issues.apache.org/jira/browse/IGNITE-12052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903105#comment-16903105
]
Ignite TC Bot commented on IGNITE-12052:
{panel:title=Branch: [pull/6761/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=4479591]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
[Artifacts publishing failed]
|https://ci.ignite.apache.org/viewLog.html?buildId=4479598]]
{color:#d04437}Cache (Failover) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4479570]]
* IgniteCacheFailoverTestSuite3:
IgniteCachePutRetryTransactionalSelfTest.testExplicitTransactionRetriesStoreEnabled
- 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=4479626buildTypeId=IgniteTests24Java8_RunAll]
> GridDhtTxPrepareFuture should print transaction in case of assertion error
> --
>
> Key: IGNITE-12052
> URL: https://issues.apache.org/jira/browse/IGNITE-12052
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment we getting exception, if assertion error occurs:
> {noformat}
> 2019-07-13
> 20:23:00.769[ERROR][srvc-deploy-#299%xxx_GRID%xxxGridNodeName%][o.a.i.i.p.s.GridServiceProcessor]
> Error when executing service: null
> java.lang.AssertionError: Got removed exception on entry with dht local
> candidate: IgniteTxEntry []
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.sendPrepareRequests(GridDhtTxPrepareFuture.java:1368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1276)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:704)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:699)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:153)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:69)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
> at
> org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:276)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.init(GridDhtForceKeysFuture.java:217)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:523)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:521)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at
>
[jira] [Updated] (IGNITE-12053) Total time threads parked if checkpoint throttling occurred
[ https://issues.apache.org/jira/browse/IGNITE-12053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12053: - Description: Currently, threads that generate dirty pages during an ongoing checkpoint are throttled. User should have the ability to see total time threads are parked during the checkpoint writing marked pages. See `PagesWriteThrottle` class as a start point of investigation. was: Currently, threads that generate dirty pages during an ongoing checkpoint are throttled. User should have the ability to see total time threads are parked during the checkpoint writing marked pages. Such a metric must be dropped down at checkpoint end. See `PagesWriteThrottle` class as a start point of investigation. > Total time threads parked if checkpoint throttling occurred > --- > > Key: IGNITE-12053 > URL: https://issues.apache.org/jira/browse/IGNITE-12053 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > Currently, threads that generate dirty pages during an ongoing checkpoint are > throttled. User should have the ability to see total time threads are parked > during the checkpoint writing marked pages. > See `PagesWriteThrottle` class as a start point of investigation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-12053) Total time threads parked if checkpoint throttling occurred
Maxim Muzafarov created IGNITE-12053: Summary: Total time threads parked if checkpoint throttling occurred Key: IGNITE-12053 URL: https://issues.apache.org/jira/browse/IGNITE-12053 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov Fix For: 2.8 Currently, threads that generate dirty pages during an ongoing checkpoint are throttled. User should have the ability to see total time threads are parked during the checkpoint writing marked pages. Such a metric must be dropped down at checkpoint end. See `PagesWriteThrottle` class as a start point of investigation. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902941#comment-16902941
]
Anton Kalashnikov commented on IGNITE-12048:
[~DmitriyGovorukhin] thanks for your changes. Looks good to me.
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
> Reduce test time execution (scale factor for a long-running tests)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902938#comment-16902938
]
Dmitriy Govorukhin commented on IGNITE-12048:
-
Looks like it is the same test as in master [link to
test|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1194594567102543889=testDetails]].
Now name generated by parameters.
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
> Reduce test time execution (scale factor for a long-running tests)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902938#comment-16902938
]
Dmitriy Govorukhin edited comment on IGNITE-12048 at 8/8/19 12:50 PM:
--
Looks like it is the same test as in master
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1194594567102543889=testDetails].
Now name generated by parameters.
was (Author: dmitriygovorukhin):
Looks like it is the same test as in master [link to
test|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1194594567102543889=testDetails]].
Now name generated by parameters.
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
> Reduce test time execution (scale factor for a long-running tests)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (IGNITE-12048) Bugs & tests fixes
[
https://issues.apache.org/jira/browse/IGNITE-12048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902936#comment-16902936
]
Ignite TC Bot commented on IGNITE-12048:
{panel:title=Branch: [pull/6756/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=4478842]]
* IgnitePdsMvccTestSuite2:
IgniteNodeStoppedDuringDisableWALTest.test[AFTER_DISABLE_WAL] - History for
base branch is absent.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4476523buildTypeId=IgniteTests24Java8_RunAll]
> Bugs & tests fixes
> --
>
> Key: IGNITE-12048
> URL: https://issues.apache.org/jira/browse/IGNITE-12048
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Page replacement can reload invalid page during checkpoint
> There is a race between {{writeCheckpointPages}} and page replacement process:
> * Checkpointer thread begins a checkpoint
> * Checkpointer thread calls {{getPageForCheckpoint()}}, which will copy page
> content *and clear dirty flag*
> * Page replacement tries to find a page for replacement and chooses this
> page, the page is thrown away
> * Before the page is written back to the store, the page is acquired again.
> As a result, an older copy of the page is brought back to memory, which
> causes all kinds of corruption exceptions and assertions.
>
> checkpointReadLock() may hang during node stop
> I got this hang during one of PDS (Indexing) runs (thread-dump is attached).
> The following code hang:
> {code:java}
> checkpointer.wakeupForCheckpoint(0, "too many dirty pages").cpBeginFut
> .getUninterruptibly();
> {code}
> It looks like {{wakeupForCheckpoint}} can be called after the checkpointer is
> stopped and {{cpBeginFut}} will be never completed.
>
> Fixed
> ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_CachesInfo1
> Fixed *.testFailAfterStart
> Reduce test time execution (scale factor for a long-running tests)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12052) GridDhtTxPrepareFuture should print transaction in case of assertion error
Sergey Antonov created IGNITE-12052:
---
Summary: GridDhtTxPrepareFuture should print transaction in case
of assertion error
Key: IGNITE-12052
URL: https://issues.apache.org/jira/browse/IGNITE-12052
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.8
At the moment we getting exception, if assertion error occurs:
{noformat}
2019-07-13
20:23:00.769[ERROR][srvc-deploy-#299%xxx_GRID%xxxGridNodeName%][o.a.i.i.p.s.GridServiceProcessor]
Error when executing service: null
java.lang.AssertionError: Got removed exception on entry with dht local
candidate: IgniteTxEntry []
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.sendPrepareRequests(GridDhtTxPrepareFuture.java:1368)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1276)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.access$000(GridDhtTxPrepareFuture.java:109)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:704)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture$2.apply(GridDhtTxPrepareFuture.java:699)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:153)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onDone(GridDhtForceKeysFuture.java:69)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:276)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.init(GridDhtForceKeysFuture.java:217)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:523)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$2.apply(GridDhtPreloader.java:521)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture.onDone(GridAffinityAssignmentCache.java:850)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture.onDone(GridAffinityAssignmentCache.java:834)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at
[jira] [Updated] (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 updated IGNITE-12033:
Summary: .NET: Callbacks from striped pool due to async/await may hang
cluster (was: .Net callbacks from striped pool due to async/await may hang
cluster)
> .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
> Fix For: 2.7.6
>
>
> 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] [Commented] (IGNITE-12051) Update javadoc for the IgniteKernal class
[
https://issues.apache.org/jira/browse/IGNITE-12051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16902918#comment-16902918
]
Maxim Muzafarov commented on IGNITE-12051:
--
Since these changes are related only to javadoc comments, I see no reasons to
provide TC.Bot visa.
Build Apache Ignite, JavaDoc, Check Code Style suites are green.
> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;
> /** Long jvm pause detector. */
> private LongJVMPauseDetector longJVMPauseDetector;
> /** Scheduler. */
> private IgniteScheduler scheduler;
> /** Stop guard. */
> private final AtomicBoolean stopGuard = new AtomicBoolean();
> {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=16901302#comment-16901302
]
Vyacheslav Koptilin edited comment on IGNITE-12042 at 8/8/19 10:34 AM:
---
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.pageSize() + nonEmptyPages * (8.0 * 1.5 /
pageMem.pageSize() + 1) + 256 /one page per bucket/);{code}
where:
{{memorySize / pageMem.systemPageSize()) - total pages}}
{{datarow.size() / pageMem.pageSize() - 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 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. :)}}
> 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-12051) Update javadoc for the IgniteKernal class
[
https://issues.apache.org/jira/browse/IGNITE-12051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12051:
-
Ignite Flags: (was: Docs Required)
> Update javadoc for the IgniteKernal class
> -
>
> Key: IGNITE-12051
> URL: https://issues.apache.org/jira/browse/IGNITE-12051
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>
> Update all ambiguous an empty javadoc comments, such as:
> {code}
> /** */
> /** Periodic starvation check interval. */
> private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;
> /** Long jvm pause detector. */
> private LongJVMPauseDetector longJVMPauseDetector;
> /** Scheduler. */
> private IgniteScheduler scheduler;
> /** Stop guard. */
> private final AtomicBoolean stopGuard = new AtomicBoolean();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12051) Update javadoc for the IgniteKernal class
Maxim Muzafarov created IGNITE-12051:
Summary: Update javadoc for the IgniteKernal class
Key: IGNITE-12051
URL: https://issues.apache.org/jira/browse/IGNITE-12051
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Update all ambiguous an empty javadoc comments, such as:
{code}
/** */
/** Periodic starvation check interval. */
private static final long PERIODIC_STARVATION_CHECK_FREQ = 1000 * 30;
/** Long jvm pause detector. */
private LongJVMPauseDetector longJVMPauseDetector;
/** Scheduler. */
private IgniteScheduler scheduler;
/** Stop guard. */
private final AtomicBoolean stopGuard = new AtomicBoolean();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (IGNITE-12050) MVCC test suites resurrection
Ivan Pavlukhin created IGNITE-12050: --- Summary: MVCC test suites resurrection Key: IGNITE-12050 URL: https://issues.apache.org/jira/browse/IGNITE-12050 Project: Ignite Issue Type: Bug Components: mvcc Reporter: Ivan Pavlukhin Assignee: Ivan Pavlukhin Need to resurrect MVCC test suites for RunAll. Mute all tests with fail rate more 50% And start use scale factor for MVCC tests to reduce execution time. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
