[jira] [Commented] (IGNITE-15926) DDL methos for tables should throw an exception when the tables exist or not
[
https://issues.apache.org/jira/browse/IGNITE-15926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464329#comment-17464329
]
Alexander Lapin commented on IGNITE-15926:
--
[~v.pyatkov] LGTM
> DDL methos for tables should throw an exception when the tables exist or not
>
>
> Key: IGNITE-15926
> URL: https://issues.apache.org/jira/browse/IGNITE-15926
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 6h
> Remaining Estimate: 0h
>
> ANSI standard[1] requires two methods for either table manager functions
> (DDL):
> _DROP TABLE [ IF EXISTS ] syntax_
> _CREATE TABLE [ IF NOT EXISTS ] syntax_
> _ALTER TABLE [ IF EXISTS ] syntax_
> for implement all these functionalities I offer to handle exceptions
> (TableAlreadyExistsException, TableNotExistsException)
> {code:java}
> TableManager#dropTable throws TableNotExistsException
> IgniteTables#createTable throws TableAlreadyExistsException
> IgniteTables#alterTable throws TableNotExistsException
> {code}
> Also, the twins of these methods with `IfNotExists` suffix (and them
> asynchronous analogs) would be removed.
> [1] [https://postgrespro.ru/docs/postgrespro/9.6/sql-altertable]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16177) Snapshot restore operation may hang if cache contains "empty" partitions
[
https://issues.apache.org/jira/browse/IGNITE-16177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464269#comment-17464269
]
Ignite TC Bot commented on IGNITE-16177:
{panel:title=Branch: [pull/9679/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9679/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6336656]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testRestoreWithEmptyPartitions[Encryption
is disabled] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6337166buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot restore operation may hang if cache contains "empty" partitions
>
>
> Key: IGNITE-16177
> URL: https://issues.apache.org/jira/browse/IGNITE-16177
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Labels: iep-43
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The snapshot restore may hang when some of the cache group partitions have
> not been physically created (for example, there is not enough data in the
> cache).
> Reproducer
> {code:java}
> public class IgniteClusterSnapshotRestoreEmptyPartsTest extends
> IgniteClusterSnapshotRestoreBaseTest {
> @Test
> public void testRestoreWithEmptyPartition() throws Exception {
> // Cache with 1024 partitions.
> CacheConfiguration cacheCfg1 = new
> CacheConfiguration<>(CACHE1);
> // Add only 10 keys (only 10 partitions will be created on the disk).
> IgniteEx ignite = startGridsWithCache(1, 10, Integer::new, cacheCfg1);
> // Snapshot contains only 10 (out of 1024 "affinity" partitions).
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
> ignite.cache(CACHE1).destroy();
> // The restore operation hangs during the "preload" phase.
> ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-13464) Ignite-rest-http modules includes vulnerable dependencies
[ https://issues.apache.org/jira/browse/IGNITE-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464058#comment-17464058 ] Sergei Ryzhov commented on IGNITE-13464: If we removed these libs, stdout will be contained 2021-12-22 22:47:43.916:INFO::main: Logging initialized @2598ms to org.eclipse.jetty.util.log.StdErrLog https://issues.apache.org/jira/browse/IGNITE-1395 added libs for log4j2 Thanks [~namelchev] > Ignite-rest-http modules includes vulnerable dependencies > - > > Key: IGNITE-13464 > URL: https://issues.apache.org/jira/browse/IGNITE-13464 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.9, 2.8.1 >Reporter: Stephen Darlington >Assignee: Sergei Ryzhov >Priority: Blocker > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > The ignite-rest-http module includes a [vulnerable > version|https://nvd.nist.gov/vuln/detail/CVE-2019-17571] of the log4j > library. It also appears to include slf4j. Why does the REST API include its > own logging libraries? > This was spotted in 2.8.1 but still appears to be an issue in master and 2.9. > More here: > http://apache-ignite-users.70518.x6.nabble.com/critical-security-vulnerability-for-opt-ignite-apache-ignite-libs-optional-ignite-rest-http-log4j-1-r-td34031.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454657#comment-17454657
]
Ilya Shishkov edited comment on IGNITE-14913 at 12/22/21, 8:27 PM:
---
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are to turn on/off or show status of metrics:
# For all caches of a cluster.
# For a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics --enable|--disable|--status cache1[,..,cacheN]|--all-caches
{code}
was (Author: shishkovilja):
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are to turn on/off or show status of metrics:
# For all caches of a cluster.
# For a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, enabling or disabling cache statistics is available only via
> IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status regexPattern
> {code}
> * regexPattern - regular expression for filtering caches (not cache groups)
> by their names. Caches with names satisfying the regular expression will be
> affected by the command. In case of an empty regex, the control script should
> finish execution with an error. If no matching caches are found, the control
> script should print a message about matching caches' absence.
> * enable - enables statistics for caches satisfying the 'regexPattern'.
> * disable - disables statistics for caches satisfying the 'regexPattern'.
> * status - prints current statistics status (enabled/disabled) for caches
> satisfying the 'regexPattern'.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-13616) IEP-54 Live schema for tables
[ https://issues.apache.org/jira/browse/IGNITE-13616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464012#comment-17464012 ] Valentin Kulichenko commented on IGNITE-13616: -- [~amashenkov] Is this parent ticket for IEP-54 as a whole, or specifically for the live schema? > IEP-54 Live schema for tables > - > > Key: IGNITE-13616 > URL: https://issues.apache.org/jira/browse/IGNITE-13616 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Umbrella ticket for > [IEP-54|https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16151) Introduce timeout for calcite planner
[ https://issues.apache.org/jira/browse/IGNITE-16151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464011#comment-17464011 ] Valentin Kulichenko commented on IGNITE-16151: -- [~ivandasch] I would suggest to have a single timeout for the query execution as a whole. >From the user's perspective, planning is a part of execution. There is no good >way for a user to decide how long the planning should take. > 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 >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] [Assigned] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-16194:
-
Assignee: Pavel Pereslegin
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot.
> --
>
> Key: IGNITE-16194
> URL: https://issues.apache.org/jira/browse/IGNITE-16194
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Critical
>
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot. Current tests do not reproduce this
> problem because they share the same working folder for the snapshots.
> Reproducer (uses dedicated work dir):
> {code:java}
> public class IgniteSnapshotRestoreWithNewNodeTest extends
> AbstractSnapshotSelfTest {
> private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
> @Test
> public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation()
> throws Exception {
> String workDir = U.defaultWorkDirectory();
> IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
> (id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
> U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
> ignite.destroyCache(DEFAULT_CACHE_NAME);
> awaitPartitionMapExchange();
> // Start new node with an empty snapshots work directory.
>
> startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
> resetBaselineTopology();
> ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
> // fails here
> for (Ignite grid : G.allGrids())
> assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
> }
> @Parameterized.Parameters(name = "Encryption is disabled")
> public static Iterable disabledEncryption() {
> return Collections.singletonList(false);
> }
> /** {@inheritDoc} */
> @After
> @Override public void afterTestSnapshot() throws Exception {
> super.afterTestSnapshot();
> try (DirectoryStream ds =
> Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
> path -> Files.isDirectory(path) &&
> path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
> ) {
> for (Path dir : ds)
> U.delete(dir);
> }
> }
> }
> {code}
> Log output
> {noformat}
> class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
> reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
> err=class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/user/ignite/source/work/snapshots/testSnapshot]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> 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)
> Caused by: class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/user/ignite/source/work/snapshots/testSnapshot
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
> at
>
[jira] [Updated] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16194:
--
Description:
Snapshot restore operation fails if any baseline node doesn't contain metadata
for the specified snapshot. Current tests do not reproduce this problem because
they share the same working folder for the snapshots.
Reproducer (uses dedicated work dir):
{code:java}
public class IgniteSnapshotRestoreWithNewNodeTest extends
AbstractSnapshotSelfTest {
private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
@Test
public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation() throws
Exception {
String workDir = U.defaultWorkDirectory();
IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
(id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
ignite.destroyCache(DEFAULT_CACHE_NAME);
awaitPartitionMapExchange();
// Start new node with an empty snapshots work directory.
startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
resetBaselineTopology();
ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT); //
fails here
for (Ignite grid : G.allGrids())
assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
}
@Parameterized.Parameters(name = "Encryption is disabled")
public static Iterable disabledEncryption() {
return Collections.singletonList(false);
}
/** {@inheritDoc} */
@After
@Override public void afterTestSnapshot() throws Exception {
super.afterTestSnapshot();
try (DirectoryStream ds =
Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
path -> Files.isDirectory(path) &&
path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
) {
for (Path dir : ds)
U.delete(dir);
}
}
}
{code}
Log output
{noformat}
class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
reduce job results due to undeclared user exception
[task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
err=class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/user/ignite/source/work/snapshots/testSnapshot]
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
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)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/user/ignite/source/work/snapshots/testSnapshot
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:39)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$6.call(GridTaskWorker.java:1149)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7276)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1147)
... 11 more
Caused by: class org.apache.ignite.IgniteException:
/home/user/ignite/source/work/snapshots/testSnapshot
at
[jira] [Updated] (IGNITE-15240) Thin 3.0: Transactions
[
https://issues.apache.org/jira/browse/IGNITE-15240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-15240:
Description:
Implement Table API transactions in thin client.
Update
[IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0]
to reflect required protocol changes.
was:
Implement Table API transactions in thin client:
{code:java}
ClientTable#withTransaction
ClientTable#transaction
{code}
> Thin 3.0: Transactions
> --
>
> Key: IGNITE-15240
> URL: https://issues.apache.org/jira/browse/IGNITE-15240
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> Implement Table API transactions in thin client.
> Update
> [IEP-76|https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0]
> to reflect required protocol changes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16194:
--
Description:
Snapshot restore operation fails if any baseline node doesn't contain metadata
for the specified snapshot. Current tests do not reproduce this problem because
they share the same working folder for the snapshots.
Reproducer (uses dedicated work dir):
{code:java}
public class IgniteSnapshotRestoreWithNewNodeTest extends
AbstractSnapshotSelfTest {
private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
@Test
public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation() throws
Exception {
String workDir = U.defaultWorkDirectory();
IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
(id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
ignite.destroyCache(DEFAULT_CACHE_NAME);
awaitPartitionMapExchange();
// Start new node with an empty snapshots work directory.
startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
resetBaselineTopology();
ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
for (Ignite grid : G.allGrids())
assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
}
@Parameterized.Parameters(name = "Encryption is disabled")
public static Iterable disabledEncryption() {
return Collections.singletonList(false);
}
/** {@inheritDoc} */
@After
@Override public void afterTestSnapshot() throws Exception {
super.afterTestSnapshot();
try (DirectoryStream ds =
Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
path -> Files.isDirectory(path) &&
path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
) {
for (Path dir : ds)
U.delete(dir);
}
}
}
{code}
Log output
{noformat}
class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
reduce job results due to undeclared user exception
[task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
err=class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/user/ignite/source/work/snapshots/testSnapshot]
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
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)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/user/ignite/source/work/snapshots/testSnapshot
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:39)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$6.call(GridTaskWorker.java:1149)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7276)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1147)
... 11 more
Caused by: class org.apache.ignite.IgniteException:
/home/user/ignite/source/work/snapshots/testSnapshot
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager.readSnapshotMetadatas(IgniteSnapshotManager.java:1253)
at
[jira] [Assigned] (IGNITE-16075) Calcite engine. Support UUID data type
[
https://issues.apache.org/jira/browse/IGNITE-16075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-16075:
-
Assignee: Vladimir Steshin
> Calcite engine. Support UUID data type
> --
>
> Key: IGNITE-16075
> URL: https://issues.apache.org/jira/browse/IGNITE-16075
> Project: Ignite
> Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, UUID columns can be selected or even filtered if a table
> containing such a column is created not by the Calcite-based SQL engine (for
> example via cache API using {{@QuerySqlField}} field annotation).
> But we cannot use it in DDL:
> {noformat}
> CREATE TABLE t (id UUID)
> {noformat}
> Or cast:
> {noformat}
> SELECT CAST(id AS UUID)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16194:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot.
> --
>
> Key: IGNITE-16194
> URL: https://issues.apache.org/jira/browse/IGNITE-16194
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
>Reporter: Pavel Pereslegin
>Priority: Critical
>
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot. Current tests do not reproduce this
> problem because they share the same working folder for the snapshots.
> Reproducer (uses dedicated work dir):
> {code:java}
> public class IgniteSnapshotRestoreWithNewNodeTest extends
> AbstractSnapshotSelfTest {
> private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
> @Test
> public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation()
> throws Exception {
> String workDir = U.defaultWorkDirectory();
> IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
> (id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
> U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
> ignite.destroyCache(DEFAULT_CACHE_NAME);
> awaitPartitionMapExchange();
> // Start new node with an empty snapshots work directory.
>
> startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
> resetBaselineTopology();
> ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
> for (Ignite grid : G.allGrids())
> assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
> }
> @Parameterized.Parameters(name = "Encryption is disabled")
> public static Iterable disabledEncryption() {
> return Collections.singletonList(false);
> }
> /** {@inheritDoc} */
> @After
> @Override public void afterTestSnapshot() throws Exception {
> super.afterTestSnapshot();
> try (DirectoryStream ds =
> Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
> path -> Files.isDirectory(path) &&
> path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
> ) {
> for (Path dir : ds)
> U.delete(dir);
> }
> }
> }
> {code}
> Log output
> {noformat}
> class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
> reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
> err=class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/xtern/src/java/ignite/source/work/snapshots/testSnapshot]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> 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)
> Caused by: class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/xtern/src/java/ignite/source/work/snapshots/testSnapshot
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
> at
>
[jira] [Updated] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16194:
--
Affects Version/s: 2.11
2.12
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot.
> --
>
> Key: IGNITE-16194
> URL: https://issues.apache.org/jira/browse/IGNITE-16194
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
>Reporter: Pavel Pereslegin
>Priority: Critical
>
> Snapshot restore operation fails if any baseline node doesn't contain
> metadata for the specified snapshot. Current tests do not reproduce this
> problem because they share the same working folder for the snapshots.
> Reproducer (uses dedicated work dir):
> {code:java}
> public class IgniteSnapshotRestoreWithNewNodeTest extends
> AbstractSnapshotSelfTest {
> private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
> @Test
> public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation()
> throws Exception {
> String workDir = U.defaultWorkDirectory();
> IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
> (id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
> U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
> ignite.destroyCache(DEFAULT_CACHE_NAME);
> awaitPartitionMapExchange();
> // Start new node with an empty snapshots work directory.
>
> startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
> resetBaselineTopology();
> ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
> for (Ignite grid : G.allGrids())
> assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
> }
> @Parameterized.Parameters(name = "Encryption is disabled")
> public static Iterable disabledEncryption() {
> return Collections.singletonList(false);
> }
> /** {@inheritDoc} */
> @After
> @Override public void afterTestSnapshot() throws Exception {
> super.afterTestSnapshot();
> try (DirectoryStream ds =
> Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
> path -> Files.isDirectory(path) &&
> path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
> ) {
> for (Path dir : ds)
> U.delete(dir);
> }
> }
> }
> {code}
> Log output
> {noformat}
> class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
> reduce job results due to undeclared user exception
> [task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
> err=class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/xtern/src/java/ignite/source/work/snapshots/testSnapshot]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> 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)
> Caused by: class
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
> /home/xtern/src/java/ignite/source/work/snapshots/testSnapshot
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
> at
>
[jira] [Created] (IGNITE-16194) Snapshot restore operation fails if any baseline node doesn't contain metadata for the specified snapshot.
Pavel Pereslegin created IGNITE-16194:
-
Summary: Snapshot restore operation fails if any baseline node
doesn't contain metadata for the specified snapshot.
Key: IGNITE-16194
URL: https://issues.apache.org/jira/browse/IGNITE-16194
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
Snapshot restore operation fails if any baseline node doesn't contain metadata
for the specified snapshot. Current tests do not reproduce this problem because
they share the same working folder for the snapshots.
Reproducer (uses dedicated work dir):
{code:java}
public class IgniteSnapshotRestoreWithNewNodeTest extends
AbstractSnapshotSelfTest {
private static final String DEDICATED_CLUSTER_PREFIX = "tmp-cluster-";
@Test
public void testRestoreOnNewTopologyWithDedicatedSnapshotLocation() throws
Exception {
String workDir = U.defaultWorkDirectory();
IgniteEx ignite = startGridsWithCache(2, CACHE_KEYS_RANGE, valBuilder,
(id, cfg) -> Paths.get(workDir, DEDICATED_CLUSTER_PREFIX +
U.maskForFileName(cfg.getIgniteInstanceName())).toString(), dfltCacheCfg);
ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
ignite.destroyCache(DEFAULT_CACHE_NAME);
awaitPartitionMapExchange();
// Start new node with an empty snapshots work directory.
startGrid(optimize(getConfiguration(getTestIgniteInstanceName(2)).setCacheConfiguration()));
resetBaselineTopology();
ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
for (Ignite grid : G.allGrids())
assertCacheKeys(grid.cache(DEFAULT_CACHE_NAME), CACHE_KEYS_RANGE);
}
@Parameterized.Parameters(name = "Encryption is disabled")
public static Iterable disabledEncryption() {
return Collections.singletonList(false);
}
/** {@inheritDoc} */
@After
@Override public void afterTestSnapshot() throws Exception {
super.afterTestSnapshot();
try (DirectoryStream ds =
Files.newDirectoryStream(Paths.get(U.defaultWorkDirectory()),
path -> Files.isDirectory(path) &&
path.getFileName().toString().toLowerCase().startsWith(DEDICATED_CLUSTER_PREFIX))
) {
for (Path dir : ds)
U.delete(dir);
}
}
}
{code}
Log output
{noformat}
class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to
reduce job results due to undeclared user exception
[task=org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask@4bb91e74,
err=class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/xtern/src/java/ignite/source/work/snapshots/testSnapshot]
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1188)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:976)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1155)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1390)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
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)
Caused by: class
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotVerifyException:
/home/xtern/src/java/ignite/source/work/snapshots/testSnapshot
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:105)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotMetadataCollectorTask.reduce(SnapshotMetadataCollectorTask.java:39)
at
org.apache.ignite.internal.processors.task.GridTaskWorker$6.call(GridTaskWorker.java:1149)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7276)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.reduce(GridTaskWorker.java:1147)
... 11 more
Caused by: class org.apache.ignite.IgniteException:
[jira] [Commented] (IGNITE-16145) Release the Apache Ignite 2.11.1
[ https://issues.apache.org/jira/browse/IGNITE-16145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463930#comment-17463930 ] Maxim Muzafarov commented on IGNITE-16145: -- Merged to the master branch. > Release the Apache Ignite 2.11.1 > > > Key: IGNITE-16145 > URL: https://issues.apache.org/jira/browse/IGNITE-16145 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > It is necessary to prepare the Apache Ignite 2.11.1 with required security > fixes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16190) Remove classes that was left after legacy service grid removal
[ https://issues.apache.org/jira/browse/IGNITE-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16190: - Labels: IEP-80 (was: ) > Remove classes that was left after legacy service grid removal > -- > > Key: IGNITE-16190 > URL: https://issues.apache.org/jira/browse/IGNITE-16190 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: IEP-80 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > ServiceDescriptorImpl is required to be removed due to legacy service grid > was removed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15271) ITNodeTest.testFollowerStartStopFollowing is still flaky
[
https://issues.apache.org/jira/browse/IGNITE-15271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15271:
-
Fix Version/s: 3.0.0-alpha4
> ITNodeTest.testFollowerStartStopFollowing is still flaky
>
>
> Key: IGNITE-15271
> URL: https://issues.apache.org/jira/browse/IGNITE-15271
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2678)
> {noformat}
> The issue is caused by (unexpected) excessive number of state changes during
> leader election on term=2:
> {noformat}
> INFO: onStartFollowing: LeaderChangeContext [leaderId=172.17.0.6:5004,
> term=2, status=Status[ENEWLEADER<10011>: Follower receives message from new
> leader with the same term.]].
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: onStartFollowing: LeaderChangeContext [leaderId=172.17.0.6:5004,
> term=2, status=Status[ENEWLEADER<10011>: Follower receives message from new
> leader with the same term.]].
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: onStartFollowing: LeaderChangeContext [leaderId=172.17.0.6:5004,
> term=2, status=Status[ENEWLEADER<10011>: Follower receives message from new
> leader with the same term.]].
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: onStopFollowing: LeaderChangeContext [leaderId=172.17.0.6:5004, term=2,
> status=Status[EVOTEFORCANDIDATE<10010>: Raft node votes for some candidate,
> step down to restart election_timer.]].
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> WARNING: Node received invalid RequestVoteResponse
> from 172.17.0.6:5006, state not in STATE_CANDIDATE but STATE_LEADER.
> Aug 09, 2021 9:32:37 AM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: onStartFollowing: LeaderChangeContext [leaderId=172.17.0.6:5004,
> term=2, status=Status[ENEWLEADER<10011>: Follower receives message from new
> leader with the same term.]].
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16179) SystemProperties for pluggins
[ https://issues.apache.org/jira/browse/IGNITE-16179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16179: - Issue Type: Improvement (was: Task) > SystemProperties for pluggins > - > > Key: IGNITE-16179 > URL: https://issues.apache.org/jira/browse/IGNITE-16179 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Alexander Belyak >Priority: Major > > Need to allow plugins to pass its system properties to ignite.sh to print > like other IgniteSystemProperties (ignite.sh -systemProps). Maybe with some > additional filter/flag to show the property's plugin name. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16190) Remove classes that was left after legacy service grid removal
[ https://issues.apache.org/jira/browse/IGNITE-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16190: - Summary: Remove classes that was left after legacy service grid removal (was: ServiceDescriptorImpl is required to be removed due to legacy service grid was removed) > Remove classes that was left after legacy service grid removal > -- > > Key: IGNITE-16190 > URL: https://issues.apache.org/jira/browse/IGNITE-16190 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > ServiceDescriptorImpl is required to be removed due to legacy service grid > was removed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16192) Calcite. Support hidden columns
[ https://issues.apache.org/jira/browse/IGNITE-16192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16192: --- Priority: Critical (was: Major) > Calcite. Support hidden columns > --- > > Key: IGNITE-16192 > URL: https://issues.apache.org/jira/browse/IGNITE-16192 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Priority: Critical > Labels: calcite2-required, calcite3-required, ignite-3 > > We should have ability to hide some columns. At first glance it's *_key* > column. It really important for autogenerated PK. > Such columns couldn't be accessed for 'select * ' query, but available for > explicit use in select statement. > Another example of hidden column is Oracle *rownum*. > Also another databases (Oracle, SQLSERVER, MySQL) have support hidden > (invisible) columns which could be created user explicitly and amend the > visibility through ALTER statement. Maybe we should consider possible > extension it for future to support one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16192) Calcite. Support hidden columns
[ https://issues.apache.org/jira/browse/IGNITE-16192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16192: --- Description: We should have ability to hide some columns. At first glance it's *_key* column. It really important for autogenerated PK. Such columns couldn't be accessed for 'select * ' query, but available for explicit use in select statement. Another example of hidden column is Oracle *rownum*. Also another databases (Oracle, SQLSERVER, MySQL) have support hidden (invisible) columns which could be created user explicitly and amend the visibility through ALTER statement. Maybe we should consider possible extension it for future to support one. was: We should have ability to hide some columns. At first glance it's *_key* column. It really important for autogenerated PK. Such columns couldn't be accessed for 'select * ' query, but available for explicit use in select statement. Another example of hidden column is Oracle *rownum*. Also another databases have support hidden (invisible) columns which could be created user explicitly and amend the visibility through ALTER statement. Maybe we should consider possible extension it for future to support one. > Calcite. Support hidden columns > --- > > Key: IGNITE-16192 > URL: https://issues.apache.org/jira/browse/IGNITE-16192 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: calcite2-required, calcite3-required, ignite-3 > > We should have ability to hide some columns. At first glance it's *_key* > column. It really important for autogenerated PK. > Such columns couldn't be accessed for 'select * ' query, but available for > explicit use in select statement. > Another example of hidden column is Oracle *rownum*. > Also another databases (Oracle, SQLSERVER, MySQL) have support hidden > (invisible) columns which could be created user explicitly and amend the > visibility through ALTER statement. Maybe we should consider possible > extension it for future to support one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16193) Thin 3.0: Implement transaction timeouts
Pavel Tupitsyn created IGNITE-16193: --- Summary: Thin 3.0: Implement transaction timeouts Key: IGNITE-16193 URL: https://issues.apache.org/jira/browse/IGNITE-16193 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-alpha3 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Implement *ClientTransactions#withTimeout*. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15936) Implement transaction timeouts
[ https://issues.apache.org/jira/browse/IGNITE-15936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-15936: Summary: Implement transaction timeouts (was: Implement timeouts) > Implement transaction timeouts > -- > > Key: IGNITE-15936 > URL: https://issues.apache.org/jira/browse/IGNITE-15936 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > > Tx should be rolled back if a timeout is exceeded [1] > [1] org.apache.ignite.tx.IgniteTransactions#withTimeout -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16192) Calcite. Support hidden columns
Yury Gerzhedovich created IGNITE-16192: -- Summary: Calcite. Support hidden columns Key: IGNITE-16192 URL: https://issues.apache.org/jira/browse/IGNITE-16192 Project: Ignite Issue Type: New Feature Components: sql Reporter: Yury Gerzhedovich We should have ability to hide some columns. At first glance it's *_key* column. It really important for autogenerated PK. Such columns couldn't be accessed for 'select * ' query, but available for explicit use in select statement. Another example of hidden column is Oracle *rownum*. Also another databases have support hidden (invisible) columns which could be created user explicitly and amend the visibility through ALTER statement. Maybe we should consider possible extension it for future to support one. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
Aleksey Plekhanov created IGNITE-16191:
--
Summary: Calcite engine. Unexpected result of COUNT with multiple
parameters
Key: IGNITE-16191
URL: https://issues.apache.org/jira/browse/IGNITE-16191
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
The calcite engine supports the {{COUNT}} aggregate function with multiple
parameters. Such a function should return the number of input rows for which
parameters are wholly not null.
But currently queries like:
{noformat}
SELECT COUNT(null, 1)
SELECT COUNT(1, null)
{noformat}
Return 0 (expected 1).
Query:
{noformat}
SELECT COUNT(null, null)
{noformat}
Throw an exception:
{noformat}
Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:657)
at java.util.ArrayList.get(ArrayList.java:433)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
at
org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16188) Eliminate creation of singleton list for DataRecord
[
https://issues.apache.org/jira/browse/IGNITE-16188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-16188:
Assignee: Nikolay Izhikov
> Eliminate creation of singleton list for DataRecord
> ---
>
> Key: IGNITE-16188
> URL: https://issues.apache.org/jira/browse/IGNITE-16188
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>
> For most DataRecord intermidiate {{Collections.singletonList}} created.
> It possible to eliminate this object with {{SingleDataRecord}},
> {{MultiDataRecord}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16189) Improve getting started section for Ignite C++
[ https://issues.apache.org/jira/browse/IGNITE-16189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-16189: - Fix Version/s: 2.12 > Improve getting started section for Ignite C++ > -- > > Key: IGNITE-16189 > URL: https://issues.apache.org/jira/browse/IGNITE-16189 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Ivan Daschinsky >Assignee: Nikita A. Safonov >Priority: Major > Fix For: 2.12 > > > 1. Lets separate building steps and examples for Ignite.C++ (thick client) > and thin client > 2. Lets remove ODBC (UnixODBC) and OpenSSL dependency for Ignite.C++. > 3. Lets remove JDK dependency for thin client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16190) ServiceDescriptorImpl is required to be removed due to legacy service grid was removed
Maxim Muzafarov created IGNITE-16190: Summary: ServiceDescriptorImpl is required to be removed due to legacy service grid was removed Key: IGNITE-16190 URL: https://issues.apache.org/jira/browse/IGNITE-16190 Project: Ignite Issue Type: Bug Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.13 ServiceDescriptorImpl is required to be removed due to legacy service grid was removed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16190) ServiceDescriptorImpl is required to be removed due to legacy service grid was removed
[ https://issues.apache.org/jira/browse/IGNITE-16190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16190: - Ignite Flags: (was: Docs Required,Release Notes Required) > ServiceDescriptorImpl is required to be removed due to legacy service grid > was removed > -- > > Key: IGNITE-16190 > URL: https://issues.apache.org/jira/browse/IGNITE-16190 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > > ServiceDescriptorImpl is required to be removed due to legacy service grid > was removed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16189) Improve getting started section for Ignite C++
Ivan Daschinsky created IGNITE-16189: Summary: Improve getting started section for Ignite C++ Key: IGNITE-16189 URL: https://issues.apache.org/jira/browse/IGNITE-16189 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Ivan Daschinsky Assignee: Nikita A. Safonov 1. Lets separate building steps and examples for Ignite.C++ (thick client) and thin client 2. Lets remove ODBC (UnixODBC) and OpenSSL dependency for Ignite.C++. 3. Lets remove JDK dependency for thin client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16188) Eliminate creation of singleton list for DataRecord
Nikolay Izhikov created IGNITE-16188:
Summary: Eliminate creation of singleton list for DataRecord
Key: IGNITE-16188
URL: https://issues.apache.org/jira/browse/IGNITE-16188
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
For most DataRecord intermidiate {{Collections.singletonList}} created.
It possible to eliminate this object with {{SingleDataRecord}},
{{MultiDataRecord}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15694) Document building ODBC driver using cmake, remove Visual Studio building sections
[ https://issues.apache.org/jira/browse/IGNITE-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463788#comment-17463788 ] Igor Sapego commented on IGNITE-15694: -- [~ivandasch] looks good to me. > Document building ODBC driver using cmake, remove Visual Studio building > sections > - > > Key: IGNITE-15694 > URL: https://issues.apache.org/jira/browse/IGNITE-15694 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16187) [ducktests] should use the jackson libs from the distribution.
Sergei Ryzhov created IGNITE-16187: -- Summary: [ducktests] should use the jackson libs from the distribution. Key: IGNITE-16187 URL: https://issues.apache.org/jira/browse/IGNITE-16187 Project: Ignite Issue Type: Test Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Should use the jackson libs from the distribution. They are now used from the DEV version. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16161) Memory leak in BaseQueryContext
[ https://issues.apache.org/jira/browse/IGNITE-16161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16161: - Priority: Blocker (was: Critical) > Memory leak in BaseQueryContext > --- > > Key: IGNITE-16161 > URL: https://issues.apache.org/jira/browse/IGNITE-16161 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha3 >Reporter: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > Attachments: image-2021-12-20-14-37-02-163.png > > > BaseQueryContext contains a number of static fields that are used in order to > store references to internal classes. For example, BaseQueryContext.CLUSTER > which indirectly refers to ignite tables (TableImpl instances). > Unfortunately, these references are not cleared even though the corresponding > ignite node is stopped. > The following trace based on a heap dump illustrates the issue: > !image-2021-12-20-14-37-02-163.png! > This issue can be partially mitigated by clearing ring buffers in > StripedDisruptor, but the right way to fix the issue is a proper approach to > handle static collections in BaseQueryContext. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16184) testTransferLeader is flaky
[ https://issues.apache.org/jira/browse/IGNITE-16184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16184: - Priority: Blocker (was: Critical) > testTransferLeader is flaky > --- > > Key: IGNITE-16184 > URL: https://issues.apache.org/jira/browse/IGNITE-16184 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Blocker > Labels: ignite-3 > Attachments: testTransferLeader.log > > > ItCliServiceTest.testTransferLeader is flaky. Need to find out the root cause. > See attached log. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16186) Possibility of declaring affinity key fields for binary object cache key
[ https://issues.apache.org/jira/browse/IGNITE-16186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Belyaev reassigned IGNITE-16186: --- Assignee: Andrey Belyaev > Possibility of declaring affinity key fields for binary object cache key > > > Key: IGNITE-16186 > URL: https://issues.apache.org/jira/browse/IGNITE-16186 > Project: Ignite > Issue Type: Bug >Reporter: Andrey Belyaev >Assignee: Andrey Belyaev >Priority: Major > > Problem: when binary object key placed in cache, ignite cant declare affinity > key. > TODO: At first cache put of binary object key needed to call of > org.apache.ignite.internal.processors.cache.GridCacheContex#prepareAffinityField -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16186) Possibility of declaring affinity key fields for binary object cache key
Andrey Belyaev created IGNITE-16186: --- Summary: Possibility of declaring affinity key fields for binary object cache key Key: IGNITE-16186 URL: https://issues.apache.org/jira/browse/IGNITE-16186 Project: Ignite Issue Type: Bug Reporter: Andrey Belyaev Problem: when binary object key placed in cache, ignite cant declare affinity key. TODO: At first cache put of binary object key needed to call of org.apache.ignite.internal.processors.cache.GridCacheContex#prepareAffinityField -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16154) Implement (un)marshalling of Externalizable
[ https://issues.apache.org/jira/browse/IGNITE-16154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463699#comment-17463699 ] Roman Puchkovskiy commented on IGNITE-16154: Thanks! > Implement (un)marshalling of Externalizable > --- > > Key: IGNITE-16154 > URL: https://issues.apache.org/jira/browse/IGNITE-16154 > Project: Ignite > Issue Type: Sub-task >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15092) Implement a vacuum
[ https://issues.apache.org/jira/browse/IGNITE-15092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15092: --- Description: During pre-writes some excessive data is written to support tx aborting. This data must be eventually removed. Additionally, tx state map also must be pruned. was: During pre-writes some excessive data is written to support tx aborting. This data must be eventually removed. > Implement a vacuum > -- > > Key: IGNITE-15092 > URL: https://issues.apache.org/jira/browse/IGNITE-15092 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > > During pre-writes some excessive data is written to support tx aborting. > This data must be eventually removed. > Additionally, tx state map also must be pruned. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15721) Effective way of retrieving tables by id.
[
https://issues.apache.org/jira/browse/IGNITE-15721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463686#comment-17463686
]
Semyon Danilov commented on IGNITE-15721:
-
[~ktkale...@gridgain.com] [~ibessonov] thank you fellas for your contribution,
merged to the main branch!
> Effective way of retrieving tables by id.
> ---
>
> Key: IGNITE-15721
> URL: https://issues.apache.org/jira/browse/IGNITE-15721
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha3
>Reporter: Alexander Lapin
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: Configuration, iep-55, ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> h3. Problem
> There are use cases that suppose retrieving configuration entities by id. For
> example retrieving table by id. The only option now is to get all tables with
> further iteration that will check whether a table id matches expected one.
> Things get worse if it's required to get table by id from remote node, e.g.
> {code:java}
> private boolean isTableConfigured(IgniteUuid id) {
> NamedListView directTablesCfg =
> ((DirectConfigurationProperty>)tablesCfg.tables()).directValue();
> // TODO: IGNITE-15721 Need to review this approach after the ticket
> would be fixed.
> // Probably, it won't be required getting configuration of all tables
> from Metastor.
> for (String name : directTablesCfg.namedListKeys()) {
> ExtendedTableView tView =
> (ExtendedTableView)directTablesCfg.get(name);
> if (tView != null && id.equals(IgniteUuid.fromString(tView.id(
> return true;
> }
> return false;
> }
> {code}
> It worth to mention that sometimes, for example in use case mentioned above,
> exact data aren't needed, cause only fact of data absence is important. In
> other words It'll be great not only to have ability to retrieve tables,
> columns, indexes and other named list items by id (in addition to retrieving
> by name) but also check whether required entity exists or not. Both local and
> direct use cases are important.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16182) Move ZookeeperIpFinder to the ignite-extensions
[
https://issues.apache.org/jira/browse/IGNITE-16182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463679#comment-17463679
]
Ignite TC Bot commented on IGNITE-16182:
{panel:title=Branch: [pull/9682/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9682/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6242391buildTypeId=IgniteTests24Java8_RunAll]
> Move ZookeeperIpFinder to the ignite-extensions
> ---
>
> Key: IGNITE-16182
> URL: https://issues.apache.org/jira/browse/IGNITE-16182
> Project: Ignite
> Issue Type: Task
> Components: extensions
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Move TcpDiscoveryZookeeperIpFinder to the ignite-extensions
> The motivation is the exclude dependency log4j(needed for curator), which
> contains
> vulnerabilities CVE-2021-4104 CVE-2019-17571
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing cache read with expiry policy.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Labels: ise (was: )
> GridCacheEntryRemovedException appears in server log when performing cache
> read with expiry policy.
> ---
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction. In this case, the
> keys-loop is interrupted by the NPE ( which is currently not outputting
> anywhere).
> Since ttl updates are not ordered (see IGNITE-305), it is difficult to
> reproduce the real-world problem that this issue could cause, but we
> shouldn't log a weird exception anyway and continue the loop without NPE.
> Reproducer:
> {code:java}
> public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
> private final ListeningTestLogger log = new
> ListeningTestLogger(GridAbstractTest.log);
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setGridLogger(log)
> .setCacheConfiguration(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(REPLICATED)
> );
> }
> @Test
> public void test() throws Exception {
> LogListener lsnr = LogListener.matches("Failed to send TTL update
> request").build();
> log.registerListener(lsnr);
> startGridsMultiThreaded(4);
> Map vals = new TreeMap<>();
> for (int i = 1; i < 10; i++)
> vals.put(i, i);
> jcache(0).putAll(vals);
> assertFalse(lsnr.check());
> long timeout = 20_000L;
> long stopTime = System.currentTimeMillis() + timeout;
> int iter = 0;
> IgniteCache cache = jcache(1).withExpiryPolicy(new
> ExpiryPolicy() {
> @Override public Duration getExpiryForAccess() {
> return new Duration(TimeUnit.MILLISECONDS, timeout);
> }
> @Override public Duration getExpiryForCreation() { return null; }
> @Override public Duration getExpiryForUpdate() { return null; }
> });
> while (System.currentTimeMillis() < stopTime) {
> cache.getAll(vals.keySet());
> assertFalse("iter=" + ++iter, lsnr.check());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16177) Snapshot restore operation may hang if cache contains "empty" partitions
[
https://issues.apache.org/jira/browse/IGNITE-16177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463659#comment-17463659
]
Ignite TC Bot commented on IGNITE-16177:
{panel:title=Branch: [pull/9679/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9679/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Snapshots{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6335238]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotRestoreSelfTest.testRestoreWithEmptyPartitions[Encryption
is disabled] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6335241buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot restore operation may hang if cache contains "empty" partitions
>
>
> Key: IGNITE-16177
> URL: https://issues.apache.org/jira/browse/IGNITE-16177
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Labels: iep-43
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The snapshot restore may hang when some of the cache group partitions have
> not been physically created (for example, there is not enough data in the
> cache).
> Reproducer
> {code:java}
> public class IgniteClusterSnapshotRestoreEmptyPartsTest extends
> IgniteClusterSnapshotRestoreBaseTest {
> @Test
> public void testRestoreWithEmptyPartition() throws Exception {
> // Cache with 1024 partitions.
> CacheConfiguration cacheCfg1 = new
> CacheConfiguration<>(CACHE1);
> // Add only 10 keys (only 10 partitions will be created on the disk).
> IgniteEx ignite = startGridsWithCache(1, 10, Integer::new, cacheCfg1);
> // Snapshot contains only 10 (out of 1024 "affinity" partitions).
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME).get(TIMEOUT);
> ignite.cache(CACHE1).destroy();
> // The restore operation hangs during the "preload" phase.
> ignite.snapshot().restoreSnapshot(SNAPSHOT_NAME, null).get(TIMEOUT);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16154) Implement (un)marshalling of Externalizable
[ https://issues.apache.org/jira/browse/IGNITE-16154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-16154: Summary: Implement (un)marshalling of Externalizable (was: Implement (un)marhalling of Externalizable) > Implement (un)marshalling of Externalizable > --- > > Key: IGNITE-16154 > URL: https://issues.apache.org/jira/browse/IGNITE-16154 > Project: Ignite > Issue Type: Sub-task >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16182) Move ZookeeperIpFinder to the ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-16182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16182: --- Description: Move TcpDiscoveryZookeeperIpFinder to the ignite-extensions The motivation is the exclude dependency log4j(needed for curator), which contains vulnerabilities CVE-2021-4104 CVE-2019-17571 was:Move TcpDiscoveryZookeeperIpFinder to the ignite-extensions > Move ZookeeperIpFinder to the ignite-extensions > --- > > Key: IGNITE-16182 > URL: https://issues.apache.org/jira/browse/IGNITE-16182 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > Labels: ise > Time Spent: 40m > Remaining Estimate: 0h > > Move TcpDiscoveryZookeeperIpFinder to the ignite-extensions > The motivation is the exclude dependency log4j(needed for curator), which > contains > vulnerabilities CVE-2021-4104 CVE-2019-17571 -- This message was sent by Atlassian Jira (v8.20.1#820001)
