[jira] [Commented] (IGNITE-16043) AssertionError in BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17455019#comment-17455019
]
Ignite TC Bot commented on IGNITE-16043:
{panel:title=Branch: [pull/9637/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9637/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Binary Objects{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6309764]]
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalSelfTest.testGetFieldForNotAssignedVal[useBinaryArrays
= true] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalNonCompactSelfTest.testGetFieldForNotAssignedVal[useBinaryArrays
= false] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalNonCompactSelfTest.testGetFieldForNotAssignedVal[useBinaryArrays
= true] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalSelfTest.testGetFieldForNotAssignedVal[useBinaryArrays
= false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6309849buildTypeId=IgniteTests24Java8_RunAll]
> AssertionError in BinaryObjectBuilder
> -
>
> Key: IGNITE-16043
> URL: https://issues.apache.org/jira/browse/IGNITE-16043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.11
>Reporter: Ilya Kazakov
>Assignee: Andrey Belyaev
>Priority: Minor
>
> AssertionError in this code (run java with -ea key):
> {{}}
>
>
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObjectBuilder;
> public class Ae {
> public static void main(String[] args) {
> try(Ignite ignite = Ignition.start()){
> BinaryObjectBuilder builder =
> ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
> String f = builder.getField("field");
> System.out.println(f);
> }
> }
> } {code}
>
>
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
> at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16077) Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
[
https://issues.apache.org/jira/browse/IGNITE-16077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16077:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
> --
>
> Key: IGNITE-16077
> URL: https://issues.apache.org/jira/browse/IGNITE-16077
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> For example:
> {noformat}
> create table t(d date)
> create index my_index on t(d);
> insert into t values (date '2021-01-01')
> insert into t values (date '2021-01-02')
> select * from t where d = date '2021-01-01'
> {noformat}
> Fails with:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> wrap object into H2 Value. java.lang.Integer cannot be cast to java.sql.Date
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.H2ValueWrapperMixin.wrapToValue(H2ValueWrapperMixin.java:37)
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.DateIndexKey.(DateIndexKey.java:31)
> at
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory.wrap(IndexKeyFactory.java:95)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:58)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.AbstractIndexScan.iterator(AbstractIndexScan.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.iterator(IndexScan.java:145)
> {noformat}
> We should convert DATE/TIME/TIMESTAMP from internal presentation (see
> {{TypeUtils.fromInternal()}}) before creating {{IndexRow}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16077) Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
[
https://issues.apache.org/jira/browse/IGNITE-16077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16077:
---
Labels: calcite2-required calcite3-required (was: )
> Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
> --
>
> Key: IGNITE-16077
> URL: https://issues.apache.org/jira/browse/IGNITE-16077
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> For example:
> {noformat}
> create table t(d date)
> create index my_index on t(d);
> insert into t values (date '2021-01-01')
> insert into t values (date '2021-01-02')
> select * from t where d = date '2021-01-01'
> {noformat}
> Fails with:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> wrap object into H2 Value. java.lang.Integer cannot be cast to java.sql.Date
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.H2ValueWrapperMixin.wrapToValue(H2ValueWrapperMixin.java:37)
> at
> org.apache.ignite.internal.processors.query.h2.index.keys.DateIndexKey.(DateIndexKey.java:31)
> at
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory.wrap(IndexKeyFactory.java:95)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:173)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:58)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.AbstractIndexScan.iterator(AbstractIndexScan.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.iterator(IndexScan.java:145)
> {noformat}
> We should convert DATE/TIME/TIMESTAMP from internal presentation (see
> {{TypeUtils.fromInternal()}}) before creating {{IndexRow}}.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16077) Calcite engine. Index on DATE/TIME/TIMESTAMP fields cannot be used
Aleksey Plekhanov created IGNITE-16077:
--
Summary: Calcite engine. Index on DATE/TIME/TIMESTAMP fields
cannot be used
Key: IGNITE-16077
URL: https://issues.apache.org/jira/browse/IGNITE-16077
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
For example:
{noformat}
create table t(d date)
create index my_index on t(d);
insert into t values (date '2021-01-01')
insert into t values (date '2021-01-02')
select * from t where d = date '2021-01-01'
{noformat}
Fails with:
{noformat}
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to wrap
object into H2 Value. java.lang.Integer cannot be cast to java.sql.Date
at
org.apache.ignite.internal.processors.query.h2.index.keys.H2ValueWrapperMixin.wrapToValue(H2ValueWrapperMixin.java:37)
at
org.apache.ignite.internal.processors.query.h2.index.keys.DateIndexKey.(DateIndexKey.java:31)
at
org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory.wrap(IndexKeyFactory.java:95)
at
org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:173)
at
org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.row2indexRow(IndexScan.java:58)
at
org.apache.ignite.internal.processors.query.calcite.exec.AbstractIndexScan.iterator(AbstractIndexScan.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.IndexScan.iterator(IndexScan.java:145)
{noformat}
We should convert DATE/TIME/TIMESTAMP from internal presentation (see
{{TypeUtils.fromInternal()}}) before creating {{IndexRow}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16076) .NET: Remove duplicate test class
[ https://issues.apache.org/jira/browse/IGNITE-16076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-16076: Assignee: Nikolay Izhikov > .NET: Remove duplicate test class > - > > Key: IGNITE-16076 > URL: https://issues.apache.org/jira/browse/IGNITE-16076 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Trivial > > PlatformBinarizable defined two times in tests. > This means when using SimpleNameMapper two different classes messed up during > tests execution. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16076) .NET: Remove duplicate test class
Nikolay Izhikov created IGNITE-16076: Summary: .NET: Remove duplicate test class Key: IGNITE-16076 URL: https://issues.apache.org/jira/browse/IGNITE-16076 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov PlatformBinarizable defined two times in tests. This means when using SimpleNameMapper two different classes messed up during tests execution. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16075) Calcite engine. Support UUID data type
Aleksey Plekhanov created IGNITE-16075:
--
Summary: Calcite engine. Support UUID data type
Key: IGNITE-16075
URL: https://issues.apache.org/jira/browse/IGNITE-16075
Project: Ignite
Issue Type: New Feature
Reporter: Aleksey Plekhanov
Currently, UUID columns can be selected or even filtered if a table containing
such a column is created not by the Calcite-based SQL engine (for example via
cache API using {{@QuerySqlField}} field annotation).
But we cannot use it in DDL:
{noformat}
CREATE TABLE t (id UUID)
{noformat}
Or cast:
{noformat}
SELECT CAST(id AS UUID)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[ https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454984#comment-17454984 ] Amelchev Nikita commented on IGNITE-16070: -- [~xtern], LGTM. Merged to the master. Thanks for the contribution! > Move the executor service used for re-encryption into the pool processor. > - > > Key: IGNITE-16070 > URL: https://issues.apache.org/jira/browse/IGNITE-16070 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Move the executor service used for re-encryption into the pool processor to > enable monitoring. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[ https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16070: - Fix Version/s: 2.13 > Move the executor service used for re-encryption into the pool processor. > - > > Key: IGNITE-16070 > URL: https://issues.apache.org/jira/browse/IGNITE-16070 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Move the executor service used for re-encryption into the pool processor to > enable monitoring. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[ https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454977#comment-17454977 ] Pavel Pereslegin commented on IGNITE-16070: --- [~NSAmelchev], could you take a look at these changes? > Move the executor service used for re-encryption into the pool processor. > - > > Key: IGNITE-16070 > URL: https://issues.apache.org/jira/browse/IGNITE-16070 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Move the executor service used for re-encryption into the pool processor to > enable monitoring. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[
https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454972#comment-17454972
]
Ignite TC Bot commented on IGNITE-16070:
{panel:title=Branch: [pull/9636/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9636/head] Base: [master] : New Tests
(30)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6309924]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=false,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=false, walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/17792118@75de29c0]
- PASSED{color}
... and 19 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6309949buildTypeId=IgniteTests24Java8_RunAll]
> Move the executor service used for re-encryption into the pool processor.
> -
>
> Key: IGNITE-16070
> URL: https://issues.apache.org/jira/browse/IGNITE-16070
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Move the executor service used for re-encryption into the pool processor to
> enable monitoring.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16074) [TC Bot] Last selected TC Branch is displayed instead of referenced one
[ https://issues.apache.org/jira/browse/IGNITE-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454849#comment-17454849 ] Dmitry Pavlov commented on IGNITE-16074: Please check results at https://tcbot2.sbt-ignite-dev.ru/ > [TC Bot] Last selected TC Branch is displayed instead of referenced one > --- > > Key: IGNITE-16074 > URL: https://issues.apache.org/jira/browse/IGNITE-16074 > Project: Ignite > Issue Type: Bug >Reporter: Shishkov Ilya >Assignee: Dmitry Pavlov >Priority: Minor > > This is because of chages in the TC UI. > Old UI href redirects to the new one, but branch is pre-selected and > displayed incorrectly > E.g. > https://ci2.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2226638663812022361=ignite-2.11=testDetails > https://ci2.ignite.apache.org/test/-2226638663812022361?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16074) [TC Bot] Last selected TC Branch is displayed instead of referenced one
[ https://issues.apache.org/jira/browse/IGNITE-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov resolved IGNITE-16074. Resolution: Fixed https://github.com/apache/ignite-teamcity-bot/commit/47d952786e4fc87da522764b1ce80c8f833dcac5 > [TC Bot] Last selected TC Branch is displayed instead of referenced one > --- > > Key: IGNITE-16074 > URL: https://issues.apache.org/jira/browse/IGNITE-16074 > Project: Ignite > Issue Type: Bug >Reporter: Shishkov Ilya >Assignee: Dmitry Pavlov >Priority: Minor > > This is because of chages in the TC UI. > Old UI href redirects to the new one, but branch is pre-selected and > displayed incorrectly > E.g. > https://ci2.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2226638663812022361=ignite-2.11=testDetails > https://ci2.ignite.apache.org/test/-2226638663812022361?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16074) [TC Bot] Last selected TC Branch is displayed instead of referenced one
[ https://issues.apache.org/jira/browse/IGNITE-16074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16074: --- Ignite Flags: (was: Docs Required,Release Notes Required) > [TC Bot] Last selected TC Branch is displayed instead of referenced one > --- > > Key: IGNITE-16074 > URL: https://issues.apache.org/jira/browse/IGNITE-16074 > Project: Ignite > Issue Type: Bug >Reporter: Shishkov Ilya >Assignee: Dmitry Pavlov >Priority: Minor > > This is because of chages in the TC UI. > Old UI href redirects to the new one, but branch is pre-selected and > displayed incorrectly > E.g. > https://ci2.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2226638663812022361=ignite-2.11=testDetails > https://ci2.ignite.apache.org/test/-2226638663812022361?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16074) [TC Bot] Last selected TC Branch is displayed instead of referenced one
Dmitry Pavlov created IGNITE-16074: -- Summary: [TC Bot] Last selected TC Branch is displayed instead of referenced one Key: IGNITE-16074 URL: https://issues.apache.org/jira/browse/IGNITE-16074 Project: Ignite Issue Type: Bug Reporter: Shishkov Ilya Assignee: Dmitry Pavlov This is because of chages in the TC UI. Old UI href redirects to the new one, but branch is pre-selected and displayed incorrectly E.g. https://ci2.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2226638663812022361=ignite-2.11=testDetails https://ci2.ignite.apache.org/test/-2226638663812022361?currentProjectId=IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16057) Second read of array field from BinaryObject fail
[
https://issues.apache.org/jira/browse/IGNITE-16057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454801#comment-17454801
]
Ignite TC Bot commented on IGNITE-16057:
{panel:title=Branch: [pull/9630/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9630/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Binary Objects{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6310012]]
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalSelfTest.testArrayFieldSeveralRead[useBinaryArrays
= true] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalNonCompactSelfTest.testArrayFieldSeveralRead[useBinaryArrays
= false] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalNonCompactSelfTest.testArrayFieldSeveralRead[useBinaryArrays
= true] - PASSED{color}
* {color:#013220}IgniteBinaryObjectsTestSuite:
BinaryObjectBuilderAdditionalSelfTest.testArrayFieldSeveralRead[useBinaryArrays
= false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6310097buildTypeId=IgniteTests24Java8_RunAll]
> Second read of array field from BinaryObject fail
> -
>
> Key: IGNITE-16057
> URL: https://issues.apache.org/jira/browse/IGNITE-16057
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Vladimir Ermakov
>Priority: Blocker
> Labels: ise
>
> Second read of array field fail and read some garbage.
> This happen because when object read with handle stream position don't move
> to the end of already deserialized object.
> So second array element is just random bytes from the middle of the stream.
> BinaryObjectBuilderAdditionalSelfTest
> {code:java}
> /** */
> @Test
> public void testArrayFieldSeveralRead() throws Exception {
> try (Ignite ignite = startGrid(1)) {
> TestClass1[] expArr = new TestClass1[] {new TestClass1(), new
> TestClass1()};
> BinaryObject arrObj = ignite.binary().toBinary(new
> TestClsWithArray(expArr));
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> arrObj =
> ignite.binary().builder(TestClsWithArray.class.getName()).setField("arr",
> expArr).build();
> for (int i = 0; i < 10; i++)
> Assert.assertArrayEquals(i + " iteration", expArr,
> PlatformUtils.unwrapBinariesInArray(arrObj.field("arr")));
> }
> finally {
> clearBinaryMeta();
> }
> }
> /** Test class with array. */
> public static class TestClsWithArray {
> /** */
> private final Object[] arr;
> /** */
> public TestClsWithArray(TestClass1[] arr) {
> this.arr = arr;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16058) Create a JUnit annotation to load test parameters from a static variable
[
https://issues.apache.org/jira/browse/IGNITE-16058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-16058:
Fix Version/s: 3.0.0-alpha4
> Create a JUnit annotation to load test parameters from a static variable
> -
>
> Key: IGNITE-16058
> URL: https://issues.apache.org/jira/browse/IGNITE-16058
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit Parameterized tests allow loading test parameters from a static method
> (see the {{MethodSource}} annotation), but not from a static variable. This
> is, however, is possible to do manually. [This
> articale|https://www.baeldung.com/parameterized-tests-junit-5#8-custom-annotation]
> can serve as a starting point.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16058) Create a JUnit annotation to load test parameters from a static variable
[
https://issues.apache.org/jira/browse/IGNITE-16058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454773#comment-17454773
]
Semyon Danilov edited comment on IGNITE-16058 at 12/7/21, 5:33 PM:
---
LGTM. Merged to the main branch, thank you for your contribution!
was (Author: sdanilov):
Merged to the main branch, thank you for your contribution!
> Create a JUnit annotation to load test parameters from a static variable
> -
>
> Key: IGNITE-16058
> URL: https://issues.apache.org/jira/browse/IGNITE-16058
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit Parameterized tests allow loading test parameters from a static method
> (see the {{MethodSource}} annotation), but not from a static variable. This
> is, however, is possible to do manually. [This
> articale|https://www.baeldung.com/parameterized-tests-junit-5#8-custom-annotation]
> can serve as a starting point.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16058) Create a JUnit annotation to load test parameters from a static variable
[
https://issues.apache.org/jira/browse/IGNITE-16058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454773#comment-17454773
]
Semyon Danilov commented on IGNITE-16058:
-
Merged to the main branch, thank you for your contribution!
> Create a JUnit annotation to load test parameters from a static variable
> -
>
> Key: IGNITE-16058
> URL: https://issues.apache.org/jira/browse/IGNITE-16058
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JUnit Parameterized tests allow loading test parameters from a static method
> (see the {{MethodSource}} annotation), but not from a static variable. This
> is, however, is possible to do manually. [This
> articale|https://www.baeldung.com/parameterized-tests-junit-5#8-custom-annotation]
> can serve as a starting point.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15824) SSLContextFactory uses wrong default key algorithm
[ https://issues.apache.org/jira/browse/IGNITE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454746#comment-17454746 ] Roman Poslavski commented on IGNITE-15824: -- Agree. ClientConfiguration.setSslKeyAlgorithm(KeyManagerFactory.getDefaultAlgorithm()) solves this and we have IbmX509 as KeyManager now on. > SSLContextFactory uses wrong default key algorithm > -- > > Key: IGNITE-15824 > URL: https://issues.apache.org/jira/browse/IGNITE-15824 > Project: Ignite > Issue Type: Bug >Reporter: Moti Nisenson-Ken >Priority: Minor > > SSLContextFactory currently tries to resolve the default key algorithm by > first looking up > ssl.KeyManagerFactory.algorithm. This is incorrect, as by default it may not > be initialized. For example, if running Ignite on IBM java, it will fall > through to the default path and try SunX509 which is not present. The correct > behavior should be to call KeyManagerFactory.getDefaultAlgorithm() which > should always be correct. > > Minor - since can be worked around. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15824) SSLContextFactory uses wrong default key algorithm
[ https://issues.apache.org/jira/browse/IGNITE-15824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454746#comment-17454746 ] Roman Poslavski edited comment on IGNITE-15824 at 12/7/21, 4:49 PM: Agree. ClientConfiguration.setSslKeyAlgorithm(KeyManagerFactory.getDefaultAlgorithm()) solves this and we have IbmX509 as KeyManagerFactory now on. was (Author: JIRAUSER281348): Agree. ClientConfiguration.setSslKeyAlgorithm(KeyManagerFactory.getDefaultAlgorithm()) solves this and we have IbmX509 as KeyManager now on. > SSLContextFactory uses wrong default key algorithm > -- > > Key: IGNITE-15824 > URL: https://issues.apache.org/jira/browse/IGNITE-15824 > Project: Ignite > Issue Type: Bug >Reporter: Moti Nisenson-Ken >Priority: Minor > > SSLContextFactory currently tries to resolve the default key algorithm by > first looking up > ssl.KeyManagerFactory.algorithm. This is incorrect, as by default it may not > be initialized. For example, if running Ignite on IBM java, it will fall > through to the default path and try SunX509 which is not present. The correct > behavior should be to call KeyManagerFactory.getDefaultAlgorithm() which > should always be correct. > > Minor - since can be worked around. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14971) Thin 3.0: Add RecordView
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14971: Description: Implement RecordView with mapping to user-defined POJOs: * ClientTable.recordView should return ClientRecordView * Support identity mapper was:Implement RecordView with mapping to user-defined POJOs. > Thin 3.0: Add RecordView > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha4 > > > Implement RecordView with mapping to user-defined POJOs: > * ClientTable.recordView should return ClientRecordView > * Support identity mapper -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14971) Thin 3.0: Add RecordView
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454694#comment-17454694 ] Pavel Tupitsyn commented on IGNITE-14971: - Let's start with implementing the RecordView interface with POJO support and 1-to-1 field/column mapping. I've updated the ticket accordingly. > Thin 3.0: Add RecordView > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha4 > > > We need to implement basic key-value API for java thin client in 3.0. Maybe > this task should involve creating an IEP and discussion on the dev list. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14971) Thin 3.0: Add RecordView
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14971: Description: Implement RecordView with mapping to user-defined POJOs. (was: We need to implement basic key-value API for java thin client in 3.0. Maybe this task should involve creating an IEP and discussion on the dev list.) > Thin 3.0: Add RecordView > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha4 > > > Implement RecordView with mapping to user-defined POJOs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14971) Thin 3.0: Add RecordView
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14971: Summary: Thin 3.0: Add RecordView (was: Implement key-value API for java thin client for 3.0) > Thin 3.0: Add RecordView > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha4 > > > We need to implement basic key-value API for java thin client in 3.0. Maybe > this task should involve creating an IEP and discussion on the dev list. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15940) Class parsing API and simple class descriptor format
[ https://issues.apache.org/jira/browse/IGNITE-15940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454682#comment-17454682 ] Semyon Danilov commented on IGNITE-15940: - Visa: https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6309997 > Class parsing API and simple class descriptor format > > > Key: IGNITE-15940 > URL: https://issues.apache.org/jira/browse/IGNITE-15940 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > To enable User Object Serialization we need to define class descriptor format > and API for parsing java classes into this format. > As the first step, we consider simple cases - Serializable/Externalizable > classes with primitive or Serializable/Externalizable fields. > Look here for reference: > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#class-descriptor -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454520#comment-17454520
]
Ilya Shishkov edited comment on IGNITE-15969 at 12/7/21, 2:22 PM:
--
I decided to do not add extra tests, because in my opinion existing test
provide necessary test coverage after small configuration fixes.
was (Author: shishkovilja):
I decided to do not add extra tests, because in my opinion existing ones after
configuration fixes provide necessary test coverage.
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454520#comment-17454520
]
Ilya Shishkov edited comment on IGNITE-15969 at 12/7/21, 2:21 PM:
--
I decided to do not add extra tests, because in my opinion existing ones after
configuration fixes provide necessary test coverage.
was (Author: shishkovilja):
I did not add extra tests, because in my opinion existing ones provides test
coverage.
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15996) Node fails with "Node with the same ID was found" while connecting to the cluster in Docker container if previous container was stopped
[
https://issues.apache.org/jira/browse/IGNITE-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454638#comment-17454638
]
Ksenia Rybakova edited comment on IGNITE-15996 at 12/7/21, 2:09 PM:
The issue is reproduced only when running containers with default network
(without --network specified) and only on Windows systems. 3rd node can not
join the cluster even if 2nd node was not stopped.
All required ports (47100, 47500) are open at all nodes. Nodes can reach each
other. Netstat shows that TCP connection to TcpDiscoverySpi port is
established, but then for some reason it's reset.
TCP traffic analysis didn't make the reason of such behavior more clear.
As a workaround a user-defined network should be created before running
containers:
{noformat}
docker network create my-net{noformat}
and then run ignite containers at this network
{noformat}
docker run -d --net my-net apacheignite/ignite{noformat}
Docker doc reference [here|https://docs.docker.com/network/bridge/]
As a resolution suggest adding corresponding info to [documentation
|https://ignite.apache.org/docs/latest/installation/installing-using-docker](recommendation
to use user-defined network when running containers on Windows).
was (Author: krybakova):
The issue is reproduced only when running containers with default network
(without --network specified) and only on Windows systems. 3rd node can not
join the cluster even if 2nd node was not stopped.
As a workaround an user-defined network should be created before running
containers:
{noformat}
docker network create my-net{noformat}
and then run ignite containers at this network
{noformat}
docker run -d --net my-net apacheignite/ignite{noformat}
Docker doc reference [here|https://docs.docker.com/network/bridge/]
As a resolution suggest adding corresponding info to [documentation
|https://ignite.apache.org/docs/latest/installation/installing-using-docker](recommendation
to use user-defined network when running containers on Windows).
> Node fails with "Node with the same ID was found" while connecting to the
> cluster in Docker container if previous container was stopped
> ---
>
> Key: IGNITE-15996
> URL: https://issues.apache.org/jira/browse/IGNITE-15996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Windows 10, Docker+WSL2
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-47b5227b.0.log, ignite-c072978e.0.log,
> ignite-c62bc58e.0.log
>
>
> Node in Docker container fails to connect to existing cluster if previously
> connected node (container) was stopped:
> {noformat}
> [11:27:38,272][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1990)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@21f9277b],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> ... 11 more
> Caused by:
[jira] [Commented] (IGNITE-15569) Calcite. JOIN with USING fails.
[
https://issues.apache.org/jira/browse/IGNITE-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454669#comment-17454669
]
Aleksey Plekhanov commented on IGNITE-15569:
[~zstan], fix in Calcite is still in the discussion phase, I doubt it will be
available in the next Calcite release. Also, perhaps in Calcite only
{{expandStar}} method will be exposed as {{protected}}, in this case, an
additional fix in Ignite will be required. See discussion in CALCITE-4923.
> Calcite. JOIN with USING fails.
> ---
>
> Key: IGNITE-15569
> URL: https://issues.apache.org/jira/browse/IGNITE-15569
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1, 2)
> statement ok
> CREATE TABLE t2 (b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (2, 3)
> statement ok
> CREATE TABLE t3 (c INTEGER, d INTEGER)
> statement ok
> INSERT INTO t3 VALUES (3, 4)
> query
> SELECT * FROM t1 JOIN t2 USING (b) JOIN t3 USING (c) ORDER BY 1, 2, 3, 4;
>
> 1 2 3 4
> {noformat}
> fails with
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 7
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute(SqlValidatorImpl.java:7084)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:662)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:424)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4414)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3657)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:182)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16031) ScanQuery returns duplicated data
[ https://issues.apache.org/jira/browse/IGNITE-16031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454666#comment-17454666 ] Maksim Timonin commented on IGNITE-16031: - Hi [~slava.koptilin] ! I dived into SQL processing, and found that SQL uses a logic for reserving partitions for such cases. See `PartitionReservationManager`. I'd like to reuse the logic for IndexQuery, because it works pretty same way as SQL does: fetches data from indexes of required partitions. But, from other side, IndexQuery also shares processing with other cache queries, ScanQuery and TextQuery. So, it looks like I can bring logic of reserving for all cache queries types. AFAIU, it wasn't done before, because ScanQuery is used in most cases with specified partition only. Maybe you're aware of that, is there any other known issues why the preserving wasn't done for ScanQuery? > ScanQuery returns duplicated data > -- > > Key: IGNITE-16031 > URL: https://issues.apache.org/jira/browse/IGNITE-16031 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.11 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > ScanQuery doesn't sync topology version over different nodes, so when query > runs on different node it can run over different topologies and can have > duplicated primary partition. > > ``` > ignite = startGrids(1); > cache = ignite.cache(CACHE); > cache.put(1L, new Person(0, 1)); > cache.put(2L, new Person(1, 0)); > cache.put(3L, new Person(1, 1)); > ScanQuery qry = new ScanQuery(); > startGrid(nodesCnt); > Thread.sleep(10); > List> result = cache.query(qry).getAll(); > assertEquals(3, result.size()); // Sometimes fails, and returns duplicated > key=1 > ``` -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454657#comment-17454657
]
Ilya Shishkov edited comment on IGNITE-14913 at 12/7/21, 1:39 PM:
--
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are to turn on/off or show status of metrics:
# For all caches of a cluster.
# For a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
was (Author: shishkovilja):
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are:
# Turn on/of metrics for all caches.
# Turn on/of metrics for a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, enabling or disabling cache statistics is available only via
> IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status regexPattern
> {code}
> * regexPattern - regular expression for filtering caches (not cache groups)
> by their names. Caches with names satisfying the regular expression will be
> affected by the command. In case of an empty regex, the control script should
> finish execution with an error. If no matching caches are found, the control
> script should print a message about matching caches' absence.
> * enable - enables statistics for caches satisfying the 'regexPattern'.
> * disable - disables statistics for caches satisfying the 'regexPattern'.
> * status - prints current statistics status (enabled/disabled) for caches
> satisfying the 'regexPattern'.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454657#comment-17454657
]
Ilya Shishkov edited comment on IGNITE-14913 at 12/7/21, 1:37 PM:
--
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are:
# Turn on/of metrics for all caches.
# Turn on/of metrics for a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
was (Author: shishkovilja):
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are:
# Turn on/of metrics for all caches.
# Turn on/of metrics for defined list caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, enabling or disabling cache statistics is available only via
> IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status regexPattern
> {code}
> * regexPattern - regular expression for filtering caches (not cache groups)
> by their names. Caches with names satisfying the regular expression will be
> affected by the command. In case of an empty regex, the control script should
> finish execution with an error. If no matching caches are found, the control
> script should print a message about matching caches' absence.
> * enable - enables statistics for caches satisfying the 'regexPattern'.
> * disable - disables statistics for caches satisfying the 'regexPattern'.
> * status - prints current statistics status (enabled/disabled) for caches
> satisfying the 'regexPattern'.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454657#comment-17454657
]
Ilya Shishkov commented on IGNITE-14913:
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are:
# Turn on/of metrics for all caches.
# Turn on/of metrics for defined list caches.
IMHO, below syntax is more suitable:
{code}
--cache metrics enable|disable|status cache1[,..,cacheN]|--all-caches
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> Currently, enabling or disabling cache statistics is available only via
> IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status regexPattern
> {code}
> * regexPattern - regular expression for filtering caches (not cache groups)
> by their names. Caches with names satisfying the regular expression will be
> affected by the command. In case of an empty regex, the control script should
> finish execution with an error. If no matching caches are found, the control
> script should print a message about matching caches' absence.
> * enable - enables statistics for caches satisfying the 'regexPattern'.
> * disable - disables statistics for caches satisfying the 'regexPattern'.
> * status - prints current statistics status (enabled/disabled) for caches
> satisfying the 'regexPattern'.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15569) Calcite. JOIN with USING fails.
[
https://issues.apache.org/jira/browse/IGNITE-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454656#comment-17454656
]
Evgeny Stanilovsky commented on IGNITE-15569:
-
fix looks like functioning, but seems there is no appropriate fix in calcite
will be in reasonable time, or you plan to make also calcite fix ?
> Calcite. JOIN with USING fails.
> ---
>
> Key: IGNITE-15569
> URL: https://issues.apache.org/jira/browse/IGNITE-15569
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1, 2)
> statement ok
> CREATE TABLE t2 (b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (2, 3)
> statement ok
> CREATE TABLE t3 (c INTEGER, d INTEGER)
> statement ok
> INSERT INTO t3 VALUES (3, 4)
> query
> SELECT * FROM t1 JOIN t2 USING (b) JOIN t3 USING (c) ORDER BY 1, 2, 3, 4;
>
> 1 2 3 4
> {noformat}
> fails with
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 7
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute(SqlValidatorImpl.java:7084)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:662)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:424)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4414)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3657)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:182)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Priority: Major (was: Minor) > Test for keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Major > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Test for keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Minor > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for keys / values with locale differs from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Summary: Test for keys / values with locale differs from JVM one (was: Test for combinations of keys / values with locale different from JVM one) > Test for keys / values with locale differs from JVM one > --- > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Minor > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Summary: Test for keys / values with locale different from JVM one (was: Test for keys / values with locale differs from JVM one) > Test for keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Minor > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for combinations of keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Labels: ise (was: ) > Test for combinations of keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Major > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16073) Test for combinations of keys / values with locale different from JVM one
[ https://issues.apache.org/jira/browse/IGNITE-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-16073: --- Priority: Minor (was: Major) > Test for combinations of keys / values with locale different from JVM one > - > > Key: IGNITE-16073 > URL: https://issues.apache.org/jira/browse/IGNITE-16073 > Project: Ignite > Issue Type: Test >Reporter: Ilya Shishkov >Priority: Minor > Labels: ise > > Test should provide: > # Insert and try to get keys and values of all characters from Unicode. > # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, > UNICODE, Big5). > # Repeat the same for SQL tables and indexes. Check that everything works in > WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16073) Test for combinations of keys / values with locale different from JVM one
Ilya Shishkov created IGNITE-16073: -- Summary: Test for combinations of keys / values with locale different from JVM one Key: IGNITE-16073 URL: https://issues.apache.org/jira/browse/IGNITE-16073 Project: Ignite Issue Type: Test Reporter: Ilya Shishkov Test should provide: # Insert and try to get keys and values of all characters from Unicode. # Check it for different default.encoding of the JVM (eg., UTF-8, UTF-16, UNICODE, Big5). # Repeat the same for SQL tables and indexes. Check that everything works in WHERE, JOIN, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16031) ScanQuery returns duplicated data
[ https://issues.apache.org/jira/browse/IGNITE-16031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454640#comment-17454640 ] Vyacheslav Koptilin commented on IGNITE-16031: -- Hello [~timonin.maksim], Well, Scan queries (without partition pinning) do not properly work on unstable topology. This is a known limitation, unfortunately. A very similar problem has been reported here https://issues.apache.org/jira/browse/IGNITE-12591 > ScanQuery returns duplicated data > -- > > Key: IGNITE-16031 > URL: https://issues.apache.org/jira/browse/IGNITE-16031 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.11 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > > ScanQuery doesn't sync topology version over different nodes, so when query > runs on different node it can run over different topologies and can have > duplicated primary partition. > > ``` > ignite = startGrids(1); > cache = ignite.cache(CACHE); > cache.put(1L, new Person(0, 1)); > cache.put(2L, new Person(1, 0)); > cache.put(3L, new Person(1, 1)); > ScanQuery qry = new ScanQuery(); > startGrid(nodesCnt); > Thread.sleep(10); > List> result = cache.query(qry).getAll(); > assertEquals(3, result.size()); // Sometimes fails, and returns duplicated > key=1 > ``` -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15996) Node fails with "Node with the same ID was found" while connecting to the cluster in Docker container if previous container was stopped
[
https://issues.apache.org/jira/browse/IGNITE-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454638#comment-17454638
]
Ksenia Rybakova edited comment on IGNITE-15996 at 12/7/21, 1:03 PM:
The issue is reproduced only when running containers with default network
(without --network specified) and only on Windows systems. 3rd node can not
join the cluster even if 2nd node was not stopped.
As a workaround an user-defined network should be created before running
containers:
{noformat}
docker network create my-net{noformat}
and then run ignite containers at this network
{noformat}
docker run -d --net my-net apacheignite/ignite{noformat}
Docker doc reference [here|https://docs.docker.com/network/bridge/]
As a resolution suggest adding corresponding info to [documentation
|https://ignite.apache.org/docs/latest/installation/installing-using-docker](recommendation
to use user-defined network when running containers on Windows).
was (Author: krybakova):
The issue is reproduced only when running containers with default network
(without --network specified) and only on Windows systems. 3rd node can not
join the cluster even if 2nd node was not stopped.
As a workaround an user-defined network should be created before running
containers:
{{docker network create my-net}}
and then run ignite containers at this network
{{docker run -d --net my-net apacheignite/ignite}}
Docker doc reference
[[here|https://docs.docker.com/network/bridge/]|https://docs.docker.com/network/bridge/]
As a resolution suggest adding corresponding info to [documentation
|[https://ignite.apache.org/docs/latest/installation/installing-using-docker]](recommendation
to use user-defined network when running containers on Windows).
> Node fails with "Node with the same ID was found" while connecting to the
> cluster in Docker container if previous container was stopped
> ---
>
> Key: IGNITE-15996
> URL: https://issues.apache.org/jira/browse/IGNITE-15996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Windows 10, Docker+WSL2
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-47b5227b.0.log, ignite-c072978e.0.log,
> ignite-c62bc58e.0.log
>
>
> Node in Docker container fails to connect to existing cluster if previously
> connected node (container) was stopped:
> {noformat}
> [11:27:38,272][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1990)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@21f9277b],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> ... 11 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Node with the same
> ID was found in node IDs history or existing node in topology has the same ID
> (fix configuration and restart local node) [localNode=TcpDiscoveryNode
>
[jira] [Commented] (IGNITE-15996) Node fails with "Node with the same ID was found" while connecting to the cluster in Docker container if previous container was stopped
[
https://issues.apache.org/jira/browse/IGNITE-15996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454638#comment-17454638
]
Ksenia Rybakova commented on IGNITE-15996:
--
The issue is reproduced only when running containers with default network
(without --network specified) and only on Windows systems. 3rd node can not
join the cluster even if 2nd node was not stopped.
As a workaround an user-defined network should be created before running
containers:
{{docker network create my-net}}
and then run ignite containers at this network
{{docker run -d --net my-net apacheignite/ignite}}
Docker doc reference
[[here|https://docs.docker.com/network/bridge/]|https://docs.docker.com/network/bridge/]
As a resolution suggest adding corresponding info to [documentation
|[https://ignite.apache.org/docs/latest/installation/installing-using-docker]](recommendation
to use user-defined network when running containers on Windows).
> Node fails with "Node with the same ID was found" while connecting to the
> cluster in Docker container if previous container was stopped
> ---
>
> Key: IGNITE-15996
> URL: https://issues.apache.org/jira/browse/IGNITE-15996
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
> Environment: Windows 10, Docker+WSL2
>Reporter: Ksenia Rybakova
>Priority: Major
> Attachments: ignite-47b5227b.0.log, ignite-c072978e.0.log,
> ignite-c62bc58e.0.log
>
>
> Node in Docker container fails to connect to existing cluster if previously
> connected node (container) was stopped:
> {noformat}
> [11:27:38,272][SEVERE][main][IgniteKernal] Got exception while starting (will
> rollback startup routine).
> class org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1990)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1331)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start
> SPI: TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@21f9277b],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:281)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:980)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1985)
> ... 11 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Node with the same
> ID was found in node IDs history or existing node in topology has the same ID
> (fix configuration and restart local node) [localNode=TcpDiscoveryNode
> [id=c62bc58e-102a-4928-8e54-ac8a56bf4d44,
> consistentId=127.0.0.1,172.17.0.4:47500, addrs=ArrayList [127.0.0.1,
> 172.17.0.4], sockAddrs=HashSet [402b337a50dd/172.17.0.4:47500,
> /127.0.0.1:47500], discPort=47500, order=0, intOrder=3,
> lastExchangeTime=1637839658247, loc=true, ver=2.11.0#20210911-sha1:8f3f07d3,
> isClient=false], existingNode=c62bc58e-102a-4928-8e54-ac8a56bf4d44]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.duplicateIdError(TcpDiscoverySpi.java:2083)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1201)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:473)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2207)
> at
>
[jira] [Assigned] (IGNITE-16043) AssertionError in BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Belyaev reassigned IGNITE-16043:
---
Assignee: Andrey Belyaev (was: Ilya Kazakov)
> AssertionError in BinaryObjectBuilder
> -
>
> Key: IGNITE-16043
> URL: https://issues.apache.org/jira/browse/IGNITE-16043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.11
>Reporter: Ilya Kazakov
>Assignee: Andrey Belyaev
>Priority: Minor
>
> AssertionError in this code (run java with -ea key):
> {{}}
>
>
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObjectBuilder;
> public class Ae {
> public static void main(String[] args) {
> try(Ignite ignite = Ignition.start()){
> BinaryObjectBuilder builder =
> ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
> String f = builder.getField("field");
> System.out.println(f);
> }
> }
> } {code}
>
>
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
> at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-14269) Design conditional multi update functionality for meta storage client
[
https://issues.apache.org/jira/browse/IGNITE-14269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov reassigned IGNITE-14269:
---
Assignee: Kirill Gusakov (was: Andrey N. Gura)
> Design conditional multi update functionality for meta storage client
> -
>
> Key: IGNITE-14269
> URL: https://issues.apache.org/jira/browse/IGNITE-14269
> Project: Ignite
> Issue Type: New Feature
>Reporter: Andrey N. Gura
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: iep-61, ignite-3
>
> Define entities required for implementation of conditional multi updates (aka
> "transactions") for meta storage.
> Requirements:
> - Design should provide possibility to define conditional updates in
> if-then-else manner with nested branches.
> - Update always starts with condition.
> - Any nested branch must start with condition.
> - Update can't precede to condition.
> - Every branch can yield exactly one custom result (limited by number of
> simple types) and any number of entries. Corresponding expression always must
> be at the end of branch.
> - Condition for entry revision allows the following comparisons: equal,
> !equal, less, greater.
> - Condition for entry value allows the following operations (byte-wise):
> equal, !equal.
> - Update allows the following operations: put, remove, no-op.
> - Condition can not use previously defined condition instance again because
> it will lead to graph cycle and infinite update execution.
> Assumptions:
> - It seems that conditions and updates entities can be conveniently linked
> using chaining.
> Simple example (pseudocode):
> {code}
> CompletableFuture> = invoke(valCond(EQUAL,
> perstEnabled, true)._then(
> valCond(EQUAL, walEnabled, true)._then(
> update(walEnabled, true)).
> _else(
> update(walEnabled, false))
> )._else(NoopUpdate))
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16067) JMH benchmarks from the raft module do not work
[
https://issues.apache.org/jira/browse/IGNITE-16067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454626#comment-17454626
]
Ivan Bessonov commented on IGNITE-16067:
Looks good, thank you for the contribution! Merged to main
> JMH benchmarks from the raft module do not work
> ---
>
> Key: IGNITE-16067
> URL: https://issues.apache.org/jira/browse/IGNITE-16067
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 50m
> Remaining Estimate: 0h
>
> When running a JMH benchmark in IDEA from the {{raft}} module (e.g.
> {{SingleThreadExecutorBenchmark}}) the following error appears:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find
> the resource: /META-INF/BenchmarkList
> at
> org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:97)
> at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:103)
> at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:256)
> at org.openjdk.jmh.runner.Runner.run(Runner.java:206)
> at
> org.apache.ignite.raft.jraft.util.concurrent.SingleThreadExecutorBenchmark.main(SingleThreadExecutorBenchmark.java:85)
> {noformat}
> h3. Supposed cause
> The {{maven-compiler-plugin}} in this module is configured to use a custom
> annotation processor which automatically disables other annotation
> processors, including the one from JMH. It should be manually enabled.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15978) Support binary HANLDEs by BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-15978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15978:
-
Fix Version/s: 2.13
> Support binary HANLDEs by BinaryObjectBuilder
> -
>
> Key: IGNITE-15978
> URL: https://issues.apache.org/jira/browse/IGNITE-15978
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have to support binary HANLDEs by BinaryObjectBuilder.
> Now, the binary object is created by marshaling the java object may contain
> filed that is represented by the HANDLE (reference) to the other member of
> the upper object.e.g.
>
> {code:java}
> class MyClass {
>List lst0;
>List lst1;
> }
> MyClass var = new MyClass();
> var.lst0 = ...;
> var.lst1 = lst0; // Will be serialized as the HANDLE with offset that refers
> to the lst0 {code}
> But the same layout of the binary object cannot be built by
> BinaryObjectBuilder.e.g.:
> {code:java}
> BinaryObjectBuilder bob = builder("MyClass");
> List lst = ...;
> bob.setField("lst0", lst);
> bob.setField("lst1", lst);
> BinaryObject bo = bob.build(); // Binary object will not contain HANDLE. The
> collections will be marshaled independently, {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16036) IgniteSqlSplitterSelfTest#testFunctionNpe no more failures on current H2 ver, so we need to unignore it.
[
https://issues.apache.org/jira/browse/IGNITE-16036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16036:
-
Fix Version/s: 2.13
> IgniteSqlSplitterSelfTest#testFunctionNpe no more failures on current H2 ver,
> so we need to unignore it.
>
>
> Key: IGNITE-16036
> URL: https://issues.apache.org/jira/browse/IGNITE-16036
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.11
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: sql
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I found that IgniteSqlSplitterSelfTest#testFunctionNpe ignored with closet
> ticket :
> @Ignore("https://issues.apache.org/jira/browse/IGNITE-1886;)
> All runs are passed, so we need to unignore it under this issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15987) PK index inline size is not calculated correctly for keys with a single field
[ https://issues.apache.org/jira/browse/IGNITE-15987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-15987: - Fix Version/s: 2.13 > PK index inline size is not calculated correctly for keys with a single field > - > > Key: IGNITE-15987 > URL: https://issues.apache.org/jira/browse/IGNITE-15987 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.11 >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Example: > CREATE TABLE IF NOT EXISTS TABLE1 ( > col1 varchar(15), > col2 varchar(100), > PRIMARY KEY(col1) > ); > In this case PK inline size would be default 10. > CREATE TABLE IF NOT EXISTS TABLE2 ( > col1 varchar(15), > col2 varchar(100), > PRIMARY KEY(col1) > ) WITH "WRAP_KEY=true"; > This one works correctly, inline size is 18. > It seems that it works as expected only for WRAP_KEY=true. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16063) Update partition assignments on rebalance triggers
[
https://issues.apache.org/jira/browse/IGNITE-16063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16063:
-
Labels: ignite-3 (was: )
> Update partition assignments on rebalance triggers
> --
>
> Key: IGNITE-16063
> URL: https://issues.apache.org/jira/browse/IGNITE-16063
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> According to an algorithm from
> https://issues.apache.org/jira/browse/IGNITE-16020, we need to support
> partition assignments updates when:
> - baseline changed
> - number of partition replicas changed
> This update needs metastore multi-invoke feature and can be described as:
> {code}
> onBaselineEvent:
> for table in tableCfg.tables():
> for partition in table.partitions:
>
>
> onReplicaNumberChange:
> with table as event.table:
> for partitoin in table.partitions:
>
> metastoreInvoke: // atomic metastore call through multi-invoke api
> if empty(partition.change.trigger.revision) ||
> partition.change.trigger.revision < event.revision:
> if empty(partition.assignments.pending) &&
> partition.assignments.stable != calcPartAssighments():
> partition.assignments.pending = calcPartAssignments()
> partition.change.trigger.revision = event.revision
> else:
> if partition.assignments.pending != calcPartAssignments
> partition.assignments.planned = calcPartAssignments()
> partition.change.trigger.revision = event.revision
> else
> remove(partition.assignments.planned)
> else:
> skip
> {code}
> (Phase 1)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16035) Checkstyle rule for empty line with whitespace only.
[
https://issues.apache.org/jira/browse/IGNITE-16035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16035:
-
Labels: ignite-3 (was: )
> Checkstyle rule for empty line with whitespace only.
>
>
> Key: IGNITE-16035
> URL: https://issues.apache.org/jira/browse/IGNITE-16035
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Need to add some checkstyle rule to avoid empty lines with whitespaces only.
> Like rule in checkstyle-rules.xml:
> {code:java}
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16072) Add configurable throttling for the spanshot process
[ https://issues.apache.org/jira/browse/IGNITE-16072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16072: - Labels: iep-43 ise (was: iep-43) > Add configurable throttling for the spanshot process > > > Key: IGNITE-16072 > URL: https://issues.apache.org/jira/browse/IGNITE-16072 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Labels: iep-43, ise > Fix For: 2.13 > > > We want to add configurable throttling to the number of threads that perform > a snapshot operation. The IGNITE-16014 have introduced the pool size > configuration property, however, it is still possible that a node can become > overloaded and unresponsive due to its attempts to copy data files on very > slow HDDs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16072) Add configurable throttling for the spanshot process
Maxim Muzafarov created IGNITE-16072: Summary: Add configurable throttling for the spanshot process Key: IGNITE-16072 URL: https://issues.apache.org/jira/browse/IGNITE-16072 Project: Ignite Issue Type: Improvement Reporter: Maxim Muzafarov Fix For: 2.13 We want to add configurable throttling to the number of threads that perform a snapshot operation. The IGNITE-16014 have introduced the pool size configuration property, however, it is still possible that a node can become overloaded and unresponsive due to its attempts to copy data files on very slow HDDs. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-14769) Key hash calculation.
[ https://issues.apache.org/jira/browse/IGNITE-14769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454594#comment-17454594 ] Andrey Mashenkov edited comment on IGNITE-14769 at 12/7/21, 11:33 AM: -- [~korlov] PR look good. Benchmark results of all alternative hash functions look similar. The distribution looks acceptable. So, we can take any of them. Partially agree with Andrey, but * Any of these functions may have bugs, even a murmur3. But murmur3 is widely used and it is less risky. Anyway, we can run SMHasher benches or other tests, and check implementation quality on different platforms for any function, if found a better one. (10+% maybe don't worth it, but e.g. 2x-10x and more looks discussable) * I'm not sure what 'optimization for Java Runtime' meant if the port shows comparable results. I'd think about possible hardware optimizations (vectorization, AVX, SSE), and maybe consider using native C++ implementation. The risk here - native call to c++ implementation may cause performance drops on some environments and/or hardware. I think we should focus on refactoring and the possibility of switching to another function easily in the future. The utility-class method call with murmur3 implementation is ok. was (Author: amashenkov): [~korlov] PR look good. Benchmark results of all alternative hash functions look similar. The distribution looks acceptable. So, we can take any of them. Partially agree with Andrey, but * Any of these functions may have bugs, even a murmur3. But murmur3 is widely used and it is less risky. Anyway, we can run SMHasher benches or other tests, and check implementation quality on different platforms for any function, if found a better one. * I'm not sure what 'optimization for Java Runtime' meant if the port shows comparable results. I'd think about possible hardware optimizations (vectorization, AVX, SSE), and maybe consider using native C++ implementation. The risk here - native call to c++ implementation may cause performance drops on some environments and/or hardware. I think we should focus on refactoring and the possibility of switching to another function easily in the future. The utility-class method call with murmur3 implementation is ok. > Key hash calculation. > - > > Key: IGNITE-14769 > URL: https://issues.apache.org/jira/browse/IGNITE-14769 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Konstantin Orlov >Priority: Major > Labels: iep-54, ignite-3 > Attachments: Partition count 100.png, Partition count 1024 (rnd).png, > Partition count 1024.png, Partition count 128 (rnd).png, Partition count > 128.png, Partition count 16 (rnd).png, Partition count 32.png, Partition > count 480 (rnd).png, Partition count 480.png, Partition count 8.png > > Original Estimate: 96h > Remaining Estimate: 96h > > There are next possible ways for cache calculation. > # Update hash on every write method call as it works for now. > # Calculate for all key chunk (hash of byte[]) - all columns including a > null-map. > Let's choose and implement the best way and along with a better hash function, > e.g. xxHash64 [1], Murmur3 [2]released in Apache Commons, CityHash (from > Google) [3], FastHash32 [4]. > > [1][https://github.com/Cyan4973/xxHash/] > [2][https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash3.java.html] > [3] [https://github.com/google/cityhash] > [4] [https://github.com/rurban/smhasher/blob/master/fasthash.cpp] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-14769) Key hash calculation.
[ https://issues.apache.org/jira/browse/IGNITE-14769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454594#comment-17454594 ] Andrey Mashenkov edited comment on IGNITE-14769 at 12/7/21, 11:30 AM: -- [~korlov] PR look good. Benchmark results of all alternative hash functions look similar. The distribution looks acceptable. So, we can take any of them. Partially agree with Andrey, but * Any of these functions may have bugs, even a murmur3. But murmur3 is widely used and it is less risky. Anyway, we can run SMHasher benches or other tests, and check implementation quality on different platforms for any function, if found a better one. * I'm not sure what 'optimization for Java Runtime' meant if the port shows comparable results. I'd think about possible hardware optimizations (vectorization, AVX, SSE), and maybe consider using native C++ implementation. The risk here - native call to c++ implementation may cause performance drops on some environments and/or hardware. I think we should focus on refactoring and the possibility of switching to another function easily in the future. The utility-class method call with murmur3 implementation is ok. was (Author: amashenkov): [~korlov] PR look good. Benchmark results of all alternative hash functions look similar. The distribution looks acceptable. So, we can take any of them. Partially agree with Andrey, but * Any of these functions may have bugs, even a murmur3. But murmur3 is widely used and it is less risky. Anyway, we can run SMHasher benches or other tests on different platforms to check implementation quality for any of these functions, if found a better one. * I'm not sure what 'optimization for Java Runtime' meant if the port shows comparable results. I'd think about possible hardware optimizations (vectorization, AVX, SSE), and maybe consider using native C++ implementation. The risk here - native call to c++ implementation may cause performance drops on some environments and/or hardware. I think we should focus on refactoring and the possibility of switching to another function easily in the future. The utility-class method call with murmur3 implementation is ok. > Key hash calculation. > - > > Key: IGNITE-14769 > URL: https://issues.apache.org/jira/browse/IGNITE-14769 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Konstantin Orlov >Priority: Major > Labels: iep-54, ignite-3 > Attachments: Partition count 100.png, Partition count 1024 (rnd).png, > Partition count 1024.png, Partition count 128 (rnd).png, Partition count > 128.png, Partition count 16 (rnd).png, Partition count 32.png, Partition > count 480 (rnd).png, Partition count 480.png, Partition count 8.png > > Original Estimate: 96h > Remaining Estimate: 96h > > There are next possible ways for cache calculation. > # Update hash on every write method call as it works for now. > # Calculate for all key chunk (hash of byte[]) - all columns including a > null-map. > Let's choose and implement the best way and along with a better hash function, > e.g. xxHash64 [1], Murmur3 [2]released in Apache Commons, CityHash (from > Google) [3], FastHash32 [4]. > > [1][https://github.com/Cyan4973/xxHash/] > [2][https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash3.java.html] > [3] [https://github.com/google/cityhash] > [4] [https://github.com/rurban/smhasher/blob/master/fasthash.cpp] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14769) Key hash calculation.
[ https://issues.apache.org/jira/browse/IGNITE-14769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454594#comment-17454594 ] Andrey Mashenkov commented on IGNITE-14769: --- [~korlov] PR look good. Benchmark results of all alternative hash functions look similar. The distribution looks acceptable. So, we can take any of them. Partially agree with Andrey, but * Any of these functions may have bugs, even a murmur3. But murmur3 is widely used and it is less risky. Anyway, we can run SMHasher benches or other tests on different platforms to check implementation quality for any of these functions, if found a better one. * I'm not sure what 'optimization for Java Runtime' meant if the port shows comparable results. I'd think about possible hardware optimizations (vectorization, AVX, SSE), and maybe consider using native C++ implementation. The risk here - native call to c++ implementation may cause performance drops on some environments and/or hardware. I think we should focus on refactoring and the possibility of switching to another function easily in the future. The utility-class method call with murmur3 implementation is ok. > Key hash calculation. > - > > Key: IGNITE-14769 > URL: https://issues.apache.org/jira/browse/IGNITE-14769 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Konstantin Orlov >Priority: Major > Labels: iep-54, ignite-3 > Attachments: Partition count 100.png, Partition count 1024 (rnd).png, > Partition count 1024.png, Partition count 128 (rnd).png, Partition count > 128.png, Partition count 16 (rnd).png, Partition count 32.png, Partition > count 480 (rnd).png, Partition count 480.png, Partition count 8.png > > Original Estimate: 96h > Remaining Estimate: 96h > > There are next possible ways for cache calculation. > # Update hash on every write method call as it works for now. > # Calculate for all key chunk (hash of byte[]) - all columns including a > null-map. > Let's choose and implement the best way and along with a better hash function, > e.g. xxHash64 [1], Murmur3 [2]released in Apache Commons, CityHash (from > Google) [3], FastHash32 [4]. > > [1][https://github.com/Cyan4973/xxHash/] > [2][https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash3.java.html] > [3] [https://github.com/google/cityhash] > [4] [https://github.com/rurban/smhasher/blob/master/fasthash.cpp] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16061) Make BinaryMarshaller#setBinaryContext() public
[ https://issues.apache.org/jira/browse/IGNITE-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454590#comment-17454590 ] Roman Puchkovskiy commented on IGNITE-16061: Thank you guys! [~ktkale...@gridgain.com] [~zstan] > Make BinaryMarshaller#setBinaryContext() public > --- > > Key: IGNITE-16061 > URL: https://issues.apache.org/jira/browse/IGNITE-16061 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > BinaryMarshaller#setBinaryContext() method is required to initialize > BinaryMarshaller, without this method invocation BinaryMarshaller cannot be > used. But the method is private and it never gets invoked from > BinaryMarshaller code itself. Instead, it is always called from other classes > using reflection, like this: > IgniteUtils.invoke(BinaryMarshaller.class, bMarsh0, "setBinaryContext", > binaryCtx, ctx.config()); > So, in reality, the method is handled like it's public, but as it is actually > private, reflection has to be used as a work-around. > It seems better to just make the method public. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15792) Update README.md with Mappers explanation.
[ https://issues.apache.org/jira/browse/IGNITE-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-15792: -- Fix Version/s: 3.0.0-alpha4 > Update README.md with Mappers explanation. > -- > > Key: IGNITE-15792 > URL: https://issues.apache.org/jira/browse/IGNITE-15792 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > Update README.md with a short description of Mappers API. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15792) Update README.md with Mappers explanation.
[ https://issues.apache.org/jira/browse/IGNITE-15792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-15792: - Assignee: Andrey Mashenkov > Update README.md with Mappers explanation. > -- > > Key: IGNITE-15792 > URL: https://issues.apache.org/jira/browse/IGNITE-15792 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Update README.md with a short description of Mappers API. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16061) Make BinaryMarshaller#setBinaryContext() public
[ https://issues.apache.org/jira/browse/IGNITE-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454579#comment-17454579 ] Evgeny Stanilovsky commented on IGNITE-16061: - [~rpuch] merged under 8c343f8e4a1400f1aab19117443e, thanks for your effort ! > Make BinaryMarshaller#setBinaryContext() public > --- > > Key: IGNITE-16061 > URL: https://issues.apache.org/jira/browse/IGNITE-16061 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > BinaryMarshaller#setBinaryContext() method is required to initialize > BinaryMarshaller, without this method invocation BinaryMarshaller cannot be > used. But the method is private and it never gets invoked from > BinaryMarshaller code itself. Instead, it is always called from other classes > using reflection, like this: > IgniteUtils.invoke(BinaryMarshaller.class, bMarsh0, "setBinaryContext", > binaryCtx, ctx.config()); > So, in reality, the method is handled like it's public, but as it is actually > private, reflection has to be used as a work-around. > It seems better to just make the method public. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16068) Operations hang with different characters encoding on nodes and authentication enabled.
[
https://issues.apache.org/jira/browse/IGNITE-16068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-16068:
-
Fix Version/s: 2.12
> Operations hang with different characters encoding on nodes and
> authentication enabled.
> ---
>
> Key: IGNITE-16068
> URL: https://issues.apache.org/jira/browse/IGNITE-16068
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class AuthenticatorMultiJvmEncodingTest extends GridCommonAbstractTest
> {
> /** Character encoding name that will be applied to the next Ignite
> process start. */
> private String jvmCharacterEncoding;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setMaxSize(100 * (1 << 20))
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected List additionalRemoteJvmArgs() {
> List args = super.additionalRemoteJvmArgs();
> args.add("-Dfile.encoding=" + jvmCharacterEncoding);
> return args;
> }
> /** {@inheritDoc} */
> @Override protected boolean isRemoteJvm(String igniteInstanceName) {
> return getTestIgniteInstanceIndex(igniteInstanceName) != 0;
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> /** */
> @Test
> public void testMultipleJvmInstancesWithDifferentEncoding() throws
> Exception {
> startGrid(0);
> jvmCharacterEncoding = "Big5";
> startGrid(1);
> jvmCharacterEncoding = "UTF-8";
> startGrid(2);
> grid(0).cluster().state(ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> String login = "語";
> String pwd = "語";
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser(login, pwd.toCharArray());
> }
> try (
> IgniteClient cli = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800")
> .setUserName(login)
> .setUserPassword(pwd))
> ) {
> ClientCache cache =
> cli.cache(DEFAULT_CACHE_NAME);
> Map entries = new HashMap<>();
> for (int i = 0; i < 1000; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> }
> }
> {code}
> Exception on server node before hanging:
> {code:java}
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : c950cc94-38f1-304d-b858-2aa6e9478357
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> java.lang.Thread.run(Thread.java:748)
> {code}
> The main reason of described above behavior is that
>
[jira] [Commented] (IGNITE-16068) Operations hang with different characters encoding on nodes and authentication enabled.
[
https://issues.apache.org/jira/browse/IGNITE-16068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454577#comment-17454577
]
Ignite TC Bot commented on IGNITE-16068:
{panel:title=Branch: [pull/9634/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9634/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Security{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6309100]]
* {color:#013220}SecurityTestSuite:
AuthenticationMultiJvmEncodingTest.testMultipleJvmInstancesWithDifferentEncoding
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6309113buildTypeId=IgniteTests24Java8_RunAll]
> Operations hang with different characters encoding on nodes and
> authentication enabled.
> ---
>
> Key: IGNITE-16068
> URL: https://issues.apache.org/jira/browse/IGNITE-16068
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class AuthenticatorMultiJvmEncodingTest extends GridCommonAbstractTest
> {
> /** Character encoding name that will be applied to the next Ignite
> process start. */
> private String jvmCharacterEncoding;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setMaxSize(100 * (1 << 20))
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected List additionalRemoteJvmArgs() {
> List args = super.additionalRemoteJvmArgs();
> args.add("-Dfile.encoding=" + jvmCharacterEncoding);
> return args;
> }
> /** {@inheritDoc} */
> @Override protected boolean isRemoteJvm(String igniteInstanceName) {
> return getTestIgniteInstanceIndex(igniteInstanceName) != 0;
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> /** */
> @Test
> public void testMultipleJvmInstancesWithDifferentEncoding() throws
> Exception {
> startGrid(0);
> jvmCharacterEncoding = "Big5";
> startGrid(1);
> jvmCharacterEncoding = "UTF-8";
> startGrid(2);
> grid(0).cluster().state(ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> String login = "語";
> String pwd = "語";
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser(login, pwd.toCharArray());
> }
> try (
> IgniteClient cli = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800")
> .setUserName(login)
> .setUserPassword(pwd))
> ) {
> ClientCache cache =
> cli.cache(DEFAULT_CACHE_NAME);
> Map entries = new HashMap<>();
> for (int i = 0; i < 1000; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> }
> }
> {code}
> Exception on server node before hanging:
> {code:java}
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : c950cc94-38f1-304d-b858-2aa6e9478357
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> [2021-12-06
[jira] [Assigned] (IGNITE-16061) Make BinaryMarshaller#setBinaryContext() public
[ https://issues.apache.org/jira/browse/IGNITE-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-16061: -- Reviewer: Kirill Tkalenko Assignee: Roman Puchkovskiy (was: Kirill Tkalenko) > Make BinaryMarshaller#setBinaryContext() public > --- > > Key: IGNITE-16061 > URL: https://issues.apache.org/jira/browse/IGNITE-16061 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > BinaryMarshaller#setBinaryContext() method is required to initialize > BinaryMarshaller, without this method invocation BinaryMarshaller cannot be > used. But the method is private and it never gets invoked from > BinaryMarshaller code itself. Instead, it is always called from other classes > using reflection, like this: > IgniteUtils.invoke(BinaryMarshaller.class, bMarsh0, "setBinaryContext", > binaryCtx, ctx.config()); > So, in reality, the method is handled like it's public, but as it is actually > private, reflection has to be used as a work-around. > It seems better to just make the method public. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454541#comment-17454541
]
Ignite TC Bot commented on IGNITE-15969:
{panel:title=Branch: [pull/9627/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9627/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6307685buildTypeId=IgniteTests24Java8_RunAll]
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15922) Create numa-aware allocator for data regions.
[
https://issues.apache.org/jira/browse/IGNITE-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454536#comment-17454536
]
Ignite TC Bot commented on IGNITE-15922:
{panel:title=Branch: [pull/9569/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9569/head] Base: [master] : New Tests
(30)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6307448]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=true,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
... and 19 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6307473buildTypeId=IgniteTests24Java8_RunAll]
> Create numa-aware allocator for data regions.
> -
>
> Key: IGNITE-15922
> URL: https://issues.apache.org/jira/browse/IGNITE-15922
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Sometimes it is worth to allocate data region on specific numa node or on
> interleaved node (i.e. Intel Optane can be set up as a little bit slower, but
> cheaper than and have more capacity, than DDR, and unified as NUMA nodes).
> Need to write C++ wrapper around {{libnuma}} and extract common allocator
> interface and add as a configuration parameter to {{DataRegionConfiguration}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15922) Create numa-aware allocator for data regions.
[
https://issues.apache.org/jira/browse/IGNITE-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454535#comment-17454535
]
Ignite TC Bot commented on IGNITE-15922:
{panel:title=Branch: [pull/9569/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9569/head] Base: [master] : New Tests
(30)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6307448]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=true,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/74735260@fc807c1] -
PASSED{color}
... and 19 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6307473buildTypeId=IgniteTests24Java8_RunAll]
> Create numa-aware allocator for data regions.
> -
>
> Key: IGNITE-15922
> URL: https://issues.apache.org/jira/browse/IGNITE-15922
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Sometimes it is worth to allocate data region on specific numa node or on
> interleaved node (i.e. Intel Optane can be set up as a little bit slower, but
> cheaper than and have more capacity, than DDR, and unified as NUMA nodes).
> Need to write C++ wrapper around {{libnuma}} and extract common allocator
> interface and add as a configuration parameter to {{DataRegionConfiguration}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454520#comment-17454520
]
Ilya Shishkov commented on IGNITE-15969:
I did not add extra tests, because in my opinion existing ones provides test
coverage.
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454518#comment-17454518
]
Ilya Shishkov commented on IGNITE-15969:
[~PetrovMikhail], can you please take a look?
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454514#comment-17454514
]
Ignite TC Bot commented on IGNITE-15969:
{panel:title=Branch: [pull/9627/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}AWS{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6223815]]
{color:#d04437}GCE{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6223817]]
{panel}
{panel:title=Branch: [pull/9627/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6222970buildTypeId=IgniteTests24Java8_RunAll]
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise, newbie
> Fix For: 2.13
>
> Attachments: ClientNodeAuthFailureReproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16071) Read Repair futures should be rewritten to use wait-free sync instead of synchronized
[ https://issues.apache.org/jira/browse/IGNITE-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-16071: -- Summary: Read Repair futures should be rewritten to use wait-free sync instead of synchronized (was: ReadRepair futures should be rewritten to use wait-free sync instead of synchronized) > Read Repair futures should be rewritten to use wait-free sync instead of > synchronized > - > > Key: IGNITE-16071 > URL: https://issues.apache.org/jira/browse/IGNITE-16071 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > Read Repair was implemented as a PoC, so synchronized sync was suitable, but > now this should be replaced with CompoundFuture logic. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16071) ReadRepair futures should be rewritten to use wait-free sync instead of synchronized
Anton Vinogradov created IGNITE-16071: - Summary: ReadRepair futures should be rewritten to use wait-free sync instead of synchronized Key: IGNITE-16071 URL: https://issues.apache.org/jira/browse/IGNITE-16071 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Read Repair was implemented as a PoC, so synchronized sync was suitable, but now this should be replaced with CompoundFuture logic. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14945) IndexQuery should use inline IO for internal filtering.
[
https://issues.apache.org/jira/browse/IGNITE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454505#comment-17454505
]
Ignite TC Bot commented on IGNITE-14945:
{panel:title=Branch: [pull/9631/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9631/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6307849buildTypeId=IgniteTests24Java8_RunAll]
> IndexQuery should use inline IO for internal filtering.
> ---
>
> Key: IGNITE-14945
> URL: https://issues.apache.org/jira/browse/IGNITE-14945
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For comparison of index keys it's required:
> # to init cache data row
> # access fields with BinaryObject API
> So, it's possible to use inline IO for filtering. It can help:
> # speed up comparison (Inline IO access is faster than BinaryObject API).
> # to avoid init cache data rows for filtered items (in case there are more
> filtered items).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-14971) Implement key-value API for java thin client for 3.0
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-14971: --- Assignee: Pavel Tupitsyn > Implement key-value API for java thin client for 3.0 > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > > We need to implement basic key-value API for java thin client in 3.0. Maybe > this task should involve creating an IEP and discussion on the dev list. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14971) Implement key-value API for java thin client for 3.0
[ https://issues.apache.org/jira/browse/IGNITE-14971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-14971: Fix Version/s: 3.0.0-alpha4 > Implement key-value API for java thin client for 3.0 > > > Key: IGNITE-14971 > URL: https://issues.apache.org/jira/browse/IGNITE-14971 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-76, ignite-3 > Fix For: 3.0.0-alpha4 > > > We need to implement basic key-value API for java thin client in 3.0. Maybe > this task should involve creating an IEP and discussion on the dev list. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13804) Java thin: avoid buffer copies in synchronous operations
[
https://issues.apache.org/jira/browse/IGNITE-13804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13804:
Release Note: Java thin: reduced memory usage by avoiding extra buffer
copy. (was: Java thin: reduced memory usage with buffer pooling.)
> Java thin: avoid buffer copies in synchronous operations
>
>
> Key: IGNITE-13804
> URL: https://issues.apache.org/jira/browse/IGNITE-13804
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{org.apache.ignite.internal.client.thin.TcpClientChannel#send}} creates a
> buffer copy, because the buffer will be returned to the pool upon leaving the
> scope, but we need it to survive longer while NIO framework processes it.
> However, for synchronous requests we block the thread anyway, so an extra
> copy can be avoided. See discussion in
> [#8483|https://github.com/apache/ignite/pull/8483#discussion_r533915757]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-13804) Java thin: avoid buffer copies in synchronous operations
[
https://issues.apache.org/jira/browse/IGNITE-13804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13804:
Release Note: Java thin: reduced memory usage with buffer pooling. (was:
Java thin: reduced memory usage)
> Java thin: avoid buffer copies in synchronous operations
>
>
> Key: IGNITE-13804
> URL: https://issues.apache.org/jira/browse/IGNITE-13804
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{org.apache.ignite.internal.client.thin.TcpClientChannel#send}} creates a
> buffer copy, because the buffer will be returned to the pool upon leaving the
> scope, but we need it to survive longer while NIO framework processes it.
> However, for synchronous requests we block the thread anyway, so an extra
> copy can be avoided. See discussion in
> [#8483|https://github.com/apache/ignite/pull/8483#discussion_r533915757]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14945) IndexQuery should use inline IO for internal filtering.
[ https://issues.apache.org/jira/browse/IGNITE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-14945: Description: For comparison of index keys it's required: # to init cache data row # access fields with BinaryObject API So, it's possible to use inline IO for filtering. It can help: # speed up comparison (Inline IO access is faster than BinaryObject API). # to avoid init cache data rows for filtered items (in case there are more filtered items). was: For comparison of index keys it's required: # to init cache data row # access fields with BinaryObject API So, it's possible to use inline IO for filtering. It can help: # speed up comparison (it's need to test whether Inline IO access significantly faster then BinaryObject API. # to avoid init cache data rows for filtered items (in case there are more filtered items). > IndexQuery should use inline IO for internal filtering. > --- > > Key: IGNITE-14945 > URL: https://issues.apache.org/jira/browse/IGNITE-14945 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Time Spent: 10m > Remaining Estimate: 0h > > For comparison of index keys it's required: > # to init cache data row > # access fields with BinaryObject API > So, it's possible to use inline IO for filtering. It can help: > # speed up comparison (Inline IO access is faster than BinaryObject API). > # to avoid init cache data rows for filtered items (in case there are more > filtered items). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16056) Using polymorphic schema leads to ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454464#comment-17454464
]
Ivan Bessonov commented on IGNITE-16056:
[~ktkale...@gridgain.com] look good to me, thank you for the fix! I'll merge it
to the main
> Using polymorphic schema leads to ClassCastException
>
>
> Key: IGNITE-16056
> URL: https://issues.apache.org/jira/browse/IGNITE-16056
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Using polymorphic schema can lead to ClassCastException.
> Let's consider the following configuration example:
> {code:java}
> ConfigurationRegistry registry = new ConfigurationRegistry(
> List.of(ThirdRootConfiguration.KEY),
> Map.of(),
> new TestConfigurationStorage(LOCAL),
> List.of(),
> List.of(
> First0PolymorphicConfigurationSchema.class,
> First1PolymorphicConfigurationSchema.class));
> registry.start();
> registry.getConfiguration(ThirdRootConfiguration.KEY).change(c -> {
> c.changeEntity(entity -> {
> entity.create("new entity", upd -> {
> upd.changePolymorphicConfig(p -> {
> p.create("key", polymorphicChange -> {
> polymorphicChange.changeName("entity name");
>
> polymorphicChange.convert(First0PolymorphicChange.class).changeTest0(12);
> });
> });
> });
> });
> }).get();
> registry.stop();
> {code}
> where polymorphic schemas are defined as follows:
> {code:java}
> @ConfigurationRoot(rootName = "third")
> public static class ThirdRootConfigurationSchema {
> @NamedConfigValue
> public EntityConfigurationSchema entity;
> }
> @Config
> public static class EntityConfigurationSchema {
> @NamedConfigValue
> public FirstPolymorphicConfigurationSchema polymorphicConfig;
> }
> @PolymorphicConfig
> public static class FirstPolymorphicConfigurationSchema {
> /** Polymorphic type id field. */
> @PolymorphicId
> public String typeId;
> @Value
> public String name;
> }
> @PolymorphicConfigInstance("first0")
> public static class First0PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public int test0;
> }
> @PolymorphicConfigInstance("first1")
> public static class First1PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public long test1;
> }
> {code}
> This example results in ClassCastException
> {noformat}
> java.util.concurrent.ExecutionException:
> org.apache.ignite.configuration.ConfigurationChangeException: Failed to
> change configuration
> at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistryTest.testAAA(ConfigurationRegistryTest.java:140)
> ...
> Caused by: org.apache.ignite.configuration.ConfigurationChangeException:
> Failed to change configuration
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$3(ConfigurationChanger.java:401)
> ...
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> cannot be cast to class
> org.apache.ignite.internal.configuration.DynamicConfiguration
> (org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> is in unnamed module of loader
> com.facebook.presto.bytecode.DynamicClassLoader @24313fcc;
> org.apache.ignite.internal.configuration.DynamicConfiguration is in unnamed
> module of loader 'app')
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:625)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:563)
> at
> org.apache.ignite.internal.configuration.EntityNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil.notifyAnyListenersOnCreate(ConfigurationNotificationsUtil.java:563)
> at
>
[jira] [Updated] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[ https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-16070: -- Description: Move the executor service used for re-encryption into the pool processor to enable monitoring. (was: Move the executor service used for re-encryption to the pool processor.) > Move the executor service used for re-encryption into the pool processor. > - > > Key: IGNITE-16070 > URL: https://issues.apache.org/jira/browse/IGNITE-16070 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > > Move the executor service used for re-encryption into the pool processor to > enable monitoring. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16056) Using polymorphic schema leads to ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-16056:
---
Epic Link: IGNITE-14904
> Using polymorphic schema leads to ClassCastException
>
>
> Key: IGNITE-16056
> URL: https://issues.apache.org/jira/browse/IGNITE-16056
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Using polymorphic schema can lead to ClassCastException.
> Let's consider the following configuration example:
> {code:java}
> ConfigurationRegistry registry = new ConfigurationRegistry(
> List.of(ThirdRootConfiguration.KEY),
> Map.of(),
> new TestConfigurationStorage(LOCAL),
> List.of(),
> List.of(
> First0PolymorphicConfigurationSchema.class,
> First1PolymorphicConfigurationSchema.class));
> registry.start();
> registry.getConfiguration(ThirdRootConfiguration.KEY).change(c -> {
> c.changeEntity(entity -> {
> entity.create("new entity", upd -> {
> upd.changePolymorphicConfig(p -> {
> p.create("key", polymorphicChange -> {
> polymorphicChange.changeName("entity name");
>
> polymorphicChange.convert(First0PolymorphicChange.class).changeTest0(12);
> });
> });
> });
> });
> }).get();
> registry.stop();
> {code}
> where polymorphic schemas are defined as follows:
> {code:java}
> @ConfigurationRoot(rootName = "third")
> public static class ThirdRootConfigurationSchema {
> @NamedConfigValue
> public EntityConfigurationSchema entity;
> }
> @Config
> public static class EntityConfigurationSchema {
> @NamedConfigValue
> public FirstPolymorphicConfigurationSchema polymorphicConfig;
> }
> @PolymorphicConfig
> public static class FirstPolymorphicConfigurationSchema {
> /** Polymorphic type id field. */
> @PolymorphicId
> public String typeId;
> @Value
> public String name;
> }
> @PolymorphicConfigInstance("first0")
> public static class First0PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public int test0;
> }
> @PolymorphicConfigInstance("first1")
> public static class First1PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public long test1;
> }
> {code}
> This example results in ClassCastException
> {noformat}
> java.util.concurrent.ExecutionException:
> org.apache.ignite.configuration.ConfigurationChangeException: Failed to
> change configuration
> at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistryTest.testAAA(ConfigurationRegistryTest.java:140)
> ...
> Caused by: org.apache.ignite.configuration.ConfigurationChangeException:
> Failed to change configuration
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$3(ConfigurationChanger.java:401)
> ...
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> cannot be cast to class
> org.apache.ignite.internal.configuration.DynamicConfiguration
> (org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> is in unnamed module of loader
> com.facebook.presto.bytecode.DynamicClassLoader @24313fcc;
> org.apache.ignite.internal.configuration.DynamicConfiguration is in unnamed
> module of loader 'app')
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:625)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:563)
> at
> org.apache.ignite.internal.configuration.EntityNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil.notifyAnyListenersOnCreate(ConfigurationNotificationsUtil.java:563)
> at
>
[jira] [Updated] (IGNITE-16056) Using polymorphic schema leads to ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-16056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-16056:
---
Fix Version/s: 3.0.0-alpha4
> Using polymorphic schema leads to ClassCastException
>
>
> Key: IGNITE-16056
> URL: https://issues.apache.org/jira/browse/IGNITE-16056
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Using polymorphic schema can lead to ClassCastException.
> Let's consider the following configuration example:
> {code:java}
> ConfigurationRegistry registry = new ConfigurationRegistry(
> List.of(ThirdRootConfiguration.KEY),
> Map.of(),
> new TestConfigurationStorage(LOCAL),
> List.of(),
> List.of(
> First0PolymorphicConfigurationSchema.class,
> First1PolymorphicConfigurationSchema.class));
> registry.start();
> registry.getConfiguration(ThirdRootConfiguration.KEY).change(c -> {
> c.changeEntity(entity -> {
> entity.create("new entity", upd -> {
> upd.changePolymorphicConfig(p -> {
> p.create("key", polymorphicChange -> {
> polymorphicChange.changeName("entity name");
>
> polymorphicChange.convert(First0PolymorphicChange.class).changeTest0(12);
> });
> });
> });
> });
> }).get();
> registry.stop();
> {code}
> where polymorphic schemas are defined as follows:
> {code:java}
> @ConfigurationRoot(rootName = "third")
> public static class ThirdRootConfigurationSchema {
> @NamedConfigValue
> public EntityConfigurationSchema entity;
> }
> @Config
> public static class EntityConfigurationSchema {
> @NamedConfigValue
> public FirstPolymorphicConfigurationSchema polymorphicConfig;
> }
> @PolymorphicConfig
> public static class FirstPolymorphicConfigurationSchema {
> /** Polymorphic type id field. */
> @PolymorphicId
> public String typeId;
> @Value
> public String name;
> }
> @PolymorphicConfigInstance("first0")
> public static class First0PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public int test0;
> }
> @PolymorphicConfigInstance("first1")
> public static class First1PolymorphicConfigurationSchema extends
> FirstPolymorphicConfigurationSchema {
> @Value
> public long test1;
> }
> {code}
> This example results in ClassCastException
> {noformat}
> java.util.concurrent.ExecutionException:
> org.apache.ignite.configuration.ConfigurationChangeException: Failed to
> change configuration
> at
> java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at
> java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistryTest.testAAA(ConfigurationRegistryTest.java:140)
> ...
> Caused by: org.apache.ignite.configuration.ConfigurationChangeException:
> Failed to change configuration
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$3(ConfigurationChanger.java:401)
> ...
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> cannot be cast to class
> org.apache.ignite.internal.configuration.DynamicConfiguration
> (org.apache.ignite.internal.configuration.First0PolymorphicConfigurationImpl
> is in unnamed module of loader
> com.facebook.presto.bytecode.DynamicClassLoader @24313fcc;
> org.apache.ignite.internal.configuration.DynamicConfiguration is in unnamed
> module of loader 'app')
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:625)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil$2.visitNamedListNode(ConfigurationNotificationsUtil.java:563)
> at
> org.apache.ignite.internal.configuration.EntityNode.traverseChildren(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.util.ConfigurationNotificationsUtil.notifyAnyListenersOnCreate(ConfigurationNotificationsUtil.java:563)
> at
>
[jira] [Updated] (IGNITE-16070) Move the executor service used for re-encryption into the pool processor.
[ https://issues.apache.org/jira/browse/IGNITE-16070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-16070: -- Summary: Move the executor service used for re-encryption into the pool processor. (was: Move the executor service used for re-encryption to the pool processor.) > Move the executor service used for re-encryption into the pool processor. > - > > Key: IGNITE-16070 > URL: https://issues.apache.org/jira/browse/IGNITE-16070 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > > Move the executor service used for re-encryption to the pool processor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16070) Move the executor service used for re-encryption to the pool processor.
Pavel Pereslegin created IGNITE-16070: - Summary: Move the executor service used for re-encryption to the pool processor. Key: IGNITE-16070 URL: https://issues.apache.org/jira/browse/IGNITE-16070 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin Move the executor service used for re-encryption to the pool processor. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16061) Make BinaryMarshaller#setBinaryContext() public
[ https://issues.apache.org/jira/browse/IGNITE-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454453#comment-17454453 ] Roman Puchkovskiy commented on IGNITE-16061: [~zstan] the PR has been approved, could you please help with merging to master? > Make BinaryMarshaller#setBinaryContext() public > --- > > Key: IGNITE-16061 > URL: https://issues.apache.org/jira/browse/IGNITE-16061 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Roman Puchkovskiy >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > BinaryMarshaller#setBinaryContext() method is required to initialize > BinaryMarshaller, without this method invocation BinaryMarshaller cannot be > used. But the method is private and it never gets invoked from > BinaryMarshaller code itself. Instead, it is always called from other classes > using reflection, like this: > IgniteUtils.invoke(BinaryMarshaller.class, bMarsh0, "setBinaryContext", > binaryCtx, ctx.config()); > So, in reality, the method is handled like it's public, but as it is actually > private, reflection has to be used as a work-around. > It seems better to just make the method public. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16061) Make BinaryMarshaller#setBinaryContext() public
[ https://issues.apache.org/jira/browse/IGNITE-16061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454452#comment-17454452 ] Kirill Tkalenko commented on IGNITE-16061: -- [~rpuch] Looks good. > Make BinaryMarshaller#setBinaryContext() public > --- > > Key: IGNITE-16061 > URL: https://issues.apache.org/jira/browse/IGNITE-16061 > Project: Ignite > Issue Type: Improvement > Components: binary >Reporter: Roman Puchkovskiy >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > BinaryMarshaller#setBinaryContext() method is required to initialize > BinaryMarshaller, without this method invocation BinaryMarshaller cannot be > used. But the method is private and it never gets invoked from > BinaryMarshaller code itself. Instead, it is always called from other classes > using reflection, like this: > IgniteUtils.invoke(BinaryMarshaller.class, bMarsh0, "setBinaryContext", > binaryCtx, ctx.config()); > So, in reality, the method is handled like it's public, but as it is actually > private, reflection has to be used as a work-around. > It seems better to just make the method public. -- This message was sent by Atlassian Jira (v8.20.1#820001)
