[jira] [Commented] (IGNITE-18183) Rest endpoint for all node metrics
[
https://issues.apache.org/jira/browse/IGNITE-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635407#comment-17635407
]
Stanislav Lukyanov commented on IGNITE-18183:
-
This is not specific to metrics. The same is applicable to any endpoint working
per node: config, version, etc.
It seems that all of the `/node/` endpoints need to have "flavors" of access -
getting data locally and getting data from one or multiple nodes in the cluster.
I guess it means re-writing all of these `/node/` handlers in a way that
supports sending remote requests. Ignite 2 does that all the time via compute
jobs, I guess Ignite 3 would do the same.
Also, seems like it might need to be `/nodes/` (plural). I like Elastic's
structure a lot.
> Rest endpoint for all node metrics
> --
>
> Key: IGNITE-18183
> URL: https://issues.apache.org/jira/browse/IGNITE-18183
> Project: Ignite
> Issue Type: Task
> Components: ignite-3
>Reporter: Stepachev Maksim
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> *The problem:*
> The ignite 3 rest of clusters will usually be hided behind a load balancer,
> as result we aren't able to get a particular node metrics. In this task is
> required to develop an endpoint at your discretion that will extract metrics
> from all nodes by one call.
> *Possible path at your wish:*
> * /all-nodes/metrics
> * {{/node/all/metrics}} - query all nodes (like {{all-nodes}} above)
> * {{/node/12345678-1234-1234-1234-12345678/metrics}} - query that particular
> node even if we happen to connect to a different one{{{}{}}}
> * {{/node/local/metrics}} - query the node we connected to
> *Please look at these examples of other databases:*
> *
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html]
> *
> [https://docs.spring.io/spring-boot/docs/current/actuator-api/htmlsingle/#metrics]
> * [https://micronaut-projects.github.io/micronaut-micrometer/latest/guide/]
> * Etc.
> It would be good if we could add filters to get specific sets of metrics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
[ https://issues.apache.org/jira/browse/IGNITE-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18129: Description: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget was: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: zip, rpm, deb * nuget > Fix Ignite 3 build and publishing for beta 1 > > > Key: IGNITE-18129 > URL: https://issues.apache.org/jira/browse/IGNITE-18129 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > Need to make a few small fixes in the build and publishing process: > * Fix the readme to mention beta 1 instead of alpha 5 > * Automatically build and sign src.zip > * Automatically build and sign .NET NuGet package (package .nuget into a > .nuget.zip like it is done in 2.x) > * Update release.md as needed > The following artifacts need to be uploaded to the release repository: > * src.zip > * ignite: zip, rpm, deb > * ignite-db: zip, rpm, deb > * ignite-client: jar > * nuget -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
[ https://issues.apache.org/jira/browse/IGNITE-18129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18129: Description: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget.zip was: Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: jar * nuget > Fix Ignite 3 build and publishing for beta 1 > > > Key: IGNITE-18129 > URL: https://issues.apache.org/jira/browse/IGNITE-18129 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > Need to make a few small fixes in the build and publishing process: > * Fix the readme to mention beta 1 instead of alpha 5 > * Automatically build and sign src.zip > * Automatically build and sign .NET NuGet package (package .nuget into a > .nuget.zip like it is done in 2.x) > * Update release.md as needed > The following artifacts need to be uploaded to the release repository: > * src.zip > * ignite: zip, rpm, deb > * ignite-db: zip, rpm, deb > * ignite-client: jar > * nuget.zip -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18129) Fix Ignite 3 build and publishing for beta 1
Stanislav Lukyanov created IGNITE-18129: --- Summary: Fix Ignite 3 build and publishing for beta 1 Key: IGNITE-18129 URL: https://issues.apache.org/jira/browse/IGNITE-18129 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov Need to make a few small fixes in the build and publishing process: * Fix the readme to mention beta 1 instead of alpha 5 * Automatically build and sign src.zip * Automatically build and sign .NET NuGet package (package .nuget into a .nuget.zip like it is done in 2.x) * Update release.md as needed The following artifacts need to be uploaded to the release repository: * src.zip * ignite: zip, rpm, deb * ignite-db: zip, rpm, deb * ignite-client: zip, rpm, deb * nuget -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17588: Fix Version/s: 3.0.0-beta2 (was: 3.0.0-beta1) > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630245#comment-17630245 ] Stanislav Lukyanov commented on IGNITE-17588: - Looks like this one wasn't on time for beta1. That's OK, we'll get it done in the next version. Changed the fixVersion. > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17989) JVM memory usage metric source
[ https://issues.apache.org/jira/browse/IGNITE-17989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17989: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > JVM memory usage metric source > -- > > Key: IGNITE-17989 > URL: https://issues.apache.org/jira/browse/IGNITE-17989 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > It will be useful to have builtin metric source with jvm memory usage stats. > h3. Definition of Done > It must expose the following metrics as a separate gauge metric each: > * heap memory usage (init/used/commited/max) > * non-heap memory usage (init/used/commited/max) > * name of metrics should have the general prefix "jvm." to group all future > jvm metrics together > Also, it needs to check, if calculation of these stats is heavy and we need > to cache it for some time windows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17357) JMX metric exporter for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-17357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17357: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > JMX metric exporter for Ignite 3 > > > Key: IGNITE-17357 > URL: https://issues.apache.org/jira/browse/IGNITE-17357 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 50m > Remaining Estimate: 0h > > Metrics should be able to be exported via JMX as a first stage of metrics > exposing. > Exporter implementation must provide the following behavior: > * for each MetricSource we need to provide separate MBean with attribute per > metric > * each MBean attribute must have the same name as corresponding metric > * on enable/disable event for MetricSource corresponding MBean must be > registered/unregistered -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17759) Need to pass commitTableId and commitPartitionId to MvPartitionStorage#addWrite
[
https://issues.apache.org/jira/browse/IGNITE-17759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-17759:
Labels: fix-version-validated ignite-3 transaction3_ro (was: ignite-3
transaction3_ro)
> Need to pass commitTableId and commitPartitionId to
> MvPartitionStorage#addWrite
> ---
>
> Key: IGNITE-17759
> URL: https://issues.apache.org/jira/browse/IGNITE-17759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: fix-version-validated, ignite-3, transaction3_ro
> Fix For: 3.0.0-beta1
>
>
> Currently when PartitionListener invokes MvPartitionStorage#addWrite it
> passes
> UUID.randomUUID() as commitTableId and 0 as commitPartitionId. Need pass
> appropriate values.
>
> For this:
> # Need to create
> {code:java}
> class PartitionId {
> UUID tableId;
> int partId;
> }{code}
> # In InternalTableImpl#enlistInTx need to save PartitionId of the first
> operation to the Transaction.
> # Need to change {color:#172b4d}Map Long>> enlisted = new ConcurrentSkipListMap<>(){color} to Map IgniteBiTuple> enlisted = new ConcurrentHashMap<>();
> # Need to change String groupId to PartitionId groupId in all places.
> # In InternalTableImpl#enlistInTx need to pass PartitionId into
> ReplicaRequest (ReadWriteSingleRowReplicaRequest,
> ReadWriteSwapRowReplicaRequest, ReadWriteMultiRowReplicaRequest)
> # In PartitionReplicaListener need to pass PartitionId from ReplicaRequest
> to UpdateCommand and UpdateAllCommand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17669) Implement node version command
[ https://issues.apache.org/jira/browse/IGNITE-17669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17669: Labels: fix-version-validated ignite-3 (was: ignite-3) > Implement node version command > -- > > Key: IGNITE-17669 > URL: https://issues.apache.org/jira/browse/IGNITE-17669 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > /management/v1/node/version/ GET returns the Ignite 3 node build version. > Implement both REPL and non-REPL commands to display it in CLI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16760) Performance degradation of IgniteTables#tables after configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-16760:
Labels: fix-version-validated ignite-3 (was: ignite-3)
> Performance degradation of IgniteTables#tables after configuration changes
> --
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: fix-version-validated, ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> for (Table t : ign.tables().tables()) {
> ;
> }
> {code}
> On begin {{IgniteTables#tables}} takes ~ 0.7 sec.
> The time of the operation is grown.
> The time after ~100 iteration is about 20 sec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17265) Support RAFT snapshot streaming for PageMemory storage
[ https://issues.apache.org/jira/browse/IGNITE-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17265: Labels: fix-version-validated ignite-3 (was: ignite-3) > Support RAFT snapshot streaming for PageMemory storage > -- > > Key: IGNITE-17265 > URL: https://issues.apache.org/jira/browse/IGNITE-17265 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > IGNITE-17254 API needs to be implemented for PageMemory storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17425) C++ 3.0: Basic C++ client
[ https://issues.apache.org/jira/browse/IGNITE-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17425: Labels: fix-version-validated ignite-3 (was: ignite-3) > C++ 3.0: Basic C++ client > - > > Key: IGNITE-17425 > URL: https://issues.apache.org/jira/browse/IGNITE-17425 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > Implement basic C++ 3.0 client that can be used as a base to add new features. > What should be done: > * Set up project structure (CMake + consider Conan); > * Establish code style; > * Document project building; > * Target C++14?; > * Set up tests (consider GTest for testing); > * Implement networking (consider adopting some library, e.g. asio); > * Implement minimal set of operations: get table by name, upsert, get; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17488) Packaging: Zip archive
[ https://issues.apache.org/jira/browse/IGNITE-17488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17488: Labels: fix-version-validated ignite-3 (was: ignite-3) > Packaging: Zip archive > --- > > Key: IGNITE-17488 > URL: https://issues.apache.org/jira/browse/IGNITE-17488 > Project: Ignite > Issue Type: New Feature > Components: build >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > Create zip archive target with all Apache Ignite binaries and > install\uninstall\update scripts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17395) Thin 3.0: Design Partition Awareness for Ignite-3
[ https://issues.apache.org/jira/browse/IGNITE-17395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17395: Labels: fix-version-validated iep-95 ignite-3 (was: iep-95 ignite-3) > Thin 3.0: Design Partition Awareness for Ignite-3 > -- > > Key: IGNITE-17395 > URL: https://issues.apache.org/jira/browse/IGNITE-17395 > Project: Ignite > Issue Type: Task > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: fix-version-validated, iep-95, ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to design Partition Awareness feature for Ignite-3 (here is analogue for > Ignite-2: > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+Thin+Clients]). > As a result, IEP should be created, discussed on the devlist and approved > for development. > See IGNITE-17394 for available APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17425) C++ 3.0: Basic C++ client
[ https://issues.apache.org/jira/browse/IGNITE-17425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627069#comment-17627069 ] Stanislav Lukyanov commented on IGNITE-17425: - This was merged under the ticket ID IGNITE-17424: [https://github.com/apache/ignite-3/commit/c685b099.|https://github.com/apache/ignite-3/commit/c685b099] > C++ 3.0: Basic C++ client > - > > Key: IGNITE-17425 > URL: https://issues.apache.org/jira/browse/IGNITE-17425 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > Implement basic C++ 3.0 client that can be used as a base to add new features. > What should be done: > * Set up project structure (CMake + consider Conan); > * Establish code style; > * Document project building; > * Target C++14?; > * Set up tests (consider GTest for testing); > * Implement networking (consider adopting some library, e.g. asio); > * Implement minimal set of operations: get table by name, upsert, get; -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17713) .NET: Thin 3.0: build fails sporadically
[
https://issues.apache.org/jira/browse/IGNITE-17713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-17713:
Labels: fix-version-validated ignite-3 (was: ignite-3)
> .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: fix-version-validated, ignite-3
> Fix For: 3.0.0-beta1
>
>
> {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-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15956: Labels: ignite-3 (was: IGNITE-17709 ignite-3) > 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 > Fix For: 3.0.0-beta1 > > > 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] [Updated] (IGNITE-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15956: Labels: fix-version-validated ignite-3 (was: ignite-3) > 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: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > 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] [Updated] (IGNITE-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15956: Labels: IGNITE-17709 ignite-3 (was: IGNITE-17709 fix-version-validated ignite-3) > 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-17709, ignite-3 > Fix For: 3.0.0-beta1 > > > 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] [Updated] (IGNITE-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15956: Labels: IGNITE-17709 fix-version-validated ignite-3 (was: fix-version-validated ignite-3) > 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-17709, fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > 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] [Updated] (IGNITE-17370) Support empty values of varlen types as default
[ https://issues.apache.org/jira/browse/IGNITE-17370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17370: Labels: fix-version-validated ignite-3 (was: ignite-3) > Support empty values of varlen types as default > > > Key: IGNITE-17370 > URL: https://issues.apache.org/jira/browse/IGNITE-17370 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > Currently, an empty string is stored in configuration instead of null value. > This leads to inability to determine the real value stored as default, hence > both null and empty string are desirialized as null. > Need to rework this in order to be able to configure and restore all sort of > values as defaults. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17164) Absorb RAFT/in-memory/rebalance details
[ https://issues.apache.org/jira/browse/IGNITE-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17164: Labels: fix-version-validated ignite-3 (was: ignite-3) > Absorb RAFT/in-memory/rebalance details > --- > > Key: IGNITE-17164 > URL: https://issues.apache.org/jira/browse/IGNITE-17164 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > There is a design described in IGNITE-16668. > To implement the required changes, it is required to read the RAFT paper, see > what problems it can cause for volatile cases and how the proposed design > solves the problems with the rebalance in volatile RAFT cases. -- 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 ] Stanislav Lukyanov updated IGNITE-17709: Labels: calcite2-required fix-version-validated ignite-3 (was: calcite2-required 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, fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 1h 10m > 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-15956) Packaging: RPM packages
[ https://issues.apache.org/jira/browse/IGNITE-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15956: Labels: fix-version-validated ignite-3 (was: ignite-3) > 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: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > 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] [Updated] (IGNITE-17523) Stabilize and cleanup ignite3_tx branch with rw logic implemented
[ https://issues.apache.org/jira/browse/IGNITE-17523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17523: Labels: fix-version-validated ignite-3 transaction3_rw (was: ignite-3 transaction3_rw) > Stabilize and cleanup ignite3_tx branch with rw logic implemented > - > > Key: IGNITE-17523 > URL: https://issues.apache.org/jira/browse/IGNITE-17523 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: fix-version-validated, ignite-3, transaction3_rw > Fix For: 3.0.0-beta1 > > Time Spent: 40m > Remaining Estimate: 0h > > It's required to cleanup all obsolete stuff > * TxManager > * VersionedRowStore > * todos without tickets > * etc > and stabilize failing tests. > h3. Upd 1 > Following major issues were implemented: > * TxStateStorage management updated. > * ItInternalTableScanTest fixed. > * Cleanup: begin, commit and forget were removed. > * Race between enlist and commit transaction fixed. > * ItIgniteInMemoryNodeRestartTest and ItNodeRestartsTest were disabled under > multiStorageSupport issue. > * Remove deprecated MVPartitoinStorage methods with old Timestamp. > * ReplicaManager handlers registration reworked. > * InsertAll operation was fixed. > * Transaction SQL Select was supported. > * Cleanup: VersionedRowStorage was removed. > * Cleanup: MVParitionStorage deprecated methods were removed. > * onBeforeApply was removed > * ItSqlLogicTest, TxAbstractTest, KeyValueBinaryViewOperationsTest and many > others updated in order to use replicas layer. > * dotNet timeouts updated. > * Dummy table actualized in order to use replicas layer. > * Async ReplicaService response processing added. > * TXNState storage ABORTED CAS fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15818) [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and re-implementation
[ https://issues.apache.org/jira/browse/IGNITE-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15818: Labels: fix-version-validated ignite-3 (was: ignite-3) > [Native Persistence 3.0] Checkpoint, lifecycle and file store refactoring and > re-implementation > --- > > Key: IGNITE-15818 > URL: https://issues.apache.org/jira/browse/IGNITE-15818 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: fix-version-validated, ignite-3 > Fix For: 3.0.0-beta1 > > > h2. Goal > Port and refactor core classes implementing page-based persistent store in > Ignite 2.x: GridCacheOffheapManager, GridCacheDatabaseSharedManager, > PageMemoryImpl, Checkpointer, FileWriteAheadLogManager. > New checkpoint implementation to avoid excessive logging. > Store lifecycle clarification to avoid complicated and invasive code of > custom lifecycle managed mostly by DatabaseSharedManager. > h2. Items to pay attention to > New checkpoint implementation based on split-file storage, new page index > structure to maintain disk-memory page mapping. > File page store implementation should be extracted from > GridCacheOffheapManager to a separate entity, target implementation should > support new version of checkpoint (split-file store to enable > always-consistent store and to eliminate binary recovery phase). > Support of big pages (256+ kB). > Support of throttling algorithms. > h2. References > New checkpoint design overview is available > [here|https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md] > h2. Thoughts > Although there is a technical opportunity to have independent checkpoints for > different data regions, managing them could be a nightmare and it's > definitely in the realm of optimizations and out of scope right now. > So, let's assume that there's one good old checkpoint process. There's still > a requirement to have checkpoint markers, but they will not have a reference > to WAL, because there's no WAL. Instead, we will have to store RAFT log > revision per partition. Or not, I'm not that familiar with a recovery > procedure that's currently in development. > Unlike checkpoints in Ignite 2.x, that had DO and REDO operations, new > version will have DO and UNDO. This drastically simplifies both checkpoint > itself and node recovery. But is complicates data access. > There will be two process that will share storage resource: "checkpointer" > and "compactor". Let's examine what compactor should or shouldn't do: > * it should not work in parallel with checkpointer, except for cases when > there are too many layers (more on that later) > * it should merge later checkpoint delta files into main partition files > * it should delete checkpoint markers once all merges are completed for it, > thus markers are decoupled from RAFT log > About "cases when there are too many layers" - too many layers could > compromise reading speed. Number of layers should not increase > uncontrollably. So, when a threshold is exceeded, compactor should start > working no mater what. If anything, writing load can be throttled, reading > matters more. > Recovery procedure: > * read the list of checkpoint markers on engines start > * remove all data from unfinished checkpoint, if it's there > * trim main partition files to their proper size (should check it it's > actually beneficial) > Table start procedure: > * read all layer files headers according to the list of checkpoints > * construct a list oh hash tables (pageId -> pageIndex) for all layers, make > it as effective as possible > * everything else is just like before > Partition removal might be tricky, but we'll see. It's tricky in Ignite 2.x > after all. "Restore partition states" procedure could be revisited, I don't > know how this will work yet. > How to store hashmaps: > regular maps might be too much, we should consider roaring map implementation > or something similar that'll occupy less space. This is only a concern for > in-memory structures. Files on disk may have a list of pairs, that's fine. > Generally speaking, checkpoints with a size of 100 thousand pages are close > to the top limit for most users. Splitting that to 500 partitions, for > example, gives us 200 pages per partition. Entire map should fit into a > single page. > The only exception to these calculations is index.bin. Amount of pages per > checkpoint can be an orders of magnitudes higher, so we should keep an eye on > it, It'll be the main target for testing/benchmarking. Anyway, 4 kilobytes is > enough to fit 512 integer pairs, scaling to 2048 for regular 16 kilobytes >
[jira] [Commented] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627064#comment-17627064 ] Stanislav Lukyanov commented on IGNITE-17588: - This isn't necessarily a blocker for the beta release. The C++ client will be usable after https://issues.apache.org/jira/browse/IGNITE-17590 is implemented. > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18009) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-18009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18009: Fix Version/s: 3.0.0-beta2 (was: 3.0.0-beta1) > Fix gradle build > > > Key: IGNITE-18009 > URL: https://issues.apache.org/jira/browse/IGNITE-18009 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18009) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-18009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626593#comment-17626593 ] Stanislav Lukyanov commented on IGNITE-18009: - It looks like this is not required in beta1 since the fix that caused this isn't in beta1. > Fix gradle build > > > Key: IGNITE-18009 > URL: https://issues.apache.org/jira/browse/IGNITE-18009 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17265) Support RAFT snapshot streaming for PageMemory storage
[ https://issues.apache.org/jira/browse/IGNITE-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626592#comment-17626592 ] Stanislav Lukyanov commented on IGNITE-17265: - I see that there is a pattern of setting "fixed by" links in Ignite Jira - let's do that. I've set the link, no more actions are required. > Support RAFT snapshot streaming for PageMemory storage > -- > > Key: IGNITE-17265 > URL: https://issues.apache.org/jira/browse/IGNITE-17265 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > IGNITE-17254 API needs to be implemented for PageMemory storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18025) wrong version reference in libs.toml for jackson-core
[ https://issues.apache.org/jira/browse/IGNITE-18025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18025: Fix Version/s: 3.0.0-beta1 > wrong version reference in libs.toml for jackson-core > - > > Key: IGNITE-18025 > URL: https://issues.apache.org/jira/browse/IGNITE-18025 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > jackson-core is referenced with wrong version that causes broken published > pom for sql-engine module -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-16760) Performance degradation of IgniteTables#tables after configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626580#comment-17626580
]
Stanislav Lukyanov commented on IGNITE-16760:
-
The change was committed with an incorrect Jira ID (IGNITE-16670):
[https://github.com/apache/ignite-3/commit/bb268f4c00b240edfa637d8b0a6e397d17472fc6]
Nothing we can do about this now.
> Performance degradation of IgniteTables#tables after configuration changes
> --
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> for (Table t : ign.tables().tables()) {
> ;
> }
> {code}
> On begin {{IgniteTables#tables}} takes ~ 0.7 sec.
> The time of the operation is grown.
> The time after ~100 iteration is about 20 sec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17265) Support RAFT snapshot streaming for PageMemory storage
[ https://issues.apache.org/jira/browse/IGNITE-17265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17626573#comment-17626573 ] Stanislav Lukyanov commented on IGNITE-17265: - [~rpuch] Should this be "Duplicate" instead of "Resolved"? > Support RAFT snapshot streaming for PageMemory storage > -- > > Key: IGNITE-17265 > URL: https://issues.apache.org/jira/browse/IGNITE-17265 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > IGNITE-17254 API needs to be implemented for PageMemory storage -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15780) ITDistributedConfigurationPropertiesTest#testFallingBehindDistributedStorageValue is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15780: Fix Version/s: (was: 3.0.0-beta1) > ITDistributedConfigurationPropertiesTest#testFallingBehindDistributedStorageValue > is flaky > -- > > Key: IGNITE-15780 > URL: https://issues.apache.org/jira/browse/IGNITE-15780 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Attachments: ITDistributedConfigurationPropertiesTest.log > > > Test fails locally after a few runs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17904) Fix flaky VolatilePageMemorySortedIndexStorageTest#testBoundsAndOrder
[ https://issues.apache.org/jira/browse/IGNITE-17904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17904: Fix Version/s: (was: 3.0.0-beta1) > Fix flaky VolatilePageMemorySortedIndexStorageTest#testBoundsAndOrder > - > > Key: IGNITE-17904 > URL: https://issues.apache.org/jira/browse/IGNITE-17904 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > https://ci.ignite.apache.org/viewLog.html?buildId=6831695=ignite3_Test_RunUnitTests=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17208) Change storage engine names based on PageMemory
[ https://issues.apache.org/jira/browse/IGNITE-17208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17208: Fix Version/s: (was: 3.0.0-beta1) > Change storage engine names based on PageMemory > --- > > Key: IGNITE-17208 > URL: https://issues.apache.org/jira/browse/IGNITE-17208 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > PageMemory based storage engine (*pagememory*) has been split into two > *aimem* (in-memory) and *aipersist* (persistent), these names don't seem > convenient and memorable like *rocksdb*, we need something similar for them. > What needs to be changed in the code: > * > *org.apache.ignite.internal.storage.pagememory.VolatilePageMemoryStorageEngine#ENGINE_NAME* > * > *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryStorageEngine#ENGINE_NAME* > * > *org.apache.ignite.configuration.schemas.table.TablesConfigurationSchema#defaultDataStorage* > * *org.apache.ignite.example.storage.PersistentPageMemoryStorageExample* > * *org.apache.ignite.example.storage.VolatilePageMemoryStorageExample* > * Fallen tests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17280) ItComputeTest.executesColocatedByClassNameWithTupleKey failed on TC
[ https://issues.apache.org/jira/browse/IGNITE-17280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17280: Fix Version/s: (was: 3.0.0-beta1) > ItComputeTest.executesColocatedByClassNameWithTupleKey failed on TC > --- > > Key: IGNITE-17280 > URL: https://issues.apache.org/jira/browse/IGNITE-17280 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Attachments: _Integration_Tests_Module_Runner_3992.log.zip > > > [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner/6655808] > > ava.lang.AssertionError > java.lang.AssertionError: Raft groups are still running > [b839ce7f-370c-4553-882e-34b471029c9c_part_0, > b839ce7f-370c-4553-882e-34b471029c9c_part_19, > b839ce7f-370c-4553-882e-34b471029c9c_part_8, > b839ce7f-370c-4553-882e-34b471029c9c_part_11, > b839ce7f-370c-4553-882e-34b471029c9c_part_4, > b839ce7f-370c-4553-882e-34b471029c9c_part_15, > b839ce7f-370c-4553-882e-34b471029c9c_part_13, > b839ce7f-370c-4553-882e-34b471029c9c_part_3, > b839ce7f-370c-4553-882e-34b471029c9c_part_14] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16939) ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-16939:
Fix Version/s: (was: 3.0.0-beta1)
> ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists
> is flaky
> --
>
> Key: IGNITE-16939
> URL: https://issues.apache.org/jira/browse/IGNITE-16939
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Reporter: Roman Puchkovskiy
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
>
> See
> [https://ci.ignite.apache.org/viewLog.html?buildId=6560290=ignite3_Test_RunUnitTests]
> {code:java}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: expected: but was:
> at
> org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68)
> {code}
> The branch is main with one commit which disables one test, so it's
> equivalent to main branch in everything that concerns the failed test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17551) Add the ability to work with the entire BinaryTuple ByteBuffer
[ https://issues.apache.org/jira/browse/IGNITE-17551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17551: Fix Version/s: (was: 3.0.0-beta1) > Add the ability to work with the entire BinaryTuple ByteBuffer > -- > > Key: IGNITE-17551 > URL: https://issues.apache.org/jira/browse/IGNITE-17551 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: iep-92, ignite-3 > > When implementing PageMemory based indexes, it was discovered that a > *BinaryTuple* does not have a method to get its *ByteBuffer* so that it can > be saved (eg to a file). > Also, we need to create a *BinaryTuple* after reading the *ByteBuffer* (eg > from a file). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17006) Add protection against arbitrary page memory links in LinkRowId
[ https://issues.apache.org/jira/browse/IGNITE-17006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17006: Fix Version/s: (was: 3.0.0-beta1) > Add protection against arbitrary page memory links in LinkRowId > --- > > Key: IGNITE-17006 > URL: https://issues.apache.org/jira/browse/IGNITE-17006 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > It's theoretically possible to pass an arbitrary page memory link (via > LinkRowId) which might cause troubles: > # If pageId exceeds page memory limit, the JVM might crash > # If the page with this pageId was never initialized, an attempt to read > will fail with an internal assertion (because lock state will be 0) > A possibility for item ID to be invalid is already handled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16642) [Native Persistence 3.0] Support indexes for B+Tree-based storage
[ https://issues.apache.org/jira/browse/IGNITE-16642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-16642: Fix Version/s: (was: 3.0.0-beta1) > [Native Persistence 3.0] Support indexes for B+Tree-based storage > - > > Key: IGNITE-16642 > URL: https://issues.apache.org/jira/browse/IGNITE-16642 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Need to support indexes for B+Tree-based storage . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-17199:
Fix Version/s: (was: 3.0.0-beta1)
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract
> configuration as with a regular configuration (as if
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
> when working with the abstract configuration itself, it creates
> inconvenience.
> For example, to get a view of the abstract configuration, we will need to
> write the following code:
> {code:java}
> BaseConfiguration baseConfig0 = ...;
> BaseConfiguration baseConfig1 = ...;
>
> BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
> BaseView baseView1 = baseConfig1.value();
> {code}
> Which is not convenient and I would like us to be able to work in the same
> way as with the *VolatileConfiguration*.
> *Possible implementations*
> * Simplest is to leave it as is;
> * Creates an additional configuration interface that will be similar to
> *BaseConfiguration*, for example *BaseConfigurationTree*, but it will be
> extended by *BaseConfiguration* and all its inheritors like
> *VolatileConfiguration*, then there may be confusion about whether to use
> *BaseConfiguration* or *BaseConfigurationTree* in the end, so we need to
> decide how to create a name for such an interface;
> ** *BaseConfigurationTree*;
> ** *AbstractBaseConfigurationTree*;
> ** other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17980) ./gradlew clean build -x test fails
[ https://issues.apache.org/jira/browse/IGNITE-17980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17980: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > ./gradlew clean build -x test fails > --- > > Key: IGNITE-17980 > URL: https://issues.apache.org/jira/browse/IGNITE-17980 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > On the latest main branch, the following fails: ./gradlew clean build -x test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18009) Fix gradle build
[ https://issues.apache.org/jira/browse/IGNITE-18009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-18009: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > Fix gradle build > > > Key: IGNITE-18009 > URL: https://issues.apache.org/jira/browse/IGNITE-18009 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17965) Enable remote build cache for Gradle
[ https://issues.apache.org/jira/browse/IGNITE-17965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17965: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > Enable remote build cache for Gradle > > > Key: IGNITE-17965 > URL: https://issues.apache.org/jira/browse/IGNITE-17965 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to enable remote build cache feature for Gradle on CI. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17966) Fix problem with stuck Gradle processes in .NET tests
[ https://issues.apache.org/jira/browse/IGNITE-17966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17966: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > Fix problem with stuck Gradle processes in .NET tests > - > > Key: IGNITE-17966 > URL: https://issues.apache.org/jira/browse/IGNITE-17966 > Project: Ignite > Issue Type: Bug > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, when .NET test suite finished some Gradle processes will alive and > after that CI agents start be in inconsistance state. The main problem is > using ports and next build will be failed because of unreachable port. So, > need to fix this problem and kill all processes which producing in build > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18005) ItDataTypesTest#testUnicodeStrings fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/IGNITE-18005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-18005:
Fix Version/s: 3.0.0-beta1
> ItDataTypesTest#testUnicodeStrings fails with IndexOutOfBoundsException
> ---
>
> Key: IGNITE-18005
> URL: https://issues.apache.org/jira/browse/IGNITE-18005
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 3.0.0-beta1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> Caused by: java.lang.IndexOutOfBoundsException: 4
> at java.base/java.nio.HeapByteBuffer.get(HeapByteBuffer.java:166)
> at org.apache.ignite.internal.schema.row.Row.findColumn(Row.java:516)
> at org.apache.ignite.internal.schema.row.Row.stringValue(Row.java:288)
> at
> org.apache.ignite.internal.schema.NativeTypeSpec$9.objectValue(NativeTypeSpec.java:134)
> at org.apache.ignite.internal.schema.row.Row.value(Row.java:122)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.toRow(IgniteTableImpl.java:284)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode.convert(TableScanNode.java:279)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode$SubscriberImpl.onNext(TableScanNode.java:246)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.TableScanNode$SubscriberImpl.onNext(TableScanNode.java:233)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl$PartitionScanPublisher$PartitionScanSubscription.lambda$scanBatch$2(InternalTableImpl.java:1182)
> at
> java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
> ... 11 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode
[
https://issues.apache.org/jira/browse/IGNITE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17623113#comment-17623113
]
Stanislav Lukyanov commented on IGNITE-17813:
-
Also, I kinda think this is not a blocker for beta. The case that doesn't work
is pretty straightforward (ORDER BY breaks if it sorts using a sorted index),
so it's easy to just call it out in release notes. Also, I suspect there is a
WA - just add a wrapping the original query with another one, like
{code:java}
select * from ( select * from T order by indexed_col ) order by indexed_col
{code}
So if you really need to get this query to run correctly (although slowly), you
can.
[~xtern] thoughts?
> Sql. Introduce sorted reducer for IndexScanNode
> ---
>
> Key: IGNITE-17813
> URL: https://issues.apache.org/jira/browse/IGNITE-17813
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This task is derived from IGNITE-17655 to reduce its scope.
> Currently, IgniteScanNode reads partition after partition which, obviously,
> breaks the sorting order. We need to introduce wrapping cursor, which accepts
> open cursors for every partition, and produce the sorted output.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17773) Remove node start/stop/list commands
[ https://issues.apache.org/jira/browse/IGNITE-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622886#comment-17622886 ] Stanislav Lukyanov commented on IGNITE-17773: - Sure, that's what I meant - since this is already in the main, we should include it. > Remove node start/stop/list commands > > > Key: IGNITE-17773 > URL: https://issues.apache.org/jira/browse/IGNITE-17773 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 20m > Remaining Estimate: 0h > > Now, ignite3 node start/stop/restart managements are done through a special > script that is provided by the distribution. CLI commands: node start, node > stop, node list, and bootstrap now do not make any sense. We have to remove > them because they do not work if a user has started a node with a startup > script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode
[ https://issues.apache.org/jira/browse/IGNITE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622642#comment-17622642 ] Stanislav Lukyanov commented on IGNITE-17813: - [~xtern] do you have an ETA for when it'll be ready for review? > Sql. Introduce sorted reducer for IndexScanNode > --- > > Key: IGNITE-17813 > URL: https://issues.apache.org/jira/browse/IGNITE-17813 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > This task is derived from IGNITE-17655 to reduce its scope. > Currently, IgniteScanNode reads partition after partition which, obviously, > breaks the sorting order. We need to introduce wrapping cursor, which accepts > open cursors for every partition, and produce the sorted output. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17590) C++ 3.0: Implement RecordBinaryView
[ https://issues.apache.org/jira/browse/IGNITE-17590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622640#comment-17622640 ] Stanislav Lukyanov commented on IGNITE-17590: - [~isapego] do you have an ETA for when it'll be ready for review? > C++ 3.0: Implement RecordBinaryView > --- > > Key: IGNITE-17590 > URL: https://issues.apache.org/jira/browse/IGNITE-17590 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > Implement record_binary_view with mapping to ignite_tuple: > * client_table::record_binary_view should return record_binary_view; > * Design and implement ignite_tuple. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17859) Update indexes on data modifications
[
https://issues.apache.org/jira/browse/IGNITE-17859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622641#comment-17622641
]
Stanislav Lukyanov commented on IGNITE-17859:
-
[~korlov] do you have an ETA for when it'll be ready for review?
> Update indexes on data modifications
>
>
> Key: IGNITE-17859
> URL: https://issues.apache.org/jira/browse/IGNITE-17859
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h3. Motivation
> For the sake of better performance and common sense, it is necessary to
> integrate indexes into data manipulation flow, which implies
> * Integrating indexes into the process of efficient evaluation keys to
> rowsIds both within pure read/scan operations and as part of modification
> operations in order to find proper rowId of a row to be modified.
> * Integrating indexes into the process of data modification itself, meaning
> that not only data should be updated but also all corresponding indexes
> should be populated with updated entries along with cleanup on transaction
> rollback.
> Given Jira issue is about second part.
> *Definition* *of Done*
> * All indexes with relevant schema version are populated with modified rows.
> * All pending index entries are removed on tx rollback.
> h3. Implementation Notes
> # Seems, that it has sense to introduce new Index abstractions that will
> manage update logic internally. Something like following:
> ** Index
> ** HashIndex extends Index
> ** HashUniqueIndex extends HashIndex
> ** SortedIndex extneds Index
> ** SorteUniquedIndex extneds SortedIndex
> # In order to define which indexes to update both during update itself or
> during rollback it'll be useful to add extra parameter _schemaVersion_ to
> each operation enlisted into transaction. All in all, that will allow to
> select only proper set of indexes with relevant schema versions.
> # During transaction rollback it'll be necessary to cleanup outdated
> pending entries that were touched during tx lifetime.
> h4. More details about *first* item.
> Index itself may declare update() and other methods that will have
> index-type-specific lock management and uniqueness processing logic, e.g. for
> HashIndex.update following is suggested:
> {code:java}
> @Override
> public CompletableFuture update(UUID txId, TxState txState, Tuple oldRow,
> Tuple newRow, VersionChain rowId) {
> Tuple oldVal = oldRow == Tuple.TOMBSTONE ? Tuple.TOMBSTONE :
> oldRow.select(col);
> Tuple newVal = newRow == Tuple.TOMBSTONE ? Tuple.TOMBSTONE :
> newRow.select(col);
> List futs = new ArrayList<>();
> if (!oldVal.equals(newVal)) {
> if (oldVal.length() > 0) {
> Lock lock0 = lockTable.getOrAddEntry(oldVal);
> txState.addLock(lock0);
> futs.add(lock0.acquire(txId, LockMode.IX));
> // Do not remove bookmarks due to multi-versioning.
> }
> if (newVal.length() > 0) {
> Lock lock0 = lockTable.getOrAddEntry(newVal);
> txState.addLock(lock0);
> futs.add(lock0.acquire(txId, LockMode.IX).thenAccept(ignored0 -> {
> if (index.insert(newVal, rowId)) {
> txState.addUndo(() -> index.remove(newVal, rowId));
> }
> }));
> }
> }
> return CompletableFuture.allOf(futs.toArray(new CompletableFuture[0]));
> } {code}
> Further details could be found in
> [https://github.com/ascherbakoff/ai3-txn-mvp]
> Detailed lock management design is described in [IEP-91-Locking
> model|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Lockingmodel]
> See index related sections, e.g. for HashIndex following lock flow is
> suggested:
> {code:java}
> Non-unique locks
> // scan
> S_commit(key)
> // insert
> IX_commit(key)
> // delete
> IX_commit(key) {code}
> h4. More details about *third* item.
> Please see cleanup flow described in
> https://issues.apache.org/jira/browse/IGNITE-17673
>
> It might have sense to consider all three items as separate tickets.
> It also worth to mention that index modification is triggered from
> PartitionListener
> * handleUpdateCommand
> * handleUpdateAllCommand
> * handleTxCleanupCommand
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans
[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622638#comment-17622638
]
Stanislav Lukyanov edited comment on IGNITE-17748 at 10/22/22 2:46 PM:
---
[~amashenkov] do you have an ETA for when it'll be ready for review?
was (Author: slukyanov):
[~amashenkov] do you have an ETA for this?
> Enrich InternalTable.scan API in order to support index scans
> -
>
> Key: IGNITE-17748
> URL: https://issues.apache.org/jira/browse/IGNITE-17748
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h3. Motivation
> SQL engine might specify index to use for scanning data along with some
> additional parameters like lower/upper bounds, including/excluding such
> bounds, columns to include etc. All in all we should enrich InternalTable
> scan api and provide corresponding data propagation logic.
> h3. Definition of Done
> *1.* InternalTable scan API has following method for both hash and sorted
> indexes scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code}
> and following method for sorted index scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, @Nullable BinaryTuple leftBound, @Nullable BinaryTuple
> rightBound, int flags, BitSet columnsToInclude) {code}
> Please check org.apache.ignite.internal.storage.index.SortedIndexStorage#scan
> for flags explanation, briefly
> {code:java}
> flags Control flags. {@link #GREATER} | {@link #LESS} by default. Other
> available values are {@link #GREATER_OR_EQUAL}, {@link #LESS_OR_EQUAL}.{code}
> *2.* Besides API itself corresponding scan-meta should be propagated to
> PartitionReplicaListener, so that some changes are also expected within
> ScanRetrieveBatchReplicaRequest. Please, pay attention that, that there's,
> probably, no sense in propagation same scan-meta within every
> ScanRetrieveBatchReplicaRequest, we might do it only wihtin initial request.
> *3.* Proper index is chosen. See optional indexId param and proper method of
> either IndexStorage or specific SortedIndexStorage is used.
> h3. Implementation Notes
> Mainly it's all specified in the section above. Seems that there's only one
> caveat left, however, non trivial one - BinaryRow to Binary tuple convertion,
> schema involved.
> h3. UPD:
> As was discussed, indexId will be always specified so that tables internals
> will never select PK-index or any other by themselves, so that @Nullable UUID
> indexId is now @NotNull UUID indexId.
>
> Besides API extension itself, it's required to build a bridge between
> https://issues.apache.org/jira/browse/IGNITE-17655 and internalTable.scan
> API, meaaning that it's required to create implementations for sql index
> interfaces introduced in 17655 that will propagate index scans to
> corresponding internalTable.scan API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622639#comment-17622639 ] Stanislav Lukyanov commented on IGNITE-17588: - [~isapego] do you have an ETA for when it'll be ready for review? > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17748) Enrich InternalTable.scan API in order to support index scans
[
https://issues.apache.org/jira/browse/IGNITE-17748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622638#comment-17622638
]
Stanislav Lukyanov commented on IGNITE-17748:
-
[~amashenkov] do you have an ETA for this?
> Enrich InternalTable.scan API in order to support index scans
> -
>
> Key: IGNITE-17748
> URL: https://issues.apache.org/jira/browse/IGNITE-17748
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h3. Motivation
> SQL engine might specify index to use for scanning data along with some
> additional parameters like lower/upper bounds, including/excluding such
> bounds, columns to include etc. All in all we should enrich InternalTable
> scan api and provide corresponding data propagation logic.
> h3. Definition of Done
> *1.* InternalTable scan API has following method for both hash and sorted
> indexes scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, BinaryTuple key, BitSet columnsToInclude){code}
> and following method for sorted index scanning
> {code:java}
> Publisher scan(int partId, @Nullable InternalTransaction tx,
> @NotNull UUID indexId, @Nullable BinaryTuple leftBound, @Nullable BinaryTuple
> rightBound, int flags, BitSet columnsToInclude) {code}
> Please check org.apache.ignite.internal.storage.index.SortedIndexStorage#scan
> for flags explanation, briefly
> {code:java}
> flags Control flags. {@link #GREATER} | {@link #LESS} by default. Other
> available values are {@link #GREATER_OR_EQUAL}, {@link #LESS_OR_EQUAL}.{code}
> *2.* Besides API itself corresponding scan-meta should be propagated to
> PartitionReplicaListener, so that some changes are also expected within
> ScanRetrieveBatchReplicaRequest. Please, pay attention that, that there's,
> probably, no sense in propagation same scan-meta within every
> ScanRetrieveBatchReplicaRequest, we might do it only wihtin initial request.
> *3.* Proper index is chosen. See optional indexId param and proper method of
> either IndexStorage or specific SortedIndexStorage is used.
> h3. Implementation Notes
> Mainly it's all specified in the section above. Seems that there's only one
> caveat left, however, non trivial one - BinaryRow to Binary tuple convertion,
> schema involved.
> h3. UPD:
> As was discussed, indexId will be always specified so that tables internals
> will never select PK-index or any other by themselves, so that @Nullable UUID
> indexId is now @NotNull UUID indexId.
>
> Besides API extension itself, it's required to build a bridge between
> https://issues.apache.org/jira/browse/IGNITE-17655 and internalTable.scan
> API, meaaning that it's required to create implementations for sql index
> interfaces introduced in 17655 that will propagate index scans to
> corresponding internalTable.scan API.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17773) Remove node start/stop/list commands
[ https://issues.apache.org/jira/browse/IGNITE-17773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622635#comment-17622635 ] Stanislav Lukyanov commented on IGNITE-17773: - To be clear - I don't think this is a blocker for beta1. That said, it does make the user interface cleaner, and we have other stuff we're waiting for, so we can include this one as well. If for any reason this takes more than a couple of days to merge, it will have a high chance to be descoped. > Remove node start/stop/list commands > > > Key: IGNITE-17773 > URL: https://issues.apache.org/jira/browse/IGNITE-17773 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > Now, ignite3 node start/stop/restart managements are done through a special > script that is provided by the distribution. CLI commands: node start, node > stop, node list, and bootstrap now do not make any sense. We have to remove > them because they do not work if a user has started a node with a startup > script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients
[
https://issues.apache.org/jira/browse/IGNITE-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-17953:
Fix Version/s: (was: 3.0.0-beta1)
> NPE and closed connection on some malformed SQL requests using third-party
> SQL clients
> --
>
> Key: IGNITE-17953
> URL: https://issues.apache.org/jira/browse/IGNITE-17953
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>
> I try to run different SQL queries in AI3 using
> [SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client
> JAR downloaded from CI. I tried both correct and some incorrect SQL queries.
> And it looks like some incorrect SQL queries lead to irrecoverable error on
> the client side. The stack trace is the following:
> {code:java}
> Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.lang.NullPointerException
> at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
> at
> org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
> at
> org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.io.IOException: Connection reset by peer
> at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>
[jira] [Commented] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients
[
https://issues.apache.org/jira/browse/IGNITE-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17622633#comment-17622633
]
Stanislav Lukyanov commented on IGNITE-17953:
-
Thanks for reporting this!
I agree that this is a bug, but it doesn't look like a blocker for beta1. I'm
sure once you go deeper, at this stage you'll find many little things that
break UX on non-happy path scenarios.
In general, please let me or [~sk0x50] know if you'd like to include issues in
the beta1 scope.
[~akhitrin] [~sk0x50] I'm removing the fixVersion for now - let me know if you
have any concerns.
> NPE and closed connection on some malformed SQL requests using third-party
> SQL clients
> --
>
> Key: IGNITE-17953
> URL: https://issues.apache.org/jira/browse/IGNITE-17953
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Fix For: 3.0.0-beta1
>
>
> I try to run different SQL queries in AI3 using
> [SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client
> JAR downloaded from CI. I tried both correct and some incorrect SQL queries.
> And it looks like some incorrect SQL queries lead to irrecoverable error on
> the client side. The stack trace is the following:
> {code:java}
> Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.lang.NullPointerException
> at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
> at
> org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
> at
> org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail
[jira] [Updated] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients
[
https://issues.apache.org/jira/browse/IGNITE-17953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-17953:
Affects Version/s: 3.0.0-beta1
> NPE and closed connection on some malformed SQL requests using third-party
> SQL clients
> --
>
> Key: IGNITE-17953
> URL: https://issues.apache.org/jira/browse/IGNITE-17953
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Fix For: 3.0.0-beta1
>
>
> I try to run different SQL queries in AI3 using
> [SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client
> JAR downloaded from CI. I tried both correct and some incorrect SQL queries.
> And it looks like some incorrect SQL queries lead to irrecoverable error on
> the client side. The stack trace is the following:
> {code:java}
> Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.lang.NullPointerException
> at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
> at
> org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
> at
> org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline
> onUnhandledInboundException
> WARNING: An exceptionCaught() event was fired, and it reached at the tail of
> the pipeline. It usually means the last handler in the pipeline did not
> handle the exception.
> java.io.IOException: Connection reset by peer
> at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
> at
[jira] [Commented] (IGNITE-14316) Binary object API for arbitrary user objects.
[ https://issues.apache.org/jira/browse/IGNITE-14316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612616#comment-17612616 ] Stanislav Lukyanov commented on IGNITE-14316: - The only purpose of this in AI 3 architecture is the client-side serialization of complex (multi-level) objects into a flat structure. Essentially, the user needs an easy way to insert a nested object. The object will necessarily be rendered to a `byte[]`, and AI won't really have any introspection into it. It seems like something Ignite should have as little to do with as possible. # The format and the serializer should be some industry standard, available in virtually any language. Avro immediately comes to mind. # Mapping complex user objects to a simpler format DB understands is the definition of what ORM does. ## When I care about the schema, it's natural to use an actual ORM. Need to investigate what's the latest and greatest in ORMs in terms of serialization support. ## When all I want is to do a simple schemaless put with complex objects like `put(new Key(a, b, c), new Val(new NestedVal(d, e), f))`, I probably don't want an ORM. In this case, the user code has to specify a way to serialize the objects. I guess there might be a default one (Avro? Java serialization?) but it feels like a slippery road. > Binary object API for arbitrary user objects. > - > > Key: IGNITE-14316 > URL: https://issues.apache.org/jira/browse/IGNITE-14316 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Original Estimate: 240h > Remaining Estimate: 240h > > Let's create BinaryObject (BO) interface and a builder interface for it > assuming > - BO is a self-described object. Similar to Ignite-2 one with a compact > footer. > - BO is unmanaged. SchemaManager doesn't care about its schema at all. > - BO can be deserialized to user class with a specified deserializer. > - BO has a flat structure, cyclic links are not allowed. However, one can > restore links on reserialization. > - BO must not have any dependencies on Ignite internals. > - Ignite should provide some base implementation for BO and builder. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-14326) Resetting Ignite cache entry TTL
[
https://issues.apache.org/jira/browse/IGNITE-14326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17573030#comment-17573030
]
Stanislav Lukyanov commented on IGNITE-14326:
-
[~kukushal] I think you'll get exactly the behavior you need if you use an
`EntryProcessor` that changes nothing and returns nothing. The value will be
touched, the new TTL will be set based on the `ExpiryPolicy`, nothing will be
touched, and no value will be returned.
If this WA has any unfortunate side effects (e.g. fetching a value onto the
heap), it's better to remove the side effects than introduce a new API (e.g.
make the `EntryProcessor` fetch value onto the heap lazily).
> Resetting Ignite cache entry TTL
>
>
> Key: IGNITE-14326
> URL: https://issues.apache.org/jira/browse/IGNITE-14326
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Stephen Darlington
>Priority: Major
> Labels: cggg
> Original Estimate: 64h
> Remaining Estimate: 64h
>
> Ignite provides a way to specify an expiry policy on per entry level, but
> there is no way to refresh the TTL without first retrieving the record, which
> is slow and resource consuming if an entry is large.
> Provide a method to reset Ignite cache entry TTL.
> Suggested API (to be discussed with community):
> {{IgniteCache#touch(key)}}: resets the TTL using the latest TTL value or does
> nothing if no TTL was specified for the key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16922) Getting an entry with expiry policy causes IgniteOutOfMemoryException
[
https://issues.apache.org/jira/browse/IGNITE-16922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17568611#comment-17568611
]
Stanislav Lukyanov commented on IGNITE-16922:
-
[~kukushal] Could you please check if setting a large enough empty pages pool
is a WA?
[https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/DataRegionConfiguration.html#setEmptyPagesPoolSize-int-]
> Getting an entry with expiry policy causes IgniteOutOfMemoryException
> -
>
> Key: IGNITE-16922
> URL: https://issues.apache.org/jira/browse/IGNITE-16922
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Alexey Kukushkin
>Priority: Major
> Labels: cggg
> Original Estimate: 64h
> Remaining Estimate: 64h
>
> {{IgniteCache#get(key)}} operation causes {{IgniteOutOfMemoryException}} if
> {{AccessedExpiryPolicy}} or {{TouchedExpiryPolicy}} is enabled for the
> {{key}} and Ignite has not enough storage for another entry of the same or
> bigger size.
> This happens because:
> # Ignite needs to update TTL
> # TTL is part of the entry and Ignite overwrites full entry to update the TTL
> # The problem is Ignite runs common code that checks if Ignite has enough
> storage to write the entry with updated TTL back. The check fails causing the
> {{IgniteCache#get(key)}} operation to throw {{IgniteOutOfMemoryException}}.
> # This behavior is very confusing for Ignite users: why would a "read"
> operation throw Ignite OOM?
> Can we update the TTL atomically and skip the storage size check?
> Please enhance Ignite not to throw Ignite OOM on {{get}}.
> Stack trace:
> {code:java}
> [2022-05-20
> 15:08:20,025][ERROR][sys-stripe-6-#8%ignite.IgniteOOMOnGet0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.i.mem.IgniteOutOfMemoryException: Out
> of memory in data region [name=default, initSize=18.1 MiB, maxSize=18.1 MiB,
> persistenceEnabled=false] Try the following:
> ^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
> ^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> ^-- Enable eviction or expiration policies]]
> class org.apache.ignite.internal.mem.IgniteOutOfMemoryException: Out of
> memory in data region [name=default, initSize=18.1 MiB, maxSize=18.1 MiB,
> persistenceEnabled=false] Try the following:
> ^-- Increase maximum off-heap memory size (DataRegionConfiguration.maxSize)
> ^-- Enable Ignite persistence (DataRegionConfiguration.persistenceEnabled)
> ^-- Enable eviction or expiration policies
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.ensureFreeSpaceForInsert(IgniteCacheDatabaseSharedManager.java:1234)
> at
> org.apache.ignite.internal.processors.cache.persistence.RowStore.addRow(RowStore.java:108)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.createRow(IgniteCacheOffheapManagerImpl.java:1962)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5767)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$UpdateClosure.call(GridCacheMapEntry.java:5695)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:4131)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2121)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1997)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1860)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1843)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:471)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4164)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:4140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:2961)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:2934)
[jira] [Comment Edited] (IGNITE-17032) Apache Ignite Docker container does not run correctly if image is run in read only file system mode
[
https://issues.apache.org/jira/browse/IGNITE-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563063#comment-17563063
]
Stanislav Lukyanov edited comment on IGNITE-17032 at 7/6/22 8:57 AM:
-
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
{code}
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
{code}
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
{code}
docker run --tmpfs /tmp ...
{code}
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
was (Author: slukyanov):
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
```
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
```
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
```
docker run --tmpfs /tmp ...
```
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
> Apache Ignite Docker container does not run correctly if image is run in read
> only file system mode
> ---
>
> Key: IGNITE-17032
> URL: https://issues.apache.org/jira/browse/IGNITE-17032
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.13
>Reporter: Petar Tonkovic
>Priority: Major
>
> When following the Kubernetes deployment tutorials (online:
> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment,
> youtube: [https://youtu.be/38YgdAOs038]), trying to run the official docker
> image () with the --read-only flag is causing errors:
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 52: cannot create
> temp file for here-document: Read-only file system
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 85: [: -lt: unary
> operator expected2022-05-25T14:27:34.504369604+02:00
>
[jira] [Comment Edited] (IGNITE-17032) Apache Ignite Docker container does not run correctly if image is run in read only file system mode
[
https://issues.apache.org/jira/browse/IGNITE-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563063#comment-17563063
]
Stanislav Lukyanov edited comment on IGNITE-17032 at 7/6/22 8:56 AM:
-
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
```
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
```
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
```
docker run --tmpfs /tmp ...
```
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
was (Author: slukyanov):
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
```
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
```
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
```
docker run --tmpfs /tmp ...
```
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
> Apache Ignite Docker container does not run correctly if image is run in read
> only file system mode
> ---
>
> Key: IGNITE-17032
> URL: https://issues.apache.org/jira/browse/IGNITE-17032
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.13
>Reporter: Petar Tonkovic
>Priority: Major
>
> When following the Kubernetes deployment tutorials (online:
> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment,
> youtube: [https://youtu.be/38YgdAOs038]), trying to run the official docker
> image () with the --read-only flag is causing errors:
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 52: cannot create
> temp file for here-document: Read-only file system
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 85: [: -lt: unary
> operator expected2022-05-25T14:27:34.504369604+02:00
>
> Since most
[jira] [Commented] (IGNITE-17032) Apache Ignite Docker container does not run correctly if image is run in read only file system mode
[
https://issues.apache.org/jira/browse/IGNITE-17032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17563063#comment-17563063
]
Stanislav Lukyanov commented on IGNITE-17032:
-
Thanks for reporting [~tonkovic].
TLDR: this is fixable, and I think there is a workaround - see it at the end of
the comment.
My first read of this was - well, Ignite should normally be used with a
writable disk, so "Not an issue".
BUT reading the second time I realized that the problem is that we're trying to
write into the *root* volume. We shouldn't do that.
Apparently, the thing that doesn't work is the following line
```
version=$(awk -F[\"\.] '{print $2}' <<< ${version})
```
In particular, the `<<<` is at fault.
Turns out, in Bash the `<<<` ("here-string") is implemented via `<<`
("here-document") which is in turn implemented via temp files. The root file
system is read-only, hence `/tmp` is also read-only, hence `<<` and `<<<` can't
work. You learn something new everyday, don't you?
[This](https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash)
explains it.
I'm quite surprised that basic Bash syntax can be unfriendly to cloud but here
we are.
Two things we should do (each of them will suffice, but I'd do both):
1. Get rid of the `<<<` and `<<` in the scripts, just in case.
2. Mount `/tmp` as tmpfs. It should always be tmpfs in all environments, for
many good reasons. I'm a bit surprised it's not tmpfs now, and I'd certainly
change that. The question is whether we can and should do this right in the
Dockerfile, or ask everyone to mount `/tmp` as tmpfs when running. The latter
requires at least docs changes.
As a workaround, I think running the container with an [explicit tmpfs
mount](https://stackoverflow.com/questions/34698620/docker-and-volatile-volumes-ala-tmp)
will do the trick:
```
docker run --tmpfs /tmp ...
```
Disclaimer: I haven't got my hands dirty yet, so all of the above needs to be
confirmed with tests.
> Apache Ignite Docker container does not run correctly if image is run in read
> only file system mode
> ---
>
> Key: IGNITE-17032
> URL: https://issues.apache.org/jira/browse/IGNITE-17032
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.13
>Reporter: Petar Tonkovic
>Priority: Major
>
> When following the Kubernetes deployment tutorials (online:
> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment,
> youtube: [https://youtu.be/38YgdAOs038]), trying to run the official docker
> image () with the --read-only flag is causing errors:
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 52: cannot create
> temp file for here-document: Read-only file system
> /opt/ignite/apache-ignite/bin/include/functions.sh: line 85: [: -lt: unary
> operator expected2022-05-25T14:27:34.504369604+02:00
>
> Since most managed company Kubernetes clusters enforce this read-only flag as
> a security requirement, it would be good to look into these errors.
>
> Later on, we get the following error on starting up:
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML
> application context (make sure all classes used in Spring configuration are
> present at CLASSPATH) [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1135)
> at org.apache.ignite.Ignition.start(Ignition.java:356)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> instantiate Spring XML application context (make sure all classes used in
> Spring configuration are present at CLASSPATH)
> [springUrl=file:/ignite/config/node-configuration.xml]
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:364)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:102)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:96)
> at
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:729)2022-05-25T14:27:34.916588365+02:00
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:930)
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:839)2022-05-25T14:27:34.916609431+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:709)2022-05-25T14:27:34.916622089+02:00
> at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)2022-05-25T14:27:34.916636146+02:00
> at
>
[jira] [Updated] (IGNITE-9524) Ignite Spring Session Integration
[ https://issues.apache.org/jira/browse/IGNITE-9524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-9524: --- Description: Spring Session Integration was released [https://lists.apache.org/thread/dy8w65jjqw8ygkvsbwd8lldzgsbpmomt.] Need docs for it. was: Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs [https://github.com/antkr/spring-session-ignite] and [https://github.com/antkr/spring-session-ignite-rest] - to be merged to Ignite [https://apacheignite-mix.readme.io/docs] under "Spring" section with a reference from "web session clustering" section. Ignite web site needs to be updated as well - [https://ignite.apache.org/use-cases/caching/web-session-clustering.html] > Ignite Spring Session Integration > - > > Key: IGNITE-9524 > URL: https://issues.apache.org/jira/browse/IGNITE-9524 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Prachi Garg >Assignee: Prachi Garg >Priority: Major > > Spring Session Integration was released > [https://lists.apache.org/thread/dy8w65jjqw8ygkvsbwd8lldzgsbpmomt.] > Need docs for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16952) Java public API for SQL queries
[ https://issues.apache.org/jira/browse/IGNITE-16952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-16952: Component/s: sql thin client > Java public API for SQL queries > --- > > Key: IGNITE-16952 > URL: https://issues.apache.org/jira/browse/IGNITE-16952 > Project: Ignite > Issue Type: Epic > Components: sql, thin client >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Ignite 3.0 should provide convinient pubic API to execute SQL. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16832) Expose the number of lost partitions as a metric
[ https://issues.apache.org/jira/browse/IGNITE-16832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-16832: Summary: Expose the number of lost partitions as a metric (was: Expose the number of lost partitions as a metricc) > Expose the number of lost partitions as a metric > > > Key: IGNITE-16832 > URL: https://issues.apache.org/jira/browse/IGNITE-16832 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > It would be useful to have a number of lost partitions of a cache as a > metric. That way monitoring tools can be set up to fire an alert when there > are lost partitions. > For the record, there is a metric MinimumNumberOfPartitionCopies which kinda > helps with that but 1) no one will ever look for it to monitor lost > partitions 2) number of lost partition would be useful (and this metric only > shows the fact that there are some lost partitions) 3) this metric doesn't > seem to work on inactive cluster, topology changes, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16832) Expose the number of lost partitions as a metricc
Stanislav Lukyanov created IGNITE-16832: --- Summary: Expose the number of lost partitions as a metricc Key: IGNITE-16832 URL: https://issues.apache.org/jira/browse/IGNITE-16832 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov It would be useful to have a number of lost partitions of a cache as a metric. That way monitoring tools can be set up to fire an alert when there are lost partitions. For the record, there is a metric MinimumNumberOfPartitionCopies which kinda helps with that but 1) no one will ever look for it to monitor lost partitions 2) number of lost partition would be useful (and this metric only shows the fact that there are some lost partitions) 3) this metric doesn't seem to work on inactive cluster, topology changes, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16821) Print collection attributes of the CacheConfiguration
Stanislav Lukyanov created IGNITE-16821: --- Summary: Print collection attributes of the CacheConfiguration Key: IGNITE-16821 URL: https://issues.apache.org/jira/browse/IGNITE-16821 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov CacheConfiguration.toString() currently doesn't print its array and collection attributes such as query entities or plugin configuration. It would be useful to have all these properties in toString for debug purposes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16821) Print collection attributes of the CacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-16821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov reassigned IGNITE-16821: --- Assignee: Stanislav Lukyanov > Print collection attributes of the CacheConfiguration > - > > Key: IGNITE-16821 > URL: https://issues.apache.org/jira/browse/IGNITE-16821 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Trivial > > CacheConfiguration.toString() currently doesn't print its array and > collection attributes such as query entities or plugin configuration. > > It would be useful to have all these properties in toString for debug > purposes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16659) Docs for Colocation in 3.0
Stanislav Lukyanov created IGNITE-16659: --- Summary: Docs for Colocation in 3.0 Key: IGNITE-16659 URL: https://issues.apache.org/jira/browse/IGNITE-16659 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov Need to document how colocation works in 3.0. See other issues in the epic for details. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425013#comment-17425013 ] Stanislav Lukyanov commented on IGNITE-15688: - None of the blockers could've been caused by this patch. > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424909#comment-17424909 ] Stanislav Lukyanov commented on IGNITE-15688: - [~isapego] could you please review? > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15688: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov reassigned IGNITE-15688: --- Assignee: Stanislav Lukyanov > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15688: Description: IgniteClient interface currently doesn't override close() from AutoClosable. Because of that, it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. was: IgniteClient interfaecs currently doesn't override close() from AutoClosable. Because of that it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Priority: Major > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
Stanislav Lukyanov created IGNITE-15688: --- Summary: IgniteClient.close shouldn't throw Exception Key: IGNITE-15688 URL: https://issues.apache.org/jira/browse/IGNITE-15688 Project: Ignite Issue Type: Bug Components: thin client Reporter: Stanislav Lukyanov IgniteClient interfaecs currently doesn't override close() from AutoClosable. Because of that it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15653) Automatic resetLostPartitions()
Stanislav Lukyanov created IGNITE-15653:
---
Summary: Automatic resetLostPartitions()
Key: IGNITE-15653
URL: https://issues.apache.org/jira/browse/IGNITE-15653
Project: Ignite
Issue Type: Bug
Reporter: Stanislav Lukyanov
h1. Motivation
Requests to automate `resetLostPartitions()` are inccredibly popular among
Ignite users. One could say that, in the world of k8s and other orchestrators,
handling of partition loss, rebalance, and graceful shutdowns remains the most
difficult thing to automated.
`shutdownPolicy=GRACEFUL` should already be enough to prevent partition loss
under normal operation (given proper configuration). However, it would be
really nice to implement automatic recovery from partition loss for cases when
nodes crash uncontrollably (e.g. OOM from an SQL query).
`resetLostPartitions()` is potentially dangerous as it fixes the state of the
partitions that's currently in the cluster: if some data wasn't returned, it's
lost forever. That's why any automation is tricky here.
h1. Proposal
I suggest that we enable a distributed boolean property
`resetLostPartitionsAutomatically` that's `false` by default (for safety and
compatibility). When the property is enabled, it allows the cluster to reset
lost partitions automatically when it decides it should be safe.
To implement this, we store the maximum update counter for each partition in
the metastore on each PME. Then we'll know the lower bound for each partition
counter at all times.
When the cluster has partition P lost, on each PME the coordinator checks P's
state in the cluster (`pCluster`) vs what's in the metastore (`pStore`) with
the following pseudocode:
{code:java}
maxCurrentUpdateCounter = max(map(pCluster.owners, o -> updateCounter));
lastKnownUpdateCounter = pStore.updateCounter
if (maxCurrentUpdateCounter >= lastKnownUpdateCounter)
resetLostPartition(p); // current would-be-primary has higher update
counter than recorded on last PME; so, there should be no data loss and
resetLostPartition is safe
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9825) Need test for cache writes on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418891#comment-17418891 ] Stanislav Lukyanov commented on IGNITE-9825: The test I used: [^SimpleLoadTest.java] > Need test for cache writes on unstable topology > --- > > Key: IGNITE-9825 > URL: https://issues.apache.org/jira/browse/IGNITE-9825 > Project: Ignite > Issue Type: Test >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Attachments: SimpleLoadTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that ignite-core test suites have no tests for a simple case - > cache writes on unstable topology. > Need to add a simple test covering this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9825) Need test for cache writes on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-9825: --- Attachment: SimpleLoadTest.java > Need test for cache writes on unstable topology > --- > > Key: IGNITE-9825 > URL: https://issues.apache.org/jira/browse/IGNITE-9825 > Project: Ignite > Issue Type: Test >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Attachments: SimpleLoadTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > It appears that ignite-core test suites have no tests for a simple case - > cache writes on unstable topology. > Need to add a simple test covering this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-9825) Need test for cache writes on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov resolved IGNITE-9825. Resolution: Cannot Reproduce > Need test for cache writes on unstable topology > --- > > Key: IGNITE-9825 > URL: https://issues.apache.org/jira/browse/IGNITE-9825 > Project: Ignite > Issue Type: Test >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It appears that ignite-core test suites have no tests for a simple case - > cache writes on unstable topology. > Need to add a simple test covering this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9825) Need test for cache writes on unstable topology
[ https://issues.apache.org/jira/browse/IGNITE-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418890#comment-17418890 ] Stanislav Lukyanov commented on IGNITE-9825: So, I tried to revisit this and see whether our tests today would catch this. I've checked the following: * If you revert 6e0ff06, the problem is reproduced with a simple test (see below) - logs are full of NPEs * At the same time, the NPEs seem not to cause any real issues - the data is intact as confirmed by idle_verify in the test * RunAll with 6e0ff06 passes - so, we indeed don't have a test that treats the NPE in the logs as a failure I'd say that while in ideal world we would've caught this and any other NPE in the logs in RunAll. But in reality, test logs can be full of (perfectly valid) exceptions, and it would be hard to catch them. I think the NPE in question also could be found in the RunAll with the 6e0ff06 reverted even in the current tests, but we don't scrape test logs for NPEs. The bottom line is: we can certainly say that our tests may fail to find a new weird exception in the logs if it doesn't cause any issues other than annoying log messages; at the same time, I currently don't have any basis to say that a gross regression would not have been caught by our tests. Doesn't look like we need to do anything here. > Need test for cache writes on unstable topology > --- > > Key: IGNITE-9825 > URL: https://issues.apache.org/jira/browse/IGNITE-9825 > Project: Ignite > Issue Type: Test >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It appears that ignite-core test suites have no tests for a simple case - > cache writes on unstable topology. > Need to add a simple test covering this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15517) Broken links in javadoc
[ https://issues.apache.org/jira/browse/IGNITE-15517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15517: Description: Javadoc has some broken links: [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteReflectionFactory.html] has a broken link [http://ignite.apache.org/images/spring-small.png.] [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/collision/jobstealing/JobStealingCollisionSpi.html] has a broken link [http://http//ignite.apache.org/images/job_stealing_white.gif]. Need to fix those and their copies. was: Javadoc has some broken links: [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteReflectionFactory.html] has a broken link [http://ignite.apache.org/images/spring-small.png.] > Broken links in javadoc > --- > > Key: IGNITE-15517 > URL: https://issues.apache.org/jira/browse/IGNITE-15517 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > > Javadoc has some broken links: > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteReflectionFactory.html] > has a broken link [http://ignite.apache.org/images/spring-small.png.] > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/spi/collision/jobstealing/JobStealingCollisionSpi.html] > has a broken link > [http://http//ignite.apache.org/images/job_stealing_white.gif]. > Need to fix those and their copies. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15517) Broken links in javadoc
Stanislav Lukyanov created IGNITE-15517: --- Summary: Broken links in javadoc Key: IGNITE-15517 URL: https://issues.apache.org/jira/browse/IGNITE-15517 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov Assignee: Stanislav Lukyanov Javadoc has some broken links: [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteReflectionFactory.html] has a broken link [http://ignite.apache.org/images/spring-small.png.] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9328) IgniteDevOnlyLogTest.testDevOnlyQuietMessage() fails to write.
[ https://issues.apache.org/jira/browse/IGNITE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17414636#comment-17414636 ] Stanislav Lukyanov commented on IGNITE-9328: "dev only" logs never got any love (for reasons I understand much better after all these years), so I'd rather delete the test together with the functionality TBH. > IgniteDevOnlyLogTest.testDevOnlyQuietMessage() fails to write. > -- > > Key: IGNITE-9328 > URL: https://issues.apache.org/jira/browse/IGNITE-9328 > Project: Ignite > Issue Type: Bug >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov >Priority: Major > Labels: MakeTeamcityGreenAgain > > After I have re-enabled it in IGNITE-9220 it started failing. I have also > migrated it to multiJvm. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15204) SQL exception to be handled by thin clients [CPP]
[ https://issues.apache.org/jira/browse/IGNITE-15204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391474#comment-17391474 ] Stanislav Lukyanov commented on IGNITE-15204: - How about adding the SQL error codes to the message on the server side? This would be helpful not just to thin clients, and thin clients already get the full message text. The application code will be able to parse the message to get the error code. > SQL exception to be handled by thin clients [CPP] > - > > Key: IGNITE-15204 > URL: https://issues.apache.org/jira/browse/IGNITE-15204 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Alexandr Shapkin >Priority: Major > > It would be nice to have meaningful error descriptions (like using ODBC) > instead of general ones. > For sample, working with SQL from a thin client it's impossible to get these > errors: > Uniq_Constraint ,Connection error,Timeout,Bind Param error,Cursor error, > Prepare error,Execute error,TABLE_NOTFOUND,CACHE_NOTFOUND > > Looks like the easiest way would be to wait for Ignite 3.0 release with the > new thin client protocol, but I think we can make some extension to the 2.x > protocol as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14685) Server crashes if joining node has static cache with a duplicate index
[
https://issues.apache.org/jira/browse/IGNITE-14685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339849#comment-17339849
]
Stanislav Lukyanov commented on IGNITE-14685:
-
Attached a reproducer. In DuplicateIndexTest, testStaticCaches and
testServerDynamicClientStaticCaches fail.
> Server crashes if joining node has static cache with a duplicate index
> --
>
> Key: IGNITE-14685
> URL: https://issues.apache.org/jira/browse/IGNITE-14685
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Stanislav Lukyanov
>Priority: Major
> Attachments: DuplicateIndexTest.java
>
>
> Scenario
> # Start a server
> # Create a cache FOO with an index named IDX and a schema named BAR
> # Start a client with a statically configured cache FOO2 with an index named
> IDX and a schema named BAR
> Expected result: either client is not allowed to join, or the cache FOO2 is
> not created.
> Result: server crashes.
> {code}
> [SEVERE][exchange-worker-#61%sqltests.DuplicateIndexTest0%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Duplicate index name [cache=foo2,
> schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]]]
> class org.apache.ignite.IgniteCheckedException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7613)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3405)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3199)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:2155)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1024)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1091)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1967)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1837)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$13(GridCacheProcessor.java:1789)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1834)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1788)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:965)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3377)
> ... 3 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14685) Server crashes if joining node has static cache with a duplicate index
[
https://issues.apache.org/jira/browse/IGNITE-14685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-14685:
Attachment: DuplicateIndexTest.java
> Server crashes if joining node has static cache with a duplicate index
> --
>
> Key: IGNITE-14685
> URL: https://issues.apache.org/jira/browse/IGNITE-14685
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Stanislav Lukyanov
>Priority: Major
> Attachments: DuplicateIndexTest.java
>
>
> Scenario
> # Start a server
> # Create a cache FOO with an index named IDX and a schema named BAR
> # Start a client with a statically configured cache FOO2 with an index named
> IDX and a schema named BAR
> Expected result: either client is not allowed to join, or the cache FOO2 is
> not created.
> Result: server crashes.
> {code}
> [SEVERE][exchange-worker-#61%sqltests.DuplicateIndexTest0%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Duplicate index name [cache=foo2,
> schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]]]
> class org.apache.ignite.IgniteCheckedException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7613)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3405)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3199)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:2155)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1024)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1091)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1967)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1837)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$13(GridCacheProcessor.java:1789)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1834)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1788)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:965)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3377)
> ... 3 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14685) Server crashes if joining node has static cache with a duplicate index
[
https://issues.apache.org/jira/browse/IGNITE-14685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-14685:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Server crashes if joining node has static cache with a duplicate index
> --
>
> Key: IGNITE-14685
> URL: https://issues.apache.org/jira/browse/IGNITE-14685
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> Scenario
> # Start a server
> # Create a cache FOO with an index named IDX and a schema named BAR
> # Start a client with a statically configured cache FOO2 with an index named
> IDX and a schema named BAR
> Expected result: either client is not allowed to join, or the cache FOO2 is
> not created.
> Result: server crashes.
> {code}
> [SEVERE][exchange-worker-#61%sqltests.DuplicateIndexTest0%][] Critical system
> error detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Duplicate index name [cache=foo2,
> schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]]]
> class org.apache.ignite.IgniteCheckedException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7613)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3405)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3199)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Duplicate index name
> [cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:2155)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1024)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1091)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1967)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1837)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$13(GridCacheProcessor.java:1789)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1834)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1788)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1769)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:965)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3377)
> ... 3 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14685) Server crashes if joining node has static cache with a duplicate index
Stanislav Lukyanov created IGNITE-14685:
---
Summary: Server crashes if joining node has static cache with a
duplicate index
Key: IGNITE-14685
URL: https://issues.apache.org/jira/browse/IGNITE-14685
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.10
Reporter: Stanislav Lukyanov
Scenario
# Start a server
# Create a cache FOO with an index named IDX and a schema named BAR
# Start a client with a statically configured cache FOO2 with an index named
IDX and a schema named BAR
Expected result: either client is not allowed to join, or the cache FOO2 is not
created.
Result: server crashes.
{code}
[SEVERE][exchange-worker-#61%sqltests.DuplicateIndexTest0%][] Critical system
error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.IgniteCheckedException: Duplicate index name [cache=foo2, schemaName=BAR,
idxName=IDX, existingTable=VAL, table=VAL2]]]
class org.apache.ignite.IgniteCheckedException: Duplicate index name
[cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7613)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3405)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3199)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteException: Duplicate index name
[cache=foo2, schemaName=BAR, idxName=IDX, existingTable=VAL, table=VAL2]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:2155)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:1024)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:1091)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1967)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1837)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$13(GridCacheProcessor.java:1789)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1834)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1788)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startReceivedCaches(GridCacheProcessor.java:1769)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:965)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3377)
... 3 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-7753) Processors are incorrectly initialized if a node joins during cluster activation
[
https://issues.apache.org/jira/browse/IGNITE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov reassigned IGNITE-7753:
--
Assignee: (was: Stanislav Lukyanov)
> Processors are incorrectly initialized if a node joins during cluster
> activation
>
>
> Key: IGNITE-7753
> URL: https://issues.apache.org/jira/browse/IGNITE-7753
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Stanislav Lukyanov
>Priority: Major
>
> If a node joins during the cluster activation process (while the related
> exchange operation is in progress), then some of the GridProcessor instances
> of that node will be incorrectly initialized. While GridClusterStateProcessor
> will correctly report the active cluster state, other processors that are
> sensitive to the cluster state, e.g. GridServiceProcessor, will be not
> initialized.
> A reproducer is below.
> ===
> Ignite server =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "server");
> CyclicBarrier barrier = new CyclicBarrier(2);
> Thread activationThread = new Thread(() -> {
> try {
> barrier.await();
> server.active(true);
> }
> catch (Exception e) {
> e.printStackTrace(); // TODO implement.
> }
> });
> activationThread.start();
> barrier.await();
> IgnitionEx.setClientMode(true);
> Ignite client =
> IgnitionEx.start("examples/config/persistentstore/example-persistent-store.xml",
> "client");
> activationThread.join();
> client.services().deployClusterSingleton("myClusterSingleton", new
> SimpleMapServiceImpl<>());
> ===
> Here a single server node is started, then simultaneously a client node is
> being started and the cluster is being activated, then client attempts to
> deploy a service. As the result, the thread calling the deploy method hangs
> forever with a stack trace like this:
> ===
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:7505)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.serviceCache(GridServiceProcessor.java:290)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.writeServiceToCache(GridServiceProcessor.java:728)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:634)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:600)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployMultiple(GridServiceProcessor.java:488)
> at
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployClusterSingleton(GridServiceProcessor.java:469)
> at
> org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:120)
> ===
> The behavior depends on the timings - the client has to join in the middle of
> the activation's exchange process. Putting Thread.sleep(4000) into
> GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest seems to work on
> a development laptop.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-7704) Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations
[ https://issues.apache.org/jira/browse/IGNITE-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov reassigned IGNITE-7704: -- Assignee: (was: Stanislav Lukyanov) > Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts > and their relations > --- > > Key: IGNITE-7704 > URL: https://issues.apache.org/jira/browse/IGNITE-7704 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Alexey Popov >Priority: Major > Fix For: 2.11 > > Attachments: timeouts.md, timeouts_v2.md > > > We often see similar questions related to IgniteConfiguration, > TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations. And we see > several side-effects after incorrect timeout configuration. > It looks like this question is not well documented. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13019) Unexpected JOIN result when querying a single-node cluster
[
https://issues.apache.org/jira/browse/IGNITE-13019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326560#comment-17326560
]
Stanislav Lukyanov commented on IGNITE-13019:
-
[~amashenkov], on your comment about the performance - how bad do you think
it'll be? I actually like that currently in the code all checks are separate as
it makes them much either to read. Merging them all into a single method or a
chain of visitors might get pretty complicated... Do you think running a set of
benchmarks before merging will suffice to show that this doesn't hurt the
performance too much?
> Unexpected JOIN result when querying a single-node cluster
> --
>
> Key: IGNITE-13019
> URL: https://issues.apache.org/jira/browse/IGNITE-13019
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Check reproducer near,
> seems something wrong with pkey logic , if we change it - results will be ok.
> {code:java}
> @Test
> public void test() throws Exception {
> inlineSize = 10;
> startGrid(0);
> String t1 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno)\n" +
> " );";
> execSql(t1);
> String t2 = "CREATE TABLE emp\n" +
> " (\n" +
> "empno LONG,\n" +
> "ename VARCHAR,\n" +
> "job VARCHAR,\n" +
> "mgr INTEGER,\n" +
> "hiredate DATE,\n" +
> "sal LONG,\n" +
> "comm LONG,\n" +
> "deptno LONG,\n" +
> "CONSTRAINT pk_emp PRIMARY KEY (empno)\n" +
> " );";
> execSql(t2);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7839, 'KING', 'PRESIDENT', null,
> to_date('17-11-1981','dd-mm-'), 5000, null, 10);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values( 7698, 'BLAKE', 'MANAGER', 7839,
> to_date('1-5-1981','dd-mm-'), 2850, null, 30);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7782, 'CLARK', 'MANAGER', 7839,
> to_date('9-6-1981','dd-mm-'), 2450, null, 10);");
> List> vals1 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals1.size(), 2);
> List> vals2 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> //assertEquals(vals2.size(), 2); <--* uncomment for fail*
> execSql("drop table dept");
> String t3 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno, dname)\n" +
> " );";
> execSql(t3);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> List> vals11 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals11.size(), 2);
> List> vals22 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> assertEquals(vals22.size(), 2);
> }
> /** */
> private List> execSql(String qry) {
> return grid(0).context().query()
> .querySqlFields(new SqlFieldsQuery(qry).setLazy(true), false)
> .getAll();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13019) Unexpected JOIN result when querying a single-node cluster
[
https://issues.apache.org/jira/browse/IGNITE-13019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17326558#comment-17326558
]
Stanislav Lukyanov commented on IGNITE-13019:
-
Some comments in the PR.
Also, I would like to raise a couple of additional suggestions.
First, I think it would be very helpful if we print an INFO-level message when
a partitioned cache is created that contains the primary and affinity key
columns and explains that the JOINs with other partitioned caches must use
either the affinity key or the primary key.
Second, I think it would be good to have a mode when an incorrect JOIN
condition throws an error instead of printing a warning. Furthermore, I think
the next minor Ignite version can have the error as default. The error can be
suppressed by changing a metastore property.
> Unexpected JOIN result when querying a single-node cluster
> --
>
> Key: IGNITE-13019
> URL: https://issues.apache.org/jira/browse/IGNITE-13019
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Check reproducer near,
> seems something wrong with pkey logic , if we change it - results will be ok.
> {code:java}
> @Test
> public void test() throws Exception {
> inlineSize = 10;
> startGrid(0);
> String t1 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno)\n" +
> " );";
> execSql(t1);
> String t2 = "CREATE TABLE emp\n" +
> " (\n" +
> "empno LONG,\n" +
> "ename VARCHAR,\n" +
> "job VARCHAR,\n" +
> "mgr INTEGER,\n" +
> "hiredate DATE,\n" +
> "sal LONG,\n" +
> "comm LONG,\n" +
> "deptno LONG,\n" +
> "CONSTRAINT pk_emp PRIMARY KEY (empno)\n" +
> " );";
> execSql(t2);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7839, 'KING', 'PRESIDENT', null,
> to_date('17-11-1981','dd-mm-'), 5000, null, 10);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values( 7698, 'BLAKE', 'MANAGER', 7839,
> to_date('1-5-1981','dd-mm-'), 2850, null, 30);");
> execSql("insert into emp (empno, ename, job, mgr, hiredate, sal,
> comm, deptno) values(7782, 'CLARK', 'MANAGER', 7839,
> to_date('9-6-1981','dd-mm-'), 2450, null, 10);");
> List> vals1 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals1.size(), 2);
> List> vals2 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> //assertEquals(vals2.size(), 2); <--* uncomment for fail*
> execSql("drop table dept");
> String t3 = "CREATE TABLE dept\n" +
> " (\n" +
> "deptno LONG,\n" +
> "dname VARCHAR,\n" +
> "loc VARCHAR,\n" +
> "CONSTRAINT pk_dept PRIMARY KEY (deptno, dname)\n" +
> " );";
> execSql(t3);
> execSql("insert into dept (deptno, dname, loc) values (10,
> 'ACCOUNTING', 'NEW YORK');");
> execSql("insert into dept (deptno, dname, loc) values(20, 'RESEARCH',
> 'DALLAS');");
> execSql("insert into dept (deptno, dname, loc) values(30, 'SALES',
> 'CHICAGO');");
> List> vals11 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND e.deptno = 10;");
> assertEquals(vals11.size(), 2);
> List> vals22 = execSql("SELECT d.deptno,\n" +
> "e.ename\n" +
> "FROM EMP e\n" +
> "INNER JOIN dept d\n" +
> "ON e.deptno = d.deptno AND d.DEPTNO = 10;");
> assertEquals(vals22.size(), 2);
> }
> /** */
> private List> execSql(String qry) {
> return grid(0).context().query()
>
[jira] [Commented] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319653#comment-17319653 ] Stanislav Lukyanov commented on IGNITE-6895: Please see my comment in https://issues.apache.org/jira/browse/IGNITE-6894 (how are these two issues different, really? I think solving deadlocks without solving hanged TXs isn't really possible, and vice versa) > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov (Obsolete, actual is "av") >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319650#comment-17319650
]
Stanislav Lukyanov commented on IGNITE-6893:
We don't only check for starvation, we check for any hanging Ignite threads
with the thread heartbeats. The only way we may miss a deadlock is if it is in
a user's thread. I don't think Ignite should be responsible for finding
deadlocks in the threads it doesn't manage.
> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov (Obsolete, actual is "av")
>Priority: Major
> Labels: iep-7
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock.
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a
> warning on UI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6894) Hanged Tx monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17319647#comment-17319647 ] Stanislav Lukyanov commented on IGNITE-6894: [~avinogradov] Logging of long-running transactions is already implemented - the code you've linked (dumpLongRunningOperations0) is doing that. The only other thing mentioned in the ticket is the Web Console enhancement. So, is this a ticket for the Web Console? > Hanged Tx monitoring > > > Key: IGNITE-6894 > URL: https://issues.apache.org/jira/browse/IGNITE-6894 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov (Obsolete, actual is "av") >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Hanging Transactions not Related to Deadlock > Description > This situation can occur if user explicitly markups the transaction (esp > Pessimistic Repeatable Read) and, for example, calls remote service (which > may be unresponsive) after acquiring some locks. All other transactions > depending on the same keys will hang. > Detection and Solution > This most likely cannot be resolved automatically other than rollback TX by > timeout and release all the locks acquired so far. Also such TXs can be > rolled back from Web Console as described above. > If transaction has been rolled back on timeout or via UI then any further > action in the transaction, e.g. lock acquisition or commit attempt should > throw exception. > Report > Management tools (eg. Web Console) should provide ability to rollback any > transaction via UI. > Long running transaction should be reported to logs. Log record should > contain: near nodes, transaction IDs, cache names, keys (limited to several > tens of), etc ( ?). > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the info as above. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9325) Add an ability to make a sound after a complete execution to all command-line utilities
[ https://issues.apache.org/jira/browse/IGNITE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17317371#comment-17317371 ] Stanislav Lukyanov commented on IGNITE-9325: Instead of the beep, it's better to play a WAV with the "work complete" sound of your favorite WC3 race. Obviously, Ignite can't use WC3 sounds for copyright reasons, so no point in implementing any sound functionality at all. On a serious note, simple ``` bin/control.sh --state; echo -e "\a" ``` worked for me on OS X (and you can use `afplay` to play a WAV - or at least internet tells me so). I think this ticket should be closed. > Add an ability to make a sound after a complete execution to all command-line > utilities > --- > > Key: IGNITE-9325 > URL: https://issues.apache.org/jira/browse/IGNITE-9325 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Artsiom Panko >Priority: Major > Labels: command-line, newbie > > Often I work simultaneously on several clusters over ssh and there are > situations when I forget to check that the first cluster has completed the > command (for example, activation), while working on the second. > It would be great if there was an option to ignite command-line utilities > that would allow some sort of sound (or system beep) to be played after the > command got executed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
