[jira] [Commented] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745860#comment-16745860 ] Sergi Vladykin commented on IGNITE-10798: - [~gvvinblade], Thanks! Just added manual sorting to the test and it passes. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745837#comment-16745837
]
Ignite TC Bot commented on IGNITE-10754:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2824480buildTypeId=IgniteTests24Java8_RunAll]
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8283) CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
[
https://issues.apache.org/jira/browse/IGNITE-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
chaos reassigned IGNITE-8283:
-
Assignee: chaos
> CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
> ---
>
> Key: IGNITE-8283
> URL: https://issues.apache.org/jira/browse/IGNITE-8283
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Daradur
>Assignee: chaos
>Priority: Major
> Fix For: 2.8
>
>
> Need to finish the solution that has been prepared into IGNITE-5153 to be
> configurable via {{BinaryConfiguration}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-2771) Document machine safety
[ https://issues.apache.org/jira/browse/IGNITE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745656#comment-16745656 ] Prachi Garg commented on IGNITE-2771: - [~vkulichenko], Can you please review - https://apacheignite.readme.io/v2.7/docs/performance-tips-2#section-tune-partitions-on-multiple-racks > Document machine safety > --- > > Key: IGNITE-2771 > URL: https://issues.apache.org/jira/browse/IGNITE-2771 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745541#comment-16745541
]
Ignite TC Bot commented on IGNITE-10752:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2823909buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Tests invariants are violated sometimes
> -
>
> Key: IGNITE-10752
> URL: https://issues.apache.org/jira/browse/IGNITE-10752
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes tests are failed by violated invariants errors. For example, when
> total sum on accounts is not as expected.
> Muted tests:
> * {{CacheMvccPartitionedCoordinatorFailoverTest}}
> **
> {{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> **
> {{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
> ** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
> ** {{testGetReadInProgressCoordinatorFails}}
> ** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
> * {{CacheMvccReplicatedCoordinatorFailoverTest}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> * {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
> * {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
> * {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> * {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
> ** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
> ** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
> ** {{testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> **
> {{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> **
> {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> ** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
> ** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
> ** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
> {noformat}
> junit.framework.AssertionFailedError: Unexpected error:
> junit.framework.AssertionFailedError: expected:<0> but was:<4>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6450) Kotlin: Inherited platform declarations clash
[ https://issues.apache.org/jira/browse/IGNITE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745534#comment-16745534 ] Derick SeongJun Lee commented on IGNITE-6450: - Any progress? I met the same. > Kotlin: Inherited platform declarations clash > - > > Key: IGNITE-6450 > URL: https://issues.apache.org/jira/browse/IGNITE-6450 > Project: Ignite > Issue Type: Bug > Components: cache, spring >Affects Versions: 2.1, 2.2 > Environment: OS: macOS 10.12 > Java: 1.8.0_112-b16 > Kotlin: 1.1.4-3 > org.apache.ignite:ignite-spring-data:2.2.0 > org.springframework.data:spring-data-commons:1.13.1.RELEASE -> 2.0.0.RC3 >Reporter: redtank >Priority: Major > > I am trying Spring Data and Ignite. My repository interface is below > ``` > @RepositoryConfig(cacheName = "QuoteRequest") > interface QuoteRequestRepository : IgniteRepository > ``` > The code works for spring-data-commons:1.13.1.RELEASE. But it doesn't work > for 2.0.0.RC3. The error message is below > > ``` > Error:(9, 11) Kotlin: Inherited platform declarations clash: The following > declarations have the same JVM signature (deleteAll(Ljava/lang/Iterable;)V): > fun deleteAll(p0: (Mutable)Iterable!): Unit defined in > repository.QuoteRequestRepository > fun deleteAll(p0: (Mutable)Iterable!): Unit defined in > repository.QuoteRequestRepository > ``` -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10508) Need to support the new checkpoint feature, checkpint should not wait for the previous operation to complete
[ https://issues.apache.org/jira/browse/IGNITE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10508: Summary: Need to support the new checkpoint feature, checkpint should not wait for the previous operation to complete (was: Need to support the new checkpoint feature not wait for the previous operation to complete) > Need to support the new checkpoint feature, checkpint should not wait for the > previous operation to complete > > > Key: IGNITE-10508 > URL: https://issues.apache.org/jira/browse/IGNITE-10508 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > There are cases we should trigger the checkpoint, some operations will be > sure that all operation finished before the checkpoint. It is necessary to > support the possibility of run checkpoint without waiting for the completion > of the previous checkpoint. > Solution: > Merge checkpoint pages and append write new dirty pages to a current > checkpoint. > Restrictions: > Trigger new checkpoint should not wait for the previous checkpoint operation > completed. > - It should not break crash recovery mechanisms > - Only one merged is allow in the first implementation (potentially OOM, if > we will try to merge many checkpoint operations) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8407) Wrong memory size printing in IgniteCacheDatabaseSnaredManager
[
https://issues.apache.org/jira/browse/IGNITE-8407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745416#comment-16745416
]
Andrey Kalinin commented on IGNITE-8407:
This ticket looks like a duplicate of IGNITE-5755. [~sbberkov] I propose to
close this ticket. What do you think?
> Wrong memory size printing in IgniteCacheDatabaseSnaredManager
> --
>
> Key: IGNITE-8407
> URL: https://issues.apache.org/jira/browse/IGNITE-8407
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Priority: Trivial
>
> In checkDataRegionSize regCfg printing in "si" format (based on 1000, not
> 1024). Need to fix it and any other usages of getInitialSize()/getMaxSize())
> with U.readableSize(*, true)
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), true) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), true) + "]"
> {noformat}
> should be replaced with
> {noformat}
> throw new IgniteCheckedException("DataRegion must have size more than 10MB
> (use " +
> "DataRegionConfiguration.initialSize and .maxSize properties
> to set correct size in bytes) " +
> "[name=" + regCfg.getName() + ", initialSize=" +
> U.readableSize(regCfg.getInitialSize(), false) +
> ", maxSize=" + U.readableSize(regCfg.getMaxSize(), false) +
> "]"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10508) Need to support the new checkpoint feature not wait for the previous operation to complete
[ https://issues.apache.org/jira/browse/IGNITE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10508: Priority: Critical (was: Major) > Need to support the new checkpoint feature not wait for the previous > operation to complete > -- > > Key: IGNITE-10508 > URL: https://issues.apache.org/jira/browse/IGNITE-10508 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > There are cases we should trigger the checkpoint, some operations will be > sure that all operation finished before the checkpoint. It is necessary to > support the possibility of run checkpoint without waiting for the completion > of the previous checkpoint. > Solution: > Merge checkpoint pages and append write new dirty pages to a current > checkpoint. > Restrictions: > Trigger new checkpoint should not wait for the previous checkpoint operation > completed. > - It should not break crash recovery mechanisms > - Only one merged is allow in the first implementation (potentially OOM, if > we will try to merge many checkpoint operations) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10508) Need to support the new checkpoint feature not wait for the previous operation to complete
[ https://issues.apache.org/jira/browse/IGNITE-10508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-10508: Issue Type: New Feature (was: Improvement) > Need to support the new checkpoint feature not wait for the previous > operation to complete > -- > > Key: IGNITE-10508 > URL: https://issues.apache.org/jira/browse/IGNITE-10508 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > There are cases we should trigger the checkpoint, some operations will be > sure that all operation finished before the checkpoint. It is necessary to > support the possibility of run checkpoint without waiting for the completion > of the previous checkpoint. > Solution: > Merge checkpoint pages and append write new dirty pages to a current > checkpoint. > Restrictions: > Trigger new checkpoint should not wait for the previous checkpoint operation > completed. > - It should not break crash recovery mechanisms > - Only one merged is allow in the first implementation (potentially OOM, if > we will try to merge many checkpoint operations) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10942) [TC Bot] Optimize background JIRA tickets sync
[ https://issues.apache.org/jira/browse/IGNITE-10942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-10942: Summary: [TC Bot] Optimize background JIRA tickets sync (was: [TC Bot] Optimize backround JIRA tickets sync) > [TC Bot] Optimize background JIRA tickets sync > -- > > Key: IGNITE-10942 > URL: https://issues.apache.org/jira/browse/IGNITE-10942 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > JIRA sync is now performed in not an efficient manner. > All project data is reloaded every 15 minutes, and this may create additional > pressure for 3rd party services. > Introduce incremental updates (update is running only until the first > non-modified element found) and full updates. > Check ticket data modification before saving into Ignite DB (will safe WAL & > page store pressure). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745358#comment-16745358 ] Sergey Antonov commented on IGNITE-10507: - [~ivan.glukos] i applied your comments. Could you review changes again? > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10933) Node may hang on join to topology and not move forward
[
https://issues.apache.org/jira/browse/IGNITE-10933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov reassigned IGNITE-10933:
--
Assignee: Alexei Scherbakov (was: Vladislav Pyatkov)
> Node may hang on join to topology and not move forward
> --
>
> Key: IGNITE-10933
> URL: https://issues.apache.org/jira/browse/IGNITE-10933
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Alexei Scherbakov
>Priority: Major
>
> Several nodes join to topology simultaneously and hang on a long time.
> That can be on first start all cluster nodes or join nodes to completed
> topology.
> In the logs of problem nodes can see messages:
> {noformat}
> 2019-01-11 18:37:39.296 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi]
> Node has not been connected to topology and will repeat join process. Check
> remote nodes logs for possible error messages. Note that large topology may
> require sig
> nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout'
> configuration property if getting this message on the starting nodes
> [networkTimeout=5000]
> 2019-01-11 18:43:09.374 [WARN ][Thread-56][o.a.i.s.d.tcp.TcpDiscoverySpi]
> Node has not been connected to topology and will repeat join process. Check
> remote nodes logs for possible error messages. Note that large topology may
> require sig
> nificant time to start. Increase 'TcpDiscoverySpi.networkTimeout'
> configuration property if getting this message on the starting nodes
> [networkTimeout=5000]
> ...
> {noformat}
> and so for a long time without others.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9907) Wrong index field name makes the whole cluster to fail
[ https://issues.apache.org/jira/browse/IGNITE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745303#comment-16745303 ] Vyacheslav Koptilin commented on IGNITE-9907: - Looks like the issue is already resolved by IGNITE-8640 and IGNITE-10228 > Wrong index field name makes the whole cluster to fail > -- > > Key: IGNITE-9907 > URL: https://issues.apache.org/jira/browse/IGNITE-9907 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Priority: Critical > Attachments: WrongFields.java > > > Wrong index field name makes the whole cluster to fail and there's now > reliable way to restore from this state, exchange fails with the exception: > > 2018-10-16 > 14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager] > Failed to wait for completion of partition map exchange (preloading will not > start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent > [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], crd=TcpDiscoveryNode > [id=0d8b289d-32aa-402e-8e71-137977559979, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:47500, > /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], discPort=47500, order=1, > intOrder=1, lastExchangeTime=1539726176493, loc=true, > ver=2.4.3#19691231-sha1:, isClient=false], > exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, > affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], nodeId=6859ef9c, > evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=false, hash=1240595188], init=false, > lastVer=null, partReleaseFut=PartitionReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion > [topVer=2, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], > DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, > initTs=1539726176695, centralizedAff=false, forceAffReassignment=false, > changeGlobalStateE=null, done=true, state=CRD, evtLatch=0, remaining=[], > super=GridFutureAdapter [ignoreInterrupts=false, state=DONE, > res=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, hash=1559339235]] > class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0 > at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.rangeCheck(ArrayList.java:657) > at java.util.ArrayList.get(ArrayList.java:433) > at > org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816) >
[jira] [Commented] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745297#comment-16745297
]
Ignite TC Bot commented on IGNITE-10784:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2825226buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9907) Wrong index field name makes the whole cluster to fail
[ https://issues.apache.org/jira/browse/IGNITE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-9907. - Resolution: Duplicate Fix Version/s: 2.8 > Wrong index field name makes the whole cluster to fail > -- > > Key: IGNITE-9907 > URL: https://issues.apache.org/jira/browse/IGNITE-9907 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Priority: Critical > Fix For: 2.8 > > Attachments: WrongFields.java > > > Wrong index field name makes the whole cluster to fail and there's now > reliable way to restore from this state, exchange fails with the exception: > > 2018-10-16 > 14:42:56,842][ERROR][exchange-worker-#42%server_0%][GridCachePartitionExchangeManager] > Failed to wait for completion of partition map exchange (preloading will not > start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent > [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], crd=TcpDiscoveryNode > [id=0d8b289d-32aa-402e-8e71-137977559979, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:47500, > /0:0:0:0:0:0:0:1%lo0:47500, /127.0.0.1:47500], discPort=47500, order=1, > intOrder=1, lastExchangeTime=1539726176493, loc=true, > ver=2.4.3#19691231-sha1:, isClient=false], > exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], discoEvt=DiscoveryCustomEvent [customMsg=null, > affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > super=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=6859ef9c-cceb-4d8a-8d5b-c1cd2cd192b7, addrs=[0:0:0:0:0:0:0:1%lo0, > 127.0.0.1, 192.168.75.84], sockAddrs=[/192.168.75.84:0, > /0:0:0:0:0:0:0:1%lo0:0, /127.0.0.1:0], discPort=0, order=2, intOrder=2, > lastExchangeTime=1539726176458, loc=false, ver=2.4.3#19691231-sha1:, > isClient=true], topVer=2, nodeId8=0d8b289d, msg=null, > type=DISCOVERY_CUSTOM_EVT, tstamp=1539726176684]], nodeId=6859ef9c, > evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter > [ignoreInterrupts=false, state=DONE, res=false, hash=1240595188], init=false, > lastVer=null, partReleaseFut=PartitionReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], > futures=[ExplicitLockReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[]], TxReleaseFuture [topVer=AffinityTopologyVersion > [topVer=2, minorTopVer=1], futures=[]], AtomicUpdateReleaseFuture > [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], futures=[]], > DataStreamerReleaseFuture [topVer=AffinityTopologyVersion [topVer=2, > minorTopVer=1], futures=[, exchActions=null, affChangeMsg=null, > initTs=1539726176695, centralizedAff=false, forceAffReassignment=false, > changeGlobalStateE=null, done=true, state=CRD, evtLatch=0, remaining=[], > super=GridFutureAdapter [ignoreInterrupts=false, state=DONE, > res=java.lang.IndexOutOfBoundsException: Index: 0, Size: 0, hash=1559339235]] > class org.apache.ignite.IgniteCheckedException: Index: 0, Size: 0 > at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7332) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:207) > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159) > at > org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2374) > at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.rangeCheck(ArrayList.java:657) > at java.util.ArrayList.get(ArrayList.java:433) > at > org.apache.ignite.internal.processors.cache.CacheGroupContext.singleCacheContext(CacheGroupContext.java:374) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:194) > at > org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.getOrCreatePartition(GridDhtPartitionTopologyImpl.java:816) > at >
[jira] [Updated] (IGNITE-10972) MERGE INTO hangs in MVCC mode with unsorted keys
[ https://issues.apache.org/jira/browse/IGNITE-10972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-10972: - Attachment: CacheMvccMergeConflictTest.java > MERGE INTO hangs in MVCC mode with unsorted keys > > > Key: IGNITE-10972 > URL: https://issues.apache.org/jira/browse/IGNITE-10972 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Priority: Major > Attachments: CacheMvccMergeConflictTest.java > > > right now, if you perform repeatedly > MERGE INTO T(K, V) VALUES(k1, v1), (k2, v2), (k3, v3); > and in parallel > MERGE INTO T(K, V) VALUES(k2, v2), (k1, v1); > you will eventually see a deadlock. This is expected behavior as per old > putAll behavior, but the expectation is that you should see "Cannot serialize > transaction" errors instead of deadlock when using MVCC. > When doing MERGE INTO with sorted keys you will not get deadlock but will see > a lot of "Cannot serialize transaction" exception with expectation that such > statements to not conflict instead since they are ordered. > Please see attached test and userlist discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10972) MERGE INTO hangs in MVCC mode with unsorted keys
Ilya Kasnacheev created IGNITE-10972: Summary: MERGE INTO hangs in MVCC mode with unsorted keys Key: IGNITE-10972 URL: https://issues.apache.org/jira/browse/IGNITE-10972 Project: Ignite Issue Type: Bug Components: mvcc, sql Affects Versions: 2.7 Reporter: Ilya Kasnacheev Attachments: CacheMvccMergeConflictTest.java right now, if you perform repeatedly MERGE INTO T(K, V) VALUES(k1, v1), (k2, v2), (k3, v3); and in parallel MERGE INTO T(K, V) VALUES(k2, v2), (k1, v1); you will eventually see a deadlock. This is expected behavior as per old putAll behavior, but the expectation is that you should see "Cannot serialize transaction" errors instead of deadlock when using MVCC. When doing MERGE INTO with sorted keys you will not get deadlock but will see a lot of "Cannot serialize transaction" exception with expectation that such statements to not conflict instead since they are ordered. Please see attached test and userlist discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10824:
-
Fix Version/s: 2.8
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9927) Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
[
https://issues.apache.org/jira/browse/IGNITE-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Kondakov reassigned IGNITE-9927:
--
Assignee: Roman Kondakov
> Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
> ---
>
> Key: IGNITE-9927
> URL: https://issues.apache.org/jira/browse/IGNITE-9927
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> This test was reworked significantly as a part of IGNITE-7953. Unfortunately
> it led to a number of failures appearing from time to time. The goal of this
> ticket is to get rid of these failures.
> Changes from {{51a202a4c48220fa919f47147bd4889033cd35a8}} commit should be
> applied to the test before starting investigation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10971) SQL: Support partition pruning for distributed joins
Vladimir Ozerov created IGNITE-10971:
Summary: SQL: Support partition pruning for distributed joins
Key: IGNITE-10971
URL: https://issues.apache.org/jira/browse/IGNITE-10971
Project: Ignite
Issue Type: Task
Components: sql
Reporter: Vladimir Ozerov
Fix For: 2.8
During IGNITE-10307 implementation it was revealed that distributed joins do
not work with partition pruning. We never observed it before because it was
impossible to derive partitions from joins.
The problem appears as timeout exception from reducer due to some
timeouts/retries inside distributed joins logic. Failures could be reproduced
as follows:
1) Remove {{GridSqlQuerySplitter.distributedJoins}} usage which prevents
partition to be derived for map query.
2) Run any of the following tests and observe that some of tests cases fails
with reducer timeout:
{{IgniteSqlSplitterSelfTest}}
{{IgniteCacheJoinQueryWithAffinityKeyTest}}
{{IgniteCacheDistributedJoinQueryConditionsTest}}
{{IgniteCacheCrossCacheJoinRandomTest}}
Root cause is unknown, but most likely this is due some missing messages,
because some parts of distributed join engine is not aware of extracted
partitions and await for replies from not involved nodes.
Note that most likely the same problem will appear for queries with distributed
joins and explicit partitions ({{SqlFieldsQuery.partitions}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10971) SQL: Support partition pruning for distributed joins
[
https://issues.apache.org/jira/browse/IGNITE-10971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10971:
-
Labels: iep-24 (was: )
> SQL: Support partition pruning for distributed joins
>
>
> Key: IGNITE-10971
> URL: https://issues.apache.org/jira/browse/IGNITE-10971
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> During IGNITE-10307 implementation it was revealed that distributed joins do
> not work with partition pruning. We never observed it before because it was
> impossible to derive partitions from joins.
> The problem appears as timeout exception from reducer due to some
> timeouts/retries inside distributed joins logic. Failures could be reproduced
> as follows:
> 1) Remove {{GridSqlQuerySplitter.distributedJoins}} usage which prevents
> partition to be derived for map query.
> 2) Run any of the following tests and observe that some of tests cases fails
> with reducer timeout:
> {{IgniteSqlSplitterSelfTest}}
> {{IgniteCacheJoinQueryWithAffinityKeyTest}}
> {{IgniteCacheDistributedJoinQueryConditionsTest}}
> {{IgniteCacheCrossCacheJoinRandomTest}}
> Root cause is unknown, but most likely this is due some missing messages,
> because some parts of distributed join engine is not aware of extracted
> partitions and await for replies from not involved nodes.
> Note that most likely the same problem will appear for queries with
> distributed joins and explicit partitions ({{SqlFieldsQuery.partitions}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10307:
-
Ignite Flags: (was: Docs Required)
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745222#comment-16745222
]
Pavel Kuznetsov commented on IGNITE-10824:
--
2 - Done.
1: As disscussed, deceided to work on possible sync problem in IGNITE-10964
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10752) MVCC: Tests invariants are violated sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745214#comment-16745214
]
Ignite TC Bot commented on IGNITE-10752:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=2823868]]
* IgniteCacheRestartTestSuite: GridCachePartitionedNodeRestartTest.testRestart
- 0,0% fails in last 558 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutTwoNodesNoBackups - 0,0%
fails in last 558 master runs.
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutFourNodesNoBackups - 0,0%
fails in last 558 master runs.
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2823875]]
* IgniteCacheTestSuite5:
IgniteCachePartitionLossPolicySelfTest.testReadWriteSafeWithBackupsAfterKillThreeNodesWithPersistence
- 0,0% fails in last 608 master runs.
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2823834]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2823909buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Tests invariants are violated sometimes
> -
>
> Key: IGNITE-10752
> URL: https://issues.apache.org/jira/browse/IGNITE-10752
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Igor Seliverstov
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Sometimes tests are failed by violated invariants errors. For example, when
> total sum on accounts is not as expected.
> Muted tests:
> * {{CacheMvccPartitionedCoordinatorFailoverTest}}
> **
> {{testUpdate_N_Objects_Servers_Backups0__PutGet_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> **
> {{testUpdate_N_Objects_ClientServer_Backups1_PutGet_CoordinatorFails_Persistence}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups1_CoordinatorFails}}
> ** {{testAccountsTxGet_ClientServer_Backups2_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups1_CoordinatorFails_Persistence}}
> ** {{testAccountsTxScan_Server_Backups0_CoordinatorFails}}
> ** {{testGetReadInProgressCoordinatorFails}}
> ** {{testGetReadInsideTxInProgressCoordinatorFails_ReadDelay}}
> * {{CacheMvccReplicatedCoordinatorFailoverTest}}
> ** {{testAccountsTxGet_SingleNode_CoordinatorFails}}
> ** {{testAccountsTxGet_Server_Backups0_CoordinatorFails_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode__PutGet_CoordinatorFails}}
> * {{CacheMvccTransactionsTest.testMvccCoordinatorChangeSimple}}
> * {{DataStreamProcessorMvccPersistenceSelfTest.testTryFlush}}
> * {{IgniteCacheGroupsTest.testCreateDestroyCachesMvccTxReplicated}}
> *
> {{CacheMvccReplicatedSqlCoordinatorFailoverTest.testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> * {{CacheMvccPartitionedSqlCoordinatorFailoverTest}}
> ** {{testUpdate_N_Objects_ClientServer_Backups2_Sql}}
> ** {{testUpdate_N_Objects_ClientServer_Backups1_Sql_Persistence}}
> ** {{testUpdate_N_Objects_SingleNode_Sql_Persistence}}
> ** {{testUpdate_N_Objects_ClientServer_Backups0_Sql_Persistence}}
> **
> {{testPutAllGetAll_ClientServer_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> **
> {{testPutAllGetAll_Server_Backups1_SinglePartition_RestartRandomSrv_SqlDml}}
> ** {{testPutAllGetAll_ClientServer_Backups3_RestartCoordinator_ScanDml}}
> ** {{testAccountsTxSql_Server_Backups0_CoordinatorFails}}
> ** {{testAccountsTxSql_Server_Backups1_CoordinatorFails_Persistence}}
> {noformat}
> junit.framework.AssertionFailedError: Unexpected error:
> junit.framework.AssertionFailedError: expected:<0> but was:<4>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1362)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$10.call(CacheMvccAbstractTest.java:1350)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745212#comment-16745212 ] Sergey Antonov commented on IGNITE-10507: - [~ivan.glukos] ok, I will add checking checkpoint flag after for loop. > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745209#comment-16745209 ] Ivan Rakov commented on IGNITE-10507: - [~antonovsergey93] I mean that checkpoint may start exactly when we are reading last page. Will we react to false-positive error in such case? > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10769) MVCC: CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails sometimes
[
https://issues.apache.org/jira/browse/IGNITE-10769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745206#comment-16745206
]
Roman Kondakov commented on IGNITE-10769:
-
I wasn't able to reproduce this fail locally. May be this issue has been
already fixed by the another patches.
> MVCC: CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery fails
> sometimes
> --
>
> Key: IGNITE-10769
> URL: https://issues.apache.org/jira/browse/IGNITE-10769
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test {{CacheMvccContinuousQueryClientTest.testNodeJoinsRestartQuery}} fails
> sometimes.
> {noformat}
> class org.apache.ignite.IgniteException: Unable to find 1 requied keys.
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.findKeys(GridCommonAbstractTest.java:1128)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKeys(GridCommonAbstractTest.java:1071)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.primaryKey(GridCommonAbstractTest.java:1343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientTest.testNodeJoinsRestartQuery(IgniteCacheContinuousQueryClientTest.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745195#comment-16745195 ] Sergey Antonov commented on IGNITE-10507: - [~ivan.glukos] 4) We are checking checkpoint flag before reading every page (including last page). Could you expain what you meant? > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[ https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745187#comment-16745187 ] Ivan Rakov commented on IGNITE-10507: - [~ivandasch], got it. Please never mind item 2) then :) > Control.sh add ability to check crc sums of stored pages > > > Key: IGNITE-10507 > URL: https://issues.apache.org/jira/browse/IGNITE-10507 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Critical > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have ability to check stored data on disk. Also we should return > all exceptions from all nodes, if they are occurred. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745175#comment-16745175
]
Vladimir Ozerov commented on IGNITE-10307:
--
Both failures are false-positive.
https://ci.ignite.apache.org/viewQueued.html?itemId=2825852
https://ci.ignite.apache.org/viewQueued.html?itemId=2825850
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745163#comment-16745163
]
Ivan Daschinskiy commented on IGNITE-10507:
---
[~ivan.glukos]
2) It's ok,
{code:java}
if (grpCtx == null || !grpCtx.persistenceEnabled()) {
integrityCheckedIndexes.incrementAndGet();
continue;
}
Future> checkFut =
calcExecutor.submit(new Callable>() {
@Override public T2
call() throws Exception {
IndexIntegrityCheckIssue issue =
integrityCheckIndexPartition(grpCtx);
return new T2<>(grpCtx.groupId(), issue);
}
});
integrityCheckFutures.add(checkFut);
{code}
>From these code, you can see, that if grp is inmemory, we simply skip this
>check.
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745163#comment-16745163
]
Ivan Daschinskiy edited comment on IGNITE-10507 at 1/17/19 3:00 PM:
[~ivan.glukos]
2) It's ok,
{code:java}
if (grpCtx == null || !grpCtx.persistenceEnabled()) {
integrityCheckedIndexes.incrementAndGet();
continue;
}
Future> checkFut =
calcExecutor.submit(new Callable>() {
@Override public T2
call() throws Exception {
IndexIntegrityCheckIssue issue =
integrityCheckIndexPartition(grpCtx);
return new T2<>(grpCtx.groupId(), issue);
}
});
integrityCheckFutures.add(checkFut);
{code}
>From these code, you can see, that if grp is inmemory, we simply skip this
>check.
was (Author: ivandasch):
[~ivan.glukos]
2) It's ok,
{code:java}
if (grpCtx == null || !grpCtx.persistenceEnabled()) {
integrityCheckedIndexes.incrementAndGet();
continue;
}
Future> checkFut =
calcExecutor.submit(new Callable>() {
@Override public T2
call() throws Exception {
IndexIntegrityCheckIssue issue =
integrityCheckIndexPartition(grpCtx);
return new T2<>(grpCtx.groupId(), issue);
}
});
integrityCheckFutures.add(checkFut);
{code}
>From these code, you can see, that if grp is inmemory, we simply skip this
>check.
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745162#comment-16745162
]
Ignite TC Bot commented on IGNITE-10307:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2822952]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithPutFourNodesNoBackups - 0,0%
fails in last 558 master runs.
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2822918]]
* GridServiceInjectionSpringResourceTest.testDeployServiceWithSpring (last
started)
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2822993buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-10930) [TC Bot] Support PR-less contributions
[ https://issues.apache.org/jira/browse/IGNITE-10930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-10930. - Resolution: Fixed Supported in V190117 Now apache (origin) branches ignite- and its run-alls may be used for checking this code & obtaining TC Bot visa. > [TC Bot] Support PR-less contributions > -- > > Key: IGNITE-10930 > URL: https://issues.apache.org/jira/browse/IGNITE-10930 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > An Apache Ignite committer can prepare issue fix with origin/ignite-1 > branch. And this contributions testing does not require any PR creations, > because TC RunAll may be created without it. > Support contributions detection by provided TC run for branches matching > ignite-N, where N=0-9 > If such RunAll presented for any tracked branch and JIRA issue is in PA > state, we may display these branches as addition to PRs, show its report and > setup VISA into IGNITE-N ticket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10969) Add Mvcc tests to RunAll.
[ https://issues.apache.org/jira/browse/IGNITE-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov resolved IGNITE-10969. --- Resolution: Done Added to [--> Run :: All|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll]: * MVCC Cache [1-9] * MVCC PDS [1-4] > Add Mvcc tests to RunAll. > - > > Key: IGNITE-10969 > URL: https://issues.apache.org/jira/browse/IGNITE-10969 > Project: Ignite > Issue Type: Sub-task >Reporter: Andrew Mashenkov >Assignee: Peter Ivanov >Priority: Major > > "Mvcc Cache *" and "Mvcc PDS *" test suites to Run::All suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9739) Critical exception in transaction processing in case we have nodes out of baseline and non-persisted cache
[
https://issues.apache.org/jira/browse/IGNITE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745160#comment-16745160
]
Ivan Rakov commented on IGNITE-9739:
Merged follow-up fix to master:
d15c475fc960534588c4e66b2fccdbef4bc1ff63
IGNITE-9739 fix NPE on MVCC path - Fixes #5846. Sergey Kosarev* 17.01.2019 17:48
> Critical exception in transaction processing in case we have nodes out of
> baseline and non-persisted cache
> --
>
> Key: IGNITE-9739
> URL: https://issues.apache.org/jira/browse/IGNITE-9739
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Activation finished
> {code:java}
> 2018-09-20 20:47:05.169 [INFO
> ][sys-#307%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Successfully performed final activation steps
> [nodeId=382437eb-fd8a-4f92-acd5-d9ea562c8557, client=false,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=1]]
> {code}
> but we have nodes not in base line
> {code:java}
> 2018-09-20 20:45:36.116 [INFO
> ][sys-#305%DPL_GRID%DplGridNodeName%][o.g.g.i.p.c.d.GridSnapshotAwareClusterStateProcessorImpl]
> Local node is not included in Baseline Topology and will not be used for
> persistent data storage. Use control.(sh|bat) script or IgniteCluster
> interface to include the node to Baseline Topology.
> {code}
> And we have cache (869481129) in the data region with persistanceEnabled=false
> {code:java}
> 2018-09-20 20:49:01.825 [INFO
> ][exchange-worker-#154%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheProcessor]
> Started cache [name=DPL_PUBLISHED_CACHES_REGISTRY$, *id=869481129*, group=SY
> STEM_CACHEGROUP_PUBLISHED_REGISTRY, memoryPolicyName=not-persisted,
> mode=PARTITIONED, atomicity=TRANSACTIONAL, backups=3]
> {code}
> Transaction on this cache(869481129)
> {code:java}
> 869481129{code}
> leads to critical error causing nodes by faulure handler:
> {code:java}
> 2018-09-20 20:50:24.275
> [ERROR][sys-stripe-41-#42%DPL_GRID%DplGridNodeName%][o.a.i.i.p.cache.GridCacheIoManager]
> Failed processing message [senderId=62e986f0-62b5-4ec8-8cc7-27b74d345235,
> msg=GridDhtTxPrepareRequest [nearNodeId=814af7c4-2de5-4511-b1ea-065b91eaa774,
> futId=520e308f561-255fdea5-a996-4102-a120-afa380c54570, miniId=1,
> topVer=AffinityTopologyVersion [topVer=160, minorTopVer=2],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=148944365, order=1537511036821,
> nodeOrder=132], subjId=814af7c4-2de5-4511-b1ea-065b91eaa774, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=58, concurrency=PESSIMISTIC,
> isolation=READ_COMMITTED, writeVer=GridCacheVersion [topVer=148944365,
> order=1537511036824, nodeOrder=7], timeout=299970, reads=null,
> writes=ArrayList [
> IgniteTxEntry [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=27254,
> val=com.sbt.api.entities.out.IPublishedDocType, hasValBytes=true],
> *cacheId=869481129*], val=[op=CREATE,
> val=com.sbt.dpl.gridgain.PublishedRegistry$PublishedCacheTuple
> [idHash=811765531, hash=1522508040,
> cacheName=com.sbt.gbk.entities.DocType_DPL_union-module,indexes=ArrayList
> {com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1583970836, hash=363194492, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList
> \{isDeleted},moduleName=union-module
> , cachedUnselectives=1, selectors=ArrayList {isDeleted},
> exceptUnselectives=false, primitiveCollection=false, isVersioned=false,
> isComposite=false, isSystemTypeBelongs=false,
> name=com.sbt.gbk.entities.DocType_DPL_isDeleted, isIndexedCollection=false,
> isGlobal=false, maxSelective=1000],
> com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=2060926101, hash=1983794578, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList ,moduleName=union-module,
> cachedUnselectives=1, selectors=ArrayList, exceptUnselectives=false,
> primitiveCollection=false, isVersioned=false, isComposite=false,
> isSystemTypeBelongs=false, name=com.sbt.gbk.entities.DocType_DPL_code,
> isIndexedCollection=false, isGlobal=true, maxSelective=1000]
> , com.sbt.dpl.gridgain.newModel.base.indexes.PublishedIndexType
> [idHash=1821682714, hash=-1245813786, isSoftReference=false,
> unselectiveBuckets=4096, fieldNames=ArrayList {globalId},
> moduleName=union-module, cachedUnselectives=1, selectors=ArrayList
>
[jira] [Commented] (IGNITE-10768) MVCC: CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned may hang
[
https://issues.apache.org/jira/browse/IGNITE-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745148#comment-16745148
]
Roman Kondakov commented on IGNITE-10768:
-
I wasn't able to reproduce this hanging locally. May be the cause was fixed in
the some previous tasks.
> MVCC:
> CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned
> may hang
> -
>
> Key: IGNITE-10768
> URL: https://issues.apache.org/jira/browse/IGNITE-10768
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
>
> Test
> {{CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned}}
> may hang sometimes.
>
> {noformat}
> Thread [name="test-runner-#209301%mvcc.CacheMvccBasicContinuousQueryTest%",
> id=228123, state=WAITING, blockCnt=5, waitCnt=89]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:179)
> at
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.checkUpdateCountersGapIsProcessedSimple(CacheMvccBasicContinuousQueryTest.java:346)
> at
> o.a.i.i.processors.cache.mvcc.CacheMvccBasicContinuousQueryTest.testUpdateCountersGapClosedSimplePartitioned(CacheMvccBasicContinuousQueryTest.java:257)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> o.a.i.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2121)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10969) Add Mvcc tests to RunAll.
Andrew Mashenkov created IGNITE-10969: - Summary: Add Mvcc tests to RunAll. Key: IGNITE-10969 URL: https://issues.apache.org/jira/browse/IGNITE-10969 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov "Mvcc Cache *" and "Mvcc PDS *" test suites to Run::All suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745149#comment-16745149
]
Ilya Kasnacheev commented on IGNITE-10970:
--
e.g.
{{Invalid value of "ATOMICITY" parameter (should be either ATOMIC,
TRANSACTIONAL or TRANSACTIONAL_SNAPSHOT)}}
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
Ilya Kasnacheev created IGNITE-10970:
Summary: ATOMICITY table creation error message should include
TRANSACTIONAL_SNAPSHOT
Key: IGNITE-10970
URL: https://issues.apache.org/jira/browse/IGNITE-10970
Project: Ignite
Issue Type: Bug
Components: mvcc, sql
Affects Versions: 2.7
Reporter: Ilya Kasnacheev
{code}
0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
or ATOMIC): mvcc (state=42000,code=1001)
{code}
This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate MVCC,
which totally works.
Docs update request sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10969) Add Mvcc tests to RunAll.
[ https://issues.apache.org/jira/browse/IGNITE-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-10969: - Assignee: Peter Ivanov > Add Mvcc tests to RunAll. > - > > Key: IGNITE-10969 > URL: https://issues.apache.org/jira/browse/IGNITE-10969 > Project: Ignite > Issue Type: Sub-task >Reporter: Andrew Mashenkov >Assignee: Peter Ivanov >Priority: Major > > "Mvcc Cache *" and "Mvcc PDS *" test suites to Run::All suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10969) Add Mvcc tests to RunAll.
[ https://issues.apache.org/jira/browse/IGNITE-10969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10969: -- Issue Type: Sub-task (was: Test) Parent: IGNITE-10001 > Add Mvcc tests to RunAll. > - > > Key: IGNITE-10969 > URL: https://issues.apache.org/jira/browse/IGNITE-10969 > Project: Ignite > Issue Type: Sub-task >Reporter: Andrew Mashenkov >Priority: Major > > "Mvcc Cache *" and "Mvcc PDS *" test suites to Run::All suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745122#comment-16745122
]
Ivan Rakov edited comment on IGNITE-10507 at 1/17/19 2:32 PM:
--
[~antonovsergey93], I had a look. A few comments:
1)
{code:java}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by
async runner";
}
{code}
Such exception handling is suspicious. At least, exception will be simply
ignored if assertions are disabled, which is not okay.
2) On the first glance, there's risk of ClassCastException in
ValidateIndexesClosure#integrityCheckIndexPartition: cast to
FilePageStoreManager will fail if group is not persistent.
3) VerifyBackupPartitionsJobV2#checkPartitionCrc and
ValidateIndexesClosure#integrityCheckIndexPartition look really alike. It's up
yo you, but I think we can extract common logic here.
4)
{code:java}
for (int pageNo = 0; pageNo < pageStore.pages(); pageId++,
pageNo++) {
buf.clear();
if (cpFlag.get())
throw new GridNotIdleException("Checkpoint with
dirty pages started! Cluster not idle!");
pageStore.read(pageId, buf, true);
}
{code}
Reading last page is not protected by checking checkpoint flag.
5) It's a minor, but there are several places when your code lacks some spaces.
Examples:
{code:java}
@Override public String getMessage() {
return
exceptions.stream().map(e->e.getMessage()).collect(Collectors.joining(", "));
}
{code}
{code:java}
@Override public String toString() {
return getClass() +": " + getMessage();
}
{code}
{code:java}
if(!F.isEmpty(exceptions)){
File f = new File(IDLE_VERIFY_FILE_PREFIX +
LocalDateTime.now().format(TIME_FORMATTER) + ".txt");
try(PrintWriter pw = new PrintWriter(f)) {
{code}
{code:java}
if(arg.isCheckCrc())
checkPartitionCrc(grpCtx, part, cpFlag);
{code}
and so on.
was (Author: ivan.glukos):
[~antonovsergey93], I had a look. A few comments:
1)
{code:java}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by
async runner";
}
{code}
Such exception handling is suspicious. At least, exception will be simply
ignored if assertions are disabled, which is not okay.
2) On the first glance, there's risk of ClassCastException in
ValidateIndexesClosure#integrityCheckIndexPartition: cast to
FilePageStoreManager will fail if group is not persistent.
3) VerifyBackupPartitionsJobV2#checkPartitionCrc and
ValidateIndexesClosure#integrityCheckIndexPartition look really alike. It's up
yo you, but I think we can extract common logic here.
4)
{code:java}
for (int pageNo = 0; pageNo < pageStore.pages(); pageId++,
pageNo++) {
buf.clear();
if (cpFlag.get())
throw new GridNotIdleException("Checkpoint with
dirty pages started! Cluster not idle!");
pageStore.read(pageId, buf, true);
}
{code}
Reading last page is not protected by checking checkpoint flag.
4) It's a minor, but there are several places when your code lacks some spaces.
Examples:
{code:java}
@Override public String getMessage() {
return
exceptions.stream().map(e->e.getMessage()).collect(Collectors.joining(", "));
}
{code}
{code:java}
@Override public String toString() {
return getClass() +": " + getMessage();
}
{code}
{code:java}
if(!F.isEmpty(exceptions)){
File f = new File(IDLE_VERIFY_FILE_PREFIX +
LocalDateTime.now().format(TIME_FORMATTER) + ".txt");
try(PrintWriter pw = new PrintWriter(f)) {
{code}
{code:java}
if(arg.isCheckCrc())
checkPartitionCrc(grpCtx, part, cpFlag);
{code}
and so on.
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745122#comment-16745122
]
Ivan Rakov commented on IGNITE-10507:
-
[~antonovsergey93], I had a look. A few comments:
1)
{code:java}
catch (RejectedExecutionException e) {
assert false : "A task should never be rejected by
async runner";
}
{code}
Such exception handling is suspicious. At least, exception will be simply
ignored if assertions are disabled, which is not okay.
2) On the first glance, there's risk of ClassCastException in
ValidateIndexesClosure#integrityCheckIndexPartition: cast to
FilePageStoreManager will fail if group is not persistent.
3) VerifyBackupPartitionsJobV2#checkPartitionCrc and
ValidateIndexesClosure#integrityCheckIndexPartition look really alike. It's up
yo you, but I think we can extract common logic here.
4)
{code:java}
for (int pageNo = 0; pageNo < pageStore.pages(); pageId++,
pageNo++) {
buf.clear();
if (cpFlag.get())
throw new GridNotIdleException("Checkpoint with
dirty pages started! Cluster not idle!");
pageStore.read(pageId, buf, true);
}
{code}
Reading last page is not protected by checking checkpoint flag.
4) It's a minor, but there are several places when your code lacks some spaces.
Examples:
{code:java}
@Override public String getMessage() {
return
exceptions.stream().map(e->e.getMessage()).collect(Collectors.joining(", "));
}
{code}
{code:java}
@Override public String toString() {
return getClass() +": " + getMessage();
}
{code}
{code:java}
if(!F.isEmpty(exceptions)){
File f = new File(IDLE_VERIFY_FILE_PREFIX +
LocalDateTime.now().format(TIME_FORMATTER) + ".txt");
try(PrintWriter pw = new PrintWriter(f)) {
{code}
{code:java}
if(arg.isCheckCrc())
checkPartitionCrc(grpCtx, part, cpFlag);
{code}
and so on.
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10559) MVCC TX: Use extracted partitions to reduce target nodes for Query Update
[ https://issues.apache.org/jira/browse/IGNITE-10559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov reassigned IGNITE-10559: - Assignee: Taras Ledkov > MVCC TX: Use extracted partitions to reduce target nodes for Query Update > - > > Key: IGNITE-10559 > URL: https://issues.apache.org/jira/browse/IGNITE-10559 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Taras Ledkov >Priority: Minor > Labels: iep-24 > Time Spent: 10m > Remaining Estimate: 0h > > We may avoid "query reduce" step on update queries without sorting/grouping > by simply sending them to all data nodes and executing update operation > locally. Using extracted from SQL partitions will reduce target nodes count > and save resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8573) Save baseline auto-adjust parameters to metastore
[
https://issues.apache.org/jira/browse/IGNITE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745109#comment-16745109
]
Ignite TC Bot commented on IGNITE-8573:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2822765buildTypeId=IgniteTests24Java8_RunAll]
> Save baseline auto-adjust parameters to metastore
> -
>
> Key: IGNITE-8573
> URL: https://issues.apache.org/jira/browse/IGNITE-8573
> Project: Ignite
> Issue Type: New Feature
>Reporter: Eduard Shangareev
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: IEP-4, Phase-2
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We would introduce at IGNITE-8571 new parameters. They should be saved in the
> metastore and restored from it on node/cluster restart.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10949) org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE
[
https://issues.apache.org/jira/browse/IGNITE-10949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745102#comment-16745102
]
Ignite TC Bot commented on IGNITE-10949:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2814251buildTypeId=IgniteTests24Java8_RunAll]
> org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE
> --
>
> Key: IGNITE-10949
> URL: https://issues.apache.org/jira/browse/IGNITE-10949
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Andrey Kalinin
>Priority: Major
> Labels: newbie
> Time Spent: 10m
> Remaining Estimate: 0h
>
> method entrySet return null then generates NullPointerException in method
> hashCode, toString and all classes that use an instance of this object.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-601) IgniteCache.isLocalLocked is broken
[
https://issues.apache.org/jira/browse/IGNITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745074#comment-16745074
]
Ignite TC Bot commented on IGNITE-601:
--
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2645317]]
* exe: CacheAbstractTransactionalTest.TestLockSimple - 0,0% fails in last 251
master runs.
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2645258]]
* IgniteSpiTestSuite: IgniteClientConnectTest.testClientConnectToBigTopology -
0,0% fails in last 227 master runs.
{color:#d04437}Cache (Restarts) 2{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=2645289]]
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithPutEightNodesTwoBackups - 0,0%
fails in last 234 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,0%
fails in last 234 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxSixNodesTwoBackups - 0,0%
fails in last 234 master runs.
* IgniteCacheRestartTestSuite2:
IgniteCacheAtomicNodeRestartTest.testRestartWithTxFourNodesOneBackups - 0,0%
fails in last 234 master runs.
{color:#d04437}~Build Apache Ignite~{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=2662376]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2645327buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCache.isLocalLocked is broken
> ---
>
> Key: IGNITE-601
> URL: https://issues.apache.org/jira/browse/IGNITE-601
> Project: Ignite
> Issue Type: Bug
>Reporter: Artem Shutak
>Assignee: Semen Boikov
>Priority: Major
> Labels: Muted_test
>
> To reproduce change GridCachePartitionedBasicApiTest to use PARTITIONED_ONLY
> cache instead of NEAR_PARTITIONED.
> See GG-7437. Comments from origin Jira:
> - Fixed in gg-7434-1
> - Reopening since there are left TODOs in data grid test suite.
> Now, see GridCacheReplicatedNearOnlyMultiNodeFullApiSelfTest # lockingEnabled
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745067#comment-16745067 ] Igor Seliverstov commented on IGNITE-10798: --- [~sergi.vladykin], from MVCC perspective looks OK, at least I see no issues. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745056#comment-16745056
]
Roman Kondakov commented on IGNITE-10755:
-
[~gvvinblade], patch is ready for review. Tests look good. Multiple fails in
MVCC Cache suite are caused by some problems in the master branch.
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745049#comment-16745049
]
Ignite TC Bot commented on IGNITE-10755:
{panel:title=- Run :: MVCC Cache: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC PDS 1{color} [[tests
32|https://ci.ignite.apache.org/viewLog.html?buildId=2822879]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers_5_Clients_FromClient
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivateInProgress
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers_5_Clients
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover1 -
2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover2 -
2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActive
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_5_Servers2
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover1 - 2,3%
fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateSimple_5_Servers_5_Clients
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testJoinWhileDeactivate1_Server
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testJoinWhileActivate1_Client
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testJoinWhileDeactivate1_Client
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testInactiveTopologyChanges
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateSimple_SingleNode
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testConcurrentJoinAndActivate
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateSimple_5_Servers_5_Clients_FromClient
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateSimple_5_Servers
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateSimple_5_Servers2
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterDeactivateInProgress
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateSimple_SingleNode
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterDeactivated
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterActivated
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateCachesRestore_SingleNode
- 2,3% fails in last 608 master runs.
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testActivateCachesRestore_5_Servers
- 2,3% fails in last 608 master runs.
{color:#d04437}MVCC PDS 4{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=2822882]]
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testInactiveTopologyChanges
- 2,3% fails in last 607 master runs.
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testJoinWhileDeactivate1_Client
- 2,3% fails in last 607 master runs.
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testActivateFailover2
- 2,3% fails in last 607 master runs.
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testDeactivateFailover2
- 2,3% fails in last 607 master runs.
*
[jira] [Updated] (IGNITE-10968) [ML] Create new ignite module SparkMLModelImport and add LogRegression converter
[ https://issues.apache.org/jira/browse/IGNITE-10968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10968: -- Priority: Critical (was: Major) > [ML] Create new ignite module SparkMLModelImport and add LogRegression > converter > > > Key: IGNITE-10968 > URL: https://issues.apache.org/jira/browse/IGNITE-10968 > Project: Ignite > Issue Type: Sub-task > Components: ml >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > > * Create new module > * Add specific dependencies (ml/hadoop/spark/parquet) > * Move LogRegression example to this module -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10968) [ML] Create new ignite module SparkMLModelImport and add LogRegression converter
Aleksey Zinoviev created IGNITE-10968: - Summary: [ML] Create new ignite module SparkMLModelImport and add LogRegression converter Key: IGNITE-10968 URL: https://issues.apache.org/jira/browse/IGNITE-10968 Project: Ignite Issue Type: Sub-task Components: ml Reporter: Aleksey Zinoviev Assignee: Aleksey Zinoviev * Create new module * Add specific dependencies (ml/hadoop/spark/parquet) * Move LogRegression example to this module -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[ https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko reassigned IGNITE-10179: --- Assignee: Oleg Ignatenko > Change new tests root to use @BeforeClass and @AfterClass instead of > isFirstTest() and isLastTest() > --- > > Key: IGNITE-10179 > URL: https://issues.apache.org/jira/browse/IGNITE-10179 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > > If needed, refer parent task for more details. > isFirstTest() and isLastTest() homebrew methods seem to be in > GridAbstractTest only because Junit 3 lacked necessary functionality; after > migration to Junit 4 these would better changed to use standard API of this > framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10755) MVCC: Flaky continuous query tests
[
https://issues.apache.org/jira/browse/IGNITE-10755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745042#comment-16745042
]
Ignite TC Bot commented on IGNITE-10755:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2822868buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Flaky continuous query tests
> --
>
> Key: IGNITE-10755
> URL: https://issues.apache.org/jira/browse/IGNITE-10755
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some continuous query tests are flaky when MVCC is enabled:
> * {{CacheContinuousQueryConcurrentPartitionUpdateTest}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTxCacheGroup}}
> ** {{testConcurrentUpdatesAndQueryStartMvccTx}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10967) Assertion error in log during ExchangeFuture init
Roman Kondakov created IGNITE-10967:
---
Summary: Assertion error in log during ExchangeFuture init
Key: IGNITE-10967
URL: https://issues.apache.org/jira/browse/IGNITE-10967
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7
Reporter: Roman Kondakov
Fix For: 2.8
There are some assertion errors occur in the log when test
{{IgniteClientReconnectCacheTest#testReconnectMultinode}} is running. Looks
like a wrong assertion. Should be investigated.
{noformat}
[2019-01-17
16:14:51,972][ERROR][exchange-worker-#635%internal.IgniteClientReconnectCacheTest7%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:874)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2886)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2735)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10582) MVCC: Error on txLog initialization.
[
https://issues.apache.org/jira/browse/IGNITE-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745012#comment-16745012
]
Ignite TC Bot commented on IGNITE-10582:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2816477buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Error on txLog initialization.
>
>
> Key: IGNITE-10582
> URL: https://issues.apache.org/jira/browse/IGNITE-10582
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, pagememory
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A sporadic error occurs during {{txLog}} initialization. Reproducer:
> {{IgnitePdsCacheAssignmentNodeRestartsTest#testAssignmentAfterRestarts}}.
> This error may be the result of the test settings. We need to check it more
> carefully.
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to complete exchange process.
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCaches(IgniteKernal.java:3068)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsCacheAssignmentNodeRestartsTest.testAssignmentAfterRestarts(IgnitePdsCacheAssignmentNodeRestartsTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete
> exchange process.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3041)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3069)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3151)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2748)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2556)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1807)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:145)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:382)
> at
>
[jira] [Comment Edited] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745009#comment-16745009 ] Pavel Voronkin edited comment on IGNITE-10877 at 1/17/19 12:47 PM: --- 65k partitions, 160 nodes, 3 backups !image-2019-01-17-15-45-53-043.png! !image-2019-01-17-15-46-32-872.png! was (Author: voropava): 65k partitions 160 nodes !image-2019-01-17-15-45-53-043.png! !image-2019-01-17-15-46-32-872.png! > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10877: Attachment: image-2019-01-17-15-46-32-872.png > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745009#comment-16745009 ] Pavel Voronkin commented on IGNITE-10877: - 65k partitions 160 nodes !image-2019-01-17-15-45-53-043.png! !image-2019-01-17-15-46-32-872.png! > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png, > image-2019-01-17-15-46-32-872.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10877: Attachment: image-2019-01-17-15-45-49-561.png > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10877: Attachment: image-2019-01-17-15-45-53-043.png > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png, > image-2019-01-17-15-45-49-561.png, image-2019-01-17-15-45-53-043.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[
https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745006#comment-16745006
]
Ignite TC Bot commented on IGNITE-10877:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2815399buildTypeId=IgniteTests24Java8_RunAll]
> GridAffinityAssignment.initPrimaryBackupMaps memory pressure
>
>
> Key: IGNITE-10877
> URL: https://issues.apache.org/jira/browse/IGNITE-10877
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Pavel Voronkin
>Priority: Major
> Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr,
> image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> 1) While running tests with JFR we observe huge memory allocation pressure
> produced by:
> *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)*
> java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784
> 100
> java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044
> 784 100
> java.util.HashMap.put(Object, Object) 481 298 044 784 100
> java.util.HashSet.add(Object) 480 297 221 040 99,724
>
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps()
> 1 823 744 0,276
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion,
> List, List) 1 823 744 0,276
> *Allocation stats*
> Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB
> Size(bytes) Total TLAB Size(bytes) Pressure(%)
> java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876
> java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687
> java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864
> 11,341
> java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654
> java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198
> 2) Also another hot place found
> Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)
> java.util.ArrayList.grow(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554
> java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554
> java.util.ArrayList.add(Object) 7 5 766 448 9,554
>
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int,
> AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5
> 766 448 9,554
> The reason of that is defail
> I think we need to improve memory efficiency by switching from from Sets to
> BitSets
>
> JFR attached, see Allocations in 12:50:28 - 12:50:29
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745005#comment-16745005 ] Ilya Kasnacheev commented on IGNITE-6564: - I have left a change request in PR review. Can you also split off the refactoring part as a separate PR? Best if under a dedicated ticket. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 40m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10582) MVCC: Error on txLog initialization.
[
https://issues.apache.org/jira/browse/IGNITE-10582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745003#comment-16745003
]
Ignite TC Bot commented on IGNITE-10582:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2816477buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Error on txLog initialization.
>
>
> Key: IGNITE-10582
> URL: https://issues.apache.org/jira/browse/IGNITE-10582
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, pagememory
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A sporadic error occurs during {{txLog}} initialization. Reproducer:
> {{IgnitePdsCacheAssignmentNodeRestartsTest#testAssignmentAfterRestarts}}.
> This error may be the result of the test settings. We need to check it more
> carefully.
> Stacktrace:
> {noformat}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> Failed to complete exchange process.
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.IgniteKernal.getOrCreateCaches(IgniteKernal.java:3068)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsCacheAssignmentNodeRestartsTest.testAssignmentAfterRestarts(IgnitePdsCacheAssignmentNodeRestartsTest.java:148)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$001(GridAbstractTest.java:149)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.evaluate(GridAbstractTest.java:2106)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2123)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to complete
> exchange process.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.createExchangeException(GridDhtPartitionsExchangeFuture.java:3041)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.sendExchangeFailureMessage(GridDhtPartitionsExchangeFuture.java:3069)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:3151)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:3135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2748)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:138)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2556)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:395)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:355)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2544)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1807)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1200(GridCachePartitionExchangeManager.java:145)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:382)
> at
>
[jira] [Updated] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10966: -- Issue Type: Test (was: Bug) > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10966: -- Labels: MakeTeamcityGreenAgain (was: ) > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10966: -- Issue Type: Bug (was: Test) > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10966: -- Ignite Flags: (was: Docs Required) > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744991#comment-16744991 ] Ilya Kasnacheev commented on IGNITE-6564: - [~a-polyakov] Is size() returning 0 a change of behavior or was it already the case? > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
[ https://issues.apache.org/jira/browse/IGNITE-10966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-10966: -- Fix Version/s: 2.8 > MVCC: Add scale factor support in Mvcc tests suites. > > > Key: IGNITE-10966 > URL: https://issues.apache.org/jira/browse/IGNITE-10966 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, Mvcc suites do not support "scale factor" and run only on nightly > basis. > We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" > tests to save TC time in RunAll. (Full run on nightly basis with no scaling > will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744972#comment-16744972 ] Igor Seliverstov commented on IGNITE-10798: --- [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10966) MVCC: Add scale factor support in Mvcc tests suites.
Andrew Mashenkov created IGNITE-10966: - Summary: MVCC: Add scale factor support in Mvcc tests suites. Key: IGNITE-10966 URL: https://issues.apache.org/jira/browse/IGNITE-10966 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov For now, Mvcc suites do not support "scale factor" and run only on nightly basis. We should add "scale factor" for "Mvcc Cache suite" and "Mvcc SQL suite" tests to save TC time in RunAll. (Full run on nightly basis with no scaling will not be affected) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10798) Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-10798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744972#comment-16744972 ] Igor Seliverstov edited comment on IGNITE-10798 at 1/17/19 12:18 PM: - [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. Until IGNITE-9322 is not done you need to resolve deadlocks manually (using timeouts or sorting) was (Author: gvvinblade): [~vozerov],[~sergi.vladykin], the main cause is a deadlock. There is no tx timeout and account ids are random and unsorted. > Data page scan for ScanQuery, SqlQuery and SqlFieldsQuery > - > > Key: IGNITE-10798 > URL: https://issues.apache.org/jira/browse/IGNITE-10798 > Project: Ignite > Issue Type: Improvement > Components: cache, sql >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[ https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744959#comment-16744959 ] Yury Gerzhedovich commented on IGNITE-10754: [~vozerov], Thanks for detailed comment. It were really fluky tests, which not fail at all for my previous runs. Now it fixed. > Query history statistics API > > > Key: IGNITE-10754 > URL: https://issues.apache.org/jira/browse/IGNITE-10754 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29, monitoring > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > As of now we have query statistics > (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. > 1) Duration execution it just time between start execution and return cursor > to client and doesn't include all life time of query. > 2) It doesn't know about multistatement queries. Such queries participate in > statistics as single query without splitting. > 3) API to access the statistics expose as depend on cache, however query > don't have such dependency. > > Need to create parallel similar realization as we already have. > Use new infrastructure of tracking running queries developed under > IGNITE-10621 and update statistics on unregister phase. > Expose API on upper level then it placed now. Right place will be written > later. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8630) Node filter IgnitePredicate executes twice during deploying on one single node cluster
[
https://issues.apache.org/jira/browse/IGNITE-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Aleksandrov closed IGNITE-8630.
--
Thank you for confirmation!
> Node filter IgnitePredicate executes twice during deploying on one single
> node cluster
> --
>
> Key: IGNITE-8630
> URL: https://issues.apache.org/jira/browse/IGNITE-8630
> Project: Ignite
> Issue Type: Bug
> Components: managed services
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Assignee: Vyacheslav Daradur
>Priority: Major
> Fix For: 2.8
>
>
> Next code:
> {code:java}
> Ignite ignite =
> IgnitionEx.start("examples/config/example-ignite.xml", "ignite-1");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ?
> null : filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> Produces next output:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1{code}
> In case if we will increase the cluster size to 2 then we will have:
> {code:java}
> Ignite ignite = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-1");
> Ignite ignite2 = IgnitionEx.start("examples/config/example-ignite.xml",
> "ignite-2");
> // Deploy services only on server nodes.
> ignite.services().deploy(new ServiceConfiguration()
> .setMaxPerNodeCount(1)
> .setNodeFilter(new IgnitePredicate() {
> Ignite filterIgnite;
> @Override public boolean apply(ClusterNode node) {
> System.out.println("Is local node: " + node.isLocal());
> System.out.println("ignite: " + (isNull(filterIgnite) ? null :
> filterIgnite.name()));
> return true;
> }
> @IgniteInstanceResource
> void setFilterIgnite(Ignite filterIgnite) {
> this.filterIgnite = filterIgnite;
> }
> })
> .setName("my-service")
> .setService(new SimpleMapServiceImpl<>())
> );
> {code}
> We will get:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Service was initialized: my-service
> Executing distributed service: my-service
> Service was initialized: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> Executing distributed service: my-service
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1
> {code}
> So we have additional execution:
> {code:java}
> Is local node: true
> ignite: ignite-1
> Is local node: false
> ignite: ignite-1{code}
> So Ignite executes apply method several times (2 times for 1 server, 6 times
> for 2 servers). This behavior should be documented or fixed because at the
> moment it's could be unexpected for the user.
> You can see the same behaviour during deploying of the caches with nodeFilter
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10347:
---
Description:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query with format \{node_order_id}
{X}
{node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
letter used as separator.
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
was:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query with format
\{node_order_id}{X}\{node_qry_cntr}, both node_order_id and node_qry_cntr
encoded to HEX. X - X letter used as separator.
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format \{node_order_id}
> {X}
> {node_qry_cntr}, both node_order_id and node_qry_cntr encoded to HEX. X - 'X'
> letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10347:
---
Description:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query with format
\{node_order_id}{X}\{node_qry_cntr}, both node_order_id and node_qry_cntr
encoded to HEX. X - X letter used as separator.
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
was:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query with format
\{node_order_id}X\{node_qry_cntr}, both node_order_id and node_qry_cntr encoded
to HEX.
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format
> \{node_order_id}{X}\{node_qry_cntr}, both node_order_id and node_qry_cntr
> encoded to HEX. X - X letter used as separator.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10347) Expose system SQL view for running queries
[
https://issues.apache.org/jira/browse/IGNITE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-10347:
---
Description:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query with format
\{node_order_id}X\{node_qry_cntr}, both node_order_id and node_qry_cntr encoded
to HEX.
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
was:
Need to expose system SQL view to provide list of running queries. Proposed
name is *running_queries* with following columns: query_id, node_id, sql,
schema_name, duration.
Where,
query_id - cluster unique id of query. (required clarification )
node_id - id of node where query was started
sql - sql command
schema_name - SQL schema name
duration - time in ms from start of execution of query
The view should contains all kind of running queries from RunningQueryManager
on local node
> Expose system SQL view for running queries
> --
>
> Key: IGNITE-10347
> URL: https://issues.apache.org/jira/browse/IGNITE-10347
> Project: Ignite
> Issue Type: Task
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, sql
>
> Need to expose system SQL view to provide list of running queries. Proposed
> name is *running_queries* with following columns: query_id, node_id, sql,
> schema_name, duration.
> Where,
> query_id - cluster unique id of query with format
> \{node_order_id}X\{node_qry_cntr}, both node_order_id and node_qry_cntr
> encoded to HEX.
> node_id - id of node where query was started
> sql - sql command
> schema_name - SQL schema name
> duration - time in ms from start of execution of query
>
> The view should contains all kind of running queries from RunningQueryManager
> on local node
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744875#comment-16744875
]
Pavel Kuznetsov edited comment on IGNITE-10784 at 1/17/19 10:30 AM:
[~vozerov], I've updated PR according your comments.
was (Author: pkouznet):
[~vozerov] Updated according your comments.
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744873#comment-16744873
]
Pavel Kuznetsov commented on IGNITE-10784:
--
Added test cases with filter that touches other columns. Also added simple
tests for drop/create and custom AffinityMapper.
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10965) Web console: in progress state for buttons
[ https://issues.apache.org/jira/browse/IGNITE-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10965: -- Description: *The problem:* Some actions triggered by user might take awhile, during which user can click on action button multiple times and, depending on internal details, cause unwanted side effects (like registering multiple users instead of one). *Solution:* Disable action button when action is running. Tell user to wait that something is happening. This can be integrated into special button state. Places new button state can be used in: - User registration. I'd rather prefer that new button state would: - Not affect button dimensions because sudden button size change might look uncanny. Overlays are OK, though. This probably rules out spinning indicator inline with button label. - Not hide original button label so.user always knows what's in progress. - Work for all button styles. Unique background for each button type is not OK, same background or overlay is OK. This will simplify the implementation. The requirements above are not set in stone, every point is open for discussion. [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. was: *The problem:* Some actions triggered by user might take awhile, during which user can click on action button multiple times and, depending on internal details, cause unwanted side effects (like registering multiple users instead of one). *Solution:* Disable action button when action is running. Tell user to wait that something is happening. This can be integrated into special button state. Places new button state can be used in: - User registration. I'd rather prefer that new button state would: - Not affect button dimensions because sudden button size change might look uncanny. Overlays are OK, though. This probably rules out spinning indicator inline with button label. - Not hide original button label so.user always knows what's in progress. - Work for all button styles. Unique background for each button type is not OK, same background or overlay is OK. This will simplify the implementation. The requirements above are not set in stone, every point is open for discussion. [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. > Web console: in progress state for buttons > -- > > Key: IGNITE-10965 > URL: https://issues.apache.org/jira/browse/IGNITE-10965 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vica Abramova >Priority: Minor > Original Estimate: 8h > Remaining Estimate: 8h > > *The problem:* > Some actions triggered by user might take awhile, during which user can > click on action button multiple times and, depending on internal details, > cause unwanted side effects (like registering multiple users instead of one). > *Solution:* > Disable action button when action is running. Tell user to wait that > something is happening. This can be integrated into special button state. > Places new button state can be used in: > - User registration. > I'd rather prefer that new button state would: > - Not affect button dimensions because sudden button size change might look > uncanny. Overlays are OK, though. This probably rules out spinning indicator > inline with button label. > - Not hide original button label so.user always knows what's in progress. > - Work for all button styles. Unique background for each button type is not > OK, same background or overlay is OK. This will simplify the implementation. > The requirements above are not set in stone, every point is open for > discussion. > [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10965) Web console: in progress state for buttons
[ https://issues.apache.org/jira/browse/IGNITE-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10965: -- Description: *The problem:* Some actions triggered by user might take awhile, during which user can click on action button multiple times and, depending on internal details, cause unwanted side effects (like registering multiple users instead of one). *Solution:* Disable action button when action is running. Tell user to wait that something is happening. This can be integrated into special button state. Places new button state can be used in: - User registration. I'd rather prefer that new button state would: - Not affect button dimensions because sudden button size change might look uncanny. Overlays are OK, though. This probably rules out spinning indicator inline with button label. - Not hide original button label so.user always knows what's in progress. - Work for all button styles. Unique background for each button type is not OK, same background or overlay is OK. This will simplify the implementation. The requirements above are not set in stone, every point is open for discussion. [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. was: *The problem:* Some actions triggered by user might take awhile, during which user can click on action button multiple times and, depending on internal details, cause unwanted side effects (like registering multiple users instead of one). *Solution:* Disable action button when action is running. Tell user to wait that something is happening. This can be integrated into special button state. Places new button state can be used in: - User registration. I'd rather prefer that new button state would: - Not affect button dimensions because sudden button size change might look uncanny. Overlays are OK, though. This probably rules out spinning indicator inline with button label. - Not hide original button label so.user always knows what's in progress. - Work for all button styles. Unique background for each button type is not OK, same background or overlay is OK. This will simplify the implementation. The requirements above are not set in stone, every point is open for discussion. [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. > Web console: in progress state for buttons > -- > > Key: IGNITE-10965 > URL: https://issues.apache.org/jira/browse/IGNITE-10965 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Vica Abramova >Priority: Minor > Original Estimate: 8h > Remaining Estimate: 8h > > *The problem:* > Some actions triggered by user might take awhile, during which user can > click on action button multiple times and, depending on internal details, > cause unwanted side effects (like registering multiple users instead of one). > *Solution:* > Disable action button when action is running. Tell user to wait that > something is happening. This can be integrated into special button state. > Places new button state can be used in: > - User registration. > I'd rather prefer that new button state would: > - Not affect button dimensions because sudden button size change might look > uncanny. Overlays are OK, though. This probably rules out spinning indicator > inline with button label. > - Not hide original button label so.user always knows what's in progress. > - Work for all button styles. Unique background for each button type is not > OK, same background or overlay is OK. This will simplify the implementation. > The requirements above are not set in stone, every point is open for > discussion. > [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10965) Web console: in progress state for buttons
Ilya Borisov created IGNITE-10965: - Summary: Web console: in progress state for buttons Key: IGNITE-10965 URL: https://issues.apache.org/jira/browse/IGNITE-10965 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Vica Abramova *The problem:* Some actions triggered by user might take awhile, during which user can click on action button multiple times and, depending on internal details, cause unwanted side effects (like registering multiple users instead of one). *Solution:* Disable action button when action is running. Tell user to wait that something is happening. This can be integrated into special button state. Places new button state can be used in: - User registration. I'd rather prefer that new button state would: - Not affect button dimensions because sudden button size change might look uncanny. Overlays are OK, though. This probably rules out spinning indicator inline with button label. - Not hide original button label so.user always knows what's in progress. - Work for all button styles. Unique background for each button type is not OK, same background or overlay is OK. This will simplify the implementation. The requirements above are not set in stone, every point is open for discussion. [~vabramova] to provide design, [~Klaster_1] or [~alexdel] to implement. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744853#comment-16744853 ] Pavel Voronkin commented on IGNITE-10877: - Here is the result of optimization on : 8K partitions, 200 caches, 20 groups, 4 nodes Before: !image-2019-01-17-12-58-07-382.png! After: !image-2019-01-17-12-59-52-137.png! We see compaction upto 250times for backup collections. Moreover if backup less then 6 we won't allocate List> using viewReadOnly(ArrayList) to not allocate and keep objects. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10538) Web console: make ignite-grid component for handling missing agent and cluster
[ https://issues.apache.org/jira/browse/IGNITE-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-10538: -- Summary: Web console: make ignite-grid component for handling missing agent and cluster (was: Make ignite-grid component for handling missing agent and cluster) > Web console: make ignite-grid component for handling missing agent and cluster > -- > > Key: IGNITE-10538 > URL: https://issues.apache.org/jira/browse/IGNITE-10538 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexander Kalinin >Priority: Major > > Currently we have such an aproach: When agent or cluster is not availibe we > block the whole screen and show a modal window with instructions (like in > Notebooks screen). This approach is a bad UX case as it frustrates user with > blocking and forcing to change state. > We should implement a less obtrusive aproach by showing message in body of > ignite-grid table, allowing user to stay on current state and not blocking > the whole UI. > This component should comply for following requirements: > 1) It sholuld be universal - applicable in context of any ignite-grid table > usage. > 2) Should handle common cases like missing agent or cluster under the hood. > 3) Should have a possibility of enhancing for other special cases in > different components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10964) SQL: Concurrent dml and alter table
[
https://issues.apache.org/jira/browse/IGNITE-10964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744848#comment-16744848
]
Vladimir Ozerov commented on IGNITE-10964:
--
I would say that {{GridH2Table}} is more or less OK wrt concurrency at the
moment. Every column update leads to creation of new array. The only problem
there is that {{columns}} field is not volatile, meaning that potentially we
may have visibility problems. This is already addressed in IGNITE-10307.
Bigger problem is {{QueryTypeDescriptorImpl}} which is also updated during
{{ALTER TABLE}} command. It has a number of non-thread safe collections.
Provided that {{ALTER TABLE}} command is relatively rare, I would think about
copy-on-write approach here: get old descriptor, create a copy, update the
copy, install the copy.
> SQL: Concurrent dml and alter table
> ---
>
> Key: IGNITE-10964
> URL: https://issues.apache.org/jira/browse/IGNITE-10964
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> Our tests doesn't cover the case first user select or insert to table and
> another user alters the same table. There are some parts of {{GridH2Table}}
> that may cause data races in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10877: Attachment: image-2019-01-17-12-59-52-137.png > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png, image-2019-01-17-12-59-52-137.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Voronkin updated IGNITE-10877: Attachment: image-2019-01-17-12-58-07-382.png > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr, > image-2019-01-17-12-58-07-382.png > > Time Spent: 1.5h > Remaining Estimate: 0h > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10964) SQL: Concurrent dml and alter table
[
https://issues.apache.org/jira/browse/IGNITE-10964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-10964:
-
Issue Type: Test (was: Bug)
> SQL: Concurrent dml and alter table
> ---
>
> Key: IGNITE-10964
> URL: https://issues.apache.org/jira/browse/IGNITE-10964
> Project: Ignite
> Issue Type: Test
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> Our tests doesn't cover the case first user select or insert to table and
> another user alters the same table. There are some parts of {{GridH2Table}}
> that may cause data races in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10964) SQL: Concurrent dml and alter table
Pavel Kuznetsov created IGNITE-10964:
Summary: SQL: Concurrent dml and alter table
Key: IGNITE-10964
URL: https://issues.apache.org/jira/browse/IGNITE-10964
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Our tests doesn't cover the case first user select or insert to table and
another user alters the same table. There are some parts of {{GridH2Table}}
that may cause data races in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10538) Make ignite-grid component for handling missing agent and cluster
[ https://issues.apache.org/jira/browse/IGNITE-10538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744837#comment-16744837 ] Ilya Borisov commented on IGNITE-10538: --- [~alexdel] looks good enough. I'm not sure about coupling the component with AgentManager service versus passing state value though binding, but it doesn't matter much in the end. > Make ignite-grid component for handling missing agent and cluster > - > > Key: IGNITE-10538 > URL: https://issues.apache.org/jira/browse/IGNITE-10538 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Vasiliy Sisko >Assignee: Alexander Kalinin >Priority: Major > > Currently we have such an aproach: When agent or cluster is not availibe we > block the whole screen and show a modal window with instructions (like in > Notebooks screen). This approach is a bad UX case as it frustrates user with > blocking and forcing to change state. > We should implement a less obtrusive aproach by showing message in body of > ignite-grid table, allowing user to stay on current state and not blocking > the whole UI. > This component should comply for following requirements: > 1) It sholuld be universal - applicable in context of any ignite-grid table > usage. > 2) Should handle common cases like missing agent or cluster under the hood. > 3) Should have a possibility of enhancing for other special cases in > different components. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10138) Description is not provided for operations of org.apache.ignite.mxbean.TransactionMetricsMxBean
[
https://issues.apache.org/jira/browse/IGNITE-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744836#comment-16744836
]
Ignite TC Bot commented on IGNITE-10138:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2781990buildTypeId=IgniteTests24Java8_RunAll]
> Description is not provided for operations of
> org.apache.ignite.mxbean.TransactionMetricsMxBean
> ---
>
> Key: IGNITE-10138
> URL: https://issues.apache.org/jira/browse/IGNITE-10138
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Andrey Kalinin
>Priority: Minor
> Fix For: 2.5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Description mismatch for bean
> 'TransactionMetrics.TransactionMetricsMxBeanImpl'
> operation 'commitTime()': expected 'Last commit time.', actual 'Operation
> exposed for management'
> operation 'rollbackTime()': expected 'Last rollback time.', actual 'Operation
> exposed for management'
> operation 'txCommits()': expected 'Number of transaction commits.', actual
> 'Operation exposed for management'
> operation 'txRollbacks()': expected 'Number of transaction rollbacks.',
> actual 'Operation exposed for management'
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10590) IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky
[ https://issues.apache.org/jira/browse/IGNITE-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryabov Dmitrii updated IGNITE-10590: Description: Sometimes `expireTime` resets to 0 after node restart. [Test History|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4867852032903128088=testDetails_IgniteTests24Java8=]. was: Sometimes `expireTime` resets to 0 after node restart. https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4867852032903128088=testDetails_IgniteTests24Java8= > IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky > -- > > Key: IGNITE-10590 > URL: https://issues.apache.org/jira/browse/IGNITE-10590 > Project: Ignite > Issue Type: Task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Sometimes `expireTime` resets to 0 after node restart. > [Test > History|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4867852032903128088=testDetails_IgniteTests24Java8=]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10590) IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky
[ https://issues.apache.org/jira/browse/IGNITE-10590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744829#comment-16744829 ] Dmitriy Govorukhin commented on IGNITE-10590: - [~SomeFire] Looks good to me, thanks for the contribution! Merged to master. > IgnitePersistentStoreCacheGroupsTest.testExpiryPolicy is flaky > -- > > Key: IGNITE-10590 > URL: https://issues.apache.org/jira/browse/IGNITE-10590 > Project: Ignite > Issue Type: Task >Reporter: Ryabov Dmitrii >Assignee: Ryabov Dmitrii >Priority: Minor > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes `expireTime` resets to 0 after node restart. > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4867852032903128088=testDetails_IgniteTests24Java8= -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6259) GridServiceProcessor may leave futures hanging on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Daradur reassigned IGNITE-6259: -- Assignee: (was: Vyacheslav Daradur) > GridServiceProcessor may leave futures hanging on unstable topology > --- > > Key: IGNITE-6259 > URL: https://issues.apache.org/jira/browse/IGNITE-6259 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7, 1.8, 1.9, 2.0, 2.1 >Reporter: Denis Mekhanikov >Priority: Major > Fix For: 2.8 > > > GridServiceProcessor subscribes to updates on the internal cache to get > information about new deployments or cancellations of services. Some of such > updates may be lost under conditions of unstable topology. It leads to > services not being deployed and client futures infinitely hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10307) SQL: Extract partition info from JOINs
[
https://issues.apache.org/jira/browse/IGNITE-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744821#comment-16744821
]
Vladimir Ozerov commented on IGNITE-10307:
--
Tests are created, bugs fixed.
Re-run: https://ci.ignite.apache.org/viewQueued.html?itemId=2822993
> SQL: Extract partition info from JOINs
> --
>
> Key: IGNITE-10307
> URL: https://issues.apache.org/jira/browse/IGNITE-10307
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently we do not extract partitions when JOINs are involved. Let's
> implement it. We may start with relatively simple rules:
> # No subqueries
> # No GROUP BY
> Then walk through JOINed tables and extract partitions from AND clauses.
> There are some tricky things to consider:
> # Resulting model (tree) must be craefted carefully so that we can reuse it
> later in thin clients for efficient co-location.
> # Resulting model may affect how we group tables during push-down phase.
> Probably this would be huuuge thing, so may be it is better to implement it
> in separate ticket
> # When JOIN is performed partition info might be "transferred" between
> tables. E.g.:
> {code}
> a INNER JOIN b ON a.id = b.affinity_id WHERE a.id = :1
> {code}
> In this case if tables are co-located (we may infer it automatically in some
> cases), then {{a.id=:1}} partition rule can be "transferred" to
> {{b.affinity_id=:1}}.
> Very good test coverage would be needed here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744828#comment-16744828
]
Vladimir Ozerov commented on IGNITE-10754:
--
[~jooger],
Tests still do not work for me. When {{SqlQueryHistoryFromClientSelfTest}} is
executed, it fails with assertion that a node is not a client. Most probably
this is caused by use of {{startGridsMultithreaded}} instead of {{startGrids}}.
This needs to be fixed.
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10754) Query history statistics API
[ https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10754: - Fix Version/s: 2.8 > Query history statistics API > > > Key: IGNITE-10754 > URL: https://issues.apache.org/jira/browse/IGNITE-10754 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29, monitoring > Fix For: 2.8 > > Time Spent: 40m > Remaining Estimate: 0h > > As of now we have query statistics > (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. > 1) Duration execution it just time between start execution and return cursor > to client and doesn't include all life time of query. > 2) It doesn't know about multistatement queries. Such queries participate in > statistics as single query without splitting. > 3) API to access the statistics expose as depend on cache, however query > don't have such dependency. > > Need to create parallel similar realization as we already have. > Use new infrastructure of tracking running queries developed under > IGNITE-10621 and update statistics on unregister phase. > Expose API on upper level then it placed now. Right place will be written > later. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
