[jira] [Commented] (IGNITE-14625) Make DurableBackgroundTask return future
[ https://issues.apache.org/jira/browse/IGNITE-14625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334447#comment-17334447 ] Kirill Tkalenko commented on IGNITE-14625: -- [~Denis Chudov] Please make code review. > Make DurableBackgroundTask return future > > > Key: IGNITE-14625 > URL: https://issues.apache.org/jira/browse/IGNITE-14625 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > While trying to implement rebuilding indexes on *DurableBackgroundTask*, I > encountered several problems: > * For each task, a new thread is created, which can be critical for > rebuilding indexes, since there can be many caches and this can create many > threads; > * Tasks can be completed close to the end of a checkpoint, and data may not > reach this checkpoint. > Therefore, I propose to slightly rework the *DurableBackgroundTask*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14644) .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
[ https://issues.apache.org/jira/browse/IGNITE-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14644: Release Note: .NET: Add a warning to the log when alternate stack check is not enabled > .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck > -- > > Key: IGNITE-14644 > URL: https://issues.apache.org/jira/browse/IGNITE-14644 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, newbie > Fix For: 2.11 > > Original Estimate: 2h > Time Spent: 20m > Remaining Estimate: 1h 40m > > See > https://ignite.apache.org/docs/latest/net-specific/net-troubleshooting#stack-smashing-detected-dotnet-terminated: > On Linux, Java overwrites SIGSEGV handler installed by .NET, so > NullReferenceException causes a scary "Stack smashing detected" error, which > can be fixed by setting COMPlus_EnableAlternateStackCheck environment > variable. > Write a suggestion to the log if all of the following is true: > * OS is Linux (or macOS? Check this) > * Runtime version is 3.0 or later > * COMPlus_EnableAlternateStackCheck is not set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14644) .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
[ https://issues.apache.org/jira/browse/IGNITE-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14644: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck > -- > > Key: IGNITE-14644 > URL: https://issues.apache.org/jira/browse/IGNITE-14644 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, newbie > Fix For: 2.11 > > Original Estimate: 2h > Time Spent: 20m > Remaining Estimate: 1h 40m > > See > https://ignite.apache.org/docs/latest/net-specific/net-troubleshooting#stack-smashing-detected-dotnet-terminated: > On Linux, Java overwrites SIGSEGV handler installed by .NET, so > NullReferenceException causes a scary "Stack smashing detected" error, which > can be fixed by setting COMPlus_EnableAlternateStackCheck environment > variable. > Write a suggestion to the log if all of the following is true: > * OS is Linux (or macOS? Check this) > * Runtime version is 3.0 or later > * COMPlus_EnableAlternateStackCheck is not set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14644) .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
[ https://issues.apache.org/jira/browse/IGNITE-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333500#comment-17333500 ] Pavel Tupitsyn commented on IGNITE-14644: - Merged to master: f97b932849eff35b7849b30c84468aeede14d378 > .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck > -- > > Key: IGNITE-14644 > URL: https://issues.apache.org/jira/browse/IGNITE-14644 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, newbie > Fix For: 2.11 > > Original Estimate: 2h > Time Spent: 10m > Remaining Estimate: 1h 50m > > See > https://ignite.apache.org/docs/latest/net-specific/net-troubleshooting#stack-smashing-detected-dotnet-terminated: > On Linux, Java overwrites SIGSEGV handler installed by .NET, so > NullReferenceException causes a scary "Stack smashing detected" error, which > can be fixed by setting COMPlus_EnableAlternateStackCheck environment > variable. > Write a suggestion to the log if all of the following is true: > * OS is Linux (or macOS? Check this) > * Runtime version is 3.0 or later > * COMPlus_EnableAlternateStackCheck is not set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14625) Make DurableBackgroundTask return future
[
https://issues.apache.org/jira/browse/IGNITE-14625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333485#comment-17333485
]
Ignite TC Bot commented on IGNITE-14625:
{panel:title=Branch: [pull/9037/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9037/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5984247]]
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testCancelTaskExecution - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testSimpleTaskExecutionWithoutMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskExecutionWithMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskExecutionWithoutMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testSimpleTaskExecutionWithMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskAfterRestartNode -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5984278buildTypeId=IgniteTests24Java8_RunAll]
> Make DurableBackgroundTask return future
>
>
> Key: IGNITE-14625
> URL: https://issues.apache.org/jira/browse/IGNITE-14625
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While trying to implement rebuilding indexes on *DurableBackgroundTask*, I
> encountered several problems:
> * For each task, a new thread is created, which can be critical for
> rebuilding indexes, since there can be many caches and this can create many
> threads;
> * Tasks can be completed close to the end of a checkpoint, and data may not
> reach this checkpoint.
> Therefore, I propose to slightly rework the *DurableBackgroundTask*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14662) Update dependency artifactId in spring-data extension documentation.
[ https://issues.apache.org/jira/browse/IGNITE-14662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-14662: --- Assignee: Mikhail Petrov > Update dependency artifactId in spring-data extension documentation. > > > Key: IGNITE-14662 > URL: https://issues.apache.org/jira/browse/IGNITE-14662 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It is needed to change artifactId for spring-data extension in documentation > from ignite-spring-data_2.2-ext to ignite-spring-data-2.2-ext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14644) .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
[
https://issues.apache.org/jira/browse/IGNITE-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333401#comment-17333401
]
Ignite TC Bot commented on IGNITE-14644:
{panel:title=Branch: [pull/9050/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5984336]]
{color:#d04437}Queries 1{color} [[tests 1
xmlReportParsingSurefireParsingFailure
|https://ci.ignite.apache.org/viewLog.html?buildId=5984360]]
* IgniteBinaryCacheQueryTestSuite:
IgniteSqlSkipReducerOnUpdateDmlFlagSelfTest.testInsertFromSelectJoin - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5984376]]
{panel}
{panel:title=Branch: [pull/9050/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=5984381buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
> --
>
> Key: IGNITE-14644
> URL: https://issues.apache.org/jira/browse/IGNITE-14644
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET, newbie
> Fix For: 2.11
>
> Original Estimate: 2h
> Time Spent: 10m
> Remaining Estimate: 1h 50m
>
> See
> https://ignite.apache.org/docs/latest/net-specific/net-troubleshooting#stack-smashing-detected-dotnet-terminated:
> On Linux, Java overwrites SIGSEGV handler installed by .NET, so
> NullReferenceException causes a scary "Stack smashing detected" error, which
> can be fixed by setting COMPlus_EnableAlternateStackCheck environment
> variable.
> Write a suggestion to the log if all of the following is true:
> * OS is Linux (or macOS? Check this)
> * Runtime version is 3.0 or later
> * COMPlus_EnableAlternateStackCheck is not set
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14044) Cache with node filter is not destroyed properly on the filtered node.
[
https://issues.apache.org/jira/browse/IGNITE-14044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330456#comment-17330456
]
Pavel Pereslegin edited comment on IGNITE-14044 at 4/27/21, 4:43 PM:
-
[~slava.koptilin],
could you take a look at this patch?
was (Author: xtern):
[~slava.koptilin],
could you take a look at this patch?
> Cache with node filter is not destroyed properly on the filtered node.
> --
>
> Key: IGNITE-14044
> URL: https://issues.apache.org/jira/browse/IGNITE-14044
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps to reproduce the problem:
> # Start 2 nodes
> # Create a cache with node filter (filter second node)
> # Destroy cache
> # Restart nodes
> Expected: cache was destroyed on both nodes.
> Actual: cache was destroyed only on one node, the second node cannot join
> the cluster with the following error:
> {noformat}
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Joining node has
> caches with data which are not presented on cluster, it could mean that they
> were already destroyed, to add the node to cluster - remove directories with
> the caches[cache1]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2052)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1197)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:472)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2154)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> ... 23 more
> {noformat}
> Reproducer
> {code:java}
> public class IgnitePdsDestroyCacheWithNodeFilterTest extends
> GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setConsistentId(igniteInstanceName)
> .setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> }
> @Test
> public void testDestroyCacheWithNodeFilter() throws Exception {
> cleanPersistenceDir();
> Ignite ignite = startGrids(2);
> ignite.cluster().state(ClusterState.ACTIVE);
> UUID nodeId0 = ignite.cluster().localNode().id();
> CacheConfiguration cfg1 = new
> CacheConfiguration<>("cache1")
> .setCacheMode(CacheMode.REPLICATED)
> .setNodeFilter(n -> nodeId0.equals(n.id()));
> IgniteCache cache1 = ignite.createCache(cfg1);
> cache1.destroy();
> forceCheckpoint();
> awaitPartitionMapExchange();
> stopAllGrids();
> ignite = startGrids(2); // failing here
> ignite.cluster().state(ClusterState.ACTIVE);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14663) Ignite metastorage must be enrypted using TDE
Maxim Muzafarov created IGNITE-14663: Summary: Ignite metastorage must be enrypted using TDE Key: IGNITE-14663 URL: https://issues.apache.org/jira/browse/IGNITE-14663 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov The Ignite metastorage stores files on disk the same way as it implemented for caches. These files must be also encrypted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14662) Update dependency artifactId in spring-data extension documentation.
Mikhail Petrov created IGNITE-14662: --- Summary: Update dependency artifactId in spring-data extension documentation. Key: IGNITE-14662 URL: https://issues.apache.org/jira/browse/IGNITE-14662 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov It is needed to change artifactId for spring-data extension in documentation from ignite-spring-data_2.2-ext to ignite-spring-data-2.2-ext. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14661) Broken validation of parts of compound PK
[
https://issues.apache.org/jira/browse/IGNITE-14661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1721#comment-1721
]
Konstantin Orlov commented on IGNITE-14661:
---
[~tledkov-gridgain],[~jooger], folks, do a review please
> Broken validation of parts of compound PK
> -
>
> Key: IGNITE-14661
> URL: https://issues.apache.org/jira/browse/IGNITE-14661
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently it's possible to set {{null}} to column that is part of compound PK
> even if this field was declared as {{NOT NULL}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14661) Broken validation of parts of compound PK
[
https://issues.apache.org/jira/browse/IGNITE-14661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-14661:
--
Description: Currently it's possible to set {{null}} to column that is part
of compound PK even if this field was declared as {{NOT NULL}}. (was:
Currently it's possible to set {{null}} to column that is part of compound PK
even if {{NOT NULL}} constraint was provided for this field.)
> Broken validation of parts of compound PK
> -
>
> Key: IGNITE-14661
> URL: https://issues.apache.org/jira/browse/IGNITE-14661
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
>
> Currently it's possible to set {{null}} to column that is part of compound PK
> even if this field was declared as {{NOT NULL}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14661) Broken validation of parts of compound PK
Konstantin Orlov created IGNITE-14661:
-
Summary: Broken validation of parts of compound PK
Key: IGNITE-14661
URL: https://issues.apache.org/jira/browse/IGNITE-14661
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
Currently it's possible to set {{null}} to column that is part of compound PK
even if {{NOT NULL}} constraint was provided for this field.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14644) .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck
[ https://issues.apache.org/jira/browse/IGNITE-14644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333288#comment-17333288 ] Igor Sapego commented on IGNITE-14644: -- [~ptupitsyn] looks good. Ship it. > .NET: Log a suggestion about COMPlus_EnableAlternateStackCheck > -- > > Key: IGNITE-14644 > URL: https://issues.apache.org/jira/browse/IGNITE-14644 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, newbie > Fix For: 2.11 > > Original Estimate: 2h > Time Spent: 10m > Remaining Estimate: 1h 50m > > See > https://ignite.apache.org/docs/latest/net-specific/net-troubleshooting#stack-smashing-detected-dotnet-terminated: > On Linux, Java overwrites SIGSEGV handler installed by .NET, so > NullReferenceException causes a scary "Stack smashing detected" error, which > can be fixed by setting COMPlus_EnableAlternateStackCheck environment > variable. > Write a suggestion to the log if all of the following is true: > * OS is Linux (or macOS? Check this) > * Runtime version is 3.0 or later > * COMPlus_EnableAlternateStackCheck is not set -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14660) Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
[
https://issues.apache.org/jira/browse/IGNITE-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333277#comment-17333277
]
Konstantin Orlov commented on IGNITE-14660:
---
[~tledkov-gridgain], do a review please
> Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
> ---
>
> Key: IGNITE-14660
> URL: https://issues.apache.org/jira/browse/IGNITE-14660
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently
> {{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}} could
> fail because of lack of result sorting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14660) Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
[
https://issues.apache.org/jira/browse/IGNITE-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-14660:
--
Description: Currently
{{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}} could fail
because of lack of result sorting. (was: Currently
{{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}} could fail
because of lack of result ordering.)
> Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
> ---
>
> Key: IGNITE-14660
> URL: https://issues.apache.org/jira/browse/IGNITE-14660
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently
> {{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}} could
> fail because of lack of result sorting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14660) Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
Konstantin Orlov created IGNITE-14660:
-
Summary: Flaky test
GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
Key: IGNITE-14660
URL: https://issues.apache.org/jira/browse/IGNITE-14660
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
Currently {{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}}
could fail because of lack of result ordering.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14407) In-memory implementation of Vault
[ https://issues.apache.org/jira/browse/IGNITE-14407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14407: - Labels: ignite-3 (was: ) > In-memory implementation of Vault > - > > Key: IGNITE-14407 > URL: https://issues.apache.org/jira/browse/IGNITE-14407 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Time Spent: 8h 50m > Remaining Estimate: 0h > > It seems that in-memory implementation can be provided in the first place. It > allows unblocking other activities (dev and unit testing) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14609) Document old and new async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333151#comment-17333151
]
Igor Gusev commented on IGNITE-14609:
-
Left some minor comments for your text.
> Document old and new async continuation behavior
>
>
> Key: IGNITE-14609
> URL: https://issues.apache.org/jira/browse/IGNITE-14609
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IGNITE-12033 changed the default async behavior for cache operations in Java
> and .NET, plus Compute operations in .NET.
> Document old and new async continuation behavior for Java and .NET.
> Java:
> * Update
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
> * Mention changes in upcoming 2.11
> * Fix IgniteFuture javadoc (listen methods)
> .NET:
> * Add dedicated async page to {{.NET Specific}} section
> * Explain cache async ops
> * Explain known issues in Compute (Reduce method gets blocked)
> * Mention changes in upcoming 2.11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14407) In-memory implementation of Vault
[ https://issues.apache.org/jira/browse/IGNITE-14407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14407: - Reviewer: Alexander Lapin > In-memory implementation of Vault > - > > Key: IGNITE-14407 > URL: https://issues.apache.org/jira/browse/IGNITE-14407 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Mirza Aliev >Priority: Major > Time Spent: 8h 40m > Remaining Estimate: 0h > > It seems that in-memory implementation can be provided in the first place. It > allows unblocking other activities (dev and unit testing) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14659) Check mutlikey and noncollocated tx impact on sync-free switch
Anton Vinogradov created IGNITE-14659: - Summary: Check mutlikey and noncollocated tx impact on sync-free switch Key: IGNITE-14659 URL: https://issues.apache.org/jira/browse/IGNITE-14659 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14657) Add README.md to configuration module
[ https://issues.apache.org/jira/browse/IGNITE-14657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333124#comment-17333124 ] Ivan Bessonov commented on IGNITE-14657: https://github.com/gridgain/apache-ignite-3/tree/ignite-14657/modules/configuration > Add README.md to configuration module > - > > Key: IGNITE-14657 > URL: https://issues.apache.org/jira/browse/IGNITE-14657 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 3.0.0-alpha1 >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add README.md to configuration module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[
https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333121#comment-17333121
]
Ignite TC Bot commented on IGNITE-6324:
---
{panel:title=Branch: [pull/8987/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8987/head] Base: [master] : New Tests
(196)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5963343]]
* {color:#013220}IgniteCacheTestSuite9:
CacheReadBeforeActivationTest.readUtilityCacheBeforeActivationFinished -
PASSED{color}
{color:#8b}Queries 2{color} [[tests
144|https://ci.ignite.apache.org/viewLog.html?buildId=5963305]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClientTx[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.String,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClient[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.String,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPut[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutTx[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClientTx[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClient[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPut[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=head,idxFldType=class
java.lang.String,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutTx[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=1,idxFld=head,idxFldType=class
java.lang.String,gridCnt=1] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClientTx[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=0,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=3] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPutFromThinClient[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=0,idxFld=field,idxFldType=class
java.lang.Long,gridCnt=3] - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
WrongQueryEntityFieldTypeTest.testPut[cacheMode=TRANSACTIONAL_SNAPSHOT,backups=0,idxFld=head,idxFldType=class
java.lang.String,gridCnt=3] - PASSED{color}
... and 133 new tests
{color:#8b}Cache 5{color} [[tests
21|https://ci.ignite.apache.org/viewLog.html?buildId=5963339]]
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = REPEATABLE_READ, Started from = PRIMARY] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = READ_COMMITTED, Started from = BACKUP] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = READ_COMMITTED, Started from = NEAR] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = READ_COMMITTED, Started from = PRIMARY] -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchIsolationTest.testOnlyAffectedNodesWaitForRecovery[Started
from = BACKUP] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchIsolationTest.testOnlyAffectedNodesWaitForRecovery[Started
from = NEAR] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchIsolationTest.testOnlyAffectedNodesWaitForRecovery[Started
from = PRIMARY] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= PESSIMISTIC, Concurrency = SERIALIZABLE, Started from = BACKUP] -
PASSED{color}
*
[jira] [Updated] (IGNITE-14609) Document old and new async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14609:
Description:
IGNITE-12033 changed the default async behavior for cache operations in Java
and .NET, plus Compute operations in .NET.
Document old and new async continuation behavior for Java and .NET.
Java:
* Update
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
* Mention changes in upcoming 2.11
* Fix IgniteFuture javadoc (listen methods)
.NET:
* Add dedicated async page to {{.NET Specific}} section
* Explain cache async ops
* Explain known issues in Compute (Reduce method gets blocked)
* Mention changes in upcoming 2.11
was:
IGNITE-12033 changed the default async behavior for cache operations in Java
and .NET, plus Compute operations in .NET.
Document old and new async continuation behavior for Java and .NET.
Java:
* Update
https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
* Mention changes in upcoming 2.11
* Fix IgniteFuture javadoc (listen methods)
.NET:
* Add dedicated async page to {{.NET Specific}} section
* Explain cache async ops
* Explain known issues in Compute (Reduce method gets blocked)
* Add a note to Troubleshooting with a link to async page
* Mention changes in upcoming 2.11
> Document old and new async continuation behavior
>
>
> Key: IGNITE-14609
> URL: https://issues.apache.org/jira/browse/IGNITE-14609
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IGNITE-12033 changed the default async behavior for cache operations in Java
> and .NET, plus Compute operations in .NET.
> Document old and new async continuation behavior for Java and .NET.
> Java:
> * Update
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
> * Mention changes in upcoming 2.11
> * Fix IgniteFuture javadoc (listen methods)
> .NET:
> * Add dedicated async page to {{.NET Specific}} section
> * Explain cache async ops
> * Explain known issues in Compute (Reduce method gets blocked)
> * Mention changes in upcoming 2.11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14607) Regex Based Filter in IPFinders
[ https://issues.apache.org/jira/browse/IGNITE-14607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma updated IGNITE-14607: - Release Note: Add a way to specify regex based address filters for IP addresses during discovery > Regex Based Filter in IPFinders > --- > > Key: IGNITE-14607 > URL: https://issues.apache.org/jira/browse/IGNITE-14607 > Project: Ignite > Issue Type: Sub-task >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > This Jira tracks the effort to implement regex based IP filtering in IPFinders -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333102#comment-17333102
]
Ivan Bessonov commented on IGNITE-14656:
[~vveider] Patch looks good, thank you very much!
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14656:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333087#comment-17333087
]
Peter Ivanov edited comment on IGNITE-14656 at 4/27/21, 10:13 AM:
--
Added check step.
Checked on
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_SanityChecks_Maven/5983708
was (Author: vveider):
Added check step:
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_SanityChecks_Maven/5983688
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-14658: Assignee: Nikolay Izhikov > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov updated IGNITE-14656:
--
Fix Version/s: 3.0.0-alpha2
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333087#comment-17333087
]
Peter Ivanov commented on IGNITE-14656:
---
Added check step:
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_SanityChecks_Maven/5983688
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
[
https://issues.apache.org/jira/browse/IGNITE-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Ivanov reassigned IGNITE-14656:
-
Assignee: Peter Ivanov
> Modules in root pom.xml must be lexicographically sorted.
> -
>
> Key: IGNITE-14656
> URL: https://issues.apache.org/jira/browse/IGNITE-14656
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha1
>Reporter: Ivan Bessonov
>Assignee: Peter Ivanov
>Priority: Major
>
> In order to make project more clean we should enforce sorting of
> {{}} section in root {{pom.xml}} file.
> Right now order is already broken by the last two entities - {{baseline}} and
> {{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-14658: - Labels: IEP-35 (was: ) > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14658) [IEP-35] SSL metrics
Nikolay Izhikov created IGNITE-14658: Summary: [IEP-35] SSL metrics Key: IGNITE-14658 URL: https://issues.apache.org/jira/browse/IGNITE-14658 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov The following SSL metrics required: * Count of SSL sessions. * Count of rejected SSL sessions. * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14657) Add README.md to configuration module
Ivan Bessonov created IGNITE-14657: -- Summary: Add README.md to configuration module Key: IGNITE-14657 URL: https://issues.apache.org/jira/browse/IGNITE-14657 Project: Ignite Issue Type: Sub-task Affects Versions: 3.0.0-alpha1 Reporter: Ivan Bessonov Assignee: Ivan Bessonov Add README.md to configuration module -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14407) In-memory implementation of Vault
[ https://issues.apache.org/jira/browse/IGNITE-14407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333045#comment-17333045 ] Alexander Lapin commented on IGNITE-14407: -- [~maliev] LGTM > In-memory implementation of Vault > - > > Key: IGNITE-14407 > URL: https://issues.apache.org/jira/browse/IGNITE-14407 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Mirza Aliev >Priority: Major > Time Spent: 8h 40m > Remaining Estimate: 0h > > It seems that in-memory implementation can be provided in the first place. It > allows unblocking other activities (dev and unit testing) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[
https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333043#comment-17333043
]
Ignite TC Bot commented on IGNITE-6324:
---
{panel:title=Branch: [pull/8987/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Missing Tests]{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5983498]]
{panel}
{panel:title=Branch: [pull/8987/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5983499buildTypeId=IgniteTests24Java8_RunBasicTests]
> Transactional cache data partially available after crash and further recovery.
> --
>
> Key: IGNITE-6324
> URL: https://issues.apache.org/jira/browse/IGNITE-6324
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.10
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Attachments: InterruptCommitedThreadTest.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If InterruptedException raise in client code during pds store operations we
> can obtain inconsistent cache after restart.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14656) Modules in root pom.xml must be lexicographically sorted.
Ivan Bessonov created IGNITE-14656:
--
Summary: Modules in root pom.xml must be lexicographically sorted.
Key: IGNITE-14656
URL: https://issues.apache.org/jira/browse/IGNITE-14656
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-alpha1
Reporter: Ivan Bessonov
In order to make project more clean we should enforce sorting of {{}}
section in root {{pom.xml}} file.
Right now order is already broken by the last two entities - {{baseline}} and
{{affinity}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14238) Creating and destroying tables
[ https://issues.apache.org/jira/browse/IGNITE-14238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333018#comment-17333018 ] Vladislav Pyatkov commented on IGNITE-14238: Destroy table through API will be implemented here. > Creating and destroying tables > -- > > Key: IGNITE-14238 > URL: https://issues.apache.org/jira/browse/IGNITE-14238 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > > Need to implement a new cluster-wide procedure that will be responsible for > creating and destroying caches. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14235) Provide a minimal cache/table configuration
[ https://issues.apache.org/jira/browse/IGNITE-14235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-14235: -- Assignee: Vladislav Pyatkov > Provide a minimal cache/table configuration > --- > > Key: IGNITE-14235 > URL: https://issues.apache.org/jira/browse/IGNITE-14235 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > > Need to provide a way to configure a cache/table in accordance with IEP-55 > Unified Configuration [1] and IEP-54 Schema first approach. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration > [2] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-14238) Creating and destroying tables
[ https://issues.apache.org/jira/browse/IGNITE-14238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-14238: --- Comment: was deleted (was: API for table dilation will be implemented in another ticket[1]. Because this PR is already prepared and so big for review. [1] https://issues.apache.org/jira/browse/IGNITE-14236) > Creating and destroying tables > -- > > Key: IGNITE-14238 > URL: https://issues.apache.org/jira/browse/IGNITE-14238 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > > Need to implement a new cluster-wide procedure that will be responsible for > creating and destroying caches. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-14236) Provide a new version of cache API
[
https://issues.apache.org/jira/browse/IGNITE-14236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-14236:
---
Comment: was deleted
(was: The most part for this issue is already done as [~amashenkov] said, but I
have a plane to implement an API for a table delete here.)
> Provide a new version of cache API
> --
>
> Key: IGNITE-14236
> URL: https://issues.apache.org/jira/browse/IGNITE-14236
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Koptilin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: iep-72, ignite-3
>
> Need to provide a minimal cache API that includes at least the following
> methods:
> - reading a value for a given key
> - writing a new value for a given key
> - remove a value for a given key
> - method that determines if the cache contains an entry for the specified
> key.
> - a way to iterate all key/value pairs
> - cache/table size (this method is questionable)
> Additionally, it can be considered adding a way to execute the user's code
> for the specified key - something like {{Cache#invoke()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14235) Provide a minimal cache/table configuration
[ https://issues.apache.org/jira/browse/IGNITE-14235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17333014#comment-17333014 ] Alexey Scherbakov commented on IGNITE-14235: [~v.pyatkov] LGTM. Merged to master #0de76810c8a610ec421b774f13152327efe8ea0d > Provide a minimal cache/table configuration > --- > > Key: IGNITE-14235 > URL: https://issues.apache.org/jira/browse/IGNITE-14235 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: iep-72, ignite-3 > > Need to provide a way to configure a cache/table in accordance with IEP-55 > Unified Configuration [1] and IEP-54 Schema first approach. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration > [2] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14655) .NET: Do not return task from IDataStreamer.AddData method
Pavel Tupitsyn created IGNITE-14655:
---
Summary: .NET: Do not return task from IDataStreamer.AddData method
Key: IGNITE-14655
URL: https://issues.apache.org/jira/browse/IGNITE-14655
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.11
Currently, all {{AddData}} methods return a Task, however, this task is not for
an individual add/remove operation, but for the current batch.
This is confusing: users often try to {{await}} the returned task, which is
natural; but the task will never complete, because the batch is not yet full,
and user code is stuck waiting.
* Deprecate {{AddData}}, {{RemoveData}} methods
* Add new {{void Add}} and {{void Remove}} methods
* Add new {{BatchTask}} property to get the task for the current batch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14588) Calcite integration. Wrong processing of nested aggregates
[
https://issues.apache.org/jira/browse/IGNITE-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332999#comment-17332999
]
Konstantin Orlov commented on IGNITE-14588:
---
[~alex_pl], the patch looks good in general, but let's add one more test. Since
the problem is on planner side, let's add a planner test that verifies Single
and Reduce nodes could have only SINGLE distribution.
> Calcite integration. Wrong processing of nested aggregates
> --
>
> Key: IGNITE-14588
> URL: https://issues.apache.org/jira/browse/IGNITE-14588
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The wrong plan is created when nested aggregates are used.
> For example, this query:
> {{SELECT avg(salary) FROM (SELECT avg(salary) as salary FROM employer UNION
> ALL SELECT salary FROM employer)}}
> Generates such a plan:
> {noformat}
> IgniteReduceHashAggregate(group=[{}], AVG(SALARY)=[AVG($0)])
> IgniteExchange(distribution=[single])
> IgniteMapHashAggregate(group=[{}], AVG(SALARY)=[AVG($0)])
> IgniteUnionAll(all=[true])
> IgniteSingleHashAggregate(group=[{}], SALARY=[AVG($0)])
> IgniteIndexScan(table=[[PUBLIC, EMPLOYER]], index=[_key_PK],
> requiredColumns=[{3}])
> IgniteIndexScan(table=[[PUBLIC, EMPLOYER]], index=[_key_PK],
> requiredColumns=[{3}])
> {noformat}
> With this plan, in subquery data is aggregated locally on nodes and can
> produce the wrong results.
> For example:
> {code:java}
> @Test
> public void aggregateNested() throws Exception {
> String cacheName = "employer";
> IgniteCache employer = client.getOrCreateCache(new
> CacheConfiguration()
> .setName(cacheName)
> .setSqlSchema("PUBLIC")
> .setIndexedTypes(Integer.class, Employer.class)
> .setBackups(2)
> );
> awaitPartitionMapExchange(true, true, null);
> List keysNode0 = primaryKeys(grid(0).cache(cacheName), 2);
> List keysNode1 = primaryKeys(grid(1).cache(cacheName), 1);
> employer.putAll(ImmutableMap.of(
> keysNode0.get(0), new Employer("Igor", 1d),
> keysNode0.get(1), new Employer("Roman", 2d) ,
> keysNode1.get(0), new Employer("Nikolay", 3d)
> ));
> QueryEngine engine = Commons.lookupComponent(grid(1).context(),
> QueryEngine.class);
> List>> qry = engine.query(null, "PUBLIC",
> "SELECT avg(salary) FROM " +
> "(SELECT avg(salary) as salary FROM employer UNION ALL SELECT
> salary FROM employer)");
> assertEquals(1, qry.size());
> List> rows = qry.get(0).getAll();
> assertEquals(1, rows.size());
> assertEquals(2d, F.first(F.first(rows)));
> }
> {code}
> With this reproducer we should get 2 as a result (avg(1, 2, 3) = 2, avg(2, 1,
> 2, 3) = 2), but actual result is 2.1 (avg(1, 2) = 1.5, avg (3) = 3, avg(1.5,
> 3, 1, 2, 3) = 2.1).
> Root cause: default {{passThroughDistribution}} is not suitable for "reduce
> aggregate" and "single aggregate" nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[
https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332993#comment-17332993
]
Ignite TC Bot commented on IGNITE-6324:
---
{panel:title=Branch: [pull/8987/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}[Missing Tests]{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5983464]]
{color:#d04437}[Javadoc]{color} [[tests 0 BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=5983454]]
{panel}
{panel:title=Branch: [pull/8987/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5983465buildTypeId=IgniteTests24Java8_RunBasicTests]
> Transactional cache data partially available after crash and further recovery.
> --
>
> Key: IGNITE-6324
> URL: https://issues.apache.org/jira/browse/IGNITE-6324
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.10
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Critical
> Attachments: InterruptCommitedThreadTest.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If InterruptedException raise in client code during pds store operations we
> can obtain inconsistent cache after restart.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14496) Move configuration schemas and configuration annotations to ignite-api
[
https://issues.apache.org/jira/browse/IGNITE-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14496:
---
Description:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes with a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approaches to solve the problem, I'll try my best to describe
both.
h3. Common problem for both solutions
*ignite-configuration-annotation-processor* clearly depends on *ignite-api* in
our case AND at the same time *ignite-api* should use annotation processing. We
have cycling dependency. Right way of resolving it is to create module
*ignite-configuration-api*. This shows us that having +all+ API in one module
is probably not the best idea.
h3. Solution 1 - split annotation processor into 2
There's no doubt that we need processor that will generate first set of
interfaces. We already have it. We could create a second annotation processor
that will generate implementations into other modules, let's call it
*impl-processor*. But Java annotation processing API can't do that directly. If
we compile module *B* that depends on module *A*, only classes from *B* will be
passed into environment of *impl-processor*. We have to options of how to
resolve it:
* use libraries like [classgraph|https://github.com/classgraph/classgraph],
having *ignite-api* as hardcoded compiler dependency in annotation processor.
Works in theory BUT there are issues:
** there's no clear way of distinguishing schemas that you should process in
current module from those that you shouldn't;
** *ignite-api* dependency is hardcoded as an optional source of schemas,
which is a questionable thing.
* include package with desired schemas using maven helper plugin. This
approach also has issues:
** now we understand how to configure it, but such configuration will require
more manual steps and either separate package for modules schemas or
include/exclude list in helper plugin configuration;
** we will have several identical **.class* files in target directories of
different modules.
h3. Solution 2 - leave only one annotation processor and generate everything
else at runtime
This approach requires 0 additional configuration. {{Node}} and
{{ConfigurationImpl}} can be generated from schemas when you register new root
key. We already have *ignite-bytecode* module so there's no need for additional
libraries in dependencies. Usages of the module can be seen in module
*ignite-schema*. I assume that writing tests will be much easier with runtime
code generation. Also classes like {{InnerNode}} will probably become
package-private. The problems are:
* potential problems during debugging. I don't see it as a problem. Given that
we'll cover everything with tests, generator code will be pretty stable;
* generating code requires time. Doesn't look like it really needs a
significant amount of time though;
* we can start several nodes in a single JVM so there might be collisions of
other issues. The problem is purely technical;
* choice of {{ClassLoader}} for generated classes has to be very careful.
Situation when generated configuration class cannot be loaded for some reason
is unacceptable.
IMHO, second solution is better. The fact that API usage becomes better
overweights the fact that we would need to generate different parts of
configuration code using different tools.
was:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes at a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approaches to solve the problem, I'll try my best to describe
both.
h3. Common
[jira] [Updated] (IGNITE-14496) Move configuration schemas and configuration annotations to ignite-api
[
https://issues.apache.org/jira/browse/IGNITE-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-14496:
-
Description:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes at a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approaches to solve the problem, I'll try my best to describe
both.
h3. Common problem for both solutions
*ignite-configuration-annotation-processor* clearly depends on *ignite-api* in
our case AND at the same time *ignite-api* should use annotation processing. We
have cycling dependency. Right way of resolving it is to create module
*ignite-configuration-api*. This shows us that having +all+ API in one module
is probably not the best idea.
h3. Solution 1 - split annotation processor into 2
There's no doubt that we need processor that will generate first set of
interfaces. We already have it. We could create a second annotation processor
that will generate implementations into other modules, let's call it
*impl-processor*. But Java annotation processing API can't do that directly. If
we compile module *B* that depends on module *A*, only classes from *B* will be
passed into environment of *impl-processor*. We have two options of how to
resolve it:
* use libraries like [classgraph|https://github.com/classgraph/classgraph],
having *ignite-api* as hardcoded compiler dependency in annotation processor.
Works in theory BUT there are issues:
** there's no clear way of distinguishing schemas that you should process in
current module from those that you shouldn't;
** *ignite-api* dependency is hardcoded as an optional source of schemas,
which is a questionable thing.
* include package with desired schemas using maven helper plugin. This
approach also has issues:
** now we understand how to configure it, but such configuration will require
more manual steps and either separate package for modules schemas or
include/exclude list in helper plugin configuration;
** we will have several identical **.class* files in target directories of
different modules.
h3. Solution 2 - leave only one annotation processor and generate everything
else at runtime
This approach requires 0 additional configuration. {{Node}} and
{{ConfigurationImpl}} can be generated from schemas when you register new root
key. We already have *bytecode* module so there's no need for additional
libraries in dependencies. I assume that writing tests will be much easier with
runtime code generation. Also classes like {{InnerNode}} will probably become
package-private. The problems are:
* potential problems during debugging. I don't see it as a problem. Given that
we'll cover everything with tests, generator code will be pretty stable;
* generating code requires time. Doesn't look like it really needs a
significant amount of time though;
* we can start several nodes in a single JVM so there might be collisions of
other issues. The problem is purely technical.
IMHO, second solution is better. The fact that API usage becomes better
overweights the fact that we would need to generate different parts of
configuration code using different tools.
was:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes with a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approaches to solve the problem, I'll try my best to describe
both.
h3. Common problem for both solutions
*ignite-configuration-annotation-processor* clearly depends on *ignite-api* in
our case AND at the same time *ignite-api* should use annotation processing. We
have cycling dependency. Right way of resolving
