[jira] [Updated] (IGNITE-20302) Add EventType for clearing all cache
[ https://issues.apache.org/jira/browse/IGNITE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-20302: Fix Version/s: 2.16 > Add EventType for clearing all cache > > > Key: IGNITE-20302 > URL: https://issues.apache.org/jira/browse/IGNITE-20302 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Fix For: 2.16 > > > IgniteCache provides a functionality for clearing cache (IgniteCache#clear). > Users might want to listen events for clearing all cache thus it will be > useful to add EVT_CACHE_CLEARED to EventType. > There is EVT_CACHE_OBJECT_REMOVED but it is invoked each time clear() is > called: deleting a specific key, clearing the entire cache or clearing the > value by ttl but there is no event for clearing all cache. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20302) Add EventType for clearing all cache
[ https://issues.apache.org/jira/browse/IGNITE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-20302: Labels: ise (was: ) > Add EventType for clearing all cache > > > Key: IGNITE-20302 > URL: https://issues.apache.org/jira/browse/IGNITE-20302 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20302) Add EventType for clearing all cache
Julia Bakulina created IGNITE-20302: --- Summary: Add EventType for clearing all cache Key: IGNITE-20302 URL: https://issues.apache.org/jira/browse/IGNITE-20302 Project: Ignite Issue Type: Task Reporter: Julia Bakulina Assignee: Julia Bakulina -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20302) Add EventType for clearing all cache
[ https://issues.apache.org/jira/browse/IGNITE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-20302: Priority: Minor (was: Major) > Add EventType for clearing all cache > > > Key: IGNITE-20302 > URL: https://issues.apache.org/jira/browse/IGNITE-20302 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20302) Add EventType for clearing all cache
[ https://issues.apache.org/jira/browse/IGNITE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-20302: Fix Version/s: 2.16 > Add EventType for clearing all cache > > > Key: IGNITE-20302 > URL: https://issues.apache.org/jira/browse/IGNITE-20302 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Fix For: 2.16 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19168) Command for testing that snapshot partitions will be redistributed during restore
[
https://issues.apache.org/jira/browse/IGNITE-19168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-19168:
---
Assignee: (was: Julia Bakulina)
> Command for testing that snapshot partitions will be redistributed during
> restore
> -
>
> Key: IGNITE-19168
> URL: https://issues.apache.org/jira/browse/IGNITE-19168
> Project: Ignite
> Issue Type: New Feature
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: iep-43, ise
>
> When data is restored from snapshot, taken on other baseline topology (eg.
> with another consistent identifiers or different cluster size) there will be
> two stages that can last long enough:
> # Partitions redistribution according to affinity function.
> # Index rebuilding.
> It would be nice to have command for checking, that such redistribution won't
> or will occur, eg.:
> {noformat}
> control.sh --snapshot distribution snapshot_name
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20302) Add EventType for clearing all cache
[ https://issues.apache.org/jira/browse/IGNITE-20302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-20302: Description: IgniteCache provides a functionality for clearing cache (IgniteCache#clear). Users might want to listen events for clearing all cache thus it will be useful to add EVT_CACHE_CLEARED to EventType. There is EVT_CACHE_OBJECT_REMOVED but it is invoked each time clear() is called: deleting a specific key, clearing the entire cache or clearing the value by ttl but there is no event for clearing all cache. > Add EventType for clearing all cache > > > Key: IGNITE-20302 > URL: https://issues.apache.org/jira/browse/IGNITE-20302 > Project: Ignite > Issue Type: Task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Fix For: 2.16 > > > IgniteCache provides a functionality for clearing cache (IgniteCache#clear). > Users might want to listen events for clearing all cache thus it will be > useful to add EVT_CACHE_CLEARED to EventType. > There is EVT_CACHE_OBJECT_REMOVED but it is invoked each time clear() is > called: deleting a specific key, clearing the entire cache or clearing the > value by ttl but there is no event for clearing all cache. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Ignite Flags: Docs Required,Release Notes Required > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Ignite Flags: (was: Docs Required,Release Notes Required) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17576) Update Ignite dependency: MySQL Connector
Julia Bakulina created IGNITE-17576: --- Summary: Update Ignite dependency: MySQL Connector Key: IGNITE-17576 URL: https://issues.apache.org/jira/browse/IGNITE-17576 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Assignee: Julia Bakulina Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17537:
Flags: Patch
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17537:
Flags: (was: Patch)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: External issue URL: (was: https://github.com/apache/ignite/pull/9385) Ignite Flags: (was: Docs Required,Release Notes Required) Labels: newbie (was: ) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17584673#comment-17584673
]
Julia Bakulina commented on IGNITE-17537:
-
1) ", duration=" + getDuration() {*}/ 1000{*};
", timeout=" + getTimeout();
VisorTxInfo class:
[https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286]
2) long duration from getDuration() is in milliseconds as per VisorTxTask class
(long duration = U.currentTimeMillis() - locTx.startTime()):
[https://github.com/apache/ignite/blob/f6e2ebe8e62b3e442bda2a70f19544261b3c0cfa/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxTask.java#L243]
3) long timeout is in milliseconds as per IgniteInternalTx interface ("Gets
timeout value in milliseconds for this transaction"):
[https://github.com/apache/ignite/blob/e2008f4652544e51c75a8586ef8aee82fb2923b9/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/transactions/IgniteInternalTx.java#L148]
>From the above 1) -3) after dividing into 1000 the duration is in seconds
>while timeout is still in milliseconds which should be explicitly highlighted.
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Description: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.28 (was: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.28 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17537:
Fix Version/s: 2.14
(was: 2.15)
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17541:
---
Assignee: Julia Bakulina
> 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
>
> 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] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Description: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE (was: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Description: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 (was: Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.28) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: newbie > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 -- 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] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Priority: Minor (was: Major) > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: newbie > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17576) Update Ignite dependency: MySQL Connector
[ https://issues.apache.org/jira/browse/IGNITE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17576: Ignite Flags: Release Notes Required Release Note: Updated the MySql connector dependency version (fixes CVE-2021-2471, CVE-2022-21363). > Update Ignite dependency: MySQL Connector > - > > Key: IGNITE-17576 > URL: https://issues.apache.org/jira/browse/IGNITE-17576 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Update Ignite dependency: MySQL Connector 8.0.26 to 8.0.30 to avoid CVE -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17537) Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
[
https://issues.apache.org/jira/browse/IGNITE-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17537:
---
Assignee: Julia Bakulina
> Make units of 'timeout' and 'duration' more explicit in control.sh --tx output
> --
>
> Key: IGNITE-17537
> URL: https://issues.apache.org/jira/browse/IGNITE-17537
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Trivial
> Labels: ise, newbie
>
> Execution of {{control.sh --tx}} command produces output of matching
> transactions, eg.:
> {quote}Matching transactions:
> Tx: [xid=fdc4d720281--0fd8-0177--0012, label=null,
> state=ACTIVE, startTime=2022-07-06 05:05:07.432,
> {*}{color:#ff}duration=778{color}{*}, isolation=REPEATABLE_READ,
> concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=199,
> minorTopVer=0], {*}{color:#ff}timeout=4{color}{*}, ...]
> {quote}
> But, from the above line it is unclear, that in fact, duration is printed in
> seconds [1], while timeout is printed in milliseconds.
> We can improve output in one of the following ways:
> # Explicitly append unit for seconds and milliseconds.
> # Print duration and timeout in same units: both in seconds or both in
> milliseconds.
> Links:
> #
> https://github.com/apache/ignite/blob/bf9a460eccd07701cacac2a414c65707243350f1/modules/core/src/main/java/org/apache/ignite/internal/visor/tx/VisorTxInfo.java#L286
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619607#comment-17619607 ] Julia Bakulina commented on IGNITE-17916: - @timoninmaxim Hi Maxim, could you please review the changes? > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 50m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17619747#comment-17619747
]
Julia Bakulina commented on IGNITE-8801:
As decided on DevList, the ticket is divided into two parts:
- IGNITE-17916 - deprecates IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property in
version 2.15.0.
- IGNITE-8801 - deletes IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property in
version 2.16.0.
That is why this ticket is still unresolved and waits for 2.16.0 version
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Fix Version/s: 2.15
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
>
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Reviewer: Maksim Timonin > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 1h > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Flags: Important Release Note: Deprecated IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property. > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 1h 10m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Ignite Flags: Release Notes Required > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 1h 10m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Fix Version/s: 2.15 > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Fix For: 2.15 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Release Note: Fixed IdleVerify process not responding for an inactive
cluster with persistent data regions.
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
>
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Description:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in
\{{CacheOperationContext}} constructor without arguments and arguments for
calls of another constructor.
3) Fix javadocs.
As decided during the discussion in Ignite Dev List, we need to break changes
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.
was:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in
\{{CacheOperationContext}} constructor without arguments and arguments for
calls of another constructor.
3) Fix javadocs.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
Julia Bakulina created IGNITE-17916: --- Summary: Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property Key: IGNITE-17916 URL: https://issues.apache.org/jira/browse/IGNITE-17916 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Assignee: Julia Bakulina The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to break changes of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - this ticket; 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Description: The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to break changes of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - IGNITE-17916; 2) delete this property in the release after the next one - IGNITE-8801. was: The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to break changes of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - this ticket; 2) delete this property in the release after the next one - IGNITE-8801. > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Labels: ise (was: ) > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Ignite Flags: (was: Docs Required,Release Notes Required) > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to break changes > of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620170#comment-17620170 ] Julia Bakulina commented on IGNITE-17916: - [~timonin.maksim] thank you for the review! > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Fix For: 2.15 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The ticket is a part of > [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. > As decided during the discussion in Ignite Dev List, we need to *break > changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Affects Version/s: (was: 2.13)
(was: 2.14)
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
>
[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17620046#comment-17620046
]
Julia Bakulina commented on IGNITE-17383:
-
[~timoninmaxim] Hi Maxim, could you please review the changes?
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.13, 2.14
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
>
[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):
[~NSAmelchev], could you please review the changes?
They are almost fully checked by the previous reviewer.
Green visa https://mtcga.gridgain.com/prs.html
> 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
> Fix For: 2.15
>
> Attachments: Client_configuration_test.patch
>
> Time Spent: 5h 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] [Updated] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17541:
Fix Version/s: 2.14
(was: 2.15)
> 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
> Fix For: 2.14
>
> Attachments: Client_configuration_test.patch
>
> Time Spent: 5h 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] [Updated] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17541:
Reviewer: Nikita Amelchev (was: Alex Plehanov)
> 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: 5h 5m
> 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] [Updated] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17541:
Reviewer: (was: Nikita Amelchev)
> 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: 5h 5m
> 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-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602960#comment-17602960
]
Julia Bakulina commented on IGNITE-17541:
-
[~NSAmelchev], could you please review the changes?
They are almost fully checked by the previous reviewer.
Green visa https://mtcga.gridgain.com/prs.html
> 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: 5h 5m
> 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-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17614099#comment-17614099
]
Julia Bakulina commented on IGNITE-8801:
[~SomeFire] Hello Dmitrii, don't you mind if I take this ticket? I would like
to solve this issue
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Labels: ise
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617751#comment-17617751
]
Julia Bakulina commented on IGNITE-8801:
[~timoninmaxim], hi, please review the changes
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17383:
---
Assignee: Julia Bakulina
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
>
[jira] [Updated] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17541:
Reviewer: Alex Plehanov (was: Ivan Daschinsky)
> 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-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17600241#comment-17600241
]
Julia Bakulina commented on IGNITE-17541:
-
[~alexpl], could you please review my changes?
> 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] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Fix Version/s: 2.15
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627669#comment-17627669
]
Julia Bakulina edited comment on IGNITE-8801 at 11/2/22 12:15 PM:
--
As from devlist as of 28/10/2022
https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
was (Author: JIRAUSER294860):
As from devlist as of 28/10/2022:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Flags: Important
Ignite Flags: Release Notes Required
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627669#comment-17627669
]
Julia Bakulina commented on IGNITE-8801:
As from devlist as of 28/10/2022:
1. Revert deprecation IGNITE-17916 - reverted
2. Change default value in 2.15.
3. Notify users in release notes, an exception message - how to change the
behavior back.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> \{{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17321) Document which api can work with partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17321: Labels: documentation ise (was: docuentation ise) > Document which api can work with partition awareness > > > Key: IGNITE-17321 > URL: https://issues.apache.org/jira/browse/IGNITE-17321 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Luchnikov Alexander >Assignee: Julia Bakulina >Priority: Minor > Labels: documentation, ise > Time Spent: 40m > Remaining Estimate: 0h > > In javadoc > org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled > and in the description of functionality > https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness, > it is not described with which api this functionality will work and in what > cases. For example, will it work with getAll, in a transaction? > Describe in the documentation and in the javadoc in which cases it works and > with which api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17321) Document which api can work with partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17321: Reviewer: Maksim Timonin > Document which api can work with partition awareness > > > Key: IGNITE-17321 > URL: https://issues.apache.org/jira/browse/IGNITE-17321 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Luchnikov Alexander >Assignee: Julia Bakulina >Priority: Minor > Labels: documentation, ise > Time Spent: 50m > Remaining Estimate: 0h > > In javadoc > org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled > and in the description of functionality > https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness, > it is not described with which api this functionality will work and in what > cases. For example, will it work with getAll, in a transaction? > Describe in the documentation and in the javadoc in which cases it works and > with which api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17321) Document which api can work with partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17321: Reviewer: Maksim Timonin (was: Maksim Timonin) > Document which api can work with partition awareness > > > Key: IGNITE-17321 > URL: https://issues.apache.org/jira/browse/IGNITE-17321 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Luchnikov Alexander >Assignee: Julia Bakulina >Priority: Minor > Labels: documentation, ise > Time Spent: 50m > Remaining Estimate: 0h > > In javadoc > org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled > and in the description of functionality > https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness, > it is not described with which api this functionality will work and in what > cases. For example, will it work with getAll, in a transaction? > Describe in the documentation and in the javadoc in which cases it works and > with which api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647064#comment-17647064 ] Julia Bakulina edited comment on IGNITE-18348 at 12/20/22 1:15 PM: --- Ignite.active() is massively used while being deprecated since 2018 was (Author: JIRAUSER294860): during IGNITE-17373 it became obvious that Ignite.active() is massively used while being deprecated since 2018 > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652207#comment-17652207 ] Julia Bakulina commented on IGNITE-18348: - [~NSAmelchev], thank you for the review! > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
Julia Bakulina created IGNITE-18354: --- Summary: Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE) Key: IGNITE-18354 URL: https://issues.apache.org/jira/browse/IGNITE-18354 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Currently, some classes contain outdated ignite apache docs info re Ignite.active() and Ignite.active(boolean active). active() and active(boolean active) are deprecated since 2018 thus the docs throughout the project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-17945: --- Assignee: Julia Bakulina > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > > In Long JVM pause detector we warn user that the thread wasn't alive for a > treshold > Possible too long JVM pause: 500+ milliseconds. > But it is often threated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > to enlist possible reasons behind that behaivour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Fix Version/s: 2.15 > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: External issue URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: External issue URL: (was: https://issues.apache.org/jira/browse/IGNITE-18354) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17321) Document which api can work with partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-17321: --- Assignee: Julia Bakulina (was: Luchnikov Alexander) > Document which api can work with partition awareness > > > Key: IGNITE-17321 > URL: https://issues.apache.org/jira/browse/IGNITE-17321 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Luchnikov Alexander >Assignee: Julia Bakulina >Priority: Minor > Labels: docuentation, ise > Time Spent: 40m > Remaining Estimate: 0h > > In javadoc > org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled > and in the description of functionality > https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness, > it is not described with which api this functionality will work and in what > cases. For example, will it work with getAll, in a transaction? > Describe in the documentation and in the javadoc in which cases it works and > with which api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Reviewer: Nikita Amelchev > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Release Note: Replaced deprecated Ignite.active() by Ignite.cluster().state().active(), Ignite.active(boolean active) by Ignite.cluster().state(ClusterState.ACTIVE or ClusterState.INACTIVE) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Reviewer: Maksim Timonin > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
[ https://issues.apache.org/jira/browse/IGNITE-18354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina resolved IGNITE-18354. - Resolution: Duplicate > Update apache ignite docs to replace deprecated info from Ignite.active() to > Ignite.cluster().state(ClusterState.ACTIVE) > > > Key: IGNITE-18354 > URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > > Currently, some classes contain outdated ignite apache docs info re > Ignite.active() and Ignite.active(boolean active). active() and > active(boolean active) are deprecated since 2018 thus the docs throughout the > project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise newbie (was: ise) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
Julia Bakulina created IGNITE-18348: --- Summary: Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state() Key: IGNITE-18348 URL: https://issues.apache.org/jira/browse/IGNITE-18348 Project: Ignite Issue Type: Improvement Reporter: Julia Bakulina Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. As per the ignite docs: Ignite.active() -> it is recommended to use IgniteCluster.active() instead; Ignite.active(boolean active) -> it is recommended to use IgniteCluster.active(boolean active) instead. It seems that it is time to update these deprecated methods, update the corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise (was: ) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise newbie (was: ise) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-18348: Labels: ise (was: ise newbie) > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Trivial > Labels: ise > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-18348: --- Assignee: Julia Bakulina > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18348) Change deprecated Ignite.active() to IgniteCluster.active() while Ignite.active(boolean active) to Ignite.cluster().state()
[ https://issues.apache.org/jira/browse/IGNITE-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647064#comment-17647064 ] Julia Bakulina commented on IGNITE-18348: - during IGNITE-17373 it became obvious that Ignite.active() is massively used while being deprecated since 2018 > Change deprecated Ignite.active() to IgniteCluster.active() while > Ignite.active(boolean active) to Ignite.cluster().state() > --- > > Key: IGNITE-18348 > URL: https://issues.apache.org/jira/browse/IGNITE-18348 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Trivial > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Ignite.active() and Ignite.active(boolean active) are deprecated since 2018. > As per the ignite docs: > Ignite.active() -> it is recommended to use IgniteCluster.active() instead; > Ignite.active(boolean active) -> it is recommended to use > IgniteCluster.active(boolean active) instead. > It seems that it is time to update these deprecated methods, update the > corresponding ignite docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647071#comment-17647071 ] Julia Bakulina commented on IGNITE-17945: - [~amashenkov] Hi Andrey, bulk loading is stated in ignite apache docs as one of the reasons for JVM pauses "Occasionally you may see a warning message about the JVM being paused for too long. It can happen during bulk loading, for example". [https://ignite.apache.org/docs/latest/perf-and-troubleshooting/troubleshooting] > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Release Note: Fixed an exception message for Possible too long JVM pause. Now the exception thrown includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses. > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17647034#comment-17647034 ] Julia Bakulina commented on IGNITE-17945: - [~timonin.maksim] thank you for the review! > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Release Note: Fixed an exception message for "Possible too long JVM pause". Now the exception thrown is extended and includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses. (was: Fixed an exception message for Possible too long JVM pause. Now the exception thrown includes possible reasons: GC pause, hardware temporary freeze, bulk loading, other JVM pauses.) > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
[ https://issues.apache.org/jira/browse/IGNITE-18354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-18354: --- Assignee: Julia Bakulina > Update apache ignite docs to replace deprecated info from Ignite.active() to > Ignite.cluster().state(ClusterState.ACTIVE) > > > Key: IGNITE-18354 > URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > > Currently, some classes contain outdated ignite apache docs info re > Ignite.active() and Ignite.active(boolean active). active() and > active(boolean active) are deprecated since 2018 thus the docs throughout the > project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17945: Description: In Long JVM pause detector we warn user that the thread wasn't alive for a threshold Possible too long JVM pause: 500+ milliseconds. But it is often treated as a GC pause. We can change that warning to Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware temporary freeze) To enlist possible reasons behind that behaviour was: In Long JVM pause detector we warn user that the thread wasn't alive for a treshold Possible too long JVM pause: 500+ milliseconds. But it is often threated as a GC pause. We can change that warning to Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware temporary freeze) to enlist possible reasons behind that behaivour > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646522#comment-17646522 ] Julia Bakulina commented on IGNITE-17945: - @timoninmaxim Hi Maxim, could you please review this ticket? > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641738#comment-17641738
]
Julia Bakulina commented on IGNITE-8801:
[~timonin.maksim] thank you for the review
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-17916: Description: The ticket is a part of IGNITE-8801. As decided during the discussion in [Ignite Dev List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of 18/10/2022, we need to *break changes* of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - IGNITE-17916; 2) delete this property in the release after the next one - IGNITE-8801. As per the latest round of discussions on [Ignite Dev List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of 28/10/2022 we agreed on the following: # Revert deprecation. # Change default value in 2.15. # Notify users in release notes, an exception message - how to change the behaviour back. Thus, the commit of IGNITE-17916 is reverted. was: The ticket is a part of [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1]. As decided during the discussion in Ignite Dev List, we need to *break changes* of IGNITE-8801 into 2 steps: 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next release - IGNITE-17916; 2) delete this property in the release after the next one - IGNITE-8801. > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: important, ise > Time Spent: 1.5h > Remaining Estimate: 0h > > The ticket is a part of IGNITE-8801. > As decided during the discussion in [Ignite Dev > List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of > 18/10/2022, we need to *break changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. > As per the latest round of discussions on [Ignite Dev > List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of > 28/10/2022 we agreed on the following: > # Revert deprecation. > # Change default value in 2.15. > # Notify users in release notes, an exception message - how to change the > behaviour back. > Thus, the commit of IGNITE-17916 is reverted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Description:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in {{CacheOperationContext}}
constructor without arguments and arguments for calls of another constructor.
3) Fix javadocs.
As decided during Ignite Dev List discussion as of 18/10/2022, we need to break
changes of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.
As per the latest round of discussion on Ignite Dev List as of 28/10/2022:
was:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in
\{{CacheOperationContext}} constructor without arguments and arguments for
calls of another constructor.
3) Fix javadocs.
As decided during the discussion in Ignite Dev List, we need to break changes
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As decided during Ignite Dev List discussion as of 18/10/2022, we need to
> break changes of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Release Note: IGNITE_ALLOW_ATOMIC_OPS_IN_TX turned false by default
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Description:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in {{CacheOperationContext}}
constructor without arguments and arguments for calls of another constructor.
3) Fix javadocs.
As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
agreed on the following:
1) Revert deprecation IGNITE-17916 - reverted
2) Change default value in 2.15.
3) Notify users in release notes, an exception message - how to change the
behavior back.
was:
Need to change default behaviour of atomic operations to fail inside
transactions.
1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in {{CacheOperationContext}}
constructor without arguments and arguments for calls of another constructor.
3) Fix javadocs.
As decided during Ignite Dev List discussion as of 18/10/2022, we need to break
changes of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.
As per the latest round of discussion on Ignite Dev List as of 28/10/2022:
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
[ https://issues.apache.org/jira/browse/IGNITE-17916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-17916: --- Assignee: (was: Julia Bakulina) > Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property > --- > > Key: IGNITE-17916 > URL: https://issues.apache.org/jira/browse/IGNITE-17916 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Priority: Minor > Labels: important, ise > Time Spent: 1.5h > Remaining Estimate: 0h > > The ticket is a part of IGNITE-8801. > As decided during the discussion in [Ignite Dev > List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of > 18/10/2022, we need to *break changes* of IGNITE-8801 into 2 steps: > 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next > release - IGNITE-17916; > 2) delete this property in the release after the next one - IGNITE-8801. > As per the latest round of discussions on [Ignite Dev > List|https://lists.apache.org/thread/3wxpx2tw9xnn74139nkqopdom5mh6q74] as of > 28/10/2022 we agreed on the following: > # Revert deprecation. > # Change default value in 2.15. > # Notify users in release notes, an exception message - how to change the > behaviour back. > Thus, the commit of IGNITE-17916 is reverted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17383:
Reviewer: Maksim Timonin
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
>
[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions
[
https://issues.apache.org/jira/browse/IGNITE-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-8801:
---
Release Note:
IGNITE_ALLOW_ATOMIC_OPS_IN_TX turned false by default. To return the previous
behaviour and to allow transactions in operations with atomic caches set
IGNITE_ALLOW_ATOMIC_OPS_IN_TX to true in IgniteSystemProperties
was:IGNITE_ALLOW_ATOMIC_OPS_IN_TX turned false by default
> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in
> {{CacheOperationContext}} constructor without arguments and arguments for
> calls of another constructor.
> 3) Fix javadocs.
> As per the latest round of discussion on Ignite Dev List as of 28/10/2022 we
> agreed on the following:
> 1) Revert deprecation IGNITE-17916 - reverted
> 2) Change default value in 2.15.
> 3) Notify users in release notes, an exception message - how to change the
> behavior back.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17945) Change message in case watchdog thread observes freeze
[ https://issues.apache.org/jira/browse/IGNITE-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina reassigned IGNITE-17945: --- Assignee: (was: Julia Bakulina) > Change message in case watchdog thread observes freeze > -- > > Key: IGNITE-17945 > URL: https://issues.apache.org/jira/browse/IGNITE-17945 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Priority: Minor > Labels: ise, newbie > Fix For: 2.15 > > Time Spent: 1h > Remaining Estimate: 0h > > In Long JVM pause detector we warn user that the thread wasn't alive for a > threshold > Possible too long JVM pause: 500+ milliseconds. > But it is often treated as a GC pause. > We can change that warning to > Possible too long JVM pause: 500+ milliseconds. (GC pause or hardware > temporary freeze) > To enlist possible reasons behind that behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17321) Document which api can work with partition awareness
[ https://issues.apache.org/jira/browse/IGNITE-17321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17698813#comment-17698813 ] Julia Bakulina commented on IGNITE-17321: - [~timonin.maksim] thank you for review! > Document which api can work with partition awareness > > > Key: IGNITE-17321 > URL: https://issues.apache.org/jira/browse/IGNITE-17321 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Luchnikov Alexander >Assignee: Julia Bakulina >Priority: Minor > Labels: documentation, ise > Fix For: 2.15 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > In javadoc > org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled > and in the description of functionality > https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness, > it is not described with which api this functionality will work and in what > cases. For example, will it work with getAll, in a transaction? > Describe in the documentation and in the javadoc in which cases it works and > with which api. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-18354) Update apache ignite docs to replace deprecated info from Ignite.active() to Ignite.cluster().state(ClusterState.ACTIVE)
[ https://issues.apache.org/jira/browse/IGNITE-18354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina closed IGNITE-18354. --- Ignite Flags: (was: Docs Required,Release Notes Required) it is a duplicate > Update apache ignite docs to replace deprecated info from Ignite.active() to > Ignite.cluster().state(ClusterState.ACTIVE) > > > Key: IGNITE-18354 > URL: https://issues.apache.org/jira/browse/IGNITE-18354 > Project: Ignite > Issue Type: Improvement >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise, newbie > > Currently, some classes contain outdated ignite apache docs info re > Ignite.active() and Ignite.active(boolean active). active() and > active(boolean active) are deprecated since 2018 thus the docs throughout the > project should be updated accordingly -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17713064#comment-17713064
]
Julia Bakulina commented on IGNITE-17383:
-
There needs to be 2 checks on the cluster state and persistent data region.
What is still to be done:
* 1st check - add the condition on an inactive cluster in
IdleVerify.execute(), i.e. before executeTaskByNameOnNode() - in order to fail
fast;
* 2nd check is already done;
* if smb changes the cluster state after the 1st check then do the same as
with other errors, i.e. return code OK and write the error into idle_verify.txt
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
>
[jira] [Assigned] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence
[
https://issues.apache.org/jira/browse/IGNITE-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17383:
---
Assignee: (was: Julia Bakulina)
> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 6.5h
> Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with
> persistence, control script hangs and no actions are performed. As you can
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
> at
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
> at
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
> at
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
> at
>
[jira] [Assigned] (IGNITE-17157) Documentation of the Ignite index reader
[
https://issues.apache.org/jira/browse/IGNITE-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-17157:
---
Assignee: Julia Bakulina
> Documentation of the Ignite index reader
>
>
> Key: IGNITE-17157
> URL: https://issues.apache.org/jira/browse/IGNITE-17157
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Assignee: Julia Bakulina
>Priority: Major
> Labels: documentation, ise
>
> It would be nice to have a documentation for the Ignite index reader utility
> that was added in IGNITE-14529.
> {panel:title=Draft}
> // Here should also be an overview with the description of the purposes of
> the utility
> To run this utility, use index-reader.sh/index-reader.bat script from Ignite
> *bin* directory.
> *Command line parameters:*
> *--dir*: partition directory, where index.bin and (optionally) partition
> files are located.
> *--part-cnt*: full partitions count in cache group. Default value: 0
> *--page-size*: page size. Default value: 4096
> *--page-store-ver*: page store version. Default value: 2
> *--indexes*: you can specify index tree names that will be processed,
> separated by comma without spaces, other index trees will be skipped. Default
> value: null. Index tree names are not the same as index names, they have
> format _cacheId_typeId_indexName##H2Tree%segmentNumber_, e.g.
> {{2652_885397586_T0_F0_F1_IDX##H2Tree%0}}. You can see them in utility
> output, in traversal information sections (RECURSIVE and HORIZONTAL).
> *--dest-file*: file to print the report to (by default report is printed to
> console). Default value: null
> *--check-parts*: check cache data tree in partition files and it's
> consistency with indexes. Default value: false
> The utility can analyze index.bin and optionally partitions, if *--part-cnt*
> greater that 0 and partition files are present, to read CacheDataTree and to
> look into data pages to check their availability. It reads all index trees
> from index.bin and traverses them in two ways:
> - recursive traversal from root to leaves
> - traversal by each level, as all pages on one level are connected through
> forward ids.
> Also it reads page reuse lists. After all, it scans all pages in file, trying
> to detect orphan pages (those which don’t have any references from index
> trees and reuse lists).
> So, the output of the IgniteIndexReader consists of 4 main sections:
> - recursive traversal info (with prefix )
> - horizontal traversal info (with prefix )
> - page reuse lists info (with prefix )
> - sequential scan of all pages.
> Optionally, with *--check-parts* parameter, it can have information about how
> CacheDataTree matches SQL indexes. If there are no errors, then there is only
> message like this:
> {noformat}
> Partitions check detected no errors.
> Partition check finished, total errors: 0, total problem partitions: 0
> {noformat}
> Otherwise, there is “Partitions check:“ section with list of errors. For
> example, this is how looks message about the entry that was found in
> CacheDataTree, but was not found in SQL indexes:
> {noformat}
> Errors detected in partition, partId=1023
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F0_F1_IDX##H2Tree%0, pageId=0002000d],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F2_IDX##H2Tree%0, pageId=0002000b],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> All errors in the output have prefix .
> {noformat}
> h3. Command line examples
> Analyze files from /gridgain/corrupted_idxs, there should be also 1024
> partitions in this cache group (some of partition files can be missing if
> node where they have been received from was not owning these partitions), use
> pageSize=4096 and page store version 2, report goes to report.txt:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --page-size 4096 --page-store-ver 2 --dest-file "report.txt"
> {noformat}
> Read only SQL indexes:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --dest-file "report.txt"
> {noformat}
> Read SQL indexes and check cache data tree in partitions:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --check-parts --dest-file "rep
> {noformat}
> h3. Output samples
> and output sections contain information about index
> trees: tree name, root page id, page type statistics, count of items. The
> format for both traversals is the same.
> {noformat}
> Index tree: I [idxName=2654_-1177891018__key_PK##H2Tree%0,
> pageId=02020066]
> -- Page stat:
> H2ExtrasLeafIO: 2
> H2ExtrasInnerIO: 1
> BPlusMetaIO: 1
> -- Count of items found in
[jira] [Updated] (IGNITE-17157) Documentation of the Ignite index reader
[
https://issues.apache.org/jira/browse/IGNITE-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina updated IGNITE-17157:
Labels: documentation ise (was: documentation)
> Documentation of the Ignite index reader
>
>
> Key: IGNITE-17157
> URL: https://issues.apache.org/jira/browse/IGNITE-17157
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Chudov
>Priority: Major
> Labels: documentation, ise
>
> It would be nice to have a documentation for the Ignite index reader utility
> that was added in IGNITE-14529.
> {panel:title=Draft}
> // Here should also be an overview with the description of the purposes of
> the utility
> To run this utility, use index-reader.sh/index-reader.bat script from Ignite
> *bin* directory.
> *Command line parameters:*
> *--dir*: partition directory, where index.bin and (optionally) partition
> files are located.
> *--part-cnt*: full partitions count in cache group. Default value: 0
> *--page-size*: page size. Default value: 4096
> *--page-store-ver*: page store version. Default value: 2
> *--indexes*: you can specify index tree names that will be processed,
> separated by comma without spaces, other index trees will be skipped. Default
> value: null. Index tree names are not the same as index names, they have
> format _cacheId_typeId_indexName##H2Tree%segmentNumber_, e.g.
> {{2652_885397586_T0_F0_F1_IDX##H2Tree%0}}. You can see them in utility
> output, in traversal information sections (RECURSIVE and HORIZONTAL).
> *--dest-file*: file to print the report to (by default report is printed to
> console). Default value: null
> *--check-parts*: check cache data tree in partition files and it's
> consistency with indexes. Default value: false
> The utility can analyze index.bin and optionally partitions, if *--part-cnt*
> greater that 0 and partition files are present, to read CacheDataTree and to
> look into data pages to check their availability. It reads all index trees
> from index.bin and traverses them in two ways:
> - recursive traversal from root to leaves
> - traversal by each level, as all pages on one level are connected through
> forward ids.
> Also it reads page reuse lists. After all, it scans all pages in file, trying
> to detect orphan pages (those which don’t have any references from index
> trees and reuse lists).
> So, the output of the IgniteIndexReader consists of 4 main sections:
> - recursive traversal info (with prefix )
> - horizontal traversal info (with prefix )
> - page reuse lists info (with prefix )
> - sequential scan of all pages.
> Optionally, with *--check-parts* parameter, it can have information about how
> CacheDataTree matches SQL indexes. If there are no errors, then there is only
> message like this:
> {noformat}
> Partitions check detected no errors.
> Partition check finished, total errors: 0, total problem partitions: 0
> {noformat}
> Otherwise, there is “Partitions check:“ section with list of errors. For
> example, this is how looks message about the entry that was found in
> CacheDataTree, but was not found in SQL indexes:
> {noformat}
> Errors detected in partition, partId=1023
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F0_F1_IDX##H2Tree%0, pageId=0002000d],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> Entry is missing in index: I
> [idxName=2652_885397586_T0_F2_IDX##H2Tree%0, pageId=0002000b],
> cacheId=2652, partId=1023, pageIndex=8, itemId=0, link=285868728254472
> All errors in the output have prefix .
> {noformat}
> h3. Command line examples
> Analyze files from /gridgain/corrupted_idxs, there should be also 1024
> partitions in this cache group (some of partition files can be missing if
> node where they have been received from was not owning these partitions), use
> pageSize=4096 and page store version 2, report goes to report.txt:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --page-size 4096 --page-store-ver 2 --dest-file "report.txt"
> {noformat}
> Read only SQL indexes:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --dest-file "report.txt"
> {noformat}
> Read SQL indexes and check cache data tree in partitions:
> {noformat}
> ./index-reader.sh --dir "/gridgain/corrupted_idxs" --part-cnt 1024
> --check-parts --dest-file "rep
> {noformat}
> h3. Output samples
> and output sections contain information about index
> trees: tree name, root page id, page type statistics, count of items. The
> format for both traversals is the same.
> {noformat}
> Index tree: I [idxName=2654_-1177891018__key_PK##H2Tree%0,
> pageId=02020066]
> -- Page stat:
> H2ExtrasLeafIO: 2
> H2ExtrasInnerIO: 1
> BPlusMetaIO: 1
> -- Count of items found in leaf pages: 200
> No
[jira] [Assigned] (IGNITE-19160) Improve message about sent partition file during snapshot restore
[
https://issues.apache.org/jira/browse/IGNITE-19160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-19160:
---
Assignee: Julia Bakulina
> Improve message about sent partition file during snapshot restore
> -
>
> Key: IGNITE-19160
> URL: https://issues.apache.org/jira/browse/IGNITE-19160
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: iep-43, ise
>
> Currently, message about partition is as below:
> {quote}
> [2023-03-29T18:31:44,773][INFO ][snapshot-runner-#863%node0%][SnapshotSender]
> Partition file has been send [part=part-645.bin,
> pair={color:red}GroupPartitionId [grpId=1544803905, partId=645]{color},
> length=45056]
> {quote}
> It does not tell us:
> # Receiver node id / address / consistent id.
> # Cache or cache group name which partition belongs to. Numerical group id is
> not convenient way to determine cache or cache group.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-19158) Improve message about received partition file during snapshot restore
[
https://issues.apache.org/jira/browse/IGNITE-19158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julia Bakulina reassigned IGNITE-19158:
---
Assignee: Julia Bakulina
> Improve message about received partition file during snapshot restore
> -
>
> Key: IGNITE-19158
> URL: https://issues.apache.org/jira/browse/IGNITE-19158
> Project: Ignite
> Issue Type: Task
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: iep-43, ise
>
> Currently, GridIoManager prints only name of a file and node id:
> {quote}
> [2023-03-24T18:07:00,747][INFO ]pub-#871%node1%[GridIoManager] File has been
> received [name={color:red}part-233.bin{color}, transferred=53248, time=0.0
> sec, {color:red}rmtId=76e22ef5-3c76-4987-bebd-9a6222a0{color}]
> {quote}
> This meager information does not allow to determine in a simple way which
> file is received and from which node.
> For example, such message would be more informative:
> {quote}
> [2023-03-29T17:09:42,230][INFO ][pub-#869%node0%][GridIoManager] File has
> been received
> [{color:red}path=/ignite/db/node0/_tmp_snp_restore_cache-default/part-647.bin{color},
> transferred=45056, time=0.0 sec, rmtId=de43d2e8-a1ab-4d7c-9cea-72615371,
> {color:red}rmdAddr=/127.0.0.1:51773{color}]
> {quote}
> _Other ways might be investigated_ in order to improve logging of receiving
> partition files during snapshot restore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
