[jira] [Resolved] (IGNITE-12749) Unsupported operation exception on node stop if collisionspi not null
[
https://issues.apache.org/jira/browse/IGNITE-12749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov resolved IGNITE-12749.
-
Resolution: Duplicate
> Unsupported operation exception on node stop if collisionspi not null
> -
>
> Key: IGNITE-12749
> URL: https://issues.apache.org/jira/browse/IGNITE-12749
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> If collision spi specified then on the node stop there are exception:
> {noformat}
> java.lang.UnsupportedOperationException
> at
> org.jsr166.ConcurrentLinkedHashMap.clear(ConcurrentLinkedHashMap.java:1542)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.stop(GridJobProcessor.java:376)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2697)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2569)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2660)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2623)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:339)
> at org.apache.ignite.Ignition.stop(Ignition.java:223)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1316)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1361)
> {noformat}
> The issue in the next line:
> {code:java}
> public GridJobProcessor(GridKernalContext ctx) {
> // Collision manager is already started and is fully functional.
> jobAlwaysActivate = !ctx.collision().enabled();
> activeJobs = jobAlwaysActivate ? new ConcurrentHashMap GridJobWorker>() :
> new JobsMap(1024, 0.75f, 256);
> {code}
> We need replace JobsMap with the correct implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14494) .NET: Problem with collection de/serialization
[ https://issues.apache.org/jira/browse/IGNITE-14494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov resolved IGNITE-14494. - Resolution: Resolved > .NET: Problem with collection de/serialization > -- > > Key: IGNITE-14494 > URL: https://issues.apache.org/jira/browse/IGNITE-14494 > Project: Ignite > Issue Type: Bug >Reporter: Yaroslav Molochkov >Priority: Major > Attachments: UnitTest.cs > > > Reproducer is attached. Basically the problem surfaces when you call > service's method via proxy. The method is supposed to return a collection > type result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14494) .NET: Problem with collection de/serialization
Yaroslav Molochkov created IGNITE-14494: --- Summary: .NET: Problem with collection de/serialization Key: IGNITE-14494 URL: https://issues.apache.org/jira/browse/IGNITE-14494 Project: Ignite Issue Type: Bug Reporter: Yaroslav Molochkov Attachments: UnitTest.cs Reproducer is attached. Basically the problem surfaces when you call service's method via proxy. The method is supposed to return a collection type result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17301668#comment-17301668
]
Yaroslav Molochkov commented on IGNITE-14214:
-
[~korlov], hello! Could you also take a look, please?
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-14214:
Comment: was deleted
(was: [~tledkov-gridgain], hello! Could you please take look?)
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287665#comment-17287665
]
Yaroslav Molochkov commented on IGNITE-14214:
-
[~tledkov-gridgain], hello! Could you please take look?
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287576#comment-17287576
]
Yaroslav Molochkov edited comment on IGNITE-14214 at 2/20/21, 7:36 AM:
---
[~tledkov-gridgain], hello! Could you please take look?
was (Author: yamolochkov):
[~alex_pl], could you please take look?
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287576#comment-17287576
]
Yaroslav Molochkov commented on IGNITE-14214:
-
[~alex_pl], could you please take look?
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-14214:
Affects Version/s: 2.10
2.9.1
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14214) Incorrect merge query when using oracle dialect
Yaroslav Molochkov created IGNITE-14214:
---
Summary: Incorrect merge query when using oracle dialect
Key: IGNITE-14214
URL: https://issues.apache.org/jira/browse/IGNITE-14214
Project: Ignite
Issue Type: Bug
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
If table contains only keys (e.g. relationship table) then returned query
contains empty update fields and resulting syntax is incorrect.
Consider the following example:
org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts key
and val collections. The problem is relevant if val collection is empty.
{code:java}
return String.format("MERGE INTO %s t" +
" USING (SELECT %s FROM dual) v" +
" ON %s" +
" WHEN MATCHED THEN" +
" UPDATE SET %s" +
" WHEN NOT MATCHED THEN" +
" INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols, colsLst,
valuesCols);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276576#comment-17276576 ] Yaroslav Molochkov edited comment on IGNITE-10958 at 2/2/21, 9:56 AM: -- Right now we, contrary to comments in other tickets, particularly here IGNITE-10973, we are not quite ready to migrate, because of two main things, that ignite tests rely heavily upon: suites and parameterized tests. Thing about suites is it's done with an old api using static methods to gather all needed classes in particular suite. That won't be an issue if JU5 would have supported that feature, but current solution is to use @RunWith and @SelectClasses/@SelectPackages. And the discussion about it is here https://github.com/junit-team/junit5/issues/744. This should be available relatively shortly and without that feature there would be a lot of repeated code. The worst part -- @BeforeClass and it's new JU5 version @BeforeAll doesn't work in suites right now. It is also mentioned in #744 The parameterised tests is another big issue: current JU5 version supports @ParameteizedTest which executes single test with several parameters (actually a stream of params). We have several tests that rely on exact opposite mechanism: run all tests in a class with one params preset, change preset and run all of the tests again, etc. This feature is requested and it would be very nice to have, otherwise some test runs would take forever or simply time out. Discussion about that feature is here https://stackoverflow.com/questions/54260954/junit-5-multiple-parametrized-tests-with-same-parameters-migrate-parameterized. To sum it up: not ready for JU5 without some custom questionable mechanisms. The description to the whole migration process is quite inaccurate and is available here https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4. Made some progress in migrating ignite to JU5 here https://github.com/ymolochkov/ignite/tree/junit5 was (Author: yamolochkov): Right now we, contrary to comments in other tickets, particularly here IGNITE-10973, we are not quite ready to migrate, because of two main things, that ignite tests rely heavily upon: suites and parameterized tests. Thing about suites is it's done with an old api using static methods to gather all needed classes in particular suite. That won't be an issue if JU5 would have supported that feature, but current solution is to use @RunWith and @SelectClasses/@SelectPackages. And the discussion about it is here https://github.com/junit-team/junit5/issues/744. This should be available relatively shortly and without that feature there would be a lot of repeated code. The parameterised tests is another big issue: current JU5 version supports @ParameteizedTest which executes single test with several parameters (actually a stream of params). We have several tests that rely on exact opposite mechanism: run all tests in a class with one params preset, change preset and run all of the tests again, etc. This feature is requested and it would be very nice to have, otherwise some test runs would take forever or simply time out. Discussion about that feature is here https://stackoverflow.com/questions/54260954/junit-5-multiple-parametrized-tests-with-same-parameters-migrate-parameterized. To sum it up: not ready for JU5 without some custom questionable mechanisms. The description is quite inaccurate and is available here https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4. Made some progress in migrating ignite to JU5 here https://github.com/ymolochkov/ignite/tree/junit5 > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass > -> BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled, Categories -> Tag > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the Maven surefire plugin to make it work with JUnit
[jira] [Commented] (IGNITE-10958) Migrate from Junit 4 to 5
[
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276576#comment-17276576
]
Yaroslav Molochkov commented on IGNITE-10958:
-
Right now we, contrary to comments in other tickets, particularly here
IGNITE-10973, we are not quite ready to migrate, because of two main things,
that ignite tests rely heavily upon: suites and parameterized tests.
Thing about suites is it's done with an old api using static methods to gather
all needed classes in particular suite. That won't be an issue if JU5 would
have supported that feature, but current solution is to use @RunWith and
@SelectClasses/@SelectPackages. And the discussion about it is here
https://github.com/junit-team/junit5/issues/744. This should be available
relatively shortly and without that feature there would be a lot of repeated
code.
The parameterised tests is another big issue: current JU5 version supports
@ParameteizedTest which executes single test with several parameters (actually
a stream of params). We have several tests that rely on exact opposite
mechanism: run all tests in a class with one params preset, change preset and
run all of the tests again, etc. This feature is requested and it would be very
nice to have, otherwise some test runs would take forever or simply time out.
Discussion about that feature is here
https://stackoverflow.com/questions/54260954/junit-5-multiple-parametrized-tests-with-same-parameters-migrate-parameterized.
To sum it up: not ready for JU5 without some custom questionable mechanisms.
The description is quite inaccurate and is available here
https://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4.
Made some progress in migrating ignite to JU5 here
https://github.com/ymolochkov/ignite/tree/junit5
> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId:
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher,
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass
> -> BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled, Categories -> Tag
> 4. Replace concept rules by extension model where it is necessary:
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace checking timeouts according to JUnit 5 concept: via
> {{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}
> 8. Change test suites running: @RunWith(Suit.class) to
> @Runwith(JunitPlatform.class)
> Investigation about migration to JUnit5 is provided in the ticket
> IGNITE-10180.
> [1]
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov resolved IGNITE-10973. - Resolution: Duplicate > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17276549#comment-17276549 ] Yaroslav Molochkov commented on IGNITE-10973: - Will be done within IGNITE-10958 context > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14071) .NET: Ignite messaging interoperability
[ https://issues.apache.org/jira/browse/IGNITE-14071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-14071: Attachment: Response.cs Request.cs > .NET: Ignite messaging interoperability > --- > > Key: IGNITE-14071 > URL: https://issues.apache.org/jira/browse/IGNITE-14071 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Yaroslav Molochkov >Priority: Major > Attachments: MessageHandler.java, Request.cs, Request.java, > Response.cs, Response.java, Test.cs > > > Currently IGNITE-10075 doesn't provide all needed type interoperability thus > ignite messaging works somewhat quirky. Thanks to [~kukushal] for pointing > that out. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14071) .NET: Ignite messaging interoperability
[ https://issues.apache.org/jira/browse/IGNITE-14071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-14071: Attachment: Response.java Request.java > .NET: Ignite messaging interoperability > --- > > Key: IGNITE-14071 > URL: https://issues.apache.org/jira/browse/IGNITE-14071 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Yaroslav Molochkov >Priority: Major > Attachments: MessageHandler.java, Request.cs, Request.java, > Response.cs, Response.java, Test.cs > > > Currently IGNITE-10075 doesn't provide all needed type interoperability thus > ignite messaging works somewhat quirky. Thanks to [~kukushal] for pointing > that out. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14071) .NET: Ignite messaging interoperability
Yaroslav Molochkov created IGNITE-14071: --- Summary: .NET: Ignite messaging interoperability Key: IGNITE-14071 URL: https://issues.apache.org/jira/browse/IGNITE-14071 Project: Ignite Issue Type: Improvement Affects Versions: 2.9.1 Reporter: Yaroslav Molochkov Attachments: MessageHandler.java, Test.cs Currently IGNITE-10075 doesn't provide all needed type interoperability thus ignite messaging works somewhat quirky. Thanks to [~kukushal] for pointing that out. Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-10958) Migrate from Junit 4 to 5
[
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov reassigned IGNITE-10958:
---
Assignee: Yaroslav Molochkov (was: Ivan Fedotov)
> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId:
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher,
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before -> BeforeEach, After -> AfterEach, BeforeClass
> -> BeforeAll, AfterClass -> AfterAll, Ignore -> Disabled, Categories -> Tag
> 4. Replace concept rules by extension model where it is necessary:
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> 7. Replace checking timeouts according to JUnit 5 concept: via
> {{@Test}}{{(timeout = }}{{1}}{{) or assertTimeout.}}
> 8. Change test suites running: @RunWith(Suit.class) to
> @Runwith(JunitPlatform.class)
> Investigation about migration to JUnit5 is provided in the ticket
> IGNITE-10180.
> [1]
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10973) Migrate example module tests from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov reassigned IGNITE-10973: --- Assignee: Yaroslav Molochkov (was: Ivan Fedotov) > Migrate example module tests from Junit 4 to 5 > -- > > Key: IGNITE-10973 > URL: https://issues.apache.org/jira/browse/IGNITE-10973 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Fedotov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: iep-30 > Time Spent: 0.5h > Remaining Estimate: 0h > > For more information refer parent task. > Migrate from Junit 4 to 5 in the example module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14020) .NET: Exceptions interoperability
Yaroslav Molochkov created IGNITE-14020: --- Summary: .NET: Exceptions interoperability Key: IGNITE-14020 URL: https://issues.apache.org/jira/browse/IGNITE-14020 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.9.1 Reporter: Yaroslav Molochkov Currently it's cumbersome to make use of .net exceptions because an exception is propagated from java-side reflection or local call hence we will see lots of unrelated and, more often than not, useless frames. To avoid that the exception from the .net side needs to have registered java counterpart so we can see the exact problem clearly. I propose to make exceptions interoperable just like types. We can resolve types between environments up to a namespace. It would be very useful to do the same with exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265836#comment-17265836
]
Yaroslav Molochkov commented on IGNITE-13949:
-
[~alex_pl], no, unfortunately I don't have the reproducer because I don't have
the context of the problem, yet the error in IGNITE-12854 is exactly the same
as I saw it.
Of course, the synchronisation will incur performance penalty, yet I find some
strange operations like incrementing value without lock, while some operations
with that same value are under the native lock. It very well could be the case
where we can get away without proper sync, of course, and there's a great
chance that I'm mistaken in my assumptions since I don't have a viable
reproduces or details of the situations where we can see that error.
But in any case, I think it's strange that we care for these little unsafe
optimisations yet we use native monitors, instead maybe we should use stamped
lock idioms for attempted non-blocking value change, etc, etc.
Furthermore, the PartitionUpdateCounterTrackingImpl's inheritance is not
prohibited while it is clearly is not designed for that purpose. And the way
the inheritance is implemented is it's subclass is kinda weird. In essence,
what I want to say is that client code might suffer because of said quirks.
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov resolved IGNITE-13949.
-
Resolution: Duplicate
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17265274#comment-17265274
]
Yaroslav Molochkov commented on IGNITE-13949:
-
[~alex_pl], could you please review my PR?
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
Yaroslav Molochkov created IGNITE-13949:
---
Summary: Insufficient synchronisation in
PartitionUpdateCounterTrackingImpl
Key: IGNITE-13949
URL: https://issues.apache.org/jira/browse/IGNITE-13949
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
Right now
org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
has 2 AtomicLong variables, cntr and reserveCntr, but there are some methods,
that are unsynchronised, e.g. next:
{code:java}
@Override public long next() {
long next = cntr.incrementAndGet();
reserveCntr.set(next);
return next;
} {code}
Even though both are AtomicLong, operation like "get then set" is a composite
one and should be atomic in the context of an object that holds these variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256892#comment-17256892
]
Yaroslav Molochkov commented on IGNITE-12508:
-
[~ivan.glukos], hello! Couldn't help but notice that cache descriptors are
stored in map as . In essence, we use hash code
as a crude map key here:
{code:java}
if (CU.cacheId(ccfg.getName()) == cacheId)
return cacheDesc; {code}
I suppose that's not entirely correct.
Consider the following snippet:
{code:java}
@Test
public void testCacheProcessor() {
IgniteEx ignite = grid(2);
String startedCache = "AaAaAa";
String assertedCache = "AaAaBB";
ignite.getOrCreateCache(startedCache);
GridCacheProcessor processor = ignite.context().cache();
DynamicCacheDescriptor dynamicCacheDescriptor =
processor.cacheDescriptor(CU.cacheId(assertedCache));
assertEquals(assertedCache, dynamicCacheDescriptor.cacheName());
} {code}
I
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
[
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13897:
Description:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
Method)
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService : IService
{
int processSomething(int foo, Parameter[] parameters);
int processSomething(int foo, int bar);
}
public class Parameter
{
private int id;
private ParamValue[] _values;
public Parameter(int id, ParamValue[] _values)
{
this.id = id;
this._values = _values;
}
}
public class ParamValue
{
private int id;
private double val;
public ParamValue(int id, double val)
{
this.id = id;
this.val = val;
}
}
{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Please note, that if there's no overloaded methods, at least in our experiments
we found out that it does reproduce with equal number of parameters in
overloaded methods (e.g. here we have overloaded methods that take 2 parameters
each), then the code works like a charm.
Fix in IGNITE-12823 addresses particular code execution path where the
execution flow goes through PlatformServices class. Yet in this case our code
goes through PlatformAbstractService. I think that the fix of casting arrays
should be positioned a little bit lower in the call stack (or higher in code
hierarchy) so all execution paths are covered simultaneously.
was:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
[jira] [Updated] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
[
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13897:
Description:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
Method)
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService : IService
{
int processSomething(int foo, Parameter[] parameters);
int processSomething(int foo, int bar);
}
public class Parameter
{
private int id;
private ParamValue[] _values;
public Parameter(int id, ParamValue[] _values)
{
this.id = id;
this._values = _values;
}
}
public class ParamValue
{
private int id;
private double val;
public ParamValue(int id, double val)
{
this.id = id;
this.val = val;
}
}
{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Please note, that if there's no overloaded methods, at least in our experiments
we found out that it does reproduces with equal number of parameters in
overloaded methods (e.g. here we have overloaded methods that take 2 parameters
each), then the code works like a charm.
Fix in IGNITE-12823 addresses particular code execution path where the
execution flow goes through PlatformServices class. Yet in this case our code
goes through PlatformAbstractService. I think that the fix of casting arrays
should be positioned a little bit lower in the call stack (or higher in code
hierarchy) so all execution paths are covered simultaneously.
was:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
[jira] [Commented] (IGNITE-13884) Merge docs from ignite-2.9-docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254156#comment-17254156 ] Yaroslav Molochkov commented on IGNITE-13884: - [~mstekl], [~dmagda], thanks a lot, guys. I think me and Maxim will take it from here. > Merge docs from ignite-2.9-docs into 2.9.1 > -- > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Fix For: 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > The documentation contained in ignite-2.9-docs branch needs to be merged into > 2.9.1 branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
[
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13897:
Description:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
Method)
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService : IService
{
int processSomething(int foo, Parameter[] parameters);
}
public class Parameter
{
private int id;
private ParamValue[] _values;
public Parameter(int id, ParamValue[] _values)
{
this.id = id;
this._values = _values;
}
}
public class ParamValue
{
private int id;
private double val;
public ParamValue(int id, double val)
{
this.id = id;
this.val = val;
}
}
{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Now, if this is a server node then call is successful. If the call goes from
the client node then we'll get the error above.
Fix in IGNITE-12823 addresses particular code execution path where the
execution flow goes through PlatformServices class. Yet in this case our code
goes through PlatformAbstractService. I think that the fix of casting arrays
should be positioned a little bit lower in the call stack (or higher in code
hierarchy) so all execution paths are covered simultaneously.
was:
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
[jira] [Assigned] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
[
https://issues.apache.org/jira/browse/IGNITE-13897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov reassigned IGNITE-13897:
---
Assignee: (was: Yaroslav Molochkov)
> .NET Service can't assign correct type to passed array parameters
> -
>
> Key: IGNITE-13897
> URL: https://issues.apache.org/jira/browse/IGNITE-13897
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Yaroslav Molochkov
>Priority: Major
>
> This issue relates to IGNITE-12823.
> Ignite client calls deployed service and fails with the following exception:
> {code:java}
> Apache.Ignite.Core.Common.JavaException: class
> org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
> 'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
> Method)
> at
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
> at
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
> at
> org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
> at
> org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Service interface itself looks like this:
> {code:java}
> public interface SomeService
> {
> int processSomething(int foo, Parameter[] parameters);
> }
> public class Parameter
{
> private int id;
> private ParamValue[] _values;
> public Parameter(int id, ParamValue[] _values)
{
>this.id = id;
>this._values = _values;
> }
>
}
>
public class ParamValue
{
> private int id;
> private double val;
> public ParamValue(int id, double val)
{
>this.id = id;
>this.val = val;
> }
>
}
> {code}
> And the call to the service:
> {code:java}
> var svc = igniteServices.GetServiceProxy(name, false);
> var result = svc.processSomething(id, parameters);
> {code}
> Now, if this is a server node then call is successful. If the call goes from
> the client node then we'll get the error above.
> Fix in IGNITE-12823 addresses particular code execution path where the
> execution flow goes through PlatformServices class. Yet in this case our code
> goes through PlatformAbstractService. I
[jira] [Created] (IGNITE-13897) .NET Service can't assign correct type to passed array parameters
Yaroslav Molochkov created IGNITE-13897:
---
Summary: .NET Service can't assign correct type to passed array
parameters
Key: IGNITE-13897
URL: https://issues.apache.org/jira/browse/IGNITE-13897
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.9
Reporter: Yaroslav Molochkov
Assignee: Yaroslav Molochkov
This issue relates to IGNITE-12823.
Ignite client calls deployed service and fails with the following exception:
{code:java}
Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteException: Failed to invoke proxy: there is no method
'processSomething' in type 'SomeService' with (Int32, Object[]) arguments
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
Method)
at
org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.serviceInvokeMethod(PlatformCallbackGateway.java:942)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:214)
at
org.apache.ignite.internal.processors.platform.services.PlatformAbstractService.invokeMethod(PlatformAbstractService.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.callService(GridServiceProxy.java:491)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:469)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1847)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:598)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7077)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:592)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:521)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1368)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2130)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:241)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
Service interface itself looks like this:
{code:java}
public interface SomeService
{
int processSomething(int foo, Parameter[] parameters);
}
public class Parameter
{
private int id;
private ParamValue[] _values;
public Parameter(int id, ParamValue[] _values)
{
this.id = id;
this._values = _values;
}
}
public class ParamValue
{
private int id;
private double val;
public ParamValue(int id, double val)
{
this.id = id;
this.val = val;
}
}
{code}
And the call to the service:
{code:java}
var svc = igniteServices.GetServiceProxy(name, false);
var result = svc.processSomething(id, parameters);
{code}
Now, if this is a server node then call is successful. If the call goes from
the client node then we'll get the error above.
Fix in IGNITE-12823 addresses particular code execution path where the
execution flow goes through PlatformServices class. Yet in this case our code
goes through PlatformAbstractService. I think that the fix of casting arrays
should be positioned a little bit lower in the call stack (or higher in code
hierarchy) so all execution paths are covered simultaneously.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13884) Merge docs from ignite-2.9-docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253562#comment-17253562 ] Yaroslav Molochkov commented on IGNITE-13884: - [~dmagda] actually 2.9.1 wasn't created from master but from 2.9 by tag checkout, so I would imagine that we need all the documentation commits starting from the commit that uses new documentation engine up to the last documentation commit in 2.9 + my commit that updates system views documentation. > Merge docs from ignite-2.9-docs into 2.9.1 > -- > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > > The documentation contained in ignite-2.9-docs branch needs to be merged into > 2.9.1 branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13884) Merge docs from ignite-2.9-docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13884: Description: The documentation contained in ignite-2.9-docs branch needs to be merged into 2.9.1 branch > Merge docs from ignite-2.9-docs into 2.9.1 > -- > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > > The documentation contained in ignite-2.9-docs branch needs to be merged into > 2.9.1 branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13884) Merge docs from ignite-2.9-docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13884: Summary: Merge docs from ignite-2.9-docs into 2.9.1 (was: Merge 2.9 docs into 2.9.1) > Merge docs from ignite-2.9-docs into 2.9.1 > -- > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13884) Merge 2.9 docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13884: Fix Version/s: 2.9.1 > Merge 2.9 docs into 2.9.1 > - > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Fix For: 2.9.1 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13884) Merge 2.9 docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13884: Summary: Merge 2.9 docs into 2.9.1 (was: Merge docs into 2.9.1) > Merge 2.9 docs into 2.9.1 > - > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13884) Merge docs into 2.9.1
[ https://issues.apache.org/jira/browse/IGNITE-13884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17253430#comment-17253430 ] Yaroslav Molochkov commented on IGNITE-13884: - [~dma...@apache.org], can you please take a look at merged documentation commits? Since 2.9 docs are in separate branch I have to merge it like this > Merge docs into 2.9.1 > - > > Key: IGNITE-13884 > URL: https://issues.apache.org/jira/browse/IGNITE-13884 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13884) Merge docs into 2.9.1
Yaroslav Molochkov created IGNITE-13884: --- Summary: Merge docs into 2.9.1 Key: IGNITE-13884 URL: https://issues.apache.org/jira/browse/IGNITE-13884 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13876) Update documentation for 2.9.1 release
[ https://issues.apache.org/jira/browse/IGNITE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17252729#comment-17252729 ] Yaroslav Molochkov commented on IGNITE-13876: - [~dma...@apache.org] what should we do with docs if they are in a separate branch (2.9-docs)? Create another branch for the same purposes or merge docs to the release branch? > Update documentation for 2.9.1 release > -- > > Key: IGNITE-13876 > URL: https://issues.apache.org/jira/browse/IGNITE-13876 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Critical > Fix For: 2.9.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The update should reflect changes made to system views(BINARY_METADATA and > METASTORAGE) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13876) Update documentation for 2.9.1 release
[ https://issues.apache.org/jira/browse/IGNITE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13876: Issue Type: Task (was: Bug) > Update documentation for 2.9.1 release > -- > > Key: IGNITE-13876 > URL: https://issues.apache.org/jira/browse/IGNITE-13876 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Critical > Fix For: 2.9.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The update should reflect changes made to system views(BINARY_METADATA and > METASTORAGE) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13876) Update documentation for 2.9.1 release
[ https://issues.apache.org/jira/browse/IGNITE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13876: Description: The update should reflect changes made to system views(BINARY_METADATA and METASTORAGE) (was: The update should reflect changes made to system views(BINARY_METADATA and DISTRIBUTED_METASTORAGE) and metrics (RebalancingPartitionsTotal)) > Update documentation for 2.9.1 release > -- > > Key: IGNITE-13876 > URL: https://issues.apache.org/jira/browse/IGNITE-13876 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Critical > Fix For: 2.9.1 > > > The update should reflect changes made to system views(BINARY_METADATA and > METASTORAGE) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13876) Update documentation for 2.9.1 release
[ https://issues.apache.org/jira/browse/IGNITE-13876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13876: Fix Version/s: 2.9.1 > Update documentation for 2.9.1 release > -- > > Key: IGNITE-13876 > URL: https://issues.apache.org/jira/browse/IGNITE-13876 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Critical > Fix For: 2.9.1 > > > The update should reflect changes made to system views(BINARY_METADATA and > DISTRIBUTED_METASTORAGE) and metrics (RebalancingPartitionsTotal) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13876) Update documentation for 2.9.1 release
Yaroslav Molochkov created IGNITE-13876: --- Summary: Update documentation for 2.9.1 release Key: IGNITE-13876 URL: https://issues.apache.org/jira/browse/IGNITE-13876 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov The update should reflect changes made to system views(BINARY_METADATA and DISTRIBUTED_METASTORAGE) and metrics (RebalancingPartitionsTotal) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13734) .NET Service loses returned array type information
[
https://issues.apache.org/jira/browse/IGNITE-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249718#comment-17249718
]
Yaroslav Molochkov edited comment on IGNITE-13734 at 12/15/20, 2:35 PM:
[~nizhikov], [~ptupitsyn],
there's one idea: is it worth the effort to modify returned array from a
reflection call? We have to create one and then move each element to the newly
created array. That's double the memory and O\(n\) complexity. And not every
client code needs that cast. And then, it's not really consistent if client
code will receive casted array and, for example, not parametrised list.
was (Author: yamolochkov):
[~nizhikov], [~ptupitsyn],
there's one idea: is it worth the effort to modify returned array from a
reflection call? We have to create one and then move each element to the newly
created array. That's double the memory and O\(n\) complexity. And not every
client code need that cast. And then, it's not really consistent if client code
will receive casted array and, for example, not parametrised list.
> .NET Service loses returned array type information
> --
>
> Key: IGNITE-13734
> URL: https://issues.apache.org/jira/browse/IGNITE-13734
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
>
> .NET service client receives Object[] instead of strongly typed array from a
> .NET service.
> There was another already resolved similar issue IGNITE-12823 that addressed
> the problem of using arrays as parameters. The problem of using arrays as
> results still exists.
> h3. Reproducer
> A .NET service returning an array of user-defined types is deployed:
> {code:c#}
> public interface ITestService
> {
> Parameter[] TestReturnParametersArray();
> }
> public sealed class Parameter
> {
> public int Id { get; set; }
> public int[] Values { get; set; }
> }
> {code}
> A .NET client calls the service:
> {code:c#}
> Parameter[] res = svcProxy.TestReturnParametersArray()
> {code}
> The service call fails with exception:
> {code}
> System.InvalidCastException : Unable to cast object of type 'System.Object[]'
> to type 'Parameter[]'.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13734) .NET Service loses returned array type information
[
https://issues.apache.org/jira/browse/IGNITE-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249718#comment-17249718
]
Yaroslav Molochkov edited comment on IGNITE-13734 at 12/15/20, 2:25 PM:
[~nizhikov], [~ptupitsyn],
there's one idea: is it worth the effort to modify returned array from a
reflection call? We have to create one and then move each element to the newly
created array. That's double the memory and O\(n\) complexity. And not every
client code need that cast. And then, it's not really consistent if client code
will receive casted array and, for example, not parametrised list.
was (Author: yamolochkov):
[~nizhikov], [~ptupitsyn],
there's one idea: is it worth the effort to modify returned array from a
reflection call? We have to create one and then move each element to the newly
created array. That's double the memory and O(n) complexity. And not every
client code need that cast. And then, it's not really consistent if client code
will receive casted array and, for example, not parametrised list.
> .NET Service loses returned array type information
> --
>
> Key: IGNITE-13734
> URL: https://issues.apache.org/jira/browse/IGNITE-13734
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
>
> .NET service client receives Object[] instead of strongly typed array from a
> .NET service.
> There was another already resolved similar issue IGNITE-12823 that addressed
> the problem of using arrays as parameters. The problem of using arrays as
> results still exists.
> h3. Reproducer
> A .NET service returning an array of user-defined types is deployed:
> {code:c#}
> public interface ITestService
> {
> Parameter[] TestReturnParametersArray();
> }
> public sealed class Parameter
> {
> public int Id { get; set; }
> public int[] Values { get; set; }
> }
> {code}
> A .NET client calls the service:
> {code:c#}
> Parameter[] res = svcProxy.TestReturnParametersArray()
> {code}
> The service call fails with exception:
> {code}
> System.InvalidCastException : Unable to cast object of type 'System.Object[]'
> to type 'Parameter[]'.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13734) .NET Service loses returned array type information
[
https://issues.apache.org/jira/browse/IGNITE-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249718#comment-17249718
]
Yaroslav Molochkov commented on IGNITE-13734:
-
[~nizhikov], [~ptupitsyn],
there's one idea: is it worth the effort to modify returned array from a
reflection call? We have to create one and then move each element to the newly
created array. That's double the memory and O(n) complexity. And not every
client code need that cast. And then, it's not really consistent if client code
will receive casted array and, for example, not parametrised list.
> .NET Service loses returned array type information
> --
>
> Key: IGNITE-13734
> URL: https://issues.apache.org/jira/browse/IGNITE-13734
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
>
> .NET service client receives Object[] instead of strongly typed array from a
> .NET service.
> There was another already resolved similar issue IGNITE-12823 that addressed
> the problem of using arrays as parameters. The problem of using arrays as
> results still exists.
> h3. Reproducer
> A .NET service returning an array of user-defined types is deployed:
> {code:c#}
> public interface ITestService
> {
> Parameter[] TestReturnParametersArray();
> }
> public sealed class Parameter
> {
> public int Id { get; set; }
> public int[] Values { get; set; }
> }
> {code}
> A .NET client calls the service:
> {code:c#}
> Parameter[] res = svcProxy.TestReturnParametersArray()
> {code}
> The service call fails with exception:
> {code}
> System.InvalidCastException : Unable to cast object of type 'System.Object[]'
> to type 'Parameter[]'.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13734) .NET Service loses returned array type information
[
https://issues.apache.org/jira/browse/IGNITE-13734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17248895#comment-17248895
]
Yaroslav Molochkov commented on IGNITE-13734:
-
[~kukushal], I think we need to investigate .net ability to cast results to the
needed type, so it might turn out that this ticket is not needed
> .NET Service loses returned array type information
> --
>
> Key: IGNITE-13734
> URL: https://issues.apache.org/jira/browse/IGNITE-13734
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Nikolai Kulagin
>Priority: Major
>
> .NET service client receives Object[] instead of strongly typed array from a
> .NET service.
> There was another already resolved similar issue IGNITE-12823 that addressed
> the problem of using arrays as parameters. The problem of using arrays as
> results still exists.
> h3. Reproducer
> A .NET service returning an array of user-defined types is deployed:
> {code:c#}
> public interface ITestService
> {
> Parameter[] TestReturnParametersArray();
> }
> public sealed class Parameter
> {
> public int Id { get; set; }
> public int[] Values { get; set; }
> }
> {code}
> A .NET client calls the service:
> {code:c#}
> Parameter[] res = svcProxy.TestReturnParametersArray()
> {code}
> The service call fails with exception:
> {code}
> System.InvalidCastException : Unable to cast object of type 'System.Object[]'
> to type 'Parameter[]'.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13839) TeamCity release assembly git issue
Yaroslav Molochkov created IGNITE-13839:
---
Summary: TeamCity release assembly git issue
Key: IGNITE-13839
URL: https://issues.apache.org/jira/browse/IGNITE-13839
Project: Ignite
Issue Type: Bug
Reporter: Yaroslav Molochkov
Currently there is a problem with script "vote_1[git]create_rc_tag" execution:
{code}
error: object directory /opt/buildagent/system/git/git-BF1D6845.git/objects
does not exist; check .git/objects/info/alternates
error: refs/heads/ignite-2.9 does not point to a valid object!
error: refs/remotes/origin/ignite-2.9 does not point to a valid object!
error: refs/tags/1.1.3 does not point to a valid object!
{code}
The problem is with mirroring option for TC VCS root.
Possible solution: redesign release build to require native checked out
repository, not mirrored one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13806) Merge release notes for 2.9.1 into master
[ https://issues.apache.org/jira/browse/IGNITE-13806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242658#comment-17242658 ] Yaroslav Molochkov commented on IGNITE-13806: - [~mmuzaf], release notes for 291 > Merge release notes for 2.9.1 into master > - > > Key: IGNITE-13806 > URL: https://issues.apache.org/jira/browse/IGNITE-13806 > Project: Ignite > Issue Type: Task >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13806) Merge release notes for 2.9.1 into master
Yaroslav Molochkov created IGNITE-13806: --- Summary: Merge release notes for 2.9.1 into master Key: IGNITE-13806 URL: https://issues.apache.org/jira/browse/IGNITE-13806 Project: Ignite Issue Type: Task Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13695: Fix Version/s: (was: 2.9.1) 2.10 > Move javadoc of affection of several addresses on failure detection. > > > Key: IGNITE-13695 > URL: https://issues.apache.org/jira/browse/IGNITE-13695 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Current javadoc of affection several node addresses of failure detection is > located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by > `TcpDiscoverySpi.setLocalAddress()`. > Perhaps, the text might be slightly changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13755) .NET: Inspections fail after TC upgrade - unused classes detected
[
https://issues.apache.org/jira/browse/IGNITE-13755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13755:
Fix Version/s: (was: 2.9.1)
> .NET: Inspections fail after TC upgrade - unused classes detected
> -
>
> Key: IGNITE-13755
> URL: https://issues.apache.org/jira/browse/IGNITE-13755
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> Enum 'CacheFlags' is never used
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13450) Add event fired before query execution
[
https://issues.apache.org/jira/browse/IGNITE-13450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13450:
Fix Version/s: (was: 2.9.1)
> Add event fired before query execution
> --
>
> Key: IGNITE-13450
> URL: https://issues.apache.org/jira/browse/IGNITE-13450
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Labels: event
> Fix For: 2.10
>
> Time Spent: 8.5h
> Remaining Estimate: 0h
>
> Create {{SQLQueryExecutionEvent}}, which will be fired before SQL query
> execution.
> Required fields are:
> - text of a query (with hidden arguments);
> - arguments of query;
> - query type;
> - node id.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13426) Add command to control.(sh|bin) to get an arbitrary SystemView
[ https://issues.apache.org/jira/browse/IGNITE-13426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13426: Fix Version/s: (was: 2.9.1) > Add command to control.(sh|bin) to get an arbitrary SystemView > -- > > Key: IGNITE-13426 > URL: https://issues.apache.org/jira/browse/IGNITE-13426 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: 2.9.1-rc, important > Fix For: 2.10 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > It's needed to add the ability to get an arbitrary SystemView via > control.(sh|bin) script. > Proposed command structure: > control.(sh|bin) --system-view [–node-id node_id] system_view_name > Parameters: > system_view_name - Name of the system view which value is requested. > Both "SQL" and "common" styles > of system view name are supported > (e.g. SQL_TABLES and sql.tables > will be handled similarly). > node_id - ID of the node to get the system view > from. > If not set, random node will be > chosen. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13702) Fix description of soLinger for DiscoveryTcpSpi.
[ https://issues.apache.org/jira/browse/IGNITE-13702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13702: Fix Version/s: (was: 2.9.1) > Fix description of soLinger for DiscoveryTcpSpi. > > > Key: IGNITE-13702 > URL: https://issues.apache.org/jira/browse/IGNITE-13702 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.10 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.9, 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Fix description of soLibger for DiscoveryTcpSpi. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13635) .NET: OOM due to integer overflow in PlatformOutputStream
[
https://issues.apache.org/jira/browse/IGNITE-13635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13635:
Fix Version/s: (was: 2.9.1)
> .NET: OOM due to integer overflow in PlatformOutputStream
> -
>
> Key: IGNITE-13635
> URL: https://issues.apache.org/jira/browse/IGNITE-13635
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 1.4, 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Fix For: 2.10
>
>
> {{PlatformOutputStreamImpl.unsafeEnsure}} causes integer overflow, then
> passes a negative value to {{PlatformCallbackGateway.memoryReallocate}} from
> there it is passed to {{Marshal.ReAllocHGlobal}}, which throws an
> OutOfMemoryException.
> Reproducer:
> {code}
> var val = new byte[100_000_000];
> var ignite = Ignition.Start();
> var cache = ignite.CreateCache("c");
> for (int i = 0; i < 30; i++) // ~3GB of cache data
> cache[i] = val;
> cache.Query(new ScanQuery()).GetAll();
> {code}
> We should handle this condition gracefully: detect stream size limit and
> throw an exception explaining how to fix the problem (use smaller pageSize
> for queries, for example).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13770) Ignite.dataRegionMetrics throws NPE with empty persisted region
[
https://issues.apache.org/jira/browse/IGNITE-13770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13770:
Fix Version/s: (was: 2.9.1)
2.10
> Ignite.dataRegionMetrics throws NPE with empty persisted region
> ---
>
> Key: IGNITE-13770
> URL: https://issues.apache.org/jira/browse/IGNITE-13770
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Labels: easyfix
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointBufferPagesCount(PageMemoryImpl.java:1823)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl.getUsedCheckpointBufferPages(DataRegionMetricsImpl.java:287)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsSnapshot.(DataRegionMetricsSnapshot.java:108)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.memoryMetrics(IgniteCacheDatabaseSharedManager.java:815)
> at
> org.apache.ignite.internal.IgniteKernal.dataRegionMetrics(IgniteKernal.java:3773)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13760) .NET: GetAffinity fails with NullPointerException on client node
[
https://issues.apache.org/jira/browse/IGNITE-13760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13760:
Fix Version/s: (was: 2.9.1)
> .NET: GetAffinity fails with NullPointerException on client node
>
>
> Key: IGNITE-13760
> URL: https://issues.apache.org/jira/browse/IGNITE-13760
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Alexey Kukushkin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Given there are Ignite.NET server and client nodes
> * When the server node creates a cache and then the client node immediately
> gets affinity for the cache
> * Then getting affinity fails with NullPointerException
> {code:c#}
> IgniteConfiguration IgniteCfg(bool clientMode = false) => new
> IgniteConfiguration
> {
> ClientMode = clientMode,
> IgniteInstanceName = Guid.NewGuid().ToString(),
> DiscoverySpi = new TcpDiscoverySpi
> {
> IpFinder = new TcpDiscoveryStaticIpFinder
> {
> Endpoints = new[] { "127.0.0.1:47500" }
> }
> }
> };
> using var igniteSrv = Ignition.Start(IgniteCfg());
> using var igniteClient = Ignition.Start(IgniteCfg(true));
> var cache1 = igniteSrv.GetOrCreateCache("cache1");
> igniteClient.GetAffinity("cache1");
> {code}
> The igniteClient.GetAffinity fails with this exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException
> HResult=0x80131500
> Message=Java exception occurred [class=java.lang.NullPointerException,
> message=]
> Source=Apache.Ignite.Core
> StackTrace:
>at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
>at Apache.Ignite.Core.Impl.PlatformTargetAdapter.DoOutOpObject(Int32 type,
> Action`1 action)
>at
> Apache.Ignite.Core.Impl.Ignite.Apache.Ignite.Core.Impl.IIgniteInternal.GetAffinity(String
> cacheName)
>at Apache.Ignite.Core.Impl.Ignite.GetAffinity(String cacheName)
>at DotNet.Sandbox.Program.Main(String[] args) in
> C:\Dev\tmp\DotNet.Sandbox\Program.cs:line 32
> This exception was originally thrown at this call stack:
> Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.ExceptionCheck()
>
> Apache.Ignite.Core.Impl.Unmanaged.Jni.Env.CallObjectMethod(Apache.Ignite.Core.Impl.Unmanaged.Jni.GlobalRef,
> System.IntPtr, long*)
>
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInStreamOutObject(Apache.Ignite.Core.Impl.Unmanaged.Jni.GlobalRef,
> int, long)
> Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(int,
> System.Action)
> Inner Exception 1:
> JavaException: java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.platform.cache.affinity.PlatformAffinity.(PlatformAffinity.java:125)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutObject(PlatformProcessorImpl.java:640)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> {code}
> h1. Workaround
> Add {{GetCache}} call before {{GetAffinity}}:
> {code:c#}
> ...
> var cache1 = igniteSrv.GetOrCreateCache("cache1");
> igniteClient.GetCache("cache1");
> igniteClient.GetAffinity("cache1");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13588) .NET: Returns the full name of the specified type without any assembly version info. The reason why this method is needed is that a generic type's FullName contains the
[ https://issues.apache.org/jira/browse/IGNITE-13588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13588: Fix Version/s: (was: 2.9.1) 2.10 > .NET: Returns the full name of the specified type without any assembly > version info. The reason why this method is needed is that a generic type's > FullName contains the full AssemblyQualifiedName of its item type. > -- > > Key: IGNITE-13588 > URL: https://issues.apache.org/jira/browse/IGNITE-13588 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.9, 2.8.1 > Environment: Apache Ignite: v2.8.1 > JDK: v1.8 > .NET Core: v3.1 >Reporter: Danut Radoaica >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, 2.9.1-rc > Fix For: 2.10 > > Attachments: Untitled.png > > Time Spent: 40m > Remaining Estimate: 0h > > Returns the full name of the specified type without any assembly version > info. The reason why this method is needed is that a generic type's FullName > contains the full AssemblyQualifiedName of its item type. > ([https://github.com/apache/ignite/pull/8337)|https://github.com/apache/ignite/pull/8337] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13639) .NET: No coercion operator is defined between types 'System.Int32' and 'swagger.Models.IndexParameter[]'.
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13639:
Fix Version/s: (was: 2.9.1)
2.10
> .NET: No coercion operator is defined between types 'System.Int32' and
> 'swagger.Models.IndexParameter[]'.
> -
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, 2.9.1-rc
> Fix For: 2.10
>
> Attachments: BotXEntityDto.cs, exception.txt, stream_dump.txt
>
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> ignite 2.8.1: it works
> ignite 2.9.0:
> this works:
> ICacheClient botXEntityCacheClient =
> _igniteManager.GetOrCreateCacheClient BotXEntityDto[]>($"\{MLConstants.APPLICATION_NAME}#\{nameof(BotXEntityCacheManager)}")
> .WithExpiryPolicy(new ExpiryPolicy(TimeSpan.FromHours(3),
> TimeSpan.FromHours(3), TimeSpan.FromHours(3)));
> *await botXEntityCacheClient.PutAsync(tenant.Id.Value,
> tenantBotRelatedEntities.Items.ToArray()).ConfigureAwait(false);*
> and the same key does not work with:
> ICacheClient botXEntityCacheClient =
> _igniteManager.GetOrCreateCacheClient BotXEntityDto[]>($"\{MLConstants.APPLICATION_NAME}#\{nameof(BotXEntityCacheManager)}")
> .WithExpiryPolicy(new ExpiryPolicy(TimeSpan.FromHours(3),
> TimeSpan.FromHours(3), TimeSpan.FromHours(3)));
> {color:#ff}*CacheResult cacheResult = await
> botXEntityCacheClient.TryGetAsync(tenantId).ConfigureAwait(false);*{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13636) ODBC driver assigns SQL_BINARY type to DATE fields
[
https://issues.apache.org/jira/browse/IGNITE-13636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13636:
Fix Version/s: (was: 2.9.1)
2.10
> ODBC driver assigns SQL_BINARY type to DATE fields
> --
>
> Key: IGNITE-13636
> URL: https://issues.apache.org/jira/browse/IGNITE-13636
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.9
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: odbc
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> "The DATE types should not be reported as SQL_BINARY. They should be returned
> as SQL_DATE"
> {noformat}
> DATE_FIELD DataType SQL_BINARY, DecimalDigits 0, Nullable 2, ColumnSize 10,
> UnsignedNumber 1, is_output_column
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12126) ODBC: SQLNumResultCols for prepared statement
[ https://issues.apache.org/jira/browse/IGNITE-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-12126: Fix Version/s: (was: 2.9.1) 2.10 > ODBC: SQLNumResultCols for prepared statement > - > > Key: IGNITE-12126 > URL: https://issues.apache.org/jira/browse/IGNITE-12126 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.7.5 > Environment: Windows 7 >Reporter: AH >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > According to ODBC Programmer's Reference, SQLNumResultCols can be called > successfully only when the statement is in the prepared, executed, or > positioned state. > However, it is not working when the statement is in the prepared state and > not yet executed: column count returned is 0. > > Full Connect(Default) > Env. Attr. SQL_ATTR_ODBC_VERSION set to SQL_OV_ODBC3 > Successfully connected to DSN 'Apache Ignite DSN'. > SQLExecDirect: > In: Statementhandle = 0x005C3828, > StatementText = "SELECT * FROM M.I where 1 = 0", Statementlength = 37 > Return: SQL_SUCCESS=0 > SQLNumResultCols: > In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 > Return: SQL_SUCCESS=0 > Out: *ColumnCountPtr = 20 > SQLPrepare: > In: StatementHandle = 0x005C3828, > StatementText = "SELECT * FROM M.I where 1 = 0", TextLength = 37 > Return: SQL_SUCCESS=0 > SQLExecute: > In: StatementHandle = 0x005C3828 > Return: SQL_SUCCESS=0 > SQLNumResultCols: > In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 > Return: SQL_SUCCESS=0 > Out: *ColumnCountPtr = 20 > > Not working: > SQLPrepare: > In: StatementHandle = 0x005C3828, > StatementText = "SELECT * FROM M.I where 1 = 0", TextLength = 37 > Return: SQL_SUCCESS=0 > SQLNumResultCols: > In: StatementHandle = 0x005C3828, ColumnCountPtr = 0x0061EDC8 > Return: SQL_SUCCESS=0 > Out: *ColumnCountPtr = 0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13572) Duplicates in select query during partition eviction for caches with 0 backups
[ https://issues.apache.org/jira/browse/IGNITE-13572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13572: Fix Version/s: (was: 2.9.1) 2.10 > Duplicates in select query during partition eviction for caches with 0 backups > -- > > Key: IGNITE-13572 > URL: https://issues.apache.org/jira/browse/IGNITE-13572 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.9, 2.8.1 >Reporter: Ivan Daschinskiy >Assignee: Konstantin Sirotkin >Priority: Major > Fix For: 2.10 > > Attachments: SqlPartitionEvictionTest.java > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Scenario: > # Start 2 nodes with indexed atomic partitioned cache with 0 backups. > # Load sufficient amout of data (or emulate slow removal from idx) > # Start another node. > # Perform SELECT * FROM . > Query result contains duplicates, result size is significantly bigger than > expected cache size. > Reproducer is attached. > Reproduced on 2.8.1, ongoing 2.9 and master -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13435) Fixing some unrecorded issues command warm-up control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13435: Fix Version/s: (was: 2.9.1) > Fixing some unrecorded issues command warm-up control.sh > > > Key: IGNITE-13435 > URL: https://issues.apache.org/jira/browse/IGNITE-13435 > Project: Ignite > Issue Type: Bug > Components: control.sh >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: 2.9.1-rc, IEP-40 > Fix For: 2.10 > > Time Spent: 50m > Remaining Estimate: 0h > > Unrecorded problems: > * When parsing arguments for the warm-up command, subsequent arguments may be > skipped, such as auto-confirmation "--yes"; > * Processing requests for jetty; > * Authorization. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13363) GridDhtCacheEntry::toString locks
[
https://issues.apache.org/jira/browse/IGNITE-13363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13363:
Fix Version/s: (was: 2.9.1)
> GridDhtCacheEntry::toString locks
> -
>
> Key: IGNITE-13363
> URL: https://issues.apache.org/jira/browse/IGNITE-13363
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.8.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> `GridDhtCacheEntry::toString` locks the entry which may lead to dead locks
> and, I assume, even performance issues.
> We, naturally, call `toString` on everything all the time and it needs to be
> the safest and the lightest possible operation.
> Example of a hang with locking toString:
>
> {{Thread [name="grid-timeout-worker-#71%GRIDC1%", id=98, state=WAITING,
> blockCnt=2, waitCnt=14196]
> Lock
> [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@20c96143,
> ownerName=exchange-worker-#188%GRIDC1%, ownerId=265]
> at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method)
> at
> java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:885)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:917)
> at
> java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1240)
> at
> java.base@11.0.2/java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:267)
> at
> app//o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:5051)
> at
> app//o.a.i.i.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:819)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1273)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at
> java.base@11.0.2/java.lang.StringBuilder.append(StringBuilder.java:168)
> at
> java.base@11.0.2/java.util.AbstractCollection.toString(AbstractCollection.java:473)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
> at
> app//o.a.i.i.processors.cache.distributed.GridDistributedTxMapping.toString(GridDistributedTxMapping.java:319)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
> at
> app//o.a.i.i.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:864)
> at
> app//o.a.i.i.processors.cache.distributed.near.IgniteTxMappingsSingleImpl.toString(IgniteTxMappingsSingleImpl.java:99)
> at java.base@11.0.2/java.lang.String.valueOf(String.java:2951)
> at app//o.a.i.i.util.GridStringBuilder.a(GridStringBuilder.java:101)
> at
> app//o.a.i.i.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
> at
>
[jira] [Updated] (IGNITE-13373) WAL segmentns do not released on releaseHistoryForPreloading()
[ https://issues.apache.org/jira/browse/IGNITE-13373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13373: Fix Version/s: (was: 2.9.1) > WAL segmentns do not released on releaseHistoryForPreloading() > -- > > Key: IGNITE-13373 > URL: https://issues.apache.org/jira/browse/IGNITE-13373 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > * Reserve/releaseHistoryForPreloading() was reworked, now we store oldest > WALPointer that was reserved during reserveHistoryForPreloading in > reservedForPreloading field. As a result it's possible to release wall > reservation on releaseHIstoryForPreloading(). > * searchAndReserveCheckpoints() was slightly refactored: now it returns not > only an earliestValidCheckpoints but also an oldest reservedCheckpoint, so > that there’s no need to recalculate it within reserveHistoryForExchange(). > * -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13397) NPE in logSupplierDone(UUID nodeId)
[
https://issues.apache.org/jira/browse/IGNITE-13397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13397:
Fix Version/s: (was: 2.9.1)
> NPE in logSupplierDone(UUID nodeId)
> ---
>
> Key: IGNITE-13397
> URL: https://issues.apache.org/jira/browse/IGNITE-13397
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> NPE in logSupplierDone(UUID nodeId)
> {noformat}
> [2020-08-30 18:06:52,360][ERROR][rebalance-#5033%new-version-node%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR,
> err=java.lang.NullPointerException]]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.logSupplierDone(GridDhtPartitionDemander.java:2009)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.partitionDone(GridDhtPartitionDemander.java:1730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander$RebalanceFuture.access$1200(GridDhtPartitionDemander.java:1142)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.ownPartition(GridDhtPartitionDemander.java:751)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:649)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.lambda$handleSupplyMessage$0(GridDhtPreloader.java:356)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13462) .NET: Thin client Dispose hangs when continuous query is active on .NET Core 3.x
[
https://issues.apache.org/jira/browse/IGNITE-13462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13462:
Fix Version/s: (was: 2.9.1)
> .NET: Thin client Dispose hangs when continuous query is active on .NET Core
> 3.x
>
>
> Key: IGNITE-13462
> URL: https://issues.apache.org/jira/browse/IGNITE-13462
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, 2.9.1-rc
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * Switch all projects to netcoreapp3.0 (or 3.1)
> * Run Apache.Ignite.Core.Tests.Client.Cache.ContinuousQueryTest - it hangs on
> ClientSocket.Dispose
> Looks like Socket.Shutdown call is missing, or we can use Socket.Close with a
> timeout.
> Also see https://github.com/dotnet/runtime/issues/23990:
> {code:java}
> The native behavior of closing a socket file descriptor while it's being used
> in a synchronous/blocking accept/connect/send/recv/etc. call is undefined on
> Linux, and often results in a hang
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13500) Checkpoint read lock fail if it is taking under write lock during the stopping node
[
https://issues.apache.org/jira/browse/IGNITE-13500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13500:
Fix Version/s: (was: 2.9.1)
> Checkpoint read lock fail if it is taking under write lock during the
> stopping node
> ---
>
> Key: IGNITE-13500
> URL: https://issues.apache.org/jira/browse/IGNITE-13500
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> org.apache.ignite.internal.processors.cache.index.BasicIndexTest#testDynamicIndexesDropWithPersistence
> {noformat}
> [2020-09-30
> 15:09:26,085][ERROR][db-checkpoint-thread-#371%index.BasicIndexTest0%][Checkpointer]
> Runtime error caught during grid runnable execution: GridWorker
> [name=db-checkpoint-thread, igniteInstanceName=index.BasicIndexTest0,
> finished=false, heartbeatTs=1601467766063, hashCode=963964001,
> interrupted=false, runner=db-checkpoint-thread-#371%index.BasicIndexTest0%]
> class org.apache.ignite.IgniteException: Failed to perform cache update: node
> is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:396)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:263)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to perform cache
> update: node is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointTimeoutLock.checkpointReadLock(CheckpointTimeoutLock.java:128)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1298)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.removeDurableBackgroundTask(DurableBackgroundTasksProcessor.java:245)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.onMarkCheckpointBegin(DurableBackgroundTasksProcessor.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:274)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:387)
> ... 3 more
> Caused by: class org.apache.ignite.internal.NodeStoppingException: Failed to
> perform cache update: node is stopping.
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13676) Java thin client: Message not fully read by client after SECURITY_VIOLATION error
[ https://issues.apache.org/jira/browse/IGNITE-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13676: Fix Version/s: (was: 2.9.1) > Java thin client: Message not fully read by client after SECURITY_VIOLATION > error > - > > Key: IGNITE-13676 > URL: https://issues.apache.org/jira/browse/IGNITE-13676 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.9 >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > In case of SECURITY_VIOLATION error client does not fully read message, these > leads to phantom messages and client hang. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13388) apache-ignite deb package depends on a non-existent package and can't be installed on Debian 10
[
https://issues.apache.org/jira/browse/IGNITE-13388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13388:
Fix Version/s: (was: 2.9.1)
> apache-ignite deb package depends on a non-existent package and can't be
> installed on Debian 10
> ---
>
> Key: IGNITE-13388
> URL: https://issues.apache.org/jira/browse/IGNITE-13388
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Artem Budnikov
>Assignee: Peter Ivanov
>Priority: Major
> Labels: 2.9.1-rc
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The apache-ignite deb package v. 2.8.1 depends on 'openjdk-8-jdk', which is
> only available in Debian stretch and isn't available in later Debian
> distributions. An attempt to install the package gives this error:
> {code:java}
> $ sudo apt-get install apache-ignite=2.8.1-1
> ...
> The following packages have unmet dependencies:
> apache-ignite : Depends: openjdk-8-jdk but it is not installable or
> oracle-java8-installer but it is not installable
> E: Unable to correct problems, you have held broken packages{code}
> Package information:
> {code:java}
> $ apt-cache show apache-ignite=2.8.1-1
> Package: apache-ignite
> Version: 2.8.1-1
> Architecture: all
> Maintainer: Petr Ivanov
> Installed-Size: 572071
> Depends: openjdk-8-jdk | oracle-java8-installer, systemd, passwd
> Section: misc
> Priority: optional
> Homepage: https://ignite.apache.org
> Description: Apache Ignite In-Memory Computing, Database and Caching Platform
> Ignite™ is a memory-centric distributed database, caching, and processing
> platform for transactional, analytical, and streaming workloads, delivering
> in-memory speeds at petabyte scale
> Description-md5: 6a59db03fa1e142387abef6ef6bb0d83
> Filename: pool/main/a/apache-ignite_2.8.1-1_all.deb
> SHA1: 67d197a5e582f6ea7c66da26a755f937f8e16fc9
> SHA256: fc9a274ecb82716905d4120a715e9c74441dfed67831874eb3c35c4953bfc90d
> Size: 399746094
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13637) ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one
[ https://issues.apache.org/jira/browse/IGNITE-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13637: Fix Version/s: (was: 2.9.1) 2.10 > ODBC: Add support of SQL_ATTR_ROW_ARRAY_SIZE with value more than one > - > > Key: IGNITE-13637 > URL: https://issues.apache.org/jira/browse/IGNITE-13637 > Project: Ignite > Issue Type: Improvement > Components: odbc >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, we only support fetching of result set one by one. Implement > fetching in a batch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13640) Opencensus module has no runtime dependencies.
[ https://issues.apache.org/jira/browse/IGNITE-13640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13640: Fix Version/s: (was: 2.9.1) 2.10 > Opencensus module has no runtime dependencies. > -- > > Key: IGNITE-13640 > URL: https://issues.apache.org/jira/browse/IGNITE-13640 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 50m > Remaining Estimate: 0h > > Need to add dependencies to pom.xml > * io.opencensus.opencensus-impl-core - 0.22.0 version > * io.grpc.grpc-context - 1.19.0 version > * com.lmax.disruptor - 3.4.2 version > * com.google.guava.guava - 26.0-android version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13653) Don't print warning if unordered map used for bulk update operation on atomic cache
[ https://issues.apache.org/jira/browse/IGNITE-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13653: Fix Version/s: (was: 2.9.1) > Don't print warning if unordered map used for bulk update operation on atomic > cache > --- > > Key: IGNITE-13653 > URL: https://issues.apache.org/jira/browse/IGNITE-13653 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 40m > Remaining Estimate: 0h > > Since IGNITE-12451 is resolved there no more deadlock possible for atomic > caches and it's safe to use HashMap and other unordered maps as argument of > putAll/removeAll/invokeAll operations on atomic caches. Warning, introduced > by IGNITE-6804, is not required anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13699) Support new metrics framework in ZookeeperDiscovery
[ https://issues.apache.org/jira/browse/IGNITE-13699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13699: Fix Version/s: (was: 2.9.1) > Support new metrics framework in ZookeeperDiscovery > --- > > Key: IGNITE-13699 > URL: https://issues.apache.org/jira/browse/IGNITE-13699 > Project: Ignite > Issue Type: Improvement > Components: zookeeper >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13488) Add command to control.(sh|bin) to get an arbitrary Metric
[
https://issues.apache.org/jira/browse/IGNITE-13488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13488:
Fix Version/s: (was: 2.9.1)
> Add command to control.(sh|bin) to get an arbitrary Metric
> --
>
> Key: IGNITE-13488
> URL: https://issues.apache.org/jira/browse/IGNITE-13488
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: 2.9.1-rc, important
> Fix For: 2.10
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> It's needed to add the ability to get an arbitrary Metric via
> control.(sh|bin) script.
> If name of the metric registry is passed, value of all its metrics should be
> printed.
> Proposed command structure:
> {code:java}
> control.(sh|bat) --metric [--node-id node_id] name
> Parameters:
> name - Name of the metric which value should be printed. If name of
> the metric registry is specified, value of all its metrics will be printed.
> node_id - ID of the node to get the metric value from. If not set,
> random node will be chosen.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13265: Fix Version/s: (was: 2.9.1) > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12451) Introduce deadlock detection for cache entry reentrant locks
[ https://issues.apache.org/jira/browse/IGNITE-12451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-12451: Fix Version/s: (was: 2.9.1) > Introduce deadlock detection for cache entry reentrant locks > > > Key: IGNITE-12451 > URL: https://issues.apache.org/jira/browse/IGNITE-12451 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Ivan Rakov >Assignee: Aleksey Plekhanov >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Aside from IGNITE-12365, we still have possible threat of cache-entry-level > deadlock in case of careless usage of JCache mass operations (putAll, > removeAll): > 1. If two different user threads will perform putAll on the same two keys in > reverse order (primary node for which is the same), there's a chance that > sys-stripe threads will be deadlocked. > 2. Even without direct contract violation from user side, HashMap can be > passed as argument for putAll. Even if user threads have called mass > operations with two keys in the same order, HashMap iteration order is not > strictly defined, which may cause the same deadlock. > Local deadlock detection should mitigate this issue. We can create a wrapper > for ReentrantLock with logic that performs cycle detection in wait-for graph > in case we are waiting for lock acquisition for too long. Exception will be > thrown from one of the threads in such case, failing user operation, but > letting the system make progress. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13655) Implement readiness probe REST endpoint
[ https://issues.apache.org/jira/browse/IGNITE-13655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13655: Fix Version/s: (was: 2.9.1) > Implement readiness probe REST endpoint > --- > > Key: IGNITE-13655 > URL: https://issues.apache.org/jira/browse/IGNITE-13655 > Project: Ignite > Issue Type: New Feature > Components: rest >Affects Versions: 2.9.1 >Reporter: Alexander Korenshteyn >Assignee: Alexander Korenshteyn >Priority: Major > Fix For: 2.10 > > Time Spent: 1h > Remaining Estimate: 0h > > Create a REST command (PROBE) which returns a success code (200) if kernal > has fully started > and 503 otherwise > > implemented by attaching to the join future. > It looks pretty similar to warmup machinery (in terms of implementation). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13380) Output IgniteSystemProperties via ignite.sh
[
https://issues.apache.org/jira/browse/IGNITE-13380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13380:
Fix Version/s: (was: 2.9.1)
> Output IgniteSystemProperties via ignite.sh
> ---
>
> Key: IGNITE-13380
> URL: https://issues.apache.org/jira/browse/IGNITE-13380
> Project: Ignite
> Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: 2.9.1-rc, important
> Fix For: 2.10
>
> Time Spent: 9h
> Remaining Estimate: 0h
>
> Provide the ability output of all available Ignite properties
> ({{IgniteSystemProperties}}) with its descriptions in the {{ignite.sh}}
> command. For example,
> {noformat}
> ignite.sh -systemProps
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13422) Explicit command.sh option to enable experimental commands
[ https://issues.apache.org/jira/browse/IGNITE-13422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13422: Fix Version/s: (was: 2.9.1) > Explicit command.sh option to enable experimental commands > -- > > Key: IGNITE-13422 > URL: https://issues.apache.org/jira/browse/IGNITE-13422 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Right now experimental commands can be enabled only via an environment > variable(IGNITE_ENABLE_EXPERIMENTAL_COMMAND). > We need to add an explicit option to command.sh "--enable-experimental" which > will turn on experimental commands. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13766) Add API for checking network connectivity between all nodes in a cluster
[ https://issues.apache.org/jira/browse/IGNITE-13766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13766: Fix Version/s: (was: 2.9.1) 2.10 > Add API for checking network connectivity between all nodes in a cluster > > > Key: IGNITE-13766 > URL: https://issues.apache.org/jira/browse/IGNITE-13766 > Project: Ignite > Issue Type: Task > Components: control.sh >Affects Versions: 2.9 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Lack of connectivity from Server to client nodes could be a huge problem for > cluster stability. The client will be able to connect to the server and the > server will be able to answer to the client as long as the connection > established by the client will live, but if it will be closed and the server > will try to establish it's own connection, it will just hang(along with an > operation, which requires a message to be sent to the client node, it could > be topology change or some snapshot stage change, etc). > We should introduce an API, which will be available from control.sh and will > allow checking the connectivity between all nodes in the cluster. NOTE that > nodes should always try to establish it's own connection instead of just > reusing the connection that was established by another node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13633) thin clients cannot access the Ignite Service deployed through UriDeploymentSpi( java.lang.ClassNotFoundException)
[ https://issues.apache.org/jira/browse/IGNITE-13633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13633: Fix Version/s: (was: 2.9.1) 2.10 > thin clients cannot access the Ignite Service deployed through > UriDeploymentSpi( java.lang.ClassNotFoundException) > -- > > Key: IGNITE-13633 > URL: https://issues.apache.org/jira/browse/IGNITE-13633 > Project: Ignite > Issue Type: Bug > Components: managed services, thin client >Affects Versions: 2.9 >Reporter: xingzhou >Assignee: Aleksey Plekhanov >Priority: Critical > Fix For: 2.10 > > Attachments: ignite-deploy.zip > > Original Estimate: 24h > Time Spent: 2h 20m > Remaining Estimate: 21h 40m > > When the thin client is used to call the ignite service（ use ignite-urideploy > ）, the clientserviceinvokerequest will get the service classes, the local > classloader is used, and the classes cannot be found. Therefore, the > ignite-urideploy classloader should be added -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13601) Ignite-rest-http and ignite-kubernetes include vulnerable dependencies
[ https://issues.apache.org/jira/browse/IGNITE-13601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13601: Fix Version/s: (was: 2.9.1) > Ignite-rest-http and ignite-kubernetes include vulnerable dependencies > -- > > Key: IGNITE-13601 > URL: https://issues.apache.org/jira/browse/IGNITE-13601 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.8.1 >Reporter: Andrew Story >Priority: Blocker > Labels: 2.9.1-rc > Fix For: 2.10 > > > The ignite-rest-http and ignite-kubernetes modules include a vulnerable > version of the jackson-databind library. This was spotted in 2.8.1. > This component jackson-databind-2.9.6.jar is flagged as having numerous > critical, high and medium security vulnerabilities, one of which is > described here: > [https://nvd.nist.gov/vuln/detail/CVE-2019-14540] > More here: > [http://apache-ignite-users.70518.x6.nabble.com/Critical-security-vulnerability-for-opt-ignite-apache-ignite-libs-optional-ignite-rest-http-jackson-r-td34032.html] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13679) Entryprocessor cannot be hot deployed properly via UriDeploymentSpi
[ https://issues.apache.org/jira/browse/IGNITE-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13679: Fix Version/s: (was: 2.9.1) 2.10 > Entryprocessor cannot be hot deployed properly via UriDeploymentSpi > --- > > Key: IGNITE-13679 > URL: https://issues.apache.org/jira/browse/IGNITE-13679 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.9 >Reporter: YuJue Li >Priority: Critical > Fix For: 2.10 > > Attachments: ignite-deploy.zip > > > Entryprocessor cannot be hot deployed properly via UriDeploymentSpi,the > operation steps are as follows: > 1.put jar in the specified folder of uriList; > 2.Use example-deploy.xml,start two ignite nodes; > 3.Use the DeployClient to deploy the service named "deployService"; > 4.Execute the test through ThickClientTest, and the result is correct; > 5.Modify the code of DeployServiceImpl and DeployEntryProcessor, for example, > change "Hello" to "Hi", then repackage it and put it into the specified > folder of uriList; > 6.Redeploy services by RedeployClient; > 7.Execute the test again through ThickClientTest, and the result is > incorrect,we will find that if the Entryprocessor accessed by the service is > on another node, the Entryprocessor uses the old version of the class > definition. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13688) Ignite Docs: Port Checkpointing Mapping from readme.io
[ https://issues.apache.org/jira/browse/IGNITE-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13688: Fix Version/s: (was: 2.9.1) 2.10 > Ignite Docs: Port Checkpointing Mapping from readme.io > - > > Key: IGNITE-13688 > URL: https://issues.apache.org/jira/browse/IGNITE-13688 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.9 >Reporter: YuJue Li >Priority: Major > Labels: new-docs > Fix For: 2.10 > > > The content in the link below is missing from the new version of the document: > [https://apacheignite.readme.io/docs/continuous-mapping] > [https://apacheignite.readme.io/docs/checkpointing] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13773) Ignite Docs: Port SQL Tooling from readme.io
[ https://issues.apache.org/jira/browse/IGNITE-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13773: Fix Version/s: (was: 2.9.1) 2.10 > Ignite Docs: Port SQL Tooling from readme.io > > > Key: IGNITE-13773 > URL: https://issues.apache.org/jira/browse/IGNITE-13773 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.9 >Reporter: YuJue Li >Priority: Major > Labels: new-docs > Fix For: 2.10 > > > The content in the link below is missing from the new version of the document: > [https://apacheignite-sql.readme.io/docs/sql-tooling] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13642) Nodes fail when they meet objects of unknown type in metastorage
[
https://issues.apache.org/jira/browse/IGNITE-13642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13642:
Fix Version/s: (was: 2.9.1)
2.10
> Nodes fail when they meet objects of unknown type in metastorage
>
>
> Key: IGNITE-13642
> URL: https://issues.apache.org/jira/browse/IGNITE-13642
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Denis Mekhanikov
>Priority: Blocker
> Labels: 2.9.1-rc
> Fix For: 2.10
>
>
> When a node sees an object of a class that is missing on this node's
> classpath, it fails with the following exception:
> {noformat}
> [16:46:47,134][SEVERE][disco-notifier-worker-#41][] Critical system error
> detected. Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.IgniteCheckedException: Failed to find class with given class loader
> for unmarshalling (make sure same versions of all classes are available on
> all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]]]
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading)
> [clsLdr=sun.misc.Launcher$AppClassLoader@764c12b6,
> cls=example.ClientNode$BamboozleClass]
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:128)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:138)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageUtil.unmarshal(DistributedMetaStorageUtil.java:61)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.completeWrite(DistributedMetaStorageImpl.java:1161)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onUpdateMessage(DistributedMetaStorageImpl.java:1089)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:650)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.lambda$onDiscovery$0(GridDiscoveryManager.java:521)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body0(GridDiscoveryManager.java:2718)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryMessageNotifierWorker.body(GridDiscoveryManager.java:2756)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: example.ClientNode$BamboozleClass
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9061)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:58)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1925)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1808)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2099)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1625)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:465)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:423)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:123)
> ... 11 more{noformat}
> The result is that one node can write an object of some custom class to the
> metastorage and make all other nodes fail.
> The following reproducer can be used:
> {code:java}
> public class ClientNode {
> public static void main(String[] args) throws IgniteCheckedException {
> IgniteConfiguration igniteCfg =
>
[jira] [Updated] (IGNITE-12320) Partial index rebuild fails in case indexed cache contains different datatypes
[
https://issues.apache.org/jira/browse/IGNITE-12320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-12320:
Fix Version/s: 2.9.1
> Partial index rebuild fails in case indexed cache contains different datatypes
> --
>
> Key: IGNITE-12320
> URL: https://issues.apache.org/jira/browse/IGNITE-12320
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The problem is that in case cache contains different datatypes, all of them
> will be passed to IndexRebuildPartialClosure during iteration over partition.
> Perhaps, TableCacheFilter is supposed to filter out entries of unwanted
> types, but it doesn't work properly.
> Steps to reprocude:
> 1. Add entries of different types (both indexed and not) to cache
> 2. Trigger partial index rebuild
> Index rebuild will fail with the following error:
> {code:java}
> [2019-08-20
> 00:33:55,640][ERROR][pub-#302%h2.GridIndexFullRebuildTest3%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
> val2=844420635165670]], msg=Runtime failure on row: %s string representation>]]]
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=98629247,
> val2=844420635165670]], msg=Runtime failure on row: %s string representation>]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:5126)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2236)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2183)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:285)
> at
> org.apache.ignite.internal.processors.query.h2.IndexRebuildPartialClosure.apply(IndexRebuildPartialClosure.java:49)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:3867)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:254)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:217)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartitions(SchemaIndexCacheVisitorImpl.java:176)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:135)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.rebuildIndexesFromHash0(IgniteH2Indexing.java:2191)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$7.body(IgniteH2Indexing.java:2154)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
> get field because type ID of passed object differs from type ID this
> BinaryField belongs to [expected=-635374417, actual=1778229603]
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.fieldOrder(BinaryFieldImpl.java:287)
> at
> org.apache.ignite.internal.binary.BinaryFieldImpl.value(BinaryFieldImpl.java:109)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.fieldValue(QueryBinaryProperty.java:220)
> at
> org.apache.ignite.internal.processors.query.property.QueryBinaryProperty.value(QueryBinaryProperty.java:116)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2RowDescriptor.columnValue(GridH2RowDescriptor.java:331)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2KeyValueRowOnheap.getValue0(GridH2KeyValueRowOnheap.java:122)
> at
>
[jira] [Updated] (IGNITE-13302) Java thin client connect/disconnect during topology update may lead to partition divergence in ignite-sys-cache
[
https://issues.apache.org/jira/browse/IGNITE-13302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13302:
Fix Version/s: 2.9.1
> Java thin client connect/disconnect during topology update may lead to
> partition divergence in ignite-sys-cache
> ---
>
> Key: IGNITE-13302
> URL: https://issues.apache.org/jira/browse/IGNITE-13302
> Project: Ignite
> Issue Type: Bug
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> And you can see partition inconsistency in ignite-sys-cache
> {noformat}
> [2020-04-23 15:26:31,816][WARN ][sys-#45%gridgain.Sdsb11784Ver20%][root]
> Partition states validation has failed for group: ignite-sys-cache, msg:
> Partitions cache sizes are inconsistent for Part 31: [127.0.0.1:47500=1
> 127.0.0.1:47501=2 ] Part 43: [127.0.0.1:47500=3 127.0.0.1:47501=4 ] Part 44:
> [127.0.0.1:47500=1 127.0.0.1:47501=2 ] Part 46: [127.0.0.1:47500=0
> 127.0.0.1:47501=1 ] Part 91: [127.0.0.1:47500=1 127.0.0.1:47501=2 ]
> {noformat}
> Research results:
> Entries with an internal key type doesn't check in differed delete queue, it
> leads to inconsistency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13402) [Suite] PDS 3 flaky failed on TC
[
https://issues.apache.org/jira/browse/IGNITE-13402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13402:
Fix Version/s: 2.9.1
> [Suite] PDS 3 flaky failed on TC
>
>
> Key: IGNITE-13402
> URL: https://issues.apache.org/jira/browse/IGNITE-13402
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> java.lang.AssertionError: Invalid topology version
> [topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], group=Group1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.readyTopologyVersion(GridDhtPartitionTopologyImpl.java:317)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.nextVersion(GridCacheAdapter.java:3663)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpiredInternal(GridCacheOffheapManager.java:2821)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:2747)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:1090)
> at
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> [2020-07-28 06:36:24,540][INFO
> ][exchange-worker-#38244%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][FileWriteAheadLogManager]
> Resuming logging to WAL segment
> [file=/opt/buildagent/work/bde9b45ddb020b34/incubator-ignite/work/db/wal/persistence_IgnitePdsContinuousRestartTestWithExpiryPolicy2/.wal,
> offset=3573451, ver=2]
> at
> org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> [2020-07-28
> 06:36:24,544][ERROR][ttl-cleanup-worker-#38230%persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]]]
> class org.apache.ignite.IgniteException: GridWorker
> [name=ttl-cleanup-worker,
> igniteInstanceName=persistence.IgnitePdsContinuousRestartTestWithExpiryPolicy2,
> finished=true, heartbeatTs=1595907384509]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onStopped(WorkersRegistry.java:168)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:152)
> at java.lang.Thread.run(Thread.java:748)
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13427) The local metastorage system view fails if unmarshallable values present
[
https://issues.apache.org/jira/browse/IGNITE-13427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13427:
Fix Version/s: 2.9.1
> The local metastorage system view fails if unmarshallable values present
>
>
> Key: IGNITE-13427
> URL: https://issues.apache.org/jira/browse/IGNITE-13427
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The local metastorage allow to write raw data. For example, distributed
> metastorage writes it:
> {noformat}
> metastorage.writeRaw(cleanupGuardKey(), DUMMY_VALUE);
> {noformat}
> System view iterator fails on such entries:
> {noformat}
> [2020-09-10 14:34:37,556][WARN
> ][test-runner-#1%metric.SystemViewSelfTest%][GridCacheDatabaseSharedManager]
> Metastore iteration error
> class org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> with given class loader: sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:132)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:139)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.applyCallback(MetaStorage.java:387)
> at
> org.apache.ignite.internal.processors.cache.persistence.metastorage.MetaStorage.iterate(MetaStorage.java:359)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.lambda$registerSystemView$1(GridCacheDatabaseSharedManager.java:415)
> at
> org.apache.ignite.internal.managers.systemview.SystemViewAdapter.iterator(SystemViewAdapter.java:82)
> at
> org.apache.ignite.internal.util.lang.GridFunc.find(GridFunc.java:2068)
> at
> org.apache.ignite.internal.metric.SystemViewSelfTest.testMetastorage(SystemViewSelfTest.java:1155)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2373)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9474) Ignite does not eagerly remove expired cache entries
[ https://issues.apache.org/jira/browse/IGNITE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-9474: --- Fix Version/s: 2.9.1 > Ignite does not eagerly remove expired cache entries > > > Key: IGNITE-9474 > URL: https://issues.apache.org/jira/browse/IGNITE-9474 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.4 >Reporter: Pavel Vinokurov >Assignee: Mirza Aliev >Priority: Major > Fix For: 2.10, 2.9.1 > > Attachments: IgniteExpirationReproducerWithoutPersistance.java > > Time Spent: 20m > Remaining Estimate: 0h > > cache.size() indicates existed rows, but any get operation returns empty > result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had been closed before.
[
https://issues.apache.org/jira/browse/IGNITE-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13102:
Fix Version/s: 2.9.1
> IgniteCache#isClosed() returns false on server node even if the cache had
> been closed before.
> -
>
> Key: IGNITE-13102
> URL: https://issues.apache.org/jira/browse/IGNITE-13102
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Sergey Antonov
>Assignee: Konstantin Sirotkin
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> IgniteCache#isClosed() still returns {{false}} even after
> {{IgniteCache#close()}}. Only server nodes affect by this problem.
> Simple reproducer:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx node = startGrid(0);
> IgniteCache cache =
> node.getOrCreateCache(DEFAULT_CACHE_NAME);
> assertFalse(cache.isClosed());
> cache.close();
> // java.lang.AssertionError
> assertTrue(cache.isClosed());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13251) Deadlock between grid-timeout-worker and a thread opening a communication connection.
[
https://issues.apache.org/jira/browse/IGNITE-13251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13251:
Fix Version/s: 2.9.1
> Deadlock between grid-timeout-worker and a thread opening a communication
> connection.
> -
>
> Key: IGNITE-13251
> URL: https://issues.apache.org/jira/browse/IGNITE-13251
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> grid-timeout-worker is known to go into a deadlock state with other threads
> in a few scenarios.
> The general scheme is:
> 1. A thread `T` is holding lock `L` and is trying to establish a
> communication connection, hanging in `safeTcpHandshake` method. Due to the
> logic of `safeTcpHandshake`, `grid-timeout-worker` needs to send a signal to
> `T` in order for it to proceed.
> 2. `grid-timeout-worker` is trying to acquire `L`. Hence, the deadlock.
> It may include more threads. The lock `L` can be different: checkpoint lock,
> GridCacheMapEntry lock, etc.
> #
> ## Example
> The below example shows a lock between
> * `grid-timeout-worker` trying to acquire a cp read lock in a
> `dumpLongRunningTransactions`
> * `tcp-comm-worker` trying to establish a connection but hanging on socket
> read due to unstable network
> * checkpointer trying to start a checkpoint and acquire cp write lock
> * `utility` worker waiting for the connection to be established by
> `tcp-comm-worker` while holding cp read lock
> {code:java}
> Thread [name="grid-timeout-worker-#23", id=42, state=WAITING, blockCnt=6991,
> waitCnt=1746467]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@4545a8b9,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1707)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.setResult(GridPartitionedSingleGetFuture.java:715)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.localGet(GridPartitionedSingleGetFuture.java:511)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.tryLocalGet(GridPartitionedSingleGetFuture.java:399)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:366)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:243)
> at
> o.a.i.i.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:232)
> at
> o.a.i.i.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:246)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4190)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4171)
> at
> o.a.i.i.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1362)
> at
> o.a.i.i.processors.task.GridTaskProcessor.saveTaskMetadata(GridTaskProcessor.java:908)
> at
> o.a.i.i.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:746)
> at
> o.a.i.i.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:477)
> at
> o.a.i.i.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:674)
> at
> o.a.i.i.processors.closure.GridClosureProcessor.callAsync(GridClosureProcessor.java:479)
> at o.a.i.i.IgniteComputeImpl.callAsync0(IgniteComputeImpl.java:809)
> at o.a.i.i.IgniteComputeImpl.callAsync(IgniteComputeImpl.java:794)
> at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningTransaction(GridCachePartitionExchangeManager.java:2115)
> at
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:2012)
>
[jira] [Updated] (IGNITE-13245) Rebalance future might hangs in no final state though all partitions are owned
[ https://issues.apache.org/jira/browse/IGNITE-13245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13245: Fix Version/s: 2.9.1 > Rebalance future might hangs in no final state though all partitions are owned > -- > > Key: IGNITE-13245 > URL: https://issues.apache.org/jira/browse/IGNITE-13245 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.10, 2.9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > It is very specific case, when supplier go out of cluster and in the same > time, its partitions have not needed rebalance in new topology. > Loot at my PR for to understand it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13293) .NET: Enum serialization is slow
[ https://issues.apache.org/jira/browse/IGNITE-13293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13293: Fix Version/s: 2.9.1 > .NET: Enum serialization is slow > > > Key: IGNITE-13293 > URL: https://issues.apache.org/jira/browse/IGNITE-13293 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.7, 2.8, 2.8.1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10, 2.9.1 > > Time Spent: 50m > Remaining Estimate: 0h > > BinaryWriter.SaveMetadata has performance issues when enums are present: > every enum write causes GetEnumValues call in BinaryType, which uses > reflection. > We should cache enum values per type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13174) C++: Add Windows support to CMake build system
[ https://issues.apache.org/jira/browse/IGNITE-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13174: Fix Version/s: 2.9.1 > C++: Add Windows support to CMake build system > -- > > Key: IGNITE-13174 > URL: https://issues.apache.org/jira/browse/IGNITE-13174 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.8.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10, 2.9.1 > > Time Spent: 40m > Remaining Estimate: 0h > > Ticket IGNITE-13078 adds CMake build system support, but only for Linux. Need > make sure it works on Windows and create TC job for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13235) Deadlock in IgniteServiceProcessor
[
https://issues.apache.org/jira/browse/IGNITE-13235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13235:
Fix Version/s: 2.9.1
> Deadlock in IgniteServiceProcessor
> --
>
> Key: IGNITE-13235
> URL: https://issues.apache.org/jira/browse/IGNITE-13235
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> "main" #1 prio=5 os_prio=0 tid=0x7ff9ac00f000 nid=0x86d in Object.wait()
> [0x7ff9b418b000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.ignite.internal.util.worker.GridWorker.join(GridWorker.java:242)
> - locked <0x000776ee2028> (a java.lang.Object)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:5009)
> at
> org.apache.ignite.internal.processors.service.ServiceDeploymentManager.stopProcessing(ServiceDeploymentManager.java:145)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.stopProcessor(IgniteServiceProcessor.java:261)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.onKernalStop(IgniteServiceProcessor.java:248)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2466)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2414)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2577)
> - locked <0x000776424138> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2540)
> at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:333)
> at org.apache.ignite.Ignition.stop(Ignition.java:221)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1225)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1268)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1246)
> at
> org.apache.ignite.events.ClusterActivationStartedEventTest.afterTest(ClusterActivationStartedEventTest.java:41)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.cleanUpTestEnviroment(GridAbstractTest.java:701)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:2165)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$600(GridAbstractTest.java:172)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:207)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at
> org.apache.ignite.testframework.junits.SystemPropertiesRule.lambda$methodStatement$1(SystemPropertiesRule.java:109)
> at
> org.apache.ignite.testframework.junits.SystemPropertiesRule$$Lambda$6/167185492.evaluate(Unknown
> Source)
> at
> org.apache.ignite.testframework.junits.DelegatingJUnitStatement.evaluate(DelegatingJUnitStatement.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2669)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:172)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2649)
> at
> org.apache.ignite.testframework.junits.SystemPropertiesRule.lambda$classStatement$0(SystemPropertiesRule.java:93)
> at
> org.apache.ignite.testframework.junits.SystemPropertiesRule$$Lambda$2/1879492184.evaluate(Unknown
> Source)
> at
> org.apache.ignite.testframework.junits.DelegatingJUnitStatement.evaluate(DelegatingJUnitStatement.java:48)
> at
[jira] [Updated] (IGNITE-13719) Thin client silently closes channel after inactivity
[
https://issues.apache.org/jira/browse/IGNITE-13719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaroslav Molochkov updated IGNITE-13719:
Fix Version/s: 2.9.1
> Thin client silently closes channel after inactivity
>
>
> Key: IGNITE-13719
> URL: https://issues.apache.org/jira/browse/IGNITE-13719
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: jifwin
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.10, 2.9.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following code works fine with ignite-core 2.8.0, but fails with 2.9.0
> (see the exception below). It looks like timeout is applied to client
> receiver thread. When it's not used for a while it gets closed silently.
> {code:java}
> public class IgniteDemo
> {
> public static final int TIMEOUT = 1000;
> public static void main(String[] args) throws InterruptedException
> {
> new IgniteDemo().run();
> }
> public void run() throws InterruptedException
> {
> final Ignite igniteServer = Ignition.start();
> final ClientConfiguration cfg = new
> ClientConfiguration().setAddresses("127.0.0.1:10800");
> cfg.setTimeout(TIMEOUT);
> final IgniteClient igniteClient = Ignition.startClient(cfg);
> final ClientCache cache =
> igniteClient.getOrCreateCache("test");
> Thread.sleep(TIMEOUT);
> cache.put(1, 1);
> Thread.sleep(TIMEOUT);
> cache.put(2, 2);
> }
> }
> {code}
> {code:java}
>
> Exception in thread "main"
> org.apache.ignite.client.ClientConnectionException: Channel is
> closedException in thread "main"
> org.apache.ignite.client.ClientConnectionException: Channel is closed at
> org.apache.ignite.internal.client.thin.TcpClientChannel.send(TcpClientChannel.java:236)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.service(TcpClientChannel.java:217)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.service(ReliableChannel.java:198)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.affinityService(ReliableChannel.java:261)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.cacheSingleKeyOperation(TcpClientCache.java:508)
> at
> org.apache.ignite.internal.client.thin.TcpClientCache.put(TcpClientCache.java:127)
> at IgniteDemo.run(IgniteDemo.java:26) at IgniteDemo.main(IgniteDemo.java:13)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
