[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179314#comment-17179314
]
Alexand Polyakov commented on IGNITE-13175:
---
[^IGNITE-13175_add_test.patch] implementation test, add it to pull request
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_add_test.patch,
> IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13175:
--
Attachment: IGNITE-13175_add_test.patch
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_add_test.patch,
> IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13364) Improve index inline defaults
[ https://issues.apache.org/jira/browse/IGNITE-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13364: - Fix Version/s: 2.10 > Improve index inline defaults > -- > > Key: IGNITE-13364 > URL: https://issues.apache.org/jira/browse/IGNITE-13364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to improve how inline size is calculated by default for > variable-length types. > Currently if a varlength type is encountered inline size just defaults to 10, > which is almost always not enough. > A more sensible behavior would be the following: > 1. Add a fixed default to the inline size calculation for every > variable-length type. For example, if the default inlined size for a string > is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size > default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). > 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then > that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12922) SqlViewMetricExporterSpi is redundant entity
[
https://issues.apache.org/jira/browse/IGNITE-12922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179182#comment-17179182
]
Andrey N. Gura commented on IGNITE-12922:
-
[~nizhikov] This change is very similar to #8135 (or built on it). It still
doesn't solve described problem. Could you please look at my code review
comments to #8135? I address this issue in these comments.
> SqlViewMetricExporterSpi is redundant entity
> -
>
> Key: IGNITE-12922
> URL: https://issues.apache.org/jira/browse/IGNITE-12922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-35
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{SqlViewMetricExporterSpi}} is redundant entity both in terms of design and
> in terms of user experience.
> {{METRICS}} SQL view is the internal entity that could exist regardless of
> any exporters configuration. So it should be created on indexing module
> initialization. Also from an user stand point it is strange to configure
> special exporter in order to get access to the {{METRICS}} view via SQL.
> See also IGNITE-12921.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13328) Control.sh bash script swallow return code of CommandHandler and always return 0
[
https://issues.apache.org/jira/browse/IGNITE-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179174#comment-17179174
]
Ivan Daschinskiy commented on IGNITE-13328:
---
[~vveider] So what's wrong with my patch? Is any objection against merging it?
> Control.sh bash script swallow return code of CommandHandler and always
> return 0
>
>
> Key: IGNITE-13328
> URL: https://issues.apache.org/jira/browse/IGNITE-13328
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After merging
> [IGNITE-12367|https://issues.apache.org/jira/browse/IGNITE-12367],
> control.sh always return 0, despite the fact that CommandHandler returns
> correct code.
> For example:
> Ignite 2.8.1
> {code}
> Failed to execute baseline command='collect'
> Latest topology update failed.
> Connection to cluster failed. Latest topology update failed.
> Command [BASELINE] finished with code: 2
> Control utility has completed execution at: 2020-08-05T15:01:34.123
> Execution time: 26627 ms
> >>> echo $?
> 0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12921) System views design leads to bad user expirience.
[
https://issues.apache.org/jira/browse/IGNITE-12921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179172#comment-17179172
]
Andrey N. Gura commented on IGNITE-12921:
-
[~nizhikov] Thanks! Could you please take a look at my review comments?
> System views design leads to bad user expirience.
> -
>
> Key: IGNITE-12921
> URL: https://issues.apache.org/jira/browse/IGNITE-12921
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Andrey N. Gura
>Assignee: Nikolay Izhikov
>Priority: Critical
> Labels: IEP-35
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Current implementation of system views has broken system behavior which is
> related with querying system views.
> Before 2.8 system views were available via SQL queries (if indexing is
> enabled). It did not depend on any configuration.
> After implementation of IGNITE-12145 system views available only if
> {{SqlViewExporterSpi}} is passed to
> {{IgniteConfiguration.setSystemViewExporterSpi()}}. Now, if an user
> configures some {{SystemViewExporterSpi}} then provided user configuration
> will rewrite default configuration and {{SqlViewExporterSpi}} won't be
> initialized. As result it is impossible to query system views and any query
> to the views fails with exception. This behavior is not obvious for the user.
> See tests below.
> The second problem is kind of design problem. System view is internal part of
> the system and should be available regardless of any exporter configuration
> (at least via SQL) such as it was implemented before 2.8 release.
> My suggestion is the following: we should remove {{SqlViewExporterSpi}} and
> configure all views on indexing module initialization. {{SqlViewExporterSPI}}
> also doesn't make sense because:
> - it operates by some internal API ({{SchemaManager}}, {{GridKernalContext}},
> {{IgniteH2Indexing}}).
> - it doesn't allow to end user to add any new system view.
> Only thing that could be useful is a filtering. But it could be done with SQL.
> Reproducer of broken behavior:
> {code:java}
> package org.apache.ignite.internal.processors.cache.metric;
> import org.apache.ignite.cache.query.SqlFieldsQuery;
> import org.apache.ignite.cluster.ClusterState;
> import org.apache.ignite.configuration.DataRegionConfiguration;
> import org.apache.ignite.configuration.DataStorageConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.spi.systemview.jmx.JmxSystemViewExporterSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.junit.Test;
> import java.util.HashSet;
> import java.util.List;
> import java.util.Set;
> import static java.util.Arrays.asList;
> import static
> org.apache.ignite.internal.processors.cache.index.AbstractSchemaSelfTest.queryProcessor;
> public class SystemViewTest extends GridCommonAbstractTest {
> private static boolean useDefaultSpi;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDataRegionConfigurations(
> new
> DataRegionConfiguration().setName("in-memory").setMaxSize(100L * 1024 * 1024))
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> if (!useDefaultSpi) {
> // Configure user provided system view exporter SPI.
> cfg.setSystemViewExporterSpi(new JmxSystemViewExporterSpi());
> }
> return cfg;
> }
> /**
> * Will executed succefully.
> */
> @Test
> public void testSystemViewWithDefaultSpi() throws Exception {
> useDefaultSpi = true;
> doTestSystemView();
> }
> /**
> * Will fail with Table "VIEWS" not found.
> */
> @Test
> public void testSystemViewWithCustomSpi() throws Exception {
> useDefaultSpi = false;
> doTestSystemView();
> }
> private void doTestSystemView() throws Exception {
> try (IgniteEx ignite = startGrid()) {
> ignite.cluster().state(ClusterState.ACTIVE);
> Set cacheNames = new HashSet<>(asList("cache-1",
> "cache-2"));
> for (String name : cacheNames)
> ignite.getOrCreateCache(name);
> SqlFieldsQuery qry = new SqlFieldsQuery("SELECT * FROM
> SYS.VIEWS");
> List>
[jira] [Commented] (IGNITE-13253) Advanced heuristics for historical rebalance
[ https://issues.apache.org/jira/browse/IGNITE-13253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179132#comment-17179132 ] Ivan Rakov commented on IGNITE-13253: - Dev list discussion: http://apache-ignite-developers.2346864.n4.nabble.com/Choosing-historical-rebalance-heuristics-td48389.html#a48409 > Advanced heuristics for historical rebalance > > > Key: IGNITE-13253 > URL: https://issues.apache.org/jira/browse/IGNITE-13253 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Ivan Rakov >Priority: Major > > Before, cluster detects partitions that have not to rebalance by history, by > them size. This threshold might be set through a system property > IGNITE_PDS_WAL_REBALANCE_THRESHOLD. But it is not fair deciding which > partitions will be rebalanced by WAL only by them size. WAL can have much > more records than size of a partition (many update by one key) and that > rebalance required more data than full transferring by network. > Need to implement a heuristic, that might to estimate data size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13253) Advanced heuristics for historical rebalance
[ https://issues.apache.org/jira/browse/IGNITE-13253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Rakov reassigned IGNITE-13253: --- Assignee: Ivan Rakov > Advanced heuristics for historical rebalance > > > Key: IGNITE-13253 > URL: https://issues.apache.org/jira/browse/IGNITE-13253 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Ivan Rakov >Priority: Major > > Before, cluster detects partitions that have not to rebalance by history, by > them size. This threshold might be set through a system property > IGNITE_PDS_WAL_REBALANCE_THRESHOLD. But it is not fair deciding which > partitions will be rebalanced by WAL only by them size. WAL can have much > more records than size of a partition (many update by one key) and that > rebalance required more data than full transferring by network. > Need to implement a heuristic, that might to estimate data size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13354) Add ClusterMetrics to the new framework
[ https://issues.apache.org/jira/browse/IGNITE-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-13354: - Fix Version/s: 2.10 > Add ClusterMetrics to the new framework > --- > > Key: IGNITE-13354 > URL: https://issues.apache.org/jira/browse/IGNITE-13354 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > Fix For: 2.10 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > We need to provide to the user information about cluster topology such as: > * TopologyVersion > * TotalNodes > * TotalBaselineNodes > * TotalServerNodes > * TotalClientNodes > * ActiveBaselineNodes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13354) Add ClusterMetrics to the new framework
[
https://issues.apache.org/jira/browse/IGNITE-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179058#comment-17179058
]
Ignite TC Bot commented on IGNITE-13354:
{panel:title=Branch: [pull/8150/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8150/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=5545514buildTypeId=IgniteTests24Java8_RunAll]
> Add ClusterMetrics to the new framework
> ---
>
> Key: IGNITE-13354
> URL: https://issues.apache.org/jira/browse/IGNITE-13354
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-35
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> We need to provide to the user information about cluster topology such as:
> * TopologyVersion
> * TotalNodes
> * TotalBaselineNodes
> * TotalServerNodes
> * TotalClientNodes
> * ActiveBaselineNodes
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13349) Migrate TcpDiscoveryStatistics to new metrics framework
[ https://issues.apache.org/jira/browse/IGNITE-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179012#comment-17179012 ] Amelchev Nikita commented on IGNITE-13349: -- [~nizhikov], LGTM. > Migrate TcpDiscoveryStatistics to new metrics framework > --- > > Key: IGNITE-13349 > URL: https://issues.apache.org/jira/browse/IGNITE-13349 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.10 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > TcpDiscoveryStatistics should be migrated to the new metrics framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13366) Prohibit unconditional automatic deletion of data files if WAL was disabled prior to node's shutdown
Sergey Chugunov created IGNITE-13366: Summary: Prohibit unconditional automatic deletion of data files if WAL was disabled prior to node's shutdown Key: IGNITE-13366 URL: https://issues.apache.org/jira/browse/IGNITE-13366 Project: Ignite Issue Type: Task Components: persistence Affects Versions: 2.8.1 Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.10 If node with persistence is stopped when WAL was disabled for a cache (no matters because of rebalancing in progress or by explicit user request) on next node start all data files of that cache are removed automatically and unconditionally. This behavior may be unexpected for users as they may not understand all consequences of disabling WAL locally (for rebalancing) or globally (via IgniteCluster API call). Also it is not smart enough as there is no point in deleting consistent data files. We should change this behavior to the following list: no automatic deletions whatsoever. If data files are consistent (equivalent to: no checkpoint was running when node was stopped) start up normally. If data files are corrupted, don't let the node start. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13354) Add ClusterMetrics to the new framework
[ https://issues.apache.org/jira/browse/IGNITE-13354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178952#comment-17178952 ] Nikolay Izhikov commented on IGNITE-13354: -- LGTM > Add ClusterMetrics to the new framework > --- > > Key: IGNITE-13354 > URL: https://issues.apache.org/jira/browse/IGNITE-13354 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > Time Spent: 1.5h > Remaining Estimate: 0h > > We need to provide to the user information about cluster topology such as: > * TopologyVersion > * TotalNodes > * TotalBaselineNodes > * TotalServerNodes > * TotalClientNodes > * ActiveBaselineNodes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13365) GridCacheDatabaseSharedManager.releaseHistoryForExchange may throw AssertionError when WALMode.NONE is used.
Sergey Uttsel created IGNITE-13365:
--
Summary: GridCacheDatabaseSharedManager.releaseHistoryForExchange
may throw AssertionError when WALMode.NONE is used.
Key: IGNITE-13365
URL: https://issues.apache.org/jira/browse/IGNITE-13365
Project: Ignite
Issue Type: Bug
Reporter: Sergey Uttsel
Assignee: Sergey Uttsel
It seems that an attempt to release WAL segments needed for PME may lead to the
following AseertionError when WALMode.NONE is used.
{code:java}
[db-snapshot-msg-executor-#28857%database.IgniteDbSnapshotSameTopologyTestWalModeNone0%][root]
Created executor with [size=2, isFullyWrittenTrackingRequired=false] err)
Failed to notify listener:
o.a.i.i.processors.timeout.GridTimeoutProcessor$2...@72bbf7a7java.lang.AssertionError:
Earliest checkpoint WAL pointer is not reserved for exchange: FileWALPointer
[idx=0, fileOff=0, len=0] at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.releaseHistoryForExchange(GridCacheDatabaseSharedManager.java:1968)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2521)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4726)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1500(GridDhtPartitionsExchangeFuture.java:158)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$4.apply(GridDhtPartitionsExchangeFuture.java:4397)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$4.apply(GridDhtPartitionsExchangeFuture.java:4385)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:4385)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1997)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:458)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:445)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3848)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3827)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1722)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1329)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:158)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1214)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13183) Query timeout redesign
[
https://issues.apache.org/jira/browse/IGNITE-13183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178900#comment-17178900
]
Ignite TC Bot commented on IGNITE-13183:
{panel:title=Branch: [pull/8107/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8107/head] Base: [master] : New Tests
(80)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 2{color} [[tests
79|https://ci.ignite.apache.org/viewLog.html?buildId=5544872]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout5 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout4 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout3 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout2 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testExplicitTimeout1 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testConcurrent - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testNoExplicitTimeout3 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaTest.testNoExplicitTimeout2 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaUpdateTest.testExplicitTimeout1 - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testConcurrent - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
DefaultQueryTimeoutThickJavaLazyTest.testNoExplicitTimeout3 - PASSED{color}
... and 68 new tests
{color:#8b}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5544870]]
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcThinDefaultTimeoutTest.testDefaultTimeout - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5539122buildTypeId=IgniteTests24Java8_RunAll]
> Query timeout redesign
> --
>
> Key: IGNITE-13183
> URL: https://issues.apache.org/jira/browse/IGNITE-13183
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> Now the query timeout is set up for each node separately by the node
> configuration. This property isn't propagated for the all nodes of cluster.
> Also user cannot change / disable query timeout without restart all nodes of
> the cluster.
> *Proposal fix:*
> - Adds the default query timeout property to the
> {{DistributedSqlConfiguration}}. Use distributed metastore to store and
> manage the property.
> - Deprecates the {{SqlConfiguration#defaultQueryTimeout}} property and use it
> to set up initial value of new property
> {{DistributedSqlConfiguration#defaultQueryTimeout}}
> - Adds info about explicit query timeout to {{GridH2QueryRequest}} (boolean
> flag {{explicitTimeout=false}} by default). This is necessary so that the
> default timeout may be used for queries from old nodes.
> - When query timeout is set to zero by old node ({{explicitTimeout=false}})
> we assume this is the default value and use default timeout for this queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13349) Migrate TcpDiscoveryStatistics to new metrics framework
[ https://issues.apache.org/jira/browse/IGNITE-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178891#comment-17178891 ] Stepachev Maksim commented on IGNITE-13349: --- [~nizhikov] Hi. I don't read a mail list about this feature. It looks fine for me. I added comments into PR, please check them and feel free to merge. > Migrate TcpDiscoveryStatistics to new metrics framework > --- > > Key: IGNITE-13349 > URL: https://issues.apache.org/jira/browse/IGNITE-13349 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > TcpDiscoveryStatistics should be migrated to the new metrics framework. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13345) Warming up strategy
[
https://issues.apache.org/jira/browse/IGNITE-13345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178870#comment-17178870
]
Ignite TC Bot commented on IGNITE-13345:
{panel:title=Branch: [pull/8148/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8148/head] Base: [master] : New Tests
(18)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}MVCC PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=5544748]]
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean
- PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testExecutionStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsMvccTestSuite4:
LoadAllWarmUpSelfTest.testMemoryLessPds - PASSED{color}
{color:#8b}PDS 4{color} [[tests
9|https://ci.ignite.apache.org/viewLog.html?buildId=5544746]]
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testSimple -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: LoadAllWarmUpSelfTest.testMemoryLessPds -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testNonPersistentDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDataRegionWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testUnknownDefaultWarmUpConfiguration - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testExecutionStrategies -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
WarmUpSelfTest.testAvailableWarmUpStrategies - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUp -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4: WarmUpSelfTest.testStopWarmUpByMXBean -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5538575buildTypeId=IgniteTests24Java8_RunAll]
> Warming up strategy
> ---
>
> Key: IGNITE-13345
> URL: https://issues.apache.org/jira/browse/IGNITE-13345
> Project: Ignite
> Issue Type: New Feature
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: IEP-40
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Summary of
> [Dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Cache-warmup-td48582.html]
> # Adding a marker interface
> *org.apache.ignite.configuration.WarmUpConfiguration*;
> # Adding a configuration to
> ##
> *org.apache.ignite.configuration.DataRegionConfiguration#setWarmUpConfiguration*
> ##
> *org.apache.ignite.configuration.DataStorageConfiguration#setDefaultWarmUpConfiguration*
> # Add an internal warm-up interface that will start in [1] after [2] (after
> recovery);
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
> import org.apache.ignite.IgniteCheckedException;
> import org.apache.ignite.configuration.WarmUpConfiguration;
> import org.apache.ignite.internal.GridKernalContext;
> import org.apache.ignite.internal.processors.cache.persistence.DataRegion;
> /**
> * Interface for warming up.
> */
> public interface WarmUpStrategy {
> /**
> * Returns configuration class for mapping to strategy.
> *
> * @return Configuration class.
> */
> Class configClass();
> /**
> * Warm up.
> *
> * @param kernalCtx Kernal context.
> * @param cfg Warm-up configuration.
> * @param regionData region.
> * @throws IgniteCheckedException if faild.
> */
> void warmUp(GridKernalContext kernalCtx, T cfg, DataRegion region) throws
> IgniteCheckedException;
> /**
> * Closing warm up.
> *
> * @throws IgniteCheckedException if faild.
> */
> void close() throws IgniteCheckedException;
> }
> {code}
> # Adding an internal plugin extension for add own strategies;
> {code:java}
> package org.apache.ignite.internal.processors.cache.warmup;
>
> import java.util.Collection;
> import org.apache.ignite.plugin.Extension;
>
> /**
> * Interface for getting warm-up strategies from plugins.
> */
> public
[jira] [Commented] (IGNITE-13327) Add a metric for processed keys when rebuilding indexes.
[ https://issues.apache.org/jira/browse/IGNITE-13327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178849#comment-17178849 ] Kirill Tkalenko commented on IGNITE-13327: -- [~ivan.glukos] I made changes to PR on your comments, please make a review, I think [1] will be sufficient for visa. [1] - https://ci.ignite.apache.org/viewLog.html?buildId=5544749=queuedBuildOverviewTab > Add a metric for processed keys when rebuilding indexes. > > > Key: IGNITE-13327 > URL: https://issues.apache.org/jira/browse/IGNITE-13327 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > It would be useful to understand how long it will take to rebuild indexes, > since there can be a lot of data and indexes. Now there are following metrics > that allow to estimate approximately how many indexes are left to rebuild: > # IsIndexRebuildInProgress - rebuilding cache indexes in the process; > # IndexBuildCountPartitionsLeft - remaining number of partitions (by cache > group) to rebuild indexes for. > For a more accurate estimate, I suggest adding a metric for caches "Number of > keys processed when rebuilding indexes" with the name > "IndexRebuildKeyProcessed". This way we can estimate for cache how much index > rebuilding will take. To do this, we can get "CacheSize" and use new metric > to find out how many keys are left to process. > I also suggest adding methods: > # org.apache.ignite.cache.CacheMetrics#getIndexRebuildKeyProcessed > # org.apache.ignite.cache.CacheMetrics#IsIndexRebuildInProgress -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17178825#comment-17178825
]
Kirill Tkalenko commented on IGNITE-13280:
--
[~tledkov-gridgain] Please make code review.
> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR,
> ADDRESS VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous to use "idx2" here, because first index field LANG not
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13364) Improve index inline defaults
[ https://issues.apache.org/jira/browse/IGNITE-13364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13364: - Component/s: sql > Improve index inline defaults > -- > > Key: IGNITE-13364 > URL: https://issues.apache.org/jira/browse/IGNITE-13364 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > > We need to improve how inline size is calculated by default for > variable-length types. > Currently if a varlength type is encountered inline size just defaults to 10, > which is almost always not enough. > A more sensible behavior would be the following: > 1. Add a fixed default to the inline size calculation for every > variable-length type. For example, if the default inlined size for a string > is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size > default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). > 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then > that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13364) Improve index inline defaults
Evgeniy Rudenko created IGNITE-13364: Summary: Improve index inline defaults Key: IGNITE-13364 URL: https://issues.apache.org/jira/browse/IGNITE-13364 Project: Ignite Issue Type: Improvement Reporter: Evgeniy Rudenko Assignee: Evgeniy Rudenko We need to improve how inline size is calculated by default for variable-length types. Currently if a varlength type is encountered inline size just defaults to 10, which is almost always not enough. A more sensible behavior would be the following: 1. Add a fixed default to the inline size calculation for every variable-length type. For example, if the default inlined size for a string is 10 then an index like (INT, VARCHAR, VARCHAR, INT) should have inline size default as 5 + 10 + 10 + 5 = 30 (5 for each int, 10 for each string). 2. Add special support for VARCHAR_FIXED - if a VARCHAR has known length then that length is used for inline size calculation -- This message was sent by Atlassian Jira (v8.3.4#803005)
