[jira] [Commented] (IGNITE-17796) .NET: Services do not work with default interface implementations
[
https://issues.apache.org/jira/browse/IGNITE-17796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620762#comment-17620762
]
Igor Sapego commented on IGNITE-17796:
--
[~ptupitsyn] looks good.
> .NET: Services do not work with default interface implementations
> -
>
> Key: IGNITE-17796
> URL: https://issues.apache.org/jira/browse/IGNITE-17796
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.13
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> The code below throws *"InvalidOperationException: Failed to invoke proxy:
> there is no method 'Greet' in type 'MyService' with 1 arguments"*
> {code}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Services;
> using var ignite = Ignition.Start();
> ignite.GetServices().DeployClusterSingleton("svc", new MyService());
> var svc = ignite.GetServices().GetServiceProxy("svc");
> Console.WriteLine(svc.Greet("foo"));
> public interface IMySvc
> {
> string Greet(object arg) => $"Hello, {arg}!";
> }
> class MyService : IService, IMySvc
> {
> public void Init(IServiceContext context) { }
> public void Execute(IServiceContext context) { }
> public void Cancel(IServiceContext context) { }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17939) .NET: Release build does not fail when dotnetdoc step fails
[
https://issues.apache.org/jira/browse/IGNITE-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620750#comment-17620750
]
Igor Sapego commented on IGNITE-17939:
--
[~ptupitsyn] looks good to me.
> .NET: Release build does not fail when dotnetdoc step fails
> ---
>
> Key: IGNITE-17939
> URL: https://issues.apache.org/jira/browse/IGNITE-17939
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> We should use {code}{code} to fail the build
> when executable fails.
> See https://ant.apache.org/manual/Tasks/exec.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17773) Remove node start/stop/list commands
[ https://issues.apache.org/jira/browse/IGNITE-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17773: --- Fix Version/s: 3.0.0-beta1 > Remove node start/stop/list commands > > > Key: IGNITE-17773 > URL: https://issues.apache.org/jira/browse/IGNITE-17773 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > Now, ignite3 node start/stop/restart managements are done through a special > script that is provided by the distribution. CLI commands: node start, node > stop, node list, and bootstrap now do not make any sense. We have to remove > them because they do not work if a user has started a node with a startup > script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620746#comment-17620746 ] Pavel Tupitsyn commented on IGNITE-17351: - Merged to master: 2a1f7a4ea8d656072b69df7ea36559f705b8e861 > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[
https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620727#comment-17620727
]
Ignite TC Bot commented on IGNITE-17351:
{panel:title=Branch: [pull/10331/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=6849836]]
{panel}
{panel:title=Branch: [pull/10331/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6849552buildTypeId=IgniteTests24Java8_RunAll]
> Java thin: Implement logging
>
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for
> debugging purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17796) .NET: Services do not work with default interface implementations
[
https://issues.apache.org/jira/browse/IGNITE-17796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620602#comment-17620602
]
Ignite TC Bot commented on IGNITE-17796:
{panel:title=Branch: [pull/10335/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=6850135]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6850230]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySegmentationAndConnectionRestoreTest.testConnectionRestore_Coordinator4
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6850226]]
{panel}
{panel:title=Branch: [pull/10335/head] Base: [master] : New Tests
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=6850202]]
* {color:#013220}dll:
ServicesTestFullFooterBinaryArrays.TestDefaultInterfaceMethodOverridden -
PASSED{color}
* {color:#013220}dll: ServicesTestFullFooter.TestDefaultInterfaceMethod -
PASSED{color}
* {color:#013220}dll:
ServicesTestAsyncBinaryArrays.TestDefaultInterfaceMethodOverridden -
PASSED{color}
* {color:#013220}dll:
ServicesTestFullFooterBinaryArrays.TestDefaultInterfaceMethod - PASSED{color}
* {color:#013220}dll:
ServicesTestFullFooter.TestDefaultInterfaceMethodOverridden - PASSED{color}
* {color:#013220}dll: ServicesTestAsync.TestDefaultInterfaceMethod -
PASSED{color}
* {color:#013220}dll: ServicesTest.TestDefaultInterfaceMethodOverridden -
PASSED{color}
* {color:#013220}dll: ServicesTestAsyncBinaryArrays.TestDefaultInterfaceMethod
- PASSED{color}
* {color:#013220}dll: ServicesTestAsync.TestDefaultInterfaceMethodOverridden -
PASSED{color}
* {color:#013220}dll: ServicesTest.TestDefaultInterfaceMethod - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6850235buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Services do not work with default interface implementations
> -
>
> Key: IGNITE-17796
> URL: https://issues.apache.org/jira/browse/IGNITE-17796
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.13
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> The code below throws *"InvalidOperationException: Failed to invoke proxy:
> there is no method 'Greet' in type 'MyService' with 1 arguments"*
> {code}
> using Apache.Ignite.Core;
> using Apache.Ignite.Core.Services;
> using var ignite = Ignition.Start();
> ignite.GetServices().DeployClusterSingleton("svc", new MyService());
> var svc = ignite.GetServices().GetServiceProxy("svc");
> Console.WriteLine(svc.Greet("foo"));
> public interface IMySvc
> {
> string Greet(object arg) => $"Hello, {arg}!";
> }
> class MyService : IService, IMySvc
> {
> public void Init(IServiceContext context) { }
> public void Execute(IServiceContext context) { }
> public void Cancel(IServiceContext context) { }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14999) Support dynamic restoration of encrypted snapshots.
[ https://issues.apache.org/jira/browse/IGNITE-14999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-14999: --- Labels: ise (was: ) > Support dynamic restoration of encrypted snapshots. > --- > > Key: IGNITE-14999 > URL: https://issues.apache.org/jira/browse/IGNITE-14999 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > After manual replacements of encrypted snapshots works, let's enable dynamic > snapshot restoration (`SnapshotRestoreProcess`) > Supposed new general features: > * Dynamic restoration of encrypted snapshot on a running node ( > `IgniteSnapshotManager#restoreSnapshot()` ) > * Validation of encrypted snapshot ( `IgniteSnapshotManager#checkSnapshot()` ) > Same master key is still required. > NOTE: > To restore an encrypted snapshot, we have to read the keys it was encrypted > with. The better place for the is Metastore. But it is currently unreadable > as a simple structure. This ticket suggests holding the keys in > `StoredCacheData`. It always goes together with the data and is included in > snapshot. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17939) .NET: Release build does not fail when dotnetdoc step fails
[
https://issues.apache.org/jira/browse/IGNITE-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17939:
Description:
We should use {code}{code} to fail the build when
executable fails.
See https://ant.apache.org/manual/Tasks/exec.html
was:We should use {code}{code} to fail the build
when executable fails.
> .NET: Release build does not fail when dotnetdoc step fails
> ---
>
> Key: IGNITE-17939
> URL: https://issues.apache.org/jira/browse/IGNITE-17939
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> We should use {code}{code} to fail the build
> when executable fails.
> See https://ant.apache.org/manual/Tasks/exec.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17939) .NET: Release build does not fail when dotnetdoc step fails
Pavel Tupitsyn created IGNITE-17939:
---
Summary: .NET: Release build does not fail when dotnetdoc step
fails
Key: IGNITE-17939
URL: https://issues.apache.org/jira/browse/IGNITE-17939
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.15
We should use {code}{code} to fail the build when
executable fails.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[
https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620470#comment-17620470
]
Ignite TC Bot commented on IGNITE-17351:
{panel:title=Branch: [pull/10331/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Out Of Memory Error ,
xmlReportParsingSurefireParsingFailure
|https://ci.ignite.apache.org/viewLog.html?buildId=6849452]]
{color:#d04437}Java Client{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6849494]]
{color:#d04437}Snapshots{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6849533]]
* IgniteSnapshotTestSuite:
EncryptedSnapshotTest.testStartFromSnapshotFailedWithOtherMasterKey[Encryption
is enabled.] - Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10331/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6849552buildTypeId=IgniteTests24Java8_RunAll]
> Java thin: Implement logging
>
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for
> debugging purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620468#comment-17620468
]
Vyacheslav Koptilin commented on IGNITE-17865:
--
Hello [~shishkovilja],
??As I see, most of time lists of partitions in these messages do not form a
continuous sequence, and even if so, only 2, and less often 3 and more
partitions form continuous sequence. And for two partitions real economy is a
whitespace symbol.??
Let's try to compare the output for the following scenario:
{noformat}
1.
fullPartitions=[4-5, 260-261, 500-501]
fullPartitions=[4, 5, 260, 261, 500, 501]The difference is not so big
for the case when a sequence size is equal to 2
2.
fullPartitions=[1-3, 37, 50-52, 101, 999-1001]
fullPartitions=[1, 2, 3, 37, 50, 51, 52, 101, 999, 1000, 1001]In this
case, the optimized output looks better than non optimized.
{noformat}
You need to take into account, that this output will be printed for each cache,
which should be rebalanced, and each supplier node.
All in all, I don't want to say: "please stop, you should not turn off this
optimization". :) It's up to you.
It seems to me, that even a small optimization is more useful than not having
it at all.
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}
> 2021-08-11 23:12:11.338 [WARN
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:red}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}
> 2021-08-11 23:12:11.338 [WARN
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:red}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.
[ https://issues.apache.org/jira/browse/IGNITE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17937: -- Ignite Flags: (was: Docs Required,Release Notes Required) > [Extensions] Confusing folder appears after running Ignite Extension tests. > --- > > Key: IGNITE-17937 > URL: https://issues.apache.org/jira/browse/IGNITE-17937 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Confusing folder with name sys:IGNITE_HOME appears after running Ignite > Extension tests. > It happens because GridTestUtils#initTestProjectHome method which is > responsible for initializing IGNITE_HOME system property for non Ignite tests > does not work corrctly. > First invocation of U.getIgniteHome() method tries to resolve Ignite Home > path and in case of a failure initializes it with null. > U.setIgniteHome(...) does actually nothing if the previous attempt to resolve > Ignite Home was performed (even if it fails and null was set). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17889) Calcite engine. Avoid full index scans in case of null dynamic parameter
[
https://issues.apache.org/jira/browse/IGNITE-17889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-17889:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Avoid full index scans in case of null dynamic parameter
>
>
> Key: IGNITE-17889
> URL: https://issues.apache.org/jira/browse/IGNITE-17889
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> Currently, queries like:
> {code:java}
> SELECT * FROM tbl WHERE a >= ?
> {code}
> Should return no rows if dynamic parameter is null, but can be downgraded to
> full index scan in case table have index on column {{a}} (ASCENDING order,
> NULLS FIRST).
> We should somehow analyse nulls in search bounds and return empty rows
> iterator for regular field conditions (`=`, `<`, '>`, etc). But also nulls
> should be processed as is in search bounds for conditions like `IS NULL`, `IS
> NOT NULL`, `IS NOT DISTINCT FROM` (the last one not supported currently).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.
[ https://issues.apache.org/jira/browse/IGNITE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-17937: Description: Confusing folder with name sys:IGNITE_HOME appears after running Ignite Extension tests. It happens because GridTestUtils#initTestProjectHome method which is responsible for initializing IGNITE_HOME system property for non Ignite tests does not work corrctly. First invocation of U.getIgniteHome() method tries to resolve Ignite Home path and in case of a failure initializes it with null. U.setIgniteHome(...) does actually nothing if the previous attempt to resolve Ignite Home was performed (even if it fails and null was set). was: Confusing folder with name sys:IGNITE_HOME appears after running Ignite Extension tests. It happens because GridTestUtils#initTestProjectHome method which is responsible for initializing IGNITE_HOME system property for non Ignite tests does not work corrctly. First invocation of U.getIgniteHome() method tries to resolve Ignite Home path and in case of a failure initializes it with null. U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite Home was performed before even if it fails before. > [Extensions] Confusing folder appears after running Ignite Extension tests. > --- > > Key: IGNITE-17937 > URL: https://issues.apache.org/jira/browse/IGNITE-17937 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Confusing folder with name sys:IGNITE_HOME appears after running Ignite > Extension tests. > It happens because GridTestUtils#initTestProjectHome method which is > responsible for initializing IGNITE_HOME system property for non Ignite tests > does not work corrctly. > First invocation of U.getIgniteHome() method tries to resolve Ignite Home > path and in case of a failure initializes it with null. > U.setIgniteHome(...) does actually nothing if the previous attempt to resolve > Ignite Home was performed (even if it fails and null was set). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17938) Different primary nodes can be enlisted in one transaction for the same replication group
[ https://issues.apache.org/jira/browse/IGNITE-17938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17938: --- Labels: ignite-3 (was: ) > Different primary nodes can be enlisted in one transaction for the same > replication group > - > > Key: IGNITE-17938 > URL: https://issues.apache.org/jira/browse/IGNITE-17938 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Before to send a replica request, we try to determine a primary node. If the > replication group is not used before, primary replica is choosing as a > current leader for the replication group and will be enlisted only when the > request is sent and handled. > If several replica requests are handled simultaneously, in the same > circumstances (primary is not enlisted for the replication group), a > coordinator node can try to enlist several different primaries for the group. > Before, we do nothing to resolve this situation, so last primary replaces > previous one. > But the right solution do not allow situation where we have several primaries > for the group in one transaction. Required to check that the primary node is > the same for all requests and throw an exception if this is not right. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17572) Update Ignite dependency: mockserver-netty
[ https://issues.apache.org/jira/browse/IGNITE-17572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17572: --- Description: Update dependency: mockserver-netty 5.11.1 to 5.14.0 > Update Ignite dependency: mockserver-netty > -- > > Key: IGNITE-17572 > URL: https://issues.apache.org/jira/browse/IGNITE-17572 > Project: Ignite > Issue Type: Improvement > Environment: Update dependency: mockserver-netty 5.11.1 to 5.14.0 >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Update dependency: mockserver-netty 5.11.1 to 5.14.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[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
]
Dmitry Pavlov updated IGNITE-16194:
---
Component/s: (was: ise)
> 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: Blocker
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
>
[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
]
Dmitry Pavlov updated IGNITE-16194:
---
Component/s: ise
> 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
> Components: ise
>Affects Versions: 2.11, 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
>
[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
]
Dmitry Pavlov updated IGNITE-16194:
---
Labels: ise (was: )
> 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: Blocker
> Labels: ise
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
>
[jira] [Created] (IGNITE-17938) Different primary nodes can be enlisted in one transaction for the same replication group
Vladislav Pyatkov created IGNITE-17938: -- Summary: Different primary nodes can be enlisted in one transaction for the same replication group Key: IGNITE-17938 URL: https://issues.apache.org/jira/browse/IGNITE-17938 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov Before to send a replica request, we try to determine a primary node. If the replication group is not used before, primary replica is choosing as a current leader for the replication group and will be enlisted only when the request is sent and handled. If several replica requests are handled simultaneously, in the same circumstances (primary is not enlisted for the replication group), a coordinator node can try to enlist several different primaries for the group. Before, we do nothing to resolve this situation, so last primary replaces previous one. But the right solution do not allow situation where we have several primaries for the group in one transaction. Required to check that the primary node is the same for all requests and throw an exception if this is not right. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15074) Fix documentation for support encrypted snapshots
[ https://issues.apache.org/jira/browse/IGNITE-15074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15074: --- Labels: ise (was: ) > Fix documentation for support encrypted snapshots > - > > Key: IGNITE-15074 > URL: https://issues.apache.org/jira/browse/IGNITE-15074 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: ise > Fix For: 2.12 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.
[ https://issues.apache.org/jira/browse/IGNITE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-17937: Description: Confusing folder with name sys:IGNITE_HOME appears after running Ignite Extension tests. It happens because GridTestUtils#initTestProjectHome method which is responsible for initializing IGNITE_HOME system property for non Ignite tests does not work corrctly. First invocation of U.getIgniteHome() method tries to resolve Ignite Home path and in case of a failure initializes it with null. U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite Home was performed before even if it fails before. was: Confusing folder with name sys:IGNITE_HOME appears after running Ignite Extension tests. It happens because GridTestUtils#initTestProjectHome method which is responsible for initializing IGNITE_HOME system property for non Ignite tests does not work corrctly. First invocation of U.getIgniteHome() method tries to resolve Ignite Home path and in case of a failure initializes it with null. U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite Home was performed before even if it fails. > [Extensions] Confusing folder appears after running Ignite Extension tests. > --- > > Key: IGNITE-17937 > URL: https://issues.apache.org/jira/browse/IGNITE-17937 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Confusing folder with name sys:IGNITE_HOME appears after running Ignite > Extension tests. > It happens because GridTestUtils#initTestProjectHome method which is > responsible for initializing IGNITE_HOME system property for non Ignite tests > does not work corrctly. > First invocation of U.getIgniteHome() method tries to resolve Ignite Home > path and in case of a failure initializes it with null. > U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite > Home was performed before even if it fails before. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.
[ https://issues.apache.org/jira/browse/IGNITE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-17937: --- Assignee: Mikhail Petrov > [Extensions] Confusing folder appears after running Ignite Extension tests. > --- > > Key: IGNITE-17937 > URL: https://issues.apache.org/jira/browse/IGNITE-17937 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Confusing folder with name sys:IGNITE_HOME appears after running Ignite > Extension tests. > It happens because GridTestUtils#initTestProjectHome method which is > responsible for initializing IGNITE_HOME system property for non Ignite tests > does not work corrctly. > First invocation of U.getIgniteHome() method tries to resolve Ignite Home > path and in case of a failure initializes it with null. > U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite > Home was performed before even if it fails before. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.
Mikhail Petrov created IGNITE-17937: --- Summary: [Extensions] Confusing folder appears after running Ignite Extension tests. Key: IGNITE-17937 URL: https://issues.apache.org/jira/browse/IGNITE-17937 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Confusing folder with name sys:IGNITE_HOME appears after running Ignite Extension tests. It happens because GridTestUtils#initTestProjectHome method which is responsible for initializing IGNITE_HOME system property for non Ignite tests does not work corrctly. First invocation of U.getIgniteHome() method tries to resolve Ignite Home path and in case of a failure initializes it with null. U.setIgniteHome(...) does actually nothing if an attempt to resolve Ignite Home was performed before even if it fails. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17907) Extract Table and Storage configuration into corresponding modules
[
https://issues.apache.org/jira/browse/IGNITE-17907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17907:
-
Fix Version/s: 3.0.0-beta1
(was: 3.0.0-beta2)
> Extract Table and Storage configuration into corresponding modules
> --
>
> Key: IGNITE-17907
> URL: https://issues.apache.org/jira/browse/IGNITE-17907
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is part of the work related to removing configuration from the
> ignite-api module. The following configurations should be moved:
> * Table configuration to {{ignite-schema}}.
> * Storage configuration to {{ignite-storage-api}}. However, this may
> currently be impossible, because Table configuration depends on the storage
> configuration, {{ignite-storage-api}} already depends on the
> {{ignite-schema}} module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17572) Update Ignite dependency: mockserver-netty
[ https://issues.apache.org/jira/browse/IGNITE-17572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17572: --- Fix Version/s: 2.15 > Update Ignite dependency: mockserver-netty > -- > > Key: IGNITE-17572 > URL: https://issues.apache.org/jira/browse/IGNITE-17572 > Project: Ignite > Issue Type: Improvement > Environment: Update dependency: mockserver-netty 5.11.1 to 5.14.0 >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17572) Update Ignite dependency: mockserver-netty
[
https://issues.apache.org/jira/browse/IGNITE-17572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620433#comment-17620433
]
Ignite TC Bot commented on IGNITE-17572:
{panel:title=Branch: [pull/10333/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10333/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=6842843buildTypeId=IgniteTests24Java8_RunAll]
> Update Ignite dependency: mockserver-netty
> --
>
> Key: IGNITE-17572
> URL: https://issues.apache.org/jira/browse/IGNITE-17572
> Project: Ignite
> Issue Type: Improvement
> Environment: Update dependency: mockserver-netty 5.11.1 to 5.14.0
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17926) Update Ignite dependency: Jetty
[
https://issues.apache.org/jira/browse/IGNITE-17926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620431#comment-17620431
]
Ignite TC Bot commented on IGNITE-17926:
{panel:title=Branch: [pull/10329/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10329/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=6842956buildTypeId=IgniteTests24Java8_RunAll]
> Update Ignite dependency: Jetty
> ---
>
> Key: IGNITE-17926
> URL: https://issues.apache.org/jira/browse/IGNITE-17926
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Update Jetty dependency 9.4.43.v20210629 to 9.4.49.v20220914
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16014) Add configuration for snapshot thread pool size
[ https://issues.apache.org/jira/browse/IGNITE-16014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16014: --- Labels: iep-43 ise ise.lts (was: iep-43 ise.lts) > Add configuration for snapshot thread pool size > --- > > Key: IGNITE-16014 > URL: https://issues.apache.org/jira/browse/IGNITE-16014 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Critical > Labels: iep-43, ise, ise.lts > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, the snapshot thread pool size is hardcoded with a value of 4. This > may lead to high disk utilization resources on slow SAS hard drives. The user > must be able to configure the snapshot thread pool size must be and this > thread pool also must be available for monitoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351 ]
Pavel Tupitsyn deleted comment on IGNITE-17351:
-
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10331/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Build]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6849296]]
{color:#d04437} Build{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6849241]]
{panel}
{panel:title=Branch: [pull/10331/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6849353buildTypeId=IgniteTests24Java8_RunAll]
> Java thin: Implement logging
>
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for
> debugging purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17890) Calcite engine. Support index scan on boolean field
[
https://issues.apache.org/jira/browse/IGNITE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620401#comment-17620401
]
Ignite TC Bot commented on IGNITE-17890:
{panel:title=Branch: [pull/10332/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10332/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6842509]]
* {color:#013220}IgniteCalciteTestSuite:
IndexScanlIntegrationTest.testScanBooleanField - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6842589buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Support index scan on boolean field
> ---
>
> Key: IGNITE-17890
> URL: https://issues.apache.org/jira/browse/IGNITE-17890
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if table has index on boolean field it can't be used, since
> queries like
> {code:java}
> SELECT * FROM tbl WHERE a = TRUE
> {code}
> Simplified by Calcite to
> {code:java}
> SELECT * FROM tbl WHERE a {code}
> Condition `{{{}a{}}}` is not supported for building search bounds (see
> \{{RexUtils.isSupportedTreeComparison()}}) and such an index can't be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[
https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620397#comment-17620397
]
Ignite TC Bot commented on IGNITE-17351:
{panel:title=Branch: [pull/10331/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Build]{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6849296]]
{color:#d04437} Build{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6849241]]
{panel}
{panel:title=Branch: [pull/10331/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6849353buildTypeId=IgniteTests24Java8_RunAll]
> Java thin: Implement logging
>
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for
> debugging purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17671) Implement BinaryTuple inlining in a sorted index B+Tree
[ https://issues.apache.org/jira/browse/IGNITE-17671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17671: - Fix Version/s: 3.0.0-beta1 > Implement BinaryTuple inlining in a sorted index B+Tree > --- > > Key: IGNITE-17671 > URL: https://issues.apache.org/jira/browse/IGNITE-17671 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1, 3.0.0-beta2 > > Time Spent: 7.5h > Remaining Estimate: 0h > > In a simple implementation, instead of a *BinaryTuple*, we store its link > from the *FreeList* in the key, this is not optimal and we need to inline the > *BinaryTuple* in the key, for starters, you can see how to do this in 2.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart/node_join by itself
[
https://issues.apache.org/jira/browse/IGNITE-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-17738:
Assignee: Maxim Muzafarov
> Cluster must be able to fix the inconsistency on restart/node_join by itself
>
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java,
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's
> possible to have PDS inconsistent (primary partitions may contain operations
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest
> LWM for every partition.
> Most likely, a primary will be chosen as a rebalance source, but the data
> after the LWM will not be rebalanced. So, all updates between LWM and HWM
> will not be synchronized.
> See [^PartialHistoricalRebalanceTest.java]
> Such partition may be rebalanced correctly "later" in case of full rebalance
> will be triggered sometime.
> 2) In case LWM is the same on primary and backup, rebalance will be skipped
> for such partition.
> See [^SkippedRebalanceBecauseOfTheSameLwmTest.java]
> Proposals:
> 1) Cheap fix
> A possible solution for the case when the cluster failed and restarted (same
> baseline) is to fix the counters automatically (when cluster composition is
> equal to the baseline specified before the crash).
> Counters should be set as
> - HWM at primary and as LWM at backups for caches with 2+ backups,
> - LWM at primary and as HWM at backups for caches with a single backup.
> 2) Correct fix
> Rebalance must honor whole counter state (LWM, HWM, gaps).
> 2.0) Primary HWM must be set to the highest HWM across the copies to avoid
> reapplying of already applied update counters on backups.
> 2.1) In case when WAL is available all entries between LWM and HWM
> (including) must be rebalanced to other nodes where they are required.
> Even from backups to the primary.
> 2.2) Full rebalance must be restricted when it causes any updates loss.
> For example, it's
> - ok to replace B with A when
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120],
> because A contains whole B.
> - NOT ok to replace B with A when
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111],
> hwm={*}148{*}],
> when update *142* will be lost.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart/node_join by itself
[
https://issues.apache.org/jira/browse/IGNITE-17738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-17738:
-
Fix Version/s: 2.15
> Cluster must be able to fix the inconsistency on restart/node_join by itself
>
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.15
>
> Attachments: PartialHistoricalRebalanceTest.java,
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's
> possible to have PDS inconsistent (primary partitions may contain operations
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest
> LWM for every partition.
> Most likely, a primary will be chosen as a rebalance source, but the data
> after the LWM will not be rebalanced. So, all updates between LWM and HWM
> will not be synchronized.
> See [^PartialHistoricalRebalanceTest.java]
> Such partition may be rebalanced correctly "later" in case of full rebalance
> will be triggered sometime.
> 2) In case LWM is the same on primary and backup, rebalance will be skipped
> for such partition.
> See [^SkippedRebalanceBecauseOfTheSameLwmTest.java]
> Proposals:
> 1) Cheap fix
> A possible solution for the case when the cluster failed and restarted (same
> baseline) is to fix the counters automatically (when cluster composition is
> equal to the baseline specified before the crash).
> Counters should be set as
> - HWM at primary and as LWM at backups for caches with 2+ backups,
> - LWM at primary and as HWM at backups for caches with a single backup.
> 2) Correct fix
> Rebalance must honor whole counter state (LWM, HWM, gaps).
> 2.0) Primary HWM must be set to the highest HWM across the copies to avoid
> reapplying of already applied update counters on backups.
> 2.1) In case when WAL is available all entries between LWM and HWM
> (including) must be rebalanced to other nodes where they are required.
> Even from backups to the primary.
> 2.2) Full rebalance must be restricted when it causes any updates loss.
> For example, it's
> - ok to replace B with A when
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120],
> because A contains whole B.
> - NOT ok to replace B with A when
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111],
> hwm={*}148{*}],
> when update *142* will be lost.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17053) Incorrect configuration of spring-data example
[
https://issues.apache.org/jira/browse/IGNITE-17053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620358#comment-17620358
]
Ilya Shishkov commented on IGNITE-17053:
[~mpetrov] , can you take a look please?
> Incorrect configuration of spring-data example
> --
>
> Key: IGNITE-17053
> URL: https://issues.apache.org/jira/browse/IGNITE-17053
> Project: Ignite
> Issue Type: Bug
> Components: extensions, springdata
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: SpringDataExamples.patch
>
>
> After removing of spring-data-2.2-ext, {{SpringDataExample}} will fail to
> start because of incorrect path to XML-configuration [1], and incorrect FQDN
> of Person class in XML-configuration [2].
> Fix is simple (see, [^SpringDataExamples.patch]) but it would be perfect to
> add tests for examples similarly to tests of examples in Ignite.
> *Links:*
> #
> [https://github.com/apache/ignite-extensions/blob/master/modules/spring-data-ext/examples/src/main/java/org/apache/ignite/springdata/examples/SpringApplicationConfiguration.java#L51]
> #
> [https://github.com/apache/ignite-extensions/blob/master/modules/spring-data-ext/examples/config/example-spring-data.xml#L57]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17935) Finish implementation of RAFT snapshot streamer
[ https://issues.apache.org/jira/browse/IGNITE-17935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-17935: --- Epic Link: IGNITE-17774 > Finish implementation of RAFT snapshot streamer > --- > > Key: IGNITE-17935 > URL: https://issues.apache.org/jira/browse/IGNITE-17935 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Implementation is started in IGNITE-17083, but the task turned out to be too > big for one PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17820) Ignite 3. SQL. Add native support for SEARCH/SARG operator
[
https://issues.apache.org/jira/browse/IGNITE-17820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17820:
-
Fix Version/s: 3.0.0-beta1
(was: 3.0.0-beta2)
> Ignite 3. SQL. Add native support for SEARCH/SARG operator
> --
>
> Key: IGNITE-17820
> URL: https://issues.apache.org/jira/browse/IGNITE-17820
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite, ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, Calcite compose some field conditions to {{SEARCH/SARG}} operator
> (for example: {{field IN (scalar)}}, {{field <> ...}}, {{field = value1 OR
> field = value2}}, etc). This operator is not supported natively by Ignite
> Calcite engine and converted back to original expression using
> {{RexUtil.expandSearch}} method on the {{RexToLixTranslator}} phase.
> Such behavior forces Ignite to use full table scan instead of indexes in
> some cases. For example, if {{field}} is indexed, with {{field IN (1, 2)}}
> condition usually is much faster to scan index for 2 values, then full scan
> table and filter out results. For {{OR}} operator {{OrToUnion}} rule can't be
> applied and there will be full table scan again.
> We should support index traversing using SEARCH/SARG operator.
> Alternatively we can convert {{SEARCH/SARG}} to {{UNIONs}} (similarly to
> {{OrToUnion}} rule), but this approach will extend plan search space a lot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15609) Calcite. Error WHERE clause must be a condition.
[
https://issues.apache.org/jira/browse/IGNITE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620344#comment-17620344
]
Yury Gerzhedovich commented on IGNITE-15609:
[~zstan] , LGTM
> Calcite. Error WHERE clause must be a condition.
>
>
> Key: IGNITE-15609
> URL: https://issues.apache.org/jira/browse/IGNITE-15609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {noformat}
> statement ok
> CREATE TABLE item(i_manufact INTEGER)
> query I
> SELECT * FROM item i1 WHERE (SELECT count(*) AS item_cnt FROM item WHERE
> (i_manufact = i1.i_manufact AND i_manufact=3) OR (i_manufact = i1.i_manufact
> AND i_manufact=3)) ORDER BY 1 LIMIT 100;
>
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 30 to
> line 1, column 167: WHERE clause must be a condition
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4350)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4334)
> {noformat}
> {noformat}
> /subquery/scalar/test_tpcds_correlated_subquery.test[_ignore]
> {noformat}
> tested with mysql, all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15609) Calcite. Error WHERE clause must be a condition.
[
https://issues.apache.org/jira/browse/IGNITE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15609:
---
Labels: calcite calcite2-required calcite3-required ignite-3 (was: calcite
calcite2-required calcite3-required)
> Calcite. Error WHERE clause must be a condition.
>
>
> Key: IGNITE-15609
> URL: https://issues.apache.org/jira/browse/IGNITE-15609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {noformat}
> statement ok
> CREATE TABLE item(i_manufact INTEGER)
> query I
> SELECT * FROM item i1 WHERE (SELECT count(*) AS item_cnt FROM item WHERE
> (i_manufact = i1.i_manufact AND i_manufact=3) OR (i_manufact = i1.i_manufact
> AND i_manufact=3)) ORDER BY 1 LIMIT 100;
>
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 30 to
> line 1, column 167: WHERE clause must be a condition
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4350)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4334)
> {noformat}
> {noformat}
> /subquery/scalar/test_tpcds_correlated_subquery.test[_ignore]
> {noformat}
> tested with mysql, all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15609) Calcite. Error WHERE clause must be a condition.
[
https://issues.apache.org/jira/browse/IGNITE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15609:
---
Fix Version/s: 3.0.0-beta2
> Calcite. Error WHERE clause must be a condition.
>
>
> Key: IGNITE-15609
> URL: https://issues.apache.org/jira/browse/IGNITE-15609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required
> Fix For: 3.0.0-beta2
>
>
> {noformat}
> statement ok
> CREATE TABLE item(i_manufact INTEGER)
> query I
> SELECT * FROM item i1 WHERE (SELECT count(*) AS item_cnt FROM item WHERE
> (i_manufact = i1.i_manufact AND i_manufact=3) OR (i_manufact = i1.i_manufact
> AND i_manufact=3)) ORDER BY 1 LIMIT 100;
>
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 30 to
> line 1, column 167: WHERE clause must be a condition
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4350)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4334)
> {noformat}
> {noformat}
> /subquery/scalar/test_tpcds_correlated_subquery.test[_ignore]
> {noformat}
> tested with mysql, all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17859) Update indexes on data modifications
[
https://issues.apache.org/jira/browse/IGNITE-17859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17859:
-
Fix Version/s: 3.0.0-beta1
> Update indexes on data modifications
>
>
> Key: IGNITE-17859
> URL: https://issues.apache.org/jira/browse/IGNITE-17859
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h3. Motivation
> For the sake of better performance and common sense, it is necessary to
> integrate indexes into data manipulation flow, which implies
> * Integrating indexes into the process of efficient evaluation keys to
> rowsIds both within pure read/scan operations and as part of modification
> operations in order to find proper rowId of a row to be modified.
> * Integrating indexes into the process of data modification itself, meaning
> that not only data should be updated but also all corresponding indexes
> should be populated with updated entries along with cleanup on transaction
> rollback.
> Given Jira issue is about second part.
> *Definition* *of Done*
> * All indexes with relevant schema version are populated with modified rows.
> * All pending index entries are removed on tx rollback.
> h3. Implementation Notes
> # Seems, that it has sense to introduce new Index abstractions that will
> manage update logic internally. Something like following:
> ** Index
> ** HashIndex extends Index
> ** HashUniqueIndex extends HashIndex
> ** SortedIndex extneds Index
> ** SorteUniquedIndex extneds SortedIndex
> # In order to define which indexes to update both during update itself or
> during rollback it'll be useful to add extra parameter _schemaVersion_ to
> each operation enlisted into transaction. All in all, that will allow to
> select only proper set of indexes with relevant schema versions.
> # During transaction rollback it'll be necessary to cleanup outdated
> pending entries that were touched during tx lifetime.
> h4. More details about *first* item.
> Index itself may declare update() and other methods that will have
> index-type-specific lock management and uniqueness processing logic, e.g. for
> HashIndex.update following is suggested:
> {code:java}
> @Override
> public CompletableFuture update(UUID txId, TxState txState, Tuple oldRow,
> Tuple newRow, VersionChain rowId) {
> Tuple oldVal = oldRow == Tuple.TOMBSTONE ? Tuple.TOMBSTONE :
> oldRow.select(col);
> Tuple newVal = newRow == Tuple.TOMBSTONE ? Tuple.TOMBSTONE :
> newRow.select(col);
> List futs = new ArrayList<>();
> if (!oldVal.equals(newVal)) {
> if (oldVal.length() > 0) {
> Lock lock0 = lockTable.getOrAddEntry(oldVal);
> txState.addLock(lock0);
> futs.add(lock0.acquire(txId, LockMode.IX));
> // Do not remove bookmarks due to multi-versioning.
> }
> if (newVal.length() > 0) {
> Lock lock0 = lockTable.getOrAddEntry(newVal);
> txState.addLock(lock0);
> futs.add(lock0.acquire(txId, LockMode.IX).thenAccept(ignored0 -> {
> if (index.insert(newVal, rowId)) {
> txState.addUndo(() -> index.remove(newVal, rowId));
> }
> }));
> }
> }
> return CompletableFuture.allOf(futs.toArray(new CompletableFuture[0]));
> } {code}
> Further details could be found in
> [https://github.com/ascherbakoff/ai3-txn-mvp]
> Detailed lock management design is described in [IEP-91-Locking
> model|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Lockingmodel]
> See index related sections, e.g. for HashIndex following lock flow is
> suggested:
> {code:java}
> Non-unique locks
> // scan
> S_commit(key)
> // insert
> IX_commit(key)
> // delete
> IX_commit(key) {code}
> h4. More details about *third* item.
> Please see cleanup flow described in
> https://issues.apache.org/jira/browse/IGNITE-17673
>
> It might have sense to consider all three items as separate tickets.
> It also worth to mention that index modification is triggered from
> PartitionListener
> * handleUpdateCommand
> * handleUpdateAllCommand
> * handleTxCleanupCommand
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans
[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17748:
-
Fix Version/s: 3.0.0-beta1
> Enrich InternalTable.scan API in order to support index scans
> -
>
> Key: IGNITE-17748
> URL: https://issues.apache.org/jira/browse/IGNITE-17748
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h3. Motivation
> SQL engine might specify index to use for scanning data along with some
> additional parameters like lower/upper bounds, including/excluding such
> bounds, columns to include etc. All in all we should enrich InternalTable
> scan api and provide corresponding data propagation logic.
> h3. Definition of Done
> *1.* InternalTable scan API has following method for both hash and sorted
> indexes scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code}
> and following method for sorted index scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, @Nullable BinaryTuple leftBound, @Nullable BinaryTuple
> rightBound, int flags, BitSet columnsToInclude) {code}
> Please check org.apache.ignite.internal.storage.index.SortedIndexStorage#scan
> for flags explanation, briefly
> {code:java}
> flags Control flags. {@link #GREATER} | {@link #LESS} by default. Other
> available values are {@link #GREATER_OR_EQUAL}, {@link #LESS_OR_EQUAL}.{code}
> *2.* Besides API itself corresponding scan-meta should be propagated to
> PartitionReplicaListener, so that some changes are also expected within
> ScanRetrieveBatchReplicaRequest. Please, pay attention that, that there's,
> probably, no sense in propagation same scan-meta within every
> ScanRetrieveBatchReplicaRequest, we might do it only wihtin initial request.
> *3.* Proper index is chosen. See optional indexId param and proper method of
> either IndexStorage or specific SortedIndexStorage is used.
> h3. Implementation Notes
> Mainly it's all specified in the section above. Seems that there's only one
> caveat left, however, non trivial one - BinaryRow to Binary tuple convertion,
> schema involved.
> h3. UPD:
> As was discussed, indexId will be always specified so that tables internals
> will never select PK-index or any other by themselves, so that @Nullable UUID
> indexId is now @NotNull UUID indexId.
>
> Besides API extension itself, it's required to build a bridge between
> https://issues.apache.org/jira/browse/IGNITE-17655 and internalTable.scan
> API, meaaning that it's required to create implementations for sql index
> interfaces introduced in 17655 that will propagate index scans to
> corresponding internalTable.scan API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17330) Support RO TX by SQL
[ https://issues.apache.org/jira/browse/IGNITE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17330: - Fix Version/s: 3.0.0-beta1 > Support RO TX by SQL > > > Key: IGNITE-17330 > URL: https://issues.apache.org/jira/browse/IGNITE-17330 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > SQL use RW transaction mode. It's not efficient in case we need just read > consistent data. > After implementing IGNITE-17260 we should add support RO transaction for SQL > queries. Seems required just use transaction method with timestamp > (org.apache.ignite.hlc.HybridClock#now) as parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode
[ https://issues.apache.org/jira/browse/IGNITE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17813: - Fix Version/s: 3.0.0-beta1 > Sql. Introduce sorted reducer for IndexScanNode > --- > > Key: IGNITE-17813 > URL: https://issues.apache.org/jira/browse/IGNITE-17813 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > This task is derived from IGNITE-17655 to reduce its scope. > Currently, IgniteScanNode reads partition after partition which, obviously, > breaks the sorting order. We need to introduce wrapping cursor, which accepts > open cursors for every partition, and produce the sorted output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17612) Sql. Fix TableScanNode rows propagation.
[ https://issues.apache.org/jira/browse/IGNITE-17612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17612: - Fix Version/s: 3.0.0-beta1 > Sql. Fix TableScanNode rows propagation. > > > Key: IGNITE-17612 > URL: https://issues.apache.org/jira/browse/IGNITE-17612 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > Because of a poor performance of current transactional protocol, several sql > tests was disabled under this ticked. Need to enable those tests after new > protocol will be merged to main. Also seems we have bug in TableScanNode > implementation, no rows are propagated while it still needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15609) Calcite. Error WHERE clause must be a condition.
[
https://issues.apache.org/jira/browse/IGNITE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-15609:
---
Assignee: Evgeny Stanilovsky
> Calcite. Error WHERE clause must be a condition.
>
>
> Key: IGNITE-15609
> URL: https://issues.apache.org/jira/browse/IGNITE-15609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required
>
> {noformat}
> statement ok
> CREATE TABLE item(i_manufact INTEGER)
> query I
> SELECT * FROM item i1 WHERE (SELECT count(*) AS item_cnt FROM item WHERE
> (i_manufact = i1.i_manufact AND i_manufact=3) OR (i_manufact = i1.i_manufact
> AND i_manufact=3)) ORDER BY 1 LIMIT 100;
>
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 30 to
> line 1, column 167: WHERE clause must be a condition
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4350)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4334)
> {noformat}
> {noformat}
> /subquery/scalar/test_tpcds_correlated_subquery.test[_ignore]
> {noformat}
> tested with mysql, all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17936) Change type of partition id to short
[ https://issues.apache.org/jira/browse/IGNITE-17936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17936: --- Description: Using of integer as a portion id turn out redundant, because an amount of partition is significantly less and fit in the short type. This modification has already done in the partition storage, but integer (partition id) is still using everywhere in code. Need to replace Integer partition id to Short one. Also, required to change type of partitions property in the table configuration (TableConfigurationSchema#partitions) was: Using of integer as a portion id turn out redundant, because an amount of partition is significantly less and fit in the short type. This modification has already done in the partition storage, but integer (partition id) is still using everywhere in code. Need to replace Integer partition id to Short one. > Change type of partition id to short > > > Key: IGNITE-17936 > URL: https://issues.apache.org/jira/browse/IGNITE-17936 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Using of integer as a portion id turn out redundant, because an amount of > partition is significantly less and fit in the short type. This modification > has already done in the partition storage, but integer (partition id) is > still using everywhere in code. > Need to replace Integer partition id to Short one. > Also, required to change type of partitions property in the table > configuration (TableConfigurationSchema#partitions) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17936) Change type of partition id to short
Vladislav Pyatkov created IGNITE-17936: -- Summary: Change type of partition id to short Key: IGNITE-17936 URL: https://issues.apache.org/jira/browse/IGNITE-17936 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov Using of integer as a portion id turn out redundant, because an amount of partition is significantly less and fit in the short type. This modification has already done in the partition storage, but integer (partition id) is still using everywhere in code. Need to replace Integer partition id to Short one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17869) Create a basic glossary for AI 3
[ https://issues.apache.org/jira/browse/IGNITE-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17869: - Fix Version/s: 3.0.0-beta2 > Create a basic glossary for AI 3 > > > Key: IGNITE-17869 > URL: https://issues.apache.org/jira/browse/IGNITE-17869 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17935) Finish implementation of RAFT snapshot streamer
Roman Puchkovskiy created IGNITE-17935: -- Summary: Finish implementation of RAFT snapshot streamer Key: IGNITE-17935 URL: https://issues.apache.org/jira/browse/IGNITE-17935 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 Implementation is started in IGNITE-17083, but the task turned out to be too big for one PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17934) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
[ https://issues.apache.org/jira/browse/IGNITE-17934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky resolved IGNITE-17934. - Resolution: Duplicate > Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. > --- > > Key: IGNITE-17934 > URL: https://issues.apache.org/jira/browse/IGNITE-17934 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Previously blocking fut.join() contains in SchemaManager#tableSchema after > refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary > to remove blocking approach. > [1] > https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17933) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
[ https://issues.apache.org/jira/browse/IGNITE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky resolved IGNITE-17933. - Resolution: Duplicate > Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. > --- > > Key: IGNITE-17933 > URL: https://issues.apache.org/jira/browse/IGNITE-17933 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Previously blocking fut.join() contains in SchemaManager#tableSchema after > refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary > to remove blocking approach. > [1] > https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17932) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
[ https://issues.apache.org/jira/browse/IGNITE-17932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky resolved IGNITE-17932. - Resolution: Duplicate > Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. > --- > > Key: IGNITE-17932 > URL: https://issues.apache.org/jira/browse/IGNITE-17932 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Previously blocking fut.join() contains in SchemaManager#tableSchema after > refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary > to remove blocking approach. > [1] > https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17934) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
Evgeny Stanilovsky created IGNITE-17934: --- Summary: Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. Key: IGNITE-17934 URL: https://issues.apache.org/jira/browse/IGNITE-17934 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 3.0.0-alpha5 Reporter: Evgeny Stanilovsky Previously blocking fut.join() contains in SchemaManager#tableSchema after refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary to remove blocking approach. [1] https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17933) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
Evgeny Stanilovsky created IGNITE-17933: --- Summary: Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. Key: IGNITE-17933 URL: https://issues.apache.org/jira/browse/IGNITE-17933 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 3.0.0-alpha5 Reporter: Evgeny Stanilovsky Previously blocking fut.join() contains in SchemaManager#tableSchema after refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary to remove blocking approach. [1] https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17931) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
Evgeny Stanilovsky created IGNITE-17931: --- Summary: Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. Key: IGNITE-17931 URL: https://issues.apache.org/jira/browse/IGNITE-17931 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 3.0.0-alpha5 Reporter: Evgeny Stanilovsky Previously blocking fut.join() contains in SchemaManager#tableSchema after refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary to remove blocking approach. [1] https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17932) Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored.
Evgeny Stanilovsky created IGNITE-17932: --- Summary: Blocking code inside SchemaRegistryImpl#schema(int), need to be refactored. Key: IGNITE-17932 URL: https://issues.apache.org/jira/browse/IGNITE-17932 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 3.0.0-alpha5 Reporter: Evgeny Stanilovsky Previously blocking fut.join() contains in SchemaManager#tableSchema after refactoring it moves into SchemaRegistryImpl#schema(int) [1], it`s necessary to remove blocking approach. [1] https://github.com/apache/ignite-3/blob/7b0b3395de97db09896272e03322bba302c0b556/modules/schema/src/main/java/org/apache/ignite/internal/schema/registry/SchemaRegistryImpl.java#L93 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17911) Wal isn't enabled for some caches after cancelling of rebalance
[
https://issues.apache.org/jira/browse/IGNITE-17911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17911:
-
Fix Version/s: 2.15
> Wal isn't enabled for some caches after cancelling of rebalance
> ---
>
> Key: IGNITE-17911
> URL: https://issues.apache.org/jira/browse/IGNITE-17911
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> WAL can be disabled during a rebalance if a node does not own any partitions.
> When stopping a node, a shutdown hook is used, which calls
> {{IgniteionEx#stop}} with the {{cancel}} flag set to {{true}}. This wakes up
> the checkpoint thread and starts doing a checkpoint, which creates a
> checkpoint start marker. However, since the {{cancel}} flag was set to
> {{true}}, {{Checkpointer#writePages}} finishes immediately and the checkpoint
> end marker is not created.
> This means that we have not enabled WAL again, since the rebalance was
> interrupted, and we created a checkpoint start marker, but not the end
> marker. This leads to the node being started in maintenance mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17911) Wal isn't enabled for some caches after cancelling of rebalance
[
https://issues.apache.org/jira/browse/IGNITE-17911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17911:
-
Fix Version/s: (was: 3.0.0-beta2)
> Wal isn't enabled for some caches after cancelling of rebalance
> ---
>
> Key: IGNITE-17911
> URL: https://issues.apache.org/jira/browse/IGNITE-17911
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> WAL can be disabled during a rebalance if a node does not own any partitions.
> When stopping a node, a shutdown hook is used, which calls
> {{IgniteionEx#stop}} with the {{cancel}} flag set to {{true}}. This wakes up
> the checkpoint thread and starts doing a checkpoint, which creates a
> checkpoint start marker. However, since the {{cancel}} flag was set to
> {{true}}, {{Checkpointer#writePages}} finishes immediately and the checkpoint
> end marker is not created.
> This means that we have not enabled WAL again, since the rebalance was
> interrupted, and we created a checkpoint start marker, but not the end
> marker. This leads to the node being started in maintenance mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17330) Support RO TX by SQL
[ https://issues.apache.org/jira/browse/IGNITE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-17330: Ignite Flags: (was: Docs Required,Release Notes Required) > Support RO TX by SQL > > > Key: IGNITE-17330 > URL: https://issues.apache.org/jira/browse/IGNITE-17330 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > SQL use RW transaction mode. It's not efficient in case we need just read > consistent data. > After implementing IGNITE-17260 we should add support RO transaction for SQL > queries. Seems required just use transaction method with timestamp > (org.apache.ignite.hlc.HybridClock#now) as parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17330) Support RO TX by SQL
[ https://issues.apache.org/jira/browse/IGNITE-17330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-17330: --- Assignee: Evgeny Stanilovsky > Support RO TX by SQL > > > Key: IGNITE-17330 > URL: https://issues.apache.org/jira/browse/IGNITE-17330 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > SQL use RW transaction mode. It's not efficient in case we need just read > consistent data. > After implementing IGNITE-17260 we should add support RO transaction for SQL > queries. Seems required just use transaction method with timestamp > (org.apache.ignite.hlc.HybridClock#now) as parameter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17435) Fix Datastreamer documentation.
[ https://issues.apache.org/jira/browse/IGNITE-17435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-17435: -- Description: The doc should mention something like: Setting the `allowOverwrite` property to false is best used for initial data load on a cluster with stable topology. When cluster works under load, some actions may cause issues with data consistency. To avoid them: * Avoid having the same keys repeating in the data being streamed; * Avoid concurrent updates of the cache that is being streamed into; * Avoid streane fauilure. * Avoid snapshotting. Also, the docs should note streamer's limitations and traits. Additionally, we may warn into log that datastreamer should successfully finish. was: The doc should mention something like: Setting the `allowOverwrite` property to false is best used for initial data load on a cluster with stable topology. When cluster works under load, some actions may cause issues with data consistency. To avoid them: * Avoid having the same keys repeating in the data being streamed; * Avoid concurrent updates of the cache that is being streamed into; * Avoid streane fauilure. * Avoid snapshotting. Also, the docs should note streamer's limitations and traits. > Fix Datastreamer documentation. > --- > > Key: IGNITE-17435 > URL: https://issues.apache.org/jira/browse/IGNITE-17435 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > The doc should mention something like: > Setting the `allowOverwrite` property to false is best used for initial data > load on a cluster with stable topology. When cluster works under load, some > actions may cause issues with data consistency. To avoid them: > * Avoid having the same keys repeating in the data being streamed; > * Avoid concurrent updates of the cache that is being streamed into; > * Avoid streane fauilure. > * Avoid snapshotting. > Also, the docs should note streamer's limitations and traits. > Additionally, we may warn into log that datastreamer should successfully > finish. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17435) Fix Datastreamer documentation.
[ https://issues.apache.org/jira/browse/IGNITE-17435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-17435: -- Description: The doc should mention something like: Setting the `allowOverwrite` property to false is best used for initial data load on a cluster with stable topology. When cluster works under load, some actions may cause issues with data consistency. To avoid them: * Avoid having the same keys repeating in the data being streamed; * Avoid concurrent updates of the cache that is being streamed into; * Avoid streane fauilure. * Avoid snapshotting. Also, the docs should note streamer's limitations and traits. was: The doc should mention something like: Setting the `allowOverwrite` property to false is best used for initial data load on a cluster with stable topology. When cluster works under load, some actions may cause issues with data consistency. To avoid them: * Avoid having the same keys repeating in the data being streamed; * Avoid concurrent updates of the cache that is being streamed into; * Avoid rebalance on that cache. * Avoid snapshotting. Also, the docs should note streamer's limitations and traits. > Fix Datastreamer documentation. > --- > > Key: IGNITE-17435 > URL: https://issues.apache.org/jira/browse/IGNITE-17435 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > > The doc should mention something like: > Setting the `allowOverwrite` property to false is best used for initial data > load on a cluster with stable topology. When cluster works under load, some > actions may cause issues with data consistency. To avoid them: > * Avoid having the same keys repeating in the data being streamed; > * Avoid concurrent updates of the cache that is being streamed into; > * Avoid streane fauilure. > * Avoid snapshotting. > Also, the docs should note streamer's limitations and traits. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17920) Develop docker-compose file for Ignite cluster
[ https://issues.apache.org/jira/browse/IGNITE-17920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-17920: - Assignee: Vadim Pakhnushev > Develop docker-compose file for Ignite cluster > -- > > Key: IGNITE-17920 > URL: https://issues.apache.org/jira/browse/IGNITE-17920 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > The simplest pattern for docker distribution is working: > - pull docker image > - run docker container > - connect to the node from the developer machine > But there is another case of usage: > - get the compose file that forms the cluster (3 nodes) > - adjust the compose file if needed: change the cluster name, number of > nodes, etc > - docker compose up > - connect to the formed cluster from the developer machine > The second case is more likely to be used by devs, we have to develop the > compose file that will be mentioned in examples/docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620191#comment-17620191 ] Igor Sapego commented on IGNITE-17351: -- [~ptupitsyn] overall looks good. Left single comment. > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17930) Add javadoc plugin to gradle build
Aleksandr created IGNITE-17930: -- Summary: Add javadoc plugin to gradle build Key: IGNITE-17930 URL: https://issues.apache.org/jira/browse/IGNITE-17930 Project: Ignite Issue Type: Task Components: build Reporter: Aleksandr Maven build allows us to generate Javadoc from sources but Gradle does not. We have to add Javadoc generation task to the Gradle build and adjust DEVNOTES.md. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17919) Add developer documentation for gradle usage
[ https://issues.apache.org/jira/browse/IGNITE-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17919: --- Epic Link: IGNITE-17483 > Add developer documentation for gradle usage > > > Key: IGNITE-17919 > URL: https://issues.apache.org/jira/browse/IGNITE-17919 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Gradle now is the main build system for ignite 3. But there is not any piece > of information about how to build the project, or how to build RPM, DEB, > Docker, and Zip distributions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13024) Calcite integration. Support and simplification of complex expressions in index conditions
[
https://issues.apache.org/jira/browse/IGNITE-13024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13024:
---
Labels: calcite calcite3-required (was: calcite2-required
calcite3-required)
> Calcite integration. Support and simplification of complex expressions in
> index conditions
> --
>
> Key: IGNITE-13024
> URL: https://issues.apache.org/jira/browse/IGNITE-13024
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Fix For: 2.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current implementation supports only trivial expressions in index conditions,
> i.e. {{x=1}}. We need to support all evaluatable expressions (which not
> depends on input/table references) like {{x=?+10}}. Also we need to ensure
> that complex expressions in index filters are simplified (see
> {{RexSimplify}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17775) Invalid data in network buffers causes message deserialization errors and messages loss
[
https://issues.apache.org/jira/browse/IGNITE-17775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17775:
---
Description:
h3. TL;DR
Message serialization registry behavior is inconsistent, it either throws an
AssertionError or NetworkConfigurationException if factory is not found. There
should be only one. This will simplify debugging situations where one forgot to
register a factory in the registry, as it's the case in the problem below.
There's no actual bug in messaging and mentioned exception is impossible to get
in normal circumstances.
h3. Original description
In some tests I observe network messages' deserialization errors and timeout
exceptions while waiting for response. In some cases there is negative group
type of the message, and this causes error:
{code:java}
java.lang.AssertionError: message type must not be negative, messageType=-5376
at
org.apache.ignite.network.MessageSerializationRegistryImpl.getFactory(MessageSerializationRegistryImpl.java:77)
at
org.apache.ignite.network.MessageSerializationRegistryImpl.createDeserializer(MessageSerializationRegistryImpl.java:102)
at
org.apache.ignite.internal.network.serialization.SerializationService.createDeserializer(SerializationService.java:68)
at
org.apache.ignite.internal.network.serialization.PerSessionSerializationService.createMessageDeserializer(PerSessionSerializationService.java:109)
at
org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:89)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
{code}
When the group or message type is positive but not existing, there should be a
NetworkConfigurationException but it's not displayed in logs, however, it
causes TimeoutExceptions because of messages loss.
This reproduces in
[https://github.com/gridgain/apache-ignite-3/tree/ignite-17523-2] in
ItTablesApiTest#testGetTableFromLaggedNode
was:
In some tests I observe network messages' deserialization errors and timeout
exceptions while waiting for response. In some cases there is negative group
type of the message, and this causes error:
{code:java}
java.lang.AssertionError: message type must not be negative, messageType=-5376
at
org.apache.ignite.network.MessageSerializationRegistryImpl.getFactory(MessageSerializationRegistryImpl.java:77)
at
org.apache.ignite.network.MessageSerializationRegistryImpl.createDeserializer(MessageSerializationRegistryImpl.java:102)
at
org.apache.ignite.internal.network.serialization.SerializationService.createDeserializer(SerializationService.java:68)
at
org.apache.ignite.internal.network.serialization.PerSessionSerializationService.createMessageDeserializer(PerSessionSerializationService.java:109)
at
org.apache.ignite.internal.network.netty.InboundDecoder.decode(InboundDecoder.java:89)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
at
[jira] [Commented] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620170#comment-17620170 ] Julia Bakulina commented on IGNITE-17916: - [~timonin.maksim] thank you for the review! > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620168#comment-17620168 ] Maksim Timonin commented on IGNITE-17916: - [~julia_bakulina] merged to master. Thanks for your contribution! > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17637) Implement a commit partition path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620155#comment-17620155
]
Vladislav Pyatkov commented on IGNITE-17637:
Merged 7b0b3395de97db09896272e03322bba302c0b556
> Implement a commit partition path write intent resolution logic for RO reads
>
>
> Key: IGNITE-17637
> URL: https://issues.apache.org/jira/browse/IGNITE-17637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Need to perform writeIntent resolution by commit partition path if a
> coordinator path was not able to resolve the intent.
> # A write intent contains a commit partition id \{UUID tableId, int partId}.
> # Need to create a PlacementDriver which contains a map of assignments
> \{UUID tableId, int partId} -> Set
> # Assignments are updated in TableManager#updateAssignmentInternal.
> # PartitionReplicaListener contains placementDriver and replicaService.
> # PartitionReplicaListener read a write intent, get a commit partition id,
> get assignments and send TxStateReq to first ClusterNode by ReplicaService.
> ## On receiving a cluster node check that it is a leader, read the txn state
> from the persistent storage and send response with tx state. If txState not
> found, return NULL outcome in a TxStateResp.
> ## If the node isn't a leader, then it send response with leader and
> PartitionReplicaListener resend TxStateReq to the leader.
> ## If leader is unknown then PartitionReplicaListener send TxStateReq to
> another ClusterNode
> # If txState is found, validate a commit timestamp (only for committed
> state).
> # Retry commit partition path until a success or timeout.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17890) Calcite engine. Support index scan on boolean field
[
https://issues.apache.org/jira/browse/IGNITE-17890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-17890:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Support index scan on boolean field
> ---
>
> Key: IGNITE-17890
> URL: https://issues.apache.org/jira/browse/IGNITE-17890
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
>
> Currently, if table has index on boolean field it can't be used, since
> queries like
> {code:java}
> SELECT * FROM tbl WHERE a = TRUE
> {code}
> Simplified by Calcite to
> {code:java}
> SELECT * FROM tbl WHERE a {code}
> Condition `{{{}a{}}}` is not supported for building search bounds (see
> \{{RexUtils.isSupportedTreeComparison()}}) and such an index can't be used.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17637) Implement a commit partition path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620103#comment-17620103
]
Sergey Uttsel commented on IGNITE-17637:
[~v.pyatkov] LGTM
> Implement a commit partition path write intent resolution logic for RO reads
>
>
> Key: IGNITE-17637
> URL: https://issues.apache.org/jira/browse/IGNITE-17637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Need to perform writeIntent resolution by commit partition path if a
> coordinator path was not able to resolve the intent.
> # A write intent contains a commit partition id \{UUID tableId, int partId}.
> # Need to create a PlacementDriver which contains a map of assignments
> \{UUID tableId, int partId} -> Set
> # Assignments are updated in TableManager#updateAssignmentInternal.
> # PartitionReplicaListener contains placementDriver and replicaService.
> # PartitionReplicaListener read a write intent, get a commit partition id,
> get assignments and send TxStateReq to first ClusterNode by ReplicaService.
> ## On receiving a cluster node check that it is a leader, read the txn state
> from the persistent storage and send response with tx state. If txState not
> found, return NULL outcome in a TxStateResp.
> ## If the node isn't a leader, then it send response with leader and
> PartitionReplicaListener resend TxStateReq to the leader.
> ## If leader is unknown then PartitionReplicaListener send TxStateReq to
> another ClusterNode
> # If txState is found, validate a commit timestamp (only for committed
> state).
> # Retry commit partition path until a success or timeout.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17702) Move schema changes history from configuration to metastore
[ https://issues.apache.org/jira/browse/IGNITE-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620092#comment-17620092 ] Yury Gerzhedovich commented on IGNITE-17702: [~zstan] , LGTM. > Move schema changes history from configuration to metastore > --- > > Key: IGNITE-17702 > URL: https://issues.apache.org/jira/browse/IGNITE-17702 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3, tech-debt > Fix For: 3.0.0-beta2 > > Time Spent: 5h > Remaining Estimate: 0h > > History of schema changes keeps in configuration.Looks like it wrong, due to > configuration it is just a thing which requires to recreate similar cluster. > History schema more looks like a internal part which could keeps in Metastore. > Start points: > org.apache.ignite.internal.configuration.schema.SchemaConfigurationSchema > org.apache.ignite.internal.configuration.schema.ExtendedTableConfigurationSchema -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17637) Implement a commit partition path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17637:
-
Fix Version/s: 3.0.0-beta1
> Implement a commit partition path write intent resolution logic for RO reads
>
>
> Key: IGNITE-17637
> URL: https://issues.apache.org/jira/browse/IGNITE-17637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Need to perform writeIntent resolution by commit partition path if a
> coordinator path was not able to resolve the intent.
> # A write intent contains a commit partition id \{UUID tableId, int partId}.
> # Need to create a PlacementDriver which contains a map of assignments
> \{UUID tableId, int partId} -> Set
> # Assignments are updated in TableManager#updateAssignmentInternal.
> # PartitionReplicaListener contains placementDriver and replicaService.
> # PartitionReplicaListener read a write intent, get a commit partition id,
> get assignments and send TxStateReq to first ClusterNode by ReplicaService.
> ## On receiving a cluster node check that it is a leader, read the txn state
> from the persistent storage and send response with tx state. If txState not
> found, return NULL outcome in a TxStateResp.
> ## If the node isn't a leader, then it send response with leader and
> PartitionReplicaListener resend TxStateReq to the leader.
> ## If leader is unknown then PartitionReplicaListener send TxStateReq to
> another ClusterNode
> # If txState is found, validate a commit timestamp (only for committed
> state).
> # Retry commit partition path until a success or timeout.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17759) Need to pass commitTableId and commitPartitionId to MvPartitionStorage#addWrite
[
https://issues.apache.org/jira/browse/IGNITE-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17759:
-
Fix Version/s: 3.0.0-beta1
> Need to pass commitTableId and commitPartitionId to
> MvPartitionStorage#addWrite
> ---
>
> Key: IGNITE-17759
> URL: https://issues.apache.org/jira/browse/IGNITE-17759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
>
> Currently when PartitionListener invokes MvPartitionStorage#addWrite it
> passes
> UUID.randomUUID() as commitTableId and 0 as commitPartitionId. Need pass
> appropriate values.
>
> For this:
> # Need to create
> {code:java}
> class PartitionId {
> UUID tableId;
> int partId;
> }{code}
> # In InternalTableImpl#enlistInTx need to save PartitionId of the first
> operation to the Transaction.
> # Need to change {color:#172b4d}Map Long>> enlisted = new ConcurrentSkipListMap<>(){color} to Map IgniteBiTuple> enlisted = new ConcurrentHashMap<>();
> # Need to change String groupId to PartitionId groupId in all places.
> # In InternalTableImpl#enlistInTx need to pass PartitionId into
> ReplicaRequest (ReadWriteSingleRowReplicaRequest,
> ReadWriteSwapRowReplicaRequest, ReadWriteMultiRowReplicaRequest)
> # In PartitionReplicaListener need to pass PartitionId from ReplicaRequest
> to UpdateCommand and UpdateAllCommand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17263) Implement leader to replica safe time propagation
[ https://issues.apache.org/jira/browse/IGNITE-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17263: - Fix Version/s: 3.0.0-beta1 > Implement leader to replica safe time propagation > - > > Key: IGNITE-17263 > URL: https://issues.apache.org/jira/browse/IGNITE-17263 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, transaction3_ro > Fix For: 3.0.0-beta1 > > Attachments: Screenshot from 2022-07-06 16-48-30.png, Screenshot from > 2022-07-06 16-48-41.png > > > In order to perform replica reads, it's required either to use read index or > check the safe time. Let's recall corresponding section from tx design > document. > RO transactions can be executed on non-primary replicas. write intent > resolution doesn’t help because a write intent for a committed transaction > may not be yet replicated to the replica. To mitigate this issue, it’s enough > to run readIndex on each mapped partition leader, fetch the commit index and > wait on a replica until it’s applied. This will guarantee that all required > write intents are replicated and present locally. After that the normal write > intern resolution should do the job. > There is a second option, which doesn’t require the network RTT. We can use a > special low watermark timestamp (safeTs) per replication group, which > corresponds to the apply index of a replicated entry, so then an apply index > is advanced during the replication, then the safeTs is monotonically > incremented too. The HLC used for safeTs advancing is assigned to a > replicated entry in an ordered way. > Special measures are needed to periodically advance the safeTs if no updates > are happening. It’s enough to use a special replication command for this > purpose. > All we need during RO txn is to wait until a safeTs advances past the RO txn > readTs. > !Screenshot from 2022-07-06 16-48-30.png! > In the picture we have two concurrent transactions mapped to the same > partition: T1 and T2. > OpReq(w1(x)) and OpReq(w2(x)) are received concurrently. Each write intent is > assigned a timestamp in a monotonic order consistent with the replication > order. This can be for example done when replication entries are dequeued for > processing by replication protocol (we assume entries are replicated > successively. > It’s not enough only to wait for safeTs - it may never happen due to absence > of activity in the partition. Consider the next diagram: > !Screenshot from 2022-07-06 16-48-41.png! > We need an additional safeTsSync command to propagate a safeTs event in case > there are no updates in the partition. > We need to linerialize safe time updates in all cases including leader > change. So we need a guarantee that safe time on non-primary replicas never > will be greater than HLC on leader (as we assume that primary replica is > colocated with leader). We are going to solve this problem by associating > every potential value of safeTime (propagated to the replica from leader via > appendEntries) with some log index, and this value (safe time candidate) > should be applied as new safe time value at the moment when corresponding > index is committed. > Hence, the safeTimeSyncCommand also should be a Raft write command. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods
[
https://issues.apache.org/jira/browse/IGNITE-17260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17260:
-
Fix Version/s: 3.0.0-beta1
> Enrich IgniteTransactions and Transaction interfaces with RO related methods
>
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
>
> It's required to explicitly register an intent of starting readOnly
> transaction, so following decorator producer is expected in IgniteTransactions
> {code:java}
> /**
> * Decorated {@code IgniteTransactions} instance that will start read-only
> transactions.
> *
> * @return Decorated {@code IgniteTransactions} instance that will start
> read-only transactions.
> */
> IgniteTransactions readOnly(); {code}
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
> And finally three more overloaded methods will be added to the InternalTable
> {code:java}
> CompletableFuture get(
> BinaryRowEx keyRow,
> @Nullable InternalTransaction tx,
> @NotNull ClusterNode recipientNode
> );
>
> CompletableFuture> getAll(
> Collection keyRows,
> @Nullable InternalTransaction tx,
> @NotNull ClusterNode recipientNode
> );
>
> Publisher scan(
> int p,
> @Nullable InternalTransaction tx,
> @NotNull ClusterNode recipientNode
> );
> {code}
> Please, pay attention, that new parameter @NotNull ClusterNode recipientNode
> is added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17572) Update Ignite dependency: mockserver-netty
[ https://issues.apache.org/jira/browse/IGNITE-17572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-17572: --- Environment: Update dependency: mockserver-netty 5.11.1 to 5.14.0 (was: Update dependency: mockserver-netty 5.11.1 to 5.13.2) > Update Ignite dependency: mockserver-netty > -- > > Key: IGNITE-17572 > URL: https://issues.apache.org/jira/browse/IGNITE-17572 > Project: Ignite > Issue Type: Improvement > Environment: Update dependency: mockserver-netty 5.11.1 to 5.14.0 >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17869) Create a basic glossary for AI 3
[ https://issues.apache.org/jira/browse/IGNITE-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev resolved IGNITE-17869. - Resolution: Fixed > Create a basic glossary for AI 3 > > > Key: IGNITE-17869 > URL: https://issues.apache.org/jira/browse/IGNITE-17869 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17919) Add developer documentation for gradle usage
[ https://issues.apache.org/jira/browse/IGNITE-17919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-17919: -- Assignee: Aleksandr > Add developer documentation for gradle usage > > > Key: IGNITE-17919 > URL: https://issues.apache.org/jira/browse/IGNITE-17919 > Project: Ignite > Issue Type: Task > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > > Gradle now is the main build system for ignite 3. But there is not any piece > of information about how to build the project, or how to build RPM, DEB, > Docker, and Zip distributions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17351: Fix Version/s: 2.15 > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17351: Release Note: Java thin: added configurable logging. > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17351) Java thin: Implement logging
[ https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17351: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Java thin: Implement logging > > > Key: IGNITE-17351 > URL: https://issues.apache.org/jira/browse/IGNITE-17351 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > > We need to provide support for logging for Java thin client. > Make sure that it is easy to turn on full logging without re-compiling for > debugging purposes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17900) Very slow SQL execution with LEFT JOIN and subquery after upgrade from 2.7.6
[
https://issues.apache.org/jira/browse/IGNITE-17900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dren updated IGNITE-17900:
--
Attachment: explain_plan_Calcite_SQL_engine.txt
> Very slow SQL execution with LEFT JOIN and subquery after upgrade from 2.7.6
>
>
> Key: IGNITE-17900
> URL: https://issues.apache.org/jira/browse/IGNITE-17900
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13, 2.14
> Environment: One node test instalation, 6 vCPU 8GB RAM.
> Ignite 2.14.0
> jdk-13.0.2
>
>
>Reporter: Dren
>Priority: Major
> Attachments: CREATE_TABLE1.sql, explain_plan.txt,
> explain_plan_Calcite_SQL_engine.txt, ignite_log.txt, insert_data.sql
>
>
> After migration from Ignite 2.7.6 to Ignite 2.13 I noticed that the query
> below executes very slowly. A big difference in execution time can be seen
> already in tables with several thousands of records. If table have more than
> 100,000 records, the query will never finish.
> {code:java}
> // SQL
> select T0.* , T1.HIDE
> from TABLE1 as T0
> left JOIN
> ( select key1, key2, count(*) AS HIDE
> from TABLE1
> GROUP BY key1, key2
> ) as T1
> ON T0.key1 = T1.key1 AND T0.key2 = T1.key2; {code}
>
> – Ignite v2.13.0 and v2.14.0
> – execution time 8 seconds with 2100 records
> – execution time 22 seconds with 4400 records
>
> – Ignite v 2.7.6
> – execution time 3ms with 2100 records
> – execution time 4ms with 4400 records
>
> All DDL and test data can be found in attachment.
> I tried adding indexes to the key1 and key2 columns, but the result is always
> the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17351) Java thin: Implement logging
[
https://issues.apache.org/jira/browse/IGNITE-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620061#comment-17620061
]
Ignite TC Bot commented on IGNITE-17351:
{panel:title=Branch: [pull/10331/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10331/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6846852buildTypeId=IgniteTests24Java8_RunAll]
> Java thin: Implement logging
>
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for
> debugging purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17900) Very slow SQL execution with LEFT JOIN and subquery after upgrade from 2.7.6
[
https://issues.apache.org/jira/browse/IGNITE-17900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620060#comment-17620060
]
Dren commented on IGNITE-17900:
---
I did the first testing with H2 SQL engine.
With Calcite SQL engine on Ignite 2.14.0 different SQL plan is applied.
Execution speed is much faster and same query is executed in 55 ms on table
TABLE1 with 4700 records.
> Very slow SQL execution with LEFT JOIN and subquery after upgrade from 2.7.6
>
>
> Key: IGNITE-17900
> URL: https://issues.apache.org/jira/browse/IGNITE-17900
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13, 2.14
> Environment: One node test instalation, 6 vCPU 8GB RAM.
> Ignite 2.14.0
> jdk-13.0.2
>
>
>Reporter: Dren
>Priority: Major
> Attachments: CREATE_TABLE1.sql, explain_plan.txt, ignite_log.txt,
> insert_data.sql
>
>
> After migration from Ignite 2.7.6 to Ignite 2.13 I noticed that the query
> below executes very slowly. A big difference in execution time can be seen
> already in tables with several thousands of records. If table have more than
> 100,000 records, the query will never finish.
> {code:java}
> // SQL
> select T0.* , T1.HIDE
> from TABLE1 as T0
> left JOIN
> ( select key1, key2, count(*) AS HIDE
> from TABLE1
> GROUP BY key1, key2
> ) as T1
> ON T0.key1 = T1.key1 AND T0.key2 = T1.key2; {code}
>
> – Ignite v2.13.0 and v2.14.0
> – execution time 8 seconds with 2100 records
> – execution time 22 seconds with 4400 records
>
> – Ignite v 2.7.6
> – execution time 3ms with 2100 records
> – execution time 4ms with 4400 records
>
> All DDL and test data can be found in attachment.
> I tried adding indexes to the key1 and key2 columns, but the result is always
> the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17916: - Description: The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to *break changes* of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - IGNITE-17916; 2) delete this property in the release after the next one - IGNITE-8801. was: The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to break changes of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - IGNITE-17916; 2) delete this property in the release after the next one - IGNITE-8801. > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Affects Version/s: (was: 2.13)
(was: 2.14)
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
>
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17916: - Labels: important ise (was: ise) > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620046#comment-17620046
]
Julia Bakulina commented on IGNITE-17383:
-
[~timoninmaxim] Hi Maxim, could you please review the changes?
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.13, 2.14
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
>
[jira] [Created] (IGNITE-17929) Add read-only support to ClientTransactions
Alexander Lapin created IGNITE-17929: Summary: Add read-only support to ClientTransactions Key: IGNITE-17929 URL: https://issues.apache.org/jira/browse/IGNITE-17929 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17928) SQL support analysis
Yury Gerzhedovich created IGNITE-17928: -- Summary: SQL support analysis Key: IGNITE-17928 URL: https://issues.apache.org/jira/browse/IGNITE-17928 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Assignee: Yury Gerzhedovich Need to analyze SQL standard and check which features SQL engine in Apache Ignite 3.0 support and which not. As a result, it requires create a document with proposed structure: feature id, feature name, sub feature id, sub feature name, is supported, link to existing tests, comments As basis standard let's use ISO/IEC 9075 2016 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17806) Remove transaction state PENDING
[ https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17806: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove transaction state PENDING > > > Key: IGNITE-17806 > URL: https://issues.apache.org/jira/browse/IGNITE-17806 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > In some cases, when the used does not pass a transaction explicit to SQL, the > engine (SQLProcessor) creates a new one transaction automatically. When > during the execution an exception is thrown, the automatically created > transaction is not rolled back and freezes in pending state. > Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17806) Remove transaction state PENDING
[ https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17806: - Summary: Remove transaction state PENDING (was: Rollback SQL automatically created transaction when an error has happened) > Remove transaction state PENDING > > > Key: IGNITE-17806 > URL: https://issues.apache.org/jira/browse/IGNITE-17806 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > In some cases, when the used does not pass a transaction explicit to SQL, the > engine (SQLProcessor) creates a new one transaction automatically. When > during the execution an exception is thrown, the automatically created > transaction is not rolled back and freezes in pending state. > Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15609) Calcite. Error WHERE clause must be a condition.
[
https://issues.apache.org/jira/browse/IGNITE-15609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-15609:
Labels: calcite calcite2-required calcite3-required (was: calcite
calcite2-required calcite3-required ignite-3)
> Calcite. Error WHERE clause must be a condition.
>
>
> Key: IGNITE-15609
> URL: https://issues.apache.org/jira/browse/IGNITE-15609
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required
>
> {noformat}
> statement ok
> CREATE TABLE item(i_manufact INTEGER)
> query I
> SELECT * FROM item i1 WHERE (SELECT count(*) AS item_cnt FROM item WHERE
> (i_manufact = i1.i_manufact AND i_manufact=3) OR (i_manufact = i1.i_manufact
> AND i_manufact=3)) ORDER BY 1 LIMIT 100;
>
> {noformat}
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 30 to
> line 1, column 167: WHERE clause must be a condition
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:506)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:902)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5271)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:4350)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:4334)
> {noformat}
> {noformat}
> /subquery/scalar/test_tpcds_correlated_subquery.test[_ignore]
> {noformat}
> tested with mysql, all ok there.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
