[jira] [Commented] (IGNITE-7414) Cluster restart may lead to cluster activation error
[
https://issues.apache.org/jira/browse/IGNITE-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944125#comment-16944125
]
Denis A. Magda commented on IGNITE-7414:
[~agoncharuk], is this issue still relevant?
> Cluster restart may lead to cluster activation error
>
>
> Key: IGNITE-7414
> URL: https://issues.apache.org/jira/browse/IGNITE-7414
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
>Reporter: Vyacheslav Koptilin
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: Reproducer.java
>
>
> Attempt to execute the following reproducer twice result in an error (please
> see attached)
> {code}
> public static void main(String[] args) throws IgniteException {
> Ignite ignite = Ignition.start(createIgniteConfiguration());
> ignite.active(true);
> CacheConfiguration cacheCfg = new CacheConfiguration("test-cache");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> cacheCfg.setDataRegionName("inmemory");
> cacheCfg.setIndexedTypes(Integer.class, String.class);
> IgniteCache cache = ignite.getOrCreateCache(cacheCfg);
> cache.put(42, "value-42");
> ignite.close();
> }
> private static IgniteConfiguration createIgniteConfiguration() {
> IgniteConfiguration ignCfg = IgniteConfiguration();
> ...
> DataStorageConfiguration dc = new DataStorageConfiguration();
> // persistence enabled region
> DataRegionConfiguration persistenceRegion = new
> DataRegionConfiguration();
> persistenceRegion.setName("persistence");
> persistenceRegion.setPersistenceEnabled(true);
> // persistence disabled region
> DataRegionConfiguration inmemoryRegion = new
> DataRegionConfiguration();
> inmemoryRegion.setName("inmemory");
> inmemoryRegion.setInitialSize(100L * 1024 * 1024);
> inmemoryRegion.setMaxSize(500L * 1024 * 1024);
> inmemoryRegion.setPersistenceEnabled(false);
> dc.setDataRegionConfigurations(persistenceRegion, inmemoryRegion);
> ignCfg.setDataStorageConfiguration(dc);
> return ignCfg;
> }
> {code}
> The second execution failed with the exception as follows:
> {code}
> [2018-01-15
> 17:12:52,431][ERROR][exchange-worker-#42%test-grid%][GridDhtPartitionsExchangeFuture]
> Failed to activate node components
> [nodeId=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, client=false,
> topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1]]
> class org.apache.ignite.IgniteCheckedException: Failed to find cache group
> descriptor [grpId=623628935]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Exception in thread "main" class org.apache.ignite.IgniteException: Failed to
> activate cluster
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3318)
> at org.apache.ignite.examples.Reproducer.main(Reproducer.java:33)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to activate
> cluster
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> find cache group descriptor [grpId=623628935]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602)
> at
>
[jira] [Resolved] (IGNITE-6993) Document SMTP server documentation for Web Console
[ https://issues.apache.org/jira/browse/IGNITE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda resolved IGNITE-6993. Release Note: Closing as won't fix. No longer relevant. Resolution: Won't Fix > Document SMTP server documentation for Web Console > -- > > Key: IGNITE-6993 > URL: https://issues.apache.org/jira/browse/IGNITE-6993 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Denis A. Magda >Assignee: Artem Budnikov >Priority: Critical > Fix For: 2.8 > > > Document how to configure a custom SMTP server for Web Console on this domain > under "Ignite Web Console" section: > https://apacheignite-tools.readme.io/docs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11942) IGFS and Hadoop Accelerator Discontinuation
[ https://issues.apache.org/jira/browse/IGNITE-11942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944117#comment-16944117 ] Denis A. Magda commented on IGNITE-11942: - [~azinoviev], could we please decouple TensorFlow and IGFS throughout 2.8? It would be nice to finish the story with IGFS/Hadoop. > IGFS and Hadoop Accelerator Discontinuation > --- > > Key: IGNITE-11942 > URL: https://issues.apache.org/jira/browse/IGNITE-11942 > Project: Ignite > Issue Type: Task >Reporter: Denis A. Magda >Priority: Blocker > Fix For: 2.8 > > > The community has voted for the following decision: > * IGFS and In-Memory Hadoop Accelerator components are to be discontinued and > no longer supported by the community > * The existing source code of IGFS and In-Memory Hadoop Accelerator is to be > removed from Ignite master. Before that, a special branch like > "ignite-igfs-and-hadoop-accelerator" to be forked off the master in order to > preserve the sources in Git history for those who might need it. > The voting thread: > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Complete-Discontinuation-of-IGFS-and-Hadoop-Accelerator-td42405.html > Once the changes are made for Ignite 2.8, please contact Denis Magda to > update a public documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda updated IGNITE-7595: --- Fix Version/s: (was: 2.8) > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Critical > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944115#comment-16944115 ] Denis A. Magda commented on IGNITE-7595: [~mmuzaf], is removed a target version at all as long as it's unclear if and when the community will be ready to change the docs. > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Critical > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7595) Find and switch to alternate documentation engine
[ https://issues.apache.org/jira/browse/IGNITE-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda updated IGNITE-7595: --- Priority: Minor (was: Critical) > Find and switch to alternate documentation engine > - > > Key: IGNITE-7595 > URL: https://issues.apache.org/jira/browse/IGNITE-7595 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Denis A. Magda >Priority: Minor > Attachments: Docusaurus-GitBook comparison.docx, > readme-markdown-mapping.xlsx > > > Current readme.io documentation has many drawbacks that make the life of > Ignite technical writers hard. Some of the problems are: > * Each "version" is just a copy of the previous one. When fixing something, > you have to update > all the versions. > * No good way to review changes. > * "Propose edit" functionality is a not suitable for review. You can only > accept or reject an > edit, no way to communicate with a contributor, etc > * There is no way to prevent Google from indexing old documentation > versions. Thus, it's common to come across old doc version in a google > search. > We might consider GitHub based documentation or another approach. The > discussion is here: > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled
[ https://issues.apache.org/jira/browse/IGNITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944047#comment-16944047 ] Roman Shtykh commented on IGNITE-6444: -- [~mmuzaf] I am not working on this issue now. Unassigned. Let's move it to the next one. > Validate that copyOnRead flag is configured with on-heap cache enabled > -- > > Key: IGNITE-6444 > URL: https://issues.apache.org/jira/browse/IGNITE-6444 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Major > Labels: usability > Fix For: 2.8 > > > Link to the user-list discussion: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-CopyOnRead-Problem-td17009.html > It makes sense to validate the flag and print out a warning if on-heap cache > is disabled. I do not think that we should prevent node from startup because > this may break existing deployments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled
[ https://issues.apache.org/jira/browse/IGNITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-6444: Assignee: (was: Roman Shtykh) > Validate that copyOnRead flag is configured with on-heap cache enabled > -- > > Key: IGNITE-6444 > URL: https://issues.apache.org/jira/browse/IGNITE-6444 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Priority: Major > Labels: usability > Fix For: 2.8 > > > Link to the user-list discussion: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-CopyOnRead-Problem-td17009.html > It makes sense to validate the flag and print out a warning if on-heap cache > is disabled. I do not think that we should prevent node from startup because > this may break existing deployments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-5829) Writing entry contents to WAL only single time
[ https://issues.apache.org/jira/browse/IGNITE-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-5829: Fix Version/s: (was: 2.8) 2.9 > Writing entry contents to WAL only single time > -- > > Key: IGNITE-5829 > URL: https://issues.apache.org/jira/browse/IGNITE-5829 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.9 > > > Currently we write entry contents 2 times: once in logical record and once > again when we write data page update records. We should do that only once. In > data page updates we can write only a reference to the logical update record > but not the whole entry contents. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10010) Node halted if second node was stopped, then cache destroyed, then second node returned
[
https://issues.apache.org/jira/browse/IGNITE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-10010:
-
Priority: Critical (was: Blocker)
> Node halted if second node was stopped, then cache destroyed, then second
> node returned
> ---
>
> Key: IGNITE-10010
> URL: https://issues.apache.org/jira/browse/IGNITE-10010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: PersistenceNodeRestartAfterCacheDropSelfTest.java,
> ignite-gridparitition-nullpointer.zip
>
>
> 1. Start 2 nodes with PDS
> 2. Activate cluster
> 3. Connect sqlline.
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 5. Stop node 1
> 6. Drop table {{drop table t1;}}
> 7. Start node 1
> 8. Node 2 stopped by handler:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
> Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> 2018 Copyright(C) Apache Software Foundation
> [18:04:22,745][INFO][main][IgniteKernal]
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2018 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
> [18:04:22,745][INFO][main][IgniteKernal] Config URL:
> file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
> [18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
> lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
> igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
> oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
> igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
> T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
> fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabl
> ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
> metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
> ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
> OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
> segChkFreq=1, commSpi=TcpCommunicationSp
> i [connectGate=null,
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
> locHost=null, locPort=47100, locPortRange=1
> 00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, r
> econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
> ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
> filterReachableAddresses=false, ackSndThreshold=32, una
> ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
> lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count =
> 1], stopping=false], evtSpi=org.apache.ignit
> e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
> deploySpi=LocalDeploymentSpi [], indexingSp
> i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f,
> addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encry
> ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
> rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
> rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
> dfltTxTimeout=0, txTimeoutOnPartitionMapExch
> ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
> tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
> lse], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=127.0.0.
> 1, timeSrvPortBase=31100, timeSrvPortRange=100,
> failureDetectionTimeout=1, sysWorkerBlockedTimeout=null, clientFailu
> reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
> connectorCfg=ConnectorConfiguration [jettyPath=null, hos
> t=null, port=11211, noDelay=true, directBuf=false, sndBufSize=32768,
> rcvBufSize=32768,
[jira] [Comment Edited] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943806#comment-16943806
]
Ivan Rakov edited comment on IGNITE-6930 at 10/3/19 6:23 PM:
-
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from highest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
Another option is choosing MAX_SIZE dynamically based on process -Xmx and local
(caches * partitions) count.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
Another option: clear() long lists, but remember number of flush calls. If
absolutely empty cache bucket was flushed for a certain number of times (e.g.
10) in a row, then long lists can be finally released and collected as garbage.
was (Author: ivan.glukos):
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from highest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
Another option is choosing MAX_SIZE dynamically based on process -Xmx and local
(caches * partitions) count.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
>
[jira] [Comment Edited] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943806#comment-16943806
]
Ivan Rakov edited comment on IGNITE-6930 at 10/3/19 6:19 PM:
-
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from highest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
Another option is choosing MAX_SIZE dynamically based on process -Xmx and local
(caches * partitions) count.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
was (Author: ivan.glukos):
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
Another option is choosing MAX_SIZE dynamically based on process -Xmx and local
(caches * partitions) count.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord
[jira] [Comment Edited] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943806#comment-16943806
]
Ivan Rakov edited comment on IGNITE-6930 at 10/3/19 6:18 PM:
-
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
Another option is choosing MAX_SIZE dynamically based on process -Xmx and local
(caches * partitions) count.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
was (Author: ivan.glukos):
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=30,
> chainSize=0, pos=null, type=DATA_PAGE_REMOVE_RECORD]]]
> 8. [F] PagesListRemovePageRecord
[jira] [Comment Edited] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943806#comment-16943806
]
Ivan Rakov edited comment on IGNITE-6930 at 10/3/19 6:17 PM:
-
[~alex_pl], I've taken a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
was (Author: ivan.glukos):
[~alex_pl], I've take a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=30,
> chainSize=0, pos=null, type=DATA_PAGE_REMOVE_RECORD]]]
> 8. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010008, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770,
[jira] [Commented] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943808#comment-16943808
]
Ivan Rakov commented on IGNITE-6930:
[~DmitriyGovorukhin] Do you want to take a look as well?
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=30,
> chainSize=0, pos=null, type=DATA_PAGE_REMOVE_RECORD]]]
> 8. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010008, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010008, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 9. [F] DataPageSetFreeListPageRecord [freeListPage=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=37,
> chainSize=0, pos=null, type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 10. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010006,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 11. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710662,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> {code}
> If you sum all space required for operation (size in p.3 is shown incorrectly
> here), you will see that data update required ~300 bytes, so do free list
> update!
> *Proposed solution*
> 1) Optionally do not write free list updates to WAL
> 2) In case of node restart we start with empty free lists, so data inserts
> will have to allocate new pages
> 3) When old data page is read, add it to the free list
> 4) Start a background thread which will iterate over all old data pages and
> re-create the free list, so that eventually all data pages are tracked.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943806#comment-16943806
]
Ivan Rakov commented on IGNITE-6930:
[~alex_pl], I've take a look. Some comments:
1) testRestoreFreeListCorrectlyAfterRandomStop - why do we need to disable
caching here?
2) testFreeListUnderLoadMultipleCheckpoints - what is being tested? I think, we
need to add comment that test is intended to cover weakened pageId != 0
assertion.
3) MAX_SIZE, STRIPES_COUNT - don't you think that we should make these options
configurable?
4) How did you choose 64 and 4 as defaults? Can you share some benchmarks? I
think that 64 might be on overkill: in data load scenario, data pages traverse
from biggest to lowest buckets by turn. I don't think that pages are likely to
heavily accumulate in a certain bucket; maybe 8 as MAX_SIZE would show the same
performance boost.
5) PagesList.PagesCache#flush: do we need to garbage-collect all allocated long
lists when we flush page cache? We can just clear() them and reuse again after
the checkpoint. It should reduce GC pressure.
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=30,
> chainSize=0, pos=null, type=DATA_PAGE_REMOVE_RECORD]]]
> 8. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010008, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010008, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 9. [F] DataPageSetFreeListPageRecord [freeListPage=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=37,
> chainSize=0, pos=null, type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 10. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010006,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 11. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710662,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> {code}
> If you sum all space required for operation (size in p.3 is shown incorrectly
> here), you will see that data update required ~300 bytes, so do free list
> update!
> *Proposed solution*
> 1) Optionally do not write free list updates to WAL
> 2) In
[jira] [Updated] (IGNITE-11868) GridClient#data() should be deprecated/removed.
[
https://issues.apache.org/jira/browse/IGNITE-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov updated IGNITE-11868:
Release Note: (was: [~slava.koptilin] [~kcheng.mvp] Thanks for your
contribution and review!
Merged to master.)
> GridClient#data() should be deprecated/removed.
> ---
>
> Key: IGNITE-11868
> URL: https://issues.apache.org/jira/browse/IGNITE-11868
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: kcheng.mvp
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems that {{GridClient#data()}} does not make sense after IGNITE-3488 and
> therefore it can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11868) GridClient#data() should be deprecated/removed.
[
https://issues.apache.org/jira/browse/IGNITE-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943766#comment-16943766
]
Ivan Rakov commented on IGNITE-11868:
-
[~slava.koptilin] [~kcheng.mvp] Thanks for your contribution and review!
Merged to master.
> GridClient#data() should be deprecated/removed.
> ---
>
> Key: IGNITE-11868
> URL: https://issues.apache.org/jira/browse/IGNITE-11868
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: kcheng.mvp
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> It seems that {{GridClient#data()}} does not make sense after IGNITE-3488 and
> therefore it can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9664) Found unexpected checkpoint marker after node deactivation.
[ https://issues.apache.org/jira/browse/IGNITE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-9664: --- Fix Version/s: (was: 2.8) 2.9 > Found unexpected checkpoint marker after node deactivation. > --- > > Key: IGNITE-9664 > URL: https://issues.apache.org/jira/browse/IGNITE-9664 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.9 > > Attachments: err.log > > > Found numerous messages : _Found unexpected checkpoint marker_ in ignite.log > (partially attached) , this errors appeared after node segmentation (i`m > using zookeeperDiscoverySpi), next node activation lead to %subj% error > message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9664) Found unexpected checkpoint marker after node deactivation.
[ https://issues.apache.org/jira/browse/IGNITE-9664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943752#comment-16943752 ] Stanilovsky Evgeny commented on IGNITE-9664: [~mmuzaf] hope so, cause we still have no reproducer here. > Found unexpected checkpoint marker after node deactivation. > --- > > Key: IGNITE-9664 > URL: https://issues.apache.org/jira/browse/IGNITE-9664 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Stanilovsky Evgeny >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.9 > > Attachments: err.log > > > Found numerous messages : _Found unexpected checkpoint marker_ in ignite.log > (partially attached) , this errors appeared after node segmentation (i`m > using zookeeperDiscoverySpi), next node activation lead to %subj% error > message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5829) Writing entry contents to WAL only single time
[ https://issues.apache.org/jira/browse/IGNITE-5829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943697#comment-16943697 ] Pavel Kovalenko commented on IGNITE-5829: - [~mmuzaf] The issue is still actual. We should move it to next release. > Writing entry contents to WAL only single time > -- > > Key: IGNITE-5829 > URL: https://issues.apache.org/jira/browse/IGNITE-5829 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.8 > > > Currently we write entry contents 2 times: once in logical record and once > again when we write data page update records. We should do that only once. In > data page updates we can write only a reference to the logical update record > but not the whole entry contents. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10010) Node halted if second node was stopped, then cache destroyed, then second node returned
[
https://issues.apache.org/jira/browse/IGNITE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943696#comment-16943696
]
Pavel Kovalenko commented on IGNITE-10010:
--
[~mmuzaf] There is fail-fast approach implemented in
https://issues.apache.org/jira/browse/IGNITE-9562 (that ticket is similar to
current). Changes disallow node join if it has persisted caches not presented
in the cluster. I think we can decrease priority to Critical at least.
> Node halted if second node was stopped, then cache destroyed, then second
> node returned
> ---
>
> Key: IGNITE-10010
> URL: https://issues.apache.org/jira/browse/IGNITE-10010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Blocker
> Fix For: 2.8
>
> Attachments: PersistenceNodeRestartAfterCacheDropSelfTest.java,
> ignite-gridparitition-nullpointer.zip
>
>
> 1. Start 2 nodes with PDS
> 2. Activate cluster
> 3. Connect sqlline.
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 5. Stop node 1
> 6. Drop table {{drop table t1;}}
> 7. Start node 1
> 8. Node 2 stopped by handler:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
> Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> 2018 Copyright(C) Apache Software Foundation
> [18:04:22,745][INFO][main][IgniteKernal]
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2018 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
> [18:04:22,745][INFO][main][IgniteKernal] Config URL:
> file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
> [18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
> lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
> igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
> oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
> igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
> T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
> fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabl
> ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
> metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
> ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
> OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
> segChkFreq=1, commSpi=TcpCommunicationSp
> i [connectGate=null,
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
> locHost=null, locPort=47100, locPortRange=1
> 00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, r
> econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
> ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
> filterReachableAddresses=false, ackSndThreshold=32, una
> ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
> lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count =
> 1], stopping=false], evtSpi=org.apache.ignit
> e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
> deploySpi=LocalDeploymentSpi [], indexingSp
> i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f,
> addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encry
> ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
> rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
> rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
> dfltTxTimeout=0, txTimeoutOnPartitionMapExch
> ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
> tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
> lse], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=127.0.0.
> 1, timeSrvPortBase=31100, timeSrvPortRange=100,
> failureDetectionTimeout=1,
[jira] [Commented] (IGNITE-12231) RollbackRecord's must be flushed after logging to WAL
[
https://issues.apache.org/jira/browse/IGNITE-12231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943686#comment-16943686
]
Ivan Rakov commented on IGNITE-12231:
-
[~agura] looks good.
> RollbackRecord's must be flushed after logging to WAL
> -
>
> Key: IGNITE-12231
> URL: https://issues.apache.org/jira/browse/IGNITE-12231
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Every record or records batch logged to WAL must call {{wal().flush()}} in
> order to save data on storage device.
> {{TxPartitionCounterStateOnePrimaryTwoBackupsHistoryRebalanceTest.testPartialPrepare_2TX_1_1}}
> test fails periodically with disabled MMAP.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-8996) Web console: Dropdown pupup menu is scrolled with page body on modal dialog.
[ https://issues.apache.org/jira/browse/IGNITE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-8996. > Web console: Dropdown pupup menu is scrolled with page body on modal dialog. > > > Key: IGNITE-8996 > URL: https://issues.apache.org/jira/browse/IGNITE-8996 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.6 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Open *Cluster* configuration of *Advanced* tab of *Configure* page. > # Open *Import from database* dialog > # On *Tables* step expand any dropdown > # Try to scroll mouse on area instead of import dialog. > On scroll the dropdown popup is scrolled together with background content. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-8996) Web console: Dropdown pupup menu is scrolled with page body on modal dialog.
[ https://issues.apache.org/jira/browse/IGNITE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-8996. -- Resolution: Won't Fix This is a minor feature that may be leaved as is. > Web console: Dropdown pupup menu is scrolled with page body on modal dialog. > > > Key: IGNITE-8996 > URL: https://issues.apache.org/jira/browse/IGNITE-8996 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.6 >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Open *Cluster* configuration of *Advanced* tab of *Configure* page. > # Open *Import from database* dialog > # On *Tables* step expand any dropdown > # Try to scroll mouse on area instead of import dialog. > On scroll the dropdown popup is scrolled together with background content. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-9372) Web console: Failed to execute query with limited page count
[ https://issues.apache.org/jira/browse/IGNITE-9372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-9372. > Web console: Failed to execute query with limited page count > > > Key: IGNITE-9372 > URL: https://issues.apache.org/jira/browse/IGNITE-9372 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Open Queries page an input some executable query. > # Change Max pages value from Unlimited. > # Try to execute query or explane query. > Query does not executed with syntax error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-9372) Web console: Failed to execute query with limited page count
[ https://issues.apache.org/jira/browse/IGNITE-9372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-9372. -- Resolution: Won't Fix This issue should be fixed on SQL engine level. > Web console: Failed to execute query with limited page count > > > Key: IGNITE-9372 > URL: https://issues.apache.org/jira/browse/IGNITE-9372 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Open Queries page an input some executable query. > # Change Max pages value from Unlimited. > # Try to execute query or explane query. > Query does not executed with syntax error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=16943654#comment-16943654
]
Igor Sapego commented on IGNITE-12032:
--
[~levagafonov] looks good. Merging to master.
> Server node prints exception when ODBC driver disconnects
> -
>
> Key: IGNITE-12032
> URL: https://issues.apache.org/jira/browse/IGNITE-12032
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.7.5
>Reporter: Evgenii Zhuravlev
>Assignee: Lev Agafonov
>Priority: Minor
> Labels: newbie, usability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-11230) Fix Javadoc for DataStorageConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-11230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov reassigned IGNITE-11230: -- Assignee: Ilya Shishkov > Fix Javadoc for DataStorageConfiguration > > > Key: IGNITE-11230 > URL: https://issues.apache.org/jira/browse/IGNITE-11230 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Stanislav Lukyanov >Assignee: Ilya Shishkov >Priority: Minor > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > Need to polish DataStorageConfiguration Javadoc: > - add links to set* methods from get* counterparts > - add links to the default values for all properties -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12189) Implement correct limit for TextQuery
[ https://issues.apache.org/jira/browse/IGNITE-12189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943640#comment-16943640 ] Andrey Mashenkov commented on IGNITE-12189: --- [~Yuriy_Shuliha], good try. I've left few comments to the PR. Change in PlatformCache can broke text queries in .NET. Let's make a stub and fix it later within a new ticket. Other my comments relates to code styles. > Implement correct limit for TextQuery > - > > Key: IGNITE-12189 > URL: https://issues.apache.org/jira/browse/IGNITE-12189 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Yuriy Shuliha >Assignee: Yuriy Shuliha >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > PROBLEM > For now each server-node returns all response records to the client-node and > it may contain ~thousands, ~hundred thousands records. > Event if we need only first 10-100. Again, all the results are added to > queue in _*GridCacheQueryFutureAdapter*_ in arbitrary order by pages. > There are no any means to deliver deterministic result. > SOLUTION > Implement _*limit*_ as parameter for _*TextQuery*_ and > _*GridCacheQueryRequest*_ > It should be passed as limit parameter in Lucene's > _*IndexSearcher.search()*_ in _*GridLuceneIndex*_. > For distributed queries _*limit*_ will also trim response queue when merging > results. > Type: long > Special value: : 0 -> No limit (Integer.MAX_VALUE); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12129) Upgrade spring dependencies to latest versions
[ https://issues.apache.org/jira/browse/IGNITE-12129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Surkov Aleksandr reassigned IGNITE-12129: - Assignee: Surkov Aleksandr > Upgrade spring dependencies to latest versions > -- > > Key: IGNITE-12129 > URL: https://issues.apache.org/jira/browse/IGNITE-12129 > Project: Ignite > Issue Type: Wish > Components: spring >Reporter: Pavel >Assignee: Surkov Aleksandr >Priority: Major > > The actual spring version is 5.1.9.RELEASE, spring boot version is > 2.1.7.RELEASE > In Ignite master branch spring versions are 5.0.8.RELEASE and 2.0.9.RELEASE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap
[ https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943621#comment-16943621 ] Alexei Scherbakov commented on IGNITE-7083: --- [~mmuzaf] Looks like the issue is no longer actual because we have cache groups for a long time now. CachePartitionFullCountersMap size expected to be reduced twice after IGNITE-11794. Closing the issue. > Reduce memory usage of CachePartitionFullCountersMap > > > Key: IGNITE-7083 > URL: https://issues.apache.org/jira/browse/IGNITE-7083 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.3 > Environment: Any >Reporter: Sunny Chan >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > > The Cache Partition Exchange Manager kept a copy of the already completed > exchange. However, we have found that it uses a significant amount of memory. > Upon further investigation using heap dump we have found that a large amount > of memory is used by the CachePartitionFullCountersMap. We have also observed > in most cases, these maps contains only 0s. > Therefore I propose an optimization for this: Initially the long arrays to > store initial update counter and update counter in the CPFCM will be null, > and when you get the value and see these tables are null then we will return > 0 for the counter. We only allocate the long arrays when there is any > non-zero updates to the the map. > In our tests, the amount of heap used by GridCachePartitionExchangeManager > was around 70MB (67 copies of these CPFCM), after we apply the optimization > it drops to around 9MB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap
[ https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov resolved IGNITE-7083. --- Resolution: Won't Fix > Reduce memory usage of CachePartitionFullCountersMap > > > Key: IGNITE-7083 > URL: https://issues.apache.org/jira/browse/IGNITE-7083 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.3 > Environment: Any >Reporter: Sunny Chan >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > > The Cache Partition Exchange Manager kept a copy of the already completed > exchange. However, we have found that it uses a significant amount of memory. > Upon further investigation using heap dump we have found that a large amount > of memory is used by the CachePartitionFullCountersMap. We have also observed > in most cases, these maps contains only 0s. > Therefore I propose an optimization for this: Initially the long arrays to > store initial update counter and update counter in the CPFCM will be null, > and when you get the value and see these tables are null then we will return > 0 for the counter. We only allocate the long arrays when there is any > non-zero updates to the the map. > In our tests, the amount of heap used by GridCachePartitionExchangeManager > was around 70MB (67 copies of these CPFCM), after we apply the optimization > it drops to around 9MB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12254) IO errors during write header of WAL files in FSYNC mode should be handled by failure handler
[
https://issues.apache.org/jira/browse/IGNITE-12254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-12254:
--
Assignee: Aleksey Plekhanov
> IO errors during write header of WAL files in FSYNC mode should be handled by
> failure handler
> -
>
> Key: IGNITE-12254
> URL: https://issues.apache.org/jira/browse/IGNITE-12254
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
>
> Currently, such errors can hang the cluster.
> Reproducer:
> {code:java}
> @Test
> public void testWalFsyncIOError() throws Exception {
> cleanPersistenceDir();
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setCacheConfiguration(new
> CacheConfiguration(DEFAULT_CACHE_NAME).setAtomicityMode(ATOMIC));
> cfg.setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setMaxSize(100L * 1024 * 1024)
> .setPersistenceEnabled(true))
> .setWalMode(WALMode.FSYNC)
> .setWalSegmentSize(512 * 1024)
> .setWalBufferSize(512 * 1024));
> IgniteEx ignite0 = startGrid(new
> IgniteConfiguration(cfg).setIgniteInstanceName("ignite0"));
> IgniteEx ignite1 = startGrid(new
> IgniteConfiguration(cfg).setIgniteInstanceName("ignite1"));
> ignite0.cluster().active(true);
> IgniteCache cache = ignite0.cache(DEFAULT_CACHE_NAME);
> for (int i = 0; i < 1_000; i++)
> cache.put(i, "Test value " + i);
>
> ((FileWriteAheadLogManager)ignite1.context().cache().context().wal()).setFileIOFactory(new
> FileIOFactory() {
> FileIOFactory delegateFactory = new RandomAccessFileIOFactory();
> @Override public FileIO create(File file, OpenOption... modes)
> throws IOException {
> final FileIO delegate = delegateFactory.create(file, modes);
> return new FileIODecorator(delegate) {
> @Override public int write(ByteBuffer srcBuf) throws
> IOException {
> throw new IOException("No space left on device");
> }
> };
> }
> });
> for (int i = 0; i < 2_000; i++)
> try {
> cache.put(i, "Test value " + i);
> }
> catch (Exception ignore) {
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6930) Optionally to do not write free list updates to WAL
[
https://issues.apache.org/jira/browse/IGNITE-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943607#comment-16943607
]
Aleksey Plekhanov commented on IGNITE-6930:
---
The patch is ready. To minimize WAL record I've used next approach:
There is a small on-heap pages list cache allocated for each bucket. There are
three types of operations with free-lists: put the page to the tail of the
bucket (after insert and remove row), take a page from the tail of the bucket
(before insert row), remove the page from the bucket (before remove row), each
of these operations first look into the pages cache, then work with page memory.
There is no WAL record needed if the page uses only buckets pages cache. So,
it's possible then the page was put into free-list, moved through the bucket,
leave the free list and hasn't produced any free-list WAL record at all.
On-heap pages cache is flushed to page memory before each checkpoint to ensure
the same recovery guarantees as now (physical WAL records are restored from WAL
only to the moment of the last unsuccessful checkpoint if it was started, so we
need only final buckets state at the moment of checkpoint).
[~ivan.glukos], could you please have a look?
> Optionally to do not write free list updates to WAL
> ---
>
> Key: IGNITE-6930
> URL: https://issues.apache.org/jira/browse/IGNITE-6930
> Project: Ignite
> Issue Type: Task
> Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: IEP-8, performance
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When cache entry is created, we need to write update the free list. When
> entry is updated, we need to update free list(s) several times. Currently
> free list is persistent structure, so every update to it must be logged to be
> able to recover after crash. This may incur significant overhead, especially
> for small entries.
> E.g. this is how WAL for a single update looks like. "D" - updates with real
> data, "F" - free-list management:
> {code}
> 1. [D] DataRecord [writeEntries=[UnwrapDataEntry[k = key, v = [ BinaryObject
> [idHash=2053299190, hash=1986931360, typeId=-1580729813]], super = [DataEntry
> [cacheId=94416770, op=UPDATE, writeVer=GridCacheVersion [topVer=122147562,
> order=1510667560607, nodeOrder=1], partId=0, partCnt=4, super=WALRecord
> [size=0, chainSize=0, pos=null, type=DATA_RECORD]]
> 2. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010006, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010006, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 3. [D] DataPageInsertRecord [super=PageDeltaRecord [grpId=94416770,
> pageId=00010005, super=WALRecord [size=129, chainSize=0, pos=null,
> type=DATA_PAGE_INSERT_RECORD]]]
> 4. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010008,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 5. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710664,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 6. [D] ReplaceRecord [io=DataLeafIO[ver=1], idx=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010004, super=WALRecord [size=47,
> chainSize=0, pos=null, type=BTREE_PAGE_REPLACE]]]
> 7. [F] DataPageRemoveRecord [itemId=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=30,
> chainSize=0, pos=null, type=DATA_PAGE_REMOVE_RECORD]]]
> 8. [F] PagesListRemovePageRecord [rmvdPageId=00010005,
> pageId=00010008, grpId=94416770, super=PageDeltaRecord
> [grpId=94416770, pageId=00010008, super=WALRecord [size=37,
> chainSize=0, pos=null, type=PAGES_LIST_REMOVE_PAGE]]]
> 9. [F] DataPageSetFreeListPageRecord [freeListPage=0, super=PageDeltaRecord
> [grpId=94416770, pageId=00010005, super=WALRecord [size=37,
> chainSize=0, pos=null, type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> 10. [F] PagesListAddPageRecord [dataPageId=00010005,
> super=PageDeltaRecord [grpId=94416770, pageId=00010006,
> super=WALRecord [size=37, chainSize=0, pos=null, type=PAGES_LIST_ADD_PAGE]]]
> 11. [F] DataPageSetFreeListPageRecord [freeListPage=281474976710662,
> super=PageDeltaRecord [grpId=94416770, pageId=00010005,
> super=WALRecord [size=37, chainSize=0, pos=null,
> type=DATA_PAGE_SET_FREE_LIST_PAGE]]]
> {code}
> If you sum all space required for operation (size in p.3 is shown incorrectly
> here), you will see that data update required ~300 bytes, so do free list
[jira] [Commented] (IGNITE-12181) Rebalance hangs on BLT change on cluster with in-memory regions
[ https://issues.apache.org/jira/browse/IGNITE-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943581#comment-16943581 ] Maxim Muzafarov commented on IGNITE-12181: -- [~xtern] Merged to the master branch. Thanks for your contribution! > Rebalance hangs on BLT change on cluster with in-memory regions > --- > > Key: IGNITE-12181 > URL: https://issues.apache.org/jira/browse/IGNITE-12181 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Pavel Pereslegin >Priority: Blocker > Fix For: 2.8 > > Attachments: RebalanceInMemoryWithPersistence.java > > Time Spent: 1h 20m > Remaining Estimate: 0h > > # Configured BLT on the _node-1_ (cluster activated) > # Configured in-memory region with a single cache on the _node-1_ > # A new _node-2_ join to the cluster > # Set new BLT based on two nodes > # Rebalance hangs > Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12213) Sql objects system views
[ https://issues.apache.org/jira/browse/IGNITE-12213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943576#comment-16943576 ] Aleksey Plekhanov commented on IGNITE-12213: [~nizhikov], I've looked at your patch, it looks good to me. > Sql objects system views > > > Key: IGNITE-12213 > URL: https://issues.apache.org/jira/browse/IGNITE-12213 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, await > Fix For: 2.8 > > Time Spent: 3.5h > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add SQL objects system views. > * Schemas > * Tables > * Indexes > * SQL queries -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12214) Continuous query system view
[ https://issues.apache.org/jira/browse/IGNITE-12214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943566#comment-16943566 ] Denis Garus commented on IGNITE-12214: -- LGFM > Continuous query system view > > > Key: IGNITE-12214 > URL: https://issues.apache.org/jira/browse/IGNITE-12214 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35, await > Fix For: 2.8 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > IGNITE-12145 finished > We should add continuous query system views. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-4210) CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose data.
[ https://issues.apache.org/jira/browse/IGNITE-4210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-4210: Fix Version/s: (was: 2.8) 2.9 > CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose > data. > > > Key: IGNITE-4210 > URL: https://issues.apache.org/jira/browse/IGNITE-4210 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Alexey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.9 > > > org.apache.ignite.internal.processors.cache.distributed.CacheLoadingConcurrentGridStartSelfTest#testLoadCacheFromStore > sometimes have failures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12250) Adds REST requests processing logging.
[
https://issues.apache.org/jira/browse/IGNITE-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943554#comment-16943554
]
Ignite TC Bot commented on IGNITE-12250:
{panel:title=Branch: [pull/6928/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=4656414buildTypeId=IgniteTests24Java8_RunAll]
> Adds REST requests processing logging.
> --
>
> Key: IGNITE-12250
> URL: https://issues.apache.org/jira/browse/IGNITE-12250
> Project: Ignite
> Issue Type: Improvement
>Reporter: PetrovMikhail
>Assignee: PetrovMikhail
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> It's needed to add logging of each REST request processing result including
> errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12256) Fix double invocation of javaMajorVersion in scripts
[
https://issues.apache.org/jira/browse/IGNITE-12256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943551#comment-16943551
]
Ilya Kasnacheev commented on IGNITE-12256:
--
[~vveider] please review proposed fix.
> Fix double invocation of javaMajorVersion in scripts
>
>
> Key: IGNITE-12256
> URL: https://issues.apache.org/jira/browse/IGNITE-12256
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7.6
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Most of our shell script look as folows:
> {code}
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Discover IGNITE_HOME environment variable.
> #
> setIgniteHome
> #
> # Final JVM_OPTS for Java 9+ compatibility
> #
> javaMajorVersion "${JAVA_HOME}/bin/java"
> {code}
> It makes no sense to me since we already call javaMajorVersion in checkJava.
> Let's try to get rid of it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12256) Fix double invocation of javaMajorVersion in scripts
[
https://issues.apache.org/jira/browse/IGNITE-12256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943549#comment-16943549
]
Ilya Kasnacheev commented on IGNITE-12256:
--
Also need to fix versions such as
{code}
openjdk version "9-Ubuntu"
OpenJDK Runtime Environment (build 9-Ubuntu+0-9b181-4)
OpenJDK 64-Bit Server VM (build 9-Ubuntu+0-9b181-4, mixed mode)
{code}
as in IGNITE-9836
> Fix double invocation of javaMajorVersion in scripts
>
>
> Key: IGNITE-12256
> URL: https://issues.apache.org/jira/browse/IGNITE-12256
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7.6
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Most of our shell script look as folows:
> {code}
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Discover IGNITE_HOME environment variable.
> #
> setIgniteHome
> #
> # Final JVM_OPTS for Java 9+ compatibility
> #
> javaMajorVersion "${JAVA_HOME}/bin/java"
> {code}
> It makes no sense to me since we already call javaMajorVersion in checkJava.
> Let's try to get rid of it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-9861) Authorization object names must always be non-null.
[ https://issues.apache.org/jira/browse/IGNITE-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-9861. - Fix Version/s: (was: 2.9) Resolution: Won't Fix > Authorization object names must always be non-null. > --- > > Key: IGNITE-9861 > URL: https://issues.apache.org/jira/browse/IGNITE-9861 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > > Currently, sometimes *null* name parameter passing to a method > *GridSecurityProcessor:authorize*. This leads to the fact that it is > impossible to determine the authorization object by authorization event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8377) Add cluster (de)activation LifecycleBean callbacks
[
https://issues.apache.org/jira/browse/IGNITE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943544#comment-16943544
]
Maxim Muzafarov commented on IGNITE-8377:
-
[~stalkxt]
Hello, any updates here? Will we include this issue to 2.8?
> Add cluster (de)activation LifecycleBean callbacks
> --
>
> Key: IGNITE-8377
> URL: https://issues.apache.org/jira/browse/IGNITE-8377
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Sergey Dorozhkin
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> I suggest to add new {{LifecycleEventType}}, {{BEFORE_CLUSTER_ACTIVATE}},
> {{AFTER_CLUSTER_ACTIVATE}}, {{BEFORE_CLUSTER_DEACTIVATE}},
> {{AFTER_CLUSTER_DEACTIVATE}} and fire corresponding lifecycle events along
> with regular events.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9861) Authorization object names must always be non-null.
[ https://issues.apache.org/jira/browse/IGNITE-9861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943543#comment-16943543 ] Denis Garus commented on IGNITE-9861: - [~mmuzaf], no > Authorization object names must always be non-null. > --- > > Key: IGNITE-9861 > URL: https://issues.apache.org/jira/browse/IGNITE-9861 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.6 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.9 > > > Currently, sometimes *null* name parameter passing to a method > *GridSecurityProcessor:authorize*. This leads to the fact that it is > impossible to determine the authorization object by authorization event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-9068:
Fix Version/s: (was: 2.8)
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Blocker
> Labels: test
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
> at
>
[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-9068:
Priority: Major (was: Blocker)
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: test
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
> at
>
[jira] [Commented] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()
[
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943541#comment-16943541
]
Ilya Kasnacheev commented on IGNITE-9068:
-
[~mmuzaf]I remember this issue was mostly fixed elsewhere and no longer
presents. Maybe we should close this ticket or at least deprioritize.
> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
> Issue Type: Bug
> Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Blocker
> Labels: test
> Fix For: 2.8
>
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0005cb7b0468> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
> at
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
> - locked <0x0005cb423f00> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
> at
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
> at
>
[jira] [Updated] (IGNITE-5797) Add latency tracing capability for cache operations
[ https://issues.apache.org/jira/browse/IGNITE-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-5797: Fix Version/s: (was: 2.8) > Add latency tracing capability for cache operations > --- > > Key: IGNITE-5797 > URL: https://issues.apache.org/jira/browse/IGNITE-5797 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: IEP-35 > > As a proof-of-concept, it would be great to add tracing capabilities for tx > commit phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10708) SQL implement system view for partition states
[ https://issues.apache.org/jira/browse/IGNITE-10708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10708: - Fix Version/s: (was: 2.8) 2.9 > SQL implement system view for partition states > -- > > Key: IGNITE-10708 > URL: https://issues.apache.org/jira/browse/IGNITE-10708 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-13 > Fix For: 2.9 > > > Implement SQL system view to partition states in the cluster for each cache > group and each node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap
[ https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7083: Fix Version/s: (was: 2.8) 2.9 > Reduce memory usage of CachePartitionFullCountersMap > > > Key: IGNITE-7083 > URL: https://issues.apache.org/jira/browse/IGNITE-7083 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.3 > Environment: Any >Reporter: Sunny Chan >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > > The Cache Partition Exchange Manager kept a copy of the already completed > exchange. However, we have found that it uses a significant amount of memory. > Upon further investigation using heap dump we have found that a large amount > of memory is used by the CachePartitionFullCountersMap. We have also observed > in most cases, these maps contains only 0s. > Therefore I propose an optimization for this: Initially the long arrays to > store initial update counter and update counter in the CPFCM will be null, > and when you get the value and see these tables are null then we will return > 0 for the counter. We only allocate the long arrays when there is any > non-zero updates to the the map. > In our tests, the amount of heap used by GridCachePartitionExchangeManager > was around 70MB (67 copies of these CPFCM), after we apply the optimization > it drops to around 9MB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9403) TDE - Phase-1. Thin clients
[
https://issues.apache.org/jira/browse/IGNITE-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9403:
Fix Version/s: 2.9
> TDE - Phase-1. Thin clients
> ---
>
> Key: IGNITE-9403
> URL: https://issues.apache.org/jira/browse/IGNITE-9403
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Nikolay Izhikov
>Priority: Blocker
> Fix For: 2.9
>
>
> We should provide support for a new {{encryptionEnabled}} flag in cache
> configuration for all thin clients:
> - .Net
> - Java
> - NodeJs
> - Python
> - PHP
> - C++(for now it doesn't have support of {{CacheConfiguration}})
> Backward compatibility should be preserved.
> A contributor can take
> [commit](https://github.com/apache/ignite/commit/baab0a6ddd3973fb8fca6ecb0a7d841d7d3a72be)
> as an example
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-6116) Easy way to enable metrics for default memory region
[
https://issues.apache.org/jira/browse/IGNITE-6116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov resolved IGNITE-6116.
-
Fix Version/s: (was: 2.8)
Resolution: Resolved
Will be fixed as a part of IEP-35 activities.
Consulted with Nikolay Izhikov privately.
> Easy way to enable metrics for default memory region
>
>
> Key: IGNITE-6116
> URL: https://issues.apache.org/jira/browse/IGNITE-6116
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Denis A. Magda
>Assignee: Aleksei Zaitsev
>Priority: Major
> Labels: usability
>
> Presently it's a bit challenging to enable memory metrics for the default
> memory region unless you define a new one. Add the following two methods to
> {{MemoryConfiguration}} to address the issue.
> {code}
> MemoryConfiguration.setDefaultMemoryPolicyMetricsEnabled(boolean)
> boolean MemoryConfiguration.isDefaultMemoryPolicyMetricsEnabled()
> {code}
> Discussion on @dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-memory-and-persistence-metrics-td19582.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-5797) Add latency tracing capability for cache operations
[ https://issues.apache.org/jira/browse/IGNITE-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-5797. - Resolution: Duplicate > Add latency tracing capability for cache operations > --- > > Key: IGNITE-5797 > URL: https://issues.apache.org/jira/browse/IGNITE-5797 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > As a proof-of-concept, it would be great to add tracing capabilities for tx > commit phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12219) Cache operations performance metrics
[ https://issues.apache.org/jira/browse/IGNITE-12219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12219: - Summary: Cache operations performance metrics (was: Cache operations histogram) > Cache operations performance metrics > > > Key: IGNITE-12219 > URL: https://issues.apache.org/jira/browse/IGNITE-12219 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35, await > Fix For: 2.8 > > > We need to provide cache operations histogram metrics > Next API and its variants should be covered: > * get > * getEntry > * getAll > * put > * remove > * replace > * lock > * invoke > * containsKey -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10121) Web console: Create documentation how to run Web agent as Docker image
[ https://issues.apache.org/jira/browse/IGNITE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10121. --- Resolution: Fixed > Web console: Create documentation how to run Web agent as Docker image > -- > > Key: IGNITE-10121 > URL: https://issues.apache.org/jira/browse/IGNITE-10121 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Especially specify ho configure path to external folder with jdbc driver. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-10121) Web console: Create documentation how to run Web agent as Docker image
[ https://issues.apache.org/jira/browse/IGNITE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-10121. - > Web console: Create documentation how to run Web agent as Docker image > -- > > Key: IGNITE-10121 > URL: https://issues.apache.org/jira/browse/IGNITE-10121 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > Especially specify ho configure path to external folder with jdbc driver. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-5797) Add latency tracing capability for cache operations
[ https://issues.apache.org/jira/browse/IGNITE-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943537#comment-16943537 ] Maxim Muzafarov commented on IGNITE-5797: - [~agoncharuk] [~NIzhikov] I think this issue will be completed as part of IEP-35, right? > Add latency tracing capability for cache operations > --- > > Key: IGNITE-5797 > URL: https://issues.apache.org/jira/browse/IGNITE-5797 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > As a proof-of-concept, it would be great to add tracing capabilities for tx > commit phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-5797) Add latency tracing capability for cache operations
[ https://issues.apache.org/jira/browse/IGNITE-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-5797: Labels: IEP-35 (was: ) > Add latency tracing capability for cache operations > --- > > Key: IGNITE-5797 > URL: https://issues.apache.org/jira/browse/IGNITE-5797 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: IEP-35 > Fix For: 2.8 > > > As a proof-of-concept, it would be great to add tracing capabilities for tx > commit phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6546) Update faveicon.ico in rest-htttp module
[ https://issues.apache.org/jira/browse/IGNITE-6546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6546: Fix Version/s: (was: 2.8) 2.9 > Update faveicon.ico in rest-htttp module > > > Key: IGNITE-6546 > URL: https://issues.apache.org/jira/browse/IGNITE-6546 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Alexey Kuznetsov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.9 > > > Correct icon: https://svn.apache.org/repos/asf/ignite/site/trunk/favicon.ico -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6793) NPE in InitNewCoordinatorFuture leading to Cache3 suite hang
[
https://issues.apache.org/jira/browse/IGNITE-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-6793:
Fix Version/s: (was: 2.8)
2.9
> NPE in InitNewCoordinatorFuture leading to Cache3 suite hang
>
>
> Key: IGNITE-6793
> URL: https://issues.apache.org/jira/browse/IGNITE-6793
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexey Goncharuk
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.9
>
>
> Got the following exception in the IgniteCacheGroupsTest run:
> {code}
> [17:59:25]W: [org.apache.ignite:ignite-core] [2017-10-30
> 14:59:25,159][ERROR][sys-#35070%cache.IgniteCacheGroupsTest2%][GridCacheIoManager]
> Failed processing message [senderId=9a523ce6-a252-457f-8175-7246b6c4,
> msg=GridDhtPartitionsSingleMessage [parts={3181548=GridDhtPartitionMap
> [moving=0, top=AffinityTopologyVersion [topVer=42, minorTopVer=2],
> updateSeq=1098, size=191], -2100569601=GridDhtPartitionMap [moving=0,
> top=AffinityTopologyVersion [topVer=42, minorTopVer=2], updateSeq=654,
> size=100]},
> partCntrs={3181548=o.a.i.i.processors.cache.distributed.dht.preloader.CachePartitionPartialCountersMap@78b1774,
>
> -2100569601=o.a.i.i.processors.cache.distributed.dht.preloader.CachePartitionPartialCountersMap@3cb0c48a},
> partHistCntrs=null, err=null, client=false, compress=false,
> finishMsg=GridDhtPartitionsFullMessage [parts=null, partCntrs=null,
> partCntrs2=null, partHistSuppliers=null, partsToReload=null,
> topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], errs=null,
> compress=false, resTopVer=null, partCnt=0,
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], discoEvt=null,
> nodeId=33c058c3, evt=DISCOVERY_CUSTOM_EVT], lastVer=GridCacheVersion
> [topVer=120855515, order=1509375572161, nodeOrder=32], super=GridCacheMessage
> [msgId=4153599, depInfo=null, err=null, skipPrepare=false]]],
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=42, minorTopVer=2], discoEvt=null,
> nodeId=33c058c3, evt=DISCOVERY_CUSTOM_EVT], lastVer=GridCacheVersion
> [topVer=120855515, order=1509375572153, nodeOrder=38], super=GridCacheMessage
> [msgId=4153605, depInfo=null, err=null, skipPrepare=false
> [17:59:25]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:238)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1749)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:307)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2627)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2606)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> [17:59:25]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
[jira] [Created] (IGNITE-12257) [ML] Add Feature Filter for ML Partitioned Dataset
Alexey Zinoviev created IGNITE-12257:
Summary: [ML] Add Feature Filter for ML Partitioned Dataset
Key: IGNITE-12257
URL: https://issues.apache.org/jira/browse/IGNITE-12257
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.9
Reporter: Alexey Zinoviev
Assignee: Alexey Zinoviev
Fix For: 2.9
The behavior of this method ignores possible feature choosing on the previous
levels and we have no ability to make feature engineering during the
preprocessing like simple sql: filter, exclude, produce new features and so on
public SimpleDatasetData build(
LearningEnvironment env,
Iterator> upstreamData, long upstreamDataSize, C ctx) {
// Prepares the matrix of features in flat column-major format.
int cols = -1;
double[] features = null;
int ptr = 0;
while (upstreamData.hasNext()) {
UpstreamEntry entry = upstreamData.next();
Vector row = preprocessor.apply(entry.getKey(), entry.getValue()).features();
if (cols < 0) {
cols = row.size();
features = new double[Math.toIntExact(upstreamDataSize * cols)];
}
else
assert row.size() == cols : "Feature extractor must return exactly " + cols +
" features";
for (int i = 0; i < cols; i++)
features[Math.toIntExact(i * upstreamDataSize + ptr)] = row.get(i);
ptr++;
}
return new SimpleDatasetData(features, Math.toIntExact(upstreamDataSize));
}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7083) Reduce memory usage of CachePartitionFullCountersMap
[ https://issues.apache.org/jira/browse/IGNITE-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943536#comment-16943536 ] Maxim Muzafarov commented on IGNITE-7083: - [~ascherbakov] Hello, are there any updates here? What the issues have been created? Can you link them here? > Reduce memory usage of CachePartitionFullCountersMap > > > Key: IGNITE-7083 > URL: https://issues.apache.org/jira/browse/IGNITE-7083 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.3 > Environment: Any >Reporter: Sunny Chan >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > > The Cache Partition Exchange Manager kept a copy of the already completed > exchange. However, we have found that it uses a significant amount of memory. > Upon further investigation using heap dump we have found that a large amount > of memory is used by the CachePartitionFullCountersMap. We have also observed > in most cases, these maps contains only 0s. > Therefore I propose an optimization for this: Initially the long arrays to > store initial update counter and update counter in the CPFCM will be null, > and when you get the value and see these tables are null then we will return > 0 for the counter. We only allocate the long arrays when there is any > non-zero updates to the the map. > In our tests, the amount of heap used by GridCachePartitionExchangeManager > was around 70MB (67 copies of these CPFCM), after we apply the optimization > it drops to around 9MB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8608) .NET: Sign release NuGet packages
[ https://issues.apache.org/jira/browse/IGNITE-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943533#comment-16943533 ] Pavel Tupitsyn commented on IGNITE-8608: [~mmuzaf] no chance; signing a package requires an (expensive) certificate. Need to investigate how we can get one on ASF behalf. Let's postpone. > .NET: Sign release NuGet packages > - > > Key: IGNITE-8608 > URL: https://issues.apache.org/jira/browse/IGNITE-8608 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.8 > > > NuGet signed package submissions has been introduced recently: > https://blog.nuget.org/20180522/Introducing-signed-package-submissions.html > Sign Ignite.NET packages when releasing them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10266) VisorCMD: Do not allow to execute collect and reset lost partitions for system cache.
[ https://issues.apache.org/jira/browse/IGNITE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-10266: -- Ignite Flags: (was: Docs Required) > VisorCMD: Do not allow to execute collect and reset lost partitions for > system cache. > - > > Key: IGNITE-10266 > URL: https://issues.apache.org/jira/browse/IGNITE-10266 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > VisorCMD should show valid error on try to show or reset lost partitions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8608) .NET: Sign release NuGet packages
[ https://issues.apache.org/jira/browse/IGNITE-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-8608: --- Fix Version/s: (was: 2.8) > .NET: Sign release NuGet packages > - > > Key: IGNITE-8608 > URL: https://issues.apache.org/jira/browse/IGNITE-8608 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > > NuGet signed package submissions has been introduced recently: > https://blog.nuget.org/20180522/Introducing-signed-package-submissions.html > Sign Ignite.NET packages when releasing them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12256) Fix double invocation of javaMajorVersion in scripts
[
https://issues.apache.org/jira/browse/IGNITE-12256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-12256:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix double invocation of javaMajorVersion in scripts
>
>
> Key: IGNITE-12256
> URL: https://issues.apache.org/jira/browse/IGNITE-12256
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.7.6
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> Most of our shell script look as folows:
> {code}
> #
> # Discover path to Java executable and check it's version.
> #
> checkJava
> #
> # Discover IGNITE_HOME environment variable.
> #
> setIgniteHome
> #
> # Final JVM_OPTS for Java 9+ compatibility
> #
> javaMajorVersion "${JAVA_HOME}/bin/java"
> {code}
> It makes no sense to me since we already call javaMajorVersion in checkJava.
> Let's try to get rid of it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-10266) VisorCMD: Do not allow to execute collect and reset lost partitions for system cache.
[ https://issues.apache.org/jira/browse/IGNITE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10266. --- Resolution: Won't Fix This should be fixed on core API level. > VisorCMD: Do not allow to execute collect and reset lost partitions for > system cache. > - > > Key: IGNITE-10266 > URL: https://issues.apache.org/jira/browse/IGNITE-10266 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > VisorCMD should show valid error on try to show or reset lost partitions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-10266) VisorCMD: Do not allow to execute collect and reset lost partitions for system cache.
[ https://issues.apache.org/jira/browse/IGNITE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-10266. - > VisorCMD: Do not allow to execute collect and reset lost partitions for > system cache. > - > > Key: IGNITE-10266 > URL: https://issues.apache.org/jira/browse/IGNITE-10266 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > VisorCMD should show valid error on try to show or reset lost partitions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-10632) Web console: Failed to show cache mode on query notebook page.
[ https://issues.apache.org/jira/browse/IGNITE-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-10632. - > Web console: Failed to show cache mode on query notebook page. > -- > > Key: IGNITE-10632 > URL: https://issues.apache.org/jira/browse/IGNITE-10632 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Download and run Web agent. > # open some query notebook page. > # Open metadata panel and expand metadata for any cache. > Cache mode in metadata always has *undefined* value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10632) Web console: Failed to show cache mode on query notebook page.
[ https://issues.apache.org/jira/browse/IGNITE-10632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10632. --- Resolution: Cannot Reproduce > Web console: Failed to show cache mode on query notebook page. > -- > > Key: IGNITE-10632 > URL: https://issues.apache.org/jira/browse/IGNITE-10632 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > > # Download and run Web agent. > # open some query notebook page. > # Open metadata panel and expand metadata for any cache. > Cache mode in metadata always has *undefined* value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12256) Fix double invocation of javaMajorVersion in scripts
Ilya Kasnacheev created IGNITE-12256:
Summary: Fix double invocation of javaMajorVersion in scripts
Key: IGNITE-12256
URL: https://issues.apache.org/jira/browse/IGNITE-12256
Project: Ignite
Issue Type: Improvement
Components: general
Affects Versions: 2.7.6
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
Most of our shell script look as folows:
{code}
#
# Discover path to Java executable and check it's version.
#
checkJava
#
# Discover IGNITE_HOME environment variable.
#
setIgniteHome
#
# Final JVM_OPTS for Java 9+ compatibility
#
javaMajorVersion "${JAVA_HOME}/bin/java"
{code}
It makes no sense to me since we already call javaMajorVersion in checkJava.
Let's try to get rid of it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7204) Unexpected behavior if passing null to binaryObject.field method
[
https://issues.apache.org/jira/browse/IGNITE-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7204:
Fix Version/s: (was: 2.8)
2.9
> Unexpected behavior if passing null to binaryObject.field method
>
>
> Key: IGNITE-7204
> URL: https://issues.apache.org/jira/browse/IGNITE-7204
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Dmitry Vinnik
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> If assertions are disabled, when first field value will be returned.
> If not, an AssertionError will be thrown.
> Reproducer:
> {noformat}
> public void testNullField() throws Exception {
> try {
> final IgniteEx ex = startGrid(0);
> final IgniteCache test =
> ex.cache("test").withKeepBinary();
> final BinaryObjectBuilder bldr = ex.binary().builder("obj");
> bldr.setField("x", 1);
> test.put(0, bldr.build());
> test.query(new ScanQuery<>(new IgniteBiPredicate BinaryObject>() {
> @Override public boolean apply(Integer o, BinaryObject o2) {
> final Object q = o2.field(null);
> return false;
> }
> })).getAll();
> }
> finally {
> stopAllGrids();
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7204) Unexpected behavior if passing null to binaryObject.field method
[
https://issues.apache.org/jira/browse/IGNITE-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7204:
Issue Type: Bug (was: Improvement)
> Unexpected behavior if passing null to binaryObject.field method
>
>
> Key: IGNITE-7204
> URL: https://issues.apache.org/jira/browse/IGNITE-7204
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Dmitry Vinnik
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
>
> If assertions are disabled, when first field value will be returned.
> If not, an AssertionError will be thrown.
> Reproducer:
> {noformat}
> public void testNullField() throws Exception {
> try {
> final IgniteEx ex = startGrid(0);
> final IgniteCache test =
> ex.cache("test").withKeepBinary();
> final BinaryObjectBuilder bldr = ex.binary().builder("obj");
> bldr.setField("x", 1);
> test.put(0, bldr.build());
> test.query(new ScanQuery<>(new IgniteBiPredicate BinaryObject>() {
> @Override public boolean apply(Integer o, BinaryObject o2) {
> final Object q = o2.field(null);
> return false;
> }
> })).getAll();
> }
> finally {
> stopAllGrids();
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-7671) Fix '.gitignore files are tracked' error
[
https://issues.apache.org/jira/browse/IGNITE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7671:
Fix Version/s: (was: 2.8)
2.9
> Fix '.gitignore files are tracked' error
>
>
> Key: IGNITE-7671
> URL: https://issues.apache.org/jira/browse/IGNITE-7671
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.9
>
>
> Current {{.gitignore}} has definitions of files to ignore, which are already
> under the version control system (some *.sh scripts for example). It needs to
> be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-10726) Web console: error in console after configuration import
[ https://issues.apache.org/jira/browse/IGNITE-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov closed IGNITE-10726. - > Web console: error in console after configuration import > > > Key: IGNITE-10726 > URL: https://issues.apache.org/jira/browse/IGNITE-10726 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: the error.png > > Original Estimate: 6h > Remaining Estimate: 6h > > *What happens:* > AngularJS error is thrown when switching between configuration domain models. > *How to reproduce:* > 1. Start demo mode, launch web agent. > 2. Go to configuration and perform DB import once. > 3. Open the result configuration domain models section. > 4. Import from in place DB, choose to overwrite domain models. > 5. Switch between several domain models. > The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7644) Add an utility to export all key-value data from a persisted partition
[ https://issues.apache.org/jira/browse/IGNITE-7644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-7644: Fix Version/s: (was: 2.8) 2.9 > Add an utility to export all key-value data from a persisted partition > -- > > Key: IGNITE-7644 > URL: https://issues.apache.org/jira/browse/IGNITE-7644 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.9 > > > We need an emergency utility analogous to pgdump which will be able to > full-scan all PDS partition pages and extract all survived data in some form > that later can be uploaded back to Ignite cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10726) Web console: error in console after configuration import
[ https://issues.apache.org/jira/browse/IGNITE-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-10726. --- Resolution: Cannot Reproduce > Web console: error in console after configuration import > > > Key: IGNITE-10726 > URL: https://issues.apache.org/jira/browse/IGNITE-10726 > Project: Ignite > Issue Type: Bug > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: the error.png > > Original Estimate: 6h > Remaining Estimate: 6h > > *What happens:* > AngularJS error is thrown when switching between configuration domain models. > *How to reproduce:* > 1. Start demo mode, launch web agent. > 2. Go to configuration and perform DB import once. > 3. Open the result configuration domain models section. > 4. Import from in place DB, choose to overwrite domain models. > 5. Switch between several domain models. > The issue does not persist after page reload, this looks like faulty caching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7820) Investigate and fix perfromance drop of WAL for FSYNC mode
[
https://issues.apache.org/jira/browse/IGNITE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-7820:
Priority: Critical (was: Major)
> Investigate and fix perfromance drop of WAL for FSYNC mode
> --
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Critical
> Fix For: 2.8
>
>
> WAL performance drop was introduced by
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide
> better performance for {{FSYNC}} WAL mode
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> *What we know about this performance drop:*
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some
> configuration we see performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> *What were tried during initial investigation:*
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect
> benchmarks.
> *What should we do:*
> Investigate the problem and provide fix or recommendation for system tuning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-7820) Investigate and fix perfromance drop of WAL for FSYNC mode
[
https://issues.apache.org/jira/browse/IGNITE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943531#comment-16943531
]
Maxim Muzafarov commented on IGNITE-7820:
-
[~agura]
Raised to `critical`.
Is this issue still actual?
> Investigate and fix perfromance drop of WAL for FSYNC mode
> --
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Critical
> Fix For: 2.8
>
>
> WAL performance drop was introduced by
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide
> better performance for {{FSYNC}} WAL mode
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> *What we know about this performance drop:*
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some
> configuration we see performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> *What were tried during initial investigation:*
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect
> benchmarks.
> *What should we do:*
> Investigate the problem and provide fix or recommendation for system tuning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-11157) Web Console Cluster Configuration Incomplete
[ https://issues.apache.org/jira/browse/IGNITE-11157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-11157: - Assignee: (was: Vasiliy Sisko) > Web Console Cluster Configuration Incomplete > > > Key: IGNITE-11157 > URL: https://issues.apache.org/jira/browse/IGNITE-11157 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 2.7 >Reporter: Glenn Wiebe >Priority: Minor > > This may be an artifact of configuring in both Basic and Advanced settings, > but... > Alteration of a cache's config settings from the Basic tab destroys the > configuration settings about the particular cache (all fields, queries, > indexes, etc. are now gone for the altered cache). > Replicate Error: > 1. Create a new config by Importing from database (e.g. pick two or more > tables); > 2. Open Config (note the advanced settings for one of the tables) > 3. Go back to Basic settings and change one of the caches from PARTITIONED to > REPLICATED. > 4. Save & Download the configuration > <=== Note, one may have trouble with downloading as an error may be flashed > on screen. > 4. (alternate) go to list of configurations, select it and under action, > choose Download. > Note the particular cache that was changed now has lost virtually all of its > definition. > Regards, > Glenn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-11713) Web console: cluster configuration events content fit issue
[ https://issues.apache.org/jira/browse/IGNITE-11713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-11713: - Assignee: (was: Vasiliy Sisko) > Web console: cluster configuration events content fit issue > --- > > Key: IGNITE-11713 > URL: https://issues.apache.org/jira/browse/IGNITE-11713 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Priority: Minor > Attachments: image-2019-04-10-15-46-39-859.png, screenshot-1.png > > > *What happens:* > In master, cluster configuration (2.8) / events / local events listeners > individual event listnered item sub form controls don't fit well when > viewport width is under 1420px: > !image-2019-04-10-15-46-39-859.png! > !screenshot-1.png! > *Expected behavior:* > Form controls should be laid out such they look don't overflow/wrap. > As a solution, I propose to put each control into separate row. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8290) Activation message handling fails with AssertionError sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-8290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943530#comment-16943530 ] Maxim Muzafarov commented on IGNITE-8290: - [~amashenkov] Hello, it seems that we can close this issue as not reproducible, right? > Activation message handling fails with AssertionError sporadically. > --- > > Key: IGNITE-8290 > URL: https://issues.apache.org/jira/browse/IGNITE-8290 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Andrey Mashenkov >Assignee: Andrey Kuznetsov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Attachments: disco-msg-fails-2.stack, disco-msg-fails.stack > > > Some test fails sporadically due to AssertionError while processing custom > discovery message which can leads to grid and tests handing. > PFA stacktraces. > org.apache.ignite.internal.processors.cache.persistence.db.IgnitePdsWholeClusterRestartTest > is a good startpoint. > However, the test passes at master, it's every run logs lot of > AssertionErrors . -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9204:
Ignite Flags: (was: Docs Required)
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.9
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-8608) .NET: Sign release NuGet packages
[ https://issues.apache.org/jira/browse/IGNITE-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943529#comment-16943529 ] Maxim Muzafarov commented on IGNITE-8608: - [~ptupitsyn] Is there any chance for this issue to be included in 2.8? Can we move it to the next release? > .NET: Sign release NuGet packages > - > > Key: IGNITE-8608 > URL: https://issues.apache.org/jira/browse/IGNITE-8608 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.8 > > > NuGet signed package submissions has been introduced recently: > https://blog.nuget.org/20180522/Introducing-signed-package-submissions.html > Sign Ignite.NET packages when releasing them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9317) Table Names With Special Characters Don't Work in Spark SQL Optimisations
[ https://issues.apache.org/jira/browse/IGNITE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9317: Fix Version/s: (was: 2.8) 2.9 > Table Names With Special Characters Don't Work in Spark SQL Optimisations > - > > Key: IGNITE-9317 > URL: https://issues.apache.org/jira/browse/IGNITE-9317 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.6 >Reporter: Stuart Macdonald >Assignee: Stuart Macdonald >Priority: Major > Fix For: 2.9 > > > Table names aren't escaped in execution of Ignite SQL through the spark SQL > interface, meaning table names with special characters (such as . or -) cause > SQL grammar exceptions upon execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9319) CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover is flaky in master.
[ https://issues.apache.org/jira/browse/IGNITE-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9319: Fix Version/s: (was: 2.8) 2.9 > CacheAsyncOperationsFailoverTxTest.testPutAllAsyncFailover is flaky in master. > -- > > Key: IGNITE-9319 > URL: https://issues.apache.org/jira/browse/IGNITE-9319 > Project: Ignite > Issue Type: Bug >Reporter: Alexei Scherbakov >Assignee: Anton Kalashnikov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.9 > > > https://ci.ignite.apache.org/viewLog.html?buildId=1688647=queuedBuildOverviewTab > https://ci.ignite.apache.org/viewLog.html?buildId=1688542=queuedBuildOverviewTab -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9204) Test org.apache.ignite.client.ReliabilityTest@testFailover fails intermittently
[
https://issues.apache.org/jira/browse/IGNITE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-9204:
Fix Version/s: (was: 2.8)
2.9
> Test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently
> ---
>
> Key: IGNITE-9204
> URL: https://issues.apache.org/jira/browse/IGNITE-9204
> Project: Ignite
> Issue Type: Test
> Components: thin client
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
> Fix For: 2.9
>
>
> According to [Apache Ignite Team
> City|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1817609924700192054=testDetails],
> test org.apache.ignite.client.ReliabilityTest@testFailover fails
> intermittently with this message:
>
> {noformat}
> java.lang.AssertionError: Ignite cluster is unavailable expected null, but
> was: unavailable> at
> org.apache.ignite.client.ReliabilityTest.assertOnUnstableCluster(ReliabilityTest.java:184)
> at
> org.apache.ignite.client.ReliabilityTest.testFailover(ReliabilityTest.java:88)
> * Text was not loaded fully because its' size exceeds 2 MB, see full log
> for the whole text *
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10593) Proper NoOpHandler injection
[ https://issues.apache.org/jira/browse/IGNITE-10593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10593: - Fix Version/s: (was: 2.8) 2.9 > Proper NoOpHandler injection > > > Key: IGNITE-10593 > URL: https://issues.apache.org/jira/browse/IGNITE-10593 > Project: Ignite > Issue Type: Task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Major > Fix For: 2.9 > > > Improve no-op failure handler usage by replacing copy-pasted code by > extending from class with changed default handler as recommended in > [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Default-failure-handler-was-changed-for-tests-tp38900p39010.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9317) Table Names With Special Characters Don't Work in Spark SQL Optimisations
[ https://issues.apache.org/jira/browse/IGNITE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-9317: Ignite Flags: (was: Docs Required) > Table Names With Special Characters Don't Work in Spark SQL Optimisations > - > > Key: IGNITE-9317 > URL: https://issues.apache.org/jira/browse/IGNITE-9317 > Project: Ignite > Issue Type: Bug > Components: spark >Affects Versions: 2.6 >Reporter: Stuart Macdonald >Assignee: Stuart Macdonald >Priority: Major > Fix For: 2.8 > > > Table names aren't escaped in execution of Ignite SQL through the spark SQL > interface, meaning table names with special characters (such as . or -) cause > SQL grammar exceptions upon execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10708) SQL implement system view for partition states
[ https://issues.apache.org/jira/browse/IGNITE-10708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-10708: - Labels: IEP-35 iep-13 (was: iep-13) > SQL implement system view for partition states > -- > > Key: IGNITE-10708 > URL: https://issues.apache.org/jira/browse/IGNITE-10708 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-13 > Fix For: 2.8 > > > Implement SQL system view to partition states in the cluster for each cache > group and each node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with some timeouts that haven't caused by deadlocks.
[ https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6527: Fix Version/s: (was: 2.8) 2.9 > Deadlock detection works incorrectly with some timeouts that haven't caused > by deadlocks. > - > > Key: IGNITE-6527 > URL: https://issues.apache.org/jira/browse/IGNITE-6527 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Vitaliy Biryukov >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.9 > > Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java > > > Deadlock detection works incorrectly with timeouts that haven't caused by > deadlocks. In case of a deadlock in future. Or can detect another deadlock > which was not the cause of timeout. > *requested keys:* keys primary for the same node and blocking in sequential > order during the timeout (or all keys that haven't locked by an optimistic > transaction in case of near cache). > *candidates:* keys candidates to be locked on a primary node (entries > contains in GridDhtTxLocal). > In the process of updating the Wait-For-Graph requested keys used as > candidates. But "TxDeadlock.toString" method use candidates which were > received from messages. > 1) It causes an incorrect error message. > Example: > K1: TX1 holds lock, TX2 waits lock. > K2: TX3 holds lock, TX1 waits lock. > Transactions: > TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455] > TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456] > TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, > nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457] > Keys: > K1 [key=6, cache=cache] > K2 [key=1, cache=cache] > 2) DD can detect another deadlock which was not the cause of timeout but it > would be the cause if the current deadlock did not happen. > These are very rare situations, but they can happen. > I see several solutions: > * Just make a correct message. > * log warn and continue detecting. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks
[ https://issues.apache.org/jira/browse/IGNITE-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6445: Priority: Critical (was: Major) > IgniteTxManager.txLocksInfo method misses locks > --- > > Key: IGNITE-6445 > URL: https://issues.apache.org/jira/browse/IGNITE-6445 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Critical > Fix For: 2.8 > > > In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) > misses locks. > For example: > # In case of a configuration with near cache, entries are created for the > near cache and for the ordinal cache. For each entry, their own MVCC > candidates are created. > # For non-custom objects of type (Integer, etc.), the entry stored in > "GridNearTxLocal" is not associated with MVCC candidates with which the same > entity is associated in another format stored in "GridDhtTxLocal" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks
[ https://issues.apache.org/jira/browse/IGNITE-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6445: Fix Version/s: (was: 2.9) 2.8 > IgniteTxManager.txLocksInfo method misses locks > --- > > Key: IGNITE-6445 > URL: https://issues.apache.org/jira/browse/IGNITE-6445 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.8 > > > In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) > misses locks. > For example: > # In case of a configuration with near cache, entries are created for the > near cache and for the ordinal cache. For each entry, their own MVCC > candidates are created. > # For non-custom objects of type (Integer, etc.), the entry stored in > "GridNearTxLocal" is not associated with MVCC candidates with which the same > entity is associated in another format stored in "GridDhtTxLocal" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-8771) OutOfMemory in Cache2 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov resolved IGNITE-8771. - Resolution: Cannot Reproduce OutOfMemory isn't reproducible anymore, seems it was fixed in some other ticket. > OutOfMemory in Cache2 suite in master branch on TC > -- > > Key: IGNITE-8771 > URL: https://issues.apache.org/jira/browse/IGNITE-8771 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory error happened in Cache2 suite for the first time in a while: > [https://ci.ignite.apache.org/viewLog.html?buildId=1372380=buildResultsDiv=IgniteTests24Java8_Cache2] > Recent history doesn't contain any OOMs or execution timeouts for this suite: > [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8771) OutOfMemory in Cache2 suite in master branch on TC
[ https://issues.apache.org/jira/browse/IGNITE-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943521#comment-16943521 ] Sergey Chugunov commented on IGNITE-8771: - [~mmuzaf], As it isn't reproducible anymore, I'll close the ticket. Thank you for your attention! > OutOfMemory in Cache2 suite in master branch on TC > -- > > Key: IGNITE-8771 > URL: https://issues.apache.org/jira/browse/IGNITE-8771 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Priority: Blocker > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > OutOfMemory error happened in Cache2 suite for the first time in a while: > [https://ci.ignite.apache.org/viewLog.html?buildId=1372380=buildResultsDiv=IgniteTests24Java8_Cache2] > Recent history doesn't contain any OOMs or execution timeouts for this suite: > [TC > link|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache2_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6444) Validate that copyOnRead flag is configured with on-heap cache enabled
[ https://issues.apache.org/jira/browse/IGNITE-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943522#comment-16943522 ] Maxim Muzafarov commented on IGNITE-6444: - [~shroman] Do we have a chance to include this issue to 2.8 release or it can be moved to the next one? > Validate that copyOnRead flag is configured with on-heap cache enabled > -- > > Key: IGNITE-6444 > URL: https://issues.apache.org/jira/browse/IGNITE-6444 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Assignee: Roman Shtykh >Priority: Major > Labels: usability > Fix For: 2.8 > > > Link to the user-list discussion: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-CopyOnRead-Problem-td17009.html > It makes sense to validate the flag and print out a warning if on-heap cache > is disabled. I do not think that we should prevent node from startup because > this may break existing deployments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6445) IgniteTxManager.txLocksInfo method misses locks
[ https://issues.apache.org/jira/browse/IGNITE-6445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6445: Fix Version/s: (was: 2.8) 2.9 > IgniteTxManager.txLocksInfo method misses locks > --- > > Key: IGNITE-6445 > URL: https://issues.apache.org/jira/browse/IGNITE-6445 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Vitaliy Biryukov >Assignee: Vitaliy Biryukov >Priority: Major > Fix For: 2.9 > > > In some cases "IgniteTxManager.txLocksInfo" method (searches for locks) > misses locks. > For example: > # In case of a configuration with near cache, entries are created for the > near cache and for the ordinal cache. For each entry, their own MVCC > candidates are created. > # For non-custom objects of type (Integer, etc.), the entry stored in > "GridNearTxLocal" is not associated with MVCC candidates with which the same > entity is associated in another format stored in "GridDhtTxLocal" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-1678:
Fix Version/s: (was: 2.8)
2.9
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis A. Magda
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.9
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10443) Fix flaky GridCommandHandlerTest.testKillHangingLocalTransactions
[ https://issues.apache.org/jira/browse/IGNITE-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-10443: - Fix Version/s: (was: 2.8) 2.9 > Fix flaky GridCommandHandlerTest.testKillHangingLocalTransactions > - > > Key: IGNITE-10443 > URL: https://issues.apache.org/jira/browse/IGNITE-10443 > Project: Ignite > Issue Type: Test >Reporter: Alexei Scherbakov >Assignee: Alexei Scherbakov >Priority: Major > Fix For: 2.9 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
