[jira] [Created] (IGNITE-17612) Sql. Unmute sql tests
Konstantin Orlov created IGNITE-17612: - Summary: Sql. Unmute sql tests Key: IGNITE-17612 URL: https://issues.apache.org/jira/browse/IGNITE-17612 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Because of a poor performance of current transactional protocol, several sql tests was disabled under this ticked. Need to enable those tests after new protocol will be merged to main. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17596:
Component/s: thin client
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-17596:
Fix Version/s: 3.0.0-alpha6
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598975#comment-17598975
]
Pavel Tupitsyn commented on IGNITE-17596:
-
[~vpakhnushev] looks good to me. Merged to main:
efda0215c8a6dc9193b6f94da905c3f1db02f920
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17596) ItThinClientComputeTest fails on Windows
[
https://issues.apache.org/jira/browse/IGNITE-17596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev reassigned IGNITE-17596:
-
Assignee: Vadim Pakhnushev
> ItThinClientComputeTest fails on Windows
>
>
> Key: IGNITE-17596
> URL: https://issues.apache.org/jira/browse/IGNITE-17596
> Project: Ignite
> Issue Type: Bug
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{ItThinClientComputeTest}} fails on Windows due to the not correlated
> changes in two tickets.
> In IGNITE-16734 the test was added which compared the result of
> {{NodeNameJob}} to the hardcoded string.
> In IGNITE-16691
> {{org.apache.ignite.internal.testframework.IgniteTestUtils#testNodeName}} was
> changed so on Windows node name in those tests is now not the expected
> {{"ItThinClientComputeTest_null_3344"}}, but short {{"n_3344"}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17611) Implement proper local storage recovery for transaction state store
[
https://issues.apache.org/jira/browse/IGNITE-17611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-17611:
---
Description:
h3. Preliminaries
Current design expects transaction states to be replicated using the same RAFT
groups that process partition transactional data. In code this means that there
are two physical storages associated with a single state machine. This design
is easy to achieve when the system is stable, but fault tolerance and basic
node restart might introduce some complications.
h3. Partition storage design
By itself, partition storage works this way:
* every write command writes value of the RAFT log index, associated with the
command;
* this index value is written atomically with the data from the command;
* updates are accumulated in the memory buffer before being written to disk.
* upon restart, we read the value of the last applied index and proceed the
recovery process from it. It's done with RAFT snapshots infrastructure.
h3. Changes to tx state store
Basically, everything has to be repeated:
* applied index value must be introduced to tx state storage;
* updates must be atomic;
* on restart, we should use the minimal value of last applied index from both
TX State and MvPartinion storages ({{{}PartitionSnapshotStorage{}}} has to be
changed).
h3. Other necessary changes
* atomic flush must be set up for the tx state storage. WAL should be disabled;
* snapshot command must trigger the flush. Please refer to
{{RocksDbFlushListener}} and {{RocksDbMvPartitionStorage#flush}} for
implementation reference. Listener class can be generified and reused;
* assertion in {{PartitionListener#onWrite}} should be removed or drastically
improved;
* read operation on storages must be prohibited until local recovery is
completed - we should apply all command up to "commitIndex" value that's been
read at the start of the node, otherwise storages may have data, inconsistent
with each other.
was:
h3. Preliminaries
Current design expects transaction states to be replicated using the same RAFT
groups that process partition transactional data. In code this means that there
are two physical storages associated with a single state machine. This design
is easy to achieve when the system is stable, but fault tolerance and basic
node restart might introduce some complications.
h3. Partition storage design
By itself, partition storage works this way:
* every write command writes value of the RAFT log index, associated with the
command;
* this index value is written atomically with the data from the comment;
* updates are accumulated in the memory buffer before being written to disk.
* upon restart, we read the value of the last applied index and proceed the
recovery process from it. It's done with RAFT snapshots infrastructure.
h3. Changes to tx state store
Basically, everything has to be repeated:
* applied index value must be introduced to tx state storage;
* updates must be atomic;
* on restart, we should use the minimal value of last applied index from both
TX State and MvPartinion storages ({{{}PartitionSnapshotStorage{}}} has to be
changed).
h3. Other necessary changes
* atomic flush must be set up for the tx state storage. WAL should be disabled;
* snapshot command must trigger the flush. Please refer to
{{RocksDbFlushListener}} and {{RocksDbMvPartitionStorage#flush}} for
implementation reference. Listener class can be generified and reused;
* assertion in {{PartitionListener#onWrite}} should be removed or drastically
improved;
* read operation on storages must be prohibited until local recovery is
completed - we should apply all command up to "commitIndex" value that's been
read at the start of the node, otherwise storages may have data, inconsistent
with each other.
> Implement proper local storage recovery for transaction state store
> ---
>
> Key: IGNITE-17611
> URL: https://issues.apache.org/jira/browse/IGNITE-17611
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
>
> h3. Preliminaries
> Current design expects transaction states to be replicated using the same
> RAFT groups that process partition transactional data. In code this means
> that there are two physical storages associated with a single state machine.
> This design is easy to achieve when the system is stable, but fault tolerance
> and basic node restart might introduce some complications.
> h3. Partition storage design
> By itself, partition storage works this way:
> * every write command writes value of the RAFT log index, associated with
> the command;
> * this index value is written atomically with the data from the command;
> * updates are accumulated in the
[jira] [Created] (IGNITE-17611) Implement proper local storage recovery for transaction state store
Ivan Bessonov created IGNITE-17611:
--
Summary: Implement proper local storage recovery for transaction
state store
Key: IGNITE-17611
URL: https://issues.apache.org/jira/browse/IGNITE-17611
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
h3. Preliminaries
Current design expects transaction states to be replicated using the same RAFT
groups that process partition transactional data. In code this means that there
are two physical storages associated with a single state machine. This design
is easy to achieve when the system is stable, but fault tolerance and basic
node restart might introduce some complications.
h3. Partition storage design
By itself, partition storage works this way:
* every write command writes value of the RAFT log index, associated with the
command;
* this index value is written atomically with the data from the comment;
* updates are accumulated in the memory buffer before being written to disk.
* upon restart, we read the value of the last applied index and proceed the
recovery process from it. It's done with RAFT snapshots infrastructure.
h3. Changes to tx state store
Basically, everything has to be repeated:
* applied index value must be introduced to tx state storage;
* updates must be atomic;
* on restart, we should use the minimal value of last applied index from both
TX State and MvPartinion storages ({{{}PartitionSnapshotStorage{}}} has to be
changed).
h3. Other necessary changes
* atomic flush must be set up for the tx state storage. WAL should be disabled;
* snapshot command must trigger the flush. Please refer to
{{RocksDbFlushListener}} and {{RocksDbMvPartitionStorage#flush}} for
implementation reference. Listener class can be generified and reused;
* assertion in {{PartitionListener#onWrite}} should be removed or drastically
improved;
* read operation on storages must be prohibited until local recovery is
completed - we should apply all command up to "commitIndex" value that's been
read at the start of the node, otherwise storages may have data, inconsistent
with each other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16714) [IEP-80] Move binary metadata storage to distributed metastorage
[ https://issues.apache.org/jira/browse/IGNITE-16714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598890#comment-17598890 ] Maxim Muzafarov commented on IGNITE-16714: -- The same issues are related to the marshaller mapping also. > [IEP-80] Move binary metadata storage to distributed metastorage > > > Key: IGNITE-16714 > URL: https://issues.apache.org/jira/browse/IGNITE-16714 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-80, ise > > We have common way to spread internal information over the cluster - > distributed metastorage. > But, currently, binary_metadata uses own code to do the same. > Moreover, binary_metadata folder stores file separately from other Ignite > data. > This should be refactored and binary metadata stored inside distributed > metastorage. > Additionally, we can introduce tool to retrieve and upload binary schemes to > the cluster to overcome possible bugs or edgecases during migration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598821#comment-17598821
]
Andrey Novikov commented on IGNITE-17594:
-
[~jooger] Can you please review this PR as maintainer of sql?
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose internal API to provide ability to listen query start/finish
> events. This allow to monitor query execution in monitoring tools.
> Need to pass following properties: query, queryType,
> schemaName, startTime, finishTime, local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Novikov updated IGNITE-17594:
Description:
Need to expose internal API to provide ability to listen query start/finish
events. This allow to monitor query execution in monitoring tools.
Need to pass following properties: query, queryType,
schemaName, startTime, finishTime, local, {{{}cancellable{}}},
{{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
{{failedReason}}
was:
Need to expose internal API to provide ability to listen query start/finish
events.
Need to pass following properties: query, queryType,
schemaName, startTime, finishTime, local, {{{}cancellable{}}},
{{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
{{failedReason}}
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose internal API to provide ability to listen query start/finish
> events. This allow to monitor query execution in monitoring tools.
> Need to pass following properties: query, queryType,
> schemaName, startTime, finishTime, local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17594) Provide ability to register listeners for query start/finish events
[
https://issues.apache.org/jira/browse/IGNITE-17594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598819#comment-17598819
]
Ignite TC Bot commented on IGNITE-17594:
{panel:title=Branch: [pull/10227/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10227/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6754458]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteSqlQueryStartFinishListenerTest.testVerifyQueryInfoPassedToListeners -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteSqlQueryStartFinishListenerTest.testListeneresNotBlocksQueryExecution -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteSqlQueryStartFinishListenerTest.testRegisterUnregisterQueryListeners -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
IgniteSqlQueryStartFinishListenerTest.testFailedListenereNotAffectOthers -
PASSED{color}
{color:#8b}Queries 1 (lazy=true){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6754459]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteSqlQueryStartFinishListenerTest.testVerifyQueryInfoPassedToListeners -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteSqlQueryStartFinishListenerTest.testFailedListenereNotAffectOthers -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteSqlQueryStartFinishListenerTest.testListeneresNotBlocksQueryExecution -
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite:
IgniteSqlQueryStartFinishListenerTest.testRegisterUnregisterQueryListeners -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6754488buildTypeId=IgniteTests24Java8_RunAll]
> Provide ability to register listeners for query start/finish events
> ---
>
> Key: IGNITE-17594
> URL: https://issues.apache.org/jira/browse/IGNITE-17594
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Need to expose internal API to provide ability to listen query start/finish
> events.
> Need to pass following properties: query, queryType,
> schemaName, startTime, finishTime, local, {{{}cancellable{}}},
> {{{}enforceJoinOrder{}}}, {{{}lazy{}}}, {{{}distributedJoins{}}},
> {{failedReason}}
--
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.
[
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-17610) Rework snapshot cancel command and simplify syntax in control script.
[
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.
[
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.
[
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 command syntax in control script.
[
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 snapshot command syntax in control script.
[
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] [Created] (IGNITE-17610) Rework snapshot cancel command and simplify snapshot command syntax in control script.
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.
[
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-17609) Fix logs interpretation
Mikhail Pochatkin created IGNITE-17609: -- Summary: Fix logs interpretation Key: IGNITE-17609 URL: https://issues.apache.org/jira/browse/IGNITE-17609 Project: Ignite Issue Type: Bug Components: build, ignite-3 Reporter: Mikhail Pochatkin Currently `ignite-network-annotation-processor` produce a lot of NOTE logs `org.apache.ignite.internal.network.processor.serialization.MessageSerializerGenerator#generateSerializer` In the progress of build via gradle IDEA marks these logs as errors and as result we see that build SUCCESS but has 300+ errors. This is not a problem of successful builds, this is a problem of developer convenience and log clarity. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598793#comment-17598793
]
Taras Ledkov commented on IGNITE-17600:
---
Cherry-picked to
[ignite-2.14|https://github.com/apache/ignite/commit/fe05c2d2eac83e4f3d7780c55da27a549dc58946]
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.13
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17608) Fix pmd and checkstyle for gradle build
Mikhail Pochatkin created IGNITE-17608: -- Summary: Fix pmd and checkstyle for gradle build Key: IGNITE-17608 URL: https://issues.apache.org/jira/browse/IGNITE-17608 Project: Ignite Issue Type: Bug Components: build, ignite-3 Reporter: Mikhail Pochatkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598781#comment-17598781 ] Taras Ledkov commented on IGNITE-17499: --- Merged to [ignite-2.14|https://github.com/apache/ignite/commit/1b0e8d950ab31906652ce93c620318382e003901] > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17495) Create start, stop, restart scripts for ingite-db
[ https://issues.apache.org/jira/browse/IGNITE-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-17495: -- Assignee: Mikhail Pochatkin > Create start, stop, restart scripts for ingite-db > - > > Key: IGNITE-17495 > URL: https://issues.apache.org/jira/browse/IGNITE-17495 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17226) Calcite engine. Make calcite engine independent of H2 and ignite-indexing
[ https://issues.apache.org/jira/browse/IGNITE-17226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov resolved IGNITE-17226. Release Note: Calcite-based SQL engine is now independent of H2-based SQL engine and doesn't require 'ignite-indexing' module and H2 to be in classpath anymore Resolution: Fixed > Calcite engine. Make calcite engine independent of H2 and ignite-indexing > - > > Key: IGNITE-17226 > URL: https://issues.apache.org/jira/browse/IGNITE-17226 > Project: Ignite > Issue Type: Task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, important > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, some functionality from ignite-indexing is still required for > Calcite-based SQL engine, we should move such a functionality to the core > module to make Calcite-based SQL engine fully independent of H2 and the > ignite-indexing module. > This is an umbrella ticket for migrating parts of the ignite-indexing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598774#comment-17598774
]
Ivan Daschinsky edited comment on IGNITE-17600 at 9/1/22 7:22 AM:
--
Thanks for your contribution, merged to master
was (Author: ivandasch):
Thanks for you contribution, merged to master
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.13
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15424) Calcite engine. Move schema management infrastructure to the core module
[
https://issues.apache.org/jira/browse/IGNITE-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-15424:
---
Labels: ignite-osgi important osgi (was: calcite2-required ignite-osgi
important osgi)
> Calcite engine. Move schema management infrastructure to the core module
> -
>
> Key: IGNITE-15424
> URL: https://issues.apache.org/jira/browse/IGNITE-15424
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ignite-osgi, important, osgi
> Fix For: 2.14
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Currently, schema management commands initiated in the {{ignite-core}}
> module, but all processing implemented in the {{ignite-indexing}} module.
> Ignite Calciite SQL engine use {{SchemaChangeListener}} to maintain own
> structures.
> To get rid of {{ignite-indexing}} (and H2) dependency from the
> {{ignite-calcite}} module we should move schema management implementation to
> the core module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17226) Calcite engine. Make calcite engine independent of H2 and ignite-indexing
[ https://issues.apache.org/jira/browse/IGNITE-17226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-17226: --- Labels: calcite important (was: important) > Calcite engine. Make calcite engine independent of H2 and ignite-indexing > - > > Key: IGNITE-17226 > URL: https://issues.apache.org/jira/browse/IGNITE-17226 > Project: Ignite > Issue Type: Task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, important > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, some functionality from ignite-indexing is still required for > Calcite-based SQL engine, we should move such a functionality to the core > module to make Calcite-based SQL engine fully independent of H2 and the > ignite-indexing module. > This is an umbrella ticket for migrating parts of the ignite-indexing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-17600:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.13
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-17600:
-
Affects Version/s: 2.13
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.13
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-17600:
-
Priority: Major (was: Minor)
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.13
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-17600:
-
Component/s: documentation
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17600) Fix control.sh index rebuild args
[
https://issues.apache.org/jira/browse/IGNITE-17600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-17600:
-
Labels: documentation (was: )
> Fix control.sh index rebuild args
> --
>
> Key: IGNITE-17600
> URL: https://issues.apache.org/jira/browse/IGNITE-17600
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Labels: documentation
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation says that the command control.sh --cache
> indexes_force_rebuild accepts arguments --cache-name and --cache-group, but
> in reality it expects --cache-name{*}s{*} and --cache-group{*}s{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[ https://issues.apache.org/jira/browse/IGNITE-17541 ]
Julia Bakulina deleted comment on IGNITE-17541:
-
was (Author: JIRAUSER294860):
[~ivandasch], could you please review the changes? Not sure what fix version to
include
> Add "set" prefix to
> ThinClientConfiguration#sendServerExceptionStackTraceToClient()
> ---
>
> Key: IGNITE-17541
> URL: https://issues.apache.org/jira/browse/IGNITE-17541
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 2h 25m
> Remaining Estimate: 0h
>
> IGNITE-13389 introduces
> {{ThinClientConfiguration#sendServerExceptionStackTraceToClient()}}, but name
> of the method does not allow to set up this option in XML configuration,
> because Spring expects "set" prefix for setters.
> As you can see below, there is a workaround, but it would be more convenient
> to set up this property directly.
> Workaround:
> {code:xml|title=Add extra ThinClientConfiguration bean with necessary
> parameters}
> class="org.apache.ignite.configuration.ThinClientConfiguration">
>
>
> {code}
> {code:xml|title=Set up thinClientConfiguration by means of SpEL}
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration">
>
> value="#{thinClientCfg.sendServerExceptionStackTraceToClient(true)}"/>
>
>
> {code}
> We should add "set" and "get" prefix to setter and getter methods
> respectively or add extra methods with such prefixes from the point of
> possible compatibility issues (see IGNITE-16549).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-15424) Calcite engine. Move schema management infrastructure to the core module
[
https://issues.apache.org/jira/browse/IGNITE-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17598763#comment-17598763
]
Ignite TC Bot commented on IGNITE-15424:
{panel:title=Branch: [pull/10200/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10200/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Compatibility){color} [[tests
4|https://ci2.ignite.apache.org/viewLog.html?buildId=6585353]]
* {color:#013220}IgniteCompatibilityBasicTestSuite:
CompoundIndexCompatibilityTest.testSecondaryIndexesMigration_2_7_6 -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
CompoundIndexCompatibilityTest.testSecondaryIndexesMigration_2_13_0 -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
IgnitePKIndexesMigrationToUnwrapPkTest.testSecondaryIndexesMigration_2_5 -
PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite:
IgnitePKIndexesMigrationToUnwrapPkTest.testSecondaryIndexesMigration_2_4 -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6581689buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Move schema management infrastructure to the core module
> -
>
> Key: IGNITE-15424
> URL: https://issues.apache.org/jira/browse/IGNITE-15424
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, ignite-osgi, important, osgi
> Fix For: 2.14
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently, schema management commands initiated in the {{ignite-core}}
> module, but all processing implemented in the {{ignite-indexing}} module.
> Ignite Calciite SQL engine use {{SchemaChangeListener}} to maintain own
> structures.
> To get rid of {{ignite-indexing}} (and H2) dependency from the
> {{ignite-calcite}} module we should move schema management implementation to
> the core module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
