[jira] [Commented] (IGNITE-14544) Calcite engine. Support DISTINCT aggregates
[
https://issues.apache.org/jira/browse/IGNITE-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344005#comment-17344005
]
Alexey Goncharuk commented on IGNITE-14544:
---
[~tledkov-gridgain] do we have the {{AggregateExpandDistinctAggregatesRule}}
enabled? Looks like it can reduce the distinct aggregates to {{GROUP BY}} /
{{JOIN}} operators, which will simplify the implementation, this may be an
alternative approach.
> Calcite engine. Support DISTINCT aggregates
> ---
>
> Key: IGNITE-14544
> URL: https://issues.apache.org/jira/browse/IGNITE-14544
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now, DISTINCT aggregates not implemented.
> (e.g. {{SELECT COUNT (DISTINCT lastName) FROM person}})
> Tests:
> {{aggregate/aggregates/test_count.test}}
> {{aggregate/aggregates/test_avg.test}}
> {{aggregate/aggregates/test_distinct_aggr.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14647) Ignite 3: Document affinity and rebalance process via Raft
Alexey Goncharuk created IGNITE-14647: - Summary: Ignite 3: Document affinity and rebalance process via Raft Key: IGNITE-14647 URL: https://issues.apache.org/jira/browse/IGNITE-14647 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14502) Ignite 3: Consider JSON-formatted toString implementations
Alexey Goncharuk created IGNITE-14502:
-
Summary: Ignite 3: Consider JSON-formatted toString implementations
Key: IGNITE-14502
URL: https://issues.apache.org/jira/browse/IGNITE-14502
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
This is a follow-up for IGNITE-14501. Once {{GridToStringBuilder}} is ported to
Ignite 3, we may change the formatting to a JSON-like structure so that any
object can be beautified using standard tools.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14501) Ignite 3: Fix toString implementations
Alexey Goncharuk created IGNITE-14501:
-
Summary: Ignite 3: Fix toString implementations
Key: IGNITE-14501
URL: https://issues.apache.org/jira/browse/IGNITE-14501
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Fix For: 3.0.0-alpha2
There is a number of places in the codebase where autogenerated IDEA
{{toString()}} implementations are used (for example, {{ModuleRegistry}},
{{NetworkMember}})) or non-conformant {{toString()}} implementations ({{Peer}}
in raft-client).
We need to fix the {{toString()}} implementations and move GridToStringBuilder
from Ignite 2.x to avoid further similar issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313700#comment-17313700
]
Alexey Goncharuk commented on IGNITE-14459:
---
[~agura][~ascherbakov] can you take a look at the fix?
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14459:
--
Fix Version/s: 2.11
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313028#comment-17313028
]
Alexey Goncharuk edited comment on IGNITE-14459 at 4/1/21, 9:09 AM:
The fix enforces that local and remote affinity info are fetched on the same
topology version by extracting the {{topVer}} detection to the calling site.
was (Author: agoncharuk):
The fix enforces that local and remote affinity info are fetched on the same
topology version by extracting the {{topVer}} detection in the calling site.
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17313028#comment-17313028
]
Alexey Goncharuk commented on IGNITE-14459:
---
The fix enforces that local and remote affinity info are fetched on the same
topology version by extracting the {{topVer}} detection in the calling site.
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-14459:
-
Assignee: Alexey Goncharuk
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14459:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
Alexey Goncharuk created IGNITE-14459:
-
Summary: Affinity call may fail if called upon merged exchanges
Key: IGNITE-14459
URL: https://issues.apache.org/jira/browse/IGNITE-14459
Project: Ignite
Issue Type: Improvement
Components: compute
Reporter: Alexey Goncharuk
When exchanges are merged, intermediate affinity assignments are not filled. At
the same time, when a client chooses topology to run affinity call on, it may
take a non-completed exchange version. As a result, when the affinity fetch
task arrives on a node, it will look up a non-existing assignment, resulting in
"Getting affinity for topology version earlier than affinity is calculated"
exception.
{{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because of
this bug.
The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
issue:
{code}
/**
* @throws Exception if failed.
*/
@Test
public void testAffinityCallMergedExchanges() throws Exception {
startGrids(SRVS);
final Integer key = 1;
final IgniteEx client = startClientGrid(SRVS);
assertTrue(client.configuration().isClientMode());
assertNull(client.context().cache().cache(CACHE_NAME));
try {
grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
new AffinityTopologyVersion(SRVS + 3, 0),
null
);
IgniteInternalFuture fut1 = GridTestUtils.runAsync(() ->
startGrid(SRVS + 1));
assertTrue(GridTestUtils.waitForCondition(() ->
client.context().cache().context()
.exchange().lastTopologyFuture()
.initialVersion().equals(new AffinityTopologyVersion(SRVS + 2,
0)), 5_000));
assertFalse(fut1.isDone());
// The future should not complete until second node is started.
IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
client.compute().affinityCall(CACHE_NAME, key, new
CheckCallable(key, null)));
startGrid(SRVS + 2);
fut1.get();
fut2.get();
}
finally {
stopAllGrids();
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-14393: - Assignee: Alexey Goncharuk > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14393: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14393) Describe components interactions with metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14393: -- Labels: iep-61 ignite-3 (was: ) > Describe components interactions with metastorage > - > > Key: IGNITE-14393 > URL: https://issues.apache.org/jira/browse/IGNITE-14393 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-alpha1 >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > We want to use metastorage as the golden source of the cluster state. Need to > describe how components will interact with each other based on metastorage > key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14393) Describe components interactions with metastorage
Alexey Goncharuk created IGNITE-14393: - Summary: Describe components interactions with metastorage Key: IGNITE-14393 URL: https://issues.apache.org/jira/browse/IGNITE-14393 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 3.0.0-alpha1 Reporter: Alexey Goncharuk Fix For: 3.0.0-alpha2 We want to use metastorage as the golden source of the cluster state. Need to describe how components will interact with each other based on metastorage key writes and watches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Skip writing null-map and varlen table when possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Summary: Skip writing null-map and varlen table when possible (was: Upgrade nullmap to null-defaults map) > Skip writing null-map and varlen table when possible > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). > Also, need to add support for skipping writing nullmaps (use the flags bit). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13748) Schema configuration public API
[ https://issues.apache.org/jira/browse/IGNITE-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303246#comment-17303246 ] Alexey Goncharuk commented on IGNITE-13748: --- Looks good from my side. I think we can merge and start collecting feedback from the community. > Schema configuration public API > --- > > Key: IGNITE-13748 > URL: https://issues.apache.org/jira/browse/IGNITE-13748 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Let's implement a public API classes for initial schema declaration. > Considering next: > * It should be possible to create schema without having any Class instance, > like we do now with QueryEntity. > * -Automatic schema creation based on annotated classes, like we have in > ccfg.setIndexedTypes()- IGNITE-13749 > * -Transient fields semantic.- IGNITE-13749 > * Using builder pattern for schema configuration. > * Split type-system into internal native-types (introduced IGNITE-13617) and > public API types. The latest ones should be portable (e.g. could be used in > .Net) > * API can be extracted to separate module that will not have any dependency > on other Ignite modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13618) Provide generated and reflection-based class (de)serializers
[ https://issues.apache.org/jira/browse/IGNITE-13618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303218#comment-17303218 ] Alexey Goncharuk commented on IGNITE-13618: --- [~amashenkov] I've added a README file to the module with schema management description from the IEP. Good to merge from my side. > Provide generated and reflection-based class (de)serializers > > > Key: IGNITE-13618 > URL: https://issues.apache.org/jira/browse/IGNITE-13618 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Attachments: benchmark-results.txt > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation. > It may worth having generated serializer code for performance reasons. > However, this should be proved with benchmarks. > h3. Description. > Let's prototype object serializer for type-system described in IEP-54, and > benchmark them to check if generated code approach is a better one. > * As we go with Java11 then VarHandles must be used instead of Unsafe. > * For generated serializer we can use: JDK compiler + Javapoet project (Java > code generator) or Janino compiler or even Prestodb-bytecode module of > PrestoDB project > *UPD*: JDK compile is too slow, Janino doesn't support Java9+ and VarHandles, > Prestodb-bytecode has an unwanted Guava dependency. > So, forking Prestodb without Guava looks like a preferable way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14325) SQL COPY command: when conversion fails, the error does not contain information about line number and the failed value
Alexey Goncharuk created IGNITE-14325:
-
Summary: SQL COPY command: when conversion fails, the error does
not contain information about line number and the failed value
Key: IGNITE-14325
URL: https://issues.apache.org/jira/browse/IGNITE-14325
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.10
Reporter: Alexey Goncharuk
I was trying to import data from a CSV file to Ignite cache through sqlline.
When a file contains a value that cannot be converted to the schema format, the
error message printed by the client is absolutely useless:
{code}
Error: Server error: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=PICKUP_DATETIME, from=java.lang.String,
to=java.sql.Timestamp] (state=5,code=1)
java.sql.SQLException: Server error: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=PICKUP_DATETIME, from=java.lang.String,
to=java.sql.Timestamp]
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.sendFile(JdbcThinStatement.java:336)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:243)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
at sqlline.Commands.executeSingleQuery(Commands.java:1054)
at sqlline.Commands.execute(Commands.java:1003)
at sqlline.Commands.sql(Commands.java:967)
at sqlline.SqlLine.dispatch(SqlLine.java:734)
at sqlline.SqlLine.begin(SqlLine.java:541)
at sqlline.SqlLine.start(SqlLine.java:267)
at sqlline.SqlLine.main(SqlLine.java:206)
{code}
The server log does not contain any helpful information as well.
When input validation failed, we need to output the following context
information:
* Line number of the source file that triggered the error
* A few values preceding the wrong column
* The exact value that failed parse/conversion error
* For complex types (such as date/timestamp), the acceptable input formats
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14315) Ignite 3: Use maven-flatten plugin for project pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-14315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14315: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Ignite 3: Use maven-flatten plugin for project pom.xml > -- > > Key: IGNITE-14315 > URL: https://issues.apache.org/jira/browse/IGNITE-14315 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 3.0.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > Without the flatten it would be impossible to use the maven-published > artifacts of Ignite 3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14315) Ignite 3: Use maven-flatten plugin for project pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-14315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14315: -- Fix Version/s: 3.0.0-alpha2 > Ignite 3: Use maven-flatten plugin for project pom.xml > -- > > Key: IGNITE-14315 > URL: https://issues.apache.org/jira/browse/IGNITE-14315 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 3.0.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > Without the flatten it would be impossible to use the maven-published > artifacts of Ignite 3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14315) Ignite 3: Use maven-flatten plugin for project pom.xml
Alexey Goncharuk created IGNITE-14315: - Summary: Ignite 3: Use maven-flatten plugin for project pom.xml Key: IGNITE-14315 URL: https://issues.apache.org/jira/browse/IGNITE-14315 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Without the flatten it would be impossible to use the maven-published artifacts of Ignite 3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14315) Ignite 3: Use maven-flatten plugin for project pom.xml
[ https://issues.apache.org/jira/browse/IGNITE-14315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-14315: - Assignee: Alexey Goncharuk > Ignite 3: Use maven-flatten plugin for project pom.xml > -- > > Key: IGNITE-14315 > URL: https://issues.apache.org/jira/browse/IGNITE-14315 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > Without the flatten it would be impossible to use the maven-published > artifacts of Ignite 3. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13748) Schema configuration public API
[ https://issues.apache.org/jira/browse/IGNITE-13748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13748: -- Fix Version/s: (was: 3.0) 3.0.0-alpha2 > Schema configuration public API > --- > > Key: IGNITE-13748 > URL: https://issues.apache.org/jira/browse/IGNITE-13748 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Let's implement a public API classes for initial schema declaration. > Considering next: > * It should be possible to create schema without having any Class instance, > like we do now with QueryEntity. > * -Automatic schema creation based on annotated classes, like we have in > ccfg.setIndexedTypes()- IGNITE-13749 > * -Transient fields semantic.- IGNITE-13749 > * Using builder pattern for schema configuration. > * Split type-system into internal native-types (introduced GG-13617) and > public API types. The latest ones should be portable (e.g. could be used in > .Net) > * API can be extracted to separate module that will not have any dependency > on other Ignite modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13618) Provide generated and reflection-based class (de)serializers
[ https://issues.apache.org/jira/browse/IGNITE-13618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13618: -- Fix Version/s: (was: 3.0) 3.0.0-alpha2 > Provide generated and reflection-based class (de)serializers > > > Key: IGNITE-13618 > URL: https://issues.apache.org/jira/browse/IGNITE-13618 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > Attachments: benchmark-results.txt > > Time Spent: 1h > Remaining Estimate: 0h > > h3. Motivation. > It may worth having generated serializer code for performance reasons. > However, this should be proved with benchmarks. > h3. Description. > Let's prototype object serializer for type-system described in IEP-54, and > benchmark them to check if generated code approach is a better one. > * As we go with Java11 then VarHandles must be used instead of Unsafe. > * For generated serializer we can use: JDK compiler + Javapoet project (Java > code generator) or Janino compiler or even Prestodb-bytecode module of > PrestoDB project > *UPD*: JDK compile is too slow, Janino doesn't support Java9+ and VarHandles, > Prestodb-bytecode has an unwanted Guava dependency. > So, forking Prestodb without Guava looks like a preferable way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14272) Merge modules/DEVNOTES.txt and DEVNOTES.txt
[ https://issues.apache.org/jira/browse/IGNITE-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14272: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Merge modules/DEVNOTES.txt and DEVNOTES.txt > --- > > Key: IGNITE-14272 > URL: https://issues.apache.org/jira/browse/IGNITE-14272 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Trivial > Fix For: 3.0.0-alpha2 > > > The modules/DEVNOTES.txt was mistakenly introduced, the contents should be > moved to the root DEVNOTES.txt > Also, we may add some structure to modules README.md files and link them to > DEVNOTES.txt -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14272) Merge modules/DEVNOTES.txt and DEVNOTES.txt
Alexey Goncharuk created IGNITE-14272: - Summary: Merge modules/DEVNOTES.txt and DEVNOTES.txt Key: IGNITE-14272 URL: https://issues.apache.org/jira/browse/IGNITE-14272 Project: Ignite Issue Type: Improvement Components: documentation Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk Fix For: 3.0.0-alpha2 The modules/DEVNOTES.txt was mistakenly introduced, the contents should be moved to the root DEVNOTES.txt Also, we may add some structure to modules README.md files and link them to DEVNOTES.txt -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13799) Provide a required interface for partition raft client
[ https://issues.apache.org/jira/browse/IGNITE-13799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13799: -- Description: We need to identify an interface (and possibly a state machine) for an arbitrary partition that will be further used for atomic and transactional caches. We need to identify possible commands for partition modification, as well as possible error and error codes that may be encountered during cache updates. was: We need to identify two storage interfaces that will be interacting with the replication protocol: * Distributed metastorage persistent state machine * Partition persistent state machine The interfaces for the said storages most likely will be quite different, but still will have some common ground. Need to define them so that we can start moving the page memory infrastructure to Ignite-3 > Provide a required interface for partition raft client > -- > > Key: IGNITE-13799 > URL: https://issues.apache.org/jira/browse/IGNITE-13799 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Assignee: Alexander Lapin >Priority: Major > Labels: iep-61, ignite-3 > > We need to identify an interface (and possibly a state machine) for an > arbitrary partition that will be further used for atomic and transactional > caches. > We need to identify possible commands for partition modification, as well as > possible error and error codes that may be encountered during cache updates. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13799) Provide a required interface for partition raft client
[ https://issues.apache.org/jira/browse/IGNITE-13799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13799: -- Summary: Provide a required interface for partition raft client (was: Provide a required interface for partitions for replication protocol) > Provide a required interface for partition raft client > -- > > Key: IGNITE-13799 > URL: https://issues.apache.org/jira/browse/IGNITE-13799 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Assignee: Alexander Lapin >Priority: Major > Labels: iep-61, ignite-3 > > We need to identify two storage interfaces that will be interacting with the > replication protocol: > * Distributed metastorage persistent state machine > * Partition persistent state machine > The interfaces for the said storages most likely will be quite different, but > still will have some common ground. Need to define them so that we can start > moving the page memory infrastructure to Ignite-3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13800) Provide distributed metastorage interface
[ https://issues.apache.org/jira/browse/IGNITE-13800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13800: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Provide distributed metastorage interface > - > > Key: IGNITE-13800 > URL: https://issues.apache.org/jira/browse/IGNITE-13800 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14198) Define interface for meta storage client
[ https://issues.apache.org/jira/browse/IGNITE-14198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14198: -- Description: Interface for meta storage client should be defined in order to unblock development and unit-testing. Interface implementation is not needed on this stage. We need to crystallize the metastorage interface prototype from the IEP to understand how it will be integrated with other system components. Need to cover: * Asynchrony aspects * Possible error codes (connection failure -> unknown result vs Raft failure -> known result, etc) * Complex multi-updates (aka transactions) * Watchers. Each node can watch all updates and filter locally or adjust the watched ranges dynamically (consistency is important here) These interfaces are considered "client" interfaces as they will be available on all nodes in the cluster was: Interface for meta storage client should be defined in order to unblock development and unit-testing. Interface implementation is not needed on this stage. > Define interface for meta storage client > > > Key: IGNITE-14198 > URL: https://issues.apache.org/jira/browse/IGNITE-14198 > Project: Ignite > Issue Type: New Feature >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > Interface for meta storage client should be defined in order to unblock > development and unit-testing. > Interface implementation is not needed on this stage. > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13800) Provide distributed metastorage interface
[ https://issues.apache.org/jira/browse/IGNITE-13800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13800: -- Labels: (was: iep-61 ignite-3) > Provide distributed metastorage interface > - > > Key: IGNITE-13800 > URL: https://issues.apache.org/jira/browse/IGNITE-13800 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Priority: Major > > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13799) Provide a required interface for partitions for replication protocol
[ https://issues.apache.org/jira/browse/IGNITE-13799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13799: -- Summary: Provide a required interface for partitions for replication protocol (was: Provide a required storage interface for metastorage and partitions for replication protocol) > Provide a required interface for partitions for replication protocol > > > Key: IGNITE-13799 > URL: https://issues.apache.org/jira/browse/IGNITE-13799 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Assignee: Alexander Lapin >Priority: Major > Labels: iep-61, ignite-3 > > We need to identify two storage interfaces that will be interacting with the > replication protocol: > * Distributed metastorage persistent state machine > * Partition persistent state machine > The interfaces for the said storages most likely will be quite different, but > still will have some common ground. Need to define them so that we can start > moving the page memory infrastructure to Ignite-3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13800) Provide distributed metastorage interface
[ https://issues.apache.org/jira/browse/IGNITE-13800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-13800. --- Resolution: Duplicate > Provide distributed metastorage interface > - > > Key: IGNITE-13800 > URL: https://issues.apache.org/jira/browse/IGNITE-13800 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14198) Define interface for meta storage client
[ https://issues.apache.org/jira/browse/IGNITE-14198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14198: -- Labels: iep-61 ignite-3 (was: ) > Define interface for meta storage client > > > Key: IGNITE-14198 > URL: https://issues.apache.org/jira/browse/IGNITE-14198 > Project: Ignite > Issue Type: New Feature >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha2 > > > Interface for meta storage client should be defined in order to unblock > development and unit-testing. > Interface implementation is not needed on this stage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14112) Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
[
https://issues.apache.org/jira/browse/IGNITE-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14112:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
>
>
> Key: IGNITE-14112
> URL: https://issues.apache.org/jira/browse/IGNITE-14112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a simple {{Runnable}} is passed to the {{runLocalSafe}} method, not only
> will Ignite attempt to inject resources to the runnable, but it will also
> make a call to deployment, which may have various side effects.
> Need to walk through the code and replace {{Runnable}} with
> {{GridPlainRunnable}} in all places where injection is not needed/expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14112) Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
[
https://issues.apache.org/jira/browse/IGNITE-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14112:
--
Fix Version/s: 2.11
> Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
>
>
> Key: IGNITE-14112
> URL: https://issues.apache.org/jira/browse/IGNITE-14112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If a simple {{Runnable}} is passed to the {{runLocalSafe}} method, not only
> will Ignite attempt to inject resources to the runnable, but it will also
> make a call to deployment, which may have various side effects.
> Need to walk through the code and replace {{Runnable}} with
> {{GridPlainRunnable}} in all places where injection is not needed/expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13874) Add PMD and idea inspections to Ignite-3 build cycle
[ https://issues.apache.org/jira/browse/IGNITE-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-13874. --- Fix Version/s: 3.0.0-alpha2 Resolution: Fixed > Add PMD and idea inspections to Ignite-3 build cycle > > > Key: IGNITE-13874 > URL: https://issues.apache.org/jira/browse/IGNITE-13874 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 40m > Remaining Estimate: 0h > > Since we are moving in small incremental code changes, we can impose more > strict code rules and, perhaps, automate code style check completely. > Let's start with PMD and Idea inspections transfer to Ignite-3 repository, > with some reasonable default profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14111) Clarify how AbstractDataPageIO works
[ https://issues.apache.org/jira/browse/IGNITE-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14111: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Clarify how AbstractDataPageIO works > > > Key: IGNITE-14111 > URL: https://issues.apache.org/jira/browse/IGNITE-14111 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > There we several questions on how direct and indirect items work in the > DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14111) Clarify how AbstractDataPageIO works
[ https://issues.apache.org/jira/browse/IGNITE-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277121#comment-17277121 ] Alexey Goncharuk commented on IGNITE-14111: --- Merged to master. This is a javadoc-only ticket, no need for a full visa. > Clarify how AbstractDataPageIO works > > > Key: IGNITE-14111 > URL: https://issues.apache.org/jira/browse/IGNITE-14111 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > There we several questions on how direct and indirect items work in the > DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14111) Clarify how AbstractDataPageIO works
[ https://issues.apache.org/jira/browse/IGNITE-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-14111: -- Fix Version/s: 2.11 > Clarify how AbstractDataPageIO works > > > Key: IGNITE-14111 > URL: https://issues.apache.org/jira/browse/IGNITE-14111 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > There we several questions on how direct and indirect items work in the > DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14112) Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
[
https://issues.apache.org/jira/browse/IGNITE-14112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-14112:
-
Assignee: Alexey Goncharuk
> Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
>
>
> Key: IGNITE-14112
> URL: https://issues.apache.org/jira/browse/IGNITE-14112
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>
> If a simple {{Runnable}} is passed to the {{runLocalSafe}} method, not only
> will Ignite attempt to inject resources to the runnable, but it will also
> make a call to deployment, which may have various side effects.
> Need to walk through the code and replace {{Runnable}} with
> {{GridPlainRunnable}} in all places where injection is not needed/expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14112) Revisit GridClosureProcessor#runLocalSafe(Runnable, byte) usages
Alexey Goncharuk created IGNITE-14112:
-
Summary: Revisit GridClosureProcessor#runLocalSafe(Runnable, byte)
usages
Key: IGNITE-14112
URL: https://issues.apache.org/jira/browse/IGNITE-14112
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
If a simple {{Runnable}} is passed to the {{runLocalSafe}} method, not only
will Ignite attempt to inject resources to the runnable, but it will also make
a call to deployment, which may have various side effects.
Need to walk through the code and replace {{Runnable}} with
{{GridPlainRunnable}} in all places where injection is not needed/expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14111) Clarify how AbstractDataPageIO works
[ https://issues.apache.org/jira/browse/IGNITE-14111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-14111: - Assignee: Alexey Goncharuk > Clarify how AbstractDataPageIO works > > > Key: IGNITE-14111 > URL: https://issues.apache.org/jira/browse/IGNITE-14111 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > > There we several questions on how direct and indirect items work in the > DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14111) Clarify how AbstractDataPageIO works
Alexey Goncharuk created IGNITE-14111: - Summary: Clarify how AbstractDataPageIO works Key: IGNITE-14111 URL: https://issues.apache.org/jira/browse/IGNITE-14111 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk There we several questions on how direct and indirect items work in the DataPageIO, the mechanics should be added to Javadoc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: (was: php-1.0.0)
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: php-1.0.0
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2, php-1.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: (was: python-0.3.4)
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: python-1.0.0
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2, python-1.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: (was: python-1.0.0)
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: python-0.4.0
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2, python-0.4.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: python-0.3.4
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2, python-0.3.4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14001) Minor code style fixes for configuration and runner modules
[
https://issues.apache.org/jira/browse/IGNITE-14001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-14001:
--
Fix Version/s: (was: python-0.4.0)
> Minor code style fixes for configuration and runner modules
> ---
>
> Key: IGNITE-14001
> URL: https://issues.apache.org/jira/browse/IGNITE-14001
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha1
>Reporter: Alexey Goncharuk
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 3.0.0-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Some of the configuration files contain TODOs or FIXMEs without tickets -
> either tickets should be created, or TODOs fixed/removed.
> * {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
> {{ConfigurationValidationException}}, {{FieldValidator}} contain extra
> spacing before the end of class/at the beginning of the class.
> * Some of the overridden methods do not contain {{@Override}} annotation
> ({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
> {{Configurator#onAttached}})
> We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14002) Formalize coding guidelines for platforms (C++, Python, Node)
Alexey Goncharuk created IGNITE-14002: - Summary: Formalize coding guidelines for platforms (C++, Python, Node) Key: IGNITE-14002 URL: https://issues.apache.org/jira/browse/IGNITE-14002 Project: Ignite Issue Type: Wish Reporter: Alexey Goncharuk Currently, we have coding guidelines for Java and .NET in place [1], [2]. It would be nice to have similar documents for other supported platforms and languages to ease the newcomers' trail in the project and maintain a common code style. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14001) Minor code style fixes for configuration and runner modules
Alexey Goncharuk created IGNITE-14001:
-
Summary: Minor code style fixes for configuration and runner
modules
Key: IGNITE-14001
URL: https://issues.apache.org/jira/browse/IGNITE-14001
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
* Some of the configuration files contain TODOs or FIXMEs without tickets -
either tickets should be created, or TODOs fixed/removed.
* {{Selector}}, {{DynamicProperty}}, {{ConfigurationStorage}},
{{ConfigurationValidationException}}, {{FieldValidator}} contain extra spacing
before the end of class/at the beginning of the class.
* Some of the overridden methods do not contain {{@Override}} annotation
({{ConfigurationProperty#value}}, anonymous {{PropertyListener}} in
{{Configurator#onAttached}})
We will try to figure out automated checks for this in the future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14000) Ignite 3.0: Fix codestyle for cli and cli-common packages
Alexey Goncharuk created IGNITE-14000:
-
Summary: Ignite 3.0: Fix codestyle for cli and cli-common packages
Key: IGNITE-14000
URL: https://issues.apache.org/jira/browse/IGNITE-14000
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
Fix For: 3.0
Currently, the listed modules do not conform Ignite Coding Giudelines [1]:
* classes are poorly formatted (e.g. braces for one-line if/for statements,
invalid spacing for fields and statements blocks)
* classes lack proper javadocs
* packages missing package-info.java
* code contains TODOs without tickets (tickets either should be created or
TODOs removed/fixed)
* code contains commented code blocks
* Some error messages should be fixed ("Fail to..." -> "Failed to...", remove
usages of "Please")
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13572: -- Fix Version/s: (was: nodejs-1.0.0) > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.10, 2.9.1 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13572: -- Fix Version/s: nodejs-1.0.0 > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.10, 2.9.1, nodejs-1.0.0 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12355) IEP-36: Modularization
[ https://issues.apache.org/jira/browse/IGNITE-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12355: -- Fix Version/s: (was: nodejs-1.1.0) > IEP-36: Modularization > -- > > Key: IGNITE-12355 > URL: https://issues.apache.org/jira/browse/IGNITE-12355 > Project: Ignite > Issue Type: Improvement > Components: streaming >Affects Versions: 2.8 >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > > Migrate streaming modules in ignite-extensions repo > > [https://github.com/apache/ignite-extensions] > > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12355) IEP-36: Modularization
[ https://issues.apache.org/jira/browse/IGNITE-12355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-12355: -- Fix Version/s: nodejs-1.1.0 > IEP-36: Modularization > -- > > Key: IGNITE-12355 > URL: https://issues.apache.org/jira/browse/IGNITE-12355 > Project: Ignite > Issue Type: Improvement > Components: streaming >Affects Versions: 2.8 >Reporter: Saikat Maitra >Assignee: Saikat Maitra >Priority: Major > Fix For: nodejs-1.1.0 > > > Migrate streaming modules in ignite-extensions repo > > [https://github.com/apache/ignite-extensions] > > Details: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IndependentIntegrations] > Discussion : > [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html#a44107] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13885) Investigate jraft implementation for replication framework based on RAFT protocol.
[ https://issues.apache.org/jira/browse/IGNITE-13885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13885: -- Labels: ignite-3 (was: ) > Investigate jraft implementation for replication framework based on RAFT > protocol. > -- > > Key: IGNITE-13885 > URL: https://issues.apache.org/jira/browse/IGNITE-13885 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Investigation points: > # Ease of custom RPC implementation. > # Threading model fit. > # Liveness guaranties [1] > # State machine overload safety. > [1] > https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13874) Add PMD and idea inspections to Ignite-3 build cycle
[ https://issues.apache.org/jira/browse/IGNITE-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk reassigned IGNITE-13874: - Assignee: Alexey Goncharuk > Add PMD and idea inspections to Ignite-3 build cycle > > > Key: IGNITE-13874 > URL: https://issues.apache.org/jira/browse/IGNITE-13874 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > > Since we are moving in small incremental code changes, we can impose more > strict code rules and, perhaps, automate code style check completely. > Let's start with PMD and Idea inspections transfer to Ignite-3 repository, > with some reasonable default profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13874) Add PMD and idea inspections to Ignite-3 build cycle
[ https://issues.apache.org/jira/browse/IGNITE-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13874: -- Labels: ignite-3 (was: ) > Add PMD and idea inspections to Ignite-3 build cycle > > > Key: IGNITE-13874 > URL: https://issues.apache.org/jira/browse/IGNITE-13874 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > > Since we are moving in small incremental code changes, we can impose more > strict code rules and, perhaps, automate code style check completely. > Let's start with PMD and Idea inspections transfer to Ignite-3 repository, > with some reasonable default profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13874) Add PMD and idea inspections to Ignite-3 build cycle
[ https://issues.apache.org/jira/browse/IGNITE-13874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13874: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Add PMD and idea inspections to Ignite-3 build cycle > > > Key: IGNITE-13874 > URL: https://issues.apache.org/jira/browse/IGNITE-13874 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: ignite-3 > > Since we are moving in small incremental code changes, we can impose more > strict code rules and, perhaps, automate code style check completely. > Let's start with PMD and Idea inspections transfer to Ignite-3 repository, > with some reasonable default profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13874) Add PMD and idea inspections to Ignite-3 build cycle
Alexey Goncharuk created IGNITE-13874: - Summary: Add PMD and idea inspections to Ignite-3 build cycle Key: IGNITE-13874 URL: https://issues.apache.org/jira/browse/IGNITE-13874 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Since we are moving in small incremental code changes, we can impose more strict code rules and, perhaps, automate code style check completely. Let's start with PMD and Idea inspections transfer to Ignite-3 repository, with some reasonable default profiles. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13786) PDS defragmentation can inflate index size
[ https://issues.apache.org/jira/browse/IGNITE-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17247299#comment-17247299 ] Alexey Goncharuk commented on IGNITE-13786: --- Looks good, merged to master! > PDS defragmentation can inflate index size > -- > > Key: IGNITE-13786 > URL: https://issues.apache.org/jira/browse/IGNITE-13786 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > For huge caches it is possible that defragmentation will lead to bigger > indexes size. > The reason is that we only append new data to index trees and never insert > into the middle, this leads to under-utilization of B+Tree pages space. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13786) PDS defragmentation can inflate index size
[ https://issues.apache.org/jira/browse/IGNITE-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13786: -- Fix Version/s: 2.10 > PDS defragmentation can inflate index size > -- > > Key: IGNITE-13786 > URL: https://issues.apache.org/jira/browse/IGNITE-13786 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > For huge caches it is possible that defragmentation will lead to bigger > indexes size. > The reason is that we only append new data to index trees and never insert > into the middle, this leads to under-utilization of B+Tree pages space. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13786) PDS defragmentation can inflate index size
[ https://issues.apache.org/jira/browse/IGNITE-13786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13786: -- Ignite Flags: (was: Docs Required,Release Notes Required) > PDS defragmentation can inflate index size > -- > > Key: IGNITE-13786 > URL: https://issues.apache.org/jira/browse/IGNITE-13786 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > For huge caches it is possible that defragmentation will lead to bigger > indexes size. > The reason is that we only append new data to index trees and never insert > into the middle, this leads to under-utilization of B+Tree pages space. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13800) Provide distributed metastorage interface
Alexey Goncharuk created IGNITE-13800: - Summary: Provide distributed metastorage interface Key: IGNITE-13800 URL: https://issues.apache.org/jira/browse/IGNITE-13800 Project: Ignite Issue Type: New Feature Reporter: Alexey Goncharuk We need to crystallize the metastorage interface prototype from the IEP to understand how it will be integrated with other system components. Need to cover: * Asynchrony aspects * Possible error codes (connection failure -> unknown result vs Raft failure -> known result, etc) * Complex multi-updates (aka transactions) * Watchers. Each node can watch all updates and filter locally or adjust the watched ranges dynamically (consistency is important here) These interfaces are considered "client" interfaces as they will be available on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13800) Provide distributed metastorage interface
[ https://issues.apache.org/jira/browse/IGNITE-13800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13800: -- Labels: iep-61 ignite-3 (was: ) > Provide distributed metastorage interface > - > > Key: IGNITE-13800 > URL: https://issues.apache.org/jira/browse/IGNITE-13800 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > > We need to crystallize the metastorage interface prototype from the IEP to > understand how it will be integrated with other system components. > Need to cover: > * Asynchrony aspects > * Possible error codes (connection failure -> unknown result vs Raft failure > -> known result, etc) > * Complex multi-updates (aka transactions) > * Watchers. Each node can watch all updates and filter locally or adjust the > watched ranges dynamically (consistency is important here) > These interfaces are considered "client" interfaces as they will be available > on all nodes in the cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13799) Provide a required storage interface for metastorage and partitions for replication protocol
[ https://issues.apache.org/jira/browse/IGNITE-13799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13799: -- Labels: iep-61 ignite-3 (was: ) > Provide a required storage interface for metastorage and partitions for > replication protocol > > > Key: IGNITE-13799 > URL: https://issues.apache.org/jira/browse/IGNITE-13799 > Project: Ignite > Issue Type: New Feature >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-61, ignite-3 > > We need to identify two storage interfaces that will be interacting with the > replication protocol: > * Distributed metastorage persistent state machine > * Partition persistent state machine > The interfaces for the said storages most likely will be quite different, but > still will have some common ground. Need to define them so that we can start > moving the page memory infrastructure to Ignite-3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13799) Provide a required storage interface for metastorage and partitions for replication protocol
Alexey Goncharuk created IGNITE-13799: - Summary: Provide a required storage interface for metastorage and partitions for replication protocol Key: IGNITE-13799 URL: https://issues.apache.org/jira/browse/IGNITE-13799 Project: Ignite Issue Type: New Feature Reporter: Alexey Goncharuk We need to identify two storage interfaces that will be interacting with the replication protocol: * Distributed metastorage persistent state machine * Partition persistent state machine The interfaces for the said storages most likely will be quite different, but still will have some common ground. Need to define them so that we can start moving the page memory infrastructure to Ignite-3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13798) Prototype Raft implementation port to a separate zero-dependency Ignite module
Alexey Goncharuk created IGNITE-13798: - Summary: Prototype Raft implementation port to a separate zero-dependency Ignite module Key: IGNITE-13798 URL: https://issues.apache.org/jira/browse/IGNITE-13798 Project: Ignite Issue Type: New Feature Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk We need to check whether it is reasonable and feasible to port the etcd Raft implementation [1] to Java, maintaining the same API interaction model: * Raft instance is a single-threaded state machine with methods to accept messages, return progress to be processed by a raft client, and tick callback * Raft instance does not actively send messages, not does it actively write to persistent log or the state machine The implementation should demonstrate how the module will be used with omitted components: Raft Log, State Machine, Messaging, Timer. The implementation must cover: * Ability to provide leader/follower callbacks * Ability to read linearizable and relaxed commit indexes The implementation may cover: * Replication group reconfiguration The implementation prototype does not cover: * Multi-raft groups * Asynchronous state machine mutation -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17239330#comment-17239330
]
Alexey Goncharuk commented on IGNITE-13753:
---
Merged to master.
> Non-thread-safe collection is used for the list of registered MBeans in
> JmxMetricExporterSpi
>
>
> Key: IGNITE-13753
> URL: https://issues.apache.org/jira/browse/IGNITE-13753
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{MetricManager}} registry creation and remove listeners can be invoked
> concurrently (the only synchronization is via {{map.computeIfAbsent}} which
> provides key-level granularity.
> As a result, some of the beans are lost and I get an occasional assertion on
> {code}
> boolean rmv = mBeans.remove(mbeanName);
> assert rmv;
> {code}
> Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13753:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Non-thread-safe collection is used for the list of registered MBeans in
> JmxMetricExporterSpi
>
>
> Key: IGNITE-13753
> URL: https://issues.apache.org/jira/browse/IGNITE-13753
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{MetricManager}} registry creation and remove listeners can be invoked
> concurrently (the only synchronization is via {{map.computeIfAbsent}} which
> provides key-level granularity.
> As a result, some of the beans are lost and I get an occasional assertion on
> {code}
> boolean rmv = mBeans.remove(mbeanName);
> assert rmv;
> {code}
> Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238830#comment-17238830
]
Alexey Goncharuk commented on IGNITE-13753:
---
[~agura] [~nizhikov] can you take a look at the changes? The tests are failing
in master as well (.NET inspections are related to TC update and Cache5 fails
with some random errors - I will try to investigate and file a separate
ticket(s)).
> Non-thread-safe collection is used for the list of registered MBeans in
> JmxMetricExporterSpi
>
>
> Key: IGNITE-13753
> URL: https://issues.apache.org/jira/browse/IGNITE-13753
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{MetricManager}} registry creation and remove listeners can be invoked
> concurrently (the only synchronization is via {{map.computeIfAbsent}} which
> provides key-level granularity.
> As a result, some of the beans are lost and I get an occasional assertion on
> {code}
> boolean rmv = mBeans.remove(mbeanName);
> assert rmv;
> {code}
> Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13753:
--
Fix Version/s: 2.10
> Non-thread-safe collection is used for the list of registered MBeans in
> JmxMetricExporterSpi
>
>
> Key: IGNITE-13753
> URL: https://issues.apache.org/jira/browse/IGNITE-13753
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
>
> {{MetricManager}} registry creation and remove listeners can be invoked
> concurrently (the only synchronization is via {{map.computeIfAbsent}} which
> provides key-level granularity.
> As a result, some of the beans are lost and I get an occasional assertion on
> {code}
> boolean rmv = mBeans.remove(mbeanName);
> assert rmv;
> {code}
> Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
[
https://issues.apache.org/jira/browse/IGNITE-13753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-13753:
-
Assignee: Alexey Goncharuk
> Non-thread-safe collection is used for the list of registered MBeans in
> JmxMetricExporterSpi
>
>
> Key: IGNITE-13753
> URL: https://issues.apache.org/jira/browse/IGNITE-13753
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>
> {{MetricManager}} registry creation and remove listeners can be invoked
> concurrently (the only synchronization is via {{map.computeIfAbsent}} which
> provides key-level granularity.
> As a result, some of the beans are lost and I get an occasional assertion on
> {code}
> boolean rmv = mBeans.remove(mbeanName);
> assert rmv;
> {code}
> Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13753) Non-thread-safe collection is used for the list of registered MBeans in JmxMetricExporterSpi
Alexey Goncharuk created IGNITE-13753:
-
Summary: Non-thread-safe collection is used for the list of
registered MBeans in JmxMetricExporterSpi
Key: IGNITE-13753
URL: https://issues.apache.org/jira/browse/IGNITE-13753
Project: Ignite
Issue Type: Bug
Reporter: Alexey Goncharuk
{{MetricManager}} registry creation and remove listeners can be invoked
concurrently (the only synchronization is via {{map.computeIfAbsent}} which
provides key-level granularity.
As a result, some of the beans are lost and I get an occasional assertion on
{code}
boolean rmv = mBeans.remove(mbeanName);
assert rmv;
{code}
Changing the collection to a synchronized list should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13190) Core defragmentation functions
[ https://issues.apache.org/jira/browse/IGNITE-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17238158#comment-17238158 ] Alexey Goncharuk commented on IGNITE-13190: --- Ivan, thank you for your effort! Now the PR looks good to me. > Core defragmentation functions > -- > > Key: IGNITE-13190 > URL: https://issues.apache.org/jira/browse/IGNITE-13190 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Ivan Bessonov >Priority: Major > Labels: IEP-47 > Time Spent: 8h 20m > Remaining Estimate: 0h > > The following set of functions covering defragmentation happy-case needed: > * Initialization of defragmentation manager when node is started in > maintenance mode. > * Information about partition files is gathered by defrag mgr. > * For each partition file corresponding file of defragmented partition is > created and initialized. > * Keys are transferred from old partitions to new partitions. > * Checkpointer is aware of new partition files and flushes defragmented > memory to new partition files. > > No fault-tolerance code nor index defragmentation mappings are needed in this > task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13745) Add release notes for streaming extensions release 1.0.0
[ https://issues.apache.org/jira/browse/IGNITE-13745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk resolved IGNITE-13745. --- Resolution: Fixed Added release notes for streaming extensions. > Add release notes for streaming extensions release 1.0.0 > > > Key: IGNITE-13745 > URL: https://issues.apache.org/jira/browse/IGNITE-13745 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexey Goncharuk >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13745) Add release notes for streaming extensions release 1.0.0
Alexey Goncharuk created IGNITE-13745: - Summary: Add release notes for streaming extensions release 1.0.0 Key: IGNITE-13745 URL: https://issues.apache.org/jira/browse/IGNITE-13745 Project: Ignite Issue Type: Sub-task Reporter: Alexey Goncharuk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13701) SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of columns and content
[
https://issues.apache.org/jira/browse/IGNITE-13701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232835#comment-17232835
]
Alexey Goncharuk commented on IGNITE-13701:
---
LGTM
> SQL Indexes,Tables and Schemas views in IEP-35 changed amount, order of
> columns and content
> ---
>
> Key: IGNITE-13701
> URL: https://issues.apache.org/jira/browse/IGNITE-13701
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://issues.apache.org/jira/browse/IGNITE-12213 broke backward
> compatibility:
> * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
> {{INDEXES}} view.
> * {{CACHE_GROUP_ID}} and {{CACHE_GROUP_NAME}} columns was removed from the
> {{TABLES}} view.
> * {{SCHEMA_NAME}} column was renamed to {{NAME}} for the {{SCHEMAS}} view.
> * {{PREDEFINED}} column was added to the {{SCHEMAS}} view.
> Default columns order was changed.
> Also content of {{SCHEMAS}} view has changed in a wrong way: now view
> contains proxy indexes (it is simply wrapper and implementation detail) and
> indexes for cache key displays as {{PK}} index (it is incorrect, because
> {{PK}} index could be only for table and this kind of indexes is
> implementation detail).
> This behavior should be replaced by previous one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12489) Error during purges by expiration: Unknown page type
[
https://issues.apache.org/jira/browse/IGNITE-12489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232646#comment-17232646
]
Alexey Goncharuk commented on IGNITE-12489:
---
The changes look good to me, thanks for tackling this issue!
> Error during purges by expiration: Unknown page type
>
>
> Key: IGNITE-12489
> URL: https://issues.apache.org/jira/browse/IGNITE-12489
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.7.6
>Reporter: Ruslan Kamashev
>Assignee: Nikita Tolstunov
>Priority: Blocker
> Fix For: 2.10
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{*logger*}}
> {code:java}
> org.apache.ignite.internal.processors.cache.GridCacheIoManager
> {code}
> {{*message*}}
> {code:java}
> Failed to process message [senderId=969d56ba-4b46-40cf-886e-ac445cf6a95d,
> messageType=class
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicUpdateRequest]{code}
> {{*thread*}}
> {code:java}
> sys-stripe-19-#20{code}
> {{*trace*}}
> {code:java}
> java.lang.IllegalStateException: Unknown page type: 1 pageId: 00010303117d
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.io(BPlusTree.java:5058)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$200(BPlusTree.java:90)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AbstractForwardCursor.nextPage(BPlusTree.java:5330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$ForwardCursor.next(BPlusTree.java:5566)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2232)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2157)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:845)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:207)
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:888)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessageProcessed(GridCacheIoManager.java:1103)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1076)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Dec 23, 2019 @ 18:28:28.457 {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Description: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). Also, need to add support for skipping writing nullmaps (use the flags bit). was: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). > Also, need to add support for skipping writing nullmaps (use the flags bit). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
[ https://issues.apache.org/jira/browse/IGNITE-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13693: -- Description: After the IEP discussion, we agreed to extend the schema identifier size to 2 bytes and introduce flags byte to support tombstones. Need to implement these enhancements in the Tuple and TupleAssembler. > Add flags field with tombstone support, update schema size to 2 bytes > - > > Key: IGNITE-13693 > URL: https://issues.apache.org/jira/browse/IGNITE-13693 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > After the IEP discussion, we agreed to extend the schema identifier size to 2 > bytes and introduce flags byte to support tombstones. Need to implement these > enhancements in the Tuple and TupleAssembler. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
Alexey Goncharuk created IGNITE-13693: - Summary: Add flags field with tombstone support, update schema size to 2 bytes Key: IGNITE-13693 URL: https://issues.apache.org/jira/browse/IGNITE-13693 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Description: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). was:The nullmap is currently always written to the tuple layout. However, it can be fully omitted for schemas where all columns are non-null - this saves both a little space and runtime for offsets folding. > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Summary: Upgrade nullmap to null-defaults map (was: Omit nullmap where possible) > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout. However, it can > be fully omitted for schemas where all columns are non-null - this saves both > a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13670) Omit nullmap where possible
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Labels: iep-54 ignite-3 (was: ) > Omit nullmap where possible > --- > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout. However, it can > be fully omitted for schemas where all columns are non-null - this saves both > a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13669) Implement date native types
[ https://issues.apache.org/jira/browse/IGNITE-13669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13669: -- Labels: iep-54 ignite-3 (was: ) > Implement date native types > > > Key: IGNITE-13669 > URL: https://issues.apache.org/jira/browse/IGNITE-13669 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > Besides the types themselves, it may be beneficial to provide date/time field > extraction methods so that they can be read without object creation. The > layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13667) Add schema columns relocation table to map from user order to system order
[
https://issues.apache.org/jira/browse/IGNITE-13667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13667:
--
Labels: iep-54 ignite-3 (was: )
> Add schema columns relocation table to map from user order to system order
> --
>
> Key: IGNITE-13667
> URL: https://issues.apache.org/jira/browse/IGNITE-13667
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: iep-54, ignite-3
>
> When a schema is defined, the key chunk columns and value chunk columns are
> sorted so that fixlen columns go first and varlen columns go second, so the
> sorted column order differs from the order of the user-defined columns.
> We need to add a simple relocation table which is a permutation of indices
> {{[0..n)}}, so that an internal column order for user index {{n}} is
> {{relocationTbl[n]}}.
> NB: the tuple assembler will still need to access the internal sorted order
> for proper tuple assembly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13668:
--
Labels: iep-54 ignite-3 (was: )
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Labels: iep-54, ignite-3
>
> Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
> the varlong style (so that Number(4) can be mapped to integer and Number(8)
> can be mapped to long during (de)serialization). Larger numbers can be
> represented as {{BigInteger}}. The Number( n ) is a varlen type, so it will
> take two additional bytes in the varlen table, so types smaller than
> Number(2) are better represented by {{byte}} and {{short}} types as their
> fixlen encoding takes exactly 1 and 2 bytes respectively.
> Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13670) Omit nullmap where possible
Alexey Goncharuk created IGNITE-13670: - Summary: Omit nullmap where possible Key: IGNITE-13670 URL: https://issues.apache.org/jira/browse/IGNITE-13670 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk The nullmap is currently always written to the tuple layout. However, it can be fully omitted for schemas where all columns are non-null - this saves both a little space and runtime for offsets folding. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13669) Implement date native types
Alexey Goncharuk created IGNITE-13669: - Summary: Implement date native types Key: IGNITE-13669 URL: https://issues.apache.org/jira/browse/IGNITE-13669 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Besides the types themselves, it may be beneficial to provide date/time field extraction methods so that they can be read without object creation. The layout is described in the IEP. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13668) Implement Number(n) and Decimal native types
Alexey Goncharuk created IGNITE-13668:
-
Summary: Implement Number(n) and Decimal native types
Key: IGNITE-13668
URL: https://issues.apache.org/jira/browse/IGNITE-13668
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
Number(n) is an {{n}}-bytes two-complement integer signed value encoded in the
varlong style (so that Number(4) can be mapped to integer and Number(8) can be
mapped to long during (de)serialization). Larger numbers can be represented as
{{BigInteger}}. The Number(n) is a varlen type, so it will take two additional
bytes in the varlen table, so types smaller than Number(2) are better
represented by {{byte}} and {{short}} types as their fixlen encoding takes
exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13668) Implement Number(n) and Decimal native types
[
https://issues.apache.org/jira/browse/IGNITE-13668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-13668:
--
Description:
Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
the varlong style (so that Number(4) can be mapped to integer and Number(8) can
be mapped to long during (de)serialization). Larger numbers can be represented
as {{BigInteger}}. The Number( n ) is a varlen type, so it will take two
additional bytes in the varlen table, so types smaller than Number(2) are
better represented by {{byte}} and {{short}} types as their fixlen encoding
takes exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
was:
Number(n) is an {{n}}-bytes two-complement integer signed value encoded in the
varlong style (so that Number(4) can be mapped to integer and Number(8) can be
mapped to long during (de)serialization). Larger numbers can be represented as
{{BigInteger}}. The Number(n) is a varlen type, so it will take two additional
bytes in the varlen table, so types smaller than Number(2) are better
represented by {{byte}} and {{short}} types as their fixlen encoding takes
exactly 1 and 2 bytes respectively.
Decimal is a direct mapping to BigDecimal value.
> Implement Number(n) and Decimal native types
>
>
> Key: IGNITE-13668
> URL: https://issues.apache.org/jira/browse/IGNITE-13668
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
>
> Number( n ) is an {{n}}-bytes two-complement integer signed value encoded in
> the varlong style (so that Number(4) can be mapped to integer and Number(8)
> can be mapped to long during (de)serialization). Larger numbers can be
> represented as {{BigInteger}}. The Number( n ) is a varlen type, so it will
> take two additional bytes in the varlen table, so types smaller than
> Number(2) are better represented by {{byte}} and {{short}} types as their
> fixlen encoding takes exactly 1 and 2 bytes respectively.
> Decimal is a direct mapping to BigDecimal value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13667) Add schema columns relocation table to map from user order to system order
Alexey Goncharuk created IGNITE-13667:
-
Summary: Add schema columns relocation table to map from user
order to system order
Key: IGNITE-13667
URL: https://issues.apache.org/jira/browse/IGNITE-13667
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
When a schema is defined, the key chunk columns and value chunk columns are
sorted so that fixlen columns go first and varlen columns go second, so the
sorted column order differs from the order of the user-defined columns.
We need to add a simple relocation table which is a permutation of indices
{{[0..n)}}, so that an internal column order for user index {{n}} is
{{relocationTbl[n]}}.
NB: the tuple assembler will still need to access the internal sorted order for
proper tuple assembly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13618) Provide generated and reflection-based class (de)serializers
[ https://issues.apache.org/jira/browse/IGNITE-13618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13618: -- Issue Type: Improvement (was: Task) > Provide generated and reflection-based class (de)serializers > > > Key: IGNITE-13618 > URL: https://issues.apache.org/jira/browse/IGNITE-13618 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexey Goncharuk >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13617) Provide an initial implementation for assembling/reading tuples for a given schema
[ https://issues.apache.org/jira/browse/IGNITE-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13617: -- Parent: (was: IGNITE-13616) Issue Type: Improvement (was: Sub-task) > Provide an initial implementation for assembling/reading tuples for a given > schema > -- > > Key: IGNITE-13617 > URL: https://issues.apache.org/jira/browse/IGNITE-13617 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
