[jira] [Created] (IGNITE-18106) prepareMarshal()/unmarshal() are not relayed for Collection subtypes
Roman Puchkovskiy created IGNITE-18106:
--
Summary: prepareMarshal()/unmarshal() are not relayed for
Collection subtypes
Key: IGNITE-18106
URL: https://issues.apache.org/jira/browse/IGNITE-18106
Project: Ignite
Issue Type: Bug
Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
Fix For: 3.0.0-beta2
{{@Marshallable}} fields cause prepareMarshal()/unmarshal() methods to be
generated; also, these methods need to be called for each message containing a
marshallable field. This means that any container that contains messages must
relay calls to them (that is, it must contain a snippet in its
prepareMarshal()/unmarshal() to iterate its elements and call the corresponding
method on them). This is currently implemented for single message fields, for
arrays and {{{}Collection{}}}, but not for subtypes of {{Collection}} (like
lists).
We should either support subtypes of {{Collection}} fully (and relay the
methods calls), or not support them at all (and fail compilation if someone
defines such a structure).
The first (support) seems preferrable, it's easy to implement and does not
seem to pose any dangers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17588: Fix Version/s: 3.0.0-beta2 (was: 3.0.0-beta1) > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17588) C++ 3.0: Implement SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17630245#comment-17630245 ] Stanislav Lukyanov commented on IGNITE-17588: - Looks like this one wasn't on time for beta1. That's OK, we'll get it done in the next version. Changed the fixVersion. > C++ 3.0: Implement SQL API > -- > > Key: IGNITE-17588 > URL: https://issues.apache.org/jira/browse/IGNITE-17588 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > > We need to implement SQL API for C++ client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17989) JVM memory usage metric source
[ https://issues.apache.org/jira/browse/IGNITE-17989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17989: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > JVM memory usage metric source > -- > > Key: IGNITE-17989 > URL: https://issues.apache.org/jira/browse/IGNITE-17989 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation > It will be useful to have builtin metric source with jvm memory usage stats. > h3. Definition of Done > It must expose the following metrics as a separate gauge metric each: > * heap memory usage (init/used/commited/max) > * non-heap memory usage (init/used/commited/max) > * name of metrics should have the general prefix "jvm." to group all future > jvm metrics together > Also, it needs to check, if calculation of these stats is heavy and we need > to cache it for some time windows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17357) JMX metric exporter for Ignite 3
[ https://issues.apache.org/jira/browse/IGNITE-17357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-17357: Fix Version/s: 3.0.0-beta1 (was: 3.0.0-beta2) > JMX metric exporter for Ignite 3 > > > Key: IGNITE-17357 > URL: https://issues.apache.org/jira/browse/IGNITE-17357 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta1 > > Time Spent: 50m > Remaining Estimate: 0h > > Metrics should be able to be exported via JMX as a first stage of metrics > exposing. > Exporter implementation must provide the following behavior: > * for each MetricSource we need to provide separate MBean with attribute per > metric > * each MBean attribute must have the same name as corresponding metric > * on enable/disable event for MetricSource corresponding MBean must be > registered/unregistered -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18105) Remove ivy dependency
Vadim Pakhnushev created IGNITE-18105: - Summary: Remove ivy dependency Key: IGNITE-18105 URL: https://issues.apache.org/jira/browse/IGNITE-18105 Project: Ignite Issue Type: Task Components: cli Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev After removing bootstrap command in IGNITE-17773, ivy library is not needed anymore -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-18062:
-
Fix Version/s: 2.15
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ducktests
> Fix For: 2.15
>
> Attachments: logs.tgz
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629840#comment-17629840
]
Nikolay Izhikov commented on IGNITE-18062:
--
Failures unrelated.
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ducktests
> Attachments: logs.tgz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629839#comment-17629839
]
Ignite TC Bot commented on IGNITE-18062:
{panel:title=Branch: [pull/10365/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6899045]]
{color:#d04437}PDS (Indexing){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6899040]]
* IgnitePdsWithIndexingCoreTestSuite:
IgniteWalRecoveryTest.testBinaryRecoverBeforePMEWhenMiddleCheckpoint - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache (Failover) 2{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6898989]]
* IgniteCacheFailoverTestSuite2:
GridCacheAtomicFailoverSelfTest.testTopologyChange - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Queries 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6899047]]
* IgniteBinaryCacheQueryTestSuite:
H2DynamicTableSelfTest.testTableEnabledDynamicallyNotExistsIfCacheDestroyed -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10365/head] Base: [master] : New Tests
(46)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin client: Python{color} [[tests
46|https://ci2.ignite.apache.org/viewLog.html?buildId=6899071]]
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(put-targs1)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(get-targs0)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(clear-targs5)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(replace-targs4)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(put_all-targs3)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(get_all-targs2)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(contains_keys-targs9)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(contains_key-targs8)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(clear_keys-targs7)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(clear_key-targs6)
- PASSED{color}
*
{color:#013220}tests.custom.test_timeouts.test_cancellation_on_slow_response(get_and_remove-targs13)
- PASSED{color}
... and 35 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6899078buildTypeId=IgniteTests24Java8_RunAll]
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ducktests
> Attachments: logs.tgz
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17998) ItSqlAsynchronousApiTest#closeSession is unstable.
[
https://issues.apache.org/jira/browse/IGNITE-17998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-17998:
-
Assignee: Pavel Pereslegin
> ItSqlAsynchronousApiTest#closeSession is unstable.
> --
>
> Key: IGNITE-17998
> URL: https://issues.apache.org/jira/browse/IGNITE-17998
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Evgeny Stanilovsky
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> ItSqlAsynchronousApiTest#closeSession is unstable.
> {noformat}
> org.opentest4j.AssertionFailedError: Exception is neither of a specified
> class, nor has a cause of the specified class: class
> org.apache.ignite.sql.SqlException
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:43)
> at org.junit.jupiter.api.Assertions.fail(Assertions.java:146)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:284)
> at
> org.apache.ignite.internal.testframework.IgniteTestUtils.assertThrowsWithCause(IgniteTestUtils.java:264)
> at
> org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession(ItSqlAsynchronousApiTest.java:541)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18104) Pull apdates of physical cluster topology using websockets
Ivan Gagarkin created IGNITE-18104: -- Summary: Pull apdates of physical cluster topology using websockets Key: IGNITE-18104 URL: https://issues.apache.org/jira/browse/IGNITE-18104 Project: Ignite Issue Type: Improvement Components: cli Affects Versions: None Reporter: Ivan Gagarkin Currently, CLI pulls updates of the physical cluster topology using a scheduled thread. It would be better to replace that with websockets. See NodeNameRegisrty. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18103) Move building python artifacts to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18103: - Ignite Flags: (was: Docs Required,Release Notes Required) > Move building python artifacts to github actions > > > Key: IGNITE-18103 > URL: https://issues.apache.org/jira/browse/IGNITE-18103 > Project: Ignite > Issue Type: Task > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18103) Move building python artifacts to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18103: - Fix Version/s: python-0.6.0 > Move building python artifacts to github actions > > > Key: IGNITE-18103 > URL: https://issues.apache.org/jira/browse/IGNITE-18103 > Project: Ignite > Issue Type: Task > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18103) Move building python artifacts to github actions
[ https://issues.apache.org/jira/browse/IGNITE-18103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629813#comment-17629813 ] Igor Sapego commented on IGNITE-18103: -- [~ivandasch] looks good to me. > Move building python artifacts to github actions > > > Key: IGNITE-18103 > URL: https://issues.apache.org/jira/browse/IGNITE-18103 > Project: Ignite > Issue Type: Task > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18103) Move building python artifacts to github actions
Ivan Daschinsky created IGNITE-18103: Summary: Move building python artifacts to github actions Key: IGNITE-18103 URL: https://issues.apache.org/jira/browse/IGNITE-18103 Project: Ignite Issue Type: Task Components: python, thin client Reporter: Ivan Daschinsky Assignee: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME
[
https://issues.apache.org/jira/browse/IGNITE-17865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629787#comment-17629787
]
Anton Vinogradov commented on IGNITE-17865:
---
[~slava.koptilin]
{quote}
I would look for it the same way as the previous four years, as long as this
optimization exists. For example, it does not seem to be so hard to find out
the 433 partition in the file that Ilya Shishkov mentioned
{quote}
Not sure I've got an idea.
Could you please explain the search plan step-by-step?
> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Attachments: replicated.txt
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you need to analyze cases of partitions inconsistency, full list of
> partitions is needed, but there is an optimization which replaces list of
> consecutive partitions with ranges. So, as you can see below, we can not find
> partition 2 by simple text search:
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
> Partitions have been scheduled for rebalancing due to outdated update
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33,
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0],
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5,
> partsFull=[{color:#ff}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}2021-08-11 23:12:11.338 [WARN
> ][sys-#213|#213][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
> Partitions weren't present in any history reservation: [[[grp=grp2
> part=[[{color:#ff}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs
> analysis.
> Partition ranges are formed in _GridToStringBuilder#compact_ method, which is
> used to log of partition lists (except one place with exception and tests).
> Below are such places (without usages in tests):
> # {_}GridClientPartitionTopology#resetOwners{_}:
> [L1311|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1311],
>
> [L1312|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridClientPartitionTopology.java#L1312]
> (WARN)
> # {_}GridDhtPartitionDemander#handleSupplyMessage{_}:
> [L561|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L561]
> (ERROR)
> # {_}GridDhtPartitionDemander.RebalanceFuture#requestPartitions0{_}:
> [L1434|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1434],
>
> [L1435|https://github.com/apache/ignite/blob/147e03177aeadee03cb4925649c03633ce6be192/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1435]
> (INFO)
> # {_}GridDhtPartitionsExchangeFuture#printPartitionRebalancingFully{_}:
> [L4282|https://github.com/apache/ignite/blob/bc843a5b40a6da0e2bfcb77857bea499ab9a4512/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java#L4282]
> (INFO)
> # {_}GridDhtPartitionSupplier#handleDemandMessage{_}:
> [L276|https://github.com/apache/ignite/blob/00988d20af19485585e98e885c610a704640c083/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionSupplier.java#L276]
> (DEBUG)
> # {_}GridDhtPartitionTopologyImpl#detectLostPartitions{_}:
> [L2281|https://github.com/apache/ignite/blob/8ec5d50896a2b5f2d008d0bb8f67f7f3d7cdf584/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/topology/GridDhtPartitionTopologyImpl.java#L2281]
> (WARN)
> # {_}GridDhtPartitionTopologyImpl#resetOwners{_}:
>
[jira] [Updated] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-17741: -- Fix Version/s: 2.15 > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629781#comment-17629781 ] Anton Vinogradov commented on IGNITE-17741: --- Merged to the master. Thanks for your contribution! > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > Time Spent: 20m > Remaining Estimate: 0h > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17846) Direct configuration request leads to synchronously waiting on network
[
https://issues.apache.org/jira/browse/IGNITE-17846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629770#comment-17629770
]
Vladislav Pyatkov commented on IGNITE-17846:
[~alapin] I tried to explain what have done clearly and changed my PR according
to latest rules.
[~Denis Chudov] Could you please review this PR?
> Direct configuration request leads to synchronously waiting on network
> --
>
> Key: IGNITE-17846
> URL: https://issues.apache.org/jira/browse/IGNITE-17846
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> .NET suite periodical hang out. Log shows the suspicious trace frizzing on a
> getting direct configuration value:
> {noformat}
> "org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2-srv-worker-3"
> #102 prio=10 os_prio=0 cpu=1958.85ms elapsed=391.19s tid=0x7fcb8c005800
> nid=0x3f7b55 waiting on condition [0x7fcce43f2000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.16.1/Native Method)
> - parking to wait for <0x00071e057c88> (a
> java.util.concurrent.CompletableFuture$Signaller)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.16.1/LockSupport.java:194)
> at
> java.util.concurrent.CompletableFuture$Signaller.block(java.base@11.0.16.1/CompletableFuture.java:1796)
> at
> java.util.concurrent.ForkJoinPool.managedBlock(java.base@11.0.16.1/ForkJoinPool.java:3128)
> at
> java.util.concurrent.CompletableFuture.waitingGet(java.base@11.0.16.1/CompletableFuture.java:1823)
> at
> java.util.concurrent.CompletableFuture.get(java.base@11.0.16.1/CompletableFuture.java:1998)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.get(ConfigurationChanger.java:627)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:328)
> at
> org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.directTableId(TableManager.java:1470)
> at
> org.apache.ignite.internal.table.distributed.TableManager.tableAsyncInternal(TableManager.java:1542)
> at
> org.apache.ignite.internal.table.distributed.TableManager.tableAsync(TableManager.java:1502)
> at
> org.apache.ignite.client.handler.requests.table.ClientTableGetRequest.process(ClientTableGetRequest.java:45)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:376)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:336)
> at
> org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:187)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
>
[jira] [Commented] (IGNITE-18006) Support timeouts in async version of python client
[ https://issues.apache.org/jira/browse/IGNITE-18006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629751#comment-17629751 ] Ivan Daschinsky commented on IGNITE-18006: -- [~isapego] Thanks for review, merged > Support timeouts in async version of python client > -- > > Key: IGNITE-18006 > URL: https://issues.apache.org/jira/browse/IGNITE-18006 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Need to support timeouts in async version of clients. > All cache operations should be supported. > Transaction start, close, commit and cursors start, fetch and close should > not be affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17976) Throw correct exception on KeyValueView#get in case of lost majority
[
https://issues.apache.org/jira/browse/IGNITE-17976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17976:
-
Description:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. We should throw TransactionException with error code, that
we don't have an actor, who can handle that request. Also we need to add a root
cause to the exception whether it was lost majority, or the reason is the
replica unavailability etc.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
was:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. We should throw TransactionException with error code, that
we don't have an actor, who can handle that request. Also we need to add root
cause to the exception whether it was lost majority, or the reason is the
replica unavailability etc.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
> Throw correct exception on KeyValueView#get in case of lost majority
>
>
> Key: IGNITE-17976
> URL: https://issues.apache.org/jira/browse/IGNITE-17976
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Scenario*:
> Start two nodes, populate data, stop node, try to
> {{table.keyValueView().get}} value.
> *Expected behaviour*:
> Exception is thrown. We should throw TransactionException with error code,
> that we don't have an actor, who can handle that request. Also we need to add
> a root cause to the exception whether it was lost majority, or the reason is
> the replica unavailability etc.
> *Actual behaviour*:
> We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
> {{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
> reason is because we can stop leader of some partition, and for two nodes it
> is impossible to elect new leader, so we get null in
> {{InternalTableImpl#enlist}} when we try to get
> {{svc.refreshAndGetLeaderWithTerm();}}
> The problem can be reproduced in the test
> {{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
> this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17976) Throw correct exception on KeyValueView#get in case of lost majority
[
https://issues.apache.org/jira/browse/IGNITE-17976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17976:
-
Description:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. We should throw TransactionException with error code, that
we don't have an actor, who can handle that request. Also we need to add root
cause to the exception whether it was lost majority, or the reason is the
replica unavailability etc.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
was:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. We should throw TransactionException with error code, that
we don't have an actor, who can handle that request.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
> Throw correct exception on KeyValueView#get in case of lost majority
>
>
> Key: IGNITE-17976
> URL: https://issues.apache.org/jira/browse/IGNITE-17976
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Scenario*:
> Start two nodes, populate data, stop node, try to
> {{table.keyValueView().get}} value.
> *Expected behaviour*:
> Exception is thrown. We should throw TransactionException with error code,
> that we don't have an actor, who can handle that request. Also we need to add
> root cause to the exception whether it was lost majority, or the reason is
> the replica unavailability etc.
> *Actual behaviour*:
> We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
> {{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
> reason is because we can stop leader of some partition, and for two nodes it
> is impossible to elect new leader, so we get null in
> {{InternalTableImpl#enlist}} when we try to get
> {{svc.refreshAndGetLeaderWithTerm();}}
> The problem can be reproduced in the test
> {{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
> this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17976) Throw correct exception on KeyValueView#get in case of lost majority
[
https://issues.apache.org/jira/browse/IGNITE-17976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17976:
-
Description:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. We should throw TransactionException with error code, that
we don't have an actor, who can handle that request.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
was:
*Scenario*:
Start two nodes, populate data, stop node, try to {{table.keyValueView().get}}
value.
*Expected behaviour*:
Exception is thrown. TransactionException with error code, that we don't have
an actor, who can handle that request.
*Actual behaviour*:
We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
{{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
reason is because we can stop leader of some partition, and for two nodes it is
impossible to elect new leader, so we get null in {{InternalTableImpl#enlist}}
when we try to get {{svc.refreshAndGetLeaderWithTerm();}}
The problem can be reproduced in the test
{{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
this ticket.
> Throw correct exception on KeyValueView#get in case of lost majority
>
>
> Key: IGNITE-17976
> URL: https://issues.apache.org/jira/browse/IGNITE-17976
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> *Scenario*:
> Start two nodes, populate data, stop node, try to
> {{table.keyValueView().get}} value.
> *Expected behaviour*:
> Exception is thrown. We should throw TransactionException with error code,
> that we don't have an actor, who can handle that request.
> *Actual behaviour*:
> We can caught {{ReplicationTimeoutException}}, {{TransactionException}},
> {{IgniteException}}. Sometimes we fail with {{NullPointerException}}, the
> reason is because we can stop leader of some partition, and for two nodes it
> is impossible to elect new leader, so we get null in
> {{InternalTableImpl#enlist}} when we try to get
> {{svc.refreshAndGetLeaderWithTerm();}}
> The problem can be reproduced in the test
> {{ItIgniteNodeRestartTest#testOneNodeRestartWithGap}}, which was muted using
> this ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18062) [ducktests] TransactionsTests.test_tx_info is broken
[
https://issues.apache.org/jira/browse/IGNITE-18062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-18062:
Assignee: Nikolay Izhikov
> [ducktests] TransactionsTests.test_tx_info is broken
>
>
> Key: IGNITE-18062
> URL: https://issues.apache.org/jira/browse/IGNITE-18062
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ducktests
> Attachments: logs.tgz
>
>
> *control_utility.tx_test.TransactionsTests.test_tx_info* test fails after
> changes in control.sh logging (IGNITE-18010)
> {noformat}
> Traceback (most recent call last):
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 133, in run
> data = self.run_test()
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/tests/runner_client.py",
> line 197, in run_test
> return self.test_context.function(self.test)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/venv/lib64/python3.8/site-packages/ducktape/mark/_mark.py",
> line 429, in wrapper
> return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/utils/_mark.py",
> line 233, in extended_test
> test_result = func(self, *args, **kwargs)
> File
> "/u01/jenkins/workspace/ise/DevOPS/Ducktape/run_tests_ai_daily/ignite-dev/modules/ducktests/tests/ignitetest/tests/control_utility/tx_test.py",
> line 62, in test_tx_info
> assert res.xid == pick_tx.xid
> AttributeError: 'NoneType' object has no attribute 'xid'
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18102) Ignite does not support create table with dot column
Chenjian created IGNITE-18102: - Summary: Ignite does not support create table with dot column Key: IGNITE-18102 URL: https://issues.apache.org/jira/browse/IGNITE-18102 Project: Ignite Issue Type: Bug Components: sql Reporter: Chenjian Attachments: image-2022-11-07-17-57-49-255.png, image-2022-11-07-18-01-49-687.png Ignite does not support create the column with dot. like create table (... , `a.dot` bigint, ...), using the !columns command only can see the suffix about the defined name `dot`. But Ignite allow add column with dot which is not compatible with self. Eg: !image-2022-11-07-17-57-49-255.png! !image-2022-11-07-18-01-49-687.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18100) help command in CLI actually runs the command instead of giving help about it
[
https://issues.apache.org/jira/browse/IGNITE-18100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Yudin updated IGNITE-18100:
Summary: help command in CLI actually runs the command instead of giving
help about it (was: help cluster status actually runs cluster status instead
of giving help)
> help command in CLI actually runs the command instead of giving help about it
> -
>
> Key: IGNITE-18100
> URL: https://issues.apache.org/jira/browse/IGNITE-18100
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Yury Yudin
>Priority: Major
> Labels: ignite-3
>
> help command actually tries to execute the actual command instead of giving
> help:
> {code:java}
> [demo1]> help cluster status
> [name: TEST, nodes: 1, status: active, cmgNodes: [demo1], msNodes: [demo1]]
> [demo1]> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18101) Add help for SQL commands
Yury Yudin created IGNITE-18101:
---
Summary: Add help for SQL commands
Key: IGNITE-18101
URL: https://issues.apache.org/jira/browse/IGNITE-18101
Project: Ignite
Issue Type: Improvement
Components: cli
Reporter: Yury Yudin
help in SQL REPL should actually give details about the syntax of SQL commands.
like:
> help create table
{color:#00}CREATE TABLE _table_name_ (
\{_}column1 datatype{_},
\{_}column2 datatype{_},
\{_}column3 datatype{_},
); {color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17132) [Native Persistence 3.0] Implement partition destruction for persistent PageMemory
[ https://issues.apache.org/jira/browse/IGNITE-17132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-17132: Assignee: Kirill Tkalenko > [Native Persistence 3.0] Implement partition destruction for persistent > PageMemory > -- > > Key: IGNITE-17132 > URL: https://issues.apache.org/jira/browse/IGNITE-17132 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, the partition destruction operation does not work quite > correctly, we just go through all the records and explicitly delete them, but > we cannot delete the partition file, because the checkpoint will then not be > able to write pages to this partition file and it will have an error. > Before implementation, you need to think about how to do it, but in any case, > deleting the partition file should definitely do a checkpoint. > See: > *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryPartitionStorage#destroy* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17132) [Native Persistence 3.0] Implement partition destruction for persistent PageMemory
[ https://issues.apache.org/jira/browse/IGNITE-17132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17132: - Fix Version/s: 3.0.0-beta2 > [Native Persistence 3.0] Implement partition destruction for persistent > PageMemory > -- > > Key: IGNITE-17132 > URL: https://issues.apache.org/jira/browse/IGNITE-17132 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, the partition destruction operation does not work quite > correctly, we just go through all the records and explicitly delete them, but > we cannot delete the partition file, because the checkpoint will then not be > able to write pages to this partition file and it will have an error. > Before implementation, you need to think about how to do it, but in any case, > deleting the partition file should definitely do a checkpoint. > See: > *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryPartitionStorage#destroy* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18100) help cluster status actually runs cluster status instead of giving help
Yury Yudin created IGNITE-18100:
---
Summary: help cluster status actually runs cluster status instead
of giving help
Key: IGNITE-18100
URL: https://issues.apache.org/jira/browse/IGNITE-18100
Project: Ignite
Issue Type: Improvement
Components: cli
Reporter: Yury Yudin
help command actually tries to execute the actual command instead of giving
help:
{code:java}
[demo1]> help cluster status
[name: TEST, nodes: 1, status: active, cmgNodes: [demo1], msNodes: [demo1]]
[demo1]> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18099) Help improvements in CLI
Yury Yudin created IGNITE-18099: --- Summary: Help improvements in CLI Key: IGNITE-18099 URL: https://issues.apache.org/jira/browse/IGNITE-18099 Project: Ignite Issue Type: Epic Components: cli Reporter: Yury Yudin Currently help command in the ignite3 CLI is very rudimental and doesn't give much information about commands or SQL syntax. This epic is a collection of items to improve that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18006) Support timeouts in async version of python client
[ https://issues.apache.org/jira/browse/IGNITE-18006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629704#comment-17629704 ] Igor Sapego commented on IGNITE-18006: -- [~ivandasch] left few comments. > Support timeouts in async version of python client > -- > > Key: IGNITE-18006 > URL: https://issues.apache.org/jira/browse/IGNITE-18006 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Need to support timeouts in async version of clients. > All cache operations should be supported. > Transaction start, close, commit and cursors start, fetch and close should > not be affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18098) ignite3 db should write logs into the logs folder.
Yury Yudin created IGNITE-18098:
---
Summary: ignite3 db should write logs into the logs folder.
Key: IGNITE-18098
URL: https://issues.apache.org/jira/browse/IGNITE-18098
Project: Ignite
Issue Type: Improvement
Components: build
Reporter: Yury Yudin
Currently ignite3db (executed from unpacked zip distro) appears to create an
empty .log file in the log directory, but most of the logs are still
written into the IGNITE_HOME/ignite3*.log files instead.
Should be written into the log directory instead.
{code:java}
demo@ymac ignite3-db-3.0.0-SNAPSHOT % l
./ README.md ignite3db-0.log.lck work/
../ bin/ lib/
LICENSE etc/ log/
NOTICE ignite3db-0.log pid
jjb@demo ignite3-db-3.0.0-SNAPSHOT % ll log
total 0
drwxr-xr-x 3 demo staff 96 7 Nov 08:51 .
drwxr-xr-x 13 demo staff 416 7 Nov 08:51 ..
-rw-r--r-- 1 demo staff 0 7 Nov 08:51 demo1.log
demo@ymac ignite3-db-3.0.0-SNAPSHOT % {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17435) Fix Datastreamer documentation.
[ https://issues.apache.org/jira/browse/IGNITE-17435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17435: - Ignite Flags: (was: Release Notes Required) > Fix Datastreamer documentation. > --- > > Key: IGNITE-17435 > URL: https://issues.apache.org/jira/browse/IGNITE-17435 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.15 > > > The doc should mention something like: > Setting the `allowOverwrite` property to false is best used for initial data > load on a cluster with stable topology. When cluster works under load, some > actions may cause issues with data consistency. To avoid them: > * Avoid having the same keys repeating in the data being streamed; > * Avoid concurrent updates of the cache that is being streamed into; > * Avoid streamer fauilure. > * Avoid snapshotting. > Also, the docs should note streamer's limitations and traits. > Additionally, we may warn into log that datastreamer should successfully > finish. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17435) Fix Datastreamer documentation.
[ https://issues.apache.org/jira/browse/IGNITE-17435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-17435: - Component/s: documentation > Fix Datastreamer documentation. > --- > > Key: IGNITE-17435 > URL: https://issues.apache.org/jira/browse/IGNITE-17435 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Labels: ise > Fix For: 2.15 > > > The doc should mention something like: > Setting the `allowOverwrite` property to false is best used for initial data > load on a cluster with stable topology. When cluster works under load, some > actions may cause issues with data consistency. To avoid them: > * Avoid having the same keys repeating in the data being streamed; > * Avoid concurrent updates of the cache that is being streamed into; > * Avoid streamer fauilure. > * Avoid snapshotting. > Also, the docs should note streamer's limitations and traits. > Additionally, we may warn into log that datastreamer should successfully > finish. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18097) CLI should check if it's already connected before trying to connect
Yury Yudin created IGNITE-18097:
---
Summary: CLI should check if it's already connected before trying
to connect
Key: IGNITE-18097
URL: https://issues.apache.org/jira/browse/IGNITE-18097
Project: Ignite
Issue Type: Improvement
Components: cli
Reporter: Yury Yudin
{code:java}
Do you want to reconnect to the last connected node http://localhost:10300?
[Y/n]
Connected to http://localhost:10300
Would you like to use http://localhost:10300 as the default URL? [Y/n]
Config saved
[demo1]> connect
Connected to http://localhost:10300
[demo1]> connect -v
--> GET http://localhost:10300/management/v1/configuration/node
<-- 200 OK http://localhost:10300/management/v1/configuration/node (2ms,
783-byte body)
--> GET http://localhost:10300/management/v1/node/state
<-- 200 OK http://localhost:10300/management/v1/node/state (1ms, 35-byte body)
Connected to http://localhost:10300
[demo1]> {code}
Currently CLI is trying to connect again even if it's already connected. It
should check and report "already connected" if the node we're trying to connect
to is the same. Otherwise it should ask the user if he's sure to connect to a
different node.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17369) Snapshot is inconsistent under streamed loading with 'allowOverwrite==false'.
[
https://issues.apache.org/jira/browse/IGNITE-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev updated IGNITE-17369:
-
Fix Version/s: 2.15
> Snapshot is inconsistent under streamed loading with 'allowOverwrite==false'.
> -
>
> Key: IGNITE-17369
> URL: https://issues.apache.org/jira/browse/IGNITE-17369
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise, ise.lts
> Fix For: 2.15
>
> Attachments: IgniteClusterShanpshotStreamerTest.java
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Ignite fails to restore snapshot created under streamed load:
> {code:java}
> Conflict partition: PartitionKeyV2 [grpId=109386747,
> grpName=SQL_PUBLIC_TEST_TBL1, partId=148]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=snapshot.IgniteClusterShanpshotStreamerTest0, updateCntr=29,
> partitionState=OWNING, size=29, partHash=827765854], PartitionHashRecordV2
> [isPrimary=false, consistentId=snapshot.IgniteClusterShanpshotStreamerTest1,
> updateCntr=9, partitionState=OWNING, size=9, partHash=-1515069105]]
> Conflict partition: PartitionKeyV2 [grpId=109386747,
> grpName=SQL_PUBLIC_TEST_TBL1, partId=146]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=snapshot.IgniteClusterShanpshotStreamerTest0, updateCntr=28,
> partitionState=OWNING, size=28, partHash=1497908810], PartitionHashRecordV2
> [isPrimary=false, consistentId=snapshot.IgniteClusterShanpshotStreamerTest1,
> updateCntr=5, partitionState=OWNING, size=5, partHash=821195757]]
> {code}
> Test (attached):
> {code:java}
> public void testClusterSnapshotConsistencyWithStreamer() throws Exception
> {
> int grids = 2;
> CountDownLatch loadNumberBeforeSnapshot = new CountDownLatch(60_000);
> AtomicBoolean stopLoading = new AtomicBoolean(false);
> dfltCacheCfg = null;
> Class.forName("org.apache.ignite.IgniteJdbcDriver");
> String tableName = "TEST_TBL1";
> startGrids(grids);
> grid(0).cluster().state(ACTIVE);
> IgniteInternalFuture load1 = runLoad(tableName, false, 1, true,
> stopLoading, loadNumberBeforeSnapshot);
> loadNumberBeforeSnapshot.await();
> grid(0).snapshot().createSnapshot(SNAPSHOT_NAME).get();
> stopLoading.set(true);
> load1.get();
> grid(0).cache("SQL_PUBLIC_" + tableName).destroy();
> grid(0).snapshot().restoreSnapshot(SNAPSHOT_NAME,
> F.asList("SQL_PUBLIC_TEST_TBL1")).get();
> }
> /** */
> private IgniteInternalFuture runLoad(String tblName, boolean useCache,
> int backups, boolean streaming, AtomicBoolean stop,
> CountDownLatch startSnp) {
> return GridTestUtils.runMultiThreadedAsync(() -> {
> if(useCache) {
> String cacheName = "SQL_PUBLIC_" + tblName.toUpperCase();
> IgniteCache cache = grid(0)
> .createCache(new CacheConfiguration Object>(cacheName).setBackups(backups)
> .setCacheMode(CacheMode.REPLICATED));
> try (IgniteDataStreamer ds =
> grid(0).dataStreamer(cacheName)) {
> for (int i = 0; !stop.get(); ++i) {
> if (streaming)
> ds.addData(i, new Account(i, i - 1));
> else
> cache.put(i, new Account(i, i - 1));
> if (startSnp.getCount() > 0)
> startSnp.countDown();
> Thread.yield();
> }
> }
> } else {
> try (Connection conn =
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")) {
> createTable(conn, tblName, backups);
> try (PreparedStatement stmt =
> conn.prepareStatement("INSERT INTO " + tblName +
> "(id, name, orgid, dep) VALUES(?, ?, ?, ?)")) {
> if (streaming)
> conn.prepareStatement("SET STREAMING
> ON;").execute();
> int leftLimit = 97; // letter 'a'
> int rightLimit = 122; // letter'z'
> int targetStringLength = 15;
> Random rand = new Random();
> //
> for (int i = 0; !stop.get(); ++i) {
> int orgid = rand.ints(1, 0,
> 5).findFirst().getAsInt();
> String val = rand.ints(leftLimit, rightLimit +
> 1).limit(targetStringLength)
> .collect(StringBuilder::new,
>
[jira] [Created] (IGNITE-18096) ignite3db script should be more verbose on startup
Yury Yudin created IGNITE-18096:
---
Summary: ignite3db script should be more verbose on startup
Key: IGNITE-18096
URL: https://issues.apache.org/jira/browse/IGNITE-18096
Project: Ignite
Issue Type: Improvement
Components: build
Reporter: Yury Yudin
{code:java}
demo@mac ignite3-db-3.0.0-SNAPSHOT % ./bin/ignite3db start
demo@mac ignite3-db-3.0.0-SNAPSHOT % {code}
Currently successful start doesn't report anything which might be confusing to
the user. It should at least report that the node with the has started
successfully.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18095) Ignite3 db startup script should attempt to guess IGNITE_HOME if not set
Yury Yudin created IGNITE-18095:
---
Summary: Ignite3 db startup script should attempt to guess
IGNITE_HOME if not set
Key: IGNITE-18095
URL: https://issues.apache.org/jira/browse/IGNITE-18095
Project: Ignite
Issue Type: Improvement
Components: build
Reporter: Yury Yudin
{code:java}
demo@mac bin % ./ignite3db
./ignite3db: line 25:
/Users/demo/Ignite/Binaries/ignite3/ignite3-db-3.0.0-SNAPSHOT/bin/etc/bootstrap-config.env:
No such file or directory
demo@mac bin % {code}
It looks like the guess of IGNITE_HOME was incorrect and needs fixing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17369) Snapshot is inconsistent under streamed loading with 'allowOverwrite==false'.
[
https://issues.apache.org/jira/browse/IGNITE-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629681#comment-17629681
]
Ignite TC Bot commented on IGNITE-17369:
{panel:title=Branch: [pull/10286/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10286/head] Base: [master] : New Tests
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility 1{color} [[tests
2|https://ci2.ignite.apache.org/viewLog.html?buildId=6896927]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterCreateSnapshotWarning - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSSLTest.testClusterCreateSnapshotWarning - PASSED{color}
{color:#8b}Snapshots{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=6896977]]
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamingIntoInMememoryDoesntAffectSnapshot[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerWhileSnapshotOverwriting[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerWhileSnapshotDefault[Encryption=false]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testOtherCacheRestores[Encryption=false] -
PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamingIntoInMememoryDoesntAffectSnapshot[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerWhileSnapshotOverwriting[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testStreamerWhileSnapshotDefault[Encryption=true]
- PASSED{color}
* {color:#013220}IgniteSnapshotTestSuite:
IgniteClusterSnapshotStreamerTest.testOtherCacheRestores[Encryption=true] -
PASSED{color}
{color:#8b}Control Utility (Zookeeper){color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6896928]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testClusterCreateSnapshotWarning - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6896996buildTypeId=IgniteTests24Java8_RunAll]
> Snapshot is inconsistent under streamed loading with 'allowOverwrite==false'.
> -
>
> Key: IGNITE-17369
> URL: https://issues.apache.org/jira/browse/IGNITE-17369
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: ise, ise.lts
> Attachments: IgniteClusterShanpshotStreamerTest.java
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Ignite fails to restore snapshot created under streamed load:
> {code:java}
> Conflict partition: PartitionKeyV2 [grpId=109386747,
> grpName=SQL_PUBLIC_TEST_TBL1, partId=148]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=snapshot.IgniteClusterShanpshotStreamerTest0, updateCntr=29,
> partitionState=OWNING, size=29, partHash=827765854], PartitionHashRecordV2
> [isPrimary=false, consistentId=snapshot.IgniteClusterShanpshotStreamerTest1,
> updateCntr=9, partitionState=OWNING, size=9, partHash=-1515069105]]
> Conflict partition: PartitionKeyV2 [grpId=109386747,
> grpName=SQL_PUBLIC_TEST_TBL1, partId=146]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=snapshot.IgniteClusterShanpshotStreamerTest0, updateCntr=28,
> partitionState=OWNING, size=28, partHash=1497908810], PartitionHashRecordV2
> [isPrimary=false, consistentId=snapshot.IgniteClusterShanpshotStreamerTest1,
> updateCntr=5, partitionState=OWNING, size=5, partHash=821195757]]
> {code}
> Test (attached):
> {code:java}
> public void testClusterSnapshotConsistencyWithStreamer() throws Exception
> {
> int grids = 2;
> CountDownLatch loadNumberBeforeSnapshot = new CountDownLatch(60_000);
> AtomicBoolean stopLoading = new AtomicBoolean(false);
> dfltCacheCfg = null;
> Class.forName("org.apache.ignite.IgniteJdbcDriver");
> String tableName = "TEST_TBL1";
> startGrids(grids);
> grid(0).cluster().state(ACTIVE);
> IgniteInternalFuture load1 = runLoad(tableName, false, 1, true,
> stopLoading, loadNumberBeforeSnapshot);
> loadNumberBeforeSnapshot.await();
> grid(0).snapshot().createSnapshot(SNAPSHOT_NAME).get();
> stopLoading.set(true);
> load1.get();
> grid(0).cache("SQL_PUBLIC_" +
[jira] [Commented] (IGNITE-18006) Support timeouts in async version of python client
[ https://issues.apache.org/jira/browse/IGNITE-18006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629680#comment-17629680 ] Ivan Daschinsky commented on IGNITE-18006: -- [~isapego] Could you please review this patch? > Support timeouts in async version of python client > -- > > Key: IGNITE-18006 > URL: https://issues.apache.org/jira/browse/IGNITE-18006 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to support timeouts in async version of clients. > All cache operations should be supported. > Transaction start, close, commit and cursors start, fetch and close should > not be affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18006) Support timeouts in async version of python client
[ https://issues.apache.org/jira/browse/IGNITE-18006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-18006: - Description: Need to support timeouts in async version of clients. All cache operations should be supported. Transaction start, close, commit and cursors start, fetch and close should not be affected. was: Need to support timeouts in async version of clients. All caches operations, cursor fetch operations. Transaction start, close, commit and cursors start and close should not be affected. > Support timeouts in async version of python client > -- > > Key: IGNITE-18006 > URL: https://issues.apache.org/jira/browse/IGNITE-18006 > Project: Ignite > Issue Type: Improvement > Components: python, thin client >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to support timeouts in async version of clients. > All cache operations should be supported. > Transaction start, close, commit and cursors start, fetch and close should > not be affected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17741) idle_verify must provide explicit data and version hashes
[ https://issues.apache.org/jira/browse/IGNITE-17741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17629645#comment-17629645 ] Nikolay Izhikov commented on IGNITE-17741: -- [~av] Can you, please, take a look at my changes? > idle_verify must provide explicit data and version hashes > - > > Key: IGNITE-17741 > URL: https://issues.apache.org/jira/browse/IGNITE-17741 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Nikolay Izhikov >Priority: Major > Labels: iep-31, ise > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have a single hash. > Separated hashes will provide more information. -- This message was sent by Atlassian Jira (v8.20.10#820010)
