[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate ignite-jdbc module # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it was: # Create a separate ignite-jdbc module # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it Consider an option to create ignite-jdbc-client and get rid of using ignite-client in ignite-jdbc module. > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate ignite-jdbc module > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on client-common, client-handler modules > # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18419) Create jdbc-client
Ivan Gagarkin created IGNITE-18419: -- Summary: Create jdbc-client Key: IGNITE-18419 URL: https://issues.apache.org/jira/browse/IGNITE-18419 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin Currently, IgniteJdbcDriver uses TcpIgniteClient for messaging between a client and a server. TcpIgniteClient is also used as a thing Ignite client and has more possible options to interact with Ignite than needed for JDBC. It would be better to create a special IgniteJdbcClient and don't use TcpIgniteClient in JDBC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18419) Create jdbc-client
[ https://issues.apache.org/jira/browse/IGNITE-18419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18419: --- Component/s: jdbc > Create jdbc-client > -- > > Key: IGNITE-18419 > URL: https://issues.apache.org/jira/browse/IGNITE-18419 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > Currently, IgniteJdbcDriver uses TcpIgniteClient for messaging between a > client and a server. TcpIgniteClient is also used as a thing Ignite client > and has more possible options to interact with Ignite than needed for JDBC. > It would be better to create a special IgniteJdbcClient and don't use > TcpIgniteClient in JDBC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
[ https://issues.apache.org/jira/browse/IGNITE-18354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina resolved IGNITE-18354. - Resolution: Duplicate > Update apache ignite docs to replace deprecated info from Ignite.active() to > Ignite.cluster().state(ClusterState.ACTIVE) > > > Key: IGNITE-18354 > URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > > Currently, some classes contain outdated ignite apache docs info re > Ignite.active() and Ignite.active(boolean active). active() and > active(boolean active) are deprecated since 2018 thus the docs throughout the > project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate ignite-jdbc module # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it Consider an option to create ignite-jdbc-client and get rid of using ignite-client in ignite-jdbc module. was: # Create a separate ignite-jdbc module # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate ignite-jdbc module > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on ignite-client, client-common, > client-handler modules > # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it > Consider an option to create ignite-jdbc-client and get rid of using > ignite-client in ignite-jdbc module. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647876#comment-17647876 ] Chenjian commented on IGNITE-18102: --- [~zstan] Thanks. [~jooger] Hi boss, can you guide me on this? which test file is in charge of the creating table test? > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Assignee: Chenjian >Priority: Minor > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Build a fat jar of ignite-jdbc and publish it was: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Build fat-jar of ignite-jdbc and publish it > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate module ignite-jdbc > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on ignite-client, client-common, > client-handler modules > # Build a fat jar of ignite-jdbc and publish it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it was: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Build a fat jar of ignite-jdbc and publish it > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate module ignite-jdbc > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on ignite-client, client-common, > client-handler modules > # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate ignite-jdbc module # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it was: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate ignite-jdbc module > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on ignite-client, client-common, > client-handler modules > # Create Maven/Gradle tasks to build a fat jar of ignite-jdbc and publish it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Description: # Create a separate module ignite-jdbc # Move the code base of jdbc to the new module (IgniteJdbcDriver, JdbcConnection, JdbcResultSet, etc) # The new module should depend on ignite-client, client-common, client-handler modules # Build fat-jar of ignite-jdbc and publish it > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > > # Create a separate module ignite-jdbc > # Move the code base of jdbc to the new module (IgniteJdbcDriver, > JdbcConnection, JdbcResultSet, etc) > # The new module should depend on ignite-client, client-common, > client-handler modules > # Build fat-jar of ignite-jdbc and publish it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18102) Ignite does not support create table with dot column
[ https://issues.apache.org/jira/browse/IGNITE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chenjian reassigned IGNITE-18102: - Assignee: Chenjian > Ignite does not support create table with dot column > > > Key: IGNITE-18102 > URL: https://issues.apache.org/jira/browse/IGNITE-18102 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Chenjian >Assignee: Chenjian >Priority: Minor > Attachments: image-2022-11-07-17-57-49-255.png, > image-2022-11-07-18-01-49-687.png > > > Ignite does not support create the column with dot. > like create table (... , `a.dot` bigint, ...), using the !columns command > only can see the suffix about the defined name `dot`. > But Ignite allow add column with dot which is not compatible with self. > Eg: > !image-2022-11-07-17-57-49-255.png! > !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18418) Create a separate ignite-jdbc module
[ https://issues.apache.org/jira/browse/IGNITE-18418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-18418: --- Component/s: jdbc > Create a separate ignite-jdbc module > > > Key: IGNITE-18418 > URL: https://issues.apache.org/jira/browse/IGNITE-18418 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Reporter: Ivan Gagarkin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18418) Create a separate ignite-jdbc module
Ivan Gagarkin created IGNITE-18418: -- Summary: Create a separate ignite-jdbc module Key: IGNITE-18418 URL: https://issues.apache.org/jira/browse/IGNITE-18418 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18377) Sql statistics become broken after node restart with enabled persistence.
[
https://issues.apache.org/jira/browse/IGNITE-18377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647853#comment-17647853
]
Ignite TC Bot commented on IGNITE-18377:
{panel:title=Branch: [pull/10441/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10441/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963081]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite4:
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite4:
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance -
PASSED{color}
{color:#8b}Queries 4 (lazy=true){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963082]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4:
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4:
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6963105&buildTypeId=IgniteTests24Java8_RunAll]
> Sql statistics become broken after node restart with enabled persistence.
> -
>
> Key: IGNITE-18377
> URL: https://issues.apache.org/jira/browse/IGNITE-18377
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.14
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It tuned out that for some reasons SQL query may be dispatched to data node
> which is performing rebalance. Eventually this will lead to falling back to
> full table scan usage instead of proper tree index.
> Scenario:
> 1. Cluster in normal state with multiple nodes, under workload (both cache
> writes/updates and SQL selects)
> 2. Particular node A is restarted
> 3. Since there were writes during the time when node A was offline, node A
> would has to perform historical rebalance
> 4. During performing historical rebalance SQL select might be dispatched to
> be executed on node A as well, but at this moment node A will return 0
> primary row count for caches under rebalance, so we will initialize table
> statistics incorrectly and further will calculate unrealistic costs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18071) Thin 3.0: Add heartbeat timeout
[ https://issues.apache.org/jira/browse/IGNITE-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647670#comment-17647670 ] Pavel Tupitsyn commented on IGNITE-18071: - Merged to main: c7ea5c8bd5811316e5facb54cd8d72f501681137 > Thin 3.0: Add heartbeat timeout > --- > > Key: IGNITE-18071 > URL: https://issues.apache.org/jira/browse/IGNITE-18071 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Close connection when the server does not respond to heartbeat in a specified > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18417) .NET: Tests sometime killed by OOM killer
[
https://issues.apache.org/jira/browse/IGNITE-18417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647664#comment-17647664
]
Pavel Tupitsyn commented on IGNITE-18417:
-
*PlatformCacheTopologyChangeTest* consumes a lot of memory on Java side, but
there are no more than 100 cache entries in use.
> .NET: Tests sometime killed by OOM killer
> -
>
> Key: IGNITE-18417
> URL: https://issues.apache.org/jira/browse/IGNITE-18417
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Example of crash log:
> {noformat}
> Test Run Aborted with error System.Exception: One or more errors occurred.
> 21:38:48 ---> System.Exception: Unable to read beyond the end of the
> stream.
> 21:38:48at System.IO.BinaryReader.Read7BitEncodedInt()
> 21:38:48at System.IO.BinaryReader.ReadString()
> 21:38:48at
> Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.LengthPrefixCommunicationChannel.NotifyDataAvailable()
> 21:38:48at
> Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TcpClientExtensions.MessageLoopAsync(TcpClient
> client, ICommunicationChannel channel, Action`1 errorHandler,
> CancellationToken cancellationToken)
> {noformat}
> Example of test run with the crash:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/6950868?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&showLog=6950868_186683_420.426&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18417) .NET: Tests sometime killed by OOM killer
[
https://issues.apache.org/jira/browse/IGNITE-18417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-18417:
---
Assignee: Pavel Tupitsyn
> .NET: Tests sometime killed by OOM killer
> -
>
> Key: IGNITE-18417
> URL: https://issues.apache.org/jira/browse/IGNITE-18417
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> Example of crash log:
> {noformat}
> Test Run Aborted with error System.Exception: One or more errors occurred.
> 21:38:48 ---> System.Exception: Unable to read beyond the end of the
> stream.
> 21:38:48at System.IO.BinaryReader.Read7BitEncodedInt()
> 21:38:48at System.IO.BinaryReader.ReadString()
> 21:38:48at
> Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.LengthPrefixCommunicationChannel.NotifyDataAvailable()
> 21:38:48at
> Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TcpClientExtensions.MessageLoopAsync(TcpClient
> client, ICommunicationChannel channel, Action`1 errorHandler,
> CancellationToken cancellationToken)
> {noformat}
> Example of test run with the crash:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/6950868?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&showLog=6950868_186683_420.426&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18417) .NET: Tests sometime killed by OOM killer
Igor Sapego created IGNITE-18417:
Summary: .NET: Tests sometime killed by OOM killer
Key: IGNITE-18417
URL: https://issues.apache.org/jira/browse/IGNITE-18417
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.14
Reporter: Igor Sapego
Example of crash log:
{noformat}
Test Run Aborted with error System.Exception: One or more errors occurred.
21:38:48 ---> System.Exception: Unable to read beyond the end of the
stream.
21:38:48at System.IO.BinaryReader.Read7BitEncodedInt()
21:38:48at System.IO.BinaryReader.ReadString()
21:38:48at
Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.LengthPrefixCommunicationChannel.NotifyDataAvailable()
21:38:48at
Microsoft.VisualStudio.TestPlatform.CommunicationUtilities.TcpClientExtensions.MessageLoopAsync(TcpClient
client, ICommunicationChannel channel, Action`1 errorHandler,
CancellationToken cancellationToken)
{noformat}
Example of test run with the crash:
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/6950868?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildProblemsSection=true&showLog=6950868_186683_420.426&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18416) Extend test coverage for DistributionZoneManager
Sergey Uttsel created IGNITE-18416: -- Summary: Extend test coverage for DistributionZoneManager Key: IGNITE-18416 URL: https://issues.apache.org/jira/browse/IGNITE-18416 Project: Ignite Issue Type: Improvement Reporter: Sergey Uttsel Need to extend test coverage for DistributionZoneManager. So need to implement test cases: Test1: # Start node1. # Create zone1 with scaleUp = 10. # Start node2. Zone timer is started at node1. # Restart node1 before a timer expiration. # Check that data nodes for zone1 is [node1, node2]. Test2: # Start node1, node2 with "zone1: scaleUp = 10". # Start node3 at the time 5. Zone timer is started at node1 and node2 which will do metastorage.invoke at time 15. # Stop node2 at time 10. # At node2 at time 15 zone timer triggers metastorage.invoke. Data nodes are changed to [node1, node2, node3]. # Start node4 at the moment 30. Zone timer is started and will do metastorage.invoke at time 40. # At time 40 timer triggers metastorage.invoke. Data nodes are changed to [node1, node2, node3, node4]. # Start node2 at time 50. Node2 try to do metastorage.invoke with dataNodes [node1, node2, node3]. # Check that this invoke is failed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18294) Multiple lock intentions support
[ https://issues.apache.org/jira/browse/IGNITE-18294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647608#comment-17647608 ] Ivan Bessonov commented on IGNITE-18294: [~v.pyatkov] please don't forget to close the pull request in github and please update the fix version > Multiple lock intentions support > > > Key: IGNITE-18294 > URL: https://issues.apache.org/jira/browse/IGNITE-18294 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > Current implementation of HeapLockManager relies on waiters that can support > only one lock intention for each transaction at a moment of time. This can > lead to problems like following: > - there are transactions tx1, tx2, tx3 started in corresponding order; > - all txs acquire S-locks; > - tx2 tries to acquire IX-lock, it's incompatible with S-locks from tx1 and > tx3, this is a lock intention and a future is created, which is completed > when SIX-lock is acquired (supremum of S and IX locks) > - tx2 concurrently tries to acquire X-lock, this is another lock intention, > supremum of locks for tx2 is X-lock. The information about previous intention > is lost; > - tx3 is committed, and tx2 waits only for tx1 but it is not allowed to wait > for it due to wait-die deadlock prevention. All lock intentions should be > canceled. > Definition of done: > We have lock mode counters inside of waiter, they should be adapted for lock > intention support. Also, "upgraded" flag of waiters and all the logic related > to "previous lock mode" should be removed. After that, the test scenario > described above should pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18413) Reorganize metastorage modules
[ https://issues.apache.org/jira/browse/IGNITE-18413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-18413: - Description: MetaStorage-related class are located in 4 modules: # metastorage # metastorage-common # metastorage-client # metastorage-server This blocks to the ongoing work on using learners in the Meta Storage, because, for example, it is currently impossible to access the Raft storage through the Meta Storage client (they are located in different modules). Moreover, these modules seem redundant and the structure can be simplified to look like other modules' structure. Therefore it is proposed to reorganize the Meta Storage into 2 modules: # metastorage # metastorage-api was: MetaStorage-related class are located in 4 modules: # metastorage-common # metastorage # metastorage-client # metastroage-server This blocks to the ongoing work on using learners in the Meta Storage, because, for example, it is currently impossible to access the Raft storage through the Meta Storage client (they are located in different modules). Moreover, these modules seem redundant and the structure can be simplified to look like other modules' structure. Therefore it is proposed to reorganize the Meta Storage into 2 modules: # metastorage # metastorage-api > Reorganize metastorage modules > -- > > Key: IGNITE-18413 > URL: https://issues.apache.org/jira/browse/IGNITE-18413 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > MetaStorage-related class are located in 4 modules: > # metastorage > # metastorage-common > # metastorage-client > # metastorage-server > This blocks to the ongoing work on using learners in the Meta Storage, > because, for example, it is currently impossible to access the Raft storage > through the Meta Storage client (they are located in different modules). > Moreover, these modules seem redundant and the structure can be simplified to > look like other modules' structure. Therefore it is proposed to reorganize > the Meta Storage into 2 modules: > # metastorage > # metastorage-api -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18415) SQL. Cannot use UUID class as parameters for query
Yury Gerzhedovich created IGNITE-18415:
--
Summary: SQL. Cannot use UUID class as parameters for query
Key: IGNITE-18415
URL: https://issues.apache.org/jira/browse/IGNITE-18415
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
imple broken scenario looks as
{code:java}
assertQuery("SELECT typeof( ? )").withParams(new
UUID(1,1)).returns(toSqlType(UUID)).check();{code}
In the case we have the following error:
{code:java}
org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
Expected: [UUID]
Actual: [RecordType()] {code}
h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18414) SQL. Cannot use BigInteger class as parameters for query
[
https://issues.apache.org/jira/browse/IGNITE-18414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18414:
---
Description:
imple broken scenario looks as
{code:java}
assertQuery("SELECT typeof( ?
)").withParams(BigInteger.valueOf(1)).returns(toSqlType(NUMBER)).check();{code}
In the case we have the following error:
{code:java}
org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
Expected: [NUMBER]
Actual: [RecordType()] {code}
h4.
was:
imple broken scenario looks as
{code:java}
{code}
assertQuery("SELECT
typeof(?)").withParams(BigInteger.valueOf(1)).returns(toSqlType(
NUMBER)).check();;
{code:java}
{code}
In the case we have the following error:
{code:java}
org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
Expected: [NUMBER]
Actual: [RecordType()] {code}
h4.
> SQL. Cannot use BigInteger class as parameters for query
>
>
> Key: IGNITE-18414
> URL: https://issues.apache.org/jira/browse/IGNITE-18414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
>
> imple broken scenario looks as
> {code:java}
> assertQuery("SELECT typeof( ?
> )").withParams(BigInteger.valueOf(1)).returns(toSqlType(NUMBER)).check();{code}
> In the case we have the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
> Expected: [NUMBER]
> Actual: [RecordType()] {code}
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18414) SQL. Cannot use BigInteger class as parameters for query
[
https://issues.apache.org/jira/browse/IGNITE-18414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18414:
---
Labels: ignite-3 (was: )
> SQL. Cannot use BigInteger class as parameters for query
>
>
> Key: IGNITE-18414
> URL: https://issues.apache.org/jira/browse/IGNITE-18414
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> imple broken scenario looks as
> {code:java}
> assertQuery("SELECT typeof( ?
> )").withParams(BigInteger.valueOf(1)).returns(toSqlType(NUMBER)).check();{code}
> In the case we have the following error:
> {code:java}
> org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
> Expected: [NUMBER]
> Actual: [RecordType()] {code}
> h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18414) SQL. Cannot use BigInteger class as parameters for query
Yury Gerzhedovich created IGNITE-18414:
--
Summary: SQL. Cannot use BigInteger class as parameters for query
Key: IGNITE-18414
URL: https://issues.apache.org/jira/browse/IGNITE-18414
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
imple broken scenario looks as
{code:java}
{code}
assertQuery("SELECT
typeof(?)").withParams(BigInteger.valueOf(1)).returns(toSqlType(
NUMBER)).check();;
{code:java}
{code}
In the case we have the following error:
{code:java}
org.opentest4j.AssertionFailedError: Collections are not equal (position 0):
Expected: [NUMBER]
Actual: [RecordType()] {code}
h4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18377) Sql statistics become broken after node restart with enabled persistence.
[
https://issues.apache.org/jira/browse/IGNITE-18377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647589#comment-17647589
]
Ignite TC Bot commented on IGNITE-18377:
{panel:title=Branch: [pull/10441/head] Base: [master] : Possible Blockers
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=6963202]]
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestDiscoveryWithoutClientConnectorOnServer
- Test has low fail rate in base branch 0,0% and is not flaky
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestClientMaintainsConnectionWhenOriginalNodeLeaves
- Test has low fail rate in base branch 0,0% and is not flaky
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestClientDiscoveryWithRandomTopologyChanges
- Test has low fail rate in base branch 0,0% and is not flaky
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestThinClientDoesNotDiscoverThickClientNodes
- Test has low fail rate in base branch 0,0% and is not flaky
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
- Test has low fail rate in base branch 0,0% and is not flaky
* exe:
ClientClusterDiscoveryTestsNoLocalhost.TestClientDiscoversJoinedServersAndRemovesDisconnected
- Test has low fail rate in base branch 0,0% and is not flaky
* exe: IgnitionStartTest.TestIgniteStartsFromAppConfig - Test has low fail rate
in base branch 0,0% and is not flaky
* exe: IgniteConfigurationSectionTest.TestIgniteStart - Test has low fail rate
in base branch 0,0% and is not flaky
* dll: EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup -
Test has low fail rate in base branch 0,0% and is not flaky
* exe: IgniteStartStopTest.TestStartDefault - Test has low fail rate in base
branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10441/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 4{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963081]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite4:
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite4:
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance -
PASSED{color}
{color:#8b}Queries 4 (lazy=true){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963082]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4:
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4:
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6963105&buildTypeId=IgniteTests24Java8_RunAll]
> Sql statistics become broken after node restart with enabled persistence.
> -
>
> Key: IGNITE-18377
> URL: https://issues.apache.org/jira/browse/IGNITE-18377
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.14
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It tuned out that for some reasons SQL query may be dispatched to data node
> which is performing rebalance. Eventually this will lead to falling back to
> full table scan usage instead of proper tree index.
> Scenario:
> 1. Cluster in normal state with multiple nodes, under workload (both cache
> writes/updates and SQL selects)
> 2. Particular node A is restarted
> 3. Since there were writes during the time when node A was offline, node A
> would has to perform historical rebalance
> 4. During performing historical rebalance SQL select might be dispatched to
> be executed on node A as well, but at this moment node A will return 0
> primary row count for caches under rebalance, so we will initialize table
> statistics incorrectly and further will calculate unrealistic costs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18413) Reorganize metastorage modules
[ https://issues.apache.org/jira/browse/IGNITE-18413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-18413: - Description: MetaStorage-related class are located in 4 modules: # metastorage-common # metastorage # metastorage-client # metastroage-server This blocks to the ongoing work on using learners in the Meta Storage, because, for example, it is currently impossible to access the Raft storage through the Meta Storage client (they are located in different modules). Moreover, these modules seem redundant and the structure can be simplified to look like other modules' structure. Therefore it is proposed to reorganize the Meta Storage into 2 modules: # metastorage # metastorage-api > Reorganize metastorage modules > -- > > Key: IGNITE-18413 > URL: https://issues.apache.org/jira/browse/IGNITE-18413 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > MetaStorage-related class are located in 4 modules: > # metastorage-common > # metastorage > # metastorage-client > # metastroage-server > This blocks to the ongoing work on using learners in the Meta Storage, > because, for example, it is currently impossible to access the Raft storage > through the Meta Storage client (they are located in different modules). > Moreover, these modules seem redundant and the structure can be simplified to > look like other modules' structure. Therefore it is proposed to reorganize > the Meta Storage into 2 modules: > # metastorage > # metastorage-api -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18413) Reorganize metastorage modules
Aleksandr Polovtcev created IGNITE-18413: Summary: Reorganize metastorage modules Key: IGNITE-18413 URL: https://issues.apache.org/jira/browse/IGNITE-18413 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18413) Reorganize metastorage modules
[ https://issues.apache.org/jira/browse/IGNITE-18413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-18413: - Fix Version/s: 3.0.0-beta2 > Reorganize metastorage modules > -- > > Key: IGNITE-18413 > URL: https://issues.apache.org/jira/browse/IGNITE-18413 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18389) Fix page index handling at BplusTree.Get#notFound, it can't get negative value
[ https://issues.apache.org/jira/browse/IGNITE-18389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko resolved IGNITE-18389. -- Resolution: Invalid > Fix page index handling at BplusTree.Get#notFound, it can't get negative value > -- > > Key: IGNITE-18389 > URL: https://issues.apache.org/jira/browse/IGNITE-18389 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3, technical-debt > > It was found that the page index that falls into > *org.apache.ignite.internal.pagememory.tree.BplusTree.Get#notFound* cannot be > negative, it is necessary to remove the handling of negative values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18402) ItLogicalTopologyTest.receivesLogicalTopologyEventsCausedByNodeRestart fails locally
[ https://issues.apache.org/jira/browse/IGNITE-18402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647500#comment-17647500 ] Aleksandr Polovtcev commented on IGNITE-18402: -- Looks nice, thank you > ItLogicalTopologyTest.receivesLogicalTopologyEventsCausedByNodeRestart fails > locally > > > Key: IGNITE-18402 > URL: https://issues.apache.org/jira/browse/IGNITE-18402 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > On the TC it seems to pass -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18071) Thin 3.0: Add heartbeat timeout
[ https://issues.apache.org/jira/browse/IGNITE-18071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647117#comment-17647117 ] Igor Sapego commented on IGNITE-18071: -- Looks good to me. > Thin 3.0: Add heartbeat timeout > --- > > Key: IGNITE-18071 > URL: https://issues.apache.org/jira/browse/IGNITE-18071 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Close connection when the server does not respond to heartbeat in a specified > time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18213) Sql. Make exchange rewindable
[ https://issues.apache.org/jira/browse/IGNITE-18213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-18213: - Assignee: Konstantin Orlov > Sql. Make exchange rewindable > - > > Key: IGNITE-18213 > URL: https://issues.apache.org/jira/browse/IGNITE-18213 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > This causes the whole table being send over the network and being stored in > the spool node. > This could be improved by making the exchange operator rewindable. > Need to introduce new type of message similar to InboxCloseMessage, but for > 'rewind' operation. The message should contain list of correlated variables. > Outbox, in turn, should accept this message, update correlation variables in > the local context with the received one, and rewind the local execution tree. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18408) Store replication protocol config as bytes in MvPartitionStorage
[
https://issues.apache.org/jira/browse/IGNITE-18408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18408:
---
Labels: ignite-3 tech-debt (was: ignite-3)
> Store replication protocol config as bytes in MvPartitionStorage
>
>
> Key: IGNITE-18408
> URL: https://issues.apache.org/jira/browse/IGNITE-18408
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
>
> Currently, each {{MvPartitionStorage}} implementation serializes the config
> object itself. This serialization should be made outside, the storage should
> only store the serialization results (as bytes).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18262) .NET: Missing files and broken examples in binary release zip package
[ https://issues.apache.org/jira/browse/IGNITE-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18262: Release Note: .NET: Fixed missing dlls in release package. (was: .NET: Fixed missing dlls in release package) > .NET: Missing files and broken examples in binary release zip package > - > > Key: IGNITE-18262 > URL: https://issues.apache.org/jira/browse/IGNITE-18262 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Issues in binary distribution > (https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip): > * *platforms/dotnet/bin* contains *netcoreapp3.1* directory, even though we > are on .NET 6 now > * LINQ and other binaries are missing in *netcoreapp3.1* directory > * Examples do not work correctly because they expect > *\bin\Apache.Ignite.Core.dll* in *Directory.Build.props* - as a result, > latest NuGet package is used instead of dlls from the parent dir. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647094#comment-17647094 ] Andrey Mashenkov edited comment on IGNITE-17945 at 12/14/22 1:05 PM: - Maxim, I'd just say "Possible too long JVM pause (this can happens due to long GC or internal JVM reasons or external reasons, like OS or other)", if you want to be more precise. was (Author: amashenkov): Maxim, I'd just say "Possible too long JVM pause (this can happens due to long GC or internal JVM reasons or external reasons, like OS or other)" > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647094#comment-17647094 ] Andrey Mashenkov commented on IGNITE-17945: --- Maxim, I'd just say "Possible too long JVM pause (this can happens due to long GC or internal JVM reasons or external reasons, like OS or other)" > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18316) Reusing same waiter for multiple acquisitions can lead to races due to future rewrite outside of synchronized section
[
https://issues.apache.org/jira/browse/IGNITE-18316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-18316:
-
Assignee: Denis Chudov
> Reusing same waiter for multiple acquisitions can lead to races due to future
> rewrite outside of synchronized section
> -
>
> Key: IGNITE-18316
> URL: https://issues.apache.org/jira/browse/IGNITE-18316
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> Under IGNITE-18294 reusable waiters in heap lock manager have been done. Each
> waiter has a {{fut}} field, storing lock future, which is completed when
> waiter can be locked, converting all of its lock intentions into actual
> locks. Only one future for all intentions can exist, this means that it will
> be completed when supremum of all lock intentions can be acquired. As the
> lock mode for the waiter can be upgraded multiple times, lock future can be
> created several times for the waiter, rewriting {{fut}} field.
> Waiter's thread safety is provided by synchronized section on the mutex which
> is waiters collection for the key. Meanwhile, lock future should be completed
> outside of this mutex, as there may be long running tasks created for
> {{thenComplete}} of this future. These tasks must be done outside of the
> mutex, otherwise performance of the lock manager will be poor.
> Obviously, assuming that future field can be rewritten inside of mutex at any
> time, we can't complete it safely outside of mutex.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647090#comment-17647090 ] Andrey Mashenkov commented on IGNITE-17945: --- My point is "bulk loading" meaning is ambiguous without referencing to Ignite. As you wrote, user may see the message during "bulk loading", but it is not a real reason. In general, before the fix some users may mistakenly think 'JVM pause'='GC pause' e.g. because they are far from Java world. after the fix the same users may get confused with useless terms, which can't be even googled. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647079#comment-17647079 ] Maksim Timonin commented on IGNITE-17945: - [~zstan] [~amashenkov] Thanks for your comments! I've reverted the commit. The idea was to notify user that there are more options than only GC pauses. Maybe it's better to change the base message "Possible too long JVM pause", because it might be misleading due to options could be outside the JVM. Let's then discuss this message more carefully on devlist. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin reopened IGNITE-17945: - > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17271) Sort out sqlogic tests on Ignite 3
[
https://issues.apache.org/jira/browse/IGNITE-17271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-17271:
---
Assignee: Evgeny Stanilovsky
> Sort out sqlogic tests on Ignite 3
> --
>
> Key: IGNITE-17271
> URL: https://issues.apache.org/jira/browse/IGNITE-17271
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, tech-debt
>
> All the tests from the lists below are muted by rename {{}} ->
> {{_ignored}}.
> If the muted test already contains muted part (file {{_ignored}}
> already exists) the file is renamed to {{_ignored_old}}.
> Tests to investigate:
> *Implement: {{STRING_AGG}}*
> {code}
> sql/aggregate/aggregates/test_aggregate_types.test
> sql/aggregate/aggregates/test_distinct_string_agg.test
> sql/aggregate/aggregates/test_perfect_ht.test
> sql/aggregate/aggregates/test_string_agg.test
> sql/aggregate/aggregates/test_string_agg_big.test
> sql/aggregate/aggregates/test_string_agg_many_groups.test
> {code}
> *Metadata issue*
> {code}
> Caused by: java.lang.AssertionError: Unexpected type of result: NULL
> at
> org.apache.ignite.internal.sql.engine.util.TypeUtils.columnType(TypeUtils.java:343)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$resultSetMetadata$5(PrepareServiceImpl.java:271)
> at
> org.apache.ignite.internal.sql.engine.prepare.LazyResultSetMetadata.columns(LazyResultSetMetadata.java:43)
> at
> org.apache.ignite.internal.sql.script.SqlScriptRunner.lambda$sql$2(SqlScriptRunner.java:173)
> at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> {code}
> {code}
> sql/aggregate/aggregates/test_aggregate_types_scalar.test
> sql/aggregate/aggregates/test_avg.test
> sql/aggregate/aggregates/test_scalar_aggr.test
> sql/function/generic/test_nvl.test
> sql/function/numeric/test_truncate.test
> sql/function/string/test_caseconvert.test
> sql/function/string/test_initcap.test
> sql/function/string/test_left.test
> sql/function/string/test_repeat.test
> sql/function/string/test_replace.test
> sql/function/string/test_reverse.test
> sql/function/string/test_right.test
> sql/function/string/test_substring.test
> sql/function/string/test_trim.test
> sql/types/null/test_null.test
> {code}
> *Support INTERVAL TYPE*
> {code}
> sql/function/interval/test_extract.test
> sql/types/interval/test_interval_ops.test
> {code}
> *Unsorted / Not expected results*
> {code}
> sql/function/timestamp/test_extract.test
> sql/function/timestamp/test_extract_ms.test
> sql/function/timestamp/test_timestampadd.test
> sql/insert/test_insert_type.test
> sql/order/test_order_same_value.test_slow
> sql/types/blob/test_blob.test
> sql/types/blob/test_blob_function.test
> sql/types/blob/test_blob_operator.test
> sql/types/blob/test_blob_string.test
> sql/types/collections/array.test
> sql/types/collections/array.test
> sql/types/collections/array.test
> sql/types/collections/array.test
> sql/types/decimal/cast_from_decimal.test
> sql/types/decimal/cast_to_decimal.test
> sql/types/interval/interval_constants.test
> sql/types/interval/test_interval_addition.test
> sql/types/null/test_is_null.test
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647073#comment-17647073 ] Evgeny Stanilovsky edited comment on IGNITE-17945 at 12/14/22 12:32 PM: [~timonin.maksim] i think that logs are the part of API because they can be parsed using regexps and so on ... 1. what additional information you will give for customer if *or other JVM internal* *pauses* will be additionally appended ? 2. bulk loading, also if it present in docs, is just a non informative words, i don`t know who approves such a doc, but just think as a customer - what this words mean ??? 3. I also don`t know about hardware freezes, i think you talking about virtualization pauses, if it so - they also can`t be mention in this context without additional environment check. was (Author: zstan): [~timonin.maksim] i think that logs are the part of API because they can be parsed using regexps and so on ... 1. what additional information you will give for customer if *or other JVM internal* *pauses* will be additionally appended ? 2. bulk loading, also if it present in docs, is just a non informative words, i don`t kwon who approves such a doc, but just think as a customer - what this words mean ??? 3. I also don`t know about hardware freezes, i think you talking about virtualization pauses, if it so - they also can`t be mention in this context without additional environment check. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647073#comment-17647073 ] Evgeny Stanilovsky commented on IGNITE-17945: - [~timonin.maksim] i think that logs are the part of API because they can be parsed using regexps and so on ... 1. what additional information you will give for customer if *or other JVM internal* *pauses* will be additionally appended ? 2. bulk loading, also if it present in docs, is just a non informative words, i don`t kwon who approves such a doc, but just think as a customer - what this words mean ??? 3. I also don`t know about hardware freezes, i think you talking about virtualization pauses, if it so - they also can`t be mention in this context without additional environment check. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647071#comment-17647071 ] Julia Bakulina commented on IGNITE-17945: - [~amashenkov] Hi Andrey, bulk loading is stated in ignite apache docs as one of the reasons for JVM pauses "Occasionally you may see a warning message about the JVM being paused for too long. It can happen during bulk loading, for example". [https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting] > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647065#comment-17647065 ] Andrey Mashenkov commented on IGNITE-17945: --- Things that looks like "hanging outside the JVM" usually are bad thread/IO scheduling in the OS (due to priority, context switching+too much threads, external hypervisor scheduler), IO issues, system clock time jump, CPU throttling. I never heard about "hardware freeze", high frequency generator in CPU just works and CPU make a progress, what progress - depends on OS demands. What is "bulk loading"? How can one diagnosis "bulk loading" issue? > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647064#comment-17647064 ] Julia Bakulina commented on IGNITE-18348: - during IGNITE-17373 it became obvious that Ignite.active() is massively used while being deprecated since 2018 > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[
https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647061#comment-17647061
]
Maksim Timonin commented on IGNITE-17945:
-
[~zstan] hi! Thanks for participating in this ticket!
I think such fix can be implemented without discussion on the devlist. Because
the place, reason, message, log level, param dimension (milliseconds) don't
change. Then I suppose no public API changed. We're only going to add a minor
clarification.
But I agree with your comment about text message. I actually missed that
recursion. Is it better to change the message to
"Possible too long JVM pause. Possible reasons: GC *or other JVM internal*
{*}pauses{*}, hardware temporary freeze, bulk loading".
This message should notify user that GC is not an only reason for this pause.
WDYT?
> Change message in case watchdog thread observes freeze
> --
>
> Key: IGNITE-17945
> URL: https://issues.apache.org/jira/browse/IGNITE-17945
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitry Pavlov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In Long JVM pause detector we warn user that the thread wasn't alive for a
> threshold
> Possible too long JVM pause: 500+ milliseconds.
> But it is often treated as a GC pause.
> We can change that warning to
> Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware
> temporary freeze)
> To enlist possible reasons behind that behaviour
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18393) Sql. Broken aggregations accumulators for (var)binary types.
[
https://issues.apache.org/jira/browse/IGNITE-18393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18393:
Labels: ignite-3 (was: )
> Sql. Broken aggregations accumulators for (var)binary types.
>
>
> Key: IGNITE-18393
> URL: https://issues.apache.org/jira/browse/IGNITE-18393
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> No accumulators implemented for aggregators with (var)binary types
> {noformat}
> CREATE TABLE blobs (b varbinary, g INTEGER);
> INSERT INTO blobs VALUES (x'FFFEFB', 1);
> SELECT MIN(b) FROM blobs;
> {noformat}
>
> {noformat}
> Caused by: org.apache.ignite.sql.SqlException: IGN-SQL-26
> TraceId:06941fc6-3098-4fd3-a9f2-07f9a66fb317 Line 2, Column 125: Cannot cast
> "long" to "org.apache.calcite.avatica.util.ByteString"
> at
> org.apache.ignite.internal.sql.engine.util.Commons.compile(Commons.java:515)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.AccumulatorsFactory.compileCast(AccumulatorsFactory.java:128)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.agg.AccumulatorsFactory.cast0(AccumulatorsFactory.java:100){noformat}
> check:
> org.apache.ignite.internal.sql.engine.exec.exp.agg.Accumulators
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-12416) Avoid using deprecated the Ignite.active(boolean) methods in project
[ https://issues.apache.org/jira/browse/IGNITE-12416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev resolved IGNITE-12416. -- Resolution: Duplicate > Avoid using deprecated the Ignite.active(boolean) methods in project > > > Key: IGNITE-12416 > URL: https://issues.apache.org/jira/browse/IGNITE-12416 > Project: Ignite > Issue Type: Task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Minor > > IgniteCluster#active(boolean) should be used instead of Ignite#active(boolean) > IgniteCluster#active() should be used instead of Ignite#active() > Since IEP-4 was merged and deprecates cluster activation methods > Deprecated methods usages provide many warnings on the build project stage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18412) Sql. Use an alias that is identical to a column name - failed.
[
https://issues.apache.org/jira/browse/IGNITE-18412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18412:
Description:
1. Use an alias that is identical to a column name
(should prioritize column name):
{noformat}
CREATE TABLE integers(i INTEGER, j INTEGER);
INSERT INTO integers VALUES (3, 4), (3, 4), (2, 4);
# use an alias that is identical to a column name (should prioritize column
name)
query IR
SELECT 1 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 2;
1 2.00
1 6.00{noformat}
Error:
{noformat}
[expectedRows=2, actualRows=1, expected=[[1, 2.00], [1, 6.00]],
actual=[[1, 8]]]{noformat}
BTW PG with equivalent data returns:
{noformat}
1 2
1 6{noformat}
2. Column reference should have preference over alias reference in grouping
{noformat}
CREATE TABLE integers(i INTEGER);
INSERT INTO integers VALUES (1), (2), (3), (NULL);
SELECT i, i % 2 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 1 NULLS FIRST;
NULL NULL NULL
1 1 1.00
2 0 2.00
3 1 3.00
{noformat}
Caused by: org.apache.calcite.runtime.CalciteContextException: At line 1,
column 53: Column 'I' is ambiguous
was:
Use an alias that is identical to a column name
(should prioritize column name):
{noformat}
CREATE TABLE integers(i INTEGER, j INTEGER);
INSERT INTO integers VALUES (3, 4), (3, 4), (2, 4);
# use an alias that is identical to a column name (should prioritize column
name)
query IR
SELECT 1 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 2;
1 2.00
1 6.00{noformat}
Error:
{noformat}
[expectedRows=2, actualRows=1, expected=[[1, 2.00], [1, 6.00]],
actual=[[1, 8]]]{noformat}
BTW PG with equivalent data returns:
{noformat}
1 2
1 6{noformat}
> Sql. Use an alias that is identical to a column name - failed.
> --
>
> Key: IGNITE-18412
> URL: https://issues.apache.org/jira/browse/IGNITE-18412
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> 1. Use an alias that is identical to a column name
> (should prioritize column name):
> {noformat}
> CREATE TABLE integers(i INTEGER, j INTEGER);
> INSERT INTO integers VALUES (3, 4), (3, 4), (2, 4);
> # use an alias that is identical to a column name (should prioritize column
> name)
> query IR
> SELECT 1 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 2;
>
> 1 2.00
> 1 6.00{noformat}
> Error:
> {noformat}
> [expectedRows=2, actualRows=1, expected=[[1, 2.00], [1, 6.00]],
> actual=[[1, 8]]]{noformat}
> BTW PG with equivalent data returns:
> {noformat}
> 1 2
> 1 6{noformat}
>
> 2. Column reference should have preference over alias reference in grouping
>
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers VALUES (1), (2), (3), (NULL);
> SELECT i, i % 2 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 1 NULLS FIRST;
>
> NULL NULL NULL
> 1 1 1.00
> 2 0 2.00
> 3 1 3.00
> {noformat}
>
> Caused by: org.apache.calcite.runtime.CalciteContextException: At line 1,
> column 53: Column 'I' is ambiguous
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18347) .NET: B+Tree is corrupted when string value has emoticons
[
https://issues.apache.org/jira/browse/IGNITE-18347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647054#comment-17647054
]
Danut Radoaica commented on IGNITE-18347:
-
unfortunately I wasn't able to reproduce locally or in the develop env (also in
AKS), this are the unit test and the helper class:
{code:c#}
[TestMethod]
public void TestCacheFactoryPutThenGetAllPrintableChars()
{
IgniteClientConfiguration igniteClientConfiguration =
CacheFactory.GetIgniteClientConfiguration();
IIgniteClient igniteClient =
CacheFactory.ConnectAsClient(igniteClientConfiguration);
string cacheName = "LiveChatConversationAllPrintableChars";
ICacheClient cacheClient =
CacheFactory.GetOrCreateCacheClient(igniteClient,
cacheName, configuration =>
configuration.QueryEntities = new List()
{
new QueryEntity(typeof(Guid), typeof(LiveChatConversation))
{
Fields = new List()
{
new QueryField("Id", typeof(Guid))
},
Indexes = new List()
{
new QueryIndex("Id")
}
}
}).WithExpiryPolicy(new ExpiryPolicy(TimeSpan.FromDays(1),
TimeSpan.FromDays(1), TimeSpan.FromDays(1)));
// see: https://web.itu.edu.tr/~sgunduz/courses/mikroisl/ascii.html
for (int i = char.MinValue; i <= char.MaxValue; i++)
{
char c = Convert.ToChar(i);
if (!char.IsControl(c))
{
Guid id = Guid.NewGuid();
LiveChatConversation liveChatConversation = new() { Id =
id, HelpdeskSubject = $"{c}" };
cacheClient.Put(liveChatConversation.Id,
liveChatConversation);
liveChatConversation =
cacheClient.Get(liveChatConversation.Id);
Assert.IsNotNull(liveChatConversation);
}
}
igniteClient.DestroyCache(cacheName);
}
{code}
{code:c#}
public static class CacheFactory
{
public static IgniteClientConfiguration
GetIgniteClientConfiguration(string endpoint = "127.0.0.1",
string userName = null, string password = null, bool useSsl = false,
string certificatePath = null, string certificatePassword = null)
{
IgniteClientConfiguration igniteClientConfiguration = new()
{
Endpoints = new[] { endpoint },
RetryPolicy = new ClientRetryReadPolicy(),
RetryLimit = 5,
SocketTimeout = TimeSpan.FromSeconds(30),
EnablePartitionAwareness = true,
EnableHeartbeats = true,
// Enable trace logging to observe discovery process.
Logger = new ConsoleLogger { MinLevel = LogLevel.Trace }
};
if (!string.IsNullOrWhiteSpace(userName))
{
igniteClientConfiguration.UserName = userName;
}
if (!string.IsNullOrWhiteSpace(password))
{
igniteClientConfiguration.Password = password;
}
if (useSsl)
{
igniteClientConfiguration.SslStreamFactory = new
SslStreamFactory
{
CertificatePath = certificatePath,
CertificatePassword = certificatePassword,
CheckCertificateRevocation = true,
SkipServerCertificateValidation = true,
SslProtocols = SslProtocols.Tls12
};
}
return igniteClientConfiguration;
}
public static IIgnite ConnectAsClient(IgniteConfiguration
igniteConfiguration)
{
Ignition.ClientMode = true;
return Ignition.Start(igniteConfiguration);
}
public static IIgniteClient ConnectAsClient(IgniteClientConfiguration
igniteClientConfiguration)
{
return Ignition.StartClient(igniteClientConfiguration);
}
public static ICache GetOrCreateCache(IIgnite
ignite, string cacheName,
Action extendConfigurationAction = null)
{
CacheConfiguration cacheCfg = new()
{
Name = cacheName,
CacheMode = CacheMode.Partitioned,
GroupName = typeof(TData).FullNameWithoutAssemblyInfo(),
QueryEntities = new[] { new QueryEntity { KeyType =
typeof(TKey), ValueType = typeof(TData) } },
Backups = 1,
PlatformCacheConfiguration = new PlatformCacheConfiguration
{
KeyTypeName = typeof(TKey).F
[jira] [Commented] (IGNITE-18043) Replaceable deadlock prevention mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647050#comment-17647050 ] Denis Chudov commented on IGNITE-18043: --- [~Sergey Uttsel] could you pls review the changes? > Replaceable deadlock prevention mechanism > - > > Key: IGNITE-18043 > URL: https://issues.apache.org/jira/browse/IGNITE-18043 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation:* > We have an embedded deadlock prevention strategy (presently, it is > _Wait-Die_). Although, [the original > paper|https://dl.acm.org/doi/pdf/10.1145/320251.320260] about deadlock > prevention contains another two strategies: _priorities_ and _Wound-Wait_. > Also, the mechanism should give a possibility to not use any strategy to > prevent deadlock. > All told, above shows we need to separate the prevention strategy in dedicate > interface (which even has one implementation _Wait-Die_). Another > implementation will be released by necessary. > *Definition of Done:* > A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to > interface, which parametrizes _LockManager_. Wait-Die strategy > (_WaitDieLockResolutionStrategy_) will be the only one implementation of > _ResolutionStrategy_. > _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18043) Replaceable deadlock prevention mechanism
[ https://issues.apache.org/jira/browse/IGNITE-18043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-18043: -- Reviewer: Sergey Uttsel > Replaceable deadlock prevention mechanism > - > > Key: IGNITE-18043 > URL: https://issues.apache.org/jira/browse/IGNITE-18043 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Motivation:* > We have an embedded deadlock prevention strategy (presently, it is > _Wait-Die_). Although, [the original > paper|https://dl.acm.org/doi/pdf/10.1145/320251.320260] about deadlock > prevention contains another two strategies: _priorities_ and _Wound-Wait_. > Also, the mechanism should give a possibility to not use any strategy to > prevent deadlock. > All told, above shows we need to separate the prevention strategy in dedicate > interface (which even has one implementation _Wait-Die_). Another > implementation will be released by necessary. > *Definition of Done:* > A deadlock resolution strategy (_ResolutionStrategy_) has to be extracted to > interface, which parametrizes _LockManager_. Wait-Die strategy > (_WaitDieLockResolutionStrategy_) will be the only one implementation of > _ResolutionStrategy_. > _HeapLockManager_ should be parametrized by _WaitDieLockResolutionStrategy_. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18412) Sql. Use an alias that is identical to a column name - failed.
Evgeny Stanilovsky created IGNITE-18412:
---
Summary: Sql. Use an alias that is identical to a column name -
failed.
Key: IGNITE-18412
URL: https://issues.apache.org/jira/browse/IGNITE-18412
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Use an alias that is identical to a column name
(should prioritize column name):
{noformat}
CREATE TABLE integers(i INTEGER, j INTEGER);
INSERT INTO integers VALUES (3, 4), (3, 4), (2, 4);
# use an alias that is identical to a column name (should prioritize column
name)
query IR
SELECT 1 AS i, SUM(i) FROM integers GROUP BY i ORDER BY 2;
1 2.00
1 6.00{noformat}
Error:
{noformat}
[expectedRows=2, actualRows=1, expected=[[1, 2.00], [1, 6.00]],
actual=[[1, 8]]]{noformat}
BTW PG with equivalent data returns:
{noformat}
1 2
1 6{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17167) Simplify the configuration asm generator
[ https://issues.apache.org/jira/browse/IGNITE-17167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647048#comment-17647048 ] Roman Puchkovskiy commented on IGNITE-17167: The patch looks good to me > Simplify the configuration asm generator > > > Key: IGNITE-17167 > URL: https://issues.apache.org/jira/browse/IGNITE-17167 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3, technical-debt > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > At the moment, the > *org.apache.ignite.internal.configuration.asm.ConfigurationAsmGenerator* > looks complicated due to the addition of internal, polymorphic and abstract > configuration, the code has become harder to read and edit. > It is proposed to think about how and to divide this class into methods or > subclasses for each type of configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647043#comment-17647043 ] Evgeny Stanilovsky commented on IGNITE-17945: - I suppose that logs are the part of public API and discussion in dev list is required. Also i think that : "Possible too long JVM pause ... Possible reasons: ... other JVM pauses" looks like recursive confusion ) > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647034#comment-17647034 ] Julia Bakulina commented on IGNITE-17945: - [~timonin.maksim] thank you for the review! > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
[ https://issues.apache.org/jira/browse/IGNITE-18354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-18354: --- Assignee: Julia Bakulina > Update apache ignite docs to replace deprecated info from Ignite.active() to > Ignite.cluster().state(ClusterState.ACTIVE) > > > Key: IGNITE-18354 > URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > > Currently, some classes contain outdated ignite apache docs info re > Ignite.active() and Ignite.active(boolean active). active() and > active(boolean active) are deprecated since 2018 thus the docs throughout the > project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18350) Redesign two collections of lock modes to a bitset into the heap lock manager
[
https://issues.apache.org/jira/browse/IGNITE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18350:
--
Description:
We have two collections, those store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for convenient way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
Also, using bit masks should limit the count of locks that one transaction can
hold on one key. This number of locks should be reasonable, but currently we
take intention locks (IS and IX) on tables and indexes on each call of get/put,
so count of locks per transaction per key (in this case, key is a table or an
index) may reach big numbers depending on a query.
was:
We have two collections, those store lock modes:
{code}
HeapLockManager.WaiterImpl#locks
HeapLockManager.WaiterImpl#intendedLocks
{code}
That is done for convenient way to implement all lock manager requirement. But
for optimization, we can do this through _BitSet_. The redesign is possible
because we have predefined lock modes (_LockMode_) and attempts to accesses to
the modes are bounded. The amount of attempts significantly less than MaxInt
value.
The optimization allows using less memory for lock on each entry.
> Redesign two collections of lock modes to a bitset into the heap lock manager
> -
>
> Key: IGNITE-18350
> URL: https://issues.apache.org/jira/browse/IGNITE-18350
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have two collections, those store lock modes:
> {code}
> HeapLockManager.WaiterImpl#locks
> HeapLockManager.WaiterImpl#intendedLocks
> {code}
> That is done for convenient way to implement all lock manager requirement.
> But for optimization, we can do this through _BitSet_. The redesign is
> possible because we have predefined lock modes (_LockMode_) and attempts to
> accesses to the modes are bounded. The amount of attempts significantly less
> than MaxInt value.
> The optimization allows using less memory for lock on each entry.
> Also, using bit masks should limit the count of locks that one transaction
> can hold on one key. This number of locks should be reasonable, but currently
> we take intention locks (IS and IX) on tables and indexes on each call of
> get/put, so count of locks per transaction per key (in this case, key is a
> table or an index) may reach big numbers depending on a query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18374) Remove RaftManager#prepareRaftGroup method
[
https://issues.apache.org/jira/browse/IGNITE-18374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-18374:
---
Issue Type: Improvement (was: Task)
> Remove RaftManager#prepareRaftGroup method
> --
>
> Key: IGNITE-18374
> URL: https://issues.apache.org/jira/browse/IGNITE-18374
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{RaftManager#prepareRaftGroup}} method does two things: starts a Raft
> service and, optionally, starts a Raft node. We already have two separate
> methods that do these things: {{startRaftNode}} and {{startRaftService}}. We
> should remove {{prepareRaftGroup}} method and replace it with these two
> methods.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18262) .NET: Missing files and broken examples in binary release zip package
[ https://issues.apache.org/jira/browse/IGNITE-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18262: Release Note: .NET: Fixed missing dlls in release package > .NET: Missing files and broken examples in binary release zip package > - > > Key: IGNITE-18262 > URL: https://issues.apache.org/jira/browse/IGNITE-18262 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Issues in binary distribution > (https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip): > * *platforms/dotnet/bin* contains *netcoreapp3.1* directory, even though we > are on .NET 6 now > * LINQ and other binaries are missing in *netcoreapp3.1* directory > * Examples do not work correctly because they expect > *\bin\Apache.Ignite.Core.dll* in *Directory.Build.props* - as a result, > latest NuGet package is used instead of dlls from the parent dir. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18262) .NET: Missing files and broken examples in binary release zip package
[ https://issues.apache.org/jira/browse/IGNITE-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18262: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > .NET: Missing files and broken examples in binary release zip package > - > > Key: IGNITE-18262 > URL: https://issues.apache.org/jira/browse/IGNITE-18262 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Issues in binary distribution > (https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip): > * *platforms/dotnet/bin* contains *netcoreapp3.1* directory, even though we > are on .NET 6 now > * LINQ and other binaries are missing in *netcoreapp3.1* directory > * Examples do not work correctly because they expect > *\bin\Apache.Ignite.Core.dll* in *Directory.Build.props* - as a result, > latest NuGet package is used instead of dlls from the parent dir. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18262) .NET: Missing files and broken examples in binary release zip package
[ https://issues.apache.org/jira/browse/IGNITE-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647015#comment-17647015 ] Pavel Tupitsyn commented on IGNITE-18262: - Merged to master: ce9b211d349461b2ab1e4dff8891ee95064f21cf > .NET: Missing files and broken examples in binary release zip package > - > > Key: IGNITE-18262 > URL: https://issues.apache.org/jira/browse/IGNITE-18262 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Issues in binary distribution > (https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip): > * *platforms/dotnet/bin* contains *netcoreapp3.1* directory, even though we > are on .NET 6 now > * LINQ and other binaries are missing in *netcoreapp3.1* directory > * Examples do not work correctly because they expect > *\bin\Apache.Ignite.Core.dll* in *Directory.Build.props* - as a result, > latest NuGet package is used instead of dlls from the parent dir. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18262) .NET: Missing files and broken examples in binary release zip package
[ https://issues.apache.org/jira/browse/IGNITE-18262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647006#comment-17647006 ] Igor Sapego commented on IGNITE-18262: -- Looks good to me. > .NET: Missing files and broken examples in binary release zip package > - > > Key: IGNITE-18262 > URL: https://issues.apache.org/jira/browse/IGNITE-18262 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Issues in binary distribution > (https://dlcdn.apache.org/ignite/2.14.0/apache-ignite-2.14.0-bin.zip): > * *platforms/dotnet/bin* contains *netcoreapp3.1* directory, even though we > are on .NET 6 now > * LINQ and other binaries are missing in *netcoreapp3.1* directory > * Examples do not work correctly because they expect > *\bin\Apache.Ignite.Core.dll* in *Directory.Build.props* - as a result, > latest NuGet package is used instead of dlls from the parent dir. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18411) Threads left after wrong SQL query
Alexander Belyak created IGNITE-18411:
-
Summary: Threads left after wrong SQL query
Key: IGNITE-18411
URL: https://issues.apache.org/jira/browse/IGNITE-18411
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 3.0.0-beta1
Reporter: Alexander Belyak
After simple test
{code:java}
public static void main(String[] args) {
try (IgniteClient client =
IgniteClient.builder().addresses("127.0.0.1:10800").build()) {
try (Session ses = client.sql().createSession()) {
try (ResultSet rs = ses.execute(null,
"SELECT id, salary, key, balance from wrongName ORDER BY
id")) {
System.out.println("SELECT DONE");
}
}
System.out.println("WORK");
} catch (Exception e) {
throw new RuntimeException(e);
}
System.out.println("DONE");
} {code}
JVM still running because of nio threads:
{noformat}
Full thread dump"nioEventLoopGroup-2-1" #14 prio=10 os_prio=0 cpu=73,59ms
elapsed=15,92s tid=0x7f8d5ca78800 nid=0xb584b runnable [0x7f8cdbdfa000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPoll.wait(java.base@11.0.17/Native Method)
at
sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.17/EPollSelectorImpl.java:120)
at
sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.17/SelectorImpl.java:124)
- locked <0x0006a4b640f0> (a
io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x0006a4b2d7c0> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(java.base@11.0.17/SelectorImpl.java:141)
at
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
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.lang.Thread.run(java.base@11.0.17/Thread.java:829)
"main" #1 prio=5 os_prio=0 cpu=551,01ms elapsed=16,46s tid=0x7f8d5c01a000
nid=0xb5832 waiting on condition [0x7f8d62e63000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.17/Native Method)
- parking to wait for <0x0006a2a92ce8> (a
java.util.concurrent.CompletableFuture$Signaller)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.17/LockSupport.java:194)
at
java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.17/CompletableFuture.java:1796)
at
java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.17/ForkJoinPool.java:3128)
at
java.util.concurrent.CompletableFuture.waitingGet(java.base@11.0.17/CompletableFuture.java:1823)
at
java.util.concurrent.CompletableFuture.join(java.base@11.0.17/CompletableFuture.java:2043)
at org.apache.ignite.sql.Session.execute(Session.java:58)
at org.apache.ignite.example.table.Check.main(Check.java:19)
"Common-Cleaner" #11 daemon prio=8 os_prio=0 cpu=0,28ms elapsed=16,39s
tid=0x7f8d5c320800 nid=0xb5840 in Object.wait() [0x7f8d309d7000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.17/Native Method)
- waiting on <0x0006a37015f0> (a java.lang.ref.ReferenceQueue$Lock)
at
java.lang.ref.ReferenceQueue.remove(java.base@11.0.17/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0x0006a37015f0> (a
java.lang.ref.ReferenceQueue$Lock)
at jdk.internal.ref.CleanerImpl.run(java.base@11.0.17/CleanerImpl.java:148)
at java.lang.Thread.run(java.base@11.0.17/Thread.java:829)
at
jdk.internal.misc.InnocuousThread.run(java.base@11.0.17/InnocuousThread.java:161)
"tcp-client-channel-heartbeats-785447854" #15 prio=5 os_prio=0 cpu=0,12ms
elapsed=15,86s tid=0x7f8d5ca89000 nid=0xb584d in Object.wait()
[0x7f8cdb4f8000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.17/Native Method)
- waiting on <0x0006a2b26828> (a java.util.TaskQueue)
at java.util.TimerThread.mainLoop(java.base@11.0.17/Timer.java:553)
- waiting to re-lock in wait() <0x0006a2b26828> (a java.util.TaskQueue)
at java.util.TimerThread.run(java.base@11.0.17/Timer.java:506)
"ForkJoinPool.commonPool-worker-3" #16 daemon prio=5 os_prio=0 cpu=0,37ms
elapsed=15,85s tid=0x7f8d5ca8e800 nid=0xb584e waiting on condition
[0x7f8cdb3f8000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.17/Native Method)
- parking to wait for <0x0006a46ff8c0> (a
java.util.concurrent.ForkJoinPool)
at
java.util.co
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Release Note: Fixed an exception message for "Possible too long JVM pause". Now the exception thrown is extended and includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses. (was: Fixed an exception message for Possible too long JVM pause. Now the exception thrown includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses.) > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Release Note: Fixed an exception message for Possible too long JVM pause. Now the exception thrown includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18410) Put data to metastorage during some components start leads to assertion error
Mirza Aliev created IGNITE-18410:
Summary: Put data to metastorage during some components start
leads to assertion error
Key: IGNITE-18410
URL: https://issues.apache.org/jira/browse/IGNITE-18410
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
When we was developing https://issues.apache.org/jira/browse/IGNITE-18087 some
tests on restart started to fail on the assertion
{code:java}
assert rev >= appliedRevision : IgniteStringFormatter.format(
{code}
in {{ConfigurationCatchUpListener}}.
It means that we have inconsistency when we compare storage revision from
configuration and revision from the event. Needed to investigate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18409) Threads left after connection refused
Alexander Belyak created IGNITE-18409:
-
Summary: Threads left after connection refused
Key: IGNITE-18409
URL: https://issues.apache.org/jira/browse/IGNITE-18409
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 3.0.0-beta1
Reporter: Alexander Belyak
Simple test
{code:java}
public static void main(String[] args) {
try (IgniteClient client =
IgniteClient.builder().addresses("127.0.0.1:10800").build()) {
System.out.println("WORK");
} catch (Exception e) {
throw new RuntimeException(e);
}
System.out.println("DONE");
}{code}
left JVM running because if a few nio thread still running:
{noformat}
Full thread dump"nioEventLoopGroup-2-1" #14 prio=10 os_prio=0 cpu=13,72ms
elapsed=62,20s tid=0x7f7870a8b800 nid=0xb4834 runnable [0x7f783d0ee000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPoll.wait(java.base@11.0.17/Native Method)
at
sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.17/EPollSelectorImpl.java:120)
at
sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.17/SelectorImpl.java:124)
- locked <0x0006a4cfecc8> (a
io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x0006a4cd00d8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(java.base@11.0.17/SelectorImpl.java:141)
at
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
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.lang.Thread.run(java.base@11.0.17/Thread.java:829)
"nioEventLoopGroup-2-2" #15 prio=10 os_prio=0 cpu=0,89ms elapsed=62,14s
tid=0x7f7870ace000 nid=0xb4835 runnable [0x7f783cfee000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPoll.wait(java.base@11.0.17/Native Method)
at
sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.17/EPollSelectorImpl.java:120)
at
sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.17/SelectorImpl.java:124)
- locked <0x0006a4b31f90> (a
io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x0006a4b31d68> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(java.base@11.0.17/SelectorImpl.java:141)
at
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
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.lang.Thread.run(java.base@11.0.17/Thread.java:829)
"nioEventLoopGroup-2-3" #16 prio=10 os_prio=0 cpu=0,59ms elapsed=62,13s
tid=0x7f7870acf000 nid=0xb4836 runnable [0x7f783ceee000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPoll.wait(java.base@11.0.17/Native Method)
at
sun.nio.ch.EPollSelectorImpl.doSelect(java.base@11.0.17/EPollSelectorImpl.java:120)
at
sun.nio.ch.SelectorImpl.lockAndDoSelect(java.base@11.0.17/SelectorImpl.java:124)
- locked <0x0006a4b358f0> (a
io.netty.channel.nio.SelectedSelectionKeySet)
- locked <0x0006a4b356c8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(java.base@11.0.17/SelectorImpl.java:141)
at
io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:68)
at io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:813)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:460)
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.lang.Thread.run(java.base@11.0.17/Thread.java:829)
"Common-Cleaner" #11 daemon prio=8 os_prio=0 cpu=0,34ms elapsed=62,62s
tid=0x7f7870340800 nid=0xb4828 in Object.wait() [0x7f783dcfe000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.17/Native Method)
- waiting on <0x0006a37048f8> (a java.lang.ref.ReferenceQueue$Lock)
at
java.lang.ref.ReferenceQueue.remove(java.base@11.0.17/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0x0006a37048f8>
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[
https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17646988#comment-17646988
]
Ignite TC Bot commented on IGNITE-17945:
{panel:title=Branch: [pull/10434/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10434/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6955579&buildTypeId=IgniteTests24Java8_RunAll]
> Change message in case watchdog thread observes freeze
> --
>
> Key: IGNITE-17945
> URL: https://issues.apache.org/jira/browse/IGNITE-17945
> Project: Ignite
> Issue Type: Improvement
>Reporter: Dmitry Pavlov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Fix For: 2.15
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In Long JVM pause detector we warn user that the thread wasn't alive for a
> threshold
> Possible too long JVM pause: 500+ milliseconds.
> But it is often treated as a GC pause.
> We can change that warning to
> Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware
> temporary freeze)
> To enlist possible reasons behind that behaviour
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18408) Store replication protocol config as bytes in MvPartitionStorage
Roman Puchkovskiy created IGNITE-18408:
--
Summary: Store replication protocol config as bytes in
MvPartitionStorage
Key: IGNITE-18408
URL: https://issues.apache.org/jira/browse/IGNITE-18408
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
Fix For: 3.0.0-beta2
Currently, each {{MvPartitionStorage}} implementation serializes the config
object itself. This serialization should be made outside, the storage should
only store the serialization results (as bytes).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
