[jira] [Commented] (IGNITE-12401) Some Text Queries return repeated results
[ https://issues.apache.org/jira/browse/IGNITE-12401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367151#comment-17367151 ] Ilya Kasnacheev commented on IGNITE-12401: -- I don't think that we have fixed it. > Some Text Queries return repeated results > - > > Key: IGNITE-12401 > URL: https://issues.apache.org/jira/browse/IGNITE-12401 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8 >Reporter: Ilya Kasnacheev >Assignee: Yuriy Shuliha >Priority: Critical > Time Spent: 10m > Remaining Estimate: 0h > > It came to my attention while checking for Range Queries support that we > don't actually check that found query results are the correct ones. > We were checking that we got some results, but not whether they were expected. > And voila, it turns out that Range Queries examples, as well as some other > test cases, will readily fail when run with such checks! A query will return > same value repeatedly, e.g. range query will return the "1" record twice, and > limited text query will return "14" record twice. > It didn't really occur on non-range queries before the introduction of limits. > I think we should not ship broken limit queries. Maybe also fix range > queries, if it's hard let's @Ignore them for now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14477) Ducktape test of rebalance for persistent mode
[
https://issues.apache.org/jira/browse/IGNITE-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Ryzhov updated IGNITE-14477:
---
Description:
This test should check the rebalance on persistent caches in two scenarios:
# Full rebalance which triggered by two event types: node join and node left
the topology (need to update baseline topology).
# Historical rebalance which triggered by joining to cluster of missed node
with existing PDS:
** Build the cluster with persistence enabled and preload data to it.
** Stop one node without baseline change.
** Make new data updates.
** Return leaved node to the cluster.
The both tests should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: rebalance statistics.
was:
This test should check the rebalance on persistent caches in two scenarios:
# Full rebalance which triggered by two event types: node join and node left
the topology (need to enable baseline auto-adjust and setting the small
baseline auto-adjust timeout).
# Historical rebalance which triggered by joining to cluster of missed node
with existing PDS:
** Build the cluster with persistence enabled and preload data to it.
** Stop one node without baseline change.
** Make new data updates.
** Return leaved node to the cluster.
The both tests should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
Test result: rebalance statistics.
> Ducktape test of rebalance for persistent mode
> --
>
> Key: IGNITE-14477
> URL: https://issues.apache.org/jira/browse/IGNITE-14477
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: IEP-56
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> This test should check the rebalance on persistent caches in two scenarios:
> # Full rebalance which triggered by two event types: node join and node left
> the topology (need to update baseline topology).
> # Historical rebalance which triggered by joining to cluster of missed node
> with existing PDS:
> ** Build the cluster with persistenc
[jira] [Created] (IGNITE-14960) Calcite engine. EXTRACT(DOW FROM d) returns invalid results
Taras Ledkov created IGNITE-14960:
-
Summary: Calcite engine. EXTRACT(DOW FROM d) returns invalid
results
Key: IGNITE-14960
URL: https://issues.apache.org/jira/browse/IGNITE-14960
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Taras Ledkov
The query
{{SELECT EXTRACT(DOW FROM CAST('1993-08-14' AS DATE))}}
return *7*.
According with documentation:
*dow* - The day of the week as Sunday(0) to Saturday(6)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-7654) Geospatial queries does not work for JDBC/ODBC
[
https://issues.apache.org/jira/browse/IGNITE-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-7654:
---
Assignee: (was: Ivan Daschinsky)
> Geospatial queries does not work for JDBC/ODBC
> --
>
> Key: IGNITE-7654
> URL: https://issues.apache.org/jira/browse/IGNITE-7654
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, odbc, sql, thin client
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Geospatial queries do not work for JDBC/ODBC.
> I can create a table with GEOMETRY from sqlline, like this:
> {code:java}
> CREATE TABLE GEO_TABLE(GID INTEGER PRIMARY KEY, THE_GEOM GEOMETRY);{code}
> I can add rows:
> {code:java}
> INSERT INTO GEO_TABLE(GID, THE_GEOM) VALUES (2, 'POINT(500 505)');{code}
> but there's no way to select GEOMETRY objects:
> {code:java}
> SELECT THE_GEOM FROM GEO_TABLE;{code}
> sqlline throws the following excpetion:
> {noformat}
> Error: class org.apache.ignite.binary.BinaryObjectException: Custom objects
> are not supported (state=5,code=0)
> java.sql.SQLException: class org.apache.ignite.binary.BinaryObjectException:
> Custom objects are not supported
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265){noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-8809) Add ability to control.sh to force rebalance for specific partitions on given nodes.
[ https://issues.apache.org/jira/browse/IGNITE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-8809: --- Assignee: (was: Ivan Daschinsky) > Add ability to control.sh to force rebalance for specific partitions on given > nodes. > > > Key: IGNITE-8809 > URL: https://issues.apache.org/jira/browse/IGNITE-8809 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Alexey Scherbakov >Priority: Major > > Sometimes it's desirable to force rebalance for specific partitions on given > nodes, for example, for test reasons or fixing synchronizations issues > without nodes downtime. > control.sh should contain new command: rebalance, which will execute the > exchange request carried by new message type, containing partitions for > rebalancing and mode: full (evict + move) or delta (historical, using > counters). > Example: > control.sh --rebalance [full|delta] nodeId:p1,p2,p3 node2:p4,p5 ... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13549) Calcite integration. CREATE/DROP INDEX support
[ https://issues.apache.org/jira/browse/IGNITE-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367228#comment-17367228 ] Aleksey Plekhanov commented on IGNITE-13549: [~korlov], [~zstan] thanks for the review! Merged to sql-calcite branch. > Calcite integration. CREATE/DROP INDEX support > -- > > Key: IGNITE-13549 > URL: https://issues.apache.org/jira/browse/IGNITE-13549 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Critical > Labels: calcite2-required, calcite3-required > Time Spent: 2.5h > Remaining Estimate: 0h > > We need to support DDL commands. The task about the support of CREATE/DROP > INDEX. Potentially with syntaxis as we already have in the H2 engine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13549) Calcite integration. CREATE/DROP INDEX support
[ https://issues.apache.org/jira/browse/IGNITE-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13549: --- Labels: calcite3-required (was: calcite2-required calcite3-required) > Calcite integration. CREATE/DROP INDEX support > -- > > Key: IGNITE-13549 > URL: https://issues.apache.org/jira/browse/IGNITE-13549 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Critical > Labels: calcite3-required > Time Spent: 2.5h > Remaining Estimate: 0h > > We need to support DDL commands. The task about the support of CREATE/DROP > INDEX. Potentially with syntaxis as we already have in the H2 engine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14960) Calcite engine. EXTRACT(DOW FROM d) returns invalid results
[
https://issues.apache.org/jira/browse/IGNITE-14960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14960:
--
Issue Type: Bug (was: Improvement)
> Calcite engine. EXTRACT(DOW FROM d) returns invalid results
> ---
>
> Key: IGNITE-14960
> URL: https://issues.apache.org/jira/browse/IGNITE-14960
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The query
> {{SELECT EXTRACT(DOW FROM CAST('1993-08-14' AS DATE))}}
> return *7*.
> According with documentation:
> *dow* - The day of the week as Sunday(0) to Saturday(6)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
Taras Ledkov created IGNITE-14961:
-
Summary: Calcite engine. Arithmetic operators cannot be applied to
+
Key: IGNITE-14961
URL: https://issues.apache.org/jira/browse/IGNITE-14961
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Taras Ledkov
The query
{{SELECT cast('2000-10-10' AS DATE) + 2}}
fails with *SqlValidatorException*
{code}
Cannot apply '+' to arguments of type ' + '. Supported form(s):
' + '
' + '
' + '
' + '
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14961:
--
Description:
The query
{{SELECT CAST('2000-10-10' AS DATE) + 2}}
fails with *SqlValidatorException*
{code}
Cannot apply '+' to arguments of type ' + '. Supported form(s):
' + '
' + '
' + '
' + '
{code}
was:
The query
{{SELECT cast('2000-10-10' AS DATE) + 2}}
fails with *SqlValidatorException*
{code}
Cannot apply '+' to arguments of type ' + '. Supported form(s):
' + '
' + '
' + '
' + '
{code}
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[
https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14961:
--
Description:
The query
{{SELECT CAST('2000-10-10' AS DATE) + 2}}
fails with *SqlValidatorException*
{code}
Cannot apply '+' to arguments of type ' + '. Supported form(s):
' + '
' + '
' + '
' + '
{code}
Tests:
{{function/date/test_extract_edge_cases.test_ignore}}
was:
The query
{{SELECT CAST('2000-10-10' AS DATE) + 2}}
fails with *SqlValidatorException*
{code}
Cannot apply '+' to arguments of type ' + '. Supported form(s):
' + '
' + '
' + '
' + '
{code}
> Calcite engine. Arithmetic operators cannot be applied to +
>
>
> Key: IGNITE-14961
> URL: https://issues.apache.org/jira/browse/IGNITE-14961
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The query
> {{SELECT CAST('2000-10-10' AS DATE) + 2}}
> fails with *SqlValidatorException*
> {code}
> Cannot apply '+' to arguments of type ' + '. Supported
> form(s): ' + '
> ' + '
> ' + '
> ' + '
> {code}
> Tests:
> {{function/date/test_extract_edge_cases.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14960) Calcite engine. EXTRACT(DOW FROM d) returns invalid results
[
https://issues.apache.org/jira/browse/IGNITE-14960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14960:
--
Description:
The query
{{SELECT EXTRACT(DOW FROM CAST('1993-08-14' AS DATE))}}
return *7*.
According with documentation:
*dow* - The day of the week as Sunday(0) to Saturday(6)
Tests:
{{function/date/test_extract.test}}
{{function/date/test_extract_edge_cases.test}}
was:
The query
{{SELECT EXTRACT(DOW FROM CAST('1993-08-14' AS DATE))}}
return *7*.
According with documentation:
*dow* - The day of the week as Sunday(0) to Saturday(6)
> Calcite engine. EXTRACT(DOW FROM d) returns invalid results
> ---
>
> Key: IGNITE-14960
> URL: https://issues.apache.org/jira/browse/IGNITE-14960
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> The query
> {{SELECT EXTRACT(DOW FROM CAST('1993-08-14' AS DATE))}}
> return *7*.
> According with documentation:
> *dow* - The day of the week as Sunday(0) to Saturday(6)
> Tests:
> {{function/date/test_extract.test}}
> {{function/date/test_extract_edge_cases.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14962) testStartJoinFinishOK is flaky
Alexey Scherbakov created IGNITE-14962:
--
Summary: testStartJoinFinishOK is flaky
Key: IGNITE-14962
URL: https://issues.apache.org/jira/browse/IGNITE-14962
Project: Ignite
Issue Type: Bug
Reporter: Alexey Scherbakov
Fix For: 3.0.0-alpha3
org.mockito.exceptions.base.MockitoException:
No argument value was captured!
You might have forgotten to use argument.capture() in verify()...
...or you used capture() in stubbing but stubbed method was not called.
Be aware that it is recommended to use capture() only with verify()
Examples of correct argument capturing:
ArgumentCaptor argument = ArgumentCaptor.forClass(Person.class);
verify(mock).doSomething(argument.capture());
assertEquals("John", argument.getValue().getName());
at
org.apache.ignite.raft.jraft.storage.snapshot.local.LocalSnapshotCopierTest.testStartJoinFinishOK(LocalSnapshotCopierTest.java:199)
--- Stderr: ---
2021-06-22 13:50:50:108 +0300 [main] INFO LogScheduledThreadPoolExecutor -
ThreadPool is terminated: JRaft-Node-ScheduleThreadPool,
org.apache.ignite.raft.jraft.util.MetricScheduledThreadPoolExecutor@44492c06[Shutting
down, pool size = 0, active threads = 0, queued tasks = 0, completed tasks =
0].
[« Hide
stacktrace|https://ci.ignite.apache.org/viewLog.html?buildId=6056091&buildTypeId=ignite3_Test_RunAllTests#]
Copy to clipboard
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14893) Bug in GridCacheWriteBehindStore Flusher thread lookup
[
https://issues.apache.org/jira/browse/IGNITE-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Korol updated IGNITE-14893:
Description:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
{code:java}
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
{code}
For example, if you pass this string as a key, it returns a negative number:
*accb2e8ea33e4a89b4189463cacc3c4e*
and then throws an array out of bounds exception when looking up the thread.
http://apache-ignite-developers.2346864.n4.nabble.com/IndexOutOfBoundsException-in-GridCacheWriteBehindStore-Flusher-thread-lookup-IGNITE-14893-tt52827.html#none
was:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
For
example, if you pass this string as a key, it returns a negative number:
accb2e8ea33e4a89b4189463cacc3c4e
and then throws an array out of bounds exception when looking up the thread.
> Bug in GridCacheWriteBehindStore Flusher thread lookup
> --
>
> Key: IGNITE-14893
> URL: https://issues.apache.org/jira/browse/IGNITE-14893
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.5, 2.7.6, 2.9, 2.8.1, 2.10, 2.9.1
>Reporter: Mike W
>Assignee: Ilya Korol
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There's a bug in GridCacheWriteBehindStore in the flusher method.
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
> The logic states there that if flush thread count is not a power of 2, then
> perform this math, which is not guaranteed to return a positive number.
> {code:java}
> idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
> {code}
> For example, if you pass this string as a key, it returns a negative number:
> *accb2e8ea33e4a89b4189463cacc3c4e*
> and then throws an array out of bounds exception when looking up the thread.
> http://apache-ignite-developers.2346864.n4.nabble.com/IndexOutOfBoundsException-in-GridCacheWriteBehindStore-Flusher-thread-lookup-IGNITE-14893-tt52827.html#none
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14907) testLearnerServices is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov resolved IGNITE-14907. Resolution: Duplicate Should be fixed by IGNITE-14853 > testLearnerServices is flaky > > > Key: IGNITE-14907 > URL: https://issues.apache.org/jira/browse/IGNITE-14907 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > https://ci.ignite.apache.org/viewLog.html?buildId=6049184&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14921) NPE in ClusterImpl on node start
[
https://issues.apache.org/jira/browse/IGNITE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov resolved IGNITE-14921.
Resolution: Duplicate
Should be fixed by IGNITE-14853
> NPE in ClusterImpl on node start
>
>
> Key: IGNITE-14921
> URL: https://issues.apache.org/jira/browse/IGNITE-14921
> Project: Ignite
> Issue Type: Task
>Reporter: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {noformat}
> 2021-06-17 12:54:17:578 +0300 [main] INFO ITCliServiceTest - >>>
> Start test method: testChangePeers
> 2021-06-17 12:54:17:578 +0300 [main] INFO ITCliServiceTest - >>>
> Start test method: testChangePeers2021-06-17 12:54:26:228 +0300 [main] INFO
> FSMCallerImpl - Starts FSMCaller successfully.2021-06-17 12:54:26:262 +0300
> [main] WARN LocalSnapshotStorage - No data for snapshot reader
> D:\work\ignite-3\modules\raft\jraft_test_1455162015862\192.168.0.107_5003\snapshot.
> 2021-06-17 12:54:26:276 +0300 [main] INFO NodeImpl - Node
> init, term=0, lastLogId=LogId [index=0,
> term=0],
> conf=192.168.0.107:5003,192.168.0.107:5004,192.168.0.107:5005,192.168.0.107:5103/learner,192.168.0.107:5104/learner,
> oldConf=.2021-06-17 12:54:27:224 +0300
> [JRaft-ElectionTimer-192.168.0.107:5003-0] INFO NodeImpl - Node
> term 0 start preVote.2021-06-17
> 12:54:27:477 +0300 [JRaft-ElectionTimer-192.168.0.107:5003-0] ERROR
> RepeatedTimer - Run timer failed.
> java.lang.NullPointerException at
> io.scalecube.cluster.ClusterImpl.requestResponse(ClusterImpl.java:419) at
> org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:123)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:130)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:124)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:199)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.connect(AbstractClientService.java:130)
> at org.apache.ignite.raft.jraft.core.NodeImpl.preVote(NodeImpl.java:2668) at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleElectionTimeout(NodeImpl.java:614)
> at org.apache.ignite.raft.jraft.core.NodeImpl$2.onTrigger(NodeImpl.java:910)
> at org.apache.ignite.raft.jraft.util.RepeatedTimer.run(RepeatedTimer.java:80)
> at
> org.apache.ignite.raft.jraft.util.RepeatedTimer.lambda$schedule$0(RepeatedTimer.java:177)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:577)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:649)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$Worker.run(HashedWheelTimer.java:383)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 2021-06-17 12:54:28:348 +0300 [main] INFO Cluster - [null][doStart] Starting,
> config: ClusterConfig[metadata=null, metadataTimeout=1000,
> metadataCodec=io.scalecube.cluster.metadata.JdkMetadataCodec@2eee3069,
> memberAlias='192.168.0.107:5003', externalHost='null', externalPort=null,
> transportConfig=TransportConfig[port=0, isSecured=false, connectTimeout=1000,
> messageCodec=io.scalecube.cluster.transport.api.JdkMessageCodec@2da59753,
> maxFrameLength=2097152,
> transportFactory=org.apache.ignite.network.scalecube.DelegatingTransportFactory@5629510],
> failureDetectorConfig=FailureDetectorConfig[pingInterval=500,
> pingTimeout=200, pingReqMembers=1], gossipConfig=GossipConfig[gossipFanout=3,
> gossipInterval=10, gossipRepeatMult=2, gossipSegmentationThreshold=1000],
> membershipConfig=MembershipConfig[seedMembers=[192.168.0.107:5003,
> 192.168.0.107:5004, 192.168.0.107:5005], syncInterval=1000, syncTimeout=3000,
> suspicionMult=1, namespace='default', removedMembersHistorySize=42]]
> 2021-06-17 12:54:28:501 +0300 [JRaft-ElectionTimer-192.168.0.107:5003-0] INFO
> NodeImpl - Node term 0 start preVote.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14852) testChangePeers is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov resolved IGNITE-14852. Resolution: Duplicate Should be fixed by IGNITE-14853 > testChangePeers is flaky > > > Key: IGNITE-14852 > URL: https://issues.apache.org/jira/browse/IGNITE-14852 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > New peer in test sometimes fails to caught up, because in has not replied to > a leader in 300 ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14852) testChangePeers is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14852: --- Issue Type: Bug (was: Task) > testChangePeers is flaky > > > Key: IGNITE-14852 > URL: https://issues.apache.org/jira/browse/IGNITE-14852 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > New peer in test sometimes fails to caught up, because in has not replied to > a leader in 300 ms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14907) testLearnerServices is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14907: --- Issue Type: Bug (was: Task) > testLearnerServices is flaky > > > Key: IGNITE-14907 > URL: https://issues.apache.org/jira/browse/IGNITE-14907 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > https://ci.ignite.apache.org/viewLog.html?buildId=6049184&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14921) NPE in ClusterImpl on node start
[
https://issues.apache.org/jira/browse/IGNITE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-14921:
---
Issue Type: Bug (was: Task)
> NPE in ClusterImpl on node start
>
>
> Key: IGNITE-14921
> URL: https://issues.apache.org/jira/browse/IGNITE-14921
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {noformat}
> 2021-06-17 12:54:17:578 +0300 [main] INFO ITCliServiceTest - >>>
> Start test method: testChangePeers
> 2021-06-17 12:54:17:578 +0300 [main] INFO ITCliServiceTest - >>>
> Start test method: testChangePeers2021-06-17 12:54:26:228 +0300 [main] INFO
> FSMCallerImpl - Starts FSMCaller successfully.2021-06-17 12:54:26:262 +0300
> [main] WARN LocalSnapshotStorage - No data for snapshot reader
> D:\work\ignite-3\modules\raft\jraft_test_1455162015862\192.168.0.107_5003\snapshot.
> 2021-06-17 12:54:26:276 +0300 [main] INFO NodeImpl - Node
> init, term=0, lastLogId=LogId [index=0,
> term=0],
> conf=192.168.0.107:5003,192.168.0.107:5004,192.168.0.107:5005,192.168.0.107:5103/learner,192.168.0.107:5104/learner,
> oldConf=.2021-06-17 12:54:27:224 +0300
> [JRaft-ElectionTimer-192.168.0.107:5003-0] INFO NodeImpl - Node
> term 0 start preVote.2021-06-17
> 12:54:27:477 +0300 [JRaft-ElectionTimer-192.168.0.107:5003-0] ERROR
> RepeatedTimer - Run timer failed.
> java.lang.NullPointerException at
> io.scalecube.cluster.ClusterImpl.requestResponse(ClusterImpl.java:419) at
> org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:123)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:130)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:124)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:199)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.connect(AbstractClientService.java:130)
> at org.apache.ignite.raft.jraft.core.NodeImpl.preVote(NodeImpl.java:2668) at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleElectionTimeout(NodeImpl.java:614)
> at org.apache.ignite.raft.jraft.core.NodeImpl$2.onTrigger(NodeImpl.java:910)
> at org.apache.ignite.raft.jraft.util.RepeatedTimer.run(RepeatedTimer.java:80)
> at
> org.apache.ignite.raft.jraft.util.RepeatedTimer.lambda$schedule$0(RepeatedTimer.java:177)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:577)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:649)
> at
> org.apache.ignite.raft.jraft.util.timer.HashedWheelTimer$Worker.run(HashedWheelTimer.java:383)
> at java.base/java.lang.Thread.run(Thread.java:834)
> 2021-06-17 12:54:28:348 +0300 [main] INFO Cluster - [null][doStart] Starting,
> config: ClusterConfig[metadata=null, metadataTimeout=1000,
> metadataCodec=io.scalecube.cluster.metadata.JdkMetadataCodec@2eee3069,
> memberAlias='192.168.0.107:5003', externalHost='null', externalPort=null,
> transportConfig=TransportConfig[port=0, isSecured=false, connectTimeout=1000,
> messageCodec=io.scalecube.cluster.transport.api.JdkMessageCodec@2da59753,
> maxFrameLength=2097152,
> transportFactory=org.apache.ignite.network.scalecube.DelegatingTransportFactory@5629510],
> failureDetectorConfig=FailureDetectorConfig[pingInterval=500,
> pingTimeout=200, pingReqMembers=1], gossipConfig=GossipConfig[gossipFanout=3,
> gossipInterval=10, gossipRepeatMult=2, gossipSegmentationThreshold=1000],
> membershipConfig=MembershipConfig[seedMembers=[192.168.0.107:5003,
> 192.168.0.107:5004, 192.168.0.107:5005], syncInterval=1000, syncTimeout=3000,
> suspicionMult=1, namespace='default', removedMembersHistorySize=42]]
> 2021-06-17 12:54:28:501 +0300 [JRaft-ElectionTimer-192.168.0.107:5003-0] INFO
> NodeImpl - Node term 0 start preVote.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14943) testInstallLargeSnapshotWithThrottle is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14943: --- Issue Type: Bug (was: Task) > testInstallLargeSnapshotWithThrottle is flaky > -- > > Key: IGNITE-14943 > URL: https://issues.apache.org/jira/browse/IGNITE-14943 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Node has failed to caugh up due to timeout by unclear reason. > https://ci.ignite.apache.org/viewLog.html?buildId=6052568&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Issue Type: Bug (was: Task) > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [testInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > [https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14933) Implement metrics for a snapshot restore operation
[ https://issues.apache.org/jira/browse/IGNITE-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-14933: - Assignee: Pavel Pereslegin > Implement metrics for a snapshot restore operation > -- > > Key: IGNITE-14933 > URL: https://issues.apache.org/jira/browse/IGNITE-14933 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > > Since the automatic snapshot restore operation can take a long time, we must > be able to track its progress using metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367314#comment-17367314 ] Alexey Scherbakov commented on IGNITE-14853: Merged to master #7d42f95c19c5642d8e00a664aec154a2faa5a357 > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [testInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > [https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Release Note: (was: Merged to master #7d42f95c19c5642d8e00a664aec154a2faa5a357) > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [testInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > [https://ci.ignite.apache.org/viewLog.html?buildId=6044871&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14893) Bug in GridCacheWriteBehindStore Flusher thread lookup
[
https://issues.apache.org/jira/browse/IGNITE-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Korol updated IGNITE-14893:
Description:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
{code:java}
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
{code}
For example, if you pass this string as a key, it returns a negative number:
*accb2e8ea33e4a89b4189463cacc3c4e*
and then throws an array out of bounds exception when looking up the thread.
https://lists.apache.org/list.html?d...@ignite.apache.org
was:
There's a bug in GridCacheWriteBehindStore in the flusher method.
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
The logic states there that if flush thread count is not a power of 2, then
perform this math, which is not guaranteed to return a positive number.
{code:java}
idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
{code}
For example, if you pass this string as a key, it returns a negative number:
*accb2e8ea33e4a89b4189463cacc3c4e*
and then throws an array out of bounds exception when looking up the thread.
http://apache-ignite-developers.2346864.n4.nabble.com/IndexOutOfBoundsException-in-GridCacheWriteBehindStore-Flusher-thread-lookup-IGNITE-14893-tt52827.html#none
> Bug in GridCacheWriteBehindStore Flusher thread lookup
> --
>
> Key: IGNITE-14893
> URL: https://issues.apache.org/jira/browse/IGNITE-14893
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.5, 2.7.6, 2.9, 2.8.1, 2.10, 2.9.1
>Reporter: Mike W
>Assignee: Ilya Korol
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There's a bug in GridCacheWriteBehindStore in the flusher method.
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
> The logic states there that if flush thread count is not a power of 2, then
> perform this math, which is not guaranteed to return a positive number.
> {code:java}
> idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
> {code}
> For example, if you pass this string as a key, it returns a negative number:
> *accb2e8ea33e4a89b4189463cacc3c4e*
> and then throws an array out of bounds exception when looking up the thread.
> https://lists.apache.org/list.html?d...@ignite.apache.org
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14794) Add JMX command and metrics for automatic snapshot restore operation.
[ https://issues.apache.org/jira/browse/IGNITE-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-14794: -- Summary: Add JMX command and metrics for automatic snapshot restore operation. (was: Add JMX command to restore a cache group from the snapshot.) > Add JMX command and metrics for automatic snapshot restore operation. > -- > > Key: IGNITE-14794 > URL: https://issues.apache.org/jira/browse/IGNITE-14794 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > > Add JMX command to restore a cache group from the snapshot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14794) Add JMX command and metrics for automatic snapshot restore operation.
[ https://issues.apache.org/jira/browse/IGNITE-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-14794: -- Description: Add JMX command to restore a cache group from the snapshot. Since the automatic snapshot restore operation can take a long time, we must be able to track its progress using metrics. was: Add JMX command to restore a cache group from the snapshot. > Add JMX command and metrics for automatic snapshot restore operation. > -- > > Key: IGNITE-14794 > URL: https://issues.apache.org/jira/browse/IGNITE-14794 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > > Add JMX command to restore a cache group from the snapshot. > Since the automatic snapshot restore operation can take a long time, we must > be able to track its progress using metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14794) Add JMX command and metrics for automatic snapshot restore operation.
[
https://issues.apache.org/jira/browse/IGNITE-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-14794:
--
Description:
Add JMX command to restore a cache group from the snapshot.
Suggested methods
{code:java}
@MXBeanDescription("Restore cluster-wide snapshot.")
public void restoreSnapshot(
@MXBeanParameter(name = "snpName", description = "Snapshot name.")
String name,
@MXBeanParameter(name = "cacheGroupNames", description = "Optional
comma-separated list of cache group names.") String cacheGroupNames);
@MXBeanDescription("Cancel previously started snapshot restore operation.")
public void cancelSnapshotRestore(@MXBeanParameter(name = "snpName",
description = "Snapshot name.") String name);
{code}
Since the automatic snapshot restore operation can take a long time, we must be
able to track its progress using metrics.
Suggested metrics:
{noformat}
start time
total partitions
copied partitions
end time
{noformat}
was:
Add JMX command to restore a cache group from the snapshot.
Since the automatic snapshot restore operation can take a long time, we must be
able to track its progress using metrics.
> Add JMX command and metrics for automatic snapshot restore operation.
> --
>
> Key: IGNITE-14794
> URL: https://issues.apache.org/jira/browse/IGNITE-14794
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43
> Fix For: 2.12
>
>
> Add JMX command to restore a cache group from the snapshot.
> Suggested methods
> {code:java}
> @MXBeanDescription("Restore cluster-wide snapshot.")
> public void restoreSnapshot(
> @MXBeanParameter(name = "snpName", description = "Snapshot name.")
> String name,
> @MXBeanParameter(name = "cacheGroupNames", description = "Optional
> comma-separated list of cache group names.") String cacheGroupNames);
> @MXBeanDescription("Cancel previously started snapshot restore
> operation.")
> public void cancelSnapshotRestore(@MXBeanParameter(name = "snpName",
> description = "Snapshot name.") String name);
> {code}
> Since the automatic snapshot restore operation can take a long time, we must
> be able to track its progress using metrics.
> Suggested metrics:
> {noformat}
> start time
> total partitions
> copied partitions
> end time
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14933) Implement metrics for a snapshot restore operation
[ https://issues.apache.org/jira/browse/IGNITE-14933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin resolved IGNITE-14933. --- Resolution: Duplicate > Implement metrics for a snapshot restore operation > -- > > Key: IGNITE-14933 > URL: https://issues.apache.org/jira/browse/IGNITE-14933 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43 > > Since the automatic snapshot restore operation can take a long time, we must > be able to track its progress using metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12437) .NET: Run tests on macOS TeamCity agent
[ https://issues.apache.org/jira/browse/IGNITE-12437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-12437: --- Assignee: (was: Pavel Tupitsyn) > .NET: Run tests on macOS TeamCity agent > --- > > Key: IGNITE-12437 > URL: https://issues.apache.org/jira/browse/IGNITE-12437 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > There is one acOS agent on TC. Run tests there to ensure full support of > Ignite.NET on macOS -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-7562) .NET: Binary object as dynamic object
[
https://issues.apache.org/jira/browse/IGNITE-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-7562:
--
Assignee: (was: Pavel Tupitsyn)
> .NET: Binary object as dynamic object
> -
>
> Key: IGNITE-7562
> URL: https://issues.apache.org/jira/browse/IGNITE-7562
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> Provide a way to access {{IBinaryObject}} fields through C# {{dynamic}} API:
> {code}
> IBinaryObject obj = cache.Get(1);
> var name = obj.GetField("Name"); // Current API
> dynamic dynObj = obj.AsDynamic();
> name = dynObj.Name; // Proposed API
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-7563) .NET: Binary object builder dynamic API
[
https://issues.apache.org/jira/browse/IGNITE-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-7563:
--
Assignee: (was: Pavel Tupitsyn)
> .NET: Binary object builder dynamic API
> ---
>
> Key: IGNITE-7563
> URL: https://issues.apache.org/jira/browse/IGNITE-7563
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> Provide a way to build binary objects with C# {{dynamic}} API:
> {code}
> IBinary bin = ignite.GetBinary();
> IBinaryObjectBuilder builder = bin.GetBuilder("myType");
> builder.SetField("Name", "Jack"); // current API
> IBinaryObjectBuilderDynamic dynBuilder = builder.AsDynamic();
> dynBuilder.Name = "Jack";
> IBinaryObject result = dynBuilder.Build();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-2292) .NET: Add ability to build .NET platform from Maven
[
https://issues.apache.org/jira/browse/IGNITE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-2292:
--
Assignee: (was: Pavel Tupitsyn)
> .NET: Add ability to build .NET platform from Maven
> ---
>
> Key: IGNITE-2292
> URL: https://issues.apache.org/jira/browse/IGNITE-2292
> Project: Ignite
> Issue Type: Task
> Components: general, platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: .net
>
> Currently build procedure looks as follows:
> 1) Java is built from Maven
> 2) .NET is built manually using modules/platforms/dotnet/mkbuild.cmd
> 3) Docs fo Java, .NET and CPP are built form Maven
> Looks like we should intergrate .NET buld into Maven process so that user can
> build the whole product with a single command. E.g.:
> {code}mvn clean package [java_build_args] -Dignite.net.docs=true
> -Dignite.net.build =true -Dignite.net.build.x86=true
> -Dignite.net.build.x86.javaHome=[path to x86 JDK]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13607) .NET: Binary meta is not registered from QueryEntity on cache start when types are not present on server node
[
https://issues.apache.org/jira/browse/IGNITE-13607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-13607:
---
Assignee: (was: Pavel Tupitsyn)
> .NET: Binary meta is not registered from QueryEntity on cache start when
> types are not present on server node
> -
>
> Key: IGNITE-13607
> URL: https://issues.apache.org/jira/browse/IGNITE-13607
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
>
> When {{QueryEntity}} is present in {{CacheConfiguration}},
> {{GridQueryProcessor}} registers binary metadata for key and value types by
> looking up Java classes (IGNITE-5795) and .NET types (IGNITE-13160) and
> scanning attributes. In particular, Affinity Key is determined at this point
> and then cached for future use.
> However, when corresponding Java/.NET types are not present on the server
> node, affinity key can't be determined from annotations/attributes and is
> considered null.
> This can happens only with dynamic cache start in the following cases:
> * Thin clients - the most obvious case, classes are almost never present on
> server nodes
> * Thick clients
> * Server nodes with different classpath
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12210) .NET: Propagate new Metrics API
[ https://issues.apache.org/jira/browse/IGNITE-12210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-12210: --- Assignee: (was: Pavel Tupitsyn) > .NET: Propagate new Metrics API > --- > > Key: IGNITE-12210 > URL: https://issues.apache.org/jira/browse/IGNITE-12210 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Recent monitoring & profiling changes (IGNITE-11848) have deprecated old > metrics APIs in Ignite interface. > We should adopt new APIs in Ignite.NET as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10411) .NET: Allow conditional serialization override
[ https://issues.apache.org/jira/browse/IGNITE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-10411: --- Assignee: (was: Pavel Tupitsyn) > .NET: Allow conditional serialization override > -- > > Key: IGNITE-10411 > URL: https://issues.apache.org/jira/browse/IGNITE-10411 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > Labels: .NET > > IBinarySerializer provides a way to override serialization per-type or > globally (when set as BinaryConfiguration.Serializer). > But often we want a global override only for *some* types, and default Ignite > mechanism for everything else. This is not trivial, because Ignite passes > uninitialized object to ReadBinary. > Provide a way to fall back to default mode from IBinarySerializer (another > interface, or extend current?). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13351) .NET: Add generic types and methods support to Services
[
https://issues.apache.org/jira/browse/IGNITE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-13351:
---
Assignee: (was: Pavel Tupitsyn)
> .NET: Add generic types and methods support to Services
> ---
>
> Key: IGNITE-13351
> URL: https://issues.apache.org/jira/browse/IGNITE-13351
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
>
> Applies to Thick and Thin modes (service proxy code is shared): allow generic
> methods and generic service types in Ignite Services. Right now
> {{ServiceProxyTypeGenerator}} does not emit proper IL code for generics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10364) .NET: FailureHandlerTest should be reworked
[
https://issues.apache.org/jira/browse/IGNITE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn reassigned IGNITE-10364:
---
Assignee: (was: Pavel Tupitsyn)
> .NET: FailureHandlerTest should be reworked
> ---
>
> Key: IGNITE-10364
> URL: https://issues.apache.org/jira/browse/IGNITE-10364
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Priority: Minor
> Labels: .NET
>
> Currently, {{FailureHandlerTest}} uses a broken {{CacheStoreFactory}} in
> order to trigger the execution of {{FailureHandler}} when a cache with the
> given factory is created. https://issues.apache.org/jira/browse/IGNITE-8640
> provides a fix that initiates rollback procedure in that case and so, does
> not trigger {{FailureHandler}}
> So, the test should use another approach to test {{FailureHandler}}. It seems
> {{IoomFailureHandlerTest}} can be used as a starting point.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-6599) .NET: IgniteConfiguration.ClusterName
[ https://issues.apache.org/jira/browse/IGNITE-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-6599: -- Assignee: (was: Pavel Tupitsyn) > .NET: IgniteConfiguration.ClusterName > - > > Key: IGNITE-6599 > URL: https://issues.apache.org/jira/browse/IGNITE-6599 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Minor > Labels: .NET, newbie > > Propagate from Java: IGNITE-6597 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-8608) .NET: Sign release NuGet packages
[ https://issues.apache.org/jira/browse/IGNITE-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-8608: -- Assignee: (was: Pavel Tupitsyn) > .NET: Sign release NuGet packages > - > > Key: IGNITE-8608 > URL: https://issues.apache.org/jira/browse/IGNITE-8608 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Priority: Major > > NuGet signed package submissions has been introduced recently: > https://blog.nuget.org/20180522/Introducing-signed-package-submissions.html > Sign Ignite.NET packages when releasing them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14857) Calcite integration. ALTER TABLE support
[
https://issues.apache.org/jira/browse/IGNITE-14857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367369#comment-17367369
]
Aleksey Plekhanov commented on IGNITE-14857:
Added support for {{ALTER TABLE ADD COLUMN}}/\{{ALTER TABLE DROP
COLUMN}}/\{{ALTER TABLE LOGGING/NOLOGGING}}
[~korlov], [~tledkov-gridgain], can you please review the patch?
> Calcite integration. ALTER TABLE support
>
>
> Key: IGNITE-14857
> URL: https://issues.apache.org/jira/browse/IGNITE-14857
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to support DDL commands. The task about the support of ALTER TABLE
> ADD/DROP/ALTER COLUMN.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14963) Calcite engine. Date interval arythmetic returns invalid results
Taras Ledkov created IGNITE-14963:
-
Summary: Calcite engine. Date interval arythmetic returns invalid
results
Key: IGNITE-14963
URL: https://issues.apache.org/jira/browse/IGNITE-14963
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Taras Ledkov
{{select date '1992-01-01' + interval (17) days}} - returns {{1992-01-18}} -
valid
{{select date '1992-01-01' + interval (18) days}} - returns {{1992-01-18}} -
invalid
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14963) Calcite engine. Date interval arythmetic returns invalid results
[
https://issues.apache.org/jira/browse/IGNITE-14963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14963:
--
Description:
{{select date '1992-01-01' + interval (17) days}} - returns {{1992-01-18}} -
valid
{{select date '1992-01-01' + interval (18) days}} - returns {{1992-01-18}} -
invalid
Tests:
{{function/date/test_extract_month.test}}
was:
{{select date '1992-01-01' + interval (17) days}} - returns {{1992-01-18}} -
valid
{{select date '1992-01-01' + interval (18) days}} - returns {{1992-01-18}} -
invalid
> Calcite engine. Date interval arythmetic returns invalid results
>
>
> Key: IGNITE-14963
> URL: https://issues.apache.org/jira/browse/IGNITE-14963
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Major
>
> {{select date '1992-01-01' + interval (17) days}} - returns {{1992-01-18}} -
> valid
> {{select date '1992-01-01' + interval (18) days}} - returns {{1992-01-18}} -
> invalid
> Tests:
> {{function/date/test_extract_month.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14957) Introduce a class for network addresses
[
https://issues.apache.org/jira/browse/IGNITE-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14957:
-
Reviewer: Slava Koptilin
> Introduce a class for network addresses
> ---
>
> Key: IGNITE-14957
> URL: https://issues.apache.org/jira/browse/IGNITE-14957
> Project: Ignite
> Issue Type: Task
> Components: networking
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Network module currently uses {{String}} as a mean to represent a network
> address. This is both inconvenient and requires additional parsing. We should
> introduce a {{NetworkAddress}} class that will contain a hostname and a port,
> and replace all {{String}} usages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14957) Introduce a class for network addresses
[
https://issues.apache.org/jira/browse/IGNITE-14957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367538#comment-17367538
]
Vyacheslav Koptilin commented on IGNITE-14957:
--
Hello [~apolovtcev],
I will take a look at your PR if you don't mind.
> Introduce a class for network addresses
> ---
>
> Key: IGNITE-14957
> URL: https://issues.apache.org/jira/browse/IGNITE-14957
> Project: Ignite
> Issue Type: Task
> Components: networking
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Network module currently uses {{String}} as a mean to represent a network
> address. This is both inconvenient and requires additional parsing. We should
> introduce a {{NetworkAddress}} class that will contain a hostname and a port,
> and replace all {{String}} usages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14964) Calcite engine. Huge list for IN clause canot be compiled
Taras Ledkov created IGNITE-14964:
-
Summary: Calcite engine. Huge list for IN clause canot be compiled
Key: IGNITE-14964
URL: https://issues.apache.org/jira/browse/IGNITE-14964
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Taras Ledkov
The query {{SELECT * FROM strings WHERE s IN ()}} fails with
error:
{code}
Code of method
"execute(Lorg/apache/ignite/internal/processors/query/calcite/exec/ExecutionContext;Ljava/lang/Object;Ljava/lang/Object;)V"
of class "SC" grows beyond 64 KB
{code}
Exception:
{code}
class org.apache.ignite.IgniteException: Compiling "SC": Code of method
"execute(Lorg/apache/ignite/internal/processors/query/calcite/exec/ExecutionContext;Ljava/lang/Object;Ljava/lang/Object;)V"
of class "SC" grows beyond 64 KB
at
org.apache.ignite.internal.processors.query.calcite.util.Commons.compile(Commons.java:299)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:315)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:263)
at
java.base/java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:330)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.scalar(ExpressionFactoryImpl.java:263)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactory.scalar(ExpressionFactory.java:114)
at
org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.predicate(ExpressionFactoryImpl.java:215)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:294)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:109)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteIndexScan.accept(IgniteIndexScan.java:134)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:657)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:667)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:369)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:109)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteSort.accept(IgniteSort.java:81)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:657)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:667)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:161)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:109)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteSender.accept(IgniteSender.java:97)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:657)
at
org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.go(LogicalRelImplementor.java:672)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeFragment(ExecutionServiceImpl.java:781)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:848)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$2(ExecutionServiceImpl.java:451)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:280)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:256)
at
org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.codehaus.janino.InternalCompilerException: Compiling "SC": Code
of method
"execute(Lorg/apache/ignite/internal/processors/query/calcite/exec/ExecutionContext;Ljava/lang/Object;Ljava/lang/Object;)V"
of class "SC" grows beyond 64 KB
at org.codehaus.jani
[jira] [Created] (IGNITE-14965) Ignite is in invalid state when trying to use Ignite as a Spring bean
Ivan Fedorenkov created IGNITE-14965: Summary: Ignite is in invalid state when trying to use Ignite as a Spring bean Key: IGNITE-14965 URL: https://issues.apache.org/jira/browse/IGNITE-14965 Project: Ignite Issue Type: Bug Components: spring Affects Versions: 2.10 Reporter: Ivan Fedorenkov The following use-case leads to temporary invalid state errors at the grid startup time: Ignite node has an Ignite Service with Ignite DI being used to inject into that service a Spring-managed bean, which in its turn depends on the Ignite instance, namely the IgniteSpringBean instance. Invoke any method of the bean that uses the Ignite instance from the execute method of the service. Result: IllegalStateException "Ignite is in invalid state to perform this operation". The root cause is that Ignite Services initialization and execution may happen before IgniteSpringBean#afterSingletonInstantiated returns and the inner g variable gets initialized. Please note that even if the g variable gets initialized before any Ignite Service starts executing, a spring-managed bean may still get the exception as the inner g variable is not volatile and other threads may observe the outdated value for some small amount of time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14966) ClientFieldsQueryCursor fails to return columns before the first row gets accessed
Ivan Fedorenkov created IGNITE-14966: Summary: ClientFieldsQueryCursor fails to return columns before the first row gets accessed Key: IGNITE-14966 URL: https://issues.apache.org/jira/browse/IGNITE-14966 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 2.9.1 Reporter: Ivan Fedorenkov When user issues a SQL query using the IgniteClient instance and wants to access the resulting list of columns as well as their total count he gets nothing and zero before the first row gets accessed. This behavior is incompatible with "fat" client nodes and server nodes that get this information right away. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14966) ClientFieldsQueryCursor fails to return columns before the first row gets accessed
[ https://issues.apache.org/jira/browse/IGNITE-14966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedorenkov updated IGNITE-14966: - Affects Version/s: (was: 2.9.1) 2.10 > ClientFieldsQueryCursor fails to return columns before the first row gets > accessed > -- > > Key: IGNITE-14966 > URL: https://issues.apache.org/jira/browse/IGNITE-14966 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.10 >Reporter: Ivan Fedorenkov >Priority: Major > > When user issues a SQL query using the IgniteClient instance and wants to > access the resulting list of columns as well as their total count he gets > nothing and zero before the first row gets accessed. This behavior is > incompatible with "fat" client nodes and server nodes that get this > information right away. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14967) High threads contention for the massive read/write scenario
Ivan Fedorenkov created IGNITE-14967: Summary: High threads contention for the massive read/write scenario Key: IGNITE-14967 URL: https://issues.apache.org/jira/browse/IGNITE-14967 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.10 Reporter: Ivan Fedorenkov There is a high threads contention for the intensive read/write scenario, caused by the PageMemoryNoStoreImpl rwLock. When user tries to insert entries into a cache with a high (or better say very high) rate, when grid nodes are running on powerful machines (e.g. 96 cores, 390+ gigs of RAM each) then the JFR (Java Flight Recorder) report shows that like 30-40% of the time writing threads are waiting for the read lock for the page that they would like to modify (gray bards in the Threads tab). The issue seems to be worse when the cache has an associated SQL schema with indexes. The workaround is to run multiple small grid nodes within the big host. However, this contradicts with the statement that Apache Ignite has a good support of both: horizontal and vertical scaling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14968) Fix classnotfoundexception in transaction cache of entryprocessor using annotation
xingzhou created IGNITE-14968: - Summary: Fix classnotfoundexception in transaction cache of entryprocessor using annotation Key: IGNITE-14968 URL: https://issues.apache.org/jira/browse/IGNITE-14968 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.9 Reporter: xingzhou Fix For: 2.9 Recurrence conditions 1. Transaction cache 2.backups>0 3. Using annotation for entryprocessor 4. Cluster node > 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14968) classnotfoundexception in transaction cache of entryprocessor using annotation
[ https://issues.apache.org/jira/browse/IGNITE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xingzhou updated IGNITE-14968: -- Summary: classnotfoundexception in transaction cache of entryprocessor using annotation (was: Fix classnotfoundexception in transaction cache of entryprocessor using annotation) > classnotfoundexception in transaction cache of entryprocessor using annotation > -- > > Key: IGNITE-14968 > URL: https://issues.apache.org/jira/browse/IGNITE-14968 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: xingzhou >Priority: Critical > Fix For: 2.9 > > Original Estimate: 24h > Remaining Estimate: 24h > > Recurrence conditions > 1. Transaction cache > 2.backups>0 > 3. Using annotation for entryprocessor > 4. Cluster node > 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14968) classnotfoundexception in transaction cache of entryprocessor using annotation
[ https://issues.apache.org/jira/browse/IGNITE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xingzhou updated IGNITE-14968: -- Attachment: application.log > classnotfoundexception in transaction cache of entryprocessor using annotation > -- > > Key: IGNITE-14968 > URL: https://issues.apache.org/jira/browse/IGNITE-14968 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: xingzhou >Priority: Critical > Fix For: 2.9 > > Attachments: application.log > > Original Estimate: 24h > Time Spent: 10m > Remaining Estimate: 23h 50m > > Recurrence conditions > 1. Transaction cache > 2.backups>0 > 3. Using annotation for entryprocessor > 4. Cluster node > 2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14893) Bug in GridCacheWriteBehindStore Flusher thread lookup
[
https://issues.apache.org/jira/browse/IGNITE-14893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367870#comment-17367870
]
Ignite TC Bot commented on IGNITE-14893:
{panel:title=Branch: [pull/9177/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9177/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6056209]]
* {color:#013220}IgniteBasicTestSuite:
IgniteUtilsSelfTest.testHashToIndexDistributionAdvanced - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
IgniteUtilsSelfTest.testHashToIndexDistribution - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6056270&buildTypeId=IgniteTests24Java8_RunAll]
> Bug in GridCacheWriteBehindStore Flusher thread lookup
> --
>
> Key: IGNITE-14893
> URL: https://issues.apache.org/jira/browse/IGNITE-14893
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.5, 2.7.6, 2.9, 2.8.1, 2.10, 2.9.1
>Reporter: Mike W
>Assignee: Ilya Korol
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There's a bug in GridCacheWriteBehindStore in the flusher method.
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674]
> The logic states there that if flush thread count is not a power of 2, then
> perform this math, which is not guaranteed to return a positive number.
> {code:java}
> idx = ((h = key.hashCode()) ^ (h >>> 16)) % flushThreadCnt
> {code}
> For example, if you pass this string as a key, it returns a negative number:
> *accb2e8ea33e4a89b4189463cacc3c4e*
> and then throws an array out of bounds exception when looking up the thread.
> https://lists.apache.org/list.html?d...@ignite.apache.org
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
