[jira] [Updated] (IGNITE-13700) More complex investigation of ConcurrentModificationException on node join.
[ https://issues.apache.org/jira/browse/IGNITE-13700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-13700: -- Summary: More complex investigation of ConcurrentModificationException on node join. (was: ConcurrentModificationException on node join.) > More complex investigation of ConcurrentModificationException on node join. > --- > > Key: IGNITE-13700 > URL: https://issues.apache.org/jira/browse/IGNITE-13700 > Project: Ignite > Issue Type: Bug >Reporter: Konstantin Sirotkin >Assignee: Konstantin Sirotkin >Priority: Minor > > This issue was created for more complex investigation of problem IGNITE-13554. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13694) Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch
[ https://issues.apache.org/jira/browse/IGNITE-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231212#comment-17231212 ] Anton Vinogradov commented on IGNITE-13694: --- Merged to ignite-ducktape > Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch > --- > > Key: IGNITE-13694 > URL: https://issues.apache.org/jira/browse/IGNITE-13694 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: IEP-56, ducktape > Time Spent: 0.5h > Remaining Estimate: 0h > > Latency drop(s) should be compared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13636) ODBC driver assigns SQL_BINARY type to DATE fields
[
https://issues.apache.org/jira/browse/IGNITE-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231211#comment-17231211
]
Pavel Tupitsyn commented on IGNITE-13636:
-
[~isapego] looks good to me
> ODBC driver assigns SQL_BINARY type to DATE fields
> --
>
> Key: IGNITE-13636
> URL: https://issues.apache.org/jira/browse/IGNITE-13636
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.9
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> "The DATE types should not be reported as SQL_BINARY. They should be returned
> as SQL_DATE"
> {noformat}
> DATE_FIELD DataType SQL_BINARY, DecimalDigits 0, Nullable 2, ColumnSize 10,
> UnsignedNumber 1, is_output_column
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13636) ODBC driver assigns SQL_BINARY type to DATE fields
[
https://issues.apache.org/jira/browse/IGNITE-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231179#comment-17231179
]
Ignite TC Bot commented on IGNITE-13636:
{panel:title=Branch: [pull/8453/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8453/head] Base: [master] : New Tests
(1974)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
948|https://ci.ignite.apache.org/viewLog.html?buildId=5731779]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr -
PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToLong - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToTiny - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText
- PASSED{color}
... and 937 new tests
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
970|https://ci.ignite.apache.org/viewLog.html?buildId=5731483]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForHost - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForOldest -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForRandom -
PASSED{color}
... and 959 new tests
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=5731477]]
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeCurdate - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsIs -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDateLegacy
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite:
TestFetchFieldDateAsDateLegacy - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeLiteral - PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestTimeTypeColumnAttributeLiteral - PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeField - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralTime -
PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestTimeTypeColumnAttributeField - PASSED{color}
... and 3 new tests
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
14|https://ci.ignite.apache.org/viewLog.html?buildId=5731484]]
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeCurdate - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsIs -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDateLegacy
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite:
TestFetchFieldDateAsDateLegacy - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeLiteral - PASSED{color}
*
[jira] [Commented] (IGNITE-13636) ODBC driver assigns SQL_BINARY type to DATE fields
[
https://issues.apache.org/jira/browse/IGNITE-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230947#comment-17230947
]
Ignite TC Bot commented on IGNITE-13636:
{panel:title=Branch: [pull/8453/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 / Debug){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5731476]]
* IgniteCoreTest: CacheTestSuite: TestRemoveAllKeys - History for base branch
is absent.
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLDriverConnect - New test
duration 100s is more that 1 minute
{panel}
{panel:title=Branch: [pull/8453/head] Base: [master] : New Tests
(1982)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
948|https://ci.ignite.apache.org/viewLog.html?buildId=5731476]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr -
PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToLong - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToTiny - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText
- PASSED{color}
... and 937 new tests
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
970|https://ci.ignite.apache.org/viewLog.html?buildId=5731483]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForHost - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForOldest -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForRandom -
PASSED{color}
... and 959 new tests
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=5731477]]
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeCurdate - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsIs -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDateLegacy
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite:
TestFetchFieldDateAsDateLegacy - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsDate -
PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeLiteral - PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestTimeTypeColumnAttributeLiteral - PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeField - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralTime -
PASSED{color}
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestTimeTypeColumnAttributeField - PASSED{color}
... and 5 new tests
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=5731484]]
* {color:#013220}IgniteOdbcTest: MetaQueriesTestSuite:
TestDateTypeColumnAttributeCurdate - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchFieldDateAsIs -
PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDateLegacy
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlTypesTestSuite: TestFetchLiteralDate -
PASSED{color}
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Simple example on my ordinary Mac having WiFi, VPN and docker (from Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, /127.0.0.1, /10.11.220.206]`. It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. And actual failure detection and connection restoring delay is: `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is usually unexpectable. This peculiarity was unearthed in [1], [2] and additionally confirmed in ducktape integration test [3]. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this setting and allow node to activate all available IPs. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. [1] https://issues.apache.org/jira/browse/IGNITE-13012 [2] https://issues.apache.org/jira/browse/IGNITE-13134 [3] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Simple example on my ordinary Mac having WiFi, VPN and docker (from Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, /127.0.0.1, /192.168.1.42]`. It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. And actual failure detection and connection restoring delay is: `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is usually unexpectable. This peculiarity was unearthed in [1], [2] and additionally confirmed in ducktape integration test [3]. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this setting and allow node to activate all available IPs. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. [1] https://issues.apache.org/jira/browse/IGNITE-13012 [2] https://issues.apache.org/jira/browse/IGNITE-13134 [3] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /10.11.220.206]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This peculiarity was unearthed in
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Simple example on my ordinary Mac having WiFi, VPN and docker (from Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, /127.0.0.1, /192.168.1.42, /10.11.220.206]`. It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. And actual failure detection and connection restoring delay is: `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is usually unexpectable. This peculiarity was unearthed in [1], [2] and additionally confirmed in ducktape integration test [3]. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this setting and allow node to activate all available IPs. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. [1] https://issues.apache.org/jira/browse/IGNITE-13012 [2] https://issues.apache.org/jira/browse/IGNITE-13134 [3] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Simple example on my ordinary Mac having WiFi, VPN and docker (from Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, /127.0.0.1, /10.11.220.206]`. It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. And actual failure detection and connection restoring delay is: `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is usually unexpectable. This peculiarity was unearthed in [1], [2] and additionally confirmed in ducktape integration test [3]. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this setting and allow node to activate all available IPs. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. [1] https://issues.apache.org/jira/browse/IGNITE-13012 [2] https://issues.apache.org/jira/browse/IGNITE-13134 [3] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /192.168.1.42, /10.11.220.206]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This
[jira] [Assigned] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13663: - Assignee: Denis A. Magda (was: Vladimir Steshin) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /192.168.1.42]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This peculiarity was unearthed in [1], [2] and > additionally confirmed in ducktape integration test [3]. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this > setting and allow node to activate all available IPs. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. > [1] https://issues.apache.org/jira/browse/IGNITE-13012 > [2] https://issues.apache.org/jira/browse/IGNITE-13134 > [3] > https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13663: - Assignee: Vladimir Steshin (was: Denis A. Magda) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /192.168.1.42]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This peculiarity was unearthed in [1], [2] and > additionally confirmed in ducktape integration test [3]. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this > setting and allow node to activate all available IPs. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. > [1] https://issues.apache.org/jira/browse/IGNITE-13012 > [2] https://issues.apache.org/jira/browse/IGNITE-13134 > [3] > https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13663: - Assignee: Denis A. Magda (was: Vladimir Steshin) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /192.168.1.42]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This peculiarity was unearthed in [1], [2] and > additionally confirmed in ducktape integration test [3]. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this > setting and allow node to activate all available IPs. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. > [1] https://issues.apache.org/jira/browse/IGNITE-13012 > [2] https://issues.apache.org/jira/browse/IGNITE-13134 > [3] > https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Simple example on my ordinary Mac having WiFi, VPN and docker (from Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, /127.0.0.1, /192.168.1.42]`. It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. And actual failure detection and connection restoring delay is: `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is usually unexpectable. This peculiarity was unearthed in [1], [2] and additionally confirmed in ducktape integration test [3]. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this setting and allow node to activate all available IPs. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. [1] https://issues.apache.org/jira/browse/IGNITE-13012 [2] https://issues.apache.org/jira/browse/IGNITE-13134 [3] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. Which is usually unexpectable. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. However, users frequently skip this setting and allow node to activate all available IPs > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Simple example on my ordinary Mac having WiFi, VPN and docker (from > Ignite log): `Local node addresses: [192.168.1.42/0:0:0:0:0:0:0:1%lo0, > /127.0.0.1, /192.168.1.42]`. > It is cleary seen that `ServerImpl.TcpServer.srvrSock` binds to '0.0.0.0'. > And actual failure detection and connection restoring delay is: > `failureDetectionTimeout * addresses_number + connRecoveryTimeout`. Which is > usually unexpectable. This peculiarity was unearthed in [1], [2] and > additionally confirmed in ducktape integration test [3]. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. Unfortunately, users frequently skip this > setting and allow node to activate all available IPs. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially.
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Not first non-loopback addresses as the documentation says. Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. Which is usually unexpectable. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. However, users frequently skip this setting and allow node to activate all available IPs was: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. > By default, all available addresses are assigned to node and node listens any > address (0.0.0.0). Not first non-loopback addresses as the documentation > says. Actual failure detection delay of this node is: > `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. Which is > usually unexpectable. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. However, users frequently skip this setting and allow > node to activate all available IPs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13637) ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one
[
https://issues.apache.org/jira/browse/IGNITE-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230812#comment-17230812
]
Ignite TC Bot commented on IGNITE-13637:
{panel:title=Branch: [pull/8403/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8403/head] Base: [master] : New Tests
(1898)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
956|https://ci.ignite.apache.org/viewLog.html?buildId=5730539]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForHost - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForOldest -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForRandom -
PASSED{color}
... and 945 new tests
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
934|https://ci.ignite.apache.org/viewLog.html?buildId=5730532]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr -
PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToLong - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToTiny - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText
- PASSED{color}
... and 923 new tests
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5730801]]
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingColumnWise - PASSED{color}
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingRowWise - PASSED{color}
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5730799]]
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingColumnWise - PASSED{color}
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingRowWise - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5730538]]
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingColumnWise - PASSED{color}
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingRowWise - PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5730537]]
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingColumnWise - PASSED{color}
* {color:#013220}IgniteOdbcTest: CursorBindingTestSuite:
TestCursorBindingRowWise - PASSED{color}
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5730541buildTypeId=IgniteTests24Java8_RunCpp]
> ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one
> -
>
> Key: IGNITE-13637
> URL: https://issues.apache.org/jira/browse/IGNITE-13637
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.9
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, we only support fetching of result set one by one. Implement
>
[jira] [Assigned] (IGNITE-13702) Fix description of soLinger for DiscoveryTcpSpi.
[ https://issues.apache.org/jira/browse/IGNITE-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13702: - Assignee: Denis A. Magda (was: Vladimir Steshin) > Fix description of soLinger for DiscoveryTcpSpi. > > > Key: IGNITE-13702 > URL: https://issues.apache.org/jira/browse/IGNITE-13702 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.10 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Minor > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix description of soLibger for DiscoveryTcpSpi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13702) Fix description of soLinger for DiscoveryTcpSpi.
[ https://issues.apache.org/jira/browse/IGNITE-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13702: -- Summary: Fix description of soLinger for DiscoveryTcpSpi. (was: Fix description of soLibger for DiscoveryTcpSpi.) > Fix description of soLinger for DiscoveryTcpSpi. > > > Key: IGNITE-13702 > URL: https://issues.apache.org/jira/browse/IGNITE-13702 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.10 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.10 > > > Fix description of soLibger for DiscoveryTcpSpi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13655) Implement readiness probe REST endpoint
[ https://issues.apache.org/jira/browse/IGNITE-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230753#comment-17230753 ] Stanislav Lukyanov commented on IGNITE-13655: - LGTM > Implement readiness probe REST endpoint > --- > > Key: IGNITE-13655 > URL: https://issues.apache.org/jira/browse/IGNITE-13655 > Project: Ignite > Issue Type: New Feature > Components: rest >Affects Versions: 2.9.1 >Reporter: Alexander Korenshteyn >Assignee: Alexander Korenshteyn >Priority: Major > Fix For: 2.9.1 > > Time Spent: 50m > Remaining Estimate: 0h > > Create a REST command (PROBE) which returns a success code (200) if kernal > has fully started > and 503 otherwise > > implemented by attaching to the join future. > It looks pretty similar to warmup machinery (in terms of implementation). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13655) Implement readiness probe REST endpoint
[
https://issues.apache.org/jira/browse/IGNITE-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230751#comment-17230751
]
Ignite TC Bot commented on IGNITE-13655:
{panel:title=Branch: [pull/8417/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5726060]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySegmentationAndConnectionRestoreTest.testConnectionRestore_NonCoordinator1
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Basic 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5726064]]
{color:#d04437}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5726096]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueEntryMoveSelfTest.testQueue - Test has low fail rate
in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8417/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Java Client{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5726042]]
* {color:#013220}IgniteClientTestSuite:
GridProbeCommandTest.testRestProbeCommand - PASSED{color}
* {color:#013220}IgniteClientTestSuite:
GridProbeCommandTest.testRestProbeCommandGridStarted - PASSED{color}
* {color:#013220}IgniteClientTestSuite:
GridProbeCommandTest.testRestProbeCommandGridNotStarted - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5726141buildTypeId=IgniteTests24Java8_RunAll]
> Implement readiness probe REST endpoint
> ---
>
> Key: IGNITE-13655
> URL: https://issues.apache.org/jira/browse/IGNITE-13655
> Project: Ignite
> Issue Type: New Feature
> Components: rest
>Affects Versions: 2.9.1
>Reporter: Alexander Korenshteyn
>Assignee: Alexander Korenshteyn
>Priority: Major
> Fix For: 2.9.1
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Create a REST command (PROBE) which returns a success code (200) if kernal
> has fully started
> and 503 otherwise
>
> implemented by attaching to the join future.
> It looks pretty similar to warmup machinery (in terms of implementation).
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13702) Fix description of soLibger for DiscoveryTcpSpi.
Vladimir Steshin created IGNITE-13702: - Summary: Fix description of soLibger for DiscoveryTcpSpi. Key: IGNITE-13702 URL: https://issues.apache.org/jira/browse/IGNITE-13702 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 2.10 Reporter: Vladimir Steshin Assignee: Vladimir Steshin Fix For: 2.10 Fix description of soLibger for DiscoveryTcpSpi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13697) Control.sh API - schedule & cancel
[ https://issues.apache.org/jira/browse/IGNITE-13697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13697: --- Labels: IEP-47 (was: ) > Control.sh API - schedule & cancel > -- > > Key: IGNITE-13697 > URL: https://issues.apache.org/jira/browse/IGNITE-13697 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-47 > Time Spent: 10m > Remaining Estimate: 0h > > > From original draft by [~sergeychugunov]: > > Schedule > *control.sh defragmentation schedule nodes > nodeConsistentId0[,nodeConsistentId1] [caches > cacheName0,cacheName1,cacheName2]* > > Optional list of caches is passed to perform defragmentation for a particular > set of caches. By default all caches are defragmented. > > _Prerequisites_: command is sent to node in normal operations, node in > maintenance mode should not accept it > _Command output:_ > Defragmentation is successfully scheduled on nodes , on next > restart the following caches will be defragmented: . > Cancel > *control.sh defragmentation cancel nodeHost nodePort [cache cacheName0]* > _Prerequisites_: command is sent to node in maintenance mode, node in normal > operations should not accept it. > _Command output:_ > Defragmentation is already completed for caches: > Defragmentation is cancelled for caches: ; all intermediate > files are cleaned up. > > *Note:* Caches list for cancel command will not be implemented here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13681) Non markers checkpoint implementation
[ https://issues.apache.org/jira/browse/IGNITE-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13681: --- Labels: IEP-47 (was: ) > Non markers checkpoint implementation > - > > Key: IGNITE-13681 > URL: https://issues.apache.org/jira/browse/IGNITE-13681 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-47 > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to implement a new version of checkpoint which will be simpler > than the current one. The main differences compared to the current checkpoint: > * It doesn't contain any write operation to WAL. > * It doesn't create checkpoint markers. > * It should be possible to configure checkpoint listener only on the exact > data region > This checkpoint will be helpful for defragmentation and for recovery(it is > not possible to use the current checkpoint during recovery right now) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13683) Added MVCC validation to ValidateIndexesClosure
[ https://issues.apache.org/jira/browse/IGNITE-13683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13683: --- Labels: IEP-47 (was: ) > Added MVCC validation to ValidateIndexesClosure > --- > > Key: IGNITE-13683 > URL: https://issues.apache.org/jira/browse/IGNITE-13683 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.9 >Reporter: Anton Kalashnikov >Assignee: Semyon Danilov >Priority: Major > Labels: IEP-47 > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > MVCC indexes validation should be added to ValidateIndexesClosure -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13682) Add generic to maintenance mode feature
[ https://issues.apache.org/jira/browse/IGNITE-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13682: --- Labels: IEP-47 (was: ) > Add generic to maintenance mode feature > --- > > Key: IGNITE-13682 > URL: https://issues.apache.org/jira/browse/IGNITE-13682 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Labels: IEP-47 > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > MaintenanceAction has no generic right now which lead to parametirezed problem -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13701) SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of columns and content
Andrey N. Gura created IGNITE-13701:
---
Summary: SQL Indexes,Tables and Schemas views in IEP-35 changed
amount, order of columns and content
Key: IGNITE-13701
URL: https://issues.apache.org/jira/browse/IGNITE-13701
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Andrey N. Gura
Fix For: 2.10
https://issues.apache.org/jira/browse/IGNITE-12213 broke backward compatibility:
* {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
{{INDEXES}} view.
* {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
{{TABLES}} view.
* {{SCHEMA_NAME}} column was renamed to {{NAME}} for the {{SCHEMAS}} view.
* {{PREDEFINED}} column was added to the {{SCHEMAS}} view.
Default columns order was changed.
Also content of {{SCHEMAS}} view has changed in a wrong way: now view contains
proxy indexes (it is simply wrapper and implementation detail) and indexes for
cache key displays as {{PK}} index (it is incorrect, because {{PK}} index could
be only for table and this kind of indexes is implementation detail).
This behavior should be replaced by previous one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13701) SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of columns and content
[
https://issues.apache.org/jira/browse/IGNITE-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura reassigned IGNITE-13701:
---
Assignee: Andrey N. Gura
> SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of
> columns and content
> ---
>
> Key: IGNITE-13701
> URL: https://issues.apache.org/jira/browse/IGNITE-13701
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.10
>
>
> https://issues.apache.org/jira/browse/IGNITE-12213 broke backward
> compatibility:
> * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
> {{INDEXES}} view.
> * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
> {{TABLES}} view.
> * {{SCHEMA_NAME}} column was renamed to {{NAME}} for the {{SCHEMAS}} view.
> * {{PREDEFINED}} column was added to the {{SCHEMAS}} view.
> Default columns order was changed.
> Also content of {{SCHEMAS}} view has changed in a wrong way: now view
> contains proxy indexes (it is simply wrapper and implementation detail) and
> indexes for cache key displays as {{PK}} index (it is incorrect, because
> {{PK}} index could be only for table and this kind of indexes is
> implementation detail).
> This behavior should be replaced by previous one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13684) Prepare PageStore/B+Tree to usage outside of standart lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-13684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13684: --- Labels: IEP-47 (was: ) > Prepare PageStore/B+Tree to usage outside of standart lifecycle > --- > > Key: IGNITE-13684 > URL: https://issues.apache.org/jira/browse/IGNITE-13684 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-47 > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Right now, PageStore and some other classes which responsible for persistent > too couple with many other dependencies which not allow to use it in > different initial conditions(ex. defragmentation). So it is needed to > refactor some places in order to improve this situation. > Changes are: > * static constant for cache group meta page; > * PageStore allocation tracker replaced with a more generic LongConsumer do > decouple it from metrics framework; > * PageReadWriteManager added to basically allow having same cache group in > different data regions; > * several methods and fields exposed as internally public/protected API; > * several inner classes refactored so that they become static classes; > * PageIOResolver interface created and used to make data structure more > flexible; > * InsertLast interface for B+Tree added that will optimize comparisons on > inserts. Unused for now; > * All this code doesn't affect existing behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13666) Fix detection of failed node number in the discovery ducktape test.
[ https://issues.apache.org/jira/browse/IGNITE-13666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13666: -- Summary: Fix detection of failed node number in the discovery ducktape test. (was: Disable socket linger in discovery ducktape test.) > Fix detection of failed node number in the discovery ducktape test. > --- > > Key: IGNITE-13666 > URL: https://issues.apache.org/jira/browse/IGNITE-13666 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > soLinger might be disabled to fasten the discovery tests. Additionally, we > could reduce failureDetectionTimeout. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13695: -- Affects Version/s: 2.9 > Move javadoc of affection of several addresses on failure detection. > > > Key: IGNITE-13695 > URL: https://issues.apache.org/jira/browse/IGNITE-13695 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Current javadoc of affection several node addresses of failure detection is > located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by > `TcpDiscoverySpi.setLocalAddress()`. > Perhaps, the text might be slightly changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13695: -- Fix Version/s: 2.9.1 > Move javadoc of affection of several addresses on failure detection. > > > Key: IGNITE-13695 > URL: https://issues.apache.org/jira/browse/IGNITE-13695 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Current javadoc of affection several node addresses of failure detection is > located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by > `TcpDiscoverySpi.setLocalAddress()`. > Perhaps, the text might be slightly changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13554) ConcurrentModificationException on node join.
[
https://issues.apache.org/jira/browse/IGNITE-13554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230587#comment-17230587
]
Ignite TC Bot commented on IGNITE-13554:
{panel:title=Branch: [pull/8440/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8440/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5724100buildTypeId=IgniteTests24Java8_RunAll]
> ConcurrentModificationException on node join.
> -
>
> Key: IGNITE-13554
> URL: https://issues.apache.org/jira/browse/IGNITE-13554
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Konstantin Sirotkin
>Priority: Major
> Attachments: id.log
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> java.util.ConcurrentModificationException: null
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1445)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1479)
> at java.util.HashMap$EntryIterator.next(HashMap.java:1477)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.fillAffinityNodeCaches(GridDiscoveryManager.java:3278)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.createDiscoCache(GridDiscoveryManager.java:2364)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.access$3100(GridDiscoveryManager.java:171)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:723)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:528)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2608)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2646)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13700) ConcurrentModificationException on node join.
Konstantin Sirotkin created IGNITE-13700: Summary: ConcurrentModificationException on node join. Key: IGNITE-13700 URL: https://issues.apache.org/jira/browse/IGNITE-13700 Project: Ignite Issue Type: Bug Reporter: Konstantin Sirotkin Assignee: Konstantin Sirotkin This issue was created for more complex investigation of problem IGNITE-13554. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13637) ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one
[ https://issues.apache.org/jira/browse/IGNITE-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230561#comment-17230561 ] Pavel Tupitsyn commented on IGNITE-13637: - [~isapego] looks good to me > ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one > - > > Key: IGNITE-13637 > URL: https://issues.apache.org/jira/browse/IGNITE-13637 > Project: Ignite > Issue Type: Improvement > Components: odbc >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we only support fetching of result set one by one. Implement > fetching in a batch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13684) Prepare PageStore/B+Tree to usage outside of standart lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-13684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13684: - Fix Version/s: 2.10 > Prepare PageStore/B+Tree to usage outside of standart lifecycle > --- > > Key: IGNITE-13684 > URL: https://issues.apache.org/jira/browse/IGNITE-13684 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Right now, PageStore and some other classes which responsible for persistent > too couple with many other dependencies which not allow to use it in > different initial conditions(ex. defragmentation). So it is needed to > refactor some places in order to improve this situation. > Changes are: > * static constant for cache group meta page; > * PageStore allocation tracker replaced with a more generic LongConsumer do > decouple it from metrics framework; > * PageReadWriteManager added to basically allow having same cache group in > different data regions; > * several methods and fields exposed as internally public/protected API; > * several inner classes refactored so that they become static classes; > * PageIOResolver interface created and used to make data structure more > flexible; > * InsertLast interface for B+Tree added that will optimize comparisons on > inserts. Unused for now; > * All this code doesn't affect existing behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
[
https://issues.apache.org/jira/browse/IGNITE-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230539#comment-17230539
]
Ignite TC Bot commented on IGNITE-13695:
{panel:title=Branch: [pull/8448/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8448/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5729918buildTypeId=IgniteTests24Java8_RunAll]
> Move javadoc of affection of several addresses on failure detection.
>
>
> Key: IGNITE-13695
> URL: https://issues.apache.org/jira/browse/IGNITE-13695
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current javadoc of affection several node addresses of failure detection is
> located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by
> `TcpDiscoverySpi.setLocalAddress()`.
> Perhaps, the text might be slightly changed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery
Ivan Daschinskiy created IGNITE-13699: - Summary: Support new metrics framework in ZookeeperDiscovery Key: IGNITE-13699 URL: https://issues.apache.org/jira/browse/IGNITE-13699 Project: Ignite Issue Type: Improvement Components: zookeeper Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13698) SQL EXPLAIN Shows Impossible Index
[
https://issues.apache.org/jira/browse/IGNITE-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-13698:
--
Description:
+*Steps to Reproduce*+
1. Create a table with a VARCHAR field and an index on that field
{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
+*Expected*+
The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
applied due to any of"
# The UPPER(TITLE) SQL function on the left-hand side
# The LIKE pattern starting from % (any symbol)
+*Actual*+
The TEST_TITLE_ASC_IDX is used
{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}
was:
+*Steps to Reproduce*+
1. Create a table with a VARCHAR field and an index on that field
{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
+*Expected*+
The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
applied due to any of"
# The UPPER(TITLE) SQL function on the left-hand side
# The LIKE pattern starting from % (any symbol)
+*Actual*+
The TEST_TITLE_ASC_IDX is used
{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}
> SQL EXPLAIN Shows Impossible Index
> --
>
> Key: IGNITE-13698
> URL: https://issues.apache.org/jira/browse/IGNITE-13698
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to Reproduce*+
> 1. Create a table with a VARCHAR field and an index on that field
> {{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
> {{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
> 2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
> {{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
> +*Expected*+
> The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
> applied due to any of"
> # The UPPER(TITLE) SQL function on the left-hand side
> # The LIKE pattern starting from % (any symbol)
> +*Actual*+
> The TEST_TITLE_ASC_IDX is used
> {{SELECT}}
> {{ __Z0._KEY AS __C0_0}}
> {{FROM PUBLIC.TEST __Z0}}
> {{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
> {{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13698) SQL EXPLAIN Shows Impossible Index
[
https://issues.apache.org/jira/browse/IGNITE-13698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-13698:
--
Description:
+*Steps to Reproduce*+
1. Create a table with a VARCHAR field and an index on that field
{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
+*Expected*+
The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
applied due to any of"
# The UPPER(TITLE) SQL function on the left-hand side
# The LIKE pattern starting from % (any symbol)
+*Actual*+
The TEST_TITLE_ASC_IDX is used
SELECT
__Z0._KEY AS __C0_0
FROM PUBLIC.TEST __Z0
/* PUBLIC.TEST_TITLE_ASC_IDX */
WHERE UPPER(__Z0.TITLE) LIKE '%A%'
was:
+*Steps to Reproduce*+
1. Create a table with a VARCHAR field and an index on that field
{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
+*Expected*+
The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
applied due to any of"
# The UPPER(TITLE) SQL function on the left-hand side
# The LIKE pattern starting from % (any symbol)
+*Actual*+
The TEST_TITLE_ASC_IDX is used
{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}
> SQL EXPLAIN Shows Impossible Index
> --
>
> Key: IGNITE-13698
> URL: https://issues.apache.org/jira/browse/IGNITE-13698
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Priority: Major
>
> +*Steps to Reproduce*+
> 1. Create a table with a VARCHAR field and an index on that field
> {{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
> {{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
> 2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
> {{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
> +*Expected*+
> The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
> applied due to any of"
> # The UPPER(TITLE) SQL function on the left-hand side
> # The LIKE pattern starting from % (any symbol)
> +*Actual*+
> The TEST_TITLE_ASC_IDX is used
> SELECT
> __Z0._KEY AS __C0_0
> FROM PUBLIC.TEST __Z0
> /* PUBLIC.TEST_TITLE_ASC_IDX */
> WHERE UPPER(__Z0.TITLE) LIKE '%A%'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13698) SQL EXPLAIN Shows Impossible Index
Alexey Kukushkin created IGNITE-13698:
-
Summary: SQL EXPLAIN Shows Impossible Index
Key: IGNITE-13698
URL: https://issues.apache.org/jira/browse/IGNITE-13698
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.9
Reporter: Alexey Kukushkin
+*Steps to Reproduce*+
1. Create a table with a VARCHAR field and an index on that field
{{CREATE TABLE TEST (ID INT PRIMARY KEY, TITLE VARCHAR);}}
{{CREATE INDEX TEST_TITLE_ASC_IDX ON TEST(TITLE); }}
2. Show a plan for querying the table with a filter UPPER(TITLE) LIKE '%A%'
{{EXPLAIN SELECT _KEY FROM TEST WHERE UPPER(TITLE) LIKE '%A%';}}
+*Expected*+
The table SCAN on the TITLE field since the TEST_TITLE_ASC_IDX cannot be
applied due to any of"
# The UPPER(TITLE) SQL function on the left-hand side
# The LIKE pattern starting from % (any symbol)
+*Actual*+
The TEST_TITLE_ASC_IDX is used
{{SELECT}}
{{ __Z0._KEY AS __C0_0}}
{{FROM PUBLIC.TEST __Z0}}
{{ /* PUBLIC.TEST_TITLE_ASC_IDX */}}
{{WHERE UPPER(__Z0.TITLE) LIKE '%A%'}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13190) Core defragmentation functions
[ https://issues.apache.org/jira/browse/IGNITE-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-13190: -- Assignee: Ivan Bessonov (was: Semyon Danilov) > Core defragmentation functions > -- > > Key: IGNITE-13190 > URL: https://issues.apache.org/jira/browse/IGNITE-13190 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-47 > Time Spent: 20m > Remaining Estimate: 0h > > The following set of functions covering defragmentation happy-case needed: > * Initialization of defragmentation manager when node is started in > maintenance mode. > * Information about partition files is gathered by defrag mgr. > * For each partition file corresponding file of defragmented partition is > created and initialized. > * Keys are transferred from old partitions to new partitions. > * Checkpointer is aware of new partition files and flushes defragmented > memory to new partition files. > > No fault-tolerance code nor index defragmentation mappings are needed in this > task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13697) Control.sh API - schedule & cancel
[ https://issues.apache.org/jira/browse/IGNITE-13697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13697: --- Description: >From original draft by [~sergeychugunov]: Schedule *control.sh defragmentation schedule nodes nodeConsistentId0[,nodeConsistentId1] [caches cacheName0,cacheName1,cacheName2]* Optional list of caches is passed to perform defragmentation for a particular set of caches. By default all caches are defragmented. _Prerequisites_: command is sent to node in normal operations, node in maintenance mode should not accept it _Command output:_ Defragmentation is successfully scheduled on nodes , on next restart the following caches will be defragmented: . Cancel *control.sh defragmentation cancel nodeHost nodePort [cache cacheName0]* _Prerequisites_: command is sent to node in maintenance mode, node in normal operations should not accept it. _Command output:_ Defragmentation is already completed for caches: Defragmentation is cancelled for caches: ; all intermediate files are cleaned up. *Note:* Caches list for cancel command will not be implemented here. > Control.sh API - schedule & cancel > -- > > Key: IGNITE-13697 > URL: https://issues.apache.org/jira/browse/IGNITE-13697 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > > > From original draft by [~sergeychugunov]: > > Schedule > *control.sh defragmentation schedule nodes > nodeConsistentId0[,nodeConsistentId1] [caches > cacheName0,cacheName1,cacheName2]* > > Optional list of caches is passed to perform defragmentation for a particular > set of caches. By default all caches are defragmented. > > _Prerequisites_: command is sent to node in normal operations, node in > maintenance mode should not accept it > _Command output:_ > Defragmentation is successfully scheduled on nodes , on next > restart the following caches will be defragmented: . > Cancel > *control.sh defragmentation cancel nodeHost nodePort [cache cacheName0]* > _Prerequisites_: command is sent to node in maintenance mode, node in normal > operations should not accept it. > _Command output:_ > Defragmentation is already completed for caches: > Defragmentation is cancelled for caches: ; all intermediate > files are cleaned up. > > *Note:* Caches list for cancel command will not be implemented here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13697) Control.sh API - schedule & cancel
Ivan Bessonov created IGNITE-13697: -- Summary: Control.sh API - schedule & cancel Key: IGNITE-13697 URL: https://issues.apache.org/jira/browse/IGNITE-13697 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13608) .NET: Add Partitions and UpdateBatchSize to SqlFieldsQuery
[
https://issues.apache.org/jira/browse/IGNITE-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230418#comment-17230418
]
Pavel Tupitsyn commented on IGNITE-13608:
-
Merged to master: c30d1ed7b6f6abdade9eb12ca765b701a2280c44
> .NET: Add Partitions and UpdateBatchSize to SqlFieldsQuery
> --
>
> Key: IGNITE-13608
> URL: https://issues.apache.org/jira/browse/IGNITE-13608
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IGNITE-4523 and IGNITE-11499 added new options to SqlFieldsQuery, propagate
> .NET:
> * {{SqlFieldsQuery.Partitions}}, {{QueryOptions.Partitions}}
> * {{SqlFieldsQuery.UpdateBatchSize}}, {{QueryOptions.UpdateBatchSize}}
> Make sure this works with thin clients too - needs a feature flag.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
