[jira] [Commented] (IGNITE-17713) .NET: Thin 3.0: build fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-17713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607517#comment-17607517
]
Pavel Tupitsyn commented on IGNITE-17713:
-
Seems related https://github.com/dotnet/sdk/issues/2902
> .NET: Thin 3.0: build fails sporadically
>
>
> Key: IGNITE-17713
> URL: https://issues.apache.org/jira/browse/IGNITE-17713
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> {code}
> Determining projects to restore...
> 06:48:18 Restored
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Apache.Ignite.csproj
> (in 282 ms).
> 06:48:18 Restored
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj
> (in 288 ms).
> 06:48:18 Restored
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Apache.Ignite.Tests.csproj
> (in 501 ms).
> 06:48:18 Restored
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Benchmarks/Apache.Ignite.Benchmarks.csproj
> (in 528 ms).
> 06:48:21 Apache.Ignite.Internal.Generators ->
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/bin/Debug/netstandard2.0/Apache.Ignite.Internal.Generators.dll
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018: System.IO.IOException: The process cannot access the file
> '/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/bin/Debug/netstandard2.0/Apache.Ignite.Internal.Generators.deps.json'
> because it is being used by another process.
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at Microsoft.Win32.SafeHandles.SafeFileHandle.Init(String
> path, FileMode mode, FileAccess access, FileShare share, FileOptions options,
> Int64 preallocationSize)
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String
> fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions
> options, Int64 preallocationSize)
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at System.IO.Strategies.OSFileStreamStrategy..ctor(String
> path, FileMode mode, FileAccess access, FileShare share, FileOptions options,
> Int64 preallocationSize)
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at
> System.IO.Strategies.FileStreamHelpers.ChooseStrategy(FileStream fileStream,
> String path, FileMode mode, FileAccess access, FileShare share, Int32
> bufferSize, FileOptions options, Int64 preallocationSize)
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at System.IO.File.Create(String path)
> [/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Internal.Generators/Apache.Ignite.Internal.Generators.csproj]
> 06:48:21
> /usr/share/dotnet/sdk/6.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(172,5):
> error MSB4018:at
> Microsoft.NET.Build.Tasks.GenerateDepsFile.WriteDepsFile(String depsFilePath)
>
[jira] [Updated] (IGNITE-17733) Resume honest index lock
[
https://issues.apache.org/jira/browse/IGNITE-17733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17733:
---
Labels: ignite-3 (was: )
> Resume honest index lock
>
>
> Key: IGNITE-17733
> URL: https://issues.apache.org/jira/browse/IGNITE-17733
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Due to an issue in protocol of lock manager, locks on indexes are avoided.
> Need to find a way where we can use honest lock modes on indexes, but not
> convert the type to {_}NAL{_}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17733) Resume honest index lock
Vladislav Pyatkov created IGNITE-17733:
--
Summary: Resume honest index lock
Key: IGNITE-17733
URL: https://issues.apache.org/jira/browse/IGNITE-17733
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
Due to an issue in protocol of lock manager, locks on indexes are avoided. Need
to find a way where we can use honest lock modes on indexes, but not convert
the type to {_}NAL{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17732) Avoid locking indexes in transaction
[
https://issues.apache.org/jira/browse/IGNITE-17732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17732:
---
Labels: ignite-3 (was: )
> Avoid locking indexes in transaction
>
>
> Key: IGNITE-17732
> URL: https://issues.apache.org/jira/browse/IGNITE-17732
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> The transaction protocol requires lock all indexes (now it is a pk) in the
> same manner as it happens for data (locks on {_}RowIds{_}). But lock manager
> cannot resolve all problems in his case (in particular, waiter for _RowId_
> does not create when the lock on index have not got).
> As a temporary workaround for this disadvantage, supposed:
> # Create a NAL (Not a lock) lock mode, which is compatible for all another
> mode
> # All lock modes on PK should convert to NAL
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17732) Avoid locking indexes in transaction
[
https://issues.apache.org/jira/browse/IGNITE-17732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-17732:
--
Assignee: Vladislav Pyatkov
> Avoid locking indexes in transaction
>
>
> Key: IGNITE-17732
> URL: https://issues.apache.org/jira/browse/IGNITE-17732
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> The transaction protocol requires lock all indexes (now it is a pk) in the
> same manner as it happens for data (locks on {_}RowIds{_}). But lock manager
> cannot resolve all problems in his case (in particular, waiter for _RowId_
> does not create when the lock on index have not got).
> As a temporary workaround for this disadvantage, supposed:
> # Create a NAL (Not a lock) lock mode, which is compatible for all another
> mode
> # All lock modes on PK should convert to NAL
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17732) Avoid locking indexes in transaction
Vladislav Pyatkov created IGNITE-17732:
--
Summary: Avoid locking indexes in transaction
Key: IGNITE-17732
URL: https://issues.apache.org/jira/browse/IGNITE-17732
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
The transaction protocol requires lock all indexes (now it is a pk) in the same
manner as it happens for data (locks on {_}RowIds{_}). But lock manager cannot
resolve all problems in his case (in particular, waiter for _RowId_ does not
create when the lock on index have not got).
As a temporary workaround for this disadvantage, supposed:
# Create a NAL (Not a lock) lock mode, which is compatible for all another mode
# All lock modes on PK should convert to NAL
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17721) Make AbstractConfiguration a legal inside NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-17721:
Description:
For dynamic configuration of metrics exporters here
https://issues.apache.org/jira/browse/IGNITE-17358 we need to have the config
like:
{code:java}
metrics.exporters
http:
port: 19191
opentelementry:
agent_port: 18{code}
So:
* every exporter have it's config with unique config schema
* this configs placed in named list with appropriate name
But there are no ways to do it at the moment:
* if we use AbstractConfiguration we can't place it inside the NamedConfigValue
* if we use PolymorphicConfigwe need to manually set the name of exporter
twice, like:
{code:java}
metrics.exporters
http:
type: http
port: 19191
opentelementry:
type: opentelemetry
agent_port: 18{code}
Code example:
{code:java}
@ConfigurationRoot(rootName = "metrics", type = ConfigurationType.DISTRIBUTED)
public class MetricConfigurationSchema {
@NamedConfigValue
public ExporterConfigurationSchema exporters;
}
@PolymorphicConfig
public class ExporterConfigurationSchema {
@PolymorphicId
public String exporterName;
}
@PolymorphicConfigInstance("jmx")
public class JmxExporterConfigurationSchema extends ExporterConfigurationSchema
{} {code}
> Make AbstractConfiguration a legal inside NamedConfigValue
> --
>
> Key: IGNITE-17721
> URL: https://issues.apache.org/jira/browse/IGNITE-17721
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> For dynamic configuration of metrics exporters here
> https://issues.apache.org/jira/browse/IGNITE-17358 we need to have the config
> like:
> {code:java}
> metrics.exporters
> http:
> port: 19191
> opentelementry:
> agent_port: 18{code}
> So:
> * every exporter have it's config with unique config schema
> * this configs placed in named list with appropriate name
> But there are no ways to do it at the moment:
> * if we use AbstractConfiguration we can't place it inside the
> NamedConfigValue
> * if we use PolymorphicConfigwe need to manually set the name of exporter
> twice, like:
> {code:java}
> metrics.exporters
> http:
> type: http
> port: 19191
> opentelementry:
> type: opentelemetry
> agent_port: 18{code}
> Code example:
> {code:java}
> @ConfigurationRoot(rootName = "metrics", type = ConfigurationType.DISTRIBUTED)
> public class MetricConfigurationSchema {
> @NamedConfigValue
> public ExporterConfigurationSchema exporters;
> }
> @PolymorphicConfig
> public class ExporterConfigurationSchema {
> @PolymorphicId
> public String exporterName;
> }
> @PolymorphicConfigInstance("jmx")
> public class JmxExporterConfigurationSchema extends
> ExporterConfigurationSchema {} {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17721) Make AbstractConfiguration a legal inside NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-17721: Ignite Flags: (was: Docs Required,Release Notes Required) > Make AbstractConfiguration a legal inside NamedConfigValue > -- > > Key: IGNITE-17721 > URL: https://issues.apache.org/jira/browse/IGNITE-17721 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17687) Get rid of using deprecated IgniteException constructors in sql-engine module
[ https://issues.apache.org/jira/browse/IGNITE-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-17687: - Assignee: Pavel Pereslegin > Get rid of using deprecated IgniteException constructors in sql-engine module > - > > Key: IGNITE-17687 > URL: https://issues.apache.org/jira/browse/IGNITE-17687 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3, tech-debt > > As of now deprecated constructors of IgniteException widely used. Let's > replace all such places in sq-engine module to use non deprecated > constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17718) Implement the way to configure metric sources
[ https://issues.apache.org/jira/browse/IGNITE-17718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-17718: Ignite Flags: (was: Docs Required,Release Notes Required) > Implement the way to configure metric sources > -- > > Key: IGNITE-17718 > URL: https://issues.apache.org/jira/browse/IGNITE-17718 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15957) Packaging: DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-15957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-15957: -- Assignee: Mikhail Pochatkin > Packaging: DEB packages > --- > > Key: IGNITE-15957 > URL: https://issues.apache.org/jira/browse/IGNITE-15957 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 3.0.0-alpha3 >Reporter: Valentin Kulichenko >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Need to create DEB packages based on ZIP packages describe in IGNITE-15955. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-15956: -- Assignee: Mikhail Pochatkin > Packaging: RPM packages > --- > > Key: IGNITE-15956 > URL: https://issues.apache.org/jira/browse/IGNITE-15956 > Project: Ignite > Issue Type: Improvement > Components: build >Affects Versions: 3.0.0-alpha3 >Reporter: Valentin Kulichenko >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Need to create RPM packages based on ZIP packages described in IGNITE-15955. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17318) Implement RocksDB based sorted index storage
[ https://issues.apache.org/jira/browse/IGNITE-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607249#comment-17607249 ] Semyon Danilov commented on IGNITE-17318: - Looks good to me! > Implement RocksDB based sorted index storage > > > Key: IGNITE-17318 > URL: https://issues.apache.org/jira/browse/IGNITE-17318 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Pretty straightforward. Complicated places are: > * Binary tuples comparator: should be as fast as possible. Some > optimizations might be moved to other issues. > * Thorough testing is required. We have both Java and native comparators > planned. They should behave identically. This means a specific way of writing > tests, to account for this in advance. > * Bounds checking on range scan: > by default, comparator should include the lower bound and exclude the upper > bound. This is how prefix search works. This means that exclusion of the > lower bound (if needed) and inclusion of the upper bound (if needed) +must be > performed manually+ inside of the scan method. > The question is, do we use separate column families for indexes? At one hand, > this increases the number of files and potentially even increases time of the > flush, but on the other, it looks easy (or is it). > Currently, every index has only a UUID id. Just like for tables, we could > create an integer identifier, because why not. This way we could store all > indexes in a single column family without too much overhead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17318) Implement RocksDB based sorted index storage
[ https://issues.apache.org/jira/browse/IGNITE-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-17318: Reviewer: Semyon Danilov > Implement RocksDB based sorted index storage > > > Key: IGNITE-17318 > URL: https://issues.apache.org/jira/browse/IGNITE-17318 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Pretty straightforward. Complicated places are: > * Binary tuples comparator: should be as fast as possible. Some > optimizations might be moved to other issues. > * Thorough testing is required. We have both Java and native comparators > planned. They should behave identically. This means a specific way of writing > tests, to account for this in advance. > * Bounds checking on range scan: > by default, comparator should include the lower bound and exclude the upper > bound. This is how prefix search works. This means that exclusion of the > lower bound (if needed) and inclusion of the upper bound (if needed) +must be > performed manually+ inside of the scan method. > The question is, do we use separate column families for indexes? At one hand, > this increases the number of files and potentially even increases time of the > flush, but on the other, it looks easy (or is it). > Currently, every index has only a UUID id. Just like for tables, we could > create an integer identifier, because why not. This way we could store all > indexes in a single column family without too much overhead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17448) Implementation of metric source for cluster state
[ https://issues.apache.org/jira/browse/IGNITE-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-17448: -- Description: At least, could be implemented metric showing *topology version*. What is needed to achieve this: Define metrics source class and metrics holder class for cluster state. Define all metric variables in the holder class, if needed. Implement initialization logic which is responsible for creation of actual instances of metrics and building an immutable instance of metrics set (will be executed on metrics enabling). Implement additional clean up logic if needed (will be executed on metrics disabled). Define methods that implement desirable manipulations with metrics. Every such method must check the state of the metrics source (enabled\disabled) by testing the holder reference to null (some kind of guard) before modifying a metric value. Read holder reference only once and use it in scope of the method in order to avoid data races. Metrics source should be registered in metrics registry on component start and should be unregistered on component stop. Initial metrics source state (enabled\disabled) should be set according to configuration for each particular component. Add logic related with metrics values modification (add invocations of metrics source methods). was: At least, could be implemented metric showing *topology version*. What is needed to achieve this: Define metrics source class and metrics holder class for ignite compute. Define all metric variables in the holder class, if needed. Implement initialization logic which is responsible for creation of actual instances of metrics and building an immutable instance of metrics set (will be executed on metrics enabling). Implement additional clean up logic if needed (will be executed on metrics disabled). Define methods that implement desirable manipulations with metrics. Every such method must check the state of the metrics source (enabled\disabled) by testing the holder reference to null (some kind of guard) before modifying a metric value. Read holder reference only once and use it in scope of the method in order to avoid data races. Metrics source should be registered in metrics registry on component start and should be unregistered on component stop. Initial metrics source state (enabled\disabled) should be set according to configuration for each particular component. Add logic related with metrics values modification (add invocations of metrics source methods). > Implementation of metric source for cluster state > - > > Key: IGNITE-17448 > URL: https://issues.apache.org/jira/browse/IGNITE-17448 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > At least, could be implemented metric showing *topology version*. > What is needed to achieve this: > Define metrics source class and metrics holder class for cluster state. > Define all metric variables in the holder class, if needed. > Implement initialization logic which is responsible for creation of actual > instances of metrics and building an immutable instance of metrics set (will > be executed on metrics enabling). Implement additional clean up logic if > needed (will be executed on metrics disabled). > Define methods that implement desirable manipulations with metrics. Every > such method must check the state of the metrics source (enabled\disabled) by > testing the holder reference to null (some kind of guard) before modifying a > metric value. Read holder reference only once and use it in scope of the > method in order to avoid data races. > Metrics source should be registered in metrics registry on component start > and should be unregistered on component stop. Initial metrics source state > (enabled\disabled) should be set according to configuration for each > particular component. > Add logic related with metrics values modification (add invocations of > metrics source methods). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17727) HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in constructor.
[ https://issues.apache.org/jira/browse/IGNITE-17727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-17727: Assignee: Aleksandr Polovtcev > HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in > constructor. > > > Key: IGNITE-17727 > URL: https://issues.apache.org/jira/browse/IGNITE-17727 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > After merger [1] constructors for HashIndexDescriptor and > SortedIndexDescriptor obtained one redundant field _tableConfig_ - for > simplifying huge existence tests only. We need remove this param and fix > appropriate tests. > [1] https://issues.apache.org/jira/browse/IGNITE-17474 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17731) Possible LRT in case of postponed GridDhtLockRequest
[ https://issues.apache.org/jira/browse/IGNITE-17731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17731: Labels: IEP-89 (was: ) > Possible LRT in case of postponed GridDhtLockRequest > > > Key: IGNITE-17731 > URL: https://issues.apache.org/jira/browse/IGNITE-17731 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Priority: Major > Labels: IEP-89 > > Let's assume the foowing scenario: > 1. TX coordinator starts transaction and sends GridDhtLockRequest to "near" > nodes. > 2. Some GridDhtLockRequest messages was delayed by the network. > 3. Not all "near" nodes receive GridDhtLockRequest and as result not all of > them respond to the TX coordinator. > 4. TX coordinator aborts TX by the timeout. > 5. Completed TX ID is stored in IgniteTxManager#completedVersHashMap. > 6. TX load continuous (assume puts in TX cache) and record about described > above completed TX is evicted from the map. > 7. GridDhtLockRequest from the clause 2 is finally recived by the "near" > nodes. They lock keys, start the local TX, and respond to the TX coordinator. > But currently TX coordinator ignores GridDhtLockResponce as info about > initial TX was evicted and does nothing. > As a result near nodes keep holding key locks and waiting for next steps of > TX protocol that will never happen as TX was already completed. > As a WA TX can be explicitly KILLED on the near node. > It is proposed to handle this situation and not aquire locks on the near node > if TX coordinator or other cluster nodes do not have notion about TX to which > current lock request belongs to. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17731) Possible LRT in case of postponed GridDhtLockRequest
Mikhail Petrov created IGNITE-17731: --- Summary: Possible LRT in case of postponed GridDhtLockRequest Key: IGNITE-17731 URL: https://issues.apache.org/jira/browse/IGNITE-17731 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Let's assume the foowing scenario: 1. TX coordinator starts transaction and sends GridDhtLockRequest to "near" nodes. 2. Some GridDhtLockRequest messages was delayed by the network. 3. Not all "near" nodes receive GridDhtLockRequest and as result not all of them respond to the TX coordinator. 4. TX coordinator aborts TX by the timeout. 5. Completed TX ID is stored in IgniteTxManager#completedVersHashMap. 6. TX load continuous (assume puts in TX cache) and record about described above completed TX is evicted from the map. 7. GridDhtLockRequest from the clause 2 is finally recived by the "near" nodes. They lock keys, start the local TX, and respond to the TX coordinator. But currently TX coordinator ignores GridDhtLockResponce as info about initial TX was evicted and does nothing. As a result near nodes keep holding key locks and waiting for next steps of TX protocol that will never happen as TX was already completed. As a WA TX can be explicitly KILLED on the near node. It is proposed to handle this situation and not aquire locks on the near node if TX coordinator or other cluster nodes do not have notion about TX to which current lock request belongs to. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17730) Correct inaccuracies in AI 3 SQL docs
Igor Gusev created IGNITE-17730: --- Summary: Correct inaccuracies in AI 3 SQL docs Key: IGNITE-17730 URL: https://issues.apache.org/jira/browse/IGNITE-17730 Project: Ignite Issue Type: Task Components: documentation Reporter: Igor Gusev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17443) Implement OpenTelemetry metric exporter
[ https://issues.apache.org/jira/browse/IGNITE-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17443: - Summary: Implement OpenTelemetry metric exporter (was: Implement OpenCensus metric exporter) > Implement OpenTelemetry metric exporter > --- > > Key: IGNITE-17443 > URL: https://issues.apache.org/jira/browse/IGNITE-17443 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Implement OpenCensus metric exporter, which should push metrics using > [OpenCensus |https://opencensus.io] API. > Metrics should be recorded via OpenCensus API once in some period of time. > The basic classes for creating metric exporters which are pushing metrics > periodically, should be added in IGNITE-17444. > For more information about OpenCensus API, see > https://opencensus.io/exporters/supported-exporters/java . > Basically, this exporter should work likewise the exporter in Apache Ignite > 2. See > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/metric/opencensus/OpenCensusMetricExporterSpi.html > . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17443) Implement OpenCensus metric exporter
[ https://issues.apache.org/jira/browse/IGNITE-17443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607185#comment-17607185 ] Vyacheslav Koptilin commented on IGNITE-17443: -- The OpenCensus and OpenTracing projects have merged into a new project; OpenTelemetry. The following statement appears on the OpenCensus project page: ??OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.?? https://opencensus.io/ It seems to me there is no reason to waste time to implement OpenCensus spec, we should proceed with the OpenTelemetry instead. > Implement OpenCensus metric exporter > > > Key: IGNITE-17443 > URL: https://issues.apache.org/jira/browse/IGNITE-17443 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Implement OpenCensus metric exporter, which should push metrics using > [OpenCensus |https://opencensus.io] API. > Metrics should be recorded via OpenCensus API once in some period of time. > The basic classes for creating metric exporters which are pushing metrics > periodically, should be added in IGNITE-17444. > For more information about OpenCensus API, see > https://opencensus.io/exporters/supported-exporters/java . > Basically, this exporter should work likewise the exporter in Apache Ignite > 2. See > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/metric/opencensus/OpenCensusMetricExporterSpi.html > . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17474) Rework configuration hierarchy
[ https://issues.apache.org/jira/browse/IGNITE-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-17474: Description: Currently indexes configuration is subtree of a table configuration. Such a hierarchy increases complexity of the objects validation. That could be improved by reworking the configuration in a way both indexes and tables belong to the same layer. This will give us tables' and indexes name uniqueness validation out of the box. was: Currently indices configuration is subtree of a table configuration. Such a hierarchy increases complexity of the objects validation. That could be improved by reworking the configuration in a way both indexes and tables belong to the same layer. This will give us tables' and indexes name uniqueness validation out of the box. > Rework configuration hierarchy > -- > > Key: IGNITE-17474 > URL: https://issues.apache.org/jira/browse/IGNITE-17474 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Currently indexes configuration is subtree of a table configuration. Such a > hierarchy increases complexity of the objects validation. > That could be improved by reworking the configuration in a way both indexes > and tables belong to the same layer. This will give us tables' and indexes > name uniqueness validation out of the box. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17663) Apache ignite is giving error when execute a sql query with Top keyword
[
https://issues.apache.org/jira/browse/IGNITE-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-17663.
Resolution: Cannot Reproduce
> Apache ignite is giving error when execute a sql query with Top keyword
> ---
>
> Key: IGNITE-17663
> URL: https://issues.apache.org/jira/browse/IGNITE-17663
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.7.6
> Environment: Windows 10 x64, Apache ignite .net,
>Reporter: Adnan
>Priority: Critical
>
> * When I execute a simple query on apache ignite it's work fine but when I
> execute with the "TOP" keyword it's give error. The query is "SELECT TOP(5)
> a.* FROM "Orders".ORDER a WHERE IsOptionTrade=FALSE AND (ACCOUNT IN ('10001',
> '10002', '10003'))".
> * The method is given below from where error occurs.
> *
> {{public IEnumerable QueryContinous(string initalquery, string
> predicateExpression, string queryKey, ref long seekinfo){if
> (string.IsNullOrEmpty(predicateExpression))
> predicateExpression = "1 == 1";if
> (ListenerLookup.ContainsKey(queryKey))
> {if (predicateExpression ==
> ListenerLookup[queryKey].PredicateExpr)return
> Query(initalquery, ref seekinfo);else{
> //Note:Same Client not using Different Versions of Client
> logger.Warn($"PredicateExpression:{predicateExpression} is Different from
> ListenerLookUp PredicateExpression:{ListenerLookup[queryKey].PredicateExpr}");
> Unsubscribe(queryKey);
> }
>
> }var listener = new Listener(queryKey);
> listener.OnUpdate += Listener_OnUpdate;var qry = new
> ContinuousQuery(listener)
> {
> Filter = new RemoteFilter()
> {
> Query = predicateExpression,
> IsWildListener = string.IsNullOrEmpty(predicateExpression)
> }
>
> };var initialQry = new SqlQuery(typeof(TV), initalquery);
>var queryHandle = Cache.QueryContinuous(qry, initialQry);// **At this
> point error occurs**var listenerDetails = new ListenerDetails()
> \{
> QueryHandle = queryHandle,
> listener = listener
>
> };
>
>
> listenerDetails.PredicateExpr = predicateExpression;
> listenerDetails.Predicate =
> System.Linq.Dynamic.Core.DynamicExpressionParser.ParseLambda(ParsingConfig.Default,
> true, predicateExpression).Compile();
>
>
> ListenerLookup.Add(queryKey, listenerDetails);return
> createList(queryHandle.GetInitialQueryCursor(), ref seekInfo);
> }}}
> * {{}}
> * {{}}
> * This is the error i am getting.
> * {{}}
> *
> {{{} Error Message : Apache.Ignite.Core.Common.IgniteException: Failed to
> parse query. Syntax error in SQL statement SELECT TOP 10 A._KEY, TOP 10[*]
> A._VAL FROM ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT
> IN ( '10001', '10002', '10003' ) ) ;
> SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' )
> ) [42000-197] ---> Apache.Ignite.Core.Common.JavaException: class
> org.apache.ignite.IgniteCheckedException: Failed to parse query. Syntax error
> in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
> ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN (
> '10001', '10002', '10003' ) ) ;
> SQL statement:SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002','10003') )
> [42000-197]
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:520)
>
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1242)
>
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:883)
>
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> * Caused by: javax.cache.CacheException: Failed to parse query.Syntax
> error in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
> ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN (
> '10001', '10002', '10003' ) ) ;
> SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' )
> ) [42000-197]
> at
>
[jira] [Updated] (IGNITE-17721) Make AbstractConfiguration a legal inside NamedConfigValue
[ https://issues.apache.org/jira/browse/IGNITE-17721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17721: - Labels: ignite-3 (was: ) > Make AbstractConfiguration a legal inside NamedConfigValue > -- > > Key: IGNITE-17721 > URL: https://issues.apache.org/jira/browse/IGNITE-17721 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17718) Implement the way to configure metric sources
[ https://issues.apache.org/jira/browse/IGNITE-17718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17718: - Labels: ignite-3 (was: ) > Implement the way to configure metric sources > -- > > Key: IGNITE-17718 > URL: https://issues.apache.org/jira/browse/IGNITE-17718 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17714) Split integration test in ignite-runner module
[ https://issues.apache.org/jira/browse/IGNITE-17714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17714: - Labels: ignite-3 (was: ) > Split integration test in ignite-runner module > -- > > Key: IGNITE-17714 > URL: https://issues.apache.org/jira/browse/IGNITE-17714 > Project: Ignite > Issue Type: Improvement > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Ignite-runner module contains tests with "sqllogic" tag and need to create > separate gradle tasks for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17714) Split integration test in ignite-runner module
[ https://issues.apache.org/jira/browse/IGNITE-17714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17714: - Component/s: (was: ignite-3) > Split integration test in ignite-runner module > -- > > Key: IGNITE-17714 > URL: https://issues.apache.org/jira/browse/IGNITE-17714 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Ignite-runner module contains tests with "sqllogic" tag and need to create > separate gradle tasks for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17711) Change Binary Tuple Prefix format to allow comparison without deserialization
[ https://issues.apache.org/jira/browse/IGNITE-17711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17711: - Labels: ignite-3 (was: ) > Change Binary Tuple Prefix format to allow comparison without deserialization > - > > Key: IGNITE-17711 > URL: https://issues.apache.org/jira/browse/IGNITE-17711 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Priority: Minor > Labels: ignite-3 > > BinaryTuplePrefix format dictates that the number of prefix elements are > appended to the end of the tuple. This is currently implemented as inserting > an extra int element which also implies an extra entry in the offset map and > non-deterministic size of this element (it can occupy from 1 to 4 bytes). > This was done for the sake of simplicity but it also has an implication: it > is not possible to simply compare it with a BinaryTuple byte-by-byte in order > to determine if a given prefix matches a given tuple. A better approach would > be to append the number of elements directly as the last two bytes (or four, > if necessary) of the tuple, bypassing the entry table. This way we can > discard the last two bytes and compare the prefix and the tuple on a per-byte > basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17701) C++ common portability utilities for ignite-3
[ https://issues.apache.org/jira/browse/IGNITE-17701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17701: - Labels: ignite-3 (was: ) > C++ common portability utilities for ignite-3 > - > > Key: IGNITE-17701 > URL: https://issues.apache.org/jira/browse/IGNITE-17701 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 3.0.0-alpha6 >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 40m > Remaining Estimate: 0h > > Provide common C++ utilities and that are useful for cross-platform > development of other libraries, e.g. for binary tuple support, for client > libraries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17696) C++ coding conventions for ignite-3
[ https://issues.apache.org/jira/browse/IGNITE-17696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17696: - Labels: ignite-3 (was: ) > C++ coding conventions for ignite-3 > --- > > Key: IGNITE-17696 > URL: https://issues.apache.org/jira/browse/IGNITE-17696 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 3.0.0-alpha6 >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Establish common style for C++ code in Apache Ignite 3. The suggested > approach is as follows: > * the C++ code style should resemble the Java style for consistency; > * for things that are specific to C++ or break C++ industry-established > practices too violently the rules will be settled one by one and described in > a MD document in the repo. > A clang-format file will be provided for automatic indentation of the code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17693) Unify all copyrights
[
https://issues.apache.org/jira/browse/IGNITE-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-17693:
Assignee: Mikhail Pochatkin
> Unify all copyrights
>
>
> Key: IGNITE-17693
> URL: https://issues.apache.org/jira/browse/IGNITE-17693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Change all copyrights to one format
> {code:java}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> {code}
> The source of this license can be found here:
> https://www.apache.org/legal/src-headers.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17693) Unify all copyrights
[
https://issues.apache.org/jira/browse/IGNITE-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17693:
-
Labels: ignite-3 (was: )
> Unify all copyrights
>
>
> Key: IGNITE-17693
> URL: https://issues.apache.org/jira/browse/IGNITE-17693
> Project: Ignite
> Issue Type: Improvement
> Components: ignite-3
>Reporter: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Change all copyrights to one format
> {code:java}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> {code}
> The source of this license can be found here:
> https://www.apache.org/legal/src-headers.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17692) Flaky test after introduce gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17692: - Labels: ignite-3 (was: ) > Flaky test after introduce gradle build > --- > > Key: IGNITE-17692 > URL: https://issues.apache.org/jira/browse/IGNITE-17692 > Project: Ignite > Issue Type: Bug > Components: build, ignite-3 >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17691) Support binary tuple format (IEP-92)
[ https://issues.apache.org/jira/browse/IGNITE-17691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17691: - Labels: ignite-3 (was: ) > Support binary tuple format (IEP-92) > > > Key: IGNITE-17691 > URL: https://issues.apache.org/jira/browse/IGNITE-17691 > Project: Ignite > Issue Type: Epic >Reporter: Aleksey Demakov >Priority: Major > Labels: ignite-3 > > Provide binary tuple format > ([IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]) > implementations for all required platforms: > * Java > * C++ > * .NET > Make use of the format where it fits: > * in storage engines > * on the client side > * probably for SQL processing > * perhaps for replication as well? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17693) Unify all copyrights
[
https://issues.apache.org/jira/browse/IGNITE-17693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17693:
-
Component/s: (was: ignite-3)
> Unify all copyrights
>
>
> Key: IGNITE-17693
> URL: https://issues.apache.org/jira/browse/IGNITE-17693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Pochatkin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Change all copyrights to one format
> {code:java}
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
> {code}
> The source of this license can be found here:
> https://www.apache.org/legal/src-headers.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17692) Flaky test after introduce gradle build
[ https://issues.apache.org/jira/browse/IGNITE-17692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17692: - Component/s: (was: ignite-3) > Flaky test after introduce gradle build > --- > > Key: IGNITE-17692 > URL: https://issues.apache.org/jira/browse/IGNITE-17692 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17729) Forbidding a table and an index with the same names.
Evgeny Stanilovsky created IGNITE-17729:
---
Summary: Forbidding a table and an index with the same names.
Key: IGNITE-17729
URL: https://issues.apache.org/jira/browse/IGNITE-17729
Project: Ignite
Issue Type: Improvement
Components: sql
Affects Versions: 3.0.0-alpha5
Reporter: Evgeny Stanilovsky
>From code review for [1] Andrey Mashenkov highlight what:
{noformat}
As far as I remember, we thought about forbidding a table and an index with the
same names.
Let's add a check here or create a separate ticket for this particular case.
{noformat}
[1] https://issues.apache.org/jira/browse/IGNITE-17474
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17474) Rework configuration hierarchy
[ https://issues.apache.org/jira/browse/IGNITE-17474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607123#comment-17607123 ] Andrey Mashenkov commented on IGNITE-17474: --- [~zstan], PR looks fine. I've left few comments. Please fix and proceed with merging. > Rework configuration hierarchy > -- > > Key: IGNITE-17474 > URL: https://issues.apache.org/jira/browse/IGNITE-17474 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > Currently indices configuration is subtree of a table configuration. Such a > hierarchy increases complexity of the objects validation. > That could be improved by reworking the configuration in a way both indexes > and tables belong to the same layer. This will give us tables' and indexes > name uniqueness validation out of the box. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17678) Create documentation for AI3 transaction changes
[ https://issues.apache.org/jira/browse/IGNITE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-17678: Fix Version/s: 3.0.0-alpha6 Reviewer: Alexey Scherbakov Assignee: Igor Gusev (was: Alexey Scherbakov) Resolution: Fixed > Create documentation for AI3 transaction changes > > > Key: IGNITE-17678 > URL: https://issues.apache.org/jira/browse/IGNITE-17678 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to document changes in AI transactions for the next release. Changes > can be based on https://cwiki.apache.org/confluence/display/IGNITE/IEP-91 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17678) Create documentation for AI3 transaction changes
[ https://issues.apache.org/jira/browse/IGNITE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-17678: Assignee: Alexey Scherbakov > Create documentation for AI3 transaction changes > > > Key: IGNITE-17678 > URL: https://issues.apache.org/jira/browse/IGNITE-17678 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > > We need to document changes in AI transactions for the next release. Changes > can be based on https://cwiki.apache.org/confluence/display/IGNITE/IEP-91 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17679) Consistency check/repair and Read Repair documentation update
[ https://issues.apache.org/jira/browse/IGNITE-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607088#comment-17607088 ] Anton Vinogradov edited comment on IGNITE-17679 at 9/20/22 10:43 AM: - [~ivandasch] , thanks for the review! Merged to the master. was (Author: av): [~ivandasch] , thanks for the review! Merget to the master. > Consistency check/repair and Read Repair documentation update > - > > Key: IGNITE-17679 > URL: https://issues.apache.org/jira/browse/IGNITE-17679 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.14 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Need to update the doc according to changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17679) Consistency check/repair and Read Repair documentation update
[ https://issues.apache.org/jira/browse/IGNITE-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607089#comment-17607089 ] Anton Vinogradov commented on IGNITE-17679: --- Merged to the ignite-2.14 > Consistency check/repair and Read Repair documentation update > - > > Key: IGNITE-17679 > URL: https://issues.apache.org/jira/browse/IGNITE-17679 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Need to update the doc according to changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17679) Consistency check/repair and Read Repair documentation update
[ https://issues.apache.org/jira/browse/IGNITE-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-17679: -- Fix Version/s: 2.14 > Consistency check/repair and Read Repair documentation update > - > > Key: IGNITE-17679 > URL: https://issues.apache.org/jira/browse/IGNITE-17679 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.14 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Need to update the doc according to changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17679) Consistency check/repair and Read Repair documentation update
[ https://issues.apache.org/jira/browse/IGNITE-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607088#comment-17607088 ] Anton Vinogradov commented on IGNITE-17679: --- [~ivandasch] , thanks for the review! Merget to the master. > Consistency check/repair and Read Repair documentation update > - > > Key: IGNITE-17679 > URL: https://issues.apache.org/jira/browse/IGNITE-17679 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Need to update the doc according to changes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17679) Consistency check/repair and Read Repair documentation update
[
https://issues.apache.org/jira/browse/IGNITE-17679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607087#comment-17607087
]
Ignite TC Bot commented on IGNITE-17679:
{panel:title=Branch: [pull/10254/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10254/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6616501buildTypeId=IgniteTests24Java8_RunAll]
> Consistency check/repair and Read Repair documentation update
> -
>
> Key: IGNITE-17679
> URL: https://issues.apache.org/jira/browse/IGNITE-17679
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Need to update the doc according to changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17723) Investigate sorting of snapshot delta pages
[ https://issues.apache.org/jira/browse/IGNITE-17723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17723: - Description: The snapshot manager applies delta pages to a partition in a random write manner. This leads to a high disk utilisation in a case of some hardware disks types. Possible solutions: - Limit delta applying speed separate with partitions limit. - Pre-sort pages. was: The snapshot manager applies delta pages to a partition in a random write manner. This leads to a high disk utilisation in a case of some types hardware. Possible solutions: - Limit delta applying speed separate with partitions limit. - Pre-sort pages. > Investigate sorting of snapshot delta pages > --- > > Key: IGNITE-17723 > URL: https://issues.apache.org/jira/browse/IGNITE-17723 > Project: Ignite > Issue Type: Improvement >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > > The snapshot manager applies delta pages to a partition in a random write > manner. This leads to a high disk utilisation in a case of some hardware > disks types. > Possible solutions: > - Limit delta applying speed separate with partitions limit. > - Pre-sort pages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17723) Investigate sorting of snapshot delta pages
[ https://issues.apache.org/jira/browse/IGNITE-17723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17723: - Description: The snapshot manager applies delta pages to a partition in a random write manner. This leads to a high disk utilisation in a case of some types hardware. Possible solutions: - Limit delta applying speed separate with partitions limit. - Pre-sort pages. was: The snapshot manager applies delta pages to a partition in a random write manner. This leads to a high disk utilization in a case of hdd hardware. Possible solutions: - Limit delta applying speed separate with partitions limit. - Pre-sort pages. > Investigate sorting of snapshot delta pages > --- > > Key: IGNITE-17723 > URL: https://issues.apache.org/jira/browse/IGNITE-17723 > Project: Ignite > Issue Type: Improvement >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > > The snapshot manager applies delta pages to a partition in a random write > manner. This leads to a high disk utilisation in a case of some types > hardware. > Possible solutions: > - Limit delta applying speed separate with partitions limit. > - Pre-sort pages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17695) Split IgniteControlUtilityTestSuite in two
[ https://issues.apache.org/jira/browse/IGNITE-17695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607049#comment-17607049 ] Roman Puchkovskiy commented on IGNITE-17695: The CI failures are caused by CI problems and are not related to the changes in the PR > Split IgniteControlUtilityTestSuite in two > -- > > Key: IGNITE-17695 > URL: https://issues.apache.org/jira/browse/IGNITE-17695 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > According to > [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ControlUtility=buildTypeStatusDiv] > , the suite takes more than 2 hours to run to completion. Often it exceeds > the time limit and times out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17695) Split IgniteControlUtilityTestSuite in two
[
https://issues.apache.org/jira/browse/IGNITE-17695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607048#comment-17607048
]
Ignite TC Bot commented on IGNITE-17695:
{panel:title=Branch: [pull/10253/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6775399]]
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0 Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=6776468]]
{panel}
{panel:title=Branch: [pull/10253/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6771611buildTypeId=IgniteTests24Java8_RunAll]
> Split IgniteControlUtilityTestSuite in two
> --
>
> Key: IGNITE-17695
> URL: https://issues.apache.org/jira/browse/IGNITE-17695
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> According to
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ControlUtility=buildTypeStatusDiv]
> , the suite takes more than 2 hours to run to completion. Often it exceeds
> the time limit and times out.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17686) Check Futures in sql-engine module on exception handling
[ https://issues.apache.org/jira/browse/IGNITE-17686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-17686: -- Assignee: Andrey Mashenkov > Check Futures in sql-engine module on exception handling > > > Key: IGNITE-17686 > URL: https://issues.apache.org/jira/browse/IGNITE-17686 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, tech-debt > > There are places in code of sql-engine module where we don't take into > account errors during work with a Future. > Let's check whole module to find and fix such problems. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17684) Investigate of using BinaryTuple instead of array of objects in SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-17684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17684: --- Description: Right now internaly we use array of objects to represent row in SQL instead of BinaryTuple and do unnecessary convertation. Let's investigate possibility migration from array of objects to direct usage of BinaryTuple in execution tree. There are possible issue for some type execution, like a twophase aggregates and potentialy we should use different representation of row for different parts. Start points are: org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow As result of the task - list of issues which need to be resolved to implement reuse BinaryTuple was: Right now internaly we use array of objects to represent row in SQL instead of BinaryTuple and do unnecessary convertation. Let's investigate possibility migration from array of objects to direct usage of BinaryTuple in execution tree. There are possible issue for some type execution, like a twophase aggregates and potentialy we should use different representation of row for different parts. Start points are: org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow As result of the task - list of issues which need to be resolved to implement reuse BinaryTyple > Investigate of using BinaryTuple instead of array of objects in SQL execution > - > > Key: IGNITE-17684 > URL: https://issues.apache.org/jira/browse/IGNITE-17684 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > Right now internaly we use array of objects to represent row in SQL instead > of BinaryTuple and do unnecessary convertation. > Let's investigate possibility migration from array of objects to direct usage > of BinaryTuple in execution tree. There are possible issue for some type > execution, like a twophase aggregates and potentialy we should use different > representation of row for different parts. > Start points are: > org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler > org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow > As result of the task - list of issues which need to be resolved to implement > reuse BinaryTuple -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17684) Investigate of using BinaryTuple instead of array of objects in SQL execution
[ https://issues.apache.org/jira/browse/IGNITE-17684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17684: --- Description: Right now internaly we use array of objects to represent row in SQL instead of BinaryTuple and do unnecessary convertation. Let's investigate possibility migration from array of objects to direct usage of BinaryTuple in execution tree. There are possible issue for some type execution, like a twophase aggregates and potentialy we should use different representation of row for different parts. Start points are: org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow As result of the task - list of issues which need to be resolved to implement reuse BinaryTyple was: Right now internaly we use array of objects to represent row in SQL instead of BinaryTuple and do unnecessary convertation. Let's investigate possibility migration from array of objects to direct usage of BinaryTuple in execution tree. There are possible issue for some type execution, like a twophase aggregates and potentialy we should use different representation of row for different parts. Start points are: org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow > Investigate of using BinaryTuple instead of array of objects in SQL execution > - > > Key: IGNITE-17684 > URL: https://issues.apache.org/jira/browse/IGNITE-17684 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > Right now internaly we use array of objects to represent row in SQL instead > of BinaryTuple and do unnecessary convertation. > Let's investigate possibility migration from array of objects to direct usage > of BinaryTuple in execution tree. There are possible issue for some type > execution, like a twophase aggregates and potentialy we should use different > representation of row for different parts. > Start points are: > org.apache.ignite.internal.sql.engine.exec.ArrayRowHandler > org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl#toRow > As result of the task - list of issues which need to be resolved to implement > reuse BinaryTyple -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17686) Check Futures in sql-engine module on exception handling
[ https://issues.apache.org/jira/browse/IGNITE-17686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-17686: --- Summary: Check Futures in sql-engine module on exception handling (was: Check Futures in eql-engine module on exception handling) > Check Futures in sql-engine module on exception handling > > > Key: IGNITE-17686 > URL: https://issues.apache.org/jira/browse/IGNITE-17686 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3, tech-debt > > There are places in code of sql-engine module where we don't take into > account errors during work with a Future. > Let's check whole module to find and fix such problems. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17728) Improve data size-related metrics
[
https://issues.apache.org/jira/browse/IGNITE-17728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17728:
-
Description:
There are several problems with the current approach to metrics related to
pages and sizes occupied by data:
# {{PagesFillFactor}} implementation is strange: though its javadoc is pretty
much useless, one might think that it represents a percentage of bytes occupied
by data in relation to the whole available bytes. However, for some reason, it
is calculated as {{(TotalSpace - FreeSpaceInDataPages) / TotalSpace}}, i.e. it
does not take completely empty pages into account.
# There exists a {{TotalUsedPages}} metric that is only available through JMX,
it does not get registered in the MetricsRegistry.
# There exists {{TotalAllocatedPages}} and {{TotalAllocatedSize}} metrics, but
no {{TotalUsedSize}} metrics.
# It would be helpful to add a metric that calculates bytes, occupied by the
data (even though it can be indirectly computed using the {{PagesFillFactor}}).
> Improve data size-related metrics
> -
>
> Key: IGNITE-17728
> URL: https://issues.apache.org/jira/browse/IGNITE-17728
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> There are several problems with the current approach to metrics related to
> pages and sizes occupied by data:
> # {{PagesFillFactor}} implementation is strange: though its javadoc is pretty
> much useless, one might think that it represents a percentage of bytes
> occupied by data in relation to the whole available bytes. However, for some
> reason, it is calculated as {{(TotalSpace - FreeSpaceInDataPages) /
> TotalSpace}}, i.e. it does not take completely empty pages into account.
> # There exists a {{TotalUsedPages}} metric that is only available through
> JMX, it does not get registered in the MetricsRegistry.
> # There exists {{TotalAllocatedPages}} and {{TotalAllocatedSize}} metrics,
> but no {{TotalUsedSize}} metrics.
> # It would be helpful to add a metric that calculates bytes, occupied by the
> data (even though it can be indirectly computed using the
> {{PagesFillFactor}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15629) Cluster Management API
[ https://issues.apache.org/jira/browse/IGNITE-15629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-15629: - Labels: iep-81 important ise (was: iep-81 important) > Cluster Management API > -- > > Key: IGNITE-15629 > URL: https://issues.apache.org/jira/browse/IGNITE-15629 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-81, important, ise > > Ignite must provide cluster management internal API in that way the other > available user APIs like REST, CLI or JMX won't require the source code > changes. > The following features must be available out of the box: > - man pages and documentation autogeneration > - registering new commands from plugins -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17727) HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in constructor.
[ https://issues.apache.org/jira/browse/IGNITE-17727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-17727: Labels: ignite-3 (was: ) > HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in > constructor. > > > Key: IGNITE-17727 > URL: https://issues.apache.org/jira/browse/IGNITE-17727 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha5 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > After merger [1] constructors for HashIndexDescriptor and > SortedIndexDescriptor obtained one redundant field _tableConfig_ - for > simplifying huge existence tests only. We need remove this param and fix > appropriate tests. > [1] https://issues.apache.org/jira/browse/IGNITE-17474 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17728) Improve data size-related metrics
Aleksandr Polovtcev created IGNITE-17728: Summary: Improve data size-related metrics Key: IGNITE-17728 URL: https://issues.apache.org/jira/browse/IGNITE-17728 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17727) HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in constructor.
Evgeny Stanilovsky created IGNITE-17727: --- Summary: HashIndexDescriptor and SortedIndexDescriptor don`t need tableConfig in constructor. Key: IGNITE-17727 URL: https://issues.apache.org/jira/browse/IGNITE-17727 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-alpha5 Reporter: Evgeny Stanilovsky After merger [1] constructors for HashIndexDescriptor and SortedIndexDescriptor obtained one redundant field _tableConfig_ - for simplifying huge existence tests only. We need remove this param and fix appropriate tests. [1] https://issues.apache.org/jira/browse/IGNITE-17474 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15425) Calcite engine. Add native support for SEARCH/SARG operator
[
https://issues.apache.org/jira/browse/IGNITE-15425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17606954#comment-17606954
]
Ignite TC Bot commented on IGNITE-15425:
{panel:title=Branch: [pull/10251/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10251/head] Base: [master] : New Tests
(16)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
16|https://ci2.ignite.apache.org/viewLog.html?buildId=6616080]]
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsOneFieldSearchWithNull - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsWithCorrelate - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsOneFieldSearchRangeOptimization -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsSeveralFieldsSearch - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsMaxComplexity - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsDynamicParams - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsOneFieldSearchDeduplication -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsOneFieldSearch - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexPlannerTest.testBoundsDescOrdering - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testNulls - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
SearchSargOnIndexIntegrationTest.testNot - PASSED{color}
... and 5 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6616159buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Add native support for SEARCH/SARG operator
> ---
>
> Key: IGNITE-15425
> URL: https://issues.apache.org/jira/browse/IGNITE-15425
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, Calcite compose some field conditions to {{SEARCH/SARG}} operator
> (for example: {{field IN (scalar)}}, {{field <> ...}}, {{field = value1 OR
> field = value2}}, etc). This operator is not supported natively by Ignite
> Calcite engine and converted back to original expression using
> {{RexUtil.expandSearch}} method on the {{RexToLixTranslator}} phase.
> Such behavior forces Ignite to use full table scan instead of indexes in
> some cases. For example, if {{field}} is indexed, with {{field IN (1, 2)}}
> condition usually is much faster to scan index for 2 values, then full scan
> table and filter out results. For {{OR}} operator {{OrToUnion}} rule can't be
> applied and there will be full table scan again.
> We should support index traversing using SEARCH/SARG operator.
> Alternatively we can convert {{SEARCH/SARG}} to {{UNIONs}} (similarly to
> {{OrToUnion}} rule), but this approach will extend plan search space a lot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17709) SQL: Support table hints.
[ https://issues.apache.org/jira/browse/IGNITE-17709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17709: -- Labels: calcite2-required ignite-3 (was: ignite-3) > SQL: Support table hints. > - > > Key: IGNITE-17709 > URL: https://issues.apache.org/jira/browse/IGNITE-17709 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Labels: calcite2-required, ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > Currently Ignite table scan implementation completely ignores _table_ > [hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html]. > We need to add support for them to be able to handle index and other table > hints. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17709) SQL: Support table hints.
[ https://issues.apache.org/jira/browse/IGNITE-17709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17709: -- Fix Version/s: 3.0.0-alpha6 > SQL: Support table hints. > - > > Key: IGNITE-17709 > URL: https://issues.apache.org/jira/browse/IGNITE-17709 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Labels: calcite2-required, ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently Ignite table scan implementation completely ignores _table_ > [hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html]. > We need to add support for them to be able to handle index and other table > hints. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17568) Improve logging in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-17568: - Assignee: Vadim Pakhnushev > Improve logging in CLI > -- > > Key: IGNITE-17568 > URL: https://issues.apache.org/jira/browse/IGNITE-17568 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > After playing with the Ignite 3 CLI a user could find his home dir is > polluted with files igtnite-*.log that might be confusing. > The aim of this ticket is to find a proper dirrectory and write logs there. > It might be a good idea if this dirrectory is confugurable. For example, by > default we write logs to /var/log/ignite-cli but the user can configure this > location in cli config. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17707) Unify annotation dependency
[ https://issues.apache.org/jira/browse/IGNITE-17707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17707: - Labels: ignite-3 (was: ) > Unify annotation dependency > --- > > Key: IGNITE-17707 > URL: https://issues.apache.org/jira/browse/IGNITE-17707 > Project: Ignite > Issue Type: Task > Components: rest >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Minor > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In the IGNITE-17510 jsr305 was used to annotate JSON properties. In fact > using org.jetbrains.annotations is enough and it was already used for this > purpose. > Let's remove jsr305 dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17707) Unify annotation dependency
[ https://issues.apache.org/jira/browse/IGNITE-17707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17707: - Reviewer: Vyacheslav Koptilin Issue Type: Bug (was: Task) > Unify annotation dependency > --- > > Key: IGNITE-17707 > URL: https://issues.apache.org/jira/browse/IGNITE-17707 > Project: Ignite > Issue Type: Bug > Components: rest >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Minor > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In the IGNITE-17510 jsr305 was used to annotate JSON properties. In fact > using org.jetbrains.annotations is enough and it was already used for this > purpose. > Let's remove jsr305 dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17726) Packaging: Docker image
Mikhail Pochatkin created IGNITE-17726: -- Summary: Packaging: Docker image Key: IGNITE-17726 URL: https://issues.apache.org/jira/browse/IGNITE-17726 Project: Ignite Issue Type: Improvement Components: ignite-3 Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17725) Thin 3.0: Implement Partition Awareness in Java client
[ https://issues.apache.org/jira/browse/IGNITE-17725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17725: Description: Implement partition awareness in Java thin client as per [IEP-95|https://cwiki.apache.org/confluence/display/IGNITE/IEP-95+Client+Partition+Awareness] > Thin 3.0: Implement Partition Awareness in Java client > -- > > Key: IGNITE-17725 > URL: https://issues.apache.org/jira/browse/IGNITE-17725 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-95, ignite-3 > Fix For: 3.0.0-alpha6 > > > Implement partition awareness in Java thin client as per > [IEP-95|https://cwiki.apache.org/confluence/display/IGNITE/IEP-95+Client+Partition+Awareness] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17725) Thin 3.0: Implement Partition Awareness in Java client
Pavel Tupitsyn created IGNITE-17725: --- Summary: Thin 3.0: Implement Partition Awareness in Java client Key: IGNITE-17725 URL: https://issues.apache.org/jira/browse/IGNITE-17725 Project: Ignite Issue Type: Bug Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17724) .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky
Pavel Tupitsyn created IGNITE-17724: --- Summary: .NET: TestPrimaryNodeLeaveClearsPlatformCache is flaky Key: IGNITE-17724 URL: https://issues.apache.org/jira/browse/IGNITE-17724 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Apache.Ignite.Core.Tests.Cache.Platform.PlatformCacheTopologyChangeTest.TestPrimaryNodeLeaveClearsPlatformCache is flaky. https://ci.ignite.apache.org/test/-4466167631530075752?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.10#820010)
