[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify snapshot command syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshotName
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify snapshot command syntax in 
> control script.
> --
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And same goes to "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17610) Rework snapshot cancel command and simplify snapshot command syntax in control script.

[Pavel Pereslegin (Jira)]

Pavel Pereslegin created IGNITE-17610:
-

 Summary: Rework snapshot cancel command and simplify snapshot 
command syntax in control script.
 Key: IGNITE-17610
 URL: https://issues.apache.org/jira/browse/IGNITE-17610
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Pereslegin


Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshotName
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify snapshot command syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Labels: iep-43  (was: )

> Rework snapshot cancel command and simplify snapshot command syntax in 
> control script.
> --
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And same goes to "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify command syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Summary: Rework snapshot cancel command and simplify command syntax in 
control script.  (was: Rework snapshot cancel command and simplify snapshot 
command syntax in control script.)

> Rework snapshot cancel command and simplify command syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And same goes to "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Summary: Rework snapshot cancel command and simplify syntax in control 
script.  (was: Rework snapshot cancel command and simplify command syntax in 
control script.)

> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And same goes to "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And the same goes to "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And the same goes to the "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And the same goes to the "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17617) Snapshot status command fails if cluster has a client node.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17617:
--
Summary: Snapshot status command fails if cluster has a client node.  (was: 
Fix NPE in the snapshot restore status command on client nodes and 
non-persistent cluster.)

> Snapshot status command fails if cluster has a client node.
> ---
>
> Key: IGNITE-17617
> URL: https://issues.apache.org/jira/browse/IGNITE-17617
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Fix For: 2.14
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> NPE example:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:133)
>   at 
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:95)
>   at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17617) Snapshot status command fails if cluster has a client node.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17617:
--
Priority: Major  (was: Minor)

> Snapshot status command fails if cluster has a client node.
> ---
>
> Key: IGNITE-17617
> URL: https://issues.apache.org/jira/browse/IGNITE-17617
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Fix For: 2.14
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> NPE example:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:133)
>   at 
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:95)
>   at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17610:
-

Assignee: Pavel Pereslegin

> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And the same goes to the "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax common:
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-16916) Make nodes more resilient in case of a job cancellation

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17600322#comment-17600322
 ] 

Pavel Pereslegin commented on IGNITE-16916:
---

[~ktkale...@gridgain.com], 

could you please suggest any workaround for system/internal tasks to cancel 
them immediately without changing 'computeJobWorkerInterruptTimeout' property?

> Make nodes more resilient in case of a job cancellation
> ---
>
> Key: IGNITE-16916
> URL: https://issues.apache.org/jira/browse/IGNITE-16916
> Project: Ignite
>  Issue Type: Task
>  Components: compute
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.14
>
> Attachments: image-2022-05-05-12-46-26-543.png, screenshot-1.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> In case of a job being cancelled we currently have a really questionable 
> approach.
> We are now setting the interruption flag even before we give a use a chance 
> to stop the job gracefully.
> Proposal for the implementation:
> * Adding a distributed property in the metastore that will set a timeout for 
> interrupting *GridJobWorker* that did not gracefully complete after calling 
> *GridJobWorker#cancel*;
> * On the call of the *GridJobWorker#cancel*, do not *Thread#interrupt* the 
> thread, but add *GridTimeoutObject*.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax simple and universal
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax common:
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> And the same goes to the "cancel" command.
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.


h5. So the proposal - make snapshot-commands syntax simple and universal
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

And the same goes to the "cancel" command.
Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.

So the proposal - make snapshot-commands syntax simple and universal
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: IgniteDebugLayoutConverter.java

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for production console output (pretty similar to spring 
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: (was: LayoutConverterDraft.java)

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for production console output (pretty similar to spring 
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: (was: log4j2-test.xml)

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for production console output (pretty similar to spring 
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: light-console.jpg

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for production console output (pretty similar to spring 
> boot).
> !prod-propsal.png|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
 !light-console.jpg! Recently completed Ignite migration to use log4j2. So we 
can use ["highlight" conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example


Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for production console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
>  !light-console.jpg! Recently completed Ignite migration to use log4j2. So we 
> can use ["highlight" conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
 !light-console.jpg!width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
 !light-console.jpg!width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

  was:
 !light-console.jpg! Recently completed Ignite migration to use log4j2. So we 
can use ["highlight" conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example


Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
>  !light-console.jpg!width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: log4j2-test.xml

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Ignite Flags:   (was: Release Notes Required)

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: (was: log4j2-test.xml)

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: log4j2-test.xml

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: dark-console-50-nodes-colors-palette.png
light-console-50-nodes-colors-palette.png

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Description: 
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.


h5. So the proposal - make snapshot-commands syntax simple and universal
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel --id operationId
{noformat}

  was:
Currently we have confusing snapshot restore command syntax.

For example snapshot creation command:
{noformat}
--snapshot create snapshot_Name
{noformat}

But for snapshot restore we should add confusing "--start" option
{noformat}
--snapshot restore snapshot_Name --start
{noformat}

Cancel snapshot creation:
{noformat}
--snapshot cancel snapshot_Name
{noformat}

But to cancel the snapshot restore you have to type something really weird:
{noformat}
--snapshot restore snapshot_Name --cancel
{noformat}

A new common snapshot "status" command has recently been introduced that 
displays an *operation ID* that can be used to cancel any snapshot operation in 
progress.


h5. So the proposal - make snapshot-commands syntax simple and universal
{noformat}
--snapshot create snapshotName
--snapshot restore snapshotName
--snapshot status
--snapshot cancel operationId
{noformat}


> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel --id operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the startup of 
different nodes (in this case, logging occurs from the *main* thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the startup of 
different nodes (in this case, logging occurs from the _main_ thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the launch of 
different nodes (in this case, logging occurs from the main thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the launch of 
> different nodes (in this case, logging occurs from the main thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the startup of 
different nodes (in this case, logging occurs from the _main_ thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the launch of 
different nodes (in this case, logging occurs from the main thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the _main_ thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: dark-console-example.png

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, dark-console-example.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, 
> log4j2-test.xml, prod-propsal.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !prod-propsal.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Attachment: (was: prod-propsal.png)

> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, dark-console-example.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, log4j2-test.xml
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !dark-console-example.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite test console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Description: 
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!dark-console-example.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the startup of 
different nodes (in this case, logging occurs from the *main* thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.

  was:
Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
conversion 
pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
colorize the output.

Initial proposal for dark test console output (pretty similar to spring boot).
!prod-propsal.png|width=679,height=337!

light console output example
!light-console.jpg|width=679,height=337!

Pattern for log4j 2.18+
{code:xml}

{code}
For the test framework, there is a suggestion - to color the output of each 
node with its own color. Apparently this can't be done without adding your own 
plugin, for example LogEventPatternConverter.

h4. Update

So far, it has been decided not to color the nodes in different colors.
The main reason is that it is not very clear how to highlight the startup of 
different nodes (in this case, logging occurs from the *main* thread).
In the attachment, I left an example of coloring different thread-nodes in 
different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
fact that the node name is contained in the name of the thread that performs 
logging.


> Colorize Ignite test console output
> ---
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, dark-console-example.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, log4j2-test.xml
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !dark-console-example.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Release Note: Added unified syntax for starting and canceling snapshot 
operations.

> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel --id operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Release Note: Added unified syntax for starting and canceling snapshot 
operations using control script.  (was: Added unified syntax for starting and 
canceling snapshot operations.)

> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel --id operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17610) Rework snapshot cancel command and simplify syntax in control script.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17610:
--
Component/s: control.sh

> Rework snapshot cancel command and simplify syntax in control script.
> -
>
> Key: IGNITE-17610
> URL: https://issues.apache.org/jira/browse/IGNITE-17610
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently we have confusing snapshot restore command syntax.
> For example snapshot creation command:
> {noformat}
> --snapshot create snapshot_Name
> {noformat}
> But for snapshot restore we should add confusing "--start" option
> {noformat}
> --snapshot restore snapshot_Name --start
> {noformat}
> Cancel snapshot creation:
> {noformat}
> --snapshot cancel snapshot_Name
> {noformat}
> But to cancel the snapshot restore you have to type something really weird:
> {noformat}
> --snapshot restore snapshot_Name --cancel
> {noformat}
> A new common snapshot "status" command has recently been introduced that 
> displays an *operation ID* that can be used to cancel any snapshot operation 
> in progress.
> h5. So the proposal - make snapshot-commands syntax simple and universal
> {noformat}
> --snapshot create snapshotName
> --snapshot restore snapshotName
> --snapshot status
> --snapshot cancel --id operationId
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Summary: Colorize Ignite console output  (was: Colorize Ignite test console 
output)

> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: test-framework
> Fix For: 2.15
>
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, dark-console-example.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, log4j2-test.xml
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !dark-console-example.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17442) Colorize Ignite console output

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17442:
--
Labels:   (was: test-framework)

> Colorize Ignite console output
> --
>
> Key: IGNITE-17442
> URL: https://issues.apache.org/jira/browse/IGNITE-17442
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.15
>
> Attachments: IgniteDebugLayoutConverter.java, 
> dark-console-50-nodes-colors-palette.png, dark-console-example.png, 
> light-console-50-nodes-colors-palette.png, light-console.jpg, log4j2-test.xml
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Recently completed Ignite migration to use log4j2. So we can use ["highlight" 
> conversion 
> pattern|https://logging.apache.org/log4j/2.x/manual/layouts.html#Patterns] to 
> colorize the output.
> Initial proposal for dark test console output (pretty similar to spring boot).
> !dark-console-example.png|width=679,height=337!
> light console output example
> !light-console.jpg|width=679,height=337!
> Pattern for log4j 2.18+
> {code:xml}
>  pattern="%style{[%d{ISO8601}]}{#77}%highlight{[%-5p]}{FATAL=red blink, 
> ERROR=red, WARN=yellow bold, INFO=green, DEBUG=green bold, 
> TRACE=blue}%style{[%t]}{magenta}%style{[%c{1}]}{cyan}%notEmpty{[%markerSimpleName]}
>  %m%n"/>
> {code}
> For the test framework, there is a suggestion - to color the output of each 
> node with its own color. Apparently this can't be done without adding your 
> own plugin, for example LogEventPatternConverter.
> h4. Update
> So far, it has been decided not to color the nodes in different colors.
> The main reason is that it is not very clear how to highlight the startup of 
> different nodes (in this case, logging occurs from the *main* thread).
> In the attachment, I left an example of coloring different thread-nodes in 
> different colors ( [^IgniteDebugLayoutConverter.java] ), which relies on the 
> fact that the node name is contained in the name of the thread that performs 
> logging.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17709) SQL: Support table hints.

[Pavel Pereslegin (Jira)]

Pavel Pereslegin created IGNITE-17709:
-

 Summary: SQL: Support table hints.
 Key: IGNITE-17709
 URL: https://issues.apache.org/jira/browse/IGNITE-17709
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin


Currently Ignite table scan implementation completely ignores _table_ 
[hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].

We need to add support for them to be able to add index and other table hints.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17709) SQL: Support table hints.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17709:
--
Component/s: sql

> SQL: Support table hints.
> -
>
> Key: IGNITE-17709
> URL: https://issues.apache.org/jira/browse/IGNITE-17709
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: ignite-3
>
> Currently Ignite table scan implementation completely ignores _table_ 
> [hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].
> We need to add support for them to be able to add index and other table hints.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17709) SQL: Support table hints.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17709:
--
Description: 
Currently Ignite table scan implementation completely ignores _table_ 
[hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].

We need to add support for them to be able to process index and other table 
hints.


  was:
Currently Ignite table scan implementation completely ignores _table_ 
[hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].

We need to add support for them to be able to add index and other table hints.



> SQL: Support table hints.
> -
>
> Key: IGNITE-17709
> URL: https://issues.apache.org/jira/browse/IGNITE-17709
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: ignite-3
>
> Currently Ignite table scan implementation completely ignores _table_ 
> [hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].
> We need to add support for them to be able to process index and other table 
> hints.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17709) SQL: Support table hints.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17709:
--
Description: 
Currently Ignite table scan implementation completely ignores _table_ 
[hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].

We need to add support for them to be able to handle index and other table 
hints.


  was:
Currently Ignite table scan implementation completely ignores _table_ 
[hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].

We need to add support for them to be able to process index and other table 
hints.



> SQL: Support table hints.
> -
>
> Key: IGNITE-17709
> URL: https://issues.apache.org/jira/browse/IGNITE-17709
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: ignite-3
>
> Currently Ignite table scan implementation completely ignores _table_ 
> [hints|https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql/SqlHint.html].
> We need to add support for them to be able to handle index and other table 
> hints.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17687) Get rid of using deprecated IgniteException constructors in sql-engine module

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17687:
-

Assignee: Pavel Pereslegin

> Get rid of using deprecated IgniteException constructors in sql-engine module
> -
>
> Key: IGNITE-17687
> URL: https://issues.apache.org/jira/browse/IGNITE-17687
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3, tech-debt
>
> As of now deprecated constructors of IgniteException widely used. Let's 
> replace all such places in sq-engine module to use non deprecated 
> constructors.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17687) Get rid of using deprecated IgniteException constructors in sql-engine module

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17687:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Get rid of using deprecated IgniteException constructors in sql-engine module
> -
>
> Key: IGNITE-17687
> URL: https://issues.apache.org/jira/browse/IGNITE-17687
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3, tech-debt
>
> As of now deprecated constructors of IgniteException widely used. Let's 
> replace all such places in sq-engine module to use non deprecated 
> constructors.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (IGNITE-17687) Get rid of using deprecated IgniteException constructors in sql-engine module

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin resolved IGNITE-17687.
---
Resolution: Done

[~jooger], thanks for the review!

Merged to the main branch.

> Get rid of using deprecated IgniteException constructors in sql-engine module
> -
>
> Key: IGNITE-17687
> URL: https://issues.apache.org/jira/browse/IGNITE-17687
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3, tech-debt
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> As of now deprecated constructors of IgniteException widely used. Let's 
> replace all such places in sq-engine module to use non deprecated 
> constructors.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17806:
-

Assignee: Pavel Pereslegin

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613982#comment-17613982
 ] 

Pavel Pereslegin commented on IGNITE-17806:
---

[~v.pyatkov],
I looked at the code of mentioned test and it seems that {{rollback()}} is 
called correctly, but some transactions cannot be rolled back because they have 
no replication groups enlisted (look at TransactionImpl#finish implementation).

For example for query "select 4/2" we registering implicit transaction that 
cannot be committed or rolled back.

Basic reproducer:

{code:java}
Transaction tx = CLUSTER_NODES.get(0).transactions().begin();
// Try to commit transaction.
tx.commit();

// Transaction remained in pending state.
TxManager txManagerInternal = (TxManager) 
IgniteTestUtils.getFieldValue(CLUSTER_NODES.get(0), IgniteImpl.class, 
"txManager");
var states = (Map) 
IgniteTestUtils.getFieldValue(txManagerInternal, TxManagerImpl.class, "states");

states.forEach((k, v) -> assertNotSame(v, TxState.PENDING));
{code}

Could you please take a look at this?

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614017#comment-17614017
 ] 

Pavel Pereslegin commented on IGNITE-17806:
---

[~v.pyatkov],
{{ItSqlSynchronousApiTest#errors}} currently fails due to case "SELECT 1 / ?". 
For this query rollback is called in {{AsyncSqlCursorImpl#requestNextAsync}}.

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614017#comment-17614017
 ] 

Pavel Pereslegin edited comment on IGNITE-17806 at 10/7/22 10:51 AM:
-

[~v.pyatkov],
{{ItSqlSynchronousApiTest#errors}} currently fails due to case "SELECT 1 / ?". 
For this case rollback is called in {{AsyncSqlCursorImpl#requestNextAsync}}.


was (Author: xtern):
[~v.pyatkov],
{{ItSqlSynchronousApiTest#errors}} currently fails due to case "SELECT 1 / ?". 
For this query rollback is called in {{AsyncSqlCursorImpl#requestNextAsync}}.

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-15245) JDBC connection leak with cache.invoke() over cache store with external JDBC storage

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-15245:
-

Assignee: Pavel Pereslegin

> JDBC connection leak with cache.invoke() over cache store with external JDBC 
> storage
> 
>
> Key: IGNITE-15245
> URL: https://issues.apache.org/jira/browse/IGNITE-15245
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.10
>Reporter: Ilya Korol
>Assignee: Pavel Pereslegin
>Priority: Major
>
> Given following snippet:
> {code:java}
> try (Transaction tx = 
> ignite.transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> cache.invoke(pojo.getId(), entryProcessor, pojo);
> tx.commit();
> }
> {code}
> If we run this over the cache that uses external storage (e.g. mysql), we may 
> get exceptions like:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Failed to load object ...
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:334)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:292)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadAllFromStore(GridCacheStoreManagerAdapter.java:433)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadAll(GridCacheStoreManagerAdapter.java:399)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:790)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onDone(GridDhtLockFuture.java:758)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onDone(GridDhtLockFuture.java:91)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:284)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:273)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:1052)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:709)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.notifyOwnerChanged(GridCacheMvccManager.java:226)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.access$200(GridCacheMvccManager.java:81)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$3.onOwnerChanged(GridCacheMvccManager.java:163)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:5043)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:4995)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:515)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:617)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:825)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsyncInternal(GridDhtTransactionalCacheAdapter.java:1027)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.obtainLockAsync(GridDhtTxLocalAdapter.java:720)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.lockAllAsync(GridDhtTxLocalAdapter.java:665)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:1238)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest0(GridDhtTransactionalCacheAdapter.java:823)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:801)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$000(GridDhtTransactionalCacheAdapter.java:113)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransacti

[jira] [Assigned] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17806:
-

Assignee: (was: Pavel Pereslegin)

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17813:
-

Assignee: Pavel Pereslegin

> Sql. Introduce sorted reducer for IndexScanNode
> ---
>
> Key: IGNITE-17813
> URL: https://issues.apache.org/jira/browse/IGNITE-17813
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> This task is derived from IGNITE-17655 to reduce its scope.
> Currently, IgniteScanNode reads partition after partition which, obviously, 
> breaks the sorting order. We need to introduce wrapping cursor, which accepts 
> open cursors for every partition, and produce the sorted output.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17937) [Extensions] Confusing folder appears after running Ignite Extension tests.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17937:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> [Extensions] Confusing folder appears after running Ignite Extension tests.
> ---
>
> Key: IGNITE-17937
> URL: https://issues.apache.org/jira/browse/IGNITE-17937
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Confusing folder with name sys:IGNITE_HOME appears after running Ignite 
> Extension tests.
> It happens because GridTestUtils#initTestProjectHome method which is 
> responsible for initializing IGNITE_HOME system property for non Ignite tests 
> does not work corrctly.
> First invocation of U.getIgniteHome() method tries to resolve Ignite Home 
> path and in case of a failure initializes it with null.
> U.setIgniteHome(...) does actually nothing if the previous attempt to resolve 
> Ignite Home was performed (even if it fails and null was set).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-17813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623684#comment-17623684
 ] 

Pavel Pereslegin commented on IGNITE-17813:
---

[~slukyanov],I'm not an expert, but it seems that ignite-3 will still use the 
index for the subquery.

> Sql. Introduce sorted reducer for IndexScanNode
> ---
>
> Key: IGNITE-17813
> URL: https://issues.apache.org/jira/browse/IGNITE-17813
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This task is derived from IGNITE-17655 to reduce its scope.
> Currently, IgniteScanNode reads partition after partition which, obviously, 
> breaks the sorting order. We need to introduce wrapping cursor, which accepts 
> open cursors for every partition, and produce the sorted output.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17729) Forbidding a table and an index with the same names.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17729:
-

Assignee: Pavel Pereslegin

> Forbidding a table and an index with the same names.
> 
>
> Key: IGNITE-17729
> URL: https://issues.apache.org/jira/browse/IGNITE-17729
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> From code review for [1] Andrey Mashenkov highlight what:
> {noformat}
> As far as I remember, we thought about forbidding a table and an index with 
> the same names.
> Let's add a check here or create a separate ticket for this particular case.
> {noformat}
> [1] https://issues.apache.org/jira/browse/IGNITE-17474



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17998:
-

Assignee: Pavel Pereslegin

> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
>   at 
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.

{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}


.



  was:
ItSqlAsynchronousApiTest#closeSession is unstable.

{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}



> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
>   at 
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
> {noformat}
> .



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.

{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}


.




> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
>   at 
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
> {noformat}
> h3. {*}UPDATE{*}:
> Since the test shows that the current behavior of "fetchNextPage" is unstable 
> on a closed session, we decided to investigate other possible use-cases on a 
> closed session.
> h4. The results are as follows:
> The behavior of the "execute*" session methods on a closed session is correct 
> - we throw a SqlException with the message "Session is closed" for any local 
> execution.
> Session return sync or async resultset. The 
> "hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
> expected results in a closed session with no errors.
>  
> The results of the rest of the methods are presented in the following table.
> |*ResultSet type*|*Method*|*RESULT*|
> | |*Data absent*|*Data present (pageSize=2)*|
> |sync|*hasNext*|false|true|
> |*next*|NoSuchElementException|4 rows, then CursorClosedException|
> | |
> |async|*CurrentPage (hasNext)*|false|true|
> |*currentPageSize*|0|2|

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
| |*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
| |*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exce

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*||
|| || ||*Data absent*||*Data present (pageSize=2)*||
| |*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
| |*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
| |*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
| |*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
>  

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| | |
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{*}|| ||
|*sync*|*hasNext*|false|true| |
| |*next*|NoSuchElementException|4 rows, then CursorClosedException| |
| | | | | |
|*async*|*CurrentPage (hasNext)*|false|true| |
| |*currentPageSize*|0|2| |
| |*hasMorePages*|false|true| |
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or 
ExecutionCancelledException| |

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstab

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| | |
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{*}|| ||
|*sync*|*hasNext*|false|true| |
| |*next*|NoSuchElementException|4 rows, then CursorClosedException| |
| | | | | |
|*async*|*CurrentPage (hasNext)*|false|true| |
| |*currentPageSize*|0|2| |
| |*hasMorePages*|false|true| |
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or 
ExecutionCancelledException| |

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*||
|| || ||*Data absent*||*Data present (pageSize=2)*||
| |*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
| |*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> 

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

 
|*ResultSet type*|*Method*|*RESULT*|
| |*Data absent*|*Data present (pageSize=2)*|
|sync|*hasNext*|false|true|
|*next*|NoSuchElementException|4 rows, then CursorClosedException|
| |
|async|*CurrentPage (hasNext)*|false|true|
|*currentPageSize*|0|2|
|*hasMorePages*|false|true|
|*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession i

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*RESULT*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|



> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
> 

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>   

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#172b4d}4 rows, then 
CursorClosedException{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
{color:#de350b}Currently: No exception or CursorClosedException or 
ExecutionCancelledException{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||{*}Data present (pageSize=2){*}{*}{{*}}||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|4 rows, then CursorClosedException|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
Currently: No exception or CursorClosedException or ExecutionCancelledException|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWi

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#00}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
{{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#00}4 rows, then 
CursorClosedException{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
{color:#aa}Currently: No exception or CursorClosedException or 
ExecutionCancelledException{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#00}4 rows, then 
CursorClosedException{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
{color:#aa}Currently: No exception or CursorClosedException or 
ExecutionCancelledException{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#172b4d}4 rows, then 
CursorClosedException{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
CursorClosedException
{color:#de350b}Currently: No exception or CursorClosedException or 
ExecutionCancelledException{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframew

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#00}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*sync*|*hasNext*|false|true|
| |*next*|NoSuchElementException|{color:#00}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*async*|*CurrentPage (hasNext)*|false|true|
| |*currentPageSize*|0|2|
| |*hasMorePages*|false|true|
| |*fetchNextPage*|SqlException IGN-SQL-1 There are no more pages.|Expected: 
{{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#00}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(A

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

 

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(Asse

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}}" methods are generic and give the expected 
results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The 
"{{hasRowSet}}/{{affectedRows}}/{{wasApplied}}/{{metadata}}" methods are 
generic and give the expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlExceptio

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The 
"{{hasRowSet}}/{{affectedRows}}/{{wasApplied}}/{{metadata}}" methods are 
generic and give the expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "execute*" session methods on a closed session is correct - 
we throw a SqlException with the message "Session is closed" for any local 
execution.

Session return sync or async resultset. The 
"hasRowSet/affectedRows/wasApplied/metadata" methods are generic and give the 
expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}}" methods are generic and give the expected 
results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apa

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results in a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: clas

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases on a 
closed session.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.Sq

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.jun

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||*ResultSet type*||*Method*||*Result*|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at o

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

"{{execute}}*" returns sync or async resultset. The "{{hasRowSet}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{close}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

Session return sync or async resultset. The "{{hasRowSet}} / {{affectedRows}} / 
{{wasApplied}} / {{metadata}} / {{close}}" methods are generic and give the 
expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (2 pages) initially
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{execute}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{Session is closed}}" 
for any local execution.

"{{execute}}*" returns sync or async resultset. The "{{hasRowSet}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{close}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows, then 
{{CursorClosedException}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception 

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|
| | | | |
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (2 pages) initially
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (2 pages) initially
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|
| | | | |
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: 

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|
| | | | |
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (prefetches 2 pages)
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|
| | | | |
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (2 pages) initially
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels:

[jira] [Updated] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17998:
--
Description: 
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|
| | | | |
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (initially, 2 pages 
are preloaded)
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|

  was:
ItSqlAsynchronousApiTest#closeSession is unstable.
{noformat}
org.opentest4j.AssertionFailedError: Exception is neither of a specified class, 
nor has a cause of the specified class: class org.apache.ignite.sql.SqlException

at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
at 
org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
at 
org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
{noformat}
h3. {*}UPDATE{*}:

Since the test shows that the current behavior of "fetchNextPage" is unstable 
on a closed session, we decided to investigate other possible use-cases.
h4. The results are as follows:

The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
correct - we throw a {{SqlException}} with the message "{{{}Session is 
closed{}}}" for any local execution.

"{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
{{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
generic and give the expected results on a closed session with no errors.

The results of the rest of the methods are presented in the following table.
||ResultSet type||Method||Result|| ||
|| || ||*Data absent*||*Data present (pageSize=2)*||
|*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
| |*{{currentPageSize}}*|0|2|
| |*{{hasMorePages}}*|false|true|
| |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
pages.|Expected: {{CursorClosedException}}
{color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
{{ExecutionCancelledException}}{color}|
| | | | |
|*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
| |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (prefetches 2 pages)
then {{CursorClosedException}}
{{(dependent on "fetchNextPage" so currently similar unstable behavior is 
possible).}}{color}|


> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> 

[jira] [Assigned] (IGNITE-17704) Get rid of usage of RelDataType in execution nodes

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-17704:
-

Assignee: Pavel Pereslegin

> Get rid of usage of RelDataType in execution nodes
> --
>
> Key: IGNITE-17704
> URL: https://issues.apache.org/jira/browse/IGNITE-17704
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3, tech-debt
>
> Execution-related classes have no third-party dependencies except for apache 
> calcite. The only thing connecting them is the RelDataType class, describing 
> a type of the row.
> Seems the only actual usage of row type is inside 
> {{CorrelatedNestedLoopJoinNode}}.
> So let's get rid of unnecessary coupling by reworking 
> {{CorrelatedNestedLoopJoinNode}} class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17704) Get rid of usage of RelDataType in execution nodes

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-17704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-17704:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Get rid of usage of RelDataType in execution nodes
> --
>
> Key: IGNITE-17704
> URL: https://issues.apache.org/jira/browse/IGNITE-17704
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Execution-related classes have no third-party dependencies except for apache 
> calcite. The only thing connecting them is the RelDataType class, describing 
> a type of the row.
> Seems the only actual usage of row type is inside 
> {{CorrelatedNestedLoopJoinNode}}.
> So let's get rid of unnecessary coupling by reworking 
> {{CorrelatedNestedLoopJoinNode}} class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634174#comment-17634174
 ] 

Pavel Pereslegin commented on IGNITE-17998:
---

[~korlov], I've updated the PR, please have a look.

> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified 
> class, nor has a cause of the specified class: class 
> org.apache.ignite.sql.SqlException
>   at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
>   at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
>   at 
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
>   at 
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
> {noformat}
> h3. {*}UPDATE{*}:
> Since the test shows that the current behavior of "fetchNextPage" is unstable 
> on a closed session, we decided to investigate other possible use-cases.
> h4. The results are as follows:
> The behavior of the "{{{}execute{}}}*" session methods on a closed session is 
> correct - we throw a {{SqlException}} with the message "{{{}Session is 
> closed{}}}" for any local execution.
> "{{{}execute{}}}*" returns sync or async resultset. The "{{{}hasRowSet{}}} / 
> {{affectedRows}} / {{wasApplied}} / {{metadata}} / {{{}close{}}}" methods are 
> generic and give the expected results on a closed session with no errors.
> The results of the rest of the methods are presented in the following table.
> ||ResultSet type||Method||Result|| ||
> || || ||*Data absent*||*Data present (pageSize=2)*||
> |*{{async}}*|*{{CurrentPage}} (hasNext)*|{{false}}|{{true}}|
> | |*{{currentPageSize}}*|0|2|
> | |*{{hasMorePages}}*|false|true|
> | |*{{fetchNextPage}}*|{{SqlException}} IGN-SQL-1 There are no more 
> pages.|Expected: {{CursorClosedException}}
> {color:#aa}Currently: {{No exception}} or {{CursorClosedException}} or 
> {{ExecutionCancelledException}}{color}|
> | | | | |
> |*{{sync}}*|*{{hasNext}}*|{{false}}|{{true}}|
> | |*next*|{{NoSuchElementException}}|{color:#676700}4 rows (initially, 2 
> pages are preloaded)
> then {{CursorClosedException}}
> {{(dependent on "fetchNextPage" so currently similar unstable behavior is 
> possible).}}{color}|



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-18156:
-

Assignee: Pavel Pereslegin

> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
>  Issue Type: Sub-task
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones  by DDL 
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
>     { fq_zone_name | simple_zone_name }
>     [WITH
>         [
>              |
>             DATA_NODES_FILTER filter |
>             (, DATA_NODES_FILTER filter)
>         ],
>         [PARTITIONS = partitions],
>         [REPLICAS = replicas],
>         [AFFINITY_FUNCTION = function]
>     ]
> [;]
>  
>  ::= [
>     DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
>     DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
>     (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value & 
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) | 
> DATA_NODES_AUTO_ADJUST  = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and 
> provide a valid AST representing those statements.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-18157) Sql. Provide commands and handlers for distributed zones related operations

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-18157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-18157:
-

Assignee: Pavel Pereslegin

> Sql. Provide commands and handlers for distributed zones related operations
> ---
>
> Key: IGNITE-18157
> URL: https://issues.apache.org/jira/browse/IGNITE-18157
> Project: Ignite
>  Issue Type: Sub-task
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> After implementing IGNITE-18156 Need to provide DDL commands and their 
> handlers to configure zones configuration in, as well as translation to these 
> command from AST representation.
> As a result, we will be able to translate AST to a command (see 
> {{{}DdlSqlToCommandConverter{}}}) and execute this command in order to apply 
> changes to configuration (see {{{}DdlCommandHandler{}}}).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-16072) Add configurable throttling for the spanshot process

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-16072:
-

Assignee: (was: Pavel Pereslegin)

> Add configurable throttling for the spanshot process
> 
>
> Key: IGNITE-16072
> URL: https://issues.apache.org/jira/browse/IGNITE-16072
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
>  Labels: iep-43, ise
> Fix For: 2.13
>
>
> We want to add configurable throttling to the number of threads that perform 
> a snapshot operation. The IGNITE-16014 have introduced the pool size 
> configuration property, however, it is still possible that a node can become 
> overloaded and unresponsive due to its attempts to copy data files on very 
> slow HDDs. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (IGNITE-15450) Snapshot restore control.sh command should display a user-friendly error about existing caches.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-15450:
-

Assignee: Pavel Pereslegin

> Snapshot restore control.sh command should display a user-friendly error 
> about existing caches.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
>  
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (IGNITE-15450) Snapshot restore control.sh command should display a user-friendly error about existing caches.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-15450:
-

Assignee: (was: Pavel Pereslegin)

> Snapshot restore control.sh command should display a user-friendly error 
> about existing caches.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
>  
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (IGNITE-15450) Snapshot restore control.sh command should display a user-friendly error about existing caches.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin reassigned IGNITE-15450:
-

Assignee: Pavel Pereslegin

> Snapshot restore control.sh command should display a user-friendly error 
> about existing caches.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
>  
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-16150) Get rid of redundant copying of files after downloading when restoring a snapshot.

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479857#comment-17479857
 ] 

Pavel Pereslegin edited comment on IGNITE-16150 at 1/21/22, 6:40 AM:
-

[~mmuzaf], take a look at the proposed changes, please.


was (Author: xtern):
[~mmuzaf], take a look at this little patch, please.

> Get rid of redundant copying of files after downloading when restoring a 
> snapshot. 
> ---
>
> Key: IGNITE-16150
> URL: https://issues.apache.org/jira/browse/IGNITE-16150
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> During the snapshot restore procedure after retrieving the partition file 
> from the remote node, we create an additional copy of this file.
> {code:java}
>   for (Map.Entry>> m : snpAff.entrySet()) 
> {
>   ctx.cache().context().snapshotMgr()
>   .requestRemoteSnapshotFiles(m.getKey(),
>   opCtx0.snpName,
>   m.getValue(),
>   opCtx0.stopChecker,
>   (snpFile, t) -> {
>   ...
>   Path partFile = 
> Paths.get(tmpCacheDir.getAbsolutePath(), snpFile.getName());
>   try {
>   
> IgniteSnapshotManager.copy(snpMgr.ioFactory(),
>   snpFile,
>   partFile.toFile(),
>   snpFile.length());
>   ...
> {code}
> File copying is redundant here and can have significant performance overhead.
> Instead, we have to download the file to the target directory (and rename it 
> to the desired name if necessary).



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-12971) Create snapshot view to show available cluster snapshots

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480890#comment-17480890
 ] 

Pavel Pereslegin commented on IGNITE-12971:
---

[~RyzhovSV],
changes look good, thanks for the contribution!


> Create snapshot view to show available cluster snapshots
> 
>
> Key: IGNITE-12971
> URL: https://issues.apache.org/jira/browse/IGNITE-12971
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Sergei Ryzhov
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Users must be able to see available information about cluster snapshots 
> through the view:
> 1. Snapshot name
> 2. Consistent ID of a node to which snapshot data relates 
> 3. Baseline nodes affected by snapshots
> 4. Cache group names that were included in the snapshot



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-12971) Create snapshot view to show available cluster snapshots

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-12971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480891#comment-17480891
 ] 

Pavel Pereslegin commented on IGNITE-12971:
---

[~mmuzaf],
could you review the proposed changes?

> Create snapshot view to show available cluster snapshots
> 
>
> Key: IGNITE-12971
> URL: https://issues.apache.org/jira/browse/IGNITE-12971
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Sergei Ryzhov
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 6h
>  Remaining Estimate: 0h
>
> Users must be able to see available information about cluster snapshots 
> through the view:
> 1. Snapshot name
> 2. Consistent ID of a node to which snapshot data relates 
> 3. Baseline nodes affected by snapshots
> 4. Cache group names that were included in the snapshot



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-15450:
--
Summary: Add special option to run snapshot commands (create/restore) 
synchronously.  (was: Snapshot restore control.sh command should display a 
user-friendly error about existing caches.)

> Add special option to run snapshot commands (create/restore) synchronously.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
>  
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.

[Pavel Pereslegin (Jira)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-15450:
--
Description: 
The process of restoring a snapshot fails if at least one of the restored 
caches already exists. 
 However, when starting this operation via control.sh, the command returns a 
successful startup status, which can be confusing for users.

We can improve this behavior by adding a separate check for existing caches 
when starting the restore operation and displaying a user-friendly error 
message.

An *alternative* option is to start a snapshot restore operation synchronously.

  was:
The process of restoring a snapshot fails if at least one of the restored 
caches already exists. 
 However, when starting this operation via control.sh, the command returns a 
successful startup status, which can be confusing for users.

We can improve this behavior by adding a separate check for existing caches 
when starting the restore operation and displaying a user-friendly error 
message.

 

An *alternative* option is to start a snapshot restore operation synchronously.


> Add special option to run snapshot commands (create/restore) synchronously.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin commented on IGNITE-15450:
---

The final solution is to add a "wait" flag to wait for the entire operation to 
complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]

Parameters:
  snapshot_name  - Snapshot name.
  wait   - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups 
group1,...groupN]

Parameters:
  snapshot_name - Snapshot name.
  wait  - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
  group1,...groupN  - Cache group names.
{noformat}

> Add special option to run snapshot commands (create/restore) synchronously.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (IGNITE-15450) Add special option to run snapshot commands (create/restore) synchronously.

[Pavel Pereslegin (Jira)]

[ 
https://issues.apache.org/jira/browse/IGNITE-15450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481846#comment-17481846
 ] 

Pavel Pereslegin edited comment on IGNITE-15450 at 1/25/22, 2:28 PM:
-

The final solution is to add a "wait" option to wait for the entire operation 
to complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]

Parameters:
  snapshot_name  - Snapshot name.
  wait   - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups 
group1,...groupN]

Parameters:
  snapshot_name - Snapshot name.
  wait  - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
  group1,...groupN  - Cache group names.
{noformat}


was (Author: xtern):
The final solution is to add a "wait" flag to wait for the entire operation to 
complete.

*Create*
{noformat}
  Create cluster snapshot:
control.(sh|bat) --snapshot create snapshot_name [--wait]

Parameters:
  snapshot_name  - Snapshot name.
  wait   - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
{noformat}

*Restore*
{noformat}
  Restore snapshot:
control.(sh|bat) --snapshot restore snapshot_name [--wait] [--groups 
group1,...groupN]

Parameters:
  snapshot_name - Snapshot name.
  wait  - Wait for the entire operation to complete. Otherwise, 
the operation will be performed in the background, and the command will 
immediately return control.
  group1,...groupN  - Cache group names.
{noformat}

> Add special option to run snapshot commands (create/restore) synchronously.
> ---
>
> Key: IGNITE-15450
> URL: https://issues.apache.org/jira/browse/IGNITE-15450
> Project: Ignite
>  Issue Type: Improvement
>  Components: control.sh
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: iep-43, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The process of restoring a snapshot fails if at least one of the restored 
> caches already exists. 
>  However, when starting this operation via control.sh, the command returns a 
> successful startup status, which can be confusing for users.
> We can improve this behavior by adding a separate check for existing caches 
> when starting the restore operation and displaying a user-friendly error 
> message.
> An *alternative* option is to start a snapshot restore operation 
> synchronously.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)