[jira] [Commented] (IGNITE-13402) [Suite] PDS 3 flaky failed on TC
[
https://issues.apache.org/jira/browse/IGNITE-13402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191874#comment-17191874
]
Vyacheslav Koptilin commented on IGNITE-13402:
--
Hello [~v.pyatkov],
The fix looks good to me, merged to master. Thank you for your efforts!
> [Suite] PDS 3 flaky failed on TC
>
>
> Key: IGNITE-13402
> URL: https://issues.apache.org/jira/browse/IGNITE-13402
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: Invalid topology version
> [topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], group=Group1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.readyTopologyVersion(GridDhtPartitionTopologyImpl.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.nextVersion(GridCacheAdapter.java:3663)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2747)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1090)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> [2020-07-28 06:36:24,540][INFO
> ][exchange-worker-#38244%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][FileWriteAheadLogManager]
> Resuming logging to WAL segment
> [file=/opt/buildagent/work/bde9b45ddb020b34/incubator-ignite/work/db/wal/persistence_IgnitePdsContinuousRestartTestWithExpiryPolicy2/.wal,
> offset=3573451, ver=2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> [2020-07-28
> 06:36:24,544][ERROR][ttl-cleanup-worker-#38230%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][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=class o.a.i.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:168)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:152)
> at java.lang.Thread.run(Thread.java:748)
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13390) CLI (control.sh) "get_master_key_name" command should display the current master key name.
[
https://issues.apache.org/jira/browse/IGNITE-13390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13390:
-
Labels: IEP-18 (was: )
> CLI (control.sh) "get_master_key_name" command should display the current
> master key name.
> --
>
> Key: IGNITE-13390
> URL: https://issues.apache.org/jira/browse/IGNITE-13390
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.9
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: IEP-18
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CLI (control.sh) "get_master_key_name" command should display current master
> key name.
> Current output is the following:
> {noformat}
> Control utility [ver. 2.10.0-SNAPSHOT#20200826-sha1:3693e413]
> 2020 Copyright(C) Apache Software Foundation
> User: xtern
> Time: 2020-08-28T16:06:04.264
> Command [ENCRYPTION] started
> Arguments: --encryption get_master_key_name --yes
>
> Command [ENCRYPTION] finished with code: 0
> Control utility has completed execution at: 2020-08-28T16:06:04.328
> Execution time: 64 ms{noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13402) [Suite] PDS 3 flaky failed on TC
[
https://issues.apache.org/jira/browse/IGNITE-13402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13402:
-
Fix Version/s: 2.10
> [Suite] PDS 3 flaky failed on TC
>
>
> Key: IGNITE-13402
> URL: https://issues.apache.org/jira/browse/IGNITE-13402
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: Invalid topology version
> [topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], group=Group1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.readyTopologyVersion(GridDhtPartitionTopologyImpl.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.nextVersion(GridCacheAdapter.java:3663)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2747)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1090)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> [2020-07-28 06:36:24,540][INFO
> ][exchange-worker-#38244%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][FileWriteAheadLogManager]
> Resuming logging to WAL segment
> [file=/opt/buildagent/work/bde9b45ddb020b34/incubator-ignite/work/db/wal/persistence_IgnitePdsContinuousRestartTestWithExpiryPolicy2/.wal,
> offset=3573451, ver=2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> [2020-07-28
> 06:36:24,544][ERROR][ttl-cleanup-worker-#38230%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][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=class o.a.i.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:168)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:152)
> at java.lang.Thread.run(Thread.java:748)
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13402) [Suite] PDS 3 flaky failed on TC
[
https://issues.apache.org/jira/browse/IGNITE-13402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13402:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> [Suite] PDS 3 flaky failed on TC
>
>
> Key: IGNITE-13402
> URL: https://issues.apache.org/jira/browse/IGNITE-13402
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: Invalid topology version
> [topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], group=Group1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.readyTopologyVersion(GridDhtPartitionTopologyImpl.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.nextVersion(GridCacheAdapter.java:3663)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2747)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1090)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> [2020-07-28 06:36:24,540][INFO
> ][exchange-worker-#38244%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][FileWriteAheadLogManager]
> Resuming logging to WAL segment
> [file=/opt/buildagent/work/bde9b45ddb020b34/incubator-ignite/work/db/wal/persistence_IgnitePdsContinuousRestartTestWithExpiryPolicy2/.wal,
> offset=3573451, ver=2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> [2020-07-28
> 06:36:24,544][ERROR][ttl-cleanup-worker-#38230%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][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=class o.a.i.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:168)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:152)
> at java.lang.Thread.run(Thread.java:748)
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13409) System view for metastorage items
[ https://issues.apache.org/jira/browse/IGNITE-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-13409: Assignee: Nikolay Izhikov > System view for metastorage items > - > > Key: IGNITE-13409 > URL: https://issues.apache.org/jira/browse/IGNITE-13409 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > We need to provide a System view to show metastorage and distributed > metastorage properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13412) Publish nightly snapshot in apache repository
Saikat Maitra created IGNITE-13412: -- Summary: Publish nightly snapshot in apache repository Key: IGNITE-13412 URL: https://issues.apache.org/jira/browse/IGNITE-13412 Project: Ignite Issue Type: Improvement Components: streaming Reporter: Saikat Maitra We used to publish nightly packages earlier in the apache snapshot repository but we are no longer publishing the packages. [https://repository.apache.org/content/repositories/snapshots/org/apache/ignite/ignite-core/] The last published package was [2.2.2-SNAPSHOT/|https://repository.apache.org/content/repositories/snapshots/org/apache/ignite/ignite-core/2.2.2-SNAPSHOT/] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191792#comment-17191792 ] Tanmay Ambre commented on IGNITE-13270: --- [~zstan] - we dont have distributed joins. the query I provided uses the affinity key to join - hence i think the joins will be collocated. also regarding passing integers to query statements. we dont do that. Our input is a text string. Hope this helps. I was not able to understand your comment completely. Hence unable to answer in detail. > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java, IgniteSqlDistributedJoinSelfTest.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12364) Migrate JMS module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191778#comment-17191778 ] Saikat Maitra commented on IGNITE-12364: [~ilyak] Thank you for sharing the feedback. I will update the below files jms11 exclusion from assembly/dependencies-apache-ignite-slim.xml modules/osgi-karaf/src/main/resources/features.xml to use ignite-ext > Migrate JMS module to ignite-extensions > --- > > Key: IGNITE-12364 > URL: https://issues.apache.org/jira/browse/IGNITE-12364 > Project: Ignite > Issue Type: Sub-task > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Migrate JMS module to ignite-extensions > [https://github.com/apache/ignite-extensions] > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13388) apache-ignite deb package depends on a non-existent package and can't be installed on Debian 10
[
https://issues.apache.org/jira/browse/IGNITE-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13388:
-
Ignite Flags: (was: Release Notes Required)
> apache-ignite deb package depends on a non-existent package and can't be
> installed on Debian 10
> ---
>
> Key: IGNITE-13388
> URL: https://issues.apache.org/jira/browse/IGNITE-13388
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Artem Budnikov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The apache-ignite deb package v. 2.8.1 depends on 'openjdk-8-jdk', which is
> only available in Debian stretch and isn't available in later Debian
> distributions. An attempt to install the package gives this error:
> {code:java}
> $ sudo apt-get install apache-ignite=2.8.1-1
> ...
> The following packages have unmet dependencies:
> apache-ignite : Depends: openjdk-8-jdk but it is not installable or
> oracle-java8-installer but it is not installable
> E: Unable to correct problems, you have held broken packages{code}
> Package information:
> {code:java}
> $ apt-cache show apache-ignite=2.8.1-1
> Package: apache-ignite
> Version: 2.8.1-1
> Architecture: all
> Maintainer: Petr Ivanov
> Installed-Size: 572071
> Depends: openjdk-8-jdk | oracle-java8-installer, systemd, passwd
> Section: misc
> Priority: optional
> Homepage: https://ignite.apache.org
> Description: Apache Ignite In-Memory Computing, Database and Caching Platform
> Ignite™ is a memory-centric distributed database, caching, and processing
> platform for transactional, analytical, and streaming workloads, delivering
> in-memory speeds at petabyte scale
> Description-md5: 6a59db03fa1e142387abef6ef6bb0d83
> Filename: pool/main/a/apache-ignite_2.8.1-1_all.deb
> SHA1: 67d197a5e582f6ea7c66da26a755f937f8e16fc9
> SHA256: fc9a274ecb82716905d4120a715e9c74441dfed67831874eb3c35c4953bfc90d
> Size: 399746094
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13411) Optimize tracing when NoopTracingSpi is used
[
https://issues.apache.org/jira/browse/IGNITE-13411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191769#comment-17191769
]
Aleksey Plekhanov commented on IGNITE-13411:
[~alapin], [~ivan.glukos], can you please have a look at PRs?
https://github.com/apache/ignite/pull/8223 - to Ignite 2.9
https://github.com/apache/ignite/pull/8224 - to master
> Optimize tracing when NoopTracingSpi is used
>
>
> Key: IGNITE-13411
> URL: https://issues.apache.org/jira/browse/IGNITE-13411
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current tracing implementation has some redundant actions for no-op tracing
> SPI which have a negative impact on performance:
> # {{GridNioTracerFilter}} added to communication SPI filters chain even if
> tracing is disabled.
> # {{MTC.support}}/{{MTC.supportContinual}} methods in case of no-op span or
> null span return {{TracingSurrounding}} which equivalently does nothing
> ({{span.set(oldSpan)}} is redundant, since {{span.set(startSpan)}} was
> skipped for no-op or null span, and {{endRequired}} is always {{false}}. So,
> instead of creating new {{TracingSurrounding}} we can return {{null}}
> (correctly processed by try-with resource block) with the same effect and get
> rid of some code on the hot path.
> # Sometimes we already have {{Span}} on hands and call to {{MTC.span()}} is
> redundant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13411) Optimize tracing when NoopTracingSpi is used
Aleksey Plekhanov created IGNITE-13411:
--
Summary: Optimize tracing when NoopTracingSpi is used
Key: IGNITE-13411
URL: https://issues.apache.org/jira/browse/IGNITE-13411
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Current tracing implementation has some redundant actions for no-op tracing SPI
which have a negative impact on performance:
# {{GridNioTracerFilter}} added to communication SPI filters chain even if
tracing is disabled.
# {{MTC.support}}/{{MTC.supportContinual}} methods in case of no-op span or
null span return {{TracingSurrounding}} which equivalently does nothing
({{span.set(oldSpan)}} is redundant, since {{span.set(startSpan)}} was skipped
for no-op or null span, and {{endRequired}} is always {{false}}. So, instead of
creating new {{TracingSurrounding}} we can return {{null}} (correctly processed
by try-with resource block) with the same effect and get rid of some code on
the hot path.
# Sometimes we already have {{Span}} on hands and call to {{MTC.span()}} is
redundant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12364) Migrate JMS module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191725#comment-17191725 ] Ilya Kasnacheev commented on IGNITE-12364: -- Please also remove jms11 exclusion from assembly/dependencies-apache-ignite-slim.xml Please update all features in modules/osgi-karaf/src/main/resources/features.xml to use ignite-ext > Migrate JMS module to ignite-extensions > --- > > Key: IGNITE-12364 > URL: https://issues.apache.org/jira/browse/IGNITE-12364 > Project: Ignite > Issue Type: Sub-task > Components: streaming >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Migrate JMS module to ignite-extensions > [https://github.com/apache/ignite-extensions] > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13410) .NET: Run Services tests with different service processors
Pavel Tupitsyn created IGNITE-13410: --- Summary: .NET: Run Services tests with different service processors Key: IGNITE-13410 URL: https://issues.apache.org/jira/browse/IGNITE-13410 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 We have two service processors - legacy and a new event-driven one. Ignite system property IGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED specifies the one to use. Make sure thick and thin service tests execute in both modes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13329) Use checkstyle from command line check on validate phase
[ https://issues.apache.org/jira/browse/IGNITE-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191681#comment-17191681 ] Maxim Muzafarov commented on IGNITE-13329: -- Merged to the master branch, thank you for the review. > Use checkstyle from command line check on validate phase > > > Key: IGNITE-13329 > URL: https://issues.apache.org/jira/browse/IGNITE-13329 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: checkstyle > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, the checkstyle plugin configured to run on the `compile` maven > phase due to the custom OverrideAnnotationOnTheSameLineCheck check must be > compiled. However, it will be faster to run checkstyle on `validate` maven > phase check all the configured rules locally prior to pushing by running the > `mvn checkstyle:check` command. > [https://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13329) Use checkstyle from command line check on validate phase
[
https://issues.apache.org/jira/browse/IGNITE-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191678#comment-17191678
]
Ignite TC Bot commented on IGNITE-13329:
{panel:title=Branch: [pull/8120/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8120/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5584516&buildTypeId=IgniteTests24Java8_RunAll]
> Use checkstyle from command line check on validate phase
>
>
> Key: IGNITE-13329
> URL: https://issues.apache.org/jira/browse/IGNITE-13329
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: checkstyle
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the checkstyle plugin configured to run on the `compile` maven
> phase due to the custom OverrideAnnotationOnTheSameLineCheck check must be
> compiled. However, it will be faster to run checkstyle on `validate` maven
> phase check all the configured rules locally prior to pushing by running the
> `mvn checkstyle:check` command.
> [https://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13358) Improvements for partition clearing related parts
[ https://issues.apache.org/jira/browse/IGNITE-13358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191616#comment-17191616 ] Alexey Goncharuk commented on IGNITE-13358: --- [~ascherbakov], I've left some comments in the PR, please take a look. > Improvements for partition clearing related parts > - > > Key: IGNITE-13358 > URL: https://issues.apache.org/jira/browse/IGNITE-13358 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > We have several issues related to a partition clearing worth fixing. > 1. PartitionsEvictManager doent's provide obvious guarantees for a > correctness when a node or a cache group is stopped while partitions are > concurrently clearing. > 2. GridDhtLocalPartition#awaitDestroy is called while holding topology write > lock, which is deadlock prone, because we currently require write lock to > destroy a partition. > 3. GridDhtLocalPartition contains a lot of messy code related to partition > clearing, most notably ClearFuture, but the clearing is done by > PartitionsEvictManager. We should get rid of a clearing code in > GridDhtLocalPartition. This should also bring better code readility and help > understand what happening during a clearing. > 4. Currently moving partitions are cleared before rebalancing in the order > different to rebalanceOrder, breaking the contract. Better to submit such > partitions for clearing to the rebalancing pool before each group starts to > rebalance. This will allow faster rebalancing (accoring to configured > rebalance pool size) and will provide rebalanceOrder guarantees. > 5. The clearing logic for for moving partitions (before rebalancing) seems > incorrect: it's possible to lost updates received during clearing. > 6. To clear partitions before full rebalancing we utilize same threads as for > a partition eviction. This can slow rebalancing even if we have resources. > Better to clear partitions in the rebalance pool (explicitely dedicated by > user). > 7. It's possible to reserve a renting partition, which have absolutely no > meaning. All operations with a renting partitions (except clearing) are a > waste of resources. > 8. Partition eviction causes system pool tasks starvation if a number of > threads in system pool=1. This can break crucial functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13409) System view for metastorage items
[ https://issues.apache.org/jira/browse/IGNITE-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-13409: - Description: We need to provide a System view to show metastorage and distributed metastorage properties. was: We need to provide a System view to show metastorage and distributed metastorage items. > System view for metastorage items > - > > Key: IGNITE-13409 > URL: https://issues.apache.org/jira/browse/IGNITE-13409 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > We need to provide a System view to show metastorage and distributed > metastorage properties. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13409) System view for metastorage items
[
https://issues.apache.org/jira/browse/IGNITE-13409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-13409:
-
Description:
We need to provide a System view to show metastorage and distributed
metastorage items.
was:
Currently, list of binary metadata available via experimental {{control.sh}}
command.
We need to provide a corresponding System view for this information.
> System view for metastorage items
> -
>
> Key: IGNITE-13409
> URL: https://issues.apache.org/jira/browse/IGNITE-13409
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
>
> We need to provide a System view to show metastorage and distributed
> metastorage items.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13408) System view for binary metadata
Nikolay Izhikov created IGNITE-13408:
Summary: System view for binary metadata
Key: IGNITE-13408
URL: https://issues.apache.org/jira/browse/IGNITE-13408
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Currently, list of binary metadata available via experimental {{control.sh}}
command.
We need to provide a corresponding System view for this information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13409) System view for metastorage items
Nikolay Izhikov created IGNITE-13409:
Summary: System view for metastorage items
Key: IGNITE-13409
URL: https://issues.apache.org/jira/browse/IGNITE-13409
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Currently, list of binary metadata available via experimental {{control.sh}}
command.
We need to provide a corresponding System view for this information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13377) WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator is flaky
[ https://issues.apache.org/jira/browse/IGNITE-13377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191561#comment-17191561 ] Alexey Scherbakov commented on IGNITE-13377: [~v.pyatkov] LGTM. Merged to master #943dfa961b9e143f1848700b041ddd5dd396688b. > WalModeChangeAdvancedSelfTest.testServerRestartNonCoordinator is flaky > --- > > Key: IGNITE-13377 > URL: https://issues.apache.org/jira/browse/IGNITE-13377 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191550#comment-17191550 ] Alexey Scherbakov commented on IGNITE-13265: [~v.pyatkov] LGTM. Merged to master #d2ece7929a22ad4f1da3abf89036d0d9ff849dda. > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13397) NPE in logSupplierDone(UUID nodeId)
[
https://issues.apache.org/jira/browse/IGNITE-13397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191504#comment-17191504
]
Alexey Scherbakov commented on IGNITE-13397:
[~ktkale...@gridgain.com]
LGTM.
Merged to master #e76ed0340db5723f6089986892b823a0b06fa3f8
> NPE in logSupplierDone(UUID nodeId)
> ---
>
> Key: IGNITE-13397
> URL: https://issues.apache.org/jira/browse/IGNITE-13397
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> NPE in logSupplierDone(UUID nodeId)
> {noformat}
> [2020-08-30 18:06:52,360][ERROR][rebalance-#5033%new-version-node%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.logSupplierDone(GridDhtPartitionDemander.java:2009)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:1730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1200(GridDhtPartitionDemander.java:1142)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.ownPartition(GridDhtPartitionDemander.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:649)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleSupplyMessage$0(GridDhtPreloader.java:356)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
