[jira] [Updated] (IGNITE-20602) Fix cache scan command page size to meet the limit argument
[ https://issues.apache.org/jira/browse/IGNITE-20602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-20602: - Labels: ise (was: ) > Fix cache scan command page size to meet the limit argument > > > Key: IGNITE-20602 > URL: https://issues.apache.org/jira/browse/IGNITE-20602 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Minor > Labels: ise > > Cache scan command ignores the limit argument and preloads default page size > entries count. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20602) Fix cache scan command page size to meet the limit argument
Nikita Amelchev created IGNITE-20602: Summary: Fix cache scan command page size to meet the limit argument Key: IGNITE-20602 URL: https://issues.apache.org/jira/browse/IGNITE-20602 Project: Ignite Issue Type: Bug Reporter: Nikita Amelchev Assignee: Nikita Amelchev Cache scan command ignores the limit argument and preloads default page size entries count. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20595) Split snapshot suite into three
[ https://issues.apache.org/jira/browse/IGNITE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20595: - Summary: Split snapshot suite into three (was: Split snapshot suite into two) > Split snapshot suite into three > --- > > Key: IGNITE-20595 > URL: https://issues.apache.org/jira/browse/IGNITE-20595 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Time Spent: 10m > Remaining Estimate: 0h > > Right now snapshot suite runs 1.5 hours or even longer. > We need split it to reduce Run All timing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20472) API to consume cache dumps
[ https://issues.apache.org/jira/browse/IGNITE-20472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20472: - Summary: API to consume cache dumps (was: API to consumer cache dumps) > API to consume cache dumps > -- > > Key: IGNITE-20472 > URL: https://issues.apache.org/jira/browse/IGNITE-20472 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite must provide API to consume cache dumps by user defined consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17060) Thin 3.0: Implement script SQL API for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-17060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-17060: -- Epic Link: IGNITE-20453 > Thin 3.0: Implement script SQL API for java thin client > --- > > Key: IGNITE-17060 > URL: https://issues.apache.org/jira/browse/IGNITE-17060 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16960) Sql. Script execution using java public API
[ https://issues.apache.org/jira/browse/IGNITE-16960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-16960: -- Epic Link: IGNITE-20453 Ignite Flags: (was: Docs Required,Release Notes Required) Description: Support script execution using native public Java API. See Session.executeScript method. was: Let's support non-transactional multi-statement DML queries. See Session.executeScript method. Issue Type: Task (was: Improvement) Summary: Sql. Script execution using java public API (was: SQL API: Add SQL script support.) > Sql. Script execution using java public API > --- > > Key: IGNITE-16960 > URL: https://issues.apache.org/jira/browse/IGNITE-16960 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Support script execution using native public Java API. > See Session.executeScript method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20580) Support only primary mode
[ https://issues.apache.org/jira/browse/IGNITE-20580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20580: - Fix Version/s: 2.16 > Support only primary mode > - > > Key: IGNITE-20580 > URL: https://issues.apache.org/jira/browse/IGNITE-20580 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > > Support only-primary mode during cache dump createion -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20472) API to consumer cache dumps
[ https://issues.apache.org/jira/browse/IGNITE-20472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20472: - Fix Version/s: 2.16 > API to consumer cache dumps > --- > > Key: IGNITE-20472 > URL: https://issues.apache.org/jira/browse/IGNITE-20472 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite must provide API to consume cache dumps by user defined consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20429) Support dump check command
[ https://issues.apache.org/jira/browse/IGNITE-20429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20429: - Fix Version/s: 2.16 > Support dump check command > -- > > Key: IGNITE-20429 > URL: https://issues.apache.org/jira/browse/IGNITE-20429 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20601) Support custom location for dumps
[ https://issues.apache.org/jira/browse/IGNITE-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20601: - Description: User may want to create cache dump in any specific folder, like regular PDS snapshots. Ignite need to support this. was: User may want to create cache dump only for specific set of cache groups. Ignite need to support this > Support custom location for dumps > - > > Key: IGNITE-20601 > URL: https://issues.apache.org/jira/browse/IGNITE-20601 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > > User may want to create cache dump in any specific folder, like regular PDS > snapshots. > Ignite need to support this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20601) Support custom location for dumps
Nikolay Izhikov created IGNITE-20601: Summary: Support custom location for dumps Key: IGNITE-20601 URL: https://issues.apache.org/jira/browse/IGNITE-20601 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov User may want to create cache dump only for specific set of cache groups. Ignite need to support this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19950) Cache dumps
[ https://issues.apache.org/jira/browse/IGNITE-19950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-19950: - Fix Version/s: 2.16 > Cache dumps > --- > > Key: IGNITE-19950 > URL: https://issues.apache.org/jira/browse/IGNITE-19950 > Project: Ignite > Issue Type: New Feature >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, iep-43, ise > Fix For: 2.16 > > Time Spent: 6.5h > Remaining Estimate: 0h > > Ignite can create snapshot for persistent cache groups only. > It will be very usefull for a user to have ability to create and restore > snapshot of in-memory cache groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20534) Transactions. It is possible to call enlist on a rollbacked transaction and cause a resource leak.
[
https://issues.apache.org/jira/browse/IGNITE-20534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-20534:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Transactions. It is possible to call enlist on a rollbacked transaction and
> cause a resource leak.
> --
>
> Key: IGNITE-20534
> URL: https://issues.apache.org/jira/browse/IGNITE-20534
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta2
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> It is possible to rollback a transaction, invoke a modification operation on
> some table, open another transaction and get 'Failed to acquire a lock due to
> a conflict' when accessing that table.
> Reproducer:
> {code:java}
> @Test
> public void testLockIsNotReleasedAfterTxRollback() {
> Ignite ignite = CLUSTER_NODES.get(0);
> IgniteSql sql = ignite.sql();
> try (Session ses = ignite.sql().createSession()) {
> ses.execute(null, "CREATE TABLE IF NOT EXISTS tst(id INTEGER
> PRIMARY KEY, val INTEGER)").affectedRows();
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin();
> assertThrows(RuntimeException.class, () -> session.execute(tx,
> "SELECT 1/0"));
> tx.rollback();
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); // if this
> line is commented out, everything works fine.
> }
> try (Session session = sql.createSession()) {
> Transaction tx = ignite.transactions().begin(new
> TransactionOptions().readOnly(false));
> session.execute(tx, "INSERT INTO tst VALUES (1, 1)"); //IGN-TX-4
> TraceId:20441aa3-c3fb-4900-a78f-b2cb4585e314 Failed to acquire a lock due to
> a conflict [txId=018af087-fb6b---e9bae05c,
> conflictingWaiter=WaiterImpl [txId=018af087-f595---e9bae05c,
> intendedLockMode=null, lockMode=X, ex=null, isDone=true]]
> tx.commit();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20127) Implement 1rtt RW transaction await logic in pre commit
[
https://issues.apache.org/jira/browse/IGNITE-20127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773264#comment-17773264
]
Alexey Scherbakov commented on IGNITE-20127:
The implementation sends a direct ack message to the txn coordinator for any
async replication command.
This currently doesn't work for SQL and needs to be implemented in a separate
ticket.
> Implement 1rtt RW transaction await logic in pre commit
> ---
>
> Key: IGNITE-20127
> URL: https://issues.apache.org/jira/browse/IGNITE-20127
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3, transactions
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> Our transaction protocol assumes that all required request validations, lock
> acquisitions and similar activities are performed on a primary replica prior
> to command replication, meaning that it's not necessary to await replication
> for every request one by one rather it's required to await them all at once
> in pre-commit phase. Most of what is required for such all at once await has
> already been implemented.
> h3. Definition of Done
> * It's required to do the command replication in an async manner, meaning
> that it's necessary to return the result to the client right after
> replication is triggered. Currently, we return replication result in
> PartitionReplicaListener#applyCmdWithExceptionHandling and await it in
> ReplicaManager#onReplicaMessageReceive
> {code:java}
> CompletableFuture result = replica.processRequest(request);
> result.handle((res, ex) -> {
> ...
> msg = prepareReplicaResponse(requestTimestamp, res);
> ...
> clusterNetSvc.messagingService().respond(senderConsistentId, msg,
> correlationId); {code}
> * And of course it's required to await all commands replication at once in
> pre-commit. We already have such logic in ReadWriteTransactionImpl#finish
> {code:java}
> protected CompletableFuture finish(boolean commit) {
> ...
> CompletableFuture mainFinishFut = CompletableFuture
> .allOf(enlistedResults.toArray(new CompletableFuture[0]))
> .thenCompose(
> ...
> return txManager.finish(
> ...{code}
> however, it should use not the result from primary, but the replication
> completion one.
> h3. Implementation Notes
> I believe it's possible to implement it in a following way:
> * ReplicaManager should await only primary related actions like lock
> acquisition and store the replication future in a sort of map. It's possible
> to use safeTime as request Id.
> * Transaction should send replicationAwaitRequest in an async manner right
> after replicationResponse from primary was achieved.
> * enlistedResults should be switched to replicationAwaitResponse.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20481) Java client: Balance requests across connections
[ https://issues.apache.org/jira/browse/IGNITE-20481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20481: --- Assignee: Wei Cheng (was: Pavel Tupitsyn) > Java client: Balance requests across connections > > > Key: IGNITE-20481 > URL: https://issues.apache.org/jira/browse/IGNITE-20481 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.15 >Reporter: Wei Cheng >Assignee: Wei Cheng >Priority: Major > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Java client: Balance requests across connections -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20127) Implement 1rtt RW transaction await logic in pre commit
[
https://issues.apache.org/jira/browse/IGNITE-20127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773264#comment-17773264
]
Alexey Scherbakov edited comment on IGNITE-20127 at 10/9/23 11:44 AM:
--
The implementation sends a direct ack message to the txn coordinator for any
async replication command.
The coordinator delays commit until all acks are received.
This currently doesn't work for SQL and needs to be implemented in a separate
ticket.
was (Author: ascherbakov):
The implementation sends a direct ack message to the txn coordinator for any
async replication command.
This currently doesn't work for SQL and needs to be implemented in a separate
ticket.
> Implement 1rtt RW transaction await logic in pre commit
> ---
>
> Key: IGNITE-20127
> URL: https://issues.apache.org/jira/browse/IGNITE-20127
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3, transactions
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> Our transaction protocol assumes that all required request validations, lock
> acquisitions and similar activities are performed on a primary replica prior
> to command replication, meaning that it's not necessary to await replication
> for every request one by one rather it's required to await them all at once
> in pre-commit phase. Most of what is required for such all at once await has
> already been implemented.
> h3. Definition of Done
> * It's required to do the command replication in an async manner, meaning
> that it's necessary to return the result to the client right after
> replication is triggered. Currently, we return replication result in
> PartitionReplicaListener#applyCmdWithExceptionHandling and await it in
> ReplicaManager#onReplicaMessageReceive
> {code:java}
> CompletableFuture result = replica.processRequest(request);
> result.handle((res, ex) -> {
> ...
> msg = prepareReplicaResponse(requestTimestamp, res);
> ...
> clusterNetSvc.messagingService().respond(senderConsistentId, msg,
> correlationId); {code}
> * And of course it's required to await all commands replication at once in
> pre-commit. We already have such logic in ReadWriteTransactionImpl#finish
> {code:java}
> protected CompletableFuture finish(boolean commit) {
> ...
> CompletableFuture mainFinishFut = CompletableFuture
> .allOf(enlistedResults.toArray(new CompletableFuture[0]))
> .thenCompose(
> ...
> return txManager.finish(
> ...{code}
> however, it should use not the result from primary, but the replication
> completion one.
> h3. Implementation Notes
> I believe it's possible to implement it in a following way:
> * ReplicaManager should await only primary related actions like lock
> acquisition and store the replication future in a sort of map. It's possible
> to use safeTime as request Id.
> * Transaction should send replicationAwaitRequest in an async manner right
> after replicationResponse from primary was achieved.
> * enlistedResults should be switched to replicationAwaitResponse.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20600:
--
Description:
Primary key column update produces an error that contains incorrect error
description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
was:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Primary key column update produces an error that contains incorrect error
> description:
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20481) Java client: Balance requests across connections
[ https://issues.apache.org/jira/browse/IGNITE-20481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20481: --- Assignee: Pavel Tupitsyn (was: Wei Cheng) > Java client: Balance requests across connections > > > Key: IGNITE-20481 > URL: https://issues.apache.org/jira/browse/IGNITE-20481 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.15 >Reporter: Wei Cheng >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Java client: Balance requests across connections -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20127) Implement 1rtt RW transaction await logic in pre commit
[
https://issues.apache.org/jira/browse/IGNITE-20127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov resolved IGNITE-20127.
Resolution: Fixed
> Implement 1rtt RW transaction await logic in pre commit
> ---
>
> Key: IGNITE-20127
> URL: https://issues.apache.org/jira/browse/IGNITE-20127
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3, transactions
> Time Spent: 8h 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> Our transaction protocol assumes that all required request validations, lock
> acquisitions and similar activities are performed on a primary replica prior
> to command replication, meaning that it's not necessary to await replication
> for every request one by one rather it's required to await them all at once
> in pre-commit phase. Most of what is required for such all at once await has
> already been implemented.
> h3. Definition of Done
> * It's required to do the command replication in an async manner, meaning
> that it's necessary to return the result to the client right after
> replication is triggered. Currently, we return replication result in
> PartitionReplicaListener#applyCmdWithExceptionHandling and await it in
> ReplicaManager#onReplicaMessageReceive
> {code:java}
> CompletableFuture result = replica.processRequest(request);
> result.handle((res, ex) -> {
> ...
> msg = prepareReplicaResponse(requestTimestamp, res);
> ...
> clusterNetSvc.messagingService().respond(senderConsistentId, msg,
> correlationId); {code}
> * And of course it's required to await all commands replication at once in
> pre-commit. We already have such logic in ReadWriteTransactionImpl#finish
> {code:java}
> protected CompletableFuture finish(boolean commit) {
> ...
> CompletableFuture mainFinishFut = CompletableFuture
> .allOf(enlistedResults.toArray(new CompletableFuture[0]))
> .thenCompose(
> ...
> return txManager.finish(
> ...{code}
> however, it should use not the result from primary, but the replication
> completion one.
> h3. Implementation Notes
> I believe it's possible to implement it in a following way:
> * ReplicaManager should await only primary related actions like lock
> acquisition and store the replication future in a sort of map. It's possible
> to use safeTime as request Id.
> * Transaction should send replicationAwaitRequest in an async manner right
> after replicationResponse from primary was achieved.
> * enlistedResults should be switched to replicationAwaitResponse.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[
https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-20600:
--
Description:
{code:java}
sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
sql("UPDATE my SET id = 1");
// Err: Cannot update field "ID". You cannot update key, key fields or val
field in case the val is a complex type
{code}
Update error message so it indicates that primary key columns are modifiable.
was:
Current the error message is `Cannot update field "ID". You cannot update key,
key fields or val field in case the val is a complex type` is not correcnt, as
it is not the reason why this operation was rejected.
Update error message so it indicates that primary key columns are modifiable.
> Sql. Updating primary key column produces an incorrect error message.
> -
>
> Key: IGNITE-20600
> URL: https://issues.apache.org/jira/browse/IGNITE-20600
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code:java}
> sql("CREATE TABLE my (id INT PRIMARY KEY, val INT)");
> sql("UPDATE my SET id = 1");
> // Err: Cannot update field "ID". You cannot update key, key fields or val
> field in case the val is a complex type
> {code}
> Update error message so it indicates that primary key columns are modifiable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20083) Sql. Investigate cost calculation for MAP/REDUCE aggregate.
[ https://issues.apache.org/jira/browse/IGNITE-20083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20083: -- Priority: Minor (was: Major) > Sql. Investigate cost calculation for MAP/REDUCE aggregate. > --- > > Key: IGNITE-20083 > URL: https://issues.apache.org/jira/browse/IGNITE-20083 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > After removing complex objects between MAP/REDUCE phase cost computations > changed and some plans that were expected to choose MAP/REDUCE aggregates are > now choose colocated aggregations or exchange is moved prior to MAP phase, > and not inserted MAP/REDUCE phases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[ https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20600: -- Priority: Minor (was: Major) > Sql. Updating primary key column produces an incorrect error message. > - > > Key: IGNITE-20600 > URL: https://issues.apache.org/jira/browse/IGNITE-20600 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Current the error message is `Cannot update field "ID". You cannot update > key, key fields or val field in case the val is a complex type` is not > correcnt, as it is not the reason why this operation was rejected. > Update error message so it indicates that primary key columns are modifiable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
Maksim Zhuravkov created IGNITE-20600: - Summary: Sql. Updating primary key column produces an incorrect error message. Key: IGNITE-20600 URL: https://issues.apache.org/jira/browse/IGNITE-20600 Project: Ignite Issue Type: Improvement Components: sql Reporter: Maksim Zhuravkov Fix For: 3.0.0-beta2 Current the error message is `Cannot update field "ID". You cannot update key, key fields or val field in case the val is a complex type` is not correcnt, as it is not the reason why this operation was rejected. Update error message so it indicates that primary key columns are modifiable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20600) Sql. Updating primary key column produces an incorrect error message.
[ https://issues.apache.org/jira/browse/IGNITE-20600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20600: -- Labels: ignite-3 (was: ) > Sql. Updating primary key column produces an incorrect error message. > - > > Key: IGNITE-20600 > URL: https://issues.apache.org/jira/browse/IGNITE-20600 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Current the error message is `Cannot update field "ID". You cannot update > key, key fields or val field in case the val is a complex type` is not > correcnt, as it is not the reason why this operation was rejected. > Update error message so it indicates that primary key columns are modifiable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20599) Implement a 'not' operation in the meta storage dsl.
Sergey Uttsel created IGNITE-20599:
--
Summary: Implement a 'not' operation in the meta storage dsl.
Key: IGNITE-20599
URL: https://issues.apache.org/jira/browse/IGNITE-20599
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Uttsel
*Motivation*
In https://issues.apache.org/jira/browse/IGNITE-20561 we need to create a
condition for a ms invoke with negation. We could do this two ways:
{code:java}
and(
notExists(dataNodes(zoneId)),
notTombstone(dataNodes(zoneId))
){code}
or
{code:java}
not(
or(
exists(dataNodes(zoneId)),
tombstone(dataNodes(zoneId))
)
){code}
But there are no `notTombstone` or `not` methods in the meta storage dsl.
I propose to implement `not` operation because it is more general approach and
it can be reused with other conditions.
*Definition of done*
`not` operation is implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20598) incorrect error for query on closed transaction through Client API
Yury Gerzhedovich created IGNITE-20598:
--
Summary: incorrect error for query on closed transaction through
Client API
Key: IGNITE-20598
URL: https://issues.apache.org/jira/browse/IGNITE-20598
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Yury Gerzhedovich
During using already closed transaction for query execution we got
SqlException with code Transactions.TX_FAILED_READ_WRITE_OPERATION_ERR. But the
Exception we have just for embeded API, for client API we have Ignite Exception
with INTERAL_ERROR code.
Let's investigate and fix the issue.
Test with reproducer are
org.apache.ignite.internal.sql.api.ItSqlApiBaseTest#checkTransactionsWithDml,
also please find tho mention of the ticket.
{code:java}
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:1615f3e8-e576-411e-b2ce-19ae7edd0f7f
org.apache.ignite.internal.lang.IgniteInternalException: Failed to find
resource with id: 1
at
java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
at
org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772)
at
org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641)
at
org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494)
at
org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
at
org.apache.ignite.internal.sql.api.ItSqlSynchronousApiTest.checkDml(ItSqlSynchronousApiTest.java:78)
at
org.apache.ignite.internal.sql.api.ItSqlApiBaseTest.lambda$checkTransactionsWithDml$1(ItSqlApiBaseTest.java:285)
at org.junit.jupiter.api.AssertThrows.assertThrows(AssertThrows.java:53)
... 75 more
Caused by: java.util.concurrent.CompletionException:
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:1615f3e8-e576-411e-b2ce-19ae7edd0f7f
org.apache.ignite.internal.lang.IgniteInternalException: Failed to find
resource with id: 1
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:426)
at
org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:231)
at
org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:111)
at
org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:33)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
at
[jira] [Assigned] (IGNITE-20424) Slow thin client connection can lead to consuming of huge amount of heap
[ https://issues.apache.org/jira/browse/IGNITE-20424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-20424: --- Assignee: Mikhail Petrov > Slow thin client connection can lead to consuming of huge amount of heap > - > > Key: IGNITE-20424 > URL: https://issues.apache.org/jira/browse/IGNITE-20424 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: ise > Time Spent: 1h 20m > Remaining Estimate: 0h > > All messages designated for the thin client are accumulated in the selector > queue GridSelectorNioSessionImpl#queue before they are sent. Note that > GridSelectorNioSessionImpl#queue for the Ignite Thin Client currently is > unbound. If the thin client connection is slow and a huge number of heavy > messages are about to send to the thin client, > GridSelectorNioSessionImpl#queue growing size can lead to OOM. > See > 1. https://issues.apache.org/jira/browse/IGNITE-20327 > 2. https://github.com/apache/ignite/issues/10559 > We need to investigate mechanisms to limit the thin client message queue size. > Currently, two mechanisms related to the described problem have already been > implemented: > 1. GridNioServer.Builder#messageQueueSizeListener is used to limit the > message queue size for Ignite Thick clients - if the message queue size limit > is exceeded, the client node will be forced to leave the cluster. > 2. GridNioServer.Builder#sendQueueLimit is used to block a thread that sends > a message if the message queue size limit is exceeded. Currently is used with > Thick Clients and Ignite REST clients. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20597) Support cache group filter for dump
[ https://issues.apache.org/jira/browse/IGNITE-20597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20597: - Description: User may want to create cache dump only for specific set of cache groups. Ignite need to support this > Support cache group filter for dump > --- > > Key: IGNITE-20597 > URL: https://issues.apache.org/jira/browse/IGNITE-20597 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > > User may want to create cache dump only for specific set of cache groups. > Ignite need to support this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20597) Support cache group filter for dump
Nikolay Izhikov created IGNITE-20597: Summary: Support cache group filter for dump Key: IGNITE-20597 URL: https://issues.apache.org/jira/browse/IGNITE-20597 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20592) Parameter '--node-ids' for command 'schedule_indexes_rebuild'.
[ https://issues.apache.org/jira/browse/IGNITE-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-20592: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Parameter '--node-ids' for command 'schedule_indexes_rebuild'. > -- > > Key: IGNITE-20592 > URL: https://issues.apache.org/jira/browse/IGNITE-20592 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Since we addded '--nodes-ids' in IGNITE-20418, 'schedule_indexes_rebuild' > should have it too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20592) Parameter '--node-ids' for command 'schedule_indexes_rebuild'.
[ https://issues.apache.org/jira/browse/IGNITE-20592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-20592: -- Release Note: Added the multiple nodes argument to the 'schedule_indexes_rebuild' command > Parameter '--node-ids' for command 'schedule_indexes_rebuild'. > -- > > Key: IGNITE-20592 > URL: https://issues.apache.org/jira/browse/IGNITE-20592 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Since we addded '--nodes-ids' in IGNITE-20418, 'schedule_indexes_rebuild' > should have it too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20596) Support dump cancel command
[ https://issues.apache.org/jira/browse/IGNITE-20596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20596: - Summary: Support dump cancel command (was: Support dump status command) > Support dump cancel command > --- > > Key: IGNITE-20596 > URL: https://issues.apache.org/jira/browse/IGNITE-20596 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20002) Implement durable unlock on primary partition re-election
[ https://issues.apache.org/jira/browse/IGNITE-20002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20002: Assignee: Denis Chudov > Implement durable unlock on primary partition re-election > - > > Key: IGNITE-20002 > URL: https://issues.apache.org/jira/browse/IGNITE-20002 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, transaction, transaction3_recovery > > h3. Motivation > It's required to release all acquired locks on transaction finish in a > durable way. Such durability consists of two parts: > * Durable unlock within same primary. > * Durable unlock on primary change. > This ticket is about second part only. There's a counterpart ticket for the > first part IGNITE-20004 > h3. Definition of Done > * All unreleased locks for the transactions that were finished are released > in case of primary re-election, including old primary failure and cluster > restart. > h3. Implementation Notes > * We may start with adding onPrimaryElected callback. > * Within this callback, it's required to scan > `org.apache.ignite.internal.tx.storage.state.TxStateStorage#scan` local > TxStateStorage and call `org.apache.ignite.internal.tx.TxManager#cleanup` for > all transactions that have false in TxMeta.locksReleased. TxManager#cleanup > is an idempotent operation, thus it's safe to run it multiple time, even from > different nodes, e.g. old primary and new primary. > * It's required to add locksReleased field to TxMeta with default value > false. > * It's required to set locksReleases to true when all cleanup > txCleanupReplicaRequest returns successfully. That extra > "updateTxnState(locksReleased == true) should be asynchronous. > * Tests will be non-trivial here, because it'll be required to kill old > primary after txnStateChanged but before sending cleanup request. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20596) Support dump status command
Nikolay Izhikov created IGNITE-20596: Summary: Support dump status command Key: IGNITE-20596 URL: https://issues.apache.org/jira/browse/IGNITE-20596 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]"
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Fix Version/s: 3.0.0-beta2 > Sql. Attempting to specify default value for UUID column results in "Unknown > type [type=UUID]" > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment it is not possible to specify a value for default column of > UUID data type. The following error is returned - Unknown type [type=UUID]. > We can fix this error by allowing to set a varchar value in default > constraint from UUID data type (because a varchar can be implicitly converted > to UUID). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]"
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Fix Version/s: (was: 3.0.0-beta2) > Sql. Attempting to specify default value for UUID column results in "Unknown > type [type=UUID]" > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > > At the moment it is not possible to specify a value for default column of > UUID data type. The following error is returned - Unknown type [type=UUID]. > We can fix this error by allowing to set a varchar value in default > constraint from UUID data type (because a varchar can be implicitly converted > to UUID). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20593) Sql. Attempting to specify default value for UUID column results in "Unknown type [type=UUID]"
[ https://issues.apache.org/jira/browse/IGNITE-20593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov updated IGNITE-20593: -- Fix Version/s: 3.0.0-beta2 > Sql. Attempting to specify default value for UUID column results in "Unknown > type [type=UUID]" > -- > > Key: IGNITE-20593 > URL: https://issues.apache.org/jira/browse/IGNITE-20593 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment it is not possible to specify a value for default column of > UUID data type. The following error is returned - Unknown type [type=UUID]. > We can fix this error by allowing to set a varchar value in default > constraint from UUID data type (because a varchar can be implicitly converted > to UUID). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yafengshi updated IGNITE-20552:
---
Reviewer: Aleksandr Nikolaev
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Assignee: yafengshi
>Priority: Major
> Labels: newbie
> Fix For: None
>
> Original Estimate: 1h
> Time Spent: 10m
> Remaining Estimate: 50m
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
>
[jira] [Commented] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773159#comment-17773159
]
yafengshi commented on IGNITE-20552:
[~aonikolaev] , Please review my changes.
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Assignee: yafengshi
>Priority: Major
> Labels: newbie
> Fix For: None
>
> Original Estimate: 1h
> Time Spent: 10m
> Remaining Estimate: 50m
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
>
[jira] [Updated] (IGNITE-20552) The example code is giving a NotSerializableException
[
https://issues.apache.org/jira/browse/IGNITE-20552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
yafengshi updated IGNITE-20552:
---
Reviewer: (was: yafengshi)
> The example code is giving a NotSerializableException
> -
>
> Key: IGNITE-20552
> URL: https://issues.apache.org/jira/browse/IGNITE-20552
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: None
>Reporter: yafengshi
>Assignee: yafengshi
>Priority: Major
> Labels: newbie
> Fix For: None
>
> Original Estimate: 1h
> Time Spent: 10m
> Remaining Estimate: 50m
>
> docs/_docs/code-snippets/java/src/main/java/org/apache/ignite/snippets/UsingScanQueries.java
>
> The following code will result in a NotSerializableException：
> {code:java}
> QueryEntity personEntity = new QueryEntity(Integer.class, Person.class)
> .setFields(new LinkedHashMap() {{
> put("orgId", Integer.class.getName());
> put("salary", Integer.class.getName());
> }}) {code}
>
> {code:java}
> java.io.NotSerializableException: com.demo.TestController
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at java.util.ArrayList.writeObject(ArrayList.java:768) ~[na:1.8.0_362]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_362]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_362]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_362]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_362]
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1154)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> ~[na:1.8.0_362]
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> ~[na:1.8.0_362]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> ~[na:1.8.0_362]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:97)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.marshal0(JdkMarshaller.java:109)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:56)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10873)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5043)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$7.applyx(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:5069)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:5024)
> ~[ignite-core-2.15.0.jar:2.15.0]
> at
>
[jira] [Updated] (IGNITE-20595) Split snapshot suite into two
[ https://issues.apache.org/jira/browse/IGNITE-20595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20595: - Description: Right now snapshot suite runs 1.5 hours or even longer. We need split it to reduce Run All timing was:Don't create snapshot directories for in-memory cluster until first dump created. > Split snapshot suite into two > - > > Key: IGNITE-20595 > URL: https://issues.apache.org/jira/browse/IGNITE-20595 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > > Right now snapshot suite runs 1.5 hours or even longer. > We need split it to reduce Run All timing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20595) Split snapshot suite into two
Nikolay Izhikov created IGNITE-20595: Summary: Split snapshot suite into two Key: IGNITE-20595 URL: https://issues.apache.org/jira/browse/IGNITE-20595 Project: Ignite Issue Type: Task Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Don't create snapshot directories for in-memory cluster until first dump created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20586) .NET: Node crash due to OverflowException in Callbacks.ConsoleWrite
[
https://issues.apache.org/jira/browse/IGNITE-20586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773140#comment-17773140
]
Pavel Tupitsyn edited comment on IGNITE-20586 at 10/9/23 6:52 AM:
--
The problem is that we use JNI GetStringUtfChars, then treat it as true UTF-8,
which it is not.
A lot of details:
https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni
Potential solutions:
* Reuse our binary string encoding logic, which already solves this problem.
* Use GetStringChars instead, and decode UTF-16
was (Author: ptupitsyn):
The problem is that we use JNI GetStringUtfChars, then treat it as true UTF-8,
which it is not.
A lot of details:
https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni
Potential solution: reuse our binary string encoding logic, which already
solves this problem.
> .NET: Node crash due to OverflowException in Callbacks.ConsoleWrite
> ---
>
> Key: IGNITE-20586
> URL: https://issues.apache.org/jira/browse/IGNITE-20586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.16
>
>
> Log excerpt:
> {code}
> [06:28:44,643][SEVERE][tcp-disco-msg-worker-[f3d85cf4 10.114.158.249:47500
> crd]-#2%ignite-instance-cfa2d711-f2b7-4572-84f3-b880e25aa9e4%-#87%ignite-instance-cfa2d711-f2b7-4572-84f3-b880e25aa9e4%][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> class org.apache.ignite.IgniteException: Arithmetic operation resulted in an
> overflow.
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Native
> Method)
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(PlatformCallbackGateway.java:1203)
> at
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write(PlatformDotNetConsoleStream.java:44)
> at java.base/java.io.PrintStream.write(PrintStream.java:559)
> at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
> at
> java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312)
> at
> java.base/sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at
> java.base/java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:181)
> at java.base/java.io.PrintStream.write(PrintStream.java:606)
> at java.base/java.io.PrintStream.print(PrintStream.java:745)
> at
> org.apache.ignite.internal.util.IgniteUtils.quiet(IgniteUtils.java:4972)
> at
> org.apache.ignite.internal.util.IgniteUtils.quietAndWarn(IgniteUtils.java:4665)
> at
> org.apache.ignite.internal.processors.failure.FailureProcessor.process(FailureProcessor.java:174)
> at
> org.apache.ignite.internal.processors.failure.FailureProcessor.process(FailureProcessor.java:156)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1703)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1693)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:299)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$1(ServerImpl.java:2973)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:8050)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:3089)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7988)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> {code}
> *PlatformCallbackUtils.consoleWrite* calls *Callbacks.ConsoleWrite* in .NET,
> and "Arithmetic operation resulted in an overflow." is from
> *OverflowException*.
> We must be doing something wrong with JNI string conversion.
> * Add try-catch, ignore exceptions in *ConsoleWrite* callback
> * Investigate whether unicode characters or long strings are handled
> incorrectly
> h2. Workaround
> Disable Java console redirect:
> {code}
> IgniteConfiguration.RedirectJavaConsoleOutput = false;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20586) .NET: Node crash due to OverflowException in Callbacks.ConsoleWrite
[
https://issues.apache.org/jira/browse/IGNITE-20586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17773140#comment-17773140
]
Pavel Tupitsyn commented on IGNITE-20586:
-
The problem is that we use JNI GetStringUtfChars, then treat it as true UTF-8,
which it is not.
A lot of details:
https://stackoverflow.com/questions/32205446/getting-true-utf-8-characters-in-java-jni
Potential solution: reuse our binary string encoding logic, which already
solves this problem.
> .NET: Node crash due to OverflowException in Callbacks.ConsoleWrite
> ---
>
> Key: IGNITE-20586
> URL: https://issues.apache.org/jira/browse/IGNITE-20586
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.16
>
>
> Log excerpt:
> {code}
> [06:28:44,643][SEVERE][tcp-disco-msg-worker-[f3d85cf4 10.114.158.249:47500
> crd]-#2%ignite-instance-cfa2d711-f2b7-4572-84f3-b880e25aa9e4%-#87%ignite-instance-cfa2d711-f2b7-4572-84f3-b880e25aa9e4%][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> class org.apache.ignite.IgniteException: Arithmetic operation resulted in an
> overflow.
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.consoleWrite(Native
> Method)
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.consoleWrite(PlatformCallbackGateway.java:1203)
> at
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetConsoleStream.write(PlatformDotNetConsoleStream.java:44)
> at java.base/java.io.PrintStream.write(PrintStream.java:559)
> at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233)
> at
> java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:312)
> at
> java.base/sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> at
> java.base/java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:181)
> at java.base/java.io.PrintStream.write(PrintStream.java:606)
> at java.base/java.io.PrintStream.print(PrintStream.java:745)
> at
> org.apache.ignite.internal.util.IgniteUtils.quiet(IgniteUtils.java:4972)
> at
> org.apache.ignite.internal.util.IgniteUtils.quietAndWarn(IgniteUtils.java:4665)
> at
> org.apache.ignite.internal.processors.failure.FailureProcessor.process(FailureProcessor.java:174)
> at
> org.apache.ignite.internal.processors.failure.FailureProcessor.process(FailureProcessor.java:156)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1703)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1693)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:299)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$1(ServerImpl.java:2973)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:8050)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:3089)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7988)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> {code}
> *PlatformCallbackUtils.consoleWrite* calls *Callbacks.ConsoleWrite* in .NET,
> and "Arithmetic operation resulted in an overflow." is from
> *OverflowException*.
> We must be doing something wrong with JNI string conversion.
> * Add try-catch, ignore exceptions in *ConsoleWrite* callback
> * Investigate whether unicode characters or long strings are handled
> incorrectly
> h2. Workaround
> Disable Java console redirect:
> {code}
> IgniteConfiguration.RedirectJavaConsoleOutput = false;
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20594) Replace ThreadLocal ByteBuffer with PooledAllocator
Nikolay Izhikov created IGNITE-20594: Summary: Replace ThreadLocal ByteBuffer with PooledAllocator Key: IGNITE-20594 URL: https://issues.apache.org/jira/browse/IGNITE-20594 Project: Ignite Issue Type: Task Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Current approach uses thread local ByteBuffer to write data while dumping caches. This can lead to memory overhead when only some threads from pool modifies data (call writeChanged) and for each thread separate ByteBuffer allocated. We have PooledAllocator that can provide ability to reduce memory overhead. Need to study if it can be used in this case. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20561) Change condition for DistributionZonesUtil#triggerKeyConditionForZonesChanges to use ConditionType#TOMBSTONE
[
https://issues.apache.org/jira/browse/IGNITE-20561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-20561:
---
Description:
*Motivation*
Currently we use zonesChangeTriggerKey in
DistributionZonesUtil#triggerKeyConditionForZonesChanges to create condition to
initialize the zone's meta storage keys on a zone creation and to remove these
keys on a zone drop. It cause some issues:
# we cannot remove zonesChangeTriggerKey to ensure that on the zone will not
recreated on DZM restart
# it doesn't work properly now because it possible that on DZM restart the
zone will be recreated with the revision which is higher than original the zone
create revision.
*Implementation notes*
To fix it we need to get rid of zonesChangeTriggerKey and use a dataNodes ms
key on a zone create and a zone drop.
so the condition for a zone creation will be:
{code:java}
and(
notExists(dataNodes(zoneId)),
notTombstone(dataNodes(zoneId))
){code}
and for a zone drop:
{code:java}
exists(dataNodes(zoneId)){code}
*Definition of done*
Got rid of the meta storage zonesChangeTriggerKey key.
was:
*Motivation*
Currently we use zonesChangeTriggerKey in
DistributionZonesUtil#triggerKeyConditionForZonesChanges to create condition to
initialize the zone's meta storage keys on a zone creation and to remove these
keys on a zone drop. It cause some issues: # we cannot remove
zonesChangeTriggerKey to ensure that on the zone will not recreated on DZM
restart
# it doesn't work properly now because it possible that on DZM restart the
zone will be recreated with the revision which is higher than original the zone
create revision.
*Implementation notes*
To fix it we need to get rid of zonesChangeTriggerKey and use a dataNodes ms
key on a zone create and a zone drop.
so the condition for a zone creation will be:
and(
notExists(dataNodes(zoneId)),
notTombstone(dataNodes(zoneId))
)
and for a zone drop:
exists(dataNodes(zoneId))
*Definition of done*
Got rid of the meta storage zonesChangeTriggerKey key.
> Change condition for DistributionZonesUtil#triggerKeyConditionForZonesChanges
> to use ConditionType#TOMBSTONE
> -
>
> Key: IGNITE-20561
> URL: https://issues.apache.org/jira/browse/IGNITE-20561
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Currently we use zonesChangeTriggerKey in
> DistributionZonesUtil#triggerKeyConditionForZonesChanges to create condition
> to initialize the zone's meta storage keys on a zone creation and to remove
> these keys on a zone drop. It cause some issues:
> # we cannot remove zonesChangeTriggerKey to ensure that on the zone will not
> recreated on DZM restart
> # it doesn't work properly now because it possible that on DZM restart the
> zone will be recreated with the revision which is higher than original the
> zone create revision.
> *Implementation notes*
> To fix it we need to get rid of zonesChangeTriggerKey and use a dataNodes ms
> key on a zone create and a zone drop.
> so the condition for a zone creation will be:
> {code:java}
> and(
> notExists(dataNodes(zoneId)),
> notTombstone(dataNodes(zoneId))
> ){code}
> and for a zone drop:
> {code:java}
> exists(dataNodes(zoneId)){code}
>
> *Definition of done*
> Got rid of the meta storage zonesChangeTriggerKey key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20561) Change condition for DistributionZonesUtil#triggerKeyConditionForZonesChanges to use ConditionType#TOMBSTONE
[
https://issues.apache.org/jira/browse/IGNITE-20561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-20561:
---
Description:
*Motivation*
Currently we use zonesChangeTriggerKey in
DistributionZonesUtil#triggerKeyConditionForZonesChanges to create condition to
initialize the zone's meta storage keys on a zone creation and to remove these
keys on a zone drop. It cause some issues: # we cannot remove
zonesChangeTriggerKey to ensure that on the zone will not recreated on DZM
restart
# it doesn't work properly now because it possible that on DZM restart the
zone will be recreated with the revision which is higher than original the zone
create revision.
*Implementation notes*
To fix it we need to get rid of zonesChangeTriggerKey and use a dataNodes ms
key on a zone create and a zone drop.
so the condition for a zone creation will be:
and(
notExists(dataNodes(zoneId)),
notTombstone(dataNodes(zoneId))
)
and for a zone drop:
exists(dataNodes(zoneId))
*Definition of done*
Got rid of the meta storage zonesChangeTriggerKey key.
was:We need to use {{ConditionType#TOMBSTONE}} in
{{DistributionZonesUtil#triggerKeyConditionForZonesChanges}} when we initialise
keys for zones in MS
> Change condition for DistributionZonesUtil#triggerKeyConditionForZonesChanges
> to use ConditionType#TOMBSTONE
> -
>
> Key: IGNITE-20561
> URL: https://issues.apache.org/jira/browse/IGNITE-20561
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Currently we use zonesChangeTriggerKey in
> DistributionZonesUtil#triggerKeyConditionForZonesChanges to create condition
> to initialize the zone's meta storage keys on a zone creation and to remove
> these keys on a zone drop. It cause some issues: # we cannot remove
> zonesChangeTriggerKey to ensure that on the zone will not recreated on DZM
> restart
> # it doesn't work properly now because it possible that on DZM restart the
> zone will be recreated with the revision which is higher than original the
> zone create revision.
>
> *Implementation notes*
> To fix it we need to get rid of zonesChangeTriggerKey and use a dataNodes ms
> key on a zone create and a zone drop.
> so the condition for a zone creation will be:
> and(
> notExists(dataNodes(zoneId)),
> notTombstone(dataNodes(zoneId))
> )
> and for a zone drop:
> exists(dataNodes(zoneId))
>
> *Definition of done*
> Got rid of the meta storage zonesChangeTriggerKey key.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
