[jira] [Commented] (IGNITE-20236) Get rid of DistributionZonesConfigurationSchema#defaultDataStorage
[ https://issues.apache.org/jira/browse/IGNITE-20236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755387#comment-17755387 ] Roman Puchkovskiy commented on IGNITE-20236: The patch looks good to me > Get rid of DistributionZonesConfigurationSchema#defaultDataStorage > -- > > Key: IGNITE-20236 > URL: https://issues.apache.org/jira/browse/IGNITE-20236 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > Since > *org.apache.ignite.internal.distributionzones.configuration.DistributionZonesConfigurationSchema* > will be deleted in IGNITE-20114, we need to do something with configuration > *DistributionZonesConfigurationSchema#defaultDataStorage*. > It is suggested to temporarily hardcode the current default value in the > *org.apache.ignite.internal.storage.DataStorageManager*. > A new solution is proposed to be implemented in NEW_TICKET. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20236) Get rid of DistributionZonesConfigurationSchema#defaultDataStorage
[ https://issues.apache.org/jira/browse/IGNITE-20236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20236: - Reviewer: Roman Puchkovskiy > Get rid of DistributionZonesConfigurationSchema#defaultDataStorage > -- > > Key: IGNITE-20236 > URL: https://issues.apache.org/jira/browse/IGNITE-20236 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Since > *org.apache.ignite.internal.distributionzones.configuration.DistributionZonesConfigurationSchema* > will be deleted in IGNITE-20114, we need to do something with configuration > *DistributionZonesConfigurationSchema#defaultDataStorage*. > It is suggested to temporarily hardcode the current default value in the > *org.apache.ignite.internal.storage.DataStorageManager*. > A new solution is proposed to be implemented in NEW_TICKET. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Description: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictive`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. was: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictive`. This should not be necessary because types > of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictive` from `SetOpConverterRule` for > both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Description: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because types of rows returned by inputs to set operation should be coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. was: `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because the types of rows returned by inputs to set operation should have been already been coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because > types of rows returned by inputs to set operation should be coerced at the > validation stage by `SqlValidator`/ SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. Remove row type transformations from SetOpConverterRule.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Summary: Sql. Remove row type transformations from SetOpConverterRule. (was: Sql. SetOpConverterRule. Remove row type transformations.) > Sql. Remove row type transformations from SetOpConverterRule. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because the > types of rows returned by inputs to set operation should have been already > been coerced at the validation stage by `SqlValidator`/ > SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20239) Sql. SetOpConverterRule. Remove row type transformations.
[ https://issues.apache.org/jira/browse/IGNITE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20239: -- Summary: Sql. SetOpConverterRule. Remove row type transformations. (was: Sql. SetOpConverterRule. ) > Sql. SetOpConverterRule. Remove row type transformations. > -- > > Key: IGNITE-20239 > URL: https://issues.apache.org/jira/browse/IGNITE-20239 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > `SetOpConverterRule` creates a rowType produced by set operation by means of > `TypeFactory::leastRestrictiveType`. This should not be necessary because the > types of rows returned by inputs to set operation should have been already > been coerced at the validation stage by `SqlValidator`/ > SetopOperandTypeChecker`. > Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` > for both colocated and map/reduce versions of operators and use `rowType` > returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20239) Sql. SetOpConverterRule.
Maksim Zhuravkov created IGNITE-20239: - Summary: Sql. SetOpConverterRule. Key: IGNITE-20239 URL: https://issues.apache.org/jira/browse/IGNITE-20239 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 `SetOpConverterRule` creates a rowType produced by set operation by means of `TypeFactory::leastRestrictiveType`. This should not be necessary because the types of rows returned by inputs to set operation should have been already been coerced at the validation stage by `SqlValidator`/ SetopOperandTypeChecker`. Remove calls to `TypeFactory::leastRestrictiveType` from `SetOpConverterRule` for both colocated and map/reduce versions of operators and use `rowType` returned by a set operator node. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17842) .NET: LINQ GroupBy with anonymous type produces invalid SQL
[
https://issues.apache.org/jira/browse/IGNITE-17842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17842:
Affects Version/s: 2.15
> .NET: LINQ GroupBy with anonymous type produces invalid SQL
> ---
>
> Key: IGNITE-17842
> URL: https://issues.apache.org/jira/browse/IGNITE-17842
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.15
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce, change *TestGroupBy* like this:
> {code}
> CollectionAssert.AreEquivalent(new[] { 1000, 1001 },
> persons.GroupBy(x => new { I0 = x.Value.OrganizationId
> }).Select(x => x.Key.I0).ToArray());
> {code}
> Result:
> {code}
> Apache.Ignite.Core.Common.IgniteException : Failed to parse query. Column
> "_T0.I0" not found; SQL statement:
> select _T0.I0 from PERSON_ORG_SCHEMA.Person as _T0 group by
> (_T0.ORGANIZATIONID)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20238) Sql. Conversion to VARCHAR for INTERVAL types is not correct.
[
https://issues.apache.org/jira/browse/IGNITE-20238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20238:
--
Description:
The following queries produce the same results:
{code:java}
#q1
SELECT CAST(INTERVAL 2 MINUTES AS VARCHAR) # '+2'
#q2
SELECT CAST(INTERVAL 2 HOURS AS VARCHAR) # '+2'
{code}
Databases that support interval types return different results for both queries.
Oracle:
{code:java}
# q1
SELECT CAST(INTERVAL '1' YEAR AS VARCHAR2(100)) # INTERVAL'+01-00'YEAR TO MONTH
# q2
SELECT CAST(INTERVAL '1' SECOND AS VARCHAR2(100)) # INTERVAL'+00
00:00:01.00'DAY TO SECOND
{code}
was:
The following queries produce the same results:
{code:java}
#q1
SELECT CAST(INTERVAL 2 MINUTES AS VARCHAR) # '+2'
#q2
SELECT CAST(INTERVAL 2 HOURS AS VARCHAR) # '+2'
{code}
Databases that support interval types return different results for both queries.
Oracle:
{code:java}
# q1
SELECT CAST(INTERVAL '1' YEAR AS VARCHAR2(100)) # INTERVAL'+01-00'YEAR TO MONTH
# q2
SELECT CAST(INTERVAL '1' SECOND AS VARCHAR2(100)) # INTERVAL'+00
00:00:01.00'DAY TO SECOND
{code}
> Sql. Conversion to VARCHAR for INTERVAL types is not correct.
> -
>
> Key: IGNITE-20238
> URL: https://issues.apache.org/jira/browse/IGNITE-20238
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following queries produce the same results:
> {code:java}
> #q1
> SELECT CAST(INTERVAL 2 MINUTES AS VARCHAR) # '+2'
> #q2
> SELECT CAST(INTERVAL 2 HOURS AS VARCHAR) # '+2'
> {code}
> Databases that support interval types return different results for both
> queries.
> Oracle:
> {code:java}
> # q1
> SELECT CAST(INTERVAL '1' YEAR AS VARCHAR2(100)) # INTERVAL'+01-00'YEAR TO
> MONTH
> # q2
> SELECT CAST(INTERVAL '1' SECOND AS VARCHAR2(100)) # INTERVAL'+00
> 00:00:01.00'DAY TO SECOND
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20238) Sql. Conversion to VARCHAR for INTERVAL types is not correct.
Maksim Zhuravkov created IGNITE-20238:
-
Summary: Sql. Conversion to VARCHAR for INTERVAL types is not
correct.
Key: IGNITE-20238
URL: https://issues.apache.org/jira/browse/IGNITE-20238
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Maksim Zhuravkov
Fix For: 3.0.0-beta2
The following queries produce the same results:
{code:java}
#q1
SELECT CAST(INTERVAL 2 MINUTES AS VARCHAR) # '+2'
#q2
SELECT CAST(INTERVAL 2 HOURS AS VARCHAR) # '+2'
{code}
Databases that support interval types return different results for both queries.
Oracle:
{code:java}
# q1
SELECT CAST(INTERVAL '1' YEAR AS VARCHAR2(100)) # INTERVAL'+01-00'YEAR TO MONTH
# q2
SELECT CAST(INTERVAL '1' SECOND AS VARCHAR2(100)) # INTERVAL'+00
00:00:01.00'DAY TO SECOND
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20237) Make default data storage configurable
Kirill Tkalenko created IGNITE-20237: Summary: Make default data storage configurable Key: IGNITE-20237 URL: https://issues.apache.org/jira/browse/IGNITE-20237 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 Since we got rid of setting up the default data store in IGNITE-20236. Then we need to return this feature, but before that we need to think about how to do this, because there is an idea that we can have a cluster of nodes with different sets of data storages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20236) Get rid of DistributionZonesConfigurationSchema#defaultDataStorage
Kirill Tkalenko created IGNITE-20236: Summary: Get rid of DistributionZonesConfigurationSchema#defaultDataStorage Key: IGNITE-20236 URL: https://issues.apache.org/jira/browse/IGNITE-20236 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 Since *org.apache.ignite.internal.distributionzones.configuration.DistributionZonesConfigurationSchema* will be deleted in IGNITE-20114, we need to do something with configuration *DistributionZonesConfigurationSchema#defaultDataStorage*. It is suggested to temporarily hardcode the current default value in the *org.apache.ignite.internal.storage.DataStorageManager*. A new solution is proposed to be implemented in NEW_TICKET. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19834) Thin 3.0: Schema validation
[ https://issues.apache.org/jira/browse/IGNITE-19834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-19834. - Resolution: Done > Thin 3.0: Schema validation > --- > > Key: IGNITE-19834 > URL: https://issues.apache.org/jira/browse/IGNITE-19834 > Project: Ignite > Issue Type: Epic > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h2. Motivation > Current Ignite 3 behavior is inconsistent when user data has unmapped columns: > * POJO: unmapped columns (not in schema) are ignored; > * Tuple: unmapped columns are ignored on client, but cause exception on > server (when using server-side API from a Compute task). > We should ensure consistent and reliable behavior across all APIs and clients. > h2. Non-goals > * Validate column types (already handled by serializers) > * Deal with any other schema aspects (indexes, constraints) which are not > present on the client side > h2. Requirements > Incompatible rows must be rejected by all APIs (Record, KeyValue, > RecordBinary, KeyValueBinary): > * Unmapped columns are present; > * Columns without default value are missing. > * Validation should be performed by the server when possible. > * Unmapped columns should be validated by the client, because rows are > serialized according to the schema (server does not see unmapped columns). > h2. Design > h3. Case 1: Missing Columns > Already handled by the client and the server: > * Client sends noValueSet to indicate which columns were not provided by the > user; > * Server rejects rows when the column is not set by the user and does not > have a default value. > h3. Case 2: Unmapped Columns > *Server-side API* > * Fix Marshaller to reject POJOs with unmapped fields; > * Reject tuples from client connector when schema is outdated (see > explanation below). > *Client-side API* > Client serializes user rows according to the latest known schema. Unmapped > columns will not reach the server side. Therefore, the client must reject > unmapped columns in user rows (Tuples, POJOs). > However, there is no guarantee that the client always has the latest schema: > * Column might be removed on the server, but the client uses old schema and > validation passes when it should fail; > ** Solution: server rejects rows with outdated schema from the client. > * Column might be added on the server, but the client uses old schema and > validation fails when it should pass. > ** Solution: when an unmapped column is detected by the client, it should > request the latest schema and retry the validation to avoid false-positive > exceptions. > The fact that the server rejects rows with outdated schema from the client > also simplifies client schema synchronization logic - we won't have to deal > with things like IGNITE-19241 Java thin 3.0: propagate table schema updates > to client on write-only operations anymore. Client will simply reload the > schema when given a certain error code. > *Schemas and Transactions* > IEP-98 Schema Synchronization proposes a more complex logic of handling > schema updates within transactions. This may alter the way we validate > schemas on the server, but should not affect the client: if a given schema > version is observed by the client, any server node should be able to handle > this version potentially waiting for it to be installed before proceeding). > h2. Implementation Notes > Client and server APIs implement the same interfaces. Therefore, the same > tests should run against both APIs and ensure identical behavior (see > ItSqlSynchronousApiTest as an example of this approach). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19840) .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected
[ https://issues.apache.org/jira/browse/IGNITE-19840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755350#comment-17755350 ] Pavel Tupitsyn commented on IGNITE-19840: - Merged to main: 730d214f92aa397d1037159618651c58464630e1 > .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected > > > Key: IGNITE-19840 > URL: https://issues.apache.org/jira/browse/IGNITE-19840 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[
https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755154#comment-17755154
]
Ignite TC Bot commented on IGNITE-20216:
{panel:title=Branch: [pull/10897/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=7303635]]
* IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 - History for base
branch is absent.
* IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 - New test duration
121s is more that 1 minute
{panel}
{panel:title=Branch: [pull/10897/head] Base: [master] : New Tests
(151)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 5{color} [[tests
151|https://ci2.ignite.apache.org/viewLog.html?buildId=7303635]]
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
* {color:#013220}IgniteCacheTestSuite5: testsuites.IgniteCacheTestSuite5 -
PASSED{color}
... and 140 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7303474&buildTypeId=IgniteTests24Java8_RunAll]
> Moving ML module to ignite-extensions
> -
>
> Key: IGNITE-20216
> URL: https://issues.apache.org/jira/browse/IGNITE-20216
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is time to move this module to ignite extensions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19148) Replace using JUL in tests with log4j2
[ https://issues.apache.org/jira/browse/IGNITE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19148: - Summary: Replace using JUL in tests with log4j2 (was: Switch output stream for Ignite logs to System.out) > Replace using JUL in tests with log4j2 > -- > > Key: IGNITE-19148 > URL: https://issues.apache.org/jira/browse/IGNITE-19148 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As for now, the default Ignite log output stream is System.err, at least for > tests, that is definitely not OK. Let's use a widely-known logging framework, > for instance - log4j2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755098#comment-17755098 ] Ivan Daschinsky commented on IGNITE-20216: -- [~zaleslaw] Test suite also works > Moving ML module to ignite-extensions > - > > Key: IGNITE-20216 > URL: https://issues.apache.org/jira/browse/IGNITE-20216 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It is time to move this module to ignite extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20235) ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail locally with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-20235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20235:
-
Fix Version/s: 3.0.0-beta2
> ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail
> locally with AssertionError
> ---
>
> Key: IGNITE-20235
> URL: https://issues.apache.org/jira/browse/IGNITE-20235
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When trying to reproduce the problem from IGNITE-20230, locally the
> *org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode*
> began to fall with an *java.lang.AssertionError*.
> {noformat}
> java.lang.AssertionError: java.util.concurrent.ExecutionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:0e2d6413-6919-41a1-919e-4a2deb0c37c6
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.createTableWithOnePartition(ItRebalanceDistributedTest.java:1026)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.testDestroyPartitionStoragesOnEvictNode(ItRebalanceDistributedTest.java:470)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(Throwab
[jira] [Assigned] (IGNITE-20235) ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail locally with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-20235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-20235:
Assignee: Kirill Tkalenko
> ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail
> locally with AssertionError
> ---
>
> Key: IGNITE-20235
> URL: https://issues.apache.org/jira/browse/IGNITE-20235
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> When trying to reproduce the problem from IGNITE-20230, locally the
> *org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode*
> began to fall with an *java.lang.AssertionError*.
> {noformat}
> java.lang.AssertionError: java.util.concurrent.ExecutionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:0e2d6413-6919-41a1-919e-4a2deb0c37c6
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.createTableWithOnePartition(ItRebalanceDistributedTest.java:1026)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.testDestroyPartitionStoragesOnEvictNode(ItRebalanceDistributedTest.java:470)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
[jira] [Assigned] (IGNITE-20235) ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail locally with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-20235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-20235:
Assignee: Alexander Lapin (was: Kirill Tkalenko)
> ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail
> locally with AssertionError
> ---
>
> Key: IGNITE-20235
> URL: https://issues.apache.org/jira/browse/IGNITE-20235
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> When trying to reproduce the problem from IGNITE-20230, locally the
> *org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode*
> began to fall with an *java.lang.AssertionError*.
> {noformat}
> java.lang.AssertionError: java.util.concurrent.ExecutionException:
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:0e2d6413-6919-41a1-919e-4a2deb0c37c6
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
> at
> org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
> at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.createTableWithOnePartition(ItRebalanceDistributedTest.java:1026)
> at
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.testDestroyPartitionStoragesOnEvictNode(ItRebalanceDistributedTest.java:470)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableColle
[jira] [Created] (IGNITE-20235) ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail locally with AssertionError
Kirill Tkalenko created IGNITE-20235:
Summary:
ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode fail locally
with AssertionError
Key: IGNITE-20235
URL: https://issues.apache.org/jira/browse/IGNITE-20235
Project: Ignite
Issue Type: Bug
Reporter: Kirill Tkalenko
When trying to reproduce the problem from IGNITE-20230, locally the
*org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode*
began to fall with an *java.lang.AssertionError*.
{noformat}
java.lang.AssertionError: java.util.concurrent.ExecutionException:
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:0e2d6413-6919-41a1-919e-4a2deb0c37c6
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:78)
at
org.apache.ignite.internal.testframework.matchers.CompletableFutureMatcher.matchesSafely(CompletableFutureMatcher.java:35)
at org.hamcrest.TypeSafeMatcher.matches(TypeSafeMatcher.java:67)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:10)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.createTableWithOnePartition(ItRebalanceDistributedTest.java:1026)
at
org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest.testDestroyPartitionStoragesOnEvictNode(ItRebalanceDistributedTest.java:470)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollect
[jira] [Updated] (IGNITE-20230) Flaky ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode
[
https://issues.apache.org/jira/browse/IGNITE-20230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-20230:
-
Summary: Flaky
ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode (was: Flaky
testDestroyPartitionStoragesOnEvictNode)
> Flaky ItRebalanceDistributedTest#testDestroyPartitionStoragesOnEvictNode
>
>
> Key: IGNITE-20230
> URL: https://issues.apache.org/jira/browse/IGNITE-20230
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> {code:java}
> Wanted but not invoked:
> testMvTableStorage.destroyPartition(0);
> -> at
> org.apache.ignite.internal.storage.impl.TestMvTableStorage.destroyPartition(TestMvTableStorage.java:123)
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7438015?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19840) .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected
[ https://issues.apache.org/jira/browse/IGNITE-19840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755072#comment-17755072 ] Igor Sapego commented on IGNITE-19840: -- Looks good to me. > .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected > > > Key: IGNITE-19840 > URL: https://issues.apache.org/jira/browse/IGNITE-19840 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19148) Switch output stream for Ignite logs to System.out
[ https://issues.apache.org/jira/browse/IGNITE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755070#comment-17755070 ] Vyacheslav Koptilin commented on IGNITE-19148: -- Hello [~rpuch], [~Mikhail Pochatkin], Guys, could you please take a look at this [patch|https://github.com/apache/ignite-3/pull/2429]? > Switch output stream for Ignite logs to System.out > -- > > Key: IGNITE-19148 > URL: https://issues.apache.org/jira/browse/IGNITE-19148 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As for now, the default Ignite log output stream is System.err, at least for > tests, that is definitely not OK. Let's use a widely-known logging framework, > for instance - log4j2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19148) Switch output stream for Ignite logs to System.out
[ https://issues.apache.org/jira/browse/IGNITE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19148: - Description: As for now, the default Ignite log output stream is System.err, at least for tests, that is definitely not OK. Let's use a widely-known logging framework, for instance - log4j2 (was: As for now, the default Ignite log output stream is System.err, it should be switched to System.out.) > Switch output stream for Ignite logs to System.out > -- > > Key: IGNITE-19148 > URL: https://issues.apache.org/jira/browse/IGNITE-19148 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As for now, the default Ignite log output stream is System.err, at least for > tests, that is definitely not OK. Let's use a widely-known logging framework, > for instance - log4j2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20234: --- Component/s: spark > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug > Components: spark >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19148) Switch output stream for Ignite logs to System.out
[ https://issues.apache.org/jira/browse/IGNITE-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-19148: - Fix Version/s: 3.0.0-beta2 > Switch output stream for Ignite logs to System.out > -- > > Key: IGNITE-19148 > URL: https://issues.apache.org/jira/browse/IGNITE-19148 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > As for now, the default Ignite log output stream is System.err, it should be > switched to System.out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-20186) [Ignite Website] Add Upcoming Events
[ https://issues.apache.org/jira/browse/IGNITE-20186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlan Aytpaev closed IGNITE-20186. -- Ignite Flags: (was: Docs Required,Release Notes Required) > [Ignite Website] Add Upcoming Events > > > Key: IGNITE-20186 > URL: https://issues.apache.org/jira/browse/IGNITE-20186 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Trivial > > Update [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#upcoming] page with upcoming > talks. > > 1) Event: Community over code, Halifax, Canada, October 9 > Talk Title - Enhancing Apache Ignite 3.0 with the Power of Open-Source > Speaker - Stanislav Lukyanov > Link - [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#BDC006] > 2) Event: Community over code, Halifax, Canada, October 8 > Scalable Distributed Computing with Groovy Using Apache Ignite > Jeremy Meyer > [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#GR008] > 3) Event: Community over code, Halifax, Canada, October 8 > Whiskey Clustering with Apache Groovy and Apache Ignite > Paul King > [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#GR007] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20186) [Ignite Website] Add Upcoming Events
[ https://issues.apache.org/jira/browse/IGNITE-20186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erlan Aytpaev resolved IGNITE-20186. Resolution: Fixed > [Ignite Website] Add Upcoming Events > > > Key: IGNITE-20186 > URL: https://issues.apache.org/jira/browse/IGNITE-20186 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Evgenia >Assignee: Erlan Aytpaev >Priority: Trivial > > Update [Apache Ignite Events - Meetups, Summit, > Conference|https://ignite.apache.org/events.html#upcoming] page with upcoming > talks. > > 1) Event: Community over code, Halifax, Canada, October 9 > Talk Title - Enhancing Apache Ignite 3.0 with the Power of Open-Source > Speaker - Stanislav Lukyanov > Link - [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#BDC006] > 2) Event: Community over code, Halifax, Canada, October 8 > Scalable Distributed Computing with Groovy Using Apache Ignite > Jeremy Meyer > [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#GR008] > 3) Event: Community over code, Halifax, Canada, October 8 > Whiskey Clustering with Apache Groovy and Apache Ignite > Paul King > [Schedule List – Community Over > Code|https://communityovercode.org/schedule-list/#GR007] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> {quote}This function uses the {{ISO}} definition when first week of year
> should have at least four days and week is started with Monday.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-20234: --- Description: There are some platform-dependent tests: * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK We need to fix them. was:IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
[ https://issues.apache.org/jira/browse/IGNITE-20234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin reassigned IGNITE-20234: -- Assignee: Ivan Gagarkin > ignite-spark-ext: fix platform-dependent tests > --- > > Key: IGNITE-20234 > URL: https://issues.apache.org/jira/browse/IGNITE-20234 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > > There are some platform-dependent tests: > * IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP > * IgniteOptimizationDateFuncSpec.Supported optimized date functions - WEEK > We need to fix them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20234) ignite-spark-ext: fix platform-dependent tests
Ivan Gagarkin created IGNITE-20234: -- Summary: ignite-spark-ext: fix platform-dependent tests Key: IGNITE-20234 URL: https://issues.apache.org/jira/browse/IGNITE-20234 Project: Ignite Issue Type: Bug Reporter: Ivan Gagarkin IgniteOptimizationMathFuncSpec.Supported optimized string functions EXP -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19415) GridCommandHandlerTest should be runnable at other modules
[ https://issues.apache.org/jira/browse/IGNITE-19415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-19415: --- Labels: ise (was: ) > GridCommandHandlerTest should be runnable at other modules > -- > > Key: IGNITE-19415 > URL: https://issues.apache.org/jira/browse/IGNITE-19415 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Snapshot tests use `CommandHandler()` which logs into control-utility module > log path, this cause failures at extended tests at other modules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19339) Get rid of deprecated GridSslContextFactory at public API
[ https://issues.apache.org/jira/browse/IGNITE-19339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-19339: --- Labels: ise (was: ) > Get rid of deprecated GridSslContextFactory at public API > -- > > Key: IGNITE-19339 > URL: https://issues.apache.org/jira/browse/IGNITE-19339 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > GridSslContextFactory deprecated since 2015, and it's time to get rid of it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19335) CommandHandler SSL migration (from GridSslBasicContextFactory to SslContextFactory)
[
https://issues.apache.org/jira/browse/IGNITE-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-19335:
---
Labels: ise (was: )
> CommandHandler SSL migration (from GridSslBasicContextFactory to
> SslContextFactory)
> ---
>
> Key: IGNITE-19335
> URL: https://issues.apache.org/jira/browse/IGNITE-19335
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Almost whole Ignite use {{Factory}} at SLL configuration, while
> CommandHandler still uses {{GridSslContextFactory}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
{quote}This function uses the {{ISO}} definition when first week of year should
have at least four days and week is started with Monday.
{quote}
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> {quote}This function uses the {{ISO}} definition when first week of year
> should have at least four days and week is started with Monday.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],], which returns the
week-based year (locale-specific) from a date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
> Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20225) ignite-spark-ext: 'select weekofyear' returns incorrect week number based on local rules
[
https://issues.apache.org/jira/browse/IGNITE-20225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Gagarkin updated IGNITE-20225:
---
Description:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
was:
According to the Spark documentation, the function
[weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
return a number based on ISO rules:
{quote}A week is considered to start on a Monday and week 1 is the first week
with >3 days.
{quote}
The current implementation of the spark-extension uses
[WEEK|http://www.h2database.com/html/functions.html#week[],] when translate
Spqrk SQL to H2 SQL which returns the week-based year (locale-specific) from a
date/time value.
The extensions should use
[ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
> ignite-spark-ext: 'select weekofyear' returns incorrect week number based on
> local rules
>
>
> Key: IGNITE-20225
> URL: https://issues.apache.org/jira/browse/IGNITE-20225
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Ivan Gagarkin
>Priority: Major
>
> According to the Spark documentation, the function
> [weekofyear|https://spark.apache.org/docs/latest/api/sql/#weekofyear] should
> return a number based on ISO rules:
> {quote}A week is considered to start on a Monday and week 1 is the first week
> with >3 days.
> {quote}
> The current implementation of the spark-extension uses
> [WEEK|http://www.h2database.com/html/functions.html#week[],] when translating
> Spark SQL to H2 SQL, which returns the week-based year (locale-specific) from
> a date/time value.
> The extensions should use
> [ISO_WEEK|http://www.h2database.com/html/functions.html#iso_week]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20229) Get rid of configurations in PlacementDriverManager
[ https://issues.apache.org/jira/browse/IGNITE-20229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-20229: - Reviewer: Vladislav Pyatkov > Get rid of configurations in PlacementDriverManager > --- > > Key: IGNITE-20229 > URL: https://issues.apache.org/jira/browse/IGNITE-20229 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > During the implementation of IGNITE-20114, it was found that the > *org.apache.ignite.internal.placementdriver.PlacementDriverManager* does not > use the configuration that is passed to it, you need to get rid of it. > We can also improve the code next to it and the tests associated with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19840) .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected
[ https://issues.apache.org/jira/browse/IGNITE-19840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19840: Summary: .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected (was: .NET: Thin 3.0: Reload schema when unmapped POCO column is detected) > .NET: Thin 3.0: Reload schema when unmapped Tuple or POCO column is detected > > > Key: IGNITE-19840 > URL: https://issues.apache.org/jira/browse/IGNITE-19840 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19788) Sql. Improve QueryBatchMessage serialisation
[
https://issues.apache.org/jira/browse/IGNITE-19788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-19788:
---
Assignee: Evgeny Stanilovsky
> Sql. Improve QueryBatchMessage serialisation
>
>
> Key: IGNITE-19788
> URL: https://issues.apache.org/jira/browse/IGNITE-19788
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> As of now, java's built-in serialisation is used to marshal rows in
> QueryBatchMessage. It's quite inefficient in terms of the size of serialised
> batch. Besides, network marshaller is unable to estimate the size of
> serialised data in advance, thus serialising the entire batch as a single
> buffer.
> Let's address the part that force marshaller to create a buffer of entire
> batch. Optimal serialisation of each particular row is subject for another
> JIRA case.
> Proposed solution
> * Extend interface {{org.apache.ignite.internal.sql.engine.exec.RowHandler}}
> with method {{ByteBuffer toByteBuffer(RowT row)}}
> * Extend interface
> {{org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory}} with
> method {{RowT create(ByteBuffer buffer)}}
> * Cover {{ArrayRowHandler}} with tests
> * Change return type of
> {{org.apache.ignite.internal.sql.engine.message.QueryBatchMessage#rows}} to
> {{List}}
> * Adjust related code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20233) jdbc: Propagate observable timestamp to sql-engine.
Pavel Pereslegin created IGNITE-20233: - Summary: jdbc: Propagate observable timestamp to sql-engine. Key: IGNITE-20233 URL: https://issues.apache.org/jira/browse/IGNITE-20233 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin We need to pass the observable timestamp from jdbc client to the sql engine. This must be done after the completion of IGNITE-19898. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20232) Java client: Propagate observable timestamp to sql engine using internal API.
Pavel Pereslegin created IGNITE-20232: - Summary: Java client: Propagate observable timestamp to sql engine using internal API. Key: IGNITE-20232 URL: https://issues.apache.org/jira/browse/IGNITE-20232 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin Currently, Java client internally uses a public API to execute sql queries (and some tests also rely on this fact). In order to pass the observable timestamp to the sql engine and keep the code clean, we need to switch to using the internal API and rework the related tests. This must be done after the completion of IGNITE-19898. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19791) Sql. Introduce SqlRowHandler
[
https://issues.apache.org/jira/browse/IGNITE-19791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-19791:
-
Assignee: Pavel Pereslegin
> Sql. Introduce SqlRowHandler
>
>
> Key: IGNITE-19791
> URL: https://issues.apache.org/jira/browse/IGNITE-19791
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> As of now, there is unconditional row conversion from storage format to sql
> internal row format. This conversion is quite expensive, and affects
> performance.
> To address this issue, lets introduce new RowHandler that apart of already
> existing way to create a row will provide one more to simply wrap row in the
> storage format and do the conversion on demand.
> Ultimate goal is to avoid any conversion for queries like {{SELECT * FROM
> table}} .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20196) Sql. Review list of reserved keywords
[ https://issues.apache.org/jira/browse/IGNITE-20196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754978#comment-17754978 ] Konstantin Orlov commented on IGNITE-20196: --- [~jooger] , [~zstan] , folks, take a look please. > Sql. Review list of reserved keywords > - > > Key: IGNITE-20196 > URL: https://issues.apache.org/jira/browse/IGNITE-20196 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-19759 introduces some refactoring to the parser configuration: > reserved keywords are revised and parser is configured with defaults defined > in default_configuration, which makes config.fmpp a bit cleaner. > Let's port all these changes to Ignite-3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754973#comment-17754973 ] Ivan Daschinsky commented on IGNITE-20216: -- [~zaleslaw] If I showed you successful TC run on extensions with all tests and examples, would you approve the move? Since main code is not affected at all. > Moving ML module to ignite-extensions > - > > Key: IGNITE-20216 > URL: https://issues.apache.org/jira/browse/IGNITE-20216 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It is time to move this module to ignite extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20231) Sql. Resolve dependencies before query planning.
Andrey Mashenkov created IGNITE-20231: - Summary: Sql. Resolve dependencies before query planning. Key: IGNITE-20231 URL: https://issues.apache.org/jira/browse/IGNITE-20231 Project: Ignite Issue Type: Improvement Components: sql Reporter: Andrey Mashenkov As for now, we resolve dependencies after cutting a query plan into fragments. After switching to Catalog, we will have no real tables/indexes available at planning stage (just descriptors). Planner requires table statistics, which is broken after switching to the Catalog. Let's resolve all the dependencies before start planner to fix table statistics. Also, ExecutableTableImpl instantiates ScannableTable and UpdatableTable regardless if the table is used for scan or update. Let's make lazy instantiation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754971#comment-17754971 ] Ivan Daschinsky commented on IGNITE-20216: -- Peter Ivanov and Me are working on ML Extensions tests on TC, works is in progress, but is going to be finished soon > Moving ML module to ignite-extensions > - > > Key: IGNITE-20216 > URL: https://issues.apache.org/jira/browse/IGNITE-20216 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It is time to move this module to ignite extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754970#comment-17754970 ] Ivan Daschinsky commented on IGNITE-20216: -- [~zaleslaw] I have prepared 2 PRs (to ignite-extensions and AI) 1. Updated dependencies 2. Changed java blas integration to [dev.ludovic.netlib|https://github.com/luhenry/netlib] (see details here. https://spark.apache.org/docs/latest/ml-linalg-guide.html). It loads blas using `dlopen`, doesn't have licence issues (MIT). Worked ok with Intel MKL (tested on ubuntu 22.04) Actually, nothing was changed and i've faced no difficulties except some minor chores with tests. > Moving ML module to ignite-extensions > - > > Key: IGNITE-20216 > URL: https://issues.apache.org/jira/browse/IGNITE-20216 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It is time to move this module to ignite extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20086) Ensure mockito resources cleaned after tests.
[ https://issues.apache.org/jira/browse/IGNITE-20086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20086: -- Fix Version/s: 3.0.0-beta2 > Ensure mockito resources cleaned after tests. > -- > > Key: IGNITE-20086 > URL: https://issues.apache.org/jira/browse/IGNITE-20086 > Project: Ignite > Issue Type: Test >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3, stability > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Tests must clean up inline mocks on tear-down. > Otherwise it may lead to OOM, see IGNITE-20065. > Let's add an arch-test to be sure all the test, which use mocks, inherits > BaseIgniteAbstractTest class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20216) Moving ML module to ignite-extensions
[ https://issues.apache.org/jira/browse/IGNITE-20216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754952#comment-17754952 ] Alexey Zinoviev commented on IGNITE-20216: -- Hi, as PMC and maintainer of this module -1 for removal +1 for moving to an extension, if it is compatible with the Ignite and could be compiled separately from other extension modules Some facts: * nobody updates it for latest 3 years—it's true * classic ML algorithms are not changed in the latest 3 years (we have not supported DL as a part of the module, it's not a goal, Random Forest was not changed latest 20 years) as a CSV parsing or JDBC * Tensorflow integration was removed 3 years ago * some people contacted me a few weeks ago to fix or develop some features in the Ignite ML urgent, but I have no time to do it urgent * I met some companies who used IgniteML in 2021 and 2022 including my job interview:) * I agree with the blas issue, great if somebody could update it, again I could help with testing I could help with the review of the PR on the github with moving to an extension, please assign on me @zaleslaw, but now I am on vacation, could do it in September > Moving ML module to ignite-extensions > - > > Key: IGNITE-20216 > URL: https://issues.apache.org/jira/browse/IGNITE-20216 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It is time to move this module to ignite extensions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20230) Flaky testDestroyPartitionStoragesOnEvictNode
Konstantin Orlov created IGNITE-20230:
-
Summary: Flaky testDestroyPartitionStoragesOnEvictNode
Key: IGNITE-20230
URL: https://issues.apache.org/jira/browse/IGNITE-20230
Project: Ignite
Issue Type: Bug
Reporter: Konstantin Orlov
{code:java}
Wanted but not invoked:
testMvTableStorage.destroyPartition(0);
-> at
org.apache.ignite.internal.storage.impl.TestMvTableStorage.destroyPartition(TestMvTableStorage.java:123)
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7438015?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20229) Get rid of configurations in PlacementDriverManager
Kirill Tkalenko created IGNITE-20229: Summary: Get rid of configurations in PlacementDriverManager Key: IGNITE-20229 URL: https://issues.apache.org/jira/browse/IGNITE-20229 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 During the implementation of IGNITE-20114, it was found that the *org.apache.ignite.internal.placementdriver.PlacementDriverManager* does not use the configuration that is passed to it, you need to get rid of it. We can also improve the code next to it and the tests associated with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Issue Type: Task (was: Bug) > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19807: Description: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. They currently are used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and migrate completely to the first. was: We currently have several ways to check if a user has permission to perform an operation. 1. IgniteSecurity#authorize methods that delegate permission check to security plugin. 2. SecurityContext#*OperationAllowed methods. That are currently is used just for one check. This approach assumes that granted permissions set is returned during user authentication and remains immutable. Let's deprecate the second authorization approach and migrate completely to the first. > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. They currently are used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19807) Deprecate legacy authorization approach through Security Context.
[ https://issues.apache.org/jira/browse/IGNITE-19807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-19807: --- Assignee: Mikhail Petrov > Deprecate legacy authorization approach through Security Context. > - > > Key: IGNITE-19807 > URL: https://issues.apache.org/jira/browse/IGNITE-19807 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > We currently have several ways to check if a user has permission to perform > an operation. > 1. IgniteSecurity#authorize methods that delegate permission check to > security plugin. > 2. SecurityContext#*OperationAllowed methods. That are currently is used just > for one check. This approach assumes that granted permissions set is > returned during user authentication and remains immutable. > Let's deprecate the second authorization approach and migrate completely to > the first. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20228) Fix flaky test KillCommandsControlShTest
Maksim Timonin created IGNITE-20228: --- Summary: Fix flaky test KillCommandsControlShTest Key: IGNITE-20228 URL: https://issues.apache.org/jira/browse/IGNITE-20228 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20196) Sql. Review list of reserved keywords
[ https://issues.apache.org/jira/browse/IGNITE-20196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-20196: -- Summary: Sql. Review list of reserved keywords (was: Sql. Review list of reserver keywords) > Sql. Review list of reserved keywords > - > > Key: IGNITE-20196 > URL: https://issues.apache.org/jira/browse/IGNITE-20196 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > IGNITE-19759 introduces some refactoring to the parser configuration: > reserved keywords are revised and parser is configured with defaults defined > in default_configuration, which makes config.fmpp a bit cleaner. > Let's port all these changes to Ignite-3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20227) Sql. Upgrade JavaCC version
Konstantin Orlov created IGNITE-20227:
-
Summary: Sql. Upgrade JavaCC version
Key: IGNITE-20227
URL: https://issues.apache.org/jira/browse/IGNITE-20227
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
After IGNITE-20196, the version of JavaCC was decreased from 4.2 to 4.0. The
reason is changes in generated {{jj_add_error_token}} method:
{code:java}
// generated by JavaCC 4.0
private void jj_add_error_token(int kind, int pos) {
if (pos >= 100) return;
if (pos == jj_endpos + 1) {
jj_lasttokens[jj_endpos++] = kind;
} else if (jj_endpos != 0) {
jj_expentry = new int[jj_endpos];
for (int i = 0; i < jj_endpos; i++) {
jj_expentry[i] = jj_lasttokens[i];
}
boolean exists = false;
for (java.util.Enumeration e = jj_expentries.elements();
e.hasMoreElements();) {
int[] oldentry = (int[])(e.nextElement());
if (oldentry.length == jj_expentry.length) {
exists = true;
for (int i = 0; i < jj_expentry.length; i++) {
if (oldentry[i] != jj_expentry[i]) {
exists = false;
break;
}
}
if (exists) break;
}
}
if (!exists) jj_expentries.addElement(jj_expentry);
if (pos != 0) jj_lasttokens[(jj_endpos = pos) - 1] = kind;
}
}
// generated by JavaCC 4.2
private void jj_add_error_token(int kind, int pos) {
if (pos >= 100) return;
if (pos == jj_endpos + 1) {
jj_lasttokens[jj_endpos++] = kind;
} else if (jj_endpos != 0) {
jj_expentry = new int[jj_endpos];
for (int i = 0; i < jj_endpos; i++) {
jj_expentry[i] = jj_lasttokens[i];
}
jj_entries_loop: for (java.util.Iterator it = jj_expentries.iterator();
it.hasNext();) {
int[] oldentry = (int[])(it.next());
if (oldentry.length == jj_expentry.length) {
for (int i = 0; i < jj_expentry.length; i++) {
if (oldentry[i] != jj_expentry[i]) {
continue jj_entries_loop;
}
}
jj_expentries.add(jj_expentry);
break jj_entries_loop;
}
}
if (pos != 0) jj_lasttokens[(jj_endpos = pos) - 1] = kind;
}
}
{code}
In JavaCC 4.0, if collection {{jj_expentries}} is empty, all visited tokes
(represented by {{jj_expentry}}) will be added to these collection. In JavaCC
4.2, the collection {{jj_expentries}} is updated only if it is _not_ empty.
This change broke
{{org.apache.calcite.sql.parser.SqlAbstractParserImpl.Metadata}}, because
initialisation of meta is relied on properly filled {{jj_expentries}}
collection. Besides, this affects generation of parsing exception: without
{{jj_expentries}}, only tokens reachable by LA(1) will be presented in possible
options (currently, default LA is set to 2).
Let's figure out what the benefits would be with upgrading to the most recent
version (7.0.12 at the time the ticket was created), and if any, make an
upgrade plan.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
