[jira] [Assigned] (IGNITE-16511) Calcite engine. Move system properties constants to IgniteSystemProperties class
[
https://issues.apache.org/jira/browse/IGNITE-16511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16511:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Move system properties constants to IgniteSystemProperties
> class
> -
>
> Key: IGNITE-16511
> URL: https://issues.apache.org/jira/browse/IGNITE-16511
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a set of system properties constants for the Calcite-based SQL
> engine, which are placed in different classes and not documented:
> {noformat}
> IGNITE_CALCITE_EXEC_IN_BUFFER_SIZE
> IGNITE_CALCITE_EXEC_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_SIZE
> IGNITE_CALCITE_EXEC_IO_BATCH_CNT
> IGNITE_CALCITE_REL_JSON_PRETTY_PRINT{noformat}
> They should be moved to {{IgniteSystemProperties}} class with a proper
> {{@SystemProperty}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-11662) Wrong classloader is used to unmarshal joining node data
[
https://issues.apache.org/jira/browse/IGNITE-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-11662:
-
Release Note: Fixed an issue that led to failure to join a new node to the
cluster in the Karaf container.
> Wrong classloader is used to unmarshal joining node data
>
>
> Key: IGNITE-11662
> URL: https://issues.apache.org/jira/browse/IGNITE-11662
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When a cluster coordinator node is running in Karaf container it cannot
> accept joining requests from other nodes. Problem lies in unability to
> unmarshal joining node data in
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode()
> This line
> {code:java}
> joiningNodeState = marsh.unmarshal((byte[]) discoData.joiningNodeData(),
> Thread.currentThread().getContextClassLoader());{code}
> fails with
> {noformat}
> Error on unmarshalling discovery data from node
> 10.0.2.15,127.0.0.1,172.17.0.1:47501: Failed to find class with given class
> loader for unmarshalling (make sure same versions of all classes are
> available on all nodes or enable peer-class-loading)
> [clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@5c0369c4,
> cls=org.apache.ignite.internal.processors.cluster.DiscoveryDataClusterState];
> node is not allowed to join{noformat}
> Apparently problem is wrong classloader returned by
> {code:java}
> Thread.currentThread().getContextClassLoader()){code}
> which is not the one created in IgniteAbstractOsgiContextActivator.start().
> *Proposed fix:*
> use proper way of obtaining classloader:
> {code:java}
> U.resolveClassLoader(ctx.config()){code}
> Like in other places. i.e. in GridClusterStateProcessor.collectGridNodeData().
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (IGNITE-16525) Fix encrypted snapshots documentation.
[ https://issues.apache.org/jira/browse/IGNITE-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed IGNITE-16525. - > Fix encrypted snapshots documentation. > -- > > Key: IGNITE-16525 > URL: https://issues.apache.org/jira/browse/IGNITE-16525 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Cluster Snapshots doc section tells that "Encrypted caches are not included > in the snapshot.". Is not true any more. Also: "No option to encrypt/decrypt > existing caches/tables." in the TDE section. Moreover, TDE is not beta any > more. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16525) Fix encrypted snapshots documentation.
[ https://issues.apache.org/jira/browse/IGNITE-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-16525. --- Resolution: Duplicate Duplicate of IGNITE-15074 > Fix encrypted snapshots documentation. > -- > > Key: IGNITE-16525 > URL: https://issues.apache.org/jira/browse/IGNITE-16525 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Cluster Snapshots doc section tells that "Encrypted caches are not included > in the snapshot.". Is not true any more. Also: "No option to encrypt/decrypt > existing caches/tables." in the TDE section. Moreover, TDE is not beta any > more. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16525) Fix encrypted snapshots documentation.
[ https://issues.apache.org/jira/browse/IGNITE-16525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16525: -- Description: Cluster Snapshots doc section tells that "Encrypted caches are not included in the snapshot.". Is not true any more. Also: "No option to encrypt/decrypt existing caches/tables." in the TDE section. Moreover, TDE is not beta any more. > Fix encrypted snapshots documentation. > -- > > Key: IGNITE-16525 > URL: https://issues.apache.org/jira/browse/IGNITE-16525 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Cluster Snapshots doc section tells that "Encrypted caches are not included > in the snapshot.". Is not true any more. Also: "No option to encrypt/decrypt > existing caches/tables." in the TDE section. Moreover, TDE is not beta any > more. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16525) Fix encrypted snapshots documentation.
Vladimir Steshin created IGNITE-16525: - Summary: Fix encrypted snapshots documentation. Key: IGNITE-16525 URL: https://issues.apache.org/jira/browse/IGNITE-16525 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14269) Design conditional multi update functionality for meta storage client
[
https://issues.apache.org/jira/browse/IGNITE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490393#comment-17490393
]
Kirill Gusakov commented on IGNITE-14269:
-
After some discussions with [~agura] and [~ibessonov] we found out, that we
have no cases or any plans for the returning list of entries together with the
result. So, this requirement will be skipped in the current implementation.
> Design conditional multi update functionality for meta storage client
> -
>
> Key: IGNITE-14269
> URL: https://issues.apache.org/jira/browse/IGNITE-14269
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey N. Gura
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: iep-61, ignite-3
>
> Define entities required for implementation of conditional multi updates (aka
> "transactions") for meta storage.
> Requirements:
> - Design should provide possibility to define conditional updates in
> if-then-else manner with nested branches.
> - Update always starts with condition.
> - Any nested branch must start with condition.
> - Update can't precede to condition.
> - Every branch can yield exactly one custom result (limited by number of
> simple types) and any number of entries. Corresponding expression always must
> be at the end of branch.
> - Condition for entry revision allows the following comparisons: equal,
> !equal, less, greater.
> - Condition for entry value allows the following operations (byte-wise):
> equal, !equal.
> - Update allows the following operations: put, remove, no-op.
> - Condition can not use previously defined condition instance again because
> it will lead to graph cycle and infinite update execution.
> Assumptions:
> - It seems that conditions and updates entities can be conveniently linked
> using chaining.
> Simple example (pseudocode):
> {code}
> CompletableFuture> = invoke(valCond(EQUAL,
> perstEnabled, true)._then(
> valCond(EQUAL, walEnabled, true)._then(
> update(walEnabled, true)).
> _else(
> update(walEnabled, false))
> )._else(NoopUpdate))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16523) WALForceArchiveTimeout lead to node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16523:
-
Priority: Blocker (was: Major)
> WALForceArchiveTimeout lead to node fails to restart
>
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setWalMode(walMode)
> .setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
> auto archive will not work.
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Parameterized.Parameters(name = "walMode={0}")
> public static Collection parameters() {
> return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY,
> WALMode.BACKGROUND);
> }
> /** */
> @Test
> public void testRestart() throws Exception {
> stopAllGrids(true);
> cleanPersistenceDir();
> Supplier restart = () -> {
> stopAllGrids(true);
> try {
> IgniteEx ign = startGrid(getConfiguration("ignite-0"));
> ign.cluster().state(ACTIVE);
> return ign;
> }
> catch (Exception e) {
> throw new RuntimeException(e);
> }
> };
> IgniteEx ign = restart.get();
> IgniteCache cache =
> ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 0, 100);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 100, 200);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 200, 300);
> restart.get();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16523) WALForceArchiveTimeout lead to node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16523:
-
Summary: WALForceArchiveTimeout lead to node fails to restart (was: When )
> WALForceArchiveTimeout lead to node fails to restart
>
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setWalMode(walMode)
> .setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
> auto archive will not work.
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Parameterized.Parameters(name = "walMode={0}")
> public static Collection parameters() {
> return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY,
> WALMode.BACKGROUND);
> }
> /** */
> @Test
> public void testRestart() throws Exception {
> stopAllGrids(true);
> cleanPersistenceDir();
> Supplier restart = () -> {
> stopAllGrids(true);
> try {
> IgniteEx ign = startGrid(getConfiguration("ignite-0"));
> ign.cluster().state(ACTIVE);
> return ign;
> }
> catch (Exception e) {
> throw new RuntimeException(e);
> }
> };
> IgniteEx ign = restart.get();
> IgniteCache cache =
> ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 0, 100);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 100, 200);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 200, 300);
> restart.get();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16523) When
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16523:
-
Summary: When (was: CLONE - All data comited before node stop should
become available for CDC consumer)
> When
> -
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setWalMode(walMode)
> .setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
> auto archive will not work.
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Parameterized.Parameters(name = "walMode={0}")
> public static Collection parameters() {
> return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY,
> WALMode.BACKGROUND);
> }
> /** */
> @Test
> public void testRestart() throws Exception {
> stopAllGrids(true);
> cleanPersistenceDir();
> Supplier restart = () -> {
> stopAllGrids(true);
> try {
> IgniteEx ign = startGrid(getConfiguration("ignite-0"));
> ign.cluster().state(ACTIVE);
> return ign;
> }
> catch (Exception e) {
> throw new RuntimeException(e);
> }
> };
> IgniteEx ign = restart.get();
> IgniteCache cache =
> ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 0, 100);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 100, 200);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 200, 300);
> restart.get();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16523) CLONE - All data comited before node stop should become available for CDC consumer
Nikolay Izhikov created IGNITE-16523:
Summary: CLONE - All data comited before node stop should become
available for CDC consumer
Key: IGNITE-16523
URL: https://issues.apache.org/jira/browse/IGNITE-16523
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Ignite should make sure that all data committed before node stop are available
to CDC consumer in case graceful shutdown. Basically, this means Ignite should
execute the current WAL segment archivation on node stop.
Possible test to check it:
{code:java}
/** */
@Test
@Ignore("Not implemented yet")
public void testReadAfterNodeStop() throws Exception {
cleanPersistenceDir();
AtomicInteger cnt = new AtomicInteger();
TestCDCConsumer cnsmr = new TestCDCConsumer();
// Restart node several time to make sure we can continue after
gracefull shutdown.
for (int restarts = 0; restarts < 2; restarts++) {
IgniteConfiguration cfg = getConfiguration("ignite-0");
Ignite ign = startGrid(cfg);
ign.cluster().state(ACTIVE);
long startCnt = cnt.get();
runAsync(() -> {
IgniteCache cache =
ign.getOrCreateCache(DEFAULT_CACHE_NAME);
while (true) {
int key = cnt.getAndIncrement();
try {
cache.put(key, createUser(key));
}
catch (Exception e) {
cnt.decrementAndGet();
throw e;
}
}
});
waitForCondition(() -> cnt.get() - startCnt > KEYS_CNT,
getTestTimeout());
ign.close();
ChangeDataCapture cdc = new ChangeDataCapture(cfg, null,
cdcConfig(cnsmr));
IgniteInternalFuture fut = runAsync(cdc);
assertTrue(waitForSize(cnt.get(), DEFAULT_CACHE_NAME, UPDATE,
getTestTimeout(), cnsmr));
fut.cancel();
List keys = cnsmr.keys(UPDATE,
cacheId(DEFAULT_CACHE_NAME));
assertTrue(cnt.get() <= keys.size());
for (int i = 0; i < cnt.get(); i++)
assertTrue(keys.contains(i));
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16523) CLONE - All data comited before node stop should become available for CDC consumer
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16523:
-
Description:
When WALForceArchiveTimeout set node failed to restart.
{code:java}
/** */
@RunWith(Parameterized.class)
public class RestartWithWalForceArchiveTimeoutTest extends
GridCommonAbstractTest {
/** */
@Parameterized.Parameter
public WALMode walMode;
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setConsistentId(igniteInstanceName);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setWalMode(walMode)
.setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
auto archive will not work.
.setDefaultDataRegionConfiguration(new
DataRegionConfiguration().setPersistenceEnabled(true)));
return cfg;
}
/** */
@Parameterized.Parameters(name = "walMode={0}")
public static Collection parameters() {
return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY, WALMode.BACKGROUND);
}
/** */
@Test
public void testRestart() throws Exception {
stopAllGrids(true);
cleanPersistenceDir();
Supplier restart = () -> {
stopAllGrids(true);
try {
IgniteEx ign = startGrid(getConfiguration("ignite-0"));
ign.cluster().state(ACTIVE);
return ign;
}
catch (Exception e) {
throw new RuntimeException(e);
}
};
IgniteEx ign = restart.get();
IgniteCache cache =
ign.getOrCreateCache(DEFAULT_CACHE_NAME);
addData(cache, 0, 100);
ign = restart.get();
cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
addData(cache, 100, 200);
ign = restart.get();
cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
addData(cache, 200, 300);
restart.get();
}
}
{code}
was:
Ignite should make sure that all data committed before node stop are available
to CDC consumer in case graceful shutdown. Basically, this means Ignite should
execute the current WAL segment archivation on node stop.
Possible test to check it:
{code:java}
/** */
@Test
@Ignore("Not implemented yet")
public void testReadAfterNodeStop() throws Exception {
cleanPersistenceDir();
AtomicInteger cnt = new AtomicInteger();
TestCDCConsumer cnsmr = new TestCDCConsumer();
// Restart node several time to make sure we can continue after
gracefull shutdown.
for (int restarts = 0; restarts < 2; restarts++) {
IgniteConfiguration cfg = getConfiguration("ignite-0");
Ignite ign = startGrid(cfg);
ign.cluster().state(ACTIVE);
long startCnt = cnt.get();
runAsync(() -> {
IgniteCache cache =
ign.getOrCreateCache(DEFAULT_CACHE_NAME);
while (true) {
int key = cnt.getAndIncrement();
try {
cache.put(key, createUser(key));
}
catch (Exception e) {
cnt.decrementAndGet();
throw e;
}
}
});
waitForCondition(() -> cnt.get() - startCnt > KEYS_CNT,
getTestTimeout());
ign.close();
ChangeDataCapture cdc = new ChangeDataCapture(cfg, null,
cdcConfig(cnsmr));
IgniteInternalFuture fut = runAsync(cdc);
assertTrue(waitForSize(cnt.get(), DEFAULT_CACHE_NAME, UPDATE,
getTestTimeout(), cnsmr));
fut.cancel();
List keys = cnsmr.keys(UPDATE,
cacheId(DEFAULT_CACHE_NAME));
assertTrue(cnt.get() <= keys.size());
for (int i = 0; i < cnt.get(); i++)
assertTrue(keys.contains(i));
}
}
{code}
> CLONE - All data comited before node stop should become available for CDC
> consumer
> --
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override
[jira] [Updated] (IGNITE-16517) Fix documentation for the snapshot restore procedure on different topologyies
[ https://issues.apache.org/jira/browse/IGNITE-16517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16517: Labels: documentation (was: docuentation) > Fix documentation for the snapshot restore procedure on different topologyies > - > > Key: IGNITE-16517 > URL: https://issues.apache.org/jira/browse/IGNITE-16517 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: documentation > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ignite.apache.org/docs/latest/snapshots/snapshots#restoring-from-snapshot > The *Restore On Cluster of Different Topology* topic needs to be updated > father the IGNITE-14744 was merged. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16517) Fix documentation for the snapshot restore procedure on different topologyies
[ https://issues.apache.org/jira/browse/IGNITE-16517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-16517. - Reviewer: Maksim Timonin Resolution: Fixed > Fix documentation for the snapshot restore procedure on different topologyies > - > > Key: IGNITE-16517 > URL: https://issues.apache.org/jira/browse/IGNITE-16517 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: docuentation > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ignite.apache.org/docs/latest/snapshots/snapshots#restoring-from-snapshot > The *Restore On Cluster of Different Topology* topic needs to be updated > father the IGNITE-14744 was merged. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16517) Fix documentation for the snapshot restore procedure on different topologyies
[ https://issues.apache.org/jira/browse/IGNITE-16517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490364#comment-17490364 ] Maksim Timonin commented on IGNITE-16517: - Merged to master. Thanks [~mmuzaf] ! > Fix documentation for the snapshot restore procedure on different topologyies > - > > Key: IGNITE-16517 > URL: https://issues.apache.org/jira/browse/IGNITE-16517 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: docuentation > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ignite.apache.org/docs/latest/snapshots/snapshots#restoring-from-snapshot > The *Restore On Cluster of Different Topology* topic needs to be updated > father the IGNITE-14744 was merged. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490361#comment-17490361
]
Mirza Aliev commented on IGNITE-16502:
--
[~korlov] Thanks for the investigation! Should we unmute then
{{ItMixedQueriesTest}} that was disabled by the current ticket?
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
> Attachments: Full thread dump
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490345#comment-17490345
]
Konstantin Orlov commented on IGNITE-16502:
---
The issue was caused by deadlock in QueryPlanCache.
To deserialize the fragment, we need to get sure that current node is up to
date with a schema of the initiator node. To do this we start to wait till the
all required tables will be created locally. The problem here is we are holding
the lock for a bucket in CHM at this particular moment. When the node finishes
to handle distributed event, it fires a local event. The handler in the
SqlQueryProcessor listens for this local event, creates any necessary
structures, and then tries to clear the plan cache. But clearing a CHM requires
an acquiring a lock, so here we are.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16522) Improve usage of JDK marshaller in raft group listeners
Semyon Danilov created IGNITE-16522: --- Summary: Improve usage of JDK marshaller in raft group listeners Key: IGNITE-16522 URL: https://issues.apache.org/jira/browse/IGNITE-16522 Project: Ignite Issue Type: Improvement Reporter: Semyon Danilov Assignee: Semyon Danilov Fix For: 3.0.0-alpha5 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16387) Improve CDC logging and monitoring
[
https://issues.apache.org/jira/browse/IGNITE-16387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16387:
-
Fix Version/s: 2.13
> Improve CDC logging and monitoring
> --
>
> Key: IGNITE-16387
> URL: https://issues.apache.org/jira/browse/IGNITE-16387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, it's hard to debug and monitor CDC state and settings.
> We need to provide some additional logging and metrics.
> * Debug {{CacheVersionConflictResolverImpl}} implementation which will log
> all conflict resolution
> * Log {{clusterId}} value and creation of
> {{CacheVersionConflictResolverImpl}} with cache name.
> * Log {{clusterId}} value int {{GridCacheVersion#toString}}
> * Add {{conflictResolver}} value in {{CacheView}}.
> * Add {{clusterId}} metric.
> * etc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16292) Calcite. Unstable alterTableServerAndClient test.
[
https://issues.apache.org/jira/browse/IGNITE-16292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16292:
-
Assignee: (was: Vladimir Ermakov)
> Calcite. Unstable alterTableServerAndClient test.
> -
>
> Key: IGNITE-16292
> URL: https://issues.apache.org/jira/browse/IGNITE-16292
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required
>
> alterTableServerAndClient test periodically fails with:
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableDescriptorImpl.rowType(CacheTableDescriptorImpl.java:550)
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableImpl.getRowType(CacheTableImpl.java:78)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:147)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:160)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:110)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteSender.accept(IgniteSender.java:100)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:658)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:673)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:591)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:652)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$2(ExecutionServiceImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> 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.20.1#820001)
[jira] [Updated] (IGNITE-14916) Calcite. RuntimeHashIndex scan must filter result by predicate
[ https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14916: -- Summary: Calcite. RuntimeHashIndex scan must filter result by predicate (was: Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.) > Calcite. RuntimeHashIndex scan must filter result by predicate > -- > > Key: IGNITE-14916 > URL: https://issues.apache.org/jira/browse/IGNITE-14916 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Taras Ledkov >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > > FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it > takes into account only _searchRow_ which can be partial representation of > _condition_. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16494) Query engine allows to insert rows with logically equal compound PK
[
https://issues.apache.org/jira/browse/IGNITE-16494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490277#comment-17490277
]
Yury Gerzhedovich commented on IGNITE-16494:
[~tledkov-gridgain] LGTM except one minor comment in PR
> Query engine allows to insert rows with logically equal compound PK
> ---
>
> Key: IGNITE-16494
> URL: https://issues.apache.org/jira/browse/IGNITE-16494
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It's possible now to insert two logically equal yet physically different keys
> with SQL API into a table, that will bring indexes into inconsistent state.
> For example follow snippet will pass, although it should have fallen on the
> third statement:
> {code}
> create table test (id1 int, id2 int, val int, constraint primary key(id1,
> id2));
> insert into test (id1, id2, val) values (1, null, 1);
> insert into test (id1, val) values (1, 1); <-- should fail here because there
> is already exists such key, but it's
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14916) Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.
[
https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490213#comment-17490213
]
Aleksey Plekhanov commented on IGNITE-14916:
Reproducer for the problem:
{code:java}
/** */
@Test
public void testHashSpoolCondition() {
executeSql("CREATE TABLE t(i INTEGER)");
executeSql("INSERT INTO t VALUES (0), (1), (2)");
String sql = "SELECT i, (SELECT i FROM t WHERE i=t1.i AND i-1=0) FROM t AS
t1";
assertQuery(sql)
.matches(QueryChecker.containsSubPlan("IgniteHashIndexSpool"))
.returns(0, null)
.returns(1, 1)
.returns(2, null)
.check();
}{code}
[~tledkov-gridgain], are you going to fix this?
> Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if
> all conditions are covered.
> ---
>
> Key: IGNITE-14916
> URL: https://issues.apache.org/jira/browse/IGNITE-14916
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it
> takes into account only _searchRow_ which can be partial representation of
> _condition_.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16521) Collect Java code coverage
Roman Puchkovskiy created IGNITE-16521: -- Summary: Collect Java code coverage Key: IGNITE-16521 URL: https://issues.apache.org/jira/browse/IGNITE-16521 Project: Ignite Issue Type: Improvement Components: build Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha5 Jacoco might be used -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14871) Add cluster initialization commands to the Ignite CLI
[
https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490189#comment-17490189
]
Roman Puchkovskiy commented on IGNITE-14871:
Guys, thank you for your reviews
> Add cluster initialization commands to the Ignite CLI
> -
>
> Key: IGNITE-14871
> URL: https://issues.apache.org/jira/browse/IGNITE-14871
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Vyacheslav Koptilin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> According to the
> [IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization],
> we are going to have some new CLI commands:
> h3. Cluster initialization
> h4. Proposed API
> {code:bash}
> ./ignite cluster init --node-endpoint=??? --metastorage-nodes=???
> [---cmg-nodes=???]
> {code}
> * {{--node-endpoint}} - address of the REST endpoint of the receiving node
> in host:port format
> * {{--metastorage-nodes}} - space-separated list of addresses of the nodes
> that will host the Metastorage Raft group. If the "-cmg-nodes" parameter is
> empty, the same nodes will also host the Cluster Management Raft group.
> * {{--cmg-nodes}} - space-separated list of addresses of the nodes that will
> host the Cluster Management Raft group (optional parameter)
> h4. Description
> The purpose of this command is to deliver the initial cluster settings. The
> recipient node should propagate this message to the specified nodes, so that
> they will start the corresponding Raft groups. In case some nodes are
> inaccessible or the Raft groups are already started, an error message should
> be returned and the command must fail.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16103) Failed to create index for table "table" with some options
[ https://issues.apache.org/jira/browse/IGNITE-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander reassigned IGNITE-16103: Assignee: Luchnikov Alexander > Failed to create index for table "table" with some options > -- > > Key: IGNITE-16103 > URL: https://issues.apache.org/jira/browse/IGNITE-16103 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Timonin >Assignee: Luchnikov Alexander >Priority: Minor > Labels: good-first-issue, newbie > > 1. How to reproduce - all options CACHE_NAME, VALUE_TYPE, INLINE_SIZE should > be in the queries to reproduce failure: > ``` > create table table(id int PRIMARY KEY, fld1 int, fld2 int) with > "CACHE_NAME=TEST_CACHE_NAME,VALUE_TYPE=TEST_VALUE_TYPE"; > create index idx_0 on table(fld1, fld2) INLINE_SIZE 0; > ``` > Creation of index fails with exception: > Syntax error in SQL statement "CREATE INDEX IDX_0 ON TABLE(FLD1, FLD2) > INLINE_SIZE[*] 0 "; SQL statement: > create index IDX_0 on table(fld1, fld2) INLINE_SIZE 0 [42000-197] > at > > 2. How to fix: need to debug why parameters matters, looks like appearance of > this options triggers some checks that doesn't run while no options > specified. Then this checks should be triggers independently on specified > options or should be removed (depends on). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16091) ItCliServiceTest.testChangePeers is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-16091:
Assignee: Alexander Lapin (was: Kirill Gusakov)
> ItCliServiceTest.testChangePeers is flaky
> -
>
> Key: IGNITE-16091
> URL: https://issues.apache.org/jira/browse/IGNITE-16091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Raft_3747.log.zip,
> _Integration_Tests_Module_Raft_785.log.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ItCliServiceTest#testChangePeers may fail with the following message:
> {noformat}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: Peer 172.17.0.5:5009 failed to catch up.
> ==> expected: but was:
> at
> org.apache.ignite.raft.jraft.core.ItCliServiceTest.testChangePeers(ItCliServiceTest.java:320)
> {noformat}
> TeamCity:
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRaft/6305117
> Logs attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16275) [Native Persistence 3.0] B+Tree porting
[ https://issues.apache.org/jira/browse/IGNITE-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16275: - Ignite Flags: (was: Docs Required,Release Notes Required) > [Native Persistence 3.0] B+Tree porting > --- > > Key: IGNITE-16275 > URL: https://issues.apache.org/jira/browse/IGNITE-16275 > Project: Ignite > Issue Type: Task >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > As a part of data structures porting, B+Tree should be moved to Ignite 3 code > base. > All WAL operations should be commented by now I guess. It's not yet clear > what to do with them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16275) [Native Persistence 3.0] B+Tree porting
[ https://issues.apache.org/jira/browse/IGNITE-16275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-16275: Assignee: Kirill Tkalenko > [Native Persistence 3.0] B+Tree porting > --- > > Key: IGNITE-16275 > URL: https://issues.apache.org/jira/browse/IGNITE-16275 > Project: Ignite > Issue Type: Task >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > As a part of data structures porting, B+Tree should be moved to Ignite 3 code > base. > All WAL operations should be commented by now I guess. It's not yet clear > what to do with them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16151) Introduce timeout for calcite planner
[ https://issues.apache.org/jira/browse/IGNITE-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-16151: Assignee: Ivan Daschinsky > Introduce timeout for calcite planner > - > > Key: IGNITE-16151 > URL: https://issues.apache.org/jira/browse/IGNITE-16151 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > > Since it is quite common case that calcite planner can produce too many plans > and can planning infinitely, it is of crucial > importance to be able to cancel this process on timeout. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16518) BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
[
https://issues.apache.org/jira/browse/IGNITE-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490109#comment-17490109
]
Kirill Tkalenko commented on IGNITE-16518:
--
[~ibessonov] Please make code review.
> BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
> --
>
> Key: IGNITE-16518
> URL: https://issues.apache.org/jira/browse/IGNITE-16518
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Found that the test sometimes fails:
> *BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
> https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=7031624718556126435=1
> Explanation
> {noformat}
> Here’s a tree and a set of operations that lead to undesired results:
>[ 2 ]
> / \
>[ 1 ] [ 3 | 4 ]
>/ \ / |\
> [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 2
> [ 1 ]
> / \
> [ ] [ 3 | 4 ]
> | /|\
> [ 1 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 5
> [ 1 ]
> / \
> [ ] [ 3 ]
> | /\
> [ 1 ] [ 3 ] [ 4 ]
> // Remove 4
> [ 1 ]
>/ \
> [ ] [ ]
> | |
> [ 1 ] [ 3 ]
> // Remove 3
> [ 1 ]
> |
> [ ]
> |
> [ 1 ]
> // Remove 1
> [ ]
> |
> [ ]
> {noformat}
> It’s clear that at some point we have a whole level consisting of routing
> nodes. This later leads to somewhat incorrect “cut tree root” operation that
> leaves empty leaf.
> Possible solutions
> * root cutting should probably be recursive and should proceed until root
> node is not empty or is a leaf.
> * merge operation should work better with routing nodes - every time there’s
> a merge, we should consider the possibility to merge empty neighbor as well.
> * re-balance data from neighbor when node becomes a router node. Might be
> impossible or very challenging in current implementation.
> Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16518) BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
[
https://issues.apache.org/jira/browse/IGNITE-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-16518:
-
Reviewer: Ivan Bessonov
> BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
> --
>
> Key: IGNITE-16518
> URL: https://issues.apache.org/jira/browse/IGNITE-16518
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Found that the test sometimes fails:
> *BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
> https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=7031624718556126435=1
> Explanation
> {noformat}
> Here’s a tree and a set of operations that lead to undesired results:
>[ 2 ]
> / \
>[ 1 ] [ 3 | 4 ]
>/ \ / |\
> [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 2
> [ 1 ]
> / \
> [ ] [ 3 | 4 ]
> | /|\
> [ 1 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 5
> [ 1 ]
> / \
> [ ] [ 3 ]
> | /\
> [ 1 ] [ 3 ] [ 4 ]
> // Remove 4
> [ 1 ]
>/ \
> [ ] [ ]
> | |
> [ 1 ] [ 3 ]
> // Remove 3
> [ 1 ]
> |
> [ ]
> |
> [ 1 ]
> // Remove 1
> [ ]
> |
> [ ]
> {noformat}
> It’s clear that at some point we have a whole level consisting of routing
> nodes. This later leads to somewhat incorrect “cut tree root” operation that
> leaves empty leaf.
> Possible solutions
> * root cutting should probably be recursive and should proceed until root
> node is not empty or is a leaf.
> * merge operation should work better with routing nodes - every time there’s
> a merge, we should consider the possibility to merge empty neighbor as well.
> * re-balance data from neighbor when node becomes a router node. Might be
> impossible or very challenging in current implementation.
> Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16518) BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
[
https://issues.apache.org/jira/browse/IGNITE-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490089#comment-17490089
]
Ignite TC Bot commented on IGNITE-16518:
{panel:title=Branch: [pull/9813/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9813/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6411830]]
* {color:#013220}IgniteBasicTestSuite:
BPlusTreeFakeReuseSelfTest.testEmptyLeafAfterConcurrentRemoves - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
BPlusTreeReuseSelfTest.testEmptyLeafAfterConcurrentRemoves - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
BPlusTreeSelfTest.testEmptyLeafAfterConcurrentRemoves - PASSED{color}
{color:#8b}PDS 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6411890]]
* {color:#013220}IgnitePdsTestSuite:
BPlusTreePageMemoryImplTest.testEmptyLeafAfterConcurrentRemoves - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
BPlusTreeReuseListPageMemoryImplTest.testEmptyLeafAfterConcurrentRemoves -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6411916buildTypeId=IgniteTests24Java8_RunAll]
> BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
> --
>
> Key: IGNITE-16518
> URL: https://issues.apache.org/jira/browse/IGNITE-16518
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Found that the test sometimes fails:
> *BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
> https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=7031624718556126435=1
> Explanation
> {noformat}
> Here’s a tree and a set of operations that lead to undesired results:
>[ 2 ]
> / \
>[ 1 ] [ 3 | 4 ]
>/ \ / |\
> [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 2
> [ 1 ]
> / \
> [ ] [ 3 | 4 ]
> | /|\
> [ 1 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 5
> [ 1 ]
> / \
> [ ] [ 3 ]
> | /\
> [ 1 ] [ 3 ] [ 4 ]
> // Remove 4
> [ 1 ]
>/ \
> [ ] [ ]
> | |
> [ 1 ] [ 3 ]
> // Remove 3
> [ 1 ]
> |
> [ ]
> |
> [ 1 ]
> // Remove 1
> [ ]
> |
> [ ]
> {noformat}
> It’s clear that at some point we have a whole level consisting of routing
> nodes. This later leads to somewhat incorrect “cut tree root” operation that
> leaves empty leaf.
> Possible solutions
> * root cutting should probably be recursive and should proceed until root
> node is not empty or is a leaf.
> * merge operation should work better with routing nodes - every time there’s
> a merge, we should consider the possibility to merge empty neighbor as well.
> * re-balance data from neighbor when node becomes a router node. Might be
> impossible or very challenging in current implementation.
> Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-16502:
-
Assignee: Konstantin Orlov
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16502:
---
Labels: ignite-3 (was: )
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16502:
---
Component/s: sql
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Mirza Aliev
>Priority: Blocker
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16502:
---
Priority: Blocker (was: Major)
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16292) Calcite. Unstable alterTableServerAndClient test.
[
https://issues.apache.org/jira/browse/IGNITE-16292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ermakov reassigned IGNITE-16292:
-
Assignee: Vladimir Ermakov
> Calcite. Unstable alterTableServerAndClient test.
> -
>
> Key: IGNITE-16292
> URL: https://issues.apache.org/jira/browse/IGNITE-16292
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite, calcite2-required
>
> alterTableServerAndClient test periodically fails with:
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 4
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableDescriptorImpl.rowType(CacheTableDescriptorImpl.java:550)
> at
> org.apache.ignite.internal.processors.query.calcite.schema.CacheTableImpl.getRowType(CacheTableImpl.java:78)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.deriveRowType(ProjectableFilterableTableScan.java:147)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at org.apache.calcite.rel.SingleRel.deriveRowType(SingleRel.java:89)
> at
> org.apache.calcite.rel.AbstractRelNode.getRowType(AbstractRelNode.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:160)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:110)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteSender.accept(IgniteSender.java:100)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:658)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:673)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:591)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:652)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$2(ExecutionServiceImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
> at
> org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> 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.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that some threads are waiting
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows some threads are waiting
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows some threads are waiting
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows some threads are waiting
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dump shows that we wait:
{noformat}
at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)
at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)
at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)
{noformat}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dump shows that we wait:
{noformat}
at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)
at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)
at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)
{noformat}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dump shows that we wait:
> {noformat}
> at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)
> at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)
> {noformat}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16504) Sort out and merge Calcite tickets to Ignite 3.0 (step 4)
[ https://issues.apache.org/jira/browse/IGNITE-16504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-16504: -- Assignee: Evgeny Stanilovsky > Sort out and merge Calcite tickets to Ignite 3.0 (step 4) > - > > Key: IGNITE-16504 > URL: https://issues.apache.org/jira/browse/IGNITE-16504 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Let's sort out tikets contains by > [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. > Tickets that could be simply merged - merge immediately. For hard cases let's > create separate tickets with estimation and link them to IGNITE-15658 or > links to blocker ticket. > h4. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-11402) SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE
[ https://issues.apache.org/jira/browse/IGNITE-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490034#comment-17490034 ] Taras Ledkov commented on IGNITE-11402: --- [~jooger], [~zstan], please review the patch. > SQL: Add ability to specify inline size of PK and affinity key indexes from > CREATE TABLE > > > Key: IGNITE-11402 > URL: https://issues.apache.org/jira/browse/IGNITE-11402 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Labels: newbie > Fix For: 2.13 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Currently it is not possible to set inline size for automatically created > indexes easily. We need to make sure that user has a convenient way to set > them both programmatically and from DDL. > Start point for automatically created indexes is > org.apache.ignite.internal.processors.query.h2.H2TableDescriptor#createSystemIndexes > where passed parameter inlineSize as -1 for > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#createSortedIndex -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-11402) SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE
[
https://issues.apache.org/jira/browse/IGNITE-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490033#comment-17490033
]
Ignite TC Bot commented on IGNITE-11402:
{panel:title=Branch: [pull/9604/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9604/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6410933]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testCreateSystemIndexWithSpecifiedInlineSizeByDdl - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testCreateSystemIndexWithSpecifiedInlineSizeByDdl -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6410957buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Add ability to specify inline size of PK and affinity key indexes from
> CREATE TABLE
>
>
> Key: IGNITE-11402
> URL: https://issues.apache.org/jira/browse/IGNITE-11402
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: newbie
> Fix For: 2.13
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently it is not possible to set inline size for automatically created
> indexes easily. We need to make sure that user has a convenient way to set
> them both programmatically and from DDL.
> Start point for automatically created indexes is
> org.apache.ignite.internal.processors.query.h2.H2TableDescriptor#createSystemIndexes
> where passed parameter inlineSize as -1 for
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#createSortedIndex
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16363) Provide a guarantee of completeness of pre-recovery actions
[ https://issues.apache.org/jira/browse/IGNITE-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17490017#comment-17490017 ] Denis Chudov commented on IGNITE-16363: --- Merged to the feature branch, commit 7d53cae8792255c88fc087adeef97b71d2848d52 > Provide a guarantee of completeness of pre-recovery actions > --- > > Key: IGNITE-16363 > URL: https://issues.apache.org/jira/browse/IGNITE-16363 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > We need to be sure that recovery should perform on the node after it has > joined physical topology and has been validated via node join protocol. > Necessary prerequisites for the recovery start are following: > * the node has retrieved the information and metastorage group from Vault; > * the node has received a join response in case of non-standalone mode, > meaning that the node is validated and is allowed to join the cluster. This > step can be mocked for now; > * all components have started and subscribed on configuration updates and > events. After this, notifications should be allowed and the recovery actually > starts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
