[jira] [Updated] (IGNITE-21293) Scan cursors do not close on transaction recovery
[ https://issues.apache.org/jira/browse/IGNITE-21293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21293: --- Epic Link: IGNITE-21221 > Scan cursors do not close on transaction recovery > - > > Key: IGNITE-21293 > URL: https://issues.apache.org/jira/browse/IGNITE-21293 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Open cursors required extra memory on the server side. Hence, resources > cannot be stored for a long time. > h3. Implementation notes > During the recovery procedure, the server receives a cleanup message (the > message releases locks). On the message processing, we update the local > transaction state, and it should also close all the cursors related to this > transaction. > h3. Definition of done > All cursors should be closed on the RW transaction recovery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21291) Scan cursors do not close when an RO transaction is finalized
[ https://issues.apache.org/jira/browse/IGNITE-21291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21291: --- Epic Link: IGNITE-21221 > Scan cursors do not close when an RO transaction is finalized > - > > Key: IGNITE-21291 > URL: https://issues.apache.org/jira/browse/IGNITE-21291 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > The cursors are opened on the server side and take up extra memory. When an > RW transaction is committed, we send the transaction cleanup messages to all > transaction participants. But the state of the RO transaction is strung > locally, so do not send any messages to the transaction participants (where > the cursors were opened). > h3. Definition of done > Cursors for RO transactions are closed somehow. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21290: - Epic Link: IGNITE-21221 > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21290: --- Reviewer: Alexander Lapin > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-20574: --- Assignee: Evgeny Stanilovsky (was: Maksim Zhuravkov) > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20574) Sql. Do not permit to create tables in SYSTEM schema.
[ https://issues.apache.org/jira/browse/IGNITE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-20574: Ignite Flags: (was: Docs Required,Release Notes Required) > Sql. Do not permit to create tables in SYSTEM schema. > - > > Key: IGNITE-20574 > URL: https://issues.apache.org/jira/browse/IGNITE-20574 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, The SYSTEM schema should only contain only system view objects; > adding other objects to this schema should not be allowed. > But it is possible to create a table in the SYSTEM schema. We need to > disallow that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20495) Sql. Provide IgniteTableModify with source id
[
https://issues.apache.org/jira/browse/IGNITE-20495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20495:
-
Assignee: Maksim Zhuravkov
> Sql. Provide IgniteTableModify with source id
> --
>
> Key: IGNITE-20495
> URL: https://issues.apache.org/jira/browse/IGNITE-20495
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, IgniteTableModify doesn't implement interface
> SourceAwareIgniteRel, and, as a result, is not being assigned its own source
> id, although requires to be mapped on particular set of nodes with regards to
> the distribution of the table it modifies.
> To fully integrate TableModify into mapping process, let's make it implement
> SourceAwareIgniteRel. This id should be used during mapping phase to create
> colocation group properly, and inside execution to acquire assignments. See
> usages of {{UpdatableTableImpl#MODIFY_NODE_SOURCE_ID}} to find all places
> that should be changed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20829) Remove "basicAuthentication" prefix from JDBC url connection properties
[ https://issues.apache.org/jira/browse/IGNITE-20829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20829: - Assignee: Maksim Zhuravkov > Remove "basicAuthentication" prefix from JDBC url connection properties > --- > > Key: IGNITE-20829 > URL: https://issues.apache.org/jira/browse/IGNITE-20829 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Aleksandr >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > > It looks confusing for the user to put basicAuthenticationUsername and > basicAuthenticationPassword properties into jdbc connection string. I propose > rename them into user/password. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21335: Labels: ignite-3 (was: ) > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21334: --- Assignee: Pavel Tupitsyn > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21335: Ignite Flags: (was: Docs Required,Release Notes Required) > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21335: Component/s: platforms > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21335: Summary: C++ 3.0: Implement JobExecutionOptions (was: Implement JobExecutionOptions in C++ client) > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21334: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21334: Component/s: platforms > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21334: Summary: .NET: Thin 3.0: Implement JobExecutionOptions (was: Implement JobExecutionOptions in C# client) > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21334: Labels: ignite-3 (was: ) > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21334) .NET: Thin 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21334: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Thin 3.0: Implement JobExecutionOptions > - > > Key: IGNITE-21334 > URL: https://issues.apache.org/jira/browse/IGNITE-21334 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21336) Retry a network send failed due to ClosedChannelException
[ https://issues.apache.org/jira/browse/IGNITE-21336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21336: --- Description: We have a connection recovery mechanism that transparently re-establishes a connection whose Channel was closed. This means that a sender should never see ClosedChannelException as a result of a send. There is a race now that allows a sender to get such an exception. A retry logic should be added (in DefaultMessagingService) to make sure this exception just caused a retry (leading to reestablishing the connection or failing to reestablish it). > Retry a network send failed due to ClosedChannelException > - > > Key: IGNITE-21336 > URL: https://issues.apache.org/jira/browse/IGNITE-21336 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We have a connection recovery mechanism that transparently re-establishes a > connection whose Channel was closed. This means that a sender should never > see ClosedChannelException as a result of a send. There is a race now that > allows a sender to get such an exception. > A retry logic should be added (in DefaultMessagingService) to make sure this > exception just caused a retry (leading to reestablishing the connection or > failing to reestablish it). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21336) Retry a network send failed due to ClosedChannelException
Roman Puchkovskiy created IGNITE-21336: -- Summary: Retry a network send failed due to ClosedChannelException Key: IGNITE-21336 URL: https://issues.apache.org/jira/browse/IGNITE-21336 Project: Ignite Issue Type: Improvement Components: networking Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21335) Implement JobExecutionOptions in C++ client
Dmitry Baranov created IGNITE-21335: --- Summary: Implement JobExecutionOptions in C++ client Key: IGNITE-21335 URL: https://issues.apache.org/jira/browse/IGNITE-21335 Project: Ignite Issue Type: Task Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Dmitry Baranov Fix For: 3.0.0-beta2 Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21334) Implement JobExecutionOptions in C# client
Dmitry Baranov created IGNITE-21334: --- Summary: Implement JobExecutionOptions in C# client Key: IGNITE-21334 URL: https://issues.apache.org/jira/browse/IGNITE-21334 Project: Ignite Issue Type: Task Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Dmitry Baranov Fix For: 3.0.0-beta2 Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Description:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wants to get.
was:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wanted to get.
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider what part of
> CacheConfiguration's a user wants to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21333) Remove internal class from the dump consumer public API
Vladimir Steshin created IGNITE-21333:
-
Summary: Remove internal class from the dump consumer public API
Key: IGNITE-21333
URL: https://issues.apache.org/jira/browse/IGNITE-21333
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider which
CacheConfiguration's data user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Description:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider what part of
CacheConfiguration's a user wanted to get.
was:
{code:java}
org.apache.ignite.dump.DumpConsumer
{code}
is a public API. But it has an internal class StoredCacheData as a parameter in
{code:java}
void onCacheConfigs(Iterator caches);
{code}
We should change it to CacheConfiguration. Or we may consider which
CacheConfiguration's data user wanted to get.
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider what part of
> CacheConfiguration's a user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21333) Remove internal class from the dump consumer public API
[
https://issues.apache.org/jira/browse/IGNITE-21333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-21333:
--
Labels: ise (was: )
> Remove internal class from the dump consumer public API
> ---
>
> Key: IGNITE-21333
> URL: https://issues.apache.org/jira/browse/IGNITE-21333
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
>
> {code:java}
> org.apache.ignite.dump.DumpConsumer
> {code}
> is a public API. But it has an internal class StoredCacheData as a parameter
> in
> {code:java}
> void onCacheConfigs(Iterator caches);
> {code}
> We should change it to CacheConfiguration. Or we may consider which
> CacheConfiguration's data user wanted to get.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21227) Monitor network critical threads for being blocked
[ https://issues.apache.org/jira/browse/IGNITE-21227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809534#comment-17809534 ] Roman Puchkovskiy commented on IGNITE-21227: Thanks > Monitor network critical threads for being blocked > -- > > Key: IGNITE-21227 > URL: https://issues.apache.org/jira/browse/IGNITE-21227 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3, threading > Fix For: 3.0.0-beta2 > > Time Spent: 4h > Remaining Estimate: 0h > > If a netty thread or an inbound thread gets blocked, this might cause a node > freeze. We need to monitor such situations to: > # Have ability to see such blockages in logs > # See the thread dump corresponding to the blockage moment to make it > possible diagnose the root cause of the blockage > There is a mechanism in AI2 that allows doing so, and it's (at least > partially) ported to AI3, it is about Ignitethreads and IgniteWorkers. > Netty and inbound threads are currently not using the IgniteWorkers > mechanism. We need to either use it or adapt them to include them in this > monitoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20361) Implement the table storage description
[ https://issues.apache.org/jira/browse/IGNITE-20361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20361: - Fix Version/s: 3.0.0-beta2 > Implement the table storage description > --- > > Key: IGNITE-20361 > URL: https://issues.apache.org/jira/browse/IGNITE-20361 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > *Motivation* > According to IGNITE-20357 we need to have an appropriate table storage > configuration, which can be used on the table create/alter to check if the > chosen zone has appropriate storage requirements. > *Definition of done* > - Table has the storage configuration, which can be used for early validation > if table can be "deployed" in its zone correctly. > - Data storage configuration removed from zone configuration > *Notes* > - Avoid altering of this field for now with appropriate exception -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21265) Implement cleaner worker
[ https://issues.apache.org/jira/browse/IGNITE-21265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-21265: Description: We need a basic cleaner infrastructure at least for: # Collecting garbage versions # Collecting expired entries on table # Collecting expired entries on cache The cleaner is a worker thread accepting a various types of fine-grained tasks. Each task represents a small action: for example, collect garbage for a single version chain or to collect single expired record. Number of workers can be configured by a user. was: We need a basic cleaner infrastructure for: # Collecting garbage versions # Collecting expired entries on table # Collecting expired entries on cache The cleaner is a worker thread accepting a various types of fine-grained tasks. Each task represents a small action: for example, collect garbage for a single version chain or to collect single expired record. Number of workers can be configured by a user. > Implement cleaner worker > > > Key: IGNITE-21265 > URL: https://issues.apache.org/jira/browse/IGNITE-21265 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > > We need a basic cleaner infrastructure at least for: > # Collecting garbage versions > # Collecting expired entries on table > # Collecting expired entries on cache > The cleaner is a worker thread accepting a various types of fine-grained > tasks. > Each task represents a small action: for example, collect garbage for a > single version chain or to collect single expired record. > Number of workers can be configured by a user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20209) Catch-up rebalance triggers on node restart
[
https://issues.apache.org/jira/browse/IGNITE-20209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809485#comment-17809485
]
Alexander Lapin commented on IGNITE-20209:
--
[~kgusakov] LGTM, Thanks!
> Catch-up rebalance triggers on node restart
> ---
>
> Key: IGNITE-20209
> URL: https://issues.apache.org/jira/browse/IGNITE-20209
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation
> Please check https://issues.apache.org/jira/browse/IGNITE-20187 for more
> context, that is about catching-up assignments.pending meta storage keys,
> whether given one is about catching-up its triggers:
> * Replica factor updates.
> * Partitions count updates. Immutable for now.
> * Data nodes updates.
> * Replica storage addition/removal. !By the way, is it possible to remove
> replica storage.
> For all aforementioned cases, it's required to update distributed assignments
> pending (planned) keys if it's not yet done. And the only difficulty here is
> precisely in understanding whether this was done or not.
> h3. Definition of Done
> Updated distributed assignments pending(planned) keys if necessary according
> to the current triggers state.
>
> Notes:
> 1) -Add to metastorage starting revision-
> ({{{}metaStorageMgr.recoveryFinishedFuture(){}}} returns long with the
> maximal recovered revision)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[
https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-21326:
---
Assignee: (was: Pavel Tupitsyn)
> .NET: Thin 3.0: Out of memory: Java heap space in tests
> ---
>
> Key: IGNITE-21326
> URL: https://issues.apache.org/jira/browse/IGNITE-21326
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: screenshot-1.png
>
>
> Happens more and more often lately:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
> {code:java}
> Out of memory: Java heap space (This problem is reported because
> OutOfMemoryError has been found in the build log text)
> {code}
> Investigate heap dumps from TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[
https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809477#comment-17809477
]
Pavel Tupitsyn commented on IGNITE-21326:
-
Most of the memory is consumed by hundreds of byte arrays within
*AppendEntriesRequestImpl* instances:
!screenshot-1.png!
> .NET: Thin 3.0: Out of memory: Java heap space in tests
> ---
>
> Key: IGNITE-21326
> URL: https://issues.apache.org/jira/browse/IGNITE-21326
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: screenshot-1.png
>
>
> Happens more and more often lately:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
> {code:java}
> Out of memory: Java heap space (This problem is reported because
> OutOfMemoryError has been found in the build log text)
> {code}
> Investigate heap dumps from TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[
https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21326:
Attachment: screenshot-1.png
> .NET: Thin 3.0: Out of memory: Java heap space in tests
> ---
>
> Key: IGNITE-21326
> URL: https://issues.apache.org/jira/browse/IGNITE-21326
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Attachments: screenshot-1.png
>
>
> Happens more and more often lately:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
> {code:java}
> Out of memory: Java heap space (This problem is reported because
> OutOfMemoryError has been found in the build log text)
> {code}
> Investigate heap dumps from TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[
https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809476#comment-17809476
]
Pavel Tupitsyn commented on IGNITE-21326:
-
Lots of warning is the log:
{code}
Received entries of which the lastLog=45838 is not greater than
appliedIndex=70732, return immediately with nothing changed.
{code}
> .NET: Thin 3.0: Out of memory: Java heap space in tests
> ---
>
> Key: IGNITE-21326
> URL: https://issues.apache.org/jira/browse/IGNITE-21326
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Happens more and more often lately:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
> {code:java}
> Out of memory: Java heap space (This problem is reported because
> OutOfMemoryError has been found in the build log text)
> {code}
> Investigate heap dumps from TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21318) Add configuration for critical workers monitoring
[ https://issues.apache.org/jira/browse/IGNITE-21318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-21318: -- Assignee: Roman Puchkovskiy > Add configuration for critical workers monitoring > - > > Key: IGNITE-21318 > URL: https://issues.apache.org/jira/browse/IGNITE-21318 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In IGNITE-21227, monitoring of critical worker threads' liveness was added. > Things like 'how often to check for lagging threads', 'how much lag to allow' > are now hardcoded (see CriticalThreadWatchdog). They need to be configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21332) nodeCannotCommunicateAfterLeavingPhysicalTopology is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21332: --- Description: ItScaleCubeNetworkMessagingTest#nodeCannotCommunicateAfterLeavingPhysicalTopology() is flaky, it fails with java.lang.AssertionError: Expected: a future that completes with an exception that is an instance of org.apache.ignite.internal.network.handshake.HandshakeException but: was completed exceptionally with java.lang.AssertionError: Expected: a future that completes with an exception that is an instance of org.apache.ignite.internal.network.handshake.HandshakeException but: was completed exceptionally with at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at org.apache.ignite.network.scalecube.ItScaleCubeNetworkMessagingTest.nodeCannotCommunicateAfterLeavingPhysicalTopology(ItScaleCubeNetworkMessagingTest.java:550) The problem seems to be that there is a race between closing channels when a node is removed from the physical topology and trying to send a message in the test. We should expect not just HandshakeException, but also ClosedChannelException. > nodeCannotCommunicateAfterLeavingPhysicalTopology is flaky > -- > > Key: IGNITE-21332 > URL: https://issues.apache.org/jira/browse/IGNITE-21332 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > ItScaleCubeNetworkMessagingTest#nodeCannotCommunicateAfterLeavingPhysicalTopology() > is flaky, it fails with > > java.lang.AssertionError: Expected: a future that completes with an exception > that is an instance of > org.apache.ignite.internal.network.handshake.HandshakeException but: was > completed exceptionally with > java.lang.AssertionError: > Expected: a future that completes with an exception that is an instance of > org.apache.ignite.internal.network.handshake.HandshakeException > but: was completed exceptionally with > > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) > at > org.apache.ignite.network.scalecube.ItScaleCubeNetworkMessagingTest.nodeCannotCommunicateAfterLeavingPhysicalTopology(ItScaleCubeNetworkMessagingTest.java:550) > > The problem seems to be that there is a race between closing channels when a > node is removed from the physical topology and trying to send a message in > the test. We should expect not just HandshakeException, but also > ClosedChannelException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21332) nodeCannotCommunicateAfterLeavingPhysicalTopology is flaky
Roman Puchkovskiy created IGNITE-21332: -- Summary: nodeCannotCommunicateAfterLeavingPhysicalTopology is flaky Key: IGNITE-21332 URL: https://issues.apache.org/jira/browse/IGNITE-21332 Project: Ignite Issue Type: Bug Components: networking Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21103) Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809467#comment-17809467 ] Pavel Tupitsyn commented on IGNITE-21103: - Merged to main: 0442153b7488d1b7cd1573aae35a4285a07140f4 > Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize > -- > > Key: IGNITE-21103 > URL: https://issues.apache.org/jira/browse/IGNITE-21103 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > Rename *DataStreamerOptions.batchSize* to *pageSize* to be consistent with > cursors and other APIs. > Update Java and .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21212) Increment and Decrement REST API documentation lists incorrect parameter
[ https://issues.apache.org/jira/browse/IGNITE-21212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809466#comment-17809466 ] Igor Gusev commented on IGNITE-21212: - [~ibelyakov] fixed, removed it from URL as well. > Increment and Decrement REST API documentation lists incorrect parameter > > > Key: IGNITE-21212 > URL: https://issues.apache.org/jira/browse/IGNITE-21212 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.16 >Reporter: Igor Belyakov >Assignee: Igor Gusev >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > The documentation for the Increment/Decrement REST API endpoints > (https://ignite.apache.org/docs/latest/restapi#increment) contains > information regarding the "cacheName" parameter, which in fact this endpoint > doesn't have. > (see: > [https://github.com/apache/ignite/blob/ignite-2.16/modules/core/src/main/java/org/apache/ignite/internal/processors/rest/request/DataStructuresRequest.java]) > This redundant parameter could be confusing since with it the endpoint looks > like an API to increment/decrement the value stored in the cache, while in > fact it is related to the IgniteAtomicLong data structure. (see > [https://ignite.apache.org/docs/latest/data-structures/atomic-types]). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21238) Add backfill index status to catalog
[ https://issues.apache.org/jira/browse/IGNITE-21238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809463#comment-17809463 ] Roman Puchkovskiy commented on IGNITE-21238: The patch looks good to me > Add backfill index status to catalog > > > Key: IGNITE-21238 > URL: https://issues.apache.org/jira/browse/IGNITE-21238 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > To implement IGNITE-21115, we need to add the "backfill" index status to the > catalog along with the transition event to this status. > It is also proposed, as part of the current ticket, to make a transition to > immediately after creating the index until ticket IGNITE-21115 is implemented. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21103) Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809459#comment-17809459 ] Igor Sapego commented on IGNITE-21103: -- Looks good to me. > Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize > -- > > Key: IGNITE-21103 > URL: https://issues.apache.org/jira/browse/IGNITE-21103 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Rename *DataStreamerOptions.batchSize* to *pageSize* to be consistent with > cursors and other APIs. > Update Java and .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21328) Fix logging in LowWatermark#start when there is no low watermark in vault
[ https://issues.apache.org/jira/browse/IGNITE-21328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809456#comment-17809456 ] Philipp Shergalis commented on IGNITE-21328: https://github.com/apache/ignite-3/pull/3073 > Fix logging in LowWatermark#start when there is no low watermark in vault > - > > Key: IGNITE-21328 > URL: https://issues.apache.org/jira/browse/IGNITE-21328 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > When starting a node, there is confusing logging at > *org.apache.ignite.internal.table.distributed.LowWatermark#start* in the > absence of a low watermark in the vault. > Example message *Low watermark has been successfully got from the vault and > is scheduled to be updated: null* it needs to be changed to something like > "Previous value of the low watermark was not found, will schedule to update > it". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21115) Wait for completion of transactions started before index appearance
[
https://issues.apache.org/jira/browse/IGNITE-21115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-21115:
Assignee: Kirill Tkalenko
> Wait for completion of transactions started before index appearance
> ---
>
> Key: IGNITE-21115
> URL: https://issues.apache.org/jira/browse/IGNITE-21115
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When an index is created (and appears in the REGISTERED state), we must wait
> for all transactions started on schemas before the index has appeared to
> finish.
> Primary replica of the partition zero of the table owning the created index
> is responsible for the wait.
> # When a node sees appearance of a REGISTERED index state in the Catalog,
> and it’s a primary of partition zero of the table owning the index, it starts
> the waiter
> # When a node becomes the primary of the partition zero of a table, and the
> table contains indices that are in the REGISTERED state (at the moment of the
> primary lease start), it starts a waiter per each such index
> # When a node ceases to be the primary of the partition zero of a table, it
> stops all the waiters it started
> # When the waiter finishes its waiting and the node is still a primary, it
> switches the index to the BACKFILLING state
> h5. Waiter operation
> # Wait for HLC.now() to become greater than ActivationMoment(index
> REGISTERED state) + MaxClockSkew (to make sure that the REGISTERED state
> activates on each node in the cluster)
> # Take all nodes in the cluster Logical Topology (LT) from the CMG Leader
> (not from the local state delivered by CMG learners) and put it in the
> *Nodes* list. ({*}Nodes{*} contains all the nodes that might have started RW
> transactions on schemas before the index appeared; other nodes had either
> left the topology, or they can only coordinate RW transactions started on
> schema versions containing the index)
> Poll each node in the *Nodes* list until either its RwTransactionsFinished(V)
> (see IGNITE-21112) returns true (where V is the catalog version where the
> index had appeared) or the node leaves the LT (if the node leaves the
> Physical Topology, we proceed waiting till it falls off the LT).
> After the waiter finishes, we must switch the index to the BACKFILLING state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21331) Sql. TPC-H q2 query hangs with sc=0.01
Konstantin Orlov created IGNITE-21331: - Summary: Sql. TPC-H q2 query hangs with sc=0.01 Key: IGNITE-21331 URL: https://issues.apache.org/jira/browse/IGNITE-21331 Project: Ignite Issue Type: Bug Components: sql Reporter: Konstantin Orlov The query q2 from TPC-H suite hangs for hours on cluster of 3 nodes with scale factor 0.01. Let's investigate and fix the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-21290: -- Assignee: Vladislav Pyatkov > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-21290: --- Description: h3. Motivation Open cursors require extra memory on the server side, so they should be closed as soon as they are no longer used. It is easy to understand on the coursor owner server when the coursor returns false for the hasNext invocation. Despite the fact that all acquired transaction resources should be released after the transaction finalizes, it would be better to close usles coursorse faseter. Moreover, the agreement is fit for all types of transactions: RO, RW, and inplicit. h3. Implementation notes When the replica returns a batch, their size can be estimated, and the cursor can be closed if the size is less than requested. h3. Definition of done A cursor is closed on the server side when the client retrieves all data from it through any type of scan operation. Moreover, the server-side cursors should be closed in case the cursor supplier is closing through the API. was: h3. Motivation Open cursors require extra memory on the server side, so they should be closed as soon as they are no longer used. It is easy to understand on the coursor owner server when the coursor returns false for the hasNext invocation. Despite the fact that all acquired transaction resources should be released after the transaction finalizes, it would be better to close usles coursorse faseter. Moreover, the agreement is fit for all types of transactions: RO, RW, and inplicit. h3. Implementation notes A course can be closed after the _isUpperBoundAchieved_ return is false. Cover all variant scan operations in tests. Get rid of the nonsensical message: _ScanCloseReplicaRequest_ h3. Definition of done A cursor is closed on the server side when the client retrieves all data from it through any type of scan operation. > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20973) Unusable thin client timeout
[ https://issues.apache.org/jira/browse/IGNITE-20973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-20973: Assignee: Igor Sapego > Unusable thin client timeout > > > Key: IGNITE-20973 > URL: https://issues.apache.org/jira/browse/IGNITE-20973 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.16, 2.17 >Reporter: Egor Fomin >Assignee: Igor Sapego >Priority: Major > Labels: ise > > Ignite thin client currently uses the same timeout value for request timeout > and connection timeout. > Connection timeout should be small enough(several seconds) while request > timeout should be able to handle long running requests. This makes Ignite > timeout unusable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
Konstantin Orlov created IGNITE-21330:
-
Summary: Sql. Index is not used for IN predicate with column type
of UUID
Key: IGNITE-21330
URL: https://issues.apache.org/jira/browse/IGNITE-21330
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Konstantin Orlov
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
[
https://issues.apache.org/jira/browse/IGNITE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21325:
--
Epic Link: IGNITE-21174
> Hold the transactional requests processing while the primary expired event
> processing is in progress
>
>
> Key: IGNITE-21325
> URL: https://issues.apache.org/jira/browse/IGNITE-21325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> No processing of any transactional request should be started when the event
> processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is
> that such requests may try to acquire transactional locks on the current
> primary replica, and the locks acquired during the previous lease are
> released by the listener of PRIMARY_REPLICA_EXPIRED event. The validity of
> the current primary is checked in
> {{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
> We must ensure that this method is called after the processing of
> PRIMARY_REPLICA_EXPIRED event. The future returned by
> {{PlacementDriver#previousPrimaryExpired}} can be used for this.
> Definition of done
> The processing of transactional requests for the current primary replica
> can't be started before the processing of PRIMARY_REPLICA_EXPIRED event
> finishes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21258) Handle primary replica events in the striped pool
[
https://issues.apache.org/jira/browse/IGNITE-21258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21258:
--
Epic Link: IGNITE-21174
> Handle primary replica events in the striped pool
> -
>
> Key: IGNITE-21258
> URL: https://issues.apache.org/jira/browse/IGNITE-21258
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> We seek to decrease the load on the metastorage thread because when the MC
> thread is holding, it blocks the handling of other events.
> {code}
> placementDriver.listen(PrimaryReplicaEvent.PRIMARY_REPLICA_ELECTED,
> this::onPrimaryReplicaElected);
> placementDriver.listen(PrimaryReplicaEvent.PRIMARY_REPLICA_EXPIRED,
> this::onPrimaryReplicaExpired);
> {code}
> Currently, both primary replica events are handled on the MC thread, though
> the striped executer is a well-suited place to do it.
> h3. Defenition of done
> Move handling of the primary replica events (PRIMARY_REPLICA_ELECTED,
> PRIMARY_REPLICA_EXPIRED) in the striped pool.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21213) Coordination of mechanisms of determination for primary on replicaside
[
https://issues.apache.org/jira/browse/IGNITE-21213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21213:
--
Description:
h3. Motivation
In the replica listener, we have unconsidered mechanisms between each other to
determine primary rteplica. The first one is based on the placement driver API
(it is used in {_}PartitionReplicaListener#ensureReplicaIsPrimary{_}) and the
other one is based on the placement driver events (the events are hadeled by
two methods: {_}ReplicaManager#onPrimaryReplicaElected{_},
{_}ReplicaManager#onPrimaryReplicaExpired{_}).
Because the replica messages and events are handled in different threads, any
variety of processing is possible. For example, the replica can release all
transaction locks (by PRIMARY_REPLICA_EXPIRED event) and then handle a message
for this transaction (because ensureReplicaIsPrimary was done before), assuming
that all the locks are holding.
h3. Definition of done
The simultaneous processing of transactional requests and
PRIMARY_REPLICA_EXPIRED is impossible.
*Implementation notes*
We must take into account and prevent the possible deadlocks, such as:
* the transactional request is trying to acquire the lock on the key A
* the processing of the PRIMARY_REPLICA_EXPIRED cannot start because the
aforementioned request processing is not finished
* the lock on the key A can't be acquired because it should be released by the
listener of PRIMARY_REPLICA_EXPIRED due to the replica expiration.
Probably the event of replica expiration should invalidate the ongoing
transactional requests and complete them.
was:
h3. Motivation
In the replica listener, we have unconsidered mechanisms between each other to
determine primary rteplica. The first one is based on the placement driver API
(it is used in _PartitionReplicaListener#ensureReplicaIsPrimary_) and the other
one is based on the placement driver events (the events are hadeled by two
methods: _ReplicaManager#onPrimaryReplicaElected_,
_ReplicaManager#onPrimaryReplicaExpired_).
Because the replica messages and events are handled in different threads, any
variety of processing is possible. For example, the replica can release all
transaction locks (by
PRIMARY_REPLICA_EXPIRED event) and then handle a message for this transaction
(because ensureReplicaIsPrimary was done before), assuming that all the locks
are holding.
h3. Definition of done
The two mechanisms work in coordination.
> Coordination of mechanisms of determination for primary on replicaside
> --
>
> Key: IGNITE-21213
> URL: https://issues.apache.org/jira/browse/IGNITE-21213
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In the replica listener, we have unconsidered mechanisms between each other
> to determine primary rteplica. The first one is based on the placement driver
> API (it is used in {_}PartitionReplicaListener#ensureReplicaIsPrimary{_}) and
> the other one is based on the placement driver events (the events are hadeled
> by two methods: {_}ReplicaManager#onPrimaryReplicaElected{_},
> {_}ReplicaManager#onPrimaryReplicaExpired{_}).
> Because the replica messages and events are handled in different threads, any
> variety of processing is possible. For example, the replica can release all
> transaction locks (by PRIMARY_REPLICA_EXPIRED event) and then handle a
> message for this transaction (because ensureReplicaIsPrimary was done
> before), assuming that all the locks are holding.
> h3. Definition of done
> The simultaneous processing of transactional requests and
> PRIMARY_REPLICA_EXPIRED is impossible.
>
> *Implementation notes*
> We must take into account and prevent the possible deadlocks, such as:
> * the transactional request is trying to acquire the lock on the key A
> * the processing of the PRIMARY_REPLICA_EXPIRED cannot start because the
> aforementioned request processing is not finished
> * the lock on the key A can't be acquired because it should be released by
> the listener of PRIMARY_REPLICA_EXPIRED due to the replica expiration.
> Probably the event of replica expiration should invalidate the ongoing
> transactional requests and complete them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21283) Improve client data streamer performance
[ https://issues.apache.org/jira/browse/IGNITE-21283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-21283: - Epic Link: IGNITE-19479 > Improve client data streamer performance > > > Key: IGNITE-21283 > URL: https://issues.apache.org/jira/browse/IGNITE-21283 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * Embedded data streamer uses partition-based > *org.apache.ignite.internal.table.InternalTable#upsertAll(java.util.Collection, > int)* method to upsert data, but client streamer uses *upsertAll* through > public API > * Embedded streamer performs batching per partition, client streamer batches > per node (connection) > Compare embedded and client streamer performance in different cases: > * 1 node, 4 nodes > * client connects to single node, client connects to all nodes > Check if using per-partition approach with internal upsertAll API improves > client streamer performance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
[
https://issues.apache.org/jira/browse/IGNITE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21325:
--
Description:
Motivation
No processing of any transactional request should be started when the event
processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is that
such requests may try to acquire transactional locks on the current primary
replica, and the locks acquired during the previous lease are released by the
listener of PRIMARY_REPLICA_EXPIRED event. The validity of the current primary
is checked in PartitionReplicaListener#ensureReplicaIsPrimary.
We must ensure that this method is called after the processing of
PRIMARY_REPLICA_EXPIRED event. The future returned by
PlacementDriver#previousPrimaryExpired can be used for this.
Definition of done
The processing of transactional requests for the current primary replica can't
be started before the processing of PRIMARY_REPLICA_EXPIRED event finishes.
was:
*Motivation*
No processing of any transactional request should be started when the event
processing of {{{}PRIMARY_REPLICA_EXPIRED event {{is in progress. The reason is
that such requests may try to acquire transactional locks on the current
primary replica, and the locks acquired during the previous lease are released
by the listener of}} PRIMARY_REPLICA_EXPIRED event. The validity of the current
primary is checked in PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
We must ensure that this method is called after the processing of
{{PRIMARY_REPLICA_EXPIRED event. The future returned by
PlacementDriver#previousPrimaryExpired}} can be used for this.
*Definition of done*
The processing of transactional requests for the current primary replica can't
be started before the processing of \{{PRIMARY_REPLICA_EXPIRED }}event finishes.
> Hold the transactional requests processing while the primary expired event
> processing is in progress
>
>
> Key: IGNITE-21325
> URL: https://issues.apache.org/jira/browse/IGNITE-21325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> No processing of any transactional request should be started when the event
> processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is
> that such requests may try to acquire transactional locks on the current
> primary replica, and the locks acquired during the previous lease are
> released by the listener of PRIMARY_REPLICA_EXPIRED event. The validity of
> the current primary is checked in
> PartitionReplicaListener#ensureReplicaIsPrimary.
> We must ensure that this method is called after the processing of
> PRIMARY_REPLICA_EXPIRED event. The future returned by
> PlacementDriver#previousPrimaryExpired can be used for this.
> Definition of done
> The processing of transactional requests for the current primary replica
> can't be started before the processing of PRIMARY_REPLICA_EXPIRED event
> finishes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
[
https://issues.apache.org/jira/browse/IGNITE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21325:
--
Description:
Motivation
No processing of any transactional request should be started when the event
processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is that
such requests may try to acquire transactional locks on the current primary
replica, and the locks acquired during the previous lease are released by the
listener of PRIMARY_REPLICA_EXPIRED event. The validity of the current primary
is checked in {{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
We must ensure that this method is called after the processing of
PRIMARY_REPLICA_EXPIRED event. The future returned by
{{PlacementDriver#previousPrimaryExpired}} can be used for this.
Definition of done
The processing of transactional requests for the current primary replica can't
be started before the processing of PRIMARY_REPLICA_EXPIRED event finishes.
was:
Motivation
No processing of any transactional request should be started when the event
processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is that
such requests may try to acquire transactional locks on the current primary
replica, and the locks acquired during the previous lease are released by the
listener of PRIMARY_REPLICA_EXPIRED event. The validity of the current primary
is checked in PartitionReplicaListener#ensureReplicaIsPrimary.
We must ensure that this method is called after the processing of
PRIMARY_REPLICA_EXPIRED event. The future returned by
PlacementDriver#previousPrimaryExpired can be used for this.
Definition of done
The processing of transactional requests for the current primary replica can't
be started before the processing of PRIMARY_REPLICA_EXPIRED event finishes.
> Hold the transactional requests processing while the primary expired event
> processing is in progress
>
>
> Key: IGNITE-21325
> URL: https://issues.apache.org/jira/browse/IGNITE-21325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Motivation
> No processing of any transactional request should be started when the event
> processing of PRIMARY_REPLICA_EXPIRED event is in progress. The reason is
> that such requests may try to acquire transactional locks on the current
> primary replica, and the locks acquired during the previous lease are
> released by the listener of PRIMARY_REPLICA_EXPIRED event. The validity of
> the current primary is checked in
> {{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
> We must ensure that this method is called after the processing of
> PRIMARY_REPLICA_EXPIRED event. The future returned by
> {{PlacementDriver#previousPrimaryExpired}} can be used for this.
> Definition of done
> The processing of transactional requests for the current primary replica
> can't be started before the processing of PRIMARY_REPLICA_EXPIRED event
> finishes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
[
https://issues.apache.org/jira/browse/IGNITE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21325:
--
Description:
*Motivation*
No processing of any transactional request should be started when the event
processing of {{{}PRIMARY_REPLICA_EXPIRED event {{is in progress. The reason is
that such requests may try to acquire transactional locks on the current
primary replica, and the locks acquired during the previous lease are released
by the listener of}} PRIMARY_REPLICA_EXPIRED event. The validity of the current
primary is checked in PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
We must ensure that this method is called after the processing of
{{PRIMARY_REPLICA_EXPIRED event. The future returned by
PlacementDriver#previousPrimaryExpired}} can be used for this.
*Definition of done*
The processing of transactional requests for the current primary replica can't
be started before the processing of \{{PRIMARY_REPLICA_EXPIRED }}event finishes.
was:
*Motivation*
No processing of any transactional request should be started when the event
processing of {{PRIMARY_REPLICA_EXPIRED }}event is in progress. The reason is
that such requests may try to acquire transactional locks on the current
primary replica, and the locks acquired during the previous lease are released
by the listener of {{PRIMARY_REPLICA_EXPIRED }}event. The validity of the
current primary is checked in
{{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
We must ensure that this method is called after the processing of
{{PRIMARY_REPLICA_EXPIRED }}event. The future returned by
{{PlacementDriver#previousPrimaryExpired}} can be used for this.
*Definition of done*
The processing of transactional requests for the current primary replica can't
be started before the processing of {{PRIMARY_REPLICA_EXPIRED }}event finishes.
> Hold the transactional requests processing while the primary expired event
> processing is in progress
>
>
> Key: IGNITE-21325
> URL: https://issues.apache.org/jira/browse/IGNITE-21325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> No processing of any transactional request should be started when the event
> processing of {{{}PRIMARY_REPLICA_EXPIRED event {{is in progress. The reason
> is that such requests may try to acquire transactional locks on the current
> primary replica, and the locks acquired during the previous lease are
> released by the listener of}} PRIMARY_REPLICA_EXPIRED event. The validity of
> the current primary is checked in
> PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
> We must ensure that this method is called after the processing of
> {{PRIMARY_REPLICA_EXPIRED event. The future returned by
> PlacementDriver#previousPrimaryExpired}} can be used for this.
> *Definition of done*
> The processing of transactional requests for the current primary replica
> can't be started before the processing of \{{PRIMARY_REPLICA_EXPIRED }}event
> finishes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
[
https://issues.apache.org/jira/browse/IGNITE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-21325:
--
Description:
*Motivation*
No processing of any transactional request should be started when the event
processing of {{PRIMARY_REPLICA_EXPIRED }}event is in progress. The reason is
that such requests may try to acquire transactional locks on the current
primary replica, and the locks acquired during the previous lease are released
by the listener of {{PRIMARY_REPLICA_EXPIRED }}event. The validity of the
current primary is checked in
{{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
We must ensure that this method is called after the processing of
{{PRIMARY_REPLICA_EXPIRED }}event. The future returned by
{{PlacementDriver#previousPrimaryExpired}} can be used for this.
*Definition of done*
The processing of transactional requests for the current primary replica can't
be started before the processing of {{PRIMARY_REPLICA_EXPIRED }}event finishes.
> Hold the transactional requests processing while the primary expired event
> processing is in progress
>
>
> Key: IGNITE-21325
> URL: https://issues.apache.org/jira/browse/IGNITE-21325
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> No processing of any transactional request should be started when the event
> processing of {{PRIMARY_REPLICA_EXPIRED }}event is in progress. The reason is
> that such requests may try to acquire transactional locks on the current
> primary replica, and the locks acquired during the previous lease are
> released by the listener of {{PRIMARY_REPLICA_EXPIRED }}event. The validity
> of the current primary is checked in
> {{{}PartitionReplicaListener#ensureReplicaIsPrimary{}}}.
> We must ensure that this method is called after the processing of
> {{PRIMARY_REPLICA_EXPIRED }}event. The future returned by
> {{PlacementDriver#previousPrimaryExpired}} can be used for this.
> *Definition of done*
> The processing of transactional requests for the current primary replica
> can't be started before the processing of {{PRIMARY_REPLICA_EXPIRED }}event
> finishes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21328) Fix logging in LowWatermark#start when there is no low watermark in vault
[ https://issues.apache.org/jira/browse/IGNITE-21328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis reassigned IGNITE-21328: -- Assignee: Philipp Shergalis > Fix logging in LowWatermark#start when there is no low watermark in vault > - > > Key: IGNITE-21328 > URL: https://issues.apache.org/jira/browse/IGNITE-21328 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When starting a node, there is confusing logging at > *org.apache.ignite.internal.table.distributed.LowWatermark#start* in the > absence of a low watermark in the vault. > Example message *Low watermark has been successfully got from the vault and > is scheduled to be updated: null* it needs to be changed to something like > "Previous value of the low watermark was not found, will schedule to update > it". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20361) Implement the table storage description
[ https://issues.apache.org/jira/browse/IGNITE-20361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809411#comment-17809411 ] Kirill Gusakov commented on IGNITE-20361: - LGTM > Implement the table storage description > --- > > Key: IGNITE-20361 > URL: https://issues.apache.org/jira/browse/IGNITE-20361 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > *Motivation* > According to IGNITE-20357 we need to have an appropriate table storage > configuration, which can be used on the table create/alter to check if the > chosen zone has appropriate storage requirements. > *Definition of done* > - Table has the storage configuration, which can be used for early validation > if table can be "deployed" in its zone correctly. > - Data storage configuration removed from zone configuration > *Notes* > - Avoid altering of this field for now with appropriate exception -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path||Type|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| > | | | | > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21329) [Extensions] Release ignite-ml extension
[ https://issues.apache.org/jira/browse/IGNITE-21329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-21329: - Description: Need to release ignite-ml extension (version 1.0.0) > [Extensions] Release ignite-ml extension > > > Key: IGNITE-21329 > URL: https://issues.apache.org/jira/browse/IGNITE-21329 > Project: Ignite > Issue Type: Task >Reporter: Ivan Daschinsky >Priority: Major > > Need to release ignite-ml extension (version 1.0.0) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21329) [Extensions] Release ignite-ml extension
[ https://issues.apache.org/jira/browse/IGNITE-21329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-21329: Assignee: Ivan Daschinsky > [Extensions] Release ignite-ml extension > > > Key: IGNITE-21329 > URL: https://issues.apache.org/jira/browse/IGNITE-21329 > Project: Ignite > Issue Type: Task >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > > Need to release ignite-ml extension (version 1.0.0) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21329) [Extensions] Release ignite-ml extension
Ivan Daschinsky created IGNITE-21329: Summary: [Extensions] Release ignite-ml extension Key: IGNITE-21329 URL: https://issues.apache.org/jira/browse/IGNITE-21329 Project: Ignite Issue Type: Task Reporter: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21328) Fix logging in LowWatermark#start when there is no low watermark in vault
[ https://issues.apache.org/jira/browse/IGNITE-21328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21328: Assignee: (was: Kirill Tkalenko) > Fix logging in LowWatermark#start when there is no low watermark in vault > - > > Key: IGNITE-21328 > URL: https://issues.apache.org/jira/browse/IGNITE-21328 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When starting a node, there is confusing logging at > *org.apache.ignite.internal.table.distributed.LowWatermark#start* in the > absence of a low watermark in the vault. > Example message *Low watermark has been successfully got from the vault and > is scheduled to be updated: null* it needs to be changed to something like > "Previous value of the low watermark was not found, will schedule to update > it". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21328) Fix logging in LowWatermark#start when there is no low watermark in vault
Kirill Tkalenko created IGNITE-21328: Summary: Fix logging in LowWatermark#start when there is no low watermark in vault Key: IGNITE-21328 URL: https://issues.apache.org/jira/browse/IGNITE-21328 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 When starting a node, there is confusing logging at *org.apache.ignite.internal.table.distributed.LowWatermark#start* in the absence of a low watermark in the vault. Example message *Low watermark has been successfully got from the vault and is scheduled to be updated: null* it needs to be changed to something like "Previous value of the low watermark was not found, will schedule to update it". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21287) Sql. LogicalOrToUnionRule may hang
[ https://issues.apache.org/jira/browse/IGNITE-21287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21287: --- Summary: Sql. LogicalOrToUnionRule may hang (was: Sql. LogicalOrToUnionRule may hand) > Sql. LogicalOrToUnionRule may hang > -- > > Key: IGNITE-21287 > URL: https://issues.apache.org/jira/browse/IGNITE-21287 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > LogicalOrToUnionRule may hand in case of huge conditions. Let's investigate > possible solutions under this ticket and uncomment the rule. > To reproduce the issue, try to uncomment the rule and run q19 from TPC-H > suite after IGNITE-20880. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21284) Internal API for manual raft group configuration update
[ https://issues.apache.org/jira/browse/IGNITE-21284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-21284: -- Assignee: Ivan Bessonov > Internal API for manual raft group configuration update > --- > > Key: IGNITE-21284 > URL: https://issues.apache.org/jira/browse/IGNITE-21284 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > We need an API (with implementation) that's analogous to > "reset-lost-partitions", but with the ability to reuse living minority of > nodes. > This API should gather the states of partitions, identify healthy peers, and > use them as a new raft group configuration (through the update of > assignments). > We have to make sure that node with latest log index will become a leader, so > we will have to propagate desired minimum for log index in assignments and > use it during the voting. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21327) Create Windows batch file to run ignite
Vadim Pakhnushev created IGNITE-21327: - Summary: Create Windows batch file to run ignite Key: IGNITE-21327 URL: https://issues.apache.org/jira/browse/IGNITE-21327 Project: Ignite Issue Type: Improvement Components: binary, cli Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev In the IGNITE-21200 it was noted that there's no way to easily run Ignite on Windows from the zip distribution. Since there's no direct way to get the PID of the last executed command and create a start/stop commands, it's probably enough to enable just running the Ignite in place. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21200) IgniteRunner start fails in Windows via git-bash
[
https://issues.apache.org/jira/browse/IGNITE-21200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev reassigned IGNITE-21200:
-
Assignee: Vadim Pakhnushev
> IgniteRunner start fails in Windows via git-bash
>
>
> Key: IGNITE-21200
> URL: https://issues.apache.org/jira/browse/IGNITE-21200
> Project: Ignite
> Issue Type: Bug
> Components: binary, cli
>Affects Versions: 3.0.0-beta2
>Reporter: Igor
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3, windows
> Fix For: 3.0.0-beta2
>
>
> h3. Steps to reproduce:
> # Build ignite3-db-3.0.0-SNAPSHOT.zip distribution from sources.
> # Use git-bash to run `./ignite3db start` in Windows.
> h3. Expected:
> IgniteRunner started.
> h3. Actual:
> Error:
> {code:java}
> ./ignite3db: line 38: C:\Program: No such file or directory{code}
> h3. Details:
> The space in path to java (C:\Program Files) is considered as separation
> between command and arguments. To avoid it, usage of all variables have to
> replaced to arrays. For example `${JAVA_CMD_WITH_ARGS}` have to be replaced
> to `${JAVA_CMD_WITH_ARGS[@]}` and so on.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[ https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21326: Description: Happens more and more often lately: https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true Investigate heap dumps from TC. > .NET: Thin 3.0: Out of memory: Java heap space in tests > --- > > Key: IGNITE-21326 > URL: https://issues.apache.org/jira/browse/IGNITE-21326 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Happens more and more often lately: > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true > Investigate heap dumps from TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
[
https://issues.apache.org/jira/browse/IGNITE-21326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21326:
Description:
Happens more and more often lately:
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
{code:java}
Out of memory: Java heap space (This problem is reported because
OutOfMemoryError has been found in the build log text)
{code}
Investigate heap dumps from TC.
was:
Happens more and more often lately:
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
Investigate heap dumps from TC.
> .NET: Thin 3.0: Out of memory: Java heap space in tests
> ---
>
> Key: IGNITE-21326
> URL: https://issues.apache.org/jira/browse/IGNITE-21326
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Happens more and more often lately:
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/7787817?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&expandBuildTestsSection=true
> {code:java}
> Out of memory: Java heap space (This problem is reported because
> OutOfMemoryError has been found in the build log text)
> {code}
> Investigate heap dumps from TC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21326) .NET: Thin 3.0: Out of memory: Java heap space in tests
Pavel Tupitsyn created IGNITE-21326: --- Summary: .NET: Thin 3.0: Out of memory: Java heap space in tests Key: IGNITE-21326 URL: https://issues.apache.org/jira/browse/IGNITE-21326 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17703) Extaract hardcoded constants to configuration in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17703: --- Description: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path||Type|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| | | | | was: We have many hardcoded constants in sql-engine module. So it can't be configure by user. Let's move the following to configuration: ||Constant||Configuration path|| |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime| |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount| |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries| |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel| | | | > Extaract hardcoded constants to configuration in sql-engine module > -- > > Key: IGNITE-17703 > URL: https://issues.apache.org/jira/browse/IGNITE-17703 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > We have many hardcoded constants in sql-engine module. So it can't be > configure by user. > Let's move the following to configuration: > ||Constant||Configuration path||Type|| > |PrepareServiceImpl#DEFAULT_PLANNER_TIMEOUT|sql.planner.maxPlanningTime|Distributed| > |PrepareServiceImpl#THREAD_COUNT|sql.planner.threadCount|Local| > |SqlQueryProcessor#PLAN_CACHE_SIZE|sql.planner.estimatedNumberOfQueries|Distributed| > |QueryTaskExecutorImpl.stripedThreadPoolExecutor|sql.execution.concurrencyLevel|Local| > | | | | -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21270) Use consistentId instead of ClusterNode in Compute API
[ https://issues.apache.org/jira/browse/IGNITE-21270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809314#comment-17809314 ] Pavel Tupitsyn commented on IGNITE-21270: - I don't think that stringly-typed API is better. We should definitely keep *ClusterNode* in the public API, it can't be replaced with a string: * To access address and metadata * Future-proofing > Use consistentId instead of ClusterNode in Compute API > -- > > Key: IGNITE-21270 > URL: https://issues.apache.org/jira/browse/IGNITE-21270 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, methods of the Compute API accept ClusterNode type to identify > nodes on which a job is to be executed. This seems redundant as we only use > consistentId from those objects. > If we replace ClusterNode with String (representing consistentId), we will > not lose API capabilities (we'll just resolve the nodes internally in the > very beginning), but we'll be able to move ClusterNode and TopologyService > from our public API, and having less public API seems to be a good thing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21103) Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21103: Ignite Flags: (was: Docs Required,Release Notes Required) > Thin 3.0: Rename DataStreamerOptions.batchSize to pageSize > -- > > Key: IGNITE-21103 > URL: https://issues.apache.org/jira/browse/IGNITE-21103 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Rename *DataStreamerOptions.batchSize* to *pageSize* to be consistent with > cursors and other APIs. > Update Java and .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21213) Coordination of mechanisms of determination for primary on replicaside
[ https://issues.apache.org/jira/browse/IGNITE-21213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809297#comment-17809297 ] Denis Chudov edited comment on IGNITE-21213 at 1/22/24 8:32 AM: There are 3 aspects of this problem: # Handling the events processing should be done within the replica stripe, will be covered in IGNITE-21258 # We shouldn't allow to process transactional requests and events handling simultaneously wrt async calls, so we should make something like read-write lock (but not literally, because simple read-write lock will lead to deadlocks). Can be done in this ticket. # We shouldn't allow to process new transactional requests until the event handling is done, PlacementDriver#previousPrimaryExpired future can be used for this: IGNITE-21325 was (Author: denis chudov): There are 3 aspects of this problem: # Handling the events processing should be done within the replica stripe, will be covered in IGNITE-21258 # We shouldn't allow to process transactional requests and events handling simultaneously wrt async calls, so we should make something like read-write lock (but not literally, because simple read-write lock will lead to deadlocks). Can be done in this ticket. # We shouldn't allow to process new transactional requests until the event handling is done, PlacementDriver#previousPrimaryExpired future can be used for this. > Coordination of mechanisms of determination for primary on replicaside > -- > > Key: IGNITE-21213 > URL: https://issues.apache.org/jira/browse/IGNITE-21213 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > In the replica listener, we have unconsidered mechanisms between each other > to determine primary rteplica. The first one is based on the placement driver > API (it is used in _PartitionReplicaListener#ensureReplicaIsPrimary_) and the > other one is based on the placement driver events (the events are hadeled by > two methods: _ReplicaManager#onPrimaryReplicaElected_, > _ReplicaManager#onPrimaryReplicaExpired_). > Because the replica messages and events are handled in different threads, any > variety of processing is possible. For example, the replica can release all > transaction locks (by > PRIMARY_REPLICA_EXPIRED event) and then handle a message for this transaction > (because ensureReplicaIsPrimary was done before), assuming that all the locks > are holding. > h3. Definition of done > The two mechanisms work in coordination. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21325) Hold the transactional requests processing while the primary expired event processing is in progress
Denis Chudov created IGNITE-21325: - Summary: Hold the transactional requests processing while the primary expired event processing is in progress Key: IGNITE-21325 URL: https://issues.apache.org/jira/browse/IGNITE-21325 Project: Ignite Issue Type: Improvement Reporter: Denis Chudov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21213) Coordination of mechanisms of determination for primary on replicaside
[ https://issues.apache.org/jira/browse/IGNITE-21213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809297#comment-17809297 ] Denis Chudov commented on IGNITE-21213: --- There are 3 aspects of this problem: # Handling the events processing should be done within the replica stripe, will be covered in IGNITE-21258 # We shouldn't allow to process transactional requests and events handling simultaneously wrt async calls, so we should make something like read-write lock (but not literally, because simple read-write lock will lead to deadlocks). Can be done in this ticket. # We shouldn't allow to process new transactional requests until the event handling is done, PlacementDriver#previousPrimaryExpired future can be used for this. > Coordination of mechanisms of determination for primary on replicaside > -- > > Key: IGNITE-21213 > URL: https://issues.apache.org/jira/browse/IGNITE-21213 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > In the replica listener, we have unconsidered mechanisms between each other > to determine primary rteplica. The first one is based on the placement driver > API (it is used in _PartitionReplicaListener#ensureReplicaIsPrimary_) and the > other one is based on the placement driver events (the events are hadeled by > two methods: _ReplicaManager#onPrimaryReplicaElected_, > _ReplicaManager#onPrimaryReplicaExpired_). > Because the replica messages and events are handled in different threads, any > variety of processing is possible. For example, the replica can release all > transaction locks (by > PRIMARY_REPLICA_EXPIRED event) and then handle a message for this transaction > (because ensureReplicaIsPrimary was done before), assuming that all the locks > are holding. > h3. Definition of done > The two mechanisms work in coordination. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21276) Check nodeId within ensureReplicaIsPrimary
[ https://issues.apache.org/jira/browse/IGNITE-21276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809289#comment-17809289 ] Vladislav Pyatkov commented on IGNITE-21276: LGTM > Check nodeId within ensureReplicaIsPrimary > -- > > Key: IGNITE-21276 > URL: https://issues.apache.org/jira/browse/IGNITE-21276 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > ensureReplicaIsPrimary should check whether primaryReplica.lease.id is the > same as localNode.id. That's it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
