[jira] [Commented] (IGNITE-14497) Move background task deletion at the end of next checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316863#comment-17316863
]
Ignite TC Bot commented on IGNITE-14497:
{panel:title=Branch: [pull/8983/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8983/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=5956539buildTypeId=IgniteTests24Java8_RunAll]
> Move background task deletion at the end of next checkpoint
> ---
>
> Key: IGNITE-14497
> URL: https://issues.apache.org/jira/browse/IGNITE-14497
> Project: Ignite
> Issue Type: Bug
>Reporter: Maria Makedonskaya
>Assignee: Maria Makedonskaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In [1] has been described scenario of the race that makes possible a
> situation when information from metastore has been deleted and part of the
> index is still present in the storage.
> Actually, fix in [1] that has been done in slightly different way, however,
> it strongly decreases possibility of the race. Removal of the background task
> has been moved to beginning of the next checkpoint. It was done this way,
> because the problem was in case when node unexpectedly failed in the middle
> of next checkpoint and after restart task failed on check of deleted index
> metaPage. The check was done in [2].
> In current issue, we only move background task deletion at the end of the
> next checkpoint.
> [1][IGNITE-13382|https://issues.apache.org/jira/browse/IGNITE-13382]
> [2][IGNITE-14447|https://issues.apache.org/jira/browse/IGNITE-14447]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14497) Move background task deletion at the end of next checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316864#comment-17316864 ] Maria Makedonskaya commented on IGNITE-14497: - [~Denis Chudov], could you please review my changes? > Move background task deletion at the end of next checkpoint > --- > > Key: IGNITE-14497 > URL: https://issues.apache.org/jira/browse/IGNITE-14497 > Project: Ignite > Issue Type: Bug >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In [1] has been described scenario of the race that makes possible a > situation when information from metastore has been deleted and part of the > index is still present in the storage. > Actually, fix in [1] that has been done in slightly different way, however, > it strongly decreases possibility of the race. Removal of the background task > has been moved to beginning of the next checkpoint. It was done this way, > because the problem was in case when node unexpectedly failed in the middle > of next checkpoint and after restart task failed on check of deleted index > metaPage. The check was done in [2]. > In current issue, we only move background task deletion at the end of the > next checkpoint. > [1][IGNITE-13382|https://issues.apache.org/jira/browse/IGNITE-13382] > [2][IGNITE-14447|https://issues.apache.org/jira/browse/IGNITE-14447] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14502) Ignite 3: Consider JSON-formatted toString implementations
Alexey Goncharuk created IGNITE-14502:
-
Summary: Ignite 3: Consider JSON-formatted toString implementations
Key: IGNITE-14502
URL: https://issues.apache.org/jira/browse/IGNITE-14502
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
This is a follow-up for IGNITE-14501. Once {{GridToStringBuilder}} is ported to
Ignite 3, we may change the formatting to a JSON-like structure so that any
object can be beautified using standard tools.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8796) Client node is terminated by the Failure handler in case of dynamic cache start failed on that client node.
[
https://issues.apache.org/jira/browse/IGNITE-8796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-8796:
---
Assignee: Maxim Muzafarov
> Client node is terminated by the Failure handler in case of dynamic cache
> start failed on that client node.
> ---
>
> Key: IGNITE-8796
> URL: https://issues.apache.org/jira/browse/IGNITE-8796
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.6
>Reporter: Vyacheslav Koptilin
>Assignee: Maxim Muzafarov
>Priority: Major
>
> Let's consider the following scenario:
> 1. start a server node
> 2. start new client node and initiate dynamic cache start via
> {{Ignite.getOrCreateCache(CacheConfiguration)}} method.
> 3. let's assume that
> {{GridDhtPartitionsExchangeFuture.onCacheChangeRequest()}} results in
> {{Exception}} on the client node only.
> 4. In that case, the cache is considered as started on the server node. On
> the other hand, the client node is terminated by {{FailureHandler}}.
> It seems that this behavior can be improved using the same approach as server
> nodes.
> See IGNITE-1094 for the details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14501) Ignite 3: Fix toString implementations
Alexey Goncharuk created IGNITE-14501:
-
Summary: Ignite 3: Fix toString implementations
Key: IGNITE-14501
URL: https://issues.apache.org/jira/browse/IGNITE-14501
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Fix For: 3.0.0-alpha2
There is a number of places in the codebase where autogenerated IDEA
{{toString()}} implementations are used (for example, {{ModuleRegistry}},
{{NetworkMember}})) or non-conformant {{toString()}} implementations ({{Peer}}
in raft-client).
We need to fix the {{toString()}} implementations and move GridToStringBuilder
from Ignite 2.x to avoid further similar issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13970) [Ducktape: Thin client] Cache API Test
[ https://issues.apache.org/jira/browse/IGNITE-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-13970. -- Resolution: Fixed > [Ducktape: Thin client] Cache API Test > -- > > Key: IGNITE-13970 > URL: https://issues.apache.org/jira/browse/IGNITE-13970 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Evgeniya Vdovets >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > > Need to check put/get (atomic, tx) and other cache API works while the user > uses TC. > +jinja2 based spring configuration. > --- > Task: create new thin client compatibility test using Ducktape framework > Guess thin client interaction is already implemented in Ducktape > > Input params: > Thin client version > Server version > > Test plan: > 1. Start the server > 2. Start the client > 3. Create new cache > 4. Main cache operations: put, get, remove -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14321) Forced index rebuilding does not work correctly
[
https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316506#comment-17316506
]
Ignite TC Bot commented on IGNITE-14321:
{panel:title=Branch: [pull/8962/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8962/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5955588]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testForceRebuildIndexesAfterExchange - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testSequentialForceRebuildIndexes - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testSequentialRebuildIndexesOnExchange - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5955621buildTypeId=IgniteTests24Java8_RunAll]
> Forced index rebuilding does not work correctly
> ---
>
> Key: IGNITE-14321
> URL: https://issues.apache.org/jira/browse/IGNITE-14321
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> At the moment, it is not possible to force an index rebuild twice (or more)
> even if the first run fails, and this also applies to command *control.sh
> --cache indexes_force_rebuild*.
> Thus, we need to fix:
> * *GridCacheDatabaseSharedManager#forceRebuildIndexes*
> * *CacheIndexesForceRebuild#execute*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14289) Calcite flaky test testNotOriginatorNodeStop.
[ https://issues.apache.org/jira/browse/IGNITE-14289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-14289: -- Assignee: Aleksey Plekhanov > Calcite flaky test testNotOriginatorNodeStop. > -- > > Key: IGNITE-14289 > URL: https://issues.apache.org/jira/browse/IGNITE-14289 > Project: Ignite > Issue Type: Bug > Components: sql > Environment: !image-2021-03-09-10-10-19-314.png! > test is flaky for now. >Reporter: Stanilovsky Evgeny >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite > Attachments: image-2021-03-09-10-10-19-314.png > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13616) IEP-54 Live schema for tables
[ https://issues.apache.org/jira/browse/IGNITE-13616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13616: -- Labels: ignite-3 (was: iep-54 ignite-3) > IEP-54 Live schema for tables > - > > Key: IGNITE-13616 > URL: https://issues.apache.org/jira/browse/IGNITE-13616 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Umbrella ticket for > [IEP-54|https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13669) Implement date native types
[ https://issues.apache.org/jira/browse/IGNITE-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316385#comment-17316385 ] Andrey Mashenkov commented on IGNITE-13669: --- Data and date-time types occupy 3 and 7 bytes regarding the Layout. Does it make sense to align them to 4 and 8? > Implement date native types > > > Key: IGNITE-13669 > URL: https://issues.apache.org/jira/browse/IGNITE-13669 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > Besides the types themselves, it may be beneficial to provide date/time field > extraction methods so that they can be read without object creation. The > layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14499) TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again during reconnection
[ https://issues.apache.org/jira/browse/IGNITE-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316352#comment-17316352 ] Andrey Aleksandrov commented on IGNITE-14499: - Pull request - https://github.com/apache/ignite/pull/8981 > TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again > during reconnection > - > > Key: IGNITE-14499 > URL: https://issues.apache.org/jira/browse/IGNITE-14499 > Project: Ignite > Issue Type: Bug > Components: messaging >Affects Versions: 2.10 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Client reconnect logic has for the following scenarios: > 1)You have 3 servers. FQDN name can be resolved to one of them (but only to > reachable server node). > 2)You have 3 servers. FQDN name will be resolved to the list of the reachable > server IPs. > Results: > Thick clients do not try to resolve FQDN once again upon connection failure. > Reconnect doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14500) Add table exceptions to public API.
[ https://issues.apache.org/jira/browse/IGNITE-14500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14500: -- Labels: iep-54 ignite-3 (was: ) > Add table exceptions to public API. > --- > > Key: IGNITE-14500 > URL: https://issues.apache.org/jira/browse/IGNITE-14500 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > * Let's introduce TableExceptions for various cases to public API > * Replace any internal exception with the public one. > * Use correct error codes defined in IGNITE-3690 > * Describe possibly thrown exceptions in javadoc to the public API methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14495:
--
Labels: iep-54 ignite-3 (was: ignite-3)
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management.
> All other exception should extend them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14495:
--
Labels: ignite-3 (was: iep-54 ignite-3)
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management.
> All other exception should extend them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14500) Add table exceptions to public API.
Andrey Mashenkov created IGNITE-14500: - Summary: Add table exceptions to public API. Key: IGNITE-14500 URL: https://issues.apache.org/jira/browse/IGNITE-14500 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov * Let's introduce TableExceptions for various cases to public API * Replace any internal exception with the public one. * Use correct error codes defined in IGNITE-3690 * Describe possibly thrown exceptions in javadoc to the public API methods. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14499) TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again during reconnection
Andrey Aleksandrov created IGNITE-14499: --- Summary: TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again during reconnection Key: IGNITE-14499 URL: https://issues.apache.org/jira/browse/IGNITE-14499 Project: Ignite Issue Type: Bug Components: messaging Affects Versions: 2.10 Reporter: Andrey Aleksandrov Client reconnect logic has for the following scenarios: 1)You have 3 servers. FQDN name can be resolved to one of them (but only to reachable server node). 2)You have 3 servers. FQDN name will be resolved to the list of the reachable server IPs. Results: Thick clients do not try to resolve FQDN once again upon connection failure. Reconnect doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14499) TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again during reconnection
[ https://issues.apache.org/jira/browse/IGNITE-14499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov reassigned IGNITE-14499: --- Assignee: Andrey Aleksandrov > TcpDiscoveryVM IP Finder: thick client does not try to resolve the FQDN again > during reconnection > - > > Key: IGNITE-14499 > URL: https://issues.apache.org/jira/browse/IGNITE-14499 > Project: Ignite > Issue Type: Bug > Components: messaging >Affects Versions: 2.10 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > > Client reconnect logic has for the following scenarios: > 1)You have 3 servers. FQDN name can be resolved to one of them (but only to > reachable server node). > 2)You have 3 servers. FQDN name will be resolved to the list of the reachable > server IPs. > Results: > Thick clients do not try to resolve FQDN once again upon connection failure. > Reconnect doesn't work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316276#comment-17316276
]
Alexey Scherbakov commented on IGNITE-14459:
[~agoncharuk]
LGTM
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14498) Flag for enabling/disabling data region metrics works incorrectly
Aleksandr Polovtcev created IGNITE-14498:
Summary: Flag for enabling/disabling data region metrics works
incorrectly
Key: IGNITE-14498
URL: https://issues.apache.org/jira/browse/IGNITE-14498
Project: Ignite
Issue Type: Bug
Components: persistence
Reporter: Aleksandr Polovtcev
{{DataRegionMetricsImpl}} class has a {{metricsEnabled}} flag which toggles
some metrics collection. This flag can be changed in runtime (e.g. through
JMX), however, when switched off, it simply disables all metrics-related
activities in this class, which means that when turned back on, all counters
will be stale and all reported statistics will be wrong.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13546) Calcite integration. Hash index spool
[ https://issues.apache.org/jira/browse/IGNITE-13546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316242#comment-17316242 ] Konstantin Orlov commented on IGNITE-13546: --- [~tledkov-gridgain], the patch looks good to me > Calcite integration. Hash index spool > - > > Key: IGNITE-13546 > URL: https://issues.apache.org/jira/browse/IGNITE-13546 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Taras Ledkov >Priority: Critical > Original Estimate: 80h > Time Spent: 3h > Remaining Estimate: 77h > > To have a performance boost need to implement hash index spools. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14497) Move background task deletion at the end of next checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-14497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Makedonskaya updated IGNITE-14497: Description: In [1] has been described scenario of the race that makes possible a situation when information from metastore has been deleted and part of the index is still present in the storage. Actually, fix in [1] that has been done in slightly different way, however, it strongly decreases possibility of the race. Removal of the background task has been moved to beginning of the next checkpoint. It was done this way, because the problem was in case when node unexpectedly failed in the middle of next checkpoint and after restart task failed on check of deleted index metaPage. The check was done in [2]. In current issue, we only move background task deletion at the end of the next checkpoint. [1][IGNITE-13382|https://issues.apache.org/jira/browse/IGNITE-13382] [2][IGNITE-14447|https://issues.apache.org/jira/browse/IGNITE-14447] was: In [1] has been described scenario of the race that makes possible a situation when information from metastore has been deleted and part of the index is still present in the storage. Actually, fix in [1] that has been done in slightly different way, however, it strongly decreases possibility of the race. Removal of the background task has been moved to beginning of the next checkpoint. It was done this way, because the problem was in case when node unexpectedly failed in the middle of next checkpoint and after restart task failed on check of deleted index metaPage. The check was done in [2]. In current issue, we only move background task deletion at the end of the next checkpoint. [1]IGNITE-13382 [2]IGNITE-14447 > Move background task deletion at the end of next checkpoint > --- > > Key: IGNITE-14497 > URL: https://issues.apache.org/jira/browse/IGNITE-14497 > Project: Ignite > Issue Type: Bug >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > > In [1] has been described scenario of the race that makes possible a > situation when information from metastore has been deleted and part of the > index is still present in the storage. > Actually, fix in [1] that has been done in slightly different way, however, > it strongly decreases possibility of the race. Removal of the background task > has been moved to beginning of the next checkpoint. It was done this way, > because the problem was in case when node unexpectedly failed in the middle > of next checkpoint and after restart task failed on check of deleted index > metaPage. The check was done in [2]. > In current issue, we only move background task deletion at the end of the > next checkpoint. > [1][IGNITE-13382|https://issues.apache.org/jira/browse/IGNITE-13382] > [2][IGNITE-14447|https://issues.apache.org/jira/browse/IGNITE-14447] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14497) Move background task deletion at the end of next checkpoint
Maria Makedonskaya created IGNITE-14497: --- Summary: Move background task deletion at the end of next checkpoint Key: IGNITE-14497 URL: https://issues.apache.org/jira/browse/IGNITE-14497 Project: Ignite Issue Type: Bug Reporter: Maria Makedonskaya Assignee: Maria Makedonskaya In [1] has been described scenario of the race that makes possible a situation when information from metastore has been deleted and part of the index is still present in the storage. Actually, fix in [1] that has been done in slightly different way, however, it strongly decreases possibility of the race. Removal of the background task has been moved to beginning of the next checkpoint. It was done this way, because the problem was in case when node unexpectedly failed in the middle of next checkpoint and after restart task failed on check of deleted index metaPage. The check was done in [2]. In current issue, we only move background task deletion at the end of the next checkpoint. [1]IGNITE-13382 [2]IGNITE-14447 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14496) Move configuration schemas and configuration annotations to ignite-api
Semyon Danilov created IGNITE-14496: --- Summary: Move configuration schemas and configuration annotations to ignite-api Key: IGNITE-14496 URL: https://issues.apache.org/jira/browse/IGNITE-14496 Project: Ignite Issue Type: Sub-task Reporter: Semyon Danilov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14482) Update the code snippet
[
https://issues.apache.org/jira/browse/IGNITE-14482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14482:
-
Priority: Minor (was: Major)
> Update the code snippet
>
>
> Key: IGNITE-14482
> URL: https://issues.apache.org/jira/browse/IGNITE-14482
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Nikita Safonov
>Assignee: Igor Gusev
>Priority: Minor
> Labels: Documentation, documentation
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See the XML code snippet of this section:
> [https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery]
> and change the line
> {{}}
> {code:java}
> name="projectName" ref="YOUR_GOOGLE_PLATFORM_PROJECT_NAME"{code}
> {{}} to{{}}
> {code:java}
> name="projectName" value="YOUR_GOOGLE_PLATFORM_PROJECT_NAME" on both
> pages{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14482) Update the code snippet
[
https://issues.apache.org/jira/browse/IGNITE-14482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14482:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Update the code snippet
>
>
> Key: IGNITE-14482
> URL: https://issues.apache.org/jira/browse/IGNITE-14482
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Nikita Safonov
>Assignee: Igor Gusev
>Priority: Major
> Labels: Documentation, documentation
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See the XML code snippet of this section:
> [https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery]
> and change the line
> {{}}
> {code:java}
> name="projectName" ref="YOUR_GOOGLE_PLATFORM_PROJECT_NAME"{code}
> {{}} to{{}}
> {code:java}
> name="projectName" value="YOUR_GOOGLE_PLATFORM_PROJECT_NAME" on both
> pages{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14421) Get rid of useless waiting on grep
[
https://issues.apache.org/jira/browse/IGNITE-14421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-14421.
---
Resolution: Fixed
> Get rid of useless waiting on grep
> --
>
> Key: IGNITE-14421
> URL: https://issues.apache.org/jira/browse/IGNITE-14421
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>
> Currently, we wait 5 seconds after each grep miss
> {noformat}
> [DEBUG - 2021-03-25 18:08:09,577 - remoteaccount - _log - lineno:160]:
> ducker@ducker11: Running ssh command: jcmd | awk
> '/org.apache.ignite.internal.ducktest.utils.IgniteAwareApplicationService/ {
> print $1 }'
> [DEBUG - 2021-03-25 18:08:09,736 - remoteaccount - _log - lineno:160]:
> ducker@ducker11: Running ssh command: tail -c +1
> /mnt/service/logs/console.log | grep
> 'IGNITE_APPLICATION_FINISHED\|IGNITE_APPLICATION_BROKEN'
> [DEBUG - 2021-03-25 18:08:09,783 - remoteaccount - _log - lineno:160]:
> ducker@ducker11: Running ssh command: tail -c +1
> /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_BROKEN'
> [DEBUG - 2021-03-25 18:08:09,833 - remoteaccount - _log - lineno:160]:
> ducker@ducker11: Running ssh command 'tail -c +1
> /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_BROKEN'' exited with
> status 1 and message: b''
> [DEBUG - 2021-03-25 18:08:14,836 - remoteaccount - _log - lineno:160]:
> ducker@ducker11: Running ssh command: tail -c +1
> /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_FINISHED'
> {noformat}
> Let's get rid of this {{backoff_sec=5}} by default.
> Need to make it 0 if possible, or as small as possible.
> Usages with defined backoff_sec should be also checked to minimization
> availability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14258) Ducktests code de-duplication and simplification
[ https://issues.apache.org/jira/browse/IGNITE-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-14258. --- Resolution: Fixed > Ducktests code de-duplication and simplification > > > Key: IGNITE-14258 > URL: https://issues.apache.org/jira/browse/IGNITE-14258 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > The goal is to perform pre-merge review of the whole ducktests code and > refactor it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (IGNITE-14258) Ducktests code de-duplication and simplification
[ https://issues.apache.org/jira/browse/IGNITE-14258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reopened IGNITE-14258: --- > Ducktests code de-duplication and simplification > > > Key: IGNITE-14258 > URL: https://issues.apache.org/jira/browse/IGNITE-14258 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > The goal is to perform pre-merge review of the whole ducktests code and > refactor it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14483) Ignite_app and ignite clean_up
[ https://issues.apache.org/jira/browse/IGNITE-14483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316116#comment-17316116 ] Anton Vinogradov commented on IGNITE-14483: --- Merged into ignite-ducktape > Ignite_app and ignite clean_up > -- > > Key: IGNITE-14483 > URL: https://issues.apache.org/jira/browse/IGNITE-14483 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Clean up and simplify. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14495:
--
Fix Version/s: 3.0.0-alpha2
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha2
>
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management.
> All other exception should extend them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Description:
We need common internal checked and unchecked exceptions like
{code:java}
IgniteInternalException, IgniteInternalCheckedException{code}
to standartize error management.
All other exception should extend them.
was:
We need common internal checked and unchecked exceptions like
{code:java}
IgniteInternalException, IgniteInternalCheckedException{code}
to standartize error management.
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management.
> All other exception should extend them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Description:
We need common internal checked and unchecked exceptions like
{code:java}
IgniteInternalException, IgniteInternalCheckedException{code}
to standartize error management.
was:
We need common internal checked and unchecked exceptions like
{code:java}
IgniteInternalException, IgniteInternalCheckedException{code}
to standartize error management in the future.
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Labels: ignite-3 (was: )
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Description:
We need common internal checked and unchecked exceptions like
{code:java}
IgniteInternalException, IgniteInternalCheckedException{code}
to standartize error management in the future.
was:
We need common checked and unchecked exceptions like
{code:java}
IgniteException, IgniteCheckedException{code}
to standartize error management in the future.
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>
> We need common internal checked and unchecked exceptions like
> {code:java}
> IgniteInternalException, IgniteInternalCheckedException{code}
> to standartize error management in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common internal ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Summary: Add common internal ignite exceptions (was: Add common ignite
exceptions)
> Add common internal ignite exceptions
> -
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>
> We need common checked and unchecked exceptions like
> {code:java}
> IgniteException, IgniteCheckedException{code}
> to standartize error management in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Description:
We need common checked and unchecked exceptions like
{code:java}
IgniteException, IgniteCheckedException{code}
to standartize error management in the future.
was:
We need common checked and unchecked exceptions like
{code:java}
IgniteException, IgniteCheckedException{code}
to simplify error management in the future.
> Add common ignite exceptions
>
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>
> We need common checked and unchecked exceptions like
> {code:java}
> IgniteException, IgniteCheckedException{code}
> to standartize error management in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14495) Add common ignite exceptions
[
https://issues.apache.org/jira/browse/IGNITE-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14495:
---
Description:
We need common checked and unchecked exceptions like
{code:java}
IgniteException, IgniteCheckedException{code}
to simplify error management in the future.
was:We need common checked and unchecked exceptions like IgniteException,
IgniteCheckedException to simplify error management in the future.
> Add common ignite exceptions
>
>
> Key: IGNITE-14495
> URL: https://issues.apache.org/jira/browse/IGNITE-14495
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>
> We need common checked and unchecked exceptions like
> {code:java}
> IgniteException, IgniteCheckedException{code}
> to simplify error management in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14495) Add common ignite exceptions
Alexey Scherbakov created IGNITE-14495: -- Summary: Add common ignite exceptions Key: IGNITE-14495 URL: https://issues.apache.org/jira/browse/IGNITE-14495 Project: Ignite Issue Type: Task Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov We need common checked and unchecked exceptions like IgniteException, IgniteCheckedException to simplify error management in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14321) Forced index rebuilding does not work correctly
[ https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315996#comment-17315996 ] Stanilovsky Evgeny commented on IGNITE-14321: - check my comments plz > Forced index rebuilding does not work correctly > --- > > Key: IGNITE-14321 > URL: https://issues.apache.org/jira/browse/IGNITE-14321 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 2.5h > Remaining Estimate: 0h > > At the moment, it is not possible to force an index rebuild twice (or more) > even if the first run fails, and this also applies to command *control.sh > --cache indexes_force_rebuild*. > Thus, we need to fix: > * *GridCacheDatabaseSharedManager#forceRebuildIndexes* > * *CacheIndexesForceRebuild#execute* -- This message was sent by Atlassian Jira (v8.3.4#803005)
