[jira] [Assigned] (IGNITE-18830) GridQueryProcessor logs unnecessary error message
[
https://issues.apache.org/jira/browse/IGNITE-18830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhangJian He reassigned IGNITE-18830:
-
Assignee: ZhangJian He
> GridQueryProcessor logs unnecessary error message
> -
>
> Key: IGNITE-18830
> URL: https://issues.apache.org/jira/browse/IGNITE-18830
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Benjamin Garaude
>Assignee: ZhangJian He
>Priority: Major
> Labels: newbie
> Time Spent: 1h
> Remaining Estimate: 0h
>
> GridQueryProcessor logs error message of type:
> {quote}07:24:47.571 [build-idx-runner-#123%default-grid%|#123%default-grid%]
> ERROR o.a.i.i.p.q.GridQueryProcessor - Failed to rebuild indexes for cache
> [name=...]
> {quote}
> But there is no underlying error.
> After a quick analysis, this log is emitted by
> org.apache.ignite.internal.processors.query.GridQueryProcessor.java:2640
> If the err is null and log.isInfoEnabled() is false, (which is our case) then
> it misses the if at line 2637, and goes to the else at line 2640.
> This is likely a log issue in that class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19501) SchemaManager should use CatalogService for building BinaryRow descriptors
[ https://issues.apache.org/jira/browse/IGNITE-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-19501: -- Assignee: Roman Puchkovskiy > SchemaManager should use CatalogService for building BinaryRow descriptors > -- > > Key: IGNITE-19501 > URL: https://issues.apache.org/jira/browse/IGNITE-19501 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > As of now, SchemaManager uses configuration data to create > BinaryRow/BinaryTuple descriptors. > Let's make SchemaManager and SchemaRegistry using Catalog data instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19984) IncrementalVV#dependingOn doesn't work sometimes*
[ https://issues.apache.org/jira/browse/IGNITE-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743168#comment-17743168 ] Roman Puchkovskiy commented on IGNITE-19984: The patch looks good to me > IncrementalVV#dependingOn doesn't work sometimes* > - > > Key: IGNITE-19984 > URL: https://issues.apache.org/jira/browse/IGNITE-19984 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 1h > Remaining Estimate: 0h > > Currently, this method is based on the following invariant: > - no "update" closures of VV will be executed until registry triggers the > token's completion. > This statement is false, update closures may be executed immediately. And > this is fine IMO. > So, we must get rid of "dependingOn" thing and provide other ways of > expressing explicit dependencies, or expand its documentation to reflect the > fact, that there are only dependencies for already completed futures, not for > futures in-progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19850) Fix metastorage unable to recover with multiple ms nodes
[ https://issues.apache.org/jira/browse/IGNITE-19850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov reassigned IGNITE-19850: --- Assignee: Semyon Danilov > Fix metastorage unable to recover with multiple ms nodes > > > Key: IGNITE-19850 > URL: https://issues.apache.org/jira/browse/IGNITE-19850 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > > On recovery, metastorage refreshes raft leader to access latest metastorage > revision. If there is no leader yet, or not all metastorage nodes are online, > recovery won't proceed. If 3 nodes are being started synchronously and all 3 > nodes are metastorage nodes, then they will fail to start. > The easiest solution would be to not start nodes synchronously. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19985) Allow single empty line at the end of the SQL test script
[
https://issues.apache.org/jira/browse/IGNITE-19985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-19985.
Fix Version/s: 3.0.0-beta2
Resolution: Fixed
Thanks, merged into main: 45ab580e4ecd6d6e78599b06cd44c29eeb4c565d
> Allow single empty line at the end of the SQL test script
> -
>
> Key: IGNITE-19985
> URL: https://issues.apache.org/jira/browse/IGNITE-19985
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If SQL test script in the {{runner/src/integrationTest/sql}} ends with
> {{}} followed by the single line break, script runner throws NPE.
> Let's allow single line break meaning empty result set of the last query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19984) IncrementalVV#dependingOn doesn't work sometimes*
[ https://issues.apache.org/jira/browse/IGNITE-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-19984: --- Reviewer: Roman Puchkovskiy > IncrementalVV#dependingOn doesn't work sometimes* > - > > Key: IGNITE-19984 > URL: https://issues.apache.org/jira/browse/IGNITE-19984 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Currently, this method is based on the following invariant: > - no "update" closures of VV will be executed until registry triggers the > token's completion. > This statement is false, update closures may be executed immediately. And > this is fine IMO. > So, we must get rid of "dependingOn" thing and provide other ways of > expressing explicit dependencies, or expand its documentation to reflect the > fact, that there are only dependencies for already completed futures, not for > futures in-progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19984) IncrementalVV#dependingOn doesn't work sometimes*
[ https://issues.apache.org/jira/browse/IGNITE-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-19984: -- Assignee: Ivan Bessonov > IncrementalVV#dependingOn doesn't work sometimes* > - > > Key: IGNITE-19984 > URL: https://issues.apache.org/jira/browse/IGNITE-19984 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Currently, this method is based on the following invariant: > - no "update" closures of VV will be executed until registry triggers the > token's completion. > This statement is false, update closures may be executed immediately. And > this is fine IMO. > So, we must get rid of "dependingOn" thing and provide other ways of > expressing explicit dependencies, or expand its documentation to reflect the > fact, that there are only dependencies for already completed futures, not for > futures in-progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19928) Fix method signature related to creating a new error group and registering a new error code
[
https://issues.apache.org/jira/browse/IGNITE-19928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743107#comment-17743107
]
Alexander Lapin commented on IGNITE-19928:
--
[~slava.koptilin] LGTM!
> Fix method signature related to creating a new error group and registering a
> new error code
> ---
>
> Key: IGNITE-19928
> URL: https://issues.apache.org/jira/browse/IGNITE-19928
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The error group and the error code in the group are defined by two bytes each
> (in
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-84%3A+Error+handling).
> On the other hand, the following methods define these parameters as int:
> {code:java}
> /**
> * Creates a new error group with the given {@code groupName} and {@code
> groupCode}.
> *
> * @param groupName Group name to be created.
> * @param groupCode Group code to be created.
> * @return New error group.
> * @throws IllegalArgumentException If the specified name or group code
> is already registered.
> * or {@code groupCode} is greater than 0x or less than or equal
> to 0.
> * Also, this exception is thrown if the given {@code groupName} is
> {@code null} or empty.
> */
> public static synchronized ErrorGroup newGroup(String groupName, int
> groupCode)
> /**
> * Registers a new error code within this error group.
> *
> * @param errorCode Error code to be registered.
> * @return Full error code which includes group code and specific error
> code.
> * @throws IllegalArgumentException If the given {@code errorCode} is
> already registered
> * or {@code errorCode} is greater than 0x or less than or equal
> to 0.
> */
> public int registerErrorCode(int errorCode)
> {code}
> This fact leads to runtime checks that the error code and error group
> identifier is greater or equal to 0 and less than or equal to 0x. It can
> be avoided by changing the type from `int` to `short` obviously. All related
> places should be corrected accordingly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19984) IncrementalVV#dependingOn doesn't work sometimes*
[ https://issues.apache.org/jira/browse/IGNITE-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-19984: --- Summary: IncrementalVV#dependingOn doesn't work sometimes* (was: IncrementalVV#dependingOn doesn't work) > IncrementalVV#dependingOn doesn't work sometimes* > - > > Key: IGNITE-19984 > URL: https://issues.apache.org/jira/browse/IGNITE-19984 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Currently, this method is based on the following invariant: > - no "update" closures of VV will be executed until registry triggers the > token's completion. > This statement is false, update closures may be executed immediately. And > this is fine IMO. > So, we must get rid of "dependingOn" thing and provide other ways of > expressing explicit dependencies, or expand its documentation to reflect the > fact, that there are only dependencies for already completed futures, not for > futures in-progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19977) Defragmentation can't use 1 thread.
[
https://issues.apache.org/jira/browse/IGNITE-19977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743087#comment-17743087
]
Mikhail Petrov commented on IGNITE-19977:
-
[~vladsz83] Thank you for the contribution.
> Defragmentation can't use 1 thread.
> ---
>
> Key: IGNITE-19977
> URL: https://issues.apache.org/jira/browse/IGNITE-19977
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.16
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * Sets maximum number of partitions which can be defragmented at the
> same time.
> *
> * @param defragmentationThreadPoolSize Maximum number of partitions
> which can be defragmented at the same time.
> * Default is {@link
> DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
> * @return {@code this} for chaining.
> */
> public DataStorageConfiguration setDefragmentationThreadPoolSize(int
> defragmentationThreadPoolSize) {
> A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
> pool size must be greater or equal to 1.");
> this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
> return this;
> }
> {code}
> should compare with 0:
> {code:java}
> A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
> must be greater or equal to 1.");
> {code}
> Defragmentation actually works with just 1 thread. Also, 1 thread seems to be
> a workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I
> couldn't detect the failure with one defragmentation worker.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19759) Calcite engine. Review list of reserved keywords
[
https://issues.apache.org/jira/browse/IGNITE-19759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743086#comment-17743086
]
Ignite TC Bot commented on IGNITE-19759:
{panel:title=Branch: [pull/10839/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10839/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=723]]
* {color:#013220}IgniteCalciteTestSuite: SqlReservedWordsTest.testReservedWords
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7254801buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Review list of reserved keywords
>
>
> Key: IGNITE-19759
> URL: https://issues.apache.org/jira/browse/IGNITE-19759
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> For the calcite engine we have too strict list of reserved keywords. For
> example, lexems such as "TYPE" and "OPTIONS" are reserved keywords and can't
> be used as columns or table names. But "TYPE" is frequently used by users as
> column name and we should exclude it from the list of reserved keywords (add
> it to non-reserved keywords, see {{config.fmpp}} file {{nonReservedKeywords}}
> section). Other vendors allow to use "TYPE" as column name.
> On the other hand Calcite-based SQL engine in Ignite now allows to use some
> keywords which should not be allowed as table or column names, for example,
> such query executes without any problem:
> {noformat}
> sql("create table true (like varchar, and int, as int)");
> sql("insert into true values ('1', 1, 1)");
> sql("select as as as from true where like like '%' and and between
> and and and");
> {noformat}
> Current list of reserved keywords copied from "Babel" dialect of Calcite.
> Calcite has "default" dialect with default list of reserved keywords (see
> [1]), this list is close to SQL stantard, but looks quite strict too.
> Other vendors lists are less restrictive. For example, in SQL standard
> build-in functions and all built-in types are reserved keywords, in MySQL
> built-in functions are not reserved, but build-in types are reserved, in
> PostgreeSQL only minimal amount of keywords required for correct parsing are
> reserved (built-in functions are not reserved, built-in types are not
> reserved). See comparison table [2]. Our old SQL engine based on H2 database
> and H2 reserved keywords (see [3]). H2 approach is close to PostgreeSQL
> approach (minimal amount of keywords are reserved). I propose to use such an
> approach for Ignite too, to maximaze compatibility between our SQL engines.
> [1] https://calcite.apache.org/docs/reference.html#keywords
> [2] https://en.wikipedia.org/wiki/List_of_SQL_reserved_words
> [3] https://www.h2database.com/html/advanced.html#keywords
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19985) Allow single empty line at the end of the SQL test script
Vadim Pakhnushev created IGNITE-19985:
-
Summary: Allow single empty line at the end of the SQL test script
Key: IGNITE-19985
URL: https://issues.apache.org/jira/browse/IGNITE-19985
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
If SQL test script in the {{runner/src/integrationTest/sql}} ends with {{}}
followed by the single line break, script runner throws NPE.
Let's allow single line break meaning empty result set of the last query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17298) Support BOOLEAN datatype.
[ https://issues.apache.org/jira/browse/IGNITE-17298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17298: -- Fix Version/s: 3.0.0-beta2 > Support BOOLEAN datatype. > - > > Key: IGNITE-17298 > URL: https://issues.apache.org/jira/browse/IGNITE-17298 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Andrey Mashenkov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 4h > Remaining Estimate: 0h > > For now, BOOLEAN column is not supported by storage. > As a simple option, we can store it as a single byte value. > We need to add BOOLEAN to native types and add appropriate methods to Tuple, > BinaryTupleParser and BinaryTupleBuilder. > We should have tests for all API: KV View, Binary View, Record View, SQL and > JDBC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19823) DeploymentUnitNotFoundException is internal, does not propagate to client
[ https://issues.apache.org/jira/browse/IGNITE-19823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-19823: Assignee: Andrey N. Gura (was: Vyacheslav Koptilin) > DeploymentUnitNotFoundException is internal, does not propagate to client > - > > Key: IGNITE-19823 > URL: https://issues.apache.org/jira/browse/IGNITE-19823 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Andrey N. Gura >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * *DeploymentUnitNotFoundException* is in internal package, but it is a > "public" exception which is thrown when the user specifies an unknown unit > name/version. > * It is remapped to *ClassNotFoundException* in > https://github.com/apache/ignite-3/blob/f90f949b342bd1fa864d342c4078b393f4ed23c0/modules/compute/src/main/java/org/apache/ignite/internal/compute/ClassLoaderExceptionsMapper.java#L50 > As a result, traceId and error code are not propagated to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19500) IndexManager should listen CatalogService events instead of configuration
[ https://issues.apache.org/jira/browse/IGNITE-19500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-19500: Assignee: Kirill Tkalenko (was: Ivan Bessonov) > IndexManager should listen CatalogService events instead of configuration > - > > Key: IGNITE-19500 > URL: https://issues.apache.org/jira/browse/IGNITE-19500 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > As of now, IndexManager listens configuration events to create internal > structures. > Let's make IndexManager listens CatalogService events instead. > Note: Some tests may fails due to changed guarantees and related ticked > incompletion. So, let's do this in a separate feature branch. > *Some thoughts:* > For some simplification of the transition to the catalog, I thought that > adding a table ID from the configuration and this ID when executing an > catalog event to delete a table can help us. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19955) Fix create zone on restart rewrites existing data nodes because of trigger key inconsistnecy
[
https://issues.apache.org/jira/browse/IGNITE-19955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19955:
-
Summary: Fix create zone on restart rewrites existing data nodes because of
trigger key inconsistnecy (was: Fix create zone on restart rewrites existing
data nodes)
> Fix create zone on restart rewrites existing data nodes because of trigger
> key inconsistnecy
>
>
> Key: IGNITE-19955
> URL: https://issues.apache.org/jira/browse/IGNITE-19955
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Currently we have the logic for initialisation of newly created zone that it
> writes keys
> {noformat}
> zoneDataNodesKey(zoneId), zoneScaleUpChangeTriggerKey(zoneId),
> zoneScaleDownChangeTriggerKey(zoneId), zonesChangeTriggerKey(zoneId)
> {noformat}
> to metastorage, and condition is
> {noformat}
> static CompoundCondition triggerKeyConditionForZonesChanges(long
> revision, int zoneId) {
> return or(
> notExists(zonesChangeTriggerKey(zoneId)),
>
> value(zonesChangeTriggerKey(zoneId)).lt(ByteUtils.longToBytes(revision))
> );
> {noformat}
> Recovery process implies that the create zone event will be processed again,
> but with the higher revision, so data nodes will be rewritten.
> We need to handle this situation, so data nodes will be consistent after
> restart.
> Possible solution is to change condition to
> {noformat}
> static SimpleCondition triggerKeyConditionForZonesCreation(long revision,
> int zoneId) {
> return notExists(zonesChangeTriggerKey(zoneId));
> }
> static SimpleCondition triggerKeyConditionForZonesDelete(int zoneId) {
> return exists(zonesChangeTriggerKey(zoneId));
> }
> {noformat}
>
> so we could not rely on revision and check only existence of the key, when we
> create or remove zone. The problem in this solution is that reordering of the
> create and remove on some node could lead to not consistent state for zones
> key in metastorage
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19984) IncrementalVV#dependingOn doesn't work
[ https://issues.apache.org/jira/browse/IGNITE-19984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-19984: --- Description: Currently, this method is based on the following invariant: - no "update" closures of VV will be executed until registry triggers the token's completion. This statement is false, update closures may be executed immediately. And this is fine IMO. So, we must get rid of "dependingOn" thing and provide other ways of expressing explicit dependencies, or expand its documentation to reflect the fact, that there are only dependencies for already completed futures, not for futures in-progress. was: Currently, this method is based on the following invariant: - no "update" closures of VV will be executed until registry triggers the token's completion. This statement is false, update closures may be executed immediately. And this is fine IMO. So, we must get rid of "dependingOn" thing and provide other ways of expressing explicit dependencies. > IncrementalVV#dependingOn doesn't work > -- > > Key: IGNITE-19984 > URL: https://issues.apache.org/jira/browse/IGNITE-19984 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > Currently, this method is based on the following invariant: > - no "update" closures of VV will be executed until registry triggers the > token's completion. > This statement is false, update closures may be executed immediately. And > this is fine IMO. > So, we must get rid of "dependingOn" thing and provide other ways of > expressing explicit dependencies, or expand its documentation to reflect the > fact, that there are only dependencies for already completed futures, not for > futures in-progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19397) Thin 3.0: Return an error to client when outdated schema is used
[
https://issues.apache.org/jira/browse/IGNITE-19397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743054#comment-17743054
]
Igor Sapego commented on IGNITE-19397:
--
Approved, left a minor comment.
> Thin 3.0: Return an error to client when outdated schema is used
>
>
> Key: IGNITE-19397
> URL: https://issues.apache.org/jira/browse/IGNITE-19397
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> IGNITE-19241 attempts to solve "client inserts data with old schema" problem
> by sending the latest schema version with every tuple operation response.
> However, this approach is not reliable, for example:
> 1. *var view = client.tables().table("FOO").recordView(); view.upsert(...)* -
> now client knows schema v1
> 2. *client.sql().exec("ALTER TABLE FOO ADD COLUMN NEWCOL INT");* - client
> alters the table, but does not know about schema v2 with new column
> 3. *view.upsert(Tuple.create().set("key", 1).set("NEWCOL", 100))* - v1 is
> used to send data to the server, NEWCOL is ignored, data is lost. Response
> says that schema v2 is available, but it is too late.
> To ensure that the latest schema is used by the client and no data is lost,
> we should throw an exception (with a specific error code) from
> *TupleMarshallerImpl* when specified schema version is outdated: client will
> receive an exception (*with specific schema version in it*), load the
> *specified* schema, and retry the operation.
> This exception should never be thrown to the user code. We can use an
> interface on *org.apache.ignite.client.handler.requests.table.ClientTuple*,
> something like *MatchingSchemaRequired*, and *TupleMarshallerImpl* will only
> perform the check in that case.
> IGNITE-19241 should be probably reverted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19984) IncrementalVV#dependingOn doesn't work
Ivan Bessonov created IGNITE-19984: -- Summary: IncrementalVV#dependingOn doesn't work Key: IGNITE-19984 URL: https://issues.apache.org/jira/browse/IGNITE-19984 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Currently, this method is based on the following invariant: - no "update" closures of VV will be executed until registry triggers the token's completion. This statement is false, update closures may be executed immediately. And this is fine IMO. So, we must get rid of "dependingOn" thing and provide other ways of expressing explicit dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18453) Query executor thread synchronously waits for leaders on query mapping.
[
https://issues.apache.org/jira/browse/IGNITE-18453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-18453:
--
Assignee: (was: Evgeny Stanilovsky)
> Query executor thread synchronously waits for leaders on query mapping.
> ---
>
> Key: IGNITE-18453
> URL: https://issues.apache.org/jira/browse/IGNITE-18453
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> If some table/partition lost the quorum, sql-execution-pool threads may stuck
> and prevent other queries over another table/partition from being executed.
> {noformat}
> "%node3%sql-execution-pool-1@65077" daemon prio=5 tid=0x8b81 nid=NA waiting
> java.lang.Thread.State: WAITING
> at jdk.internal.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1796)
> at
> java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3128)
> at
> java.util.concurrent.CompletableFuture.waitingGet(CompletableFuture.java:1823)
> at
> java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2043)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.awaitLeaderInitialization(InternalTableImpl.java:1055)
> at
> org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.assignments(InternalTableImpl.java:1004)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.partitionedGroup(IgniteTableImpl.java:484)
> at
> org.apache.ignite.internal.sql.engine.schema.IgniteTableImpl.colocationGroup(IgniteTableImpl.java:228)
> at
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.getFragmentMapping(IgniteMdFragmentMapping.java:228)
> at
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMapping(IgniteMdFragmentMapping.java:210)
> at
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping_$(Unknown
> Source:-1)
> at
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping(Unknown
> Source:-1)
> at
> org.apache.ignite.internal.sql.engine.metadata.RelMetadataQueryEx.fragmentMapping(RelMetadataQueryEx.java:93)
> at
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMappingForMetadataQuery(IgniteMdFragmentMapping.java:70)
> at
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMapping(IgniteMdFragmentMapping.java:101)
> at
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping_$(Unknown
> Source:-1)
> at
> org.apache.calcite.rel.metadata.janino.GeneratedMetadata_FragmentMappingMetadataHandler.fragmentMapping(Unknown
> Source:-1)
> at
> org.apache.ignite.internal.sql.engine.metadata.RelMetadataQueryEx.fragmentMapping(RelMetadataQueryEx.java:93)
> at
> org.apache.ignite.internal.sql.engine.metadata.IgniteMdFragmentMapping.fragmentMappingForMetadataQuery(IgniteMdFragmentMapping.java:70)
> at
> org.apache.ignite.internal.sql.engine.prepare.Fragment.mapping(Fragment.java:111)
> at
> org.apache.ignite.internal.sql.engine.prepare.Fragment.map(Fragment.java:159)
> at
> org.apache.ignite.internal.sql.engine.prepare.QueryTemplate.map(QueryTemplate.java:93)
> at
> org.apache.ignite.internal.sql.engine.prepare.QueryTemplate.map(QueryTemplate.java:71)
> at
> org.apache.ignite.internal.sql.engine.prepare.AbstractMultiStepPlan.init(AbstractMultiStepPlan.java:108)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$7(ExecutionServiceImpl.java:569)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager$$Lambda$2890.610213979.run(Unknown
> Source:-1)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl$$Lambda$1902.2051055833.run(Unknown
> Source:-1)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19975) Create abstract SSL context factory to make it possible to implement custom logic for trust/key managers creation.
[ https://issues.apache.org/jira/browse/IGNITE-19975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19975: Release Note: Removed deprecated "ssl.key.algorithm" Ignite system property - "ssl.KeyManagerFactory.algorithm" is used instead (was: Removed deprecated IGNITE_KEY_ALGORITHM_PROPERTY Ignite system property) > Create abstract SSL context factory to make it possible to implement custom > logic for trust/key managers creation. > -- > > Key: IGNITE-19975 > URL: https://issues.apache.org/jira/browse/IGNITE-19975 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SslContextFactory currently provides implementations of a trust/key manager > loading mechanism based on getting key material from files only. > In some cases, the key material can be obtained through some external storage > that has nothing to do with file paths. Let's create an abstract > implementation of SslContextFactory that will allow the user to implement > their own approach for creating key/trust managers. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19975) Create abstract SSL context factory to make it possible to implement custom logic for trust/key managers creation.
[ https://issues.apache.org/jira/browse/IGNITE-19975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19975: Fix Version/s: 2.16 > Create abstract SSL context factory to make it possible to implement custom > logic for trust/key managers creation. > -- > > Key: IGNITE-19975 > URL: https://issues.apache.org/jira/browse/IGNITE-19975 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > Fix For: 2.16 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SslContextFactory currently provides implementations of a trust/key manager > loading mechanism based on getting key material from files only. > In some cases, the key material can be obtained through some external storage > that has nothing to do with file paths. Let's create an abstract > implementation of SslContextFactory that will allow the user to implement > their own approach for creating key/trust managers. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19975) Create abstract SSL context factory to make it possible to implement custom logic for trust/key managers creation.
[ https://issues.apache.org/jira/browse/IGNITE-19975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19975: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Create abstract SSL context factory to make it possible to implement custom > logic for trust/key managers creation. > -- > > Key: IGNITE-19975 > URL: https://issues.apache.org/jira/browse/IGNITE-19975 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > SslContextFactory currently provides implementations of a trust/key manager > loading mechanism based on getting key material from files only. > In some cases, the key material can be obtained through some external storage > that has nothing to do with file paths. Let's create an abstract > implementation of SslContextFactory that will allow the user to implement > their own approach for creating key/trust managers. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19975) Create abstract SSL context factory to make it possible to implement custom logic for trust/key managers creation.
[ https://issues.apache.org/jira/browse/IGNITE-19975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-19975: Release Note: Removed deprecated IGNITE_KEY_ALGORITHM_PROPERTY Ignite system property > Create abstract SSL context factory to make it possible to implement custom > logic for trust/key managers creation. > -- > > Key: IGNITE-19975 > URL: https://issues.apache.org/jira/browse/IGNITE-19975 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > SslContextFactory currently provides implementations of a trust/key manager > loading mechanism based on getting key material from files only. > In some cases, the key material can be obtained through some external storage > that has nothing to do with file paths. Let's create an abstract > implementation of SslContextFactory that will allow the user to implement > their own approach for creating key/trust managers. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19977) Defragmentation can't use 1 thread.
[
https://issues.apache.org/jira/browse/IGNITE-19977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-19977:
--
Release Note: Defragmentation can now use minimun 1 working thread.
Description:
{code:java}
/**
* Sets maximum number of partitions which can be defragmented at the same
time.
*
* @param defragmentationThreadPoolSize Maximum number of partitions which
can be defragmented at the same time.
* Default is {@link
DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
* @return {@code this} for chaining.
*/
public DataStorageConfiguration setDefragmentationThreadPoolSize(int
defragmentationThreadPoolSize) {
A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
pool size must be greater or equal to 1.");
this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
return this;
}
{code}
should compare with 0:
{code:java}
A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
must be greater or equal to 1.");
{code}
Defragmentation actually works with just 1 thread. Also, 1 thread seems to be a
workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I couldn't
detect the failure with one defragmentation worker.
was:
{code:java}
/**
* Sets maximum number of partitions which can be defragmented at the same
time.
*
* @param defragmentationThreadPoolSize Maximum number of partitions which
can be defragmented at the same time.
* Default is {@link
DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
* @return {@code this} for chaining.
*/
public DataStorageConfiguration setDefragmentationThreadPoolSize(int
defragmentationThreadPoolSize) {
A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
pool size must be greater or equal to 1.");
this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
return this;
}
{code}
should compare with 0:
{code:java}
A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
must be greater or equal to 1.");
{code}
Defragmentation actually works with just 1 thread. Also, 1 thread seems to be a
workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I couldn't
detect the failure with one defragmentation worker.
> Defragmentation can't use 1 thread.
> ---
>
> Key: IGNITE-19977
> URL: https://issues.apache.org/jira/browse/IGNITE-19977
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.16
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * Sets maximum number of partitions which can be defragmented at the
> same time.
> *
> * @param defragmentationThreadPoolSize Maximum number of partitions
> which can be defragmented at the same time.
> * Default is {@link
> DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
> * @return {@code this} for chaining.
> */
> public DataStorageConfiguration setDefragmentationThreadPoolSize(int
> defragmentationThreadPoolSize) {
> A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
> pool size must be greater or equal to 1.");
> this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
> return this;
> }
> {code}
> should compare with 0:
> {code:java}
> A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
> must be greater or equal to 1.");
> {code}
> Defragmentation actually works with just 1 thread. Also, 1 thread seems to be
> a workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I
> couldn't detect the failure with one defragmentation worker.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19977) Defragmentation can't use 1 thread.
[
https://issues.apache.org/jira/browse/IGNITE-19977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-19977:
--
Fix Version/s: 2.16
> Defragmentation can't use 1 thread.
> ---
>
> Key: IGNITE-19977
> URL: https://issues.apache.org/jira/browse/IGNITE-19977
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Fix For: 2.16
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * Sets maximum number of partitions which can be defragmented at the
> same time.
> *
> * @param defragmentationThreadPoolSize Maximum number of partitions
> which can be defragmented at the same time.
> * Default is {@link
> DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
> * @return {@code this} for chaining.
> */
> public DataStorageConfiguration setDefragmentationThreadPoolSize(int
> defragmentationThreadPoolSize) {
> A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
> pool size must be greater or equal to 1.");
> this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
> return this;
> }
> {code}
> should compare with 0:
> {code:java}
> A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
> must be greater or equal to 1.");
> {code}
> Defragmentation actually works with just 1 thread. Also, 1 thread seems to be
> a workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I
> couldn't detect the failure with one defragmentation worker.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19971) Flaky ItNodeTest#testLeaseReadAfterSegmentation
[
https://issues.apache.org/jira/browse/IGNITE-19971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19971:
-
Reviewer: Vladislav Pyatkov
> Flaky ItNodeTest#testLeaseReadAfterSegmentation
> ---
>
> Key: IGNITE-19971
> URL: https://issues.apache.org/jira/browse/IGNITE-19971
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItNodeTest#testLeaseReadAfterSegmentation is flaky
> {code:java}
> java.lang.NullPointerException: Cannot invoke
> "org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
> "org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
> at
> org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
> {code}
> The problem was in the race in
> {code:java}
> assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
> !leader.getNodeId().equals(cluster.getLeader().getNodeId()),
> 10_000));
> {code}
> so leader was stepped done in the middle of this assertion, so the first part
> of this expression {{cluster.getLeader() != null}} was true.
> The fix is to rewrite condition to defence against NPE.
> After 300 local runs there is no failures, but 3 failures in 100 runs were
> before fix
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19971) Flaky ItNodeTest#testLeaseReadAfterSegmentation
[
https://issues.apache.org/jira/browse/IGNITE-19971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19971:
-
Description:
ItNodeTest#testLeaseReadAfterSegmentation is flaky
{code:java}
java.lang.NullPointerException: Cannot invoke
"org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
"org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
at
org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
{code}
The problem was in the race in
{code:java}
assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
!leader.getNodeId().equals(cluster.getLeader().getNodeId()),
10_000));
{code}
so leader was stepped done in the middle of this assertion, so the first part
of this expression {{cluster.getLeader() != null}} was true.
The fix is to rewrite condition to defence against NPE.
After 300 local runs there is no failures, but 3 failures in 100 runs were
before fix
was:
ItNodeTest#testLeaseReadAfterSegmentation is flaky
{code:java}
java.lang.NullPointerException: Cannot invoke
"org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
"org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
at
org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
{code}
The problem was in the race in
{code:java}
assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
!leader.getNodeId().equals(cluster.getLeader().getNodeId()),
10_000));
{code}
so leader was stepped done in the middle of this assertion, so the first part
of this expression {{cluster.getLeader() != null}} was true
> Flaky ItNodeTest#testLeaseReadAfterSegmentation
> ---
>
> Key: IGNITE-19971
> URL: https://issues.apache.org/jira/browse/IGNITE-19971
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItNodeTest#testLeaseReadAfterSegmentation is flaky
> {code:java}
> java.lang.NullPointerException: Cannot invoke
> "org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
> "org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
> at
> org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
> {code}
> The problem was in the race in
> {code:java}
> assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
> !leader.getNodeId().equals(cluster.getLeader().getNodeId()),
> 10_000));
> {code}
> so leader was stepped done in the middle of this assertion, so the first part
> of this expression {{cluster.getLeader() != null}} was true.
> The fix is to rewrite condition to defence against NPE.
> After 300 local runs there is no failures, but 3 failures in 100 runs were
> before fix
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19971) Flaky ItNodeTest#testLeaseReadAfterSegmentation
[
https://issues.apache.org/jira/browse/IGNITE-19971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19971:
-
Description:
ItNodeTest#testLeaseReadAfterSegmentation is flaky
{code:java}
java.lang.NullPointerException: Cannot invoke
"org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
"org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
at
org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
{code}
The problem was in the race in
{code:java}
assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
!leader.getNodeId().equals(cluster.getLeader().getNodeId()),
10_000));
{code}
so leader was stepped done in the middle of this assertion, so the first part
of this expression {{cluster.getLeader() != null}} was true
was:
ItNodeTest#testLeaseReadAfterSegmentation is flaky
{code:java}
java.lang.NullPointerException: Cannot invoke
"org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
"org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
at
org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
{code}
> Flaky ItNodeTest#testLeaseReadAfterSegmentation
> ---
>
> Key: IGNITE-19971
> URL: https://issues.apache.org/jira/browse/IGNITE-19971
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItNodeTest#testLeaseReadAfterSegmentation is flaky
> {code:java}
> java.lang.NullPointerException: Cannot invoke
> "org.apache.ignite.raft.jraft.Node.getNodeId()" because the return value of
> "org.apache.ignite.raft.jraft.core.TestCluster.getLeader()" is null
> at
> org.apache.ignite.raft.jraft.core.ItNodeTest.lambda$testLeaseReadAfterSegmentation$43(ItNodeTest.java:3652)
> {code}
> The problem was in the race in
> {code:java}
> assertTrue(waitForCondition(() -> cluster.getLeader() != null &&
> !leader.getNodeId().equals(cluster.getLeader().getNodeId()),
> 10_000));
> {code}
> so leader was stepped done in the middle of this assertion, so the first part
> of this expression {{cluster.getLeader() != null}} was true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-19977) Defragmentation can't use 1 thread.
[
https://issues.apache.org/jira/browse/IGNITE-19977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17743036#comment-17743036
]
Ignite TC Bot commented on IGNITE-19977:
{panel:title=Branch: [pull/10842/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10842/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=7255446]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
IgnitePdsIndexingDefragmentationTest.testSuccessfulDefragmentationOneThread -
PASSED{color}
{color:#8b}PDS 8{color} [[tests
3|https://ci2.ignite.apache.org/viewLog.html?buildId=7255444]]
* {color:#013220}IgnitePdsTestSuite8:
IgnitePdsDefragmentationTest.testSuccessfulDefragmentationOneThread -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite8:
IgnitePdsDefragmentationRandomLruEvictionTest.testSuccessfulDefragmentationOneThread
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite8:
IgnitePdsDefragmentationEncryptionTest.testSuccessfulDefragmentationOneThread -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7255485buildTypeId=IgniteTests24Java8_RunAll]
> Defragmentation can't use 1 thread.
> ---
>
> Key: IGNITE-19977
> URL: https://issues.apache.org/jira/browse/IGNITE-19977
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {code:java}
> /**
> * Sets maximum number of partitions which can be defragmented at the
> same time.
> *
> * @param defragmentationThreadPoolSize Maximum number of partitions
> which can be defragmented at the same time.
> * Default is {@link
> DataStorageConfiguration#DFLT_DEFRAGMENTATION_THREAD_POOL_SIZE}.
> * @return {@code this} for chaining.
> */
> public DataStorageConfiguration setDefragmentationThreadPoolSize(int
> defragmentationThreadPoolSize) {
> A.ensure(defragmentationThreadPoolSize > 1, "Defragmentation thread
> pool size must be greater or equal to 1.");
> this.defragmentationThreadPoolSize = defragmentationThreadPoolSize;
> return this;
> }
> {code}
> should compare with 0:
> {code:java}
> A.ensure(defragmentationThreadPoolSize > 0, "Defragmentation thread pool size
> must be greater or equal to 1.");
> {code}
> Defragmentation actually works with just 1 thread. Also, 1 thread seems to be
> a workaround for https://issues.apache.org/jira/browse/IGNITE-19904 . I
> couldn't detect the failure with one defragmentation worker.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19982) .NET: Support BOOLEAN datatype
[ https://issues.apache.org/jira/browse/IGNITE-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19982: Fix Version/s: 3.0.0-beta2 > .NET: Support BOOLEAN datatype > -- > > Key: IGNITE-19982 > URL: https://issues.apache.org/jira/browse/IGNITE-19982 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-17298 added support for boolean type to server, so we need to add it > to .NET client as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19982) .NET: Support BOOLEAN datatype
[ https://issues.apache.org/jira/browse/IGNITE-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-19982: --- Assignee: Pavel Tupitsyn > .NET: Support BOOLEAN datatype > -- > > Key: IGNITE-19982 > URL: https://issues.apache.org/jira/browse/IGNITE-19982 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > IGNITE-17298 added support for boolean type to server, so we need to add it > to .NET client as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19982) .NET: Support BOOLEAN datatype
[ https://issues.apache.org/jira/browse/IGNITE-19982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-19982: Labels: .NET ignite-3 (was: ignite-3) > .NET: Support BOOLEAN datatype > -- > > Key: IGNITE-19982 > URL: https://issues.apache.org/jira/browse/IGNITE-19982 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > IGNITE-17298 added support for boolean type to server, so we need to add it > to .NET client as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19983) C++: Support BOOLEAN datatype
Igor Sapego created IGNITE-19983: Summary: C++: Support BOOLEAN datatype Key: IGNITE-19983 URL: https://issues.apache.org/jira/browse/IGNITE-19983 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Igor Sapego IGNITE-17298 added support for boolean type to server, so we need to add it to C++ client as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19982) .NET: Support BOOLEAN datatype
Igor Sapego created IGNITE-19982: Summary: .NET: Support BOOLEAN datatype Key: IGNITE-19982 URL: https://issues.apache.org/jira/browse/IGNITE-19982 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Igor Sapego IGNITE-17298 added support for boolean type to server, so we need to add it to .NET client as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
