[jira] [Updated] (IGNITE-10629) Migration follow up: check for old style tests that could be slipped through in transition period
[
https://issues.apache.org/jira/browse/IGNITE-10629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10629:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-10173)
> Migration follow up: check for old style tests that could be slipped through
> in transition period
> -
>
> Key: IGNITE-10629
> URL: https://issues.apache.org/jira/browse/IGNITE-10629
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: junit_inspections.xml
>
>
> We need to account for risk that while tests are migrating some commits may
> by mistake slip in old style test cases - that will be ignored by JUnit 4.
> In order to address possible issues of that kind, do the following a week or
> two after IGNITE-10177 is merged to master: run the IntelliJ inspection
> called "old style Junit test method in JUnit 4 class", review report and fix
> discovered problems if there are any.
> For the reference, my version of IDE explains this inspection as follows:
> {quote}Reports JUnit 3 style test methods which are located inside a class
> which does not extend the abstract JUnit 3 class TestCase and contains JUnit
> 4/JUnit 5 @Test annotated methods.{quote}
> (note concerns mentioned in this ticket were originally raised at dev list:
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-tp29608p39300.html])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10180) Investigate migration from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10180: Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-10173) > Investigate migration from Junit 4 to 5 > --- > > Key: IGNITE-10180 > URL: https://issues.apache.org/jira/browse/IGNITE-10180 > Project: Ignite > Issue Type: Task >Reporter: Oleg Ignatenko >Assignee: Ivan Fedotov >Priority: Major > > If needed, refer parent task for more details. > Find out if Junit 5 is mature enough - specifically why maven still uses > Junit 4 as default, are there serious reasons for that or not. If it looks > okay, create a new JIRA task to migrate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10180) Investigate migration from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10180: Issue Type: Sub-task (was: Task) Parent: IGNITE-10951 > Investigate migration from Junit 4 to 5 > --- > > Key: IGNITE-10180 > URL: https://issues.apache.org/jira/browse/IGNITE-10180 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Assignee: Ivan Fedotov >Priority: Major > > If needed, refer parent task for more details. > Find out if Junit 5 is mature enough - specifically why maven still uses > Junit 4 as default, are there serious reasons for that or not. If it looks > okay, create a new JIRA task to migrate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10208:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10951
> Verify list of tests after migration to Junit 4 against some prior reference
> (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10208
> URL: https://issues.apache.org/jira/browse/IGNITE-10208
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to
> existing test cases. Since Ignite contains many thousands test cases there is
> a substantial risk that we may miss some of these in such a transition.
> In order to mitigate the risk, suggest to do a check after completion of
> IGNITE-10177 and IGNITE-10762 - somehow generate list of tests in the project
> and compare it against similar list of tests of some "known good" prior
> project version (at this point, 2.7 release branch looks like a good
> candidate for such a reference).
> If comparison shows that some test cases from older version are missed in
> newer one, open a ticket to investigate that.
> Comparison is better done using [nightly
> run-all|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8]
> test set as it is the most comprehensive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10614) investigate blocking of WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync at stopping grids when migrating from JUnit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10614:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10951
> investigate blocking of
> WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync at stopping
> grids when migrating from JUnit 3 to 4
> -
>
> Key: IGNITE-10614
> URL: https://issues.apache.org/jira/browse/IGNITE-10614
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} runs OK
> under JUnit 3 but blocks at stopping grids when migrating to JUnit 4.
> Workaround for that (discovered by [~EdShangGG]) is to run stopAllGrids in
> separate thread:
> {code}
> @Override protected void afterTest() throws Exception {
> Thread thread = new Thread(this::stopAllGrids);
> thread.start();
> thread.join(getTestTimeout());
> cleanPersistenceDir();
> }
> {code}
> If needed, [here is a diff at
> Github|https://github.com/apache/ignite/pull/5615/commits/1b342ee4c8c772b0e57583ee7f8721fc2c070bcf]
> with more context.
> Need to find out what is going on there and if something needs to be changed
> in this test or maybe in parent test classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10629) Migration follow up: check for old style tests that could be slipped through in transition period
[
https://issues.apache.org/jira/browse/IGNITE-10629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10629:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10951
> Migration follow up: check for old style tests that could be slipped through
> in transition period
> -
>
> Key: IGNITE-10629
> URL: https://issues.apache.org/jira/browse/IGNITE-10629
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Attachments: junit_inspections.xml
>
>
> We need to account for risk that while tests are migrating some commits may
> by mistake slip in old style test cases - that will be ignored by JUnit 4.
> In order to address possible issues of that kind, do the following a week or
> two after IGNITE-10177 is merged to master: run the IntelliJ inspection
> called "old style Junit test method in JUnit 4 class", review report and fix
> discovered problems if there are any.
> For the reference, my version of IDE explains this inspection as follows:
> {quote}Reports JUnit 3 style test methods which are located inside a class
> which does not extend the abstract JUnit 3 class TestCase and contains JUnit
> 4/JUnit 5 @Test annotated methods.{quote}
> (note concerns mentioned in this ticket were originally raised at dev list:
> [here|http://apache-ignite-developers.2346864.n4.nabble.com/Is-it-time-to-move-forward-to-JUnit4-5-tp29608p39300.html])
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[ https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10179: Issue Type: Sub-task (was: Task) Parent: IGNITE-10951 > Change new tests root to use @BeforeClass and @AfterClass instead of > isFirstTest() and isLastTest() > --- > > Key: IGNITE-10179 > URL: https://issues.apache.org/jira/browse/IGNITE-10179 > Project: Ignite > Issue Type: Sub-task >Reporter: Oleg Ignatenko >Priority: Major > > If needed, refer parent task for more details. > isFirstTest() and isLastTest() homebrew methods seem to be in > GridAbstractTest only because Junit 3 lacked necessary functionality; after > migration to Junit 4 these would better changed to use standard API of this > framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10614) investigate blocking of WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync at stopping grids when migrating from JUnit 3 to 4
[
https://issues.apache.org/jira/browse/IGNITE-10614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10614:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-10173)
> investigate blocking of
> WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync at stopping
> grids when migrating from JUnit 3 to 4
> -
>
> Key: IGNITE-10614
> URL: https://issues.apache.org/jira/browse/IGNITE-10614
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Ivan Rakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {{WalCompactionTest.testCompressorToleratesEmptyWalSegmentsFsync}} runs OK
> under JUnit 3 but blocks at stopping grids when migrating to JUnit 4.
> Workaround for that (discovered by [~EdShangGG]) is to run stopAllGrids in
> separate thread:
> {code}
> @Override protected void afterTest() throws Exception {
> Thread thread = new Thread(this::stopAllGrids);
> thread.start();
> thread.join(getTestTimeout());
> cleanPersistenceDir();
> }
> {code}
> If needed, [here is a diff at
> Github|https://github.com/apache/ignite/pull/5615/commits/1b342ee4c8c772b0e57583ee7f8721fc2c070bcf]
> with more context.
> Need to find out what is going on there and if something needs to be changed
> in this test or maybe in parent test classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10208) Verify list of tests after migration to Junit 4 against some prior reference (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10208:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-10173)
> Verify list of tests after migration to Junit 4 against some prior reference
> (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10208
> URL: https://issues.apache.org/jira/browse/IGNITE-10208
> Project: Ignite
> Issue Type: Task
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Migration from Junit 3 to 4 involves manually adding {{@Test}} annotation to
> existing test cases. Since Ignite contains many thousands test cases there is
> a substantial risk that we may miss some of these in such a transition.
> In order to mitigate the risk, suggest to do a check after completion of
> IGNITE-10177 and IGNITE-10762 - somehow generate list of tests in the project
> and compare it against similar list of tests of some "known good" prior
> project version (at this point, 2.7 release branch looks like a good
> candidate for such a reference).
> If comparison shows that some test cases from older version are missed in
> newer one, open a ticket to investigate that.
> Comparison is better done using [nightly
> run-all|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8]
> test set as it is the most comprehensive.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[ https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10179: Issue Type: Task (was: Sub-task) Parent: (was: IGNITE-10173) > Change new tests root to use @BeforeClass and @AfterClass instead of > isFirstTest() and isLastTest() > --- > > Key: IGNITE-10179 > URL: https://issues.apache.org/jira/browse/IGNITE-10179 > Project: Ignite > Issue Type: Task >Reporter: Oleg Ignatenko >Priority: Major > > If needed, refer parent task for more details. > isFirstTest() and isLastTest() homebrew methods seem to be in > GridAbstractTest only because Junit 3 lacked necessary functionality; after > migration to Junit 4 these would better changed to use standard API of this > framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10758:
Issue Type: Sub-task (was: Task)
Parent: IGNITE-10951
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10951) migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173)
[ https://issues.apache.org/jira/browse/IGNITE-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10951: Ignite Flags: (was: Docs Required) > migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173) > --- > > Key: IGNITE-10951 > URL: https://issues.apache.org/jira/browse/IGNITE-10951 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > > This is an umbrella ticket for those tasks related to migration from JUnit 3 > to 4 which assume that all JUnit 3 related code has been already cleaned from > the project in prior phase per IGNITE-10173 and IGNITE-10762. > This involves such tasks as update guidelines as suggested in comments of > IGNITE-10178, study of whether to migrate to JUnit 5, removal of scaffolding > annotations etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10758) remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their respective imports
[
https://issues.apache.org/jira/browse/IGNITE-10758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10758:
Issue Type: Task (was: Sub-task)
Parent: (was: IGNITE-10173)
> remove from tests scaffolding annotations "@RunWith(JUnit4.class)" and their
> respective imports
> ---
>
> Key: IGNITE-10758
> URL: https://issues.apache.org/jira/browse/IGNITE-10758
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> In the course of IGNITE-10175 and IGNITE-10176 many test classes were
> annotated {{@RunWith(JUnit4.class)}}. This was necessary to allow gradual
> switching to JUnit 4 to let classes run under the version that worked for
> these.
> After IGNITE-10177 is over, these scaffolding annotations will be not needed
> anymore (and will become even somewhat damaging by misleading readers to
> think that they serve some real purpose).
> The task is to remove these annotations and respective import statements
> after IGNITE-10177 is merged to master. Note it was initially planned as a
> part of IGNITE-10177 but per discussion with [~EdShangGG] we decided that it
> will be more convenient to do this in a separate ticket because this will
> make changes much easier to review, test and merge.
> (!) Thing worth paying attention is that mentioned annotations should be kept
> in one case - namely in root test class {{GridAbstractTest}} because over
> there these are necessary until JUnit 3 dependencies are wiped out from
> remaining cases listed in IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10925) Failure to submit affinity task from client node
[
https://issues.apache.org/jira/browse/IGNITE-10925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743702#comment-16743702
]
Prasad commented on IGNITE-10925:
-
Can we please have a fix for this in 2.8? This is a blocker, distributed
processing is not working in my app because of this.
> Failure to submit affinity task from client node
>
>
> Key: IGNITE-10925
> URL: https://issues.apache.org/jira/browse/IGNITE-10925
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Prasad
>Priority: Blocker
>
> Getting following exception while submitting the affinity task from client
> node to server node.
> Before submitting the affinity task ignite first gets the affinity cached
> function (AffinityInfo) by submitting the cluster wide task "AffinityJob".
> But while in the process of retrieving the output of this AffinityJob, ignite
> deserializes this output. I am getting exception while deserailizing this
> output.
> Code fails while un-marshalling cachesnapshotmetrics on client node.
>
> [Userlist
> Discussion|http://apache-ignite-users.70518.x6.nabble.com/After-upgrading-2-7-getting-Unexpected-error-occurred-during-unmarshalling-td26262.html]
> [Reproducer
> Project|https://github.com/prasadbhalerao1983/IgniteIssueReproducer.git]
>
> Step to Reproduce:
> 1) First Run com.example.demo.Server class as a java program
> 2) Then run com.example.demo.Client as java program.
>
> {noformat}
> 2019-01-14 15:37:02.723 ERROR 10712 --- [springDataNode%]
> o.a.i.i.processors.task.GridTaskWorker : Error deserializing job response:
> GridJobExecuteResponse [nodeId=e9a24c20-0d00-4808-b2f5-13e1ce35496a,
> sesId=76324db4861-1d85ad49-5b25-454a-b69c-d8685cfc73b0,
> jobId=86324db4861-1d85ad49-5b25-454a-b69c-d8685cfc73b0, gridEx=null,
> isCancelled=false, retry=null]
> org.apache.ignite.IgniteCheckedException: Failed to unmarshal object with
> optimized marshaller
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10146)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:831)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1081)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$JobMessageListener.onMessage(GridTaskProcessor.java:1316)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> [ignite-core-2.7.0.jar:2.7.0]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [na:1.8.0_144]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [na:1.8.0_144]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_144]
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to
> unmarshal object with optimized marshaller
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1765)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:313)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:102)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> ~[ignite-core-2.7.0.jar:2.7.0]
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10140)
> ~[ignite-core-2.7.0.jar:2.7.0]
> ... 10 common frames omitted
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to deserialize
> object with given class loader:
> [clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2, err=Failed to deserialize
> object [typeName=org.apache.ignite.internal.util.lang.GridTuple3]]
> at
>
[jira] [Updated] (IGNITE-10951) migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173)
[ https://issues.apache.org/jira/browse/IGNITE-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10951: Labels: MakeTeamcityGreenAgain technical_debt (was: MakeTeamcityGreenAgain) > migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173) > --- > > Key: IGNITE-10951 > URL: https://issues.apache.org/jira/browse/IGNITE-10951 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain, technical_debt > > This is an umbrella ticket for those tasks related to migration from JUnit 3 > to 4 which assume that all JUnit 3 related code has been already cleaned from > the project in prior phase per IGNITE-10173 and IGNITE-10762. > This involves such tasks as update guidelines as suggested in comments of > IGNITE-10178, study of whether to migrate to JUnit 5, removal of scaffolding > annotations etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10951) migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173)
[ https://issues.apache.org/jira/browse/IGNITE-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10951: Labels: MakeTeamcityGreenAgain (was: ) > migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173) > --- > > Key: IGNITE-10951 > URL: https://issues.apache.org/jira/browse/IGNITE-10951 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > > This is an umbrella ticket for those tasks related to migration from JUnit 3 > to 4 which assume that all JUnit 3 related code has been already cleaned from > the project in prior phase per IGNITE-10173 and IGNITE-10762. > This involves such tasks as update guidelines as suggested in comments of > IGNITE-10178, study of whether to migrate to JUnit 5, removal of scaffolding > annotations etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10951) migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173)
Oleg Ignatenko created IGNITE-10951: --- Summary: migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173) Key: IGNITE-10951 URL: https://issues.apache.org/jira/browse/IGNITE-10951 Project: Ignite Issue Type: Task Affects Versions: 2.8 Reporter: Oleg Ignatenko This is an umbrella ticket for those tasks related to migration from JUnit 3 to 4 which assume that all JUnit 3 related code has been already cleaned from the project in prior phase per IGNITE-10173 and IGNITE-10762. This involves such tasks as update guidelines as suggested in comments of IGNITE-10178, study of whether to migrate to JUnit 5, removal of scaffolding annotations etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10951) migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173)
[ https://issues.apache.org/jira/browse/IGNITE-10951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko reassigned IGNITE-10951: --- Assignee: Oleg Ignatenko > migration from Junit 3 to 4 phase 2 (follow-up to IGNITE-10173) > --- > > Key: IGNITE-10951 > URL: https://issues.apache.org/jira/browse/IGNITE-10951 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > > This is an umbrella ticket for those tasks related to migration from JUnit 3 > to 4 which assume that all JUnit 3 related code has been already cleaned from > the project in prior phase per IGNITE-10173 and IGNITE-10762. > This involves such tasks as update guidelines as suggested in comments of > IGNITE-10178, study of whether to migrate to JUnit 5, removal of scaffolding > annotations etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[
https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743696#comment-16743696
]
Ignite TC Bot commented on IGNITE-10754:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2805233buildTypeId=IgniteTests24Java8_RunAll]
> Query history statistics API
>
>
> Key: IGNITE-10754
> URL: https://issues.apache.org/jira/browse/IGNITE-10754
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29, monitoring
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of now we have query statistics
> (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues.
> 1) Duration execution it just time between start execution and return cursor
> to client and doesn't include all life time of query.
> 2) It doesn't know about multistatement queries. Such queries participate in
> statistics as single query without splitting.
> 3) API to access the statistics expose as depend on cache, however query
> don't have such dependency.
>
> Need to create parallel similar realization as we already have.
> Use new infrastructure of tracking running queries developed under
> IGNITE-10621 and update statistics on unregister phase.
> Expose API on upper level then it placed now. Right place will be written
> later.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743670#comment-16743670
]
Raymond Wilson commented on IGNITE-10451:
-
[~ptupitsyn], do you think there will be a fix for this in Ignite 2.8? Thanks,
Raymond.
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: 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:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
> at
>
[jira] [Commented] (IGNITE-10489) Web console: validation messages are shown twice in configuration
[ https://issues.apache.org/jira/browse/IGNITE-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743665#comment-16743665 ] Ilya Borisov commented on IGNITE-10489: --- [~pkonstantinov] I've fixed a bug where horizontal error in form-field-size had incorrect position, please test again. > Web console: validation messages are shown twice in configuration > - > > Key: IGNITE-10489 > URL: https://issues.apache.org/jira/browse/IGNITE-10489 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-11-30-14-59-19-188.png > > Time Spent: 28m > Remaining Estimate: 0h > > What happens: > When validation is triggered for any form in configuration, _two_ validation > messages are shown simultaneously: one under the input and another in tooltip. > !image-2018-11-30-14-59-19-188.png! > What should happen: > Tooltip-style validation messages should not be visible on configuration > screens. > The issues is caused by IGNITE-9811. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743668#comment-16743668 ] Ilya Borisov commented on IGNITE-10890: --- [~alexdel] looks good, [~kuaw26] please merge. > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2.5h > Remaining Estimate: 3.5h > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10890: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2.5h > Remaining Estimate: 3.5h > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10489) Web console: validation messages are shown twice in configuration
[ https://issues.apache.org/jira/browse/IGNITE-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-10489: - Assignee: Pavel Konstantinov (was: Ilya Borisov) > Web console: validation messages are shown twice in configuration > - > > Key: IGNITE-10489 > URL: https://issues.apache.org/jira/browse/IGNITE-10489 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-11-30-14-59-19-188.png > > Time Spent: 28m > Remaining Estimate: 0h > > What happens: > When validation is triggered for any form in configuration, _two_ validation > messages are shown simultaneously: one under the input and another in tooltip. > !image-2018-11-30-14-59-19-188.png! > What should happen: > Tooltip-style validation messages should not be visible on configuration > screens. > The issues is caused by IGNITE-9811. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743654#comment-16743654 ] Alexander Kalinin commented on IGNITE-10890: [~Klaster_1] Please review - https://github.com/apache/ignite/pull/5829 > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2h 10m > Remaining Estimate: 3h 50m > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-10890: -- Assignee: Ilya Borisov (was: Alexander Kalinin) > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Time Spent: 2h 10m > Remaining Estimate: 3h 50m > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10927) Relieve JUnit3TestLegacySupport from inheriting deprecated junit.framework.Assert (follow-up to IGNITE-10177)
[
https://issues.apache.org/jira/browse/IGNITE-10927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko reassigned IGNITE-10927:
---
Assignee: Oleg Ignatenko
> Relieve JUnit3TestLegacySupport from inheriting deprecated
> junit.framework.Assert (follow-up to IGNITE-10177)
> -
>
> Key: IGNITE-10927
> URL: https://issues.apache.org/jira/browse/IGNITE-10927
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
>
> {{JUnit3TestLegacySupport}} currently inherits deprecated
> {{junit.framework.Assert}}. This was done only in order to minimize risky
> code changes when tests were migrating from Junit 3, after
> {{GridAbstractTest}} has dropped inheriting {{junit.framework.TestCase}}.
> Now that migration is over it is less risky to cleanup project from
> deprecated assert methods and drop the harmful inheritance. In order to make
> this smoother and minimize amount of test changes, after inheritance is
> dropped, {{JUnit3TestLegacySupport}} should be extended with a set of
> "temporary patch" methods that would delegate most popular assertions used by
> subclasses to respective methods of {{org.junit.Assert}}.
> Mentioned temporary patch methods, in turn, should get {{@Deprecated}}
> annotation and respective {{2deprecation}} noticed in javadocs that would
> encourage developers to (safely and gradually) change them to direct
> invocations and static imports of respective Assert methods instead of using
> those inherited from superclass. These patch methods should be declared
> protected final or protected static final, to minimize their applicability
> and prevent them spreading more than intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743601#comment-16743601
]
Ignite TC Bot commented on IGNITE-10178:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2810230buildTypeId=IgniteTests24Java8_RunAllNightly]
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them.
> -
> Note that tests that are expected to be ignored depending on runtime
> conditions should be rewritten to use {{Assume}} instead of {{fail}}. So that
> old code...
> {code}if (someRuntimeCondition())
> fail("Ignite JIRA ticket URL");{code}
> ...will change to
> {code}Assume.assumeFalse("Ignite JIRA ticket URL",
> someRuntimeCondition());{code}
> (this change can be "extracted" into separate JIRA task if it is more
> convenient). Readers interested to find more details about how {{Assume}}
> works can find more details and code snippet [in comments
> here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10950) Lost backup entries when using spring data and cache store
[
https://issues.apache.org/jira/browse/IGNITE-10950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-10950:
Attachment: SpringRepositoryTest.java
> Lost backup entries when using spring data and cache store
> --
>
> Key: IGNITE-10950
> URL: https://issues.apache.org/jira/browse/IGNITE-10950
> Project: Ignite
> Issue Type: Bug
> Components: cache, spring
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: CacheRepository.java, SpringRepositoryTest.java
>
>
> For example, there are 2 server nodes in the cluster. Also, there is a
> replicated cache with a configured cache store. If we try loading entry
> through {{IgniteRepository#findById}} then it can be fetched from the
> cachestore successfully. But if we check the partitions for that entry we
> will find only one primary and there is no backup in the cluster. The
> reproducer is attached [^SpringRepositoryTest.java] [^CacheRepository.java]
> .
> As a workaround it is possible to use {{IgniteCache#get}} instead of
> {{IgniteRepository#findById}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10950) Lost backup entries when using spring data and cache store
[
https://issues.apache.org/jira/browse/IGNITE-10950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-10950:
Attachment: (was: SpringRepositoryTest.java)
> Lost backup entries when using spring data and cache store
> --
>
> Key: IGNITE-10950
> URL: https://issues.apache.org/jira/browse/IGNITE-10950
> Project: Ignite
> Issue Type: Bug
> Components: cache, spring
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: CacheRepository.java, SpringRepositoryTest.java
>
>
> For example, there are 2 server nodes in the cluster. Also, there is a
> replicated cache with a configured cache store. If we try loading entry
> through {{IgniteRepository#findById}} then it can be fetched from the
> cachestore successfully. But if we check the partitions for that entry we
> will find only one primary and there is no backup in the cluster. The
> reproducer is attached [^SpringRepositoryTest.java] [^CacheRepository.java]
> .
> As a workaround it is possible to use {{IgniteCache#get}} instead of
> {{IgniteRepository#findById}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10950) Lost backup entries when using spring data and cache store
[
https://issues.apache.org/jira/browse/IGNITE-10950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Guseinov updated IGNITE-10950:
Description:
For example, there are 2 server nodes in the cluster. Also, there is a
replicated cache with a configured cache store. If we try loading entry through
{{IgniteRepository#findById}} then it can be fetched from the cachestore
successfully. But if we check the partitions for that entry we will find only
one primary and there is no backup in the cluster. The reproducer is attached
[^SpringRepositoryTest.java] [^CacheRepository.java] .
As a workaround it is possible to use {{IgniteCache#get}} instead of
{{IgniteRepository#findById}}.
was:
For example, there are 2 server nodes in the cluster. Also, there is a
replicated cache with a configured cache store. If we try loading entry through
{{IgniteRepository#findById}} then it can be fetched from the cachestore
successfully. But if we check the partitions for that entry we will find only
one primary and there is no backup in the cluster. The reproducer is attached
[^SpringRepositoryTest.java] [^CacheRepository.java] .
As I workaround it is possible to use {{IgniteCache#get}} instead of
{{IgniteRepository#findById}}.
> Lost backup entries when using spring data and cache store
> --
>
> Key: IGNITE-10950
> URL: https://issues.apache.org/jira/browse/IGNITE-10950
> Project: Ignite
> Issue Type: Bug
> Components: cache, spring
>Affects Versions: 2.7
>Reporter: Roman Guseinov
>Priority: Major
> Attachments: CacheRepository.java, SpringRepositoryTest.java
>
>
> For example, there are 2 server nodes in the cluster. Also, there is a
> replicated cache with a configured cache store. If we try loading entry
> through {{IgniteRepository#findById}} then it can be fetched from the
> cachestore successfully. But if we check the partitions for that entry we
> will find only one primary and there is no backup in the cluster. The
> reproducer is attached [^SpringRepositoryTest.java] [^CacheRepository.java]
> .
> As a workaround it is possible to use {{IgniteCache#get}} instead of
> {{IgniteRepository#findById}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10950) Lost backup entries when using spring data and cache store
Roman Guseinov created IGNITE-10950:
---
Summary: Lost backup entries when using spring data and cache store
Key: IGNITE-10950
URL: https://issues.apache.org/jira/browse/IGNITE-10950
Project: Ignite
Issue Type: Bug
Components: cache, spring
Affects Versions: 2.7
Reporter: Roman Guseinov
Attachments: CacheRepository.java, SpringRepositoryTest.java
For example, there are 2 server nodes in the cluster. Also, there is a
replicated cache with a configured cache store. If we try loading entry through
{{IgniteRepository#findById}} then it can be fetched from the cachestore
successfully. But if we check the partitions for that entry we will find only
one primary and there is no backup in the cluster. The reproducer is attached
[^SpringRepositoryTest.java] [^CacheRepository.java] .
As I workaround it is possible to use {{IgniteCache#get}} instead of
{{IgniteRepository#findById}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10489) Web console: validation messages are shown twice in configuration
[ https://issues.apache.org/jira/browse/IGNITE-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-10489: - Assignee: Ilya Borisov (was: Pavel Konstantinov) > Web console: validation messages are shown twice in configuration > - > > Key: IGNITE-10489 > URL: https://issues.apache.org/jira/browse/IGNITE-10489 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2018-11-30-14-59-19-188.png > > Time Spent: 28m > Remaining Estimate: 0h > > What happens: > When validation is triggered for any form in configuration, _two_ validation > messages are shown simultaneously: one under the input and another in tooltip. > !image-2018-11-30-14-59-19-188.png! > What should happen: > Tooltip-style validation messages should not be visible on configuration > screens. > The issues is caused by IGNITE-9811. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9207) Update Web Console dependencies
[ https://issues.apache.org/jira/browse/IGNITE-9207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-9207: Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > Update Web Console dependencies > --- > > Key: IGNITE-9207 > URL: https://issues.apache.org/jira/browse/IGNITE-9207 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Major > Original Estimate: 2h > Time Spent: 4h > Remaining Estimate: 0h > > Update package.json to latest versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9207) Update Web Console dependencies
[ https://issues.apache.org/jira/browse/IGNITE-9207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9207: - Fix Version/s: (was: 2.8) > Update Web Console dependencies > --- > > Key: IGNITE-9207 > URL: https://issues.apache.org/jira/browse/IGNITE-9207 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Alexander Kalinin >Priority: Major > Original Estimate: 2h > Time Spent: 4h > Remaining Estimate: 0h > > Update package.json to latest versions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9758) Document data injection via the REST API
[
https://issues.apache.org/jira/browse/IGNITE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743456#comment-16743456
]
Prachi Garg commented on IGNITE-9758:
-
[~slukyanov], can you provide an example code/configuration?
> Document data injection via the REST API
>
>
> Key: IGNITE-9758
> URL: https://issues.apache.org/jira/browse/IGNITE-9758
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.6
>Reporter: Pavel Petroshenko
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.8
>
>
> There should a documentation on how to post data via the REST API.
>
> Just to capture what was proposed by [~ilyak] over email:
>
> {quote}REST API will convert complex BinaryObjects into JSON by default. But
> to put such objects via REST you will need to define your own
> ConnectorMessageInterceptor and plug it in. You will need to define string to
> entity mapping in onReceive. You can leave onSend returning arg.
>
> This interface should be used:
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/ConnectorMessageInterceptor.html].
> You need to put it into ConnectorConfiguration, which you should put into
> IgniteConfiguration.{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-8411: --- Assignee: Igor Sapego (was: Prachi Garg) > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.8 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743448#comment-16743448
]
Oleg Ignatenko commented on IGNITE-10178:
-
(i) first set of changes was made per [PR
5745|https://github.com/apache/ignite/pull/5745] which was further finalized in
[PR 5824|https://github.com/apache/ignite/pull/5824]
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them.
> -
> Note that tests that are expected to be ignored depending on runtime
> conditions should be rewritten to use {{Assume}} instead of {{fail}}. So that
> old code...
> {code}if (someRuntimeCondition())
> fail("Ignite JIRA ticket URL");{code}
> ...will change to
> {code}Assume.assumeFalse("Ignite JIRA ticket URL",
> someRuntimeCondition());{code}
> (this change can be "extracted" into separate JIRA task if it is more
> convenient). Readers interested to find more details about how {{Assume}}
> works can find more details and code snippet [in comments
> here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743435#comment-16743435
]
Eduard Shangareev commented on IGNITE-10796:
[~oignatenko], I've looked through. Looks good! Thank you for contribution.
> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10518) MVCC: Update operation may hangs on backup on unstable topology.
[
https://issues.apache.org/jira/browse/IGNITE-10518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743399#comment-16743399
]
Oleg Ignatenko edited comment on IGNITE-10518 at 1/15/19 9:48 PM:
--
(x) Teamcity history for reproducer
([IgniteTxCachePrimarySyncTest.testSingleKeyCommitFromPrimary|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4989034880085631279=testDetails])
suggests that problem hasn't been fixed in any imaginable way: I checked last
100 execution results for about 30 days since Dec 16 2018 and all of them
without any exception show all the same "muted failure" result:
{noformat}
Test status DurationBuild Info Changes Agent
Muted failure 18ms… MVCC Cache 9 pull/5823/head #1023 Tests
passed: 10, muted: 9 andrey.mashenk… (2) 14 Jan 19 17:34
publicagent17_9096
Muted failure 12ms… MVCC Cache 9 refs/heads/master #1020
Tests passed: 10, muted: 9 No changes 14 Jan 19 14:10
publicagent07_9092
Muted failure 24ms… MVCC Cache 9 refs/heads/master #1019
Tests passed: 10, muted: 9 No changes 14 Jan 19 13:06
publicagent13_9096
Muted failure 17ms… MVCC Cache 9 refs/heads/master #1018
Tests passed: 10, muted: 9 Changes (2) 14 Jan 19 12:17
publicagent10_9092
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1017
Tests passed: 10, muted: 9 Changes (2) 14 Jan 19 11:16
publicagent14_9096
Muted failure 14ms… MVCC Cache 9 refs/heads/master #1016
Tests passed: 10, muted: 9 No changes 14 Jan 19 10:06
publicagent11_9092
Muted failure 15ms… MVCC Cache 9 refs/heads/master #1015
Tests passed: 10, muted: 9 No changes 14 Jan 19 09:17
publicagent10_9096
Muted failure 12ms… MVCC Cache 9 refs/heads/master #1014
Tests passed: 10, muted: 9 No changes 14 Jan 19 08:28
publicagent11_9092
Muted failure 25ms… MVCC Cache 9 refs/heads/master #1013
Tests passed: 10, muted: 9 No changes 14 Jan 19 07:36
publicagent17_9091
Muted failure 16ms… MVCC Cache 9 refs/heads/master #1012
Tests passed: 10, muted: 9 No changes 14 Jan 19 06:46
publicagent11_9096
Muted failure 26ms… MVCC Cache 9 refs/heads/master #1011
Tests passed: 10, muted: 9 No changes 14 Jan 19 05:56
publicagent09_9094
Muted failure 8ms … MVCC Cache 9 refs/heads/master #1010
Tests passed: 10, muted: 9 No changes 14 Jan 19 05:07
publicagent17_9092
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1009
Tests passed: 10, muted: 9 No changes 14 Jan 19 04:16
publicagent15_9094
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1008
Tests passed: 10, muted: 9 No changes 14 Jan 19 03:26
publicagent16_9096
Muted failure 25ms… MVCC Cache 9 refs/heads/master #1007
Tests passed: 10, muted: 9 No changes 14 Jan 19 01:56
publicagent14_9094
Muted failure 10ms… MVCC Cache 9 refs/heads/master #1006
Tests passed: 10, muted: 9 No changes 14 Jan 19 01:06
publicagent16_9093
Muted failure 20ms… MVCC Cache 9 pull/5814/head #1005 Tests
passed: 9, ignored: 1, muted: 9 Oleg Ignatenko (79) 14 Jan 19 00:16
publicagent06_9092
Muted failure 13ms… MVCC Cache 9 refs/heads/master #1004
Tests passed: 10, muted: 9 No changes 13 Jan 19 23:47
publicagent16_9092
... etc{noformat}
I happened to find it out when re-running TC bot to get visa for IGNITE-10796
because I picked unmuted test from master. I re-run MVCC 9 suite several times
and every time it failed with execution timeout and it passed only after I
suppressed execution of reproducer back again.
Typical thread dump I observed from timed out test:
{noformat}
"sys-stripe-0-#557%distributed.IgniteTxCachePrimarySyncTest0%" #631 prio=5
os_prio=0 tid=0x7f7861d06000 nid=0x73583 waiting on condition
[0x7f7817af9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.StripedExecutor$StripeConcurrentQueue.take(StripedExecutor.java:672)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:494)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748){noformat}
(i) Reopening the ticket because of above. In case if I am mistaken -
[~amashenkov], [~gvvinblade], if you can provide successful teamcity execution
[jira] [Commented] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743400#comment-16743400
]
Ignite TC Bot commented on IGNITE-10796:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2806829buildTypeId=IgniteTests24Java8_RunAllNightly]
> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10518) MVCC: Update operation may hangs on backup on unstable topology.
[
https://issues.apache.org/jira/browse/IGNITE-10518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743399#comment-16743399
]
Oleg Ignatenko commented on IGNITE-10518:
-
(x) Teamcity history for reproducer
([IgniteTxCachePrimarySyncTest0.testSingleKeyCommitFromPrimary|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4989034880085631279=testDetails])
suggests that problem hasn't been fixed in any imaginable way: I checked last
100 execution results for about 30 days since Dec 16 2018 and all of them
without any exception show all the same "muted failure" result:
{noformat}
Test status DurationBuild Info Changes Agent
Muted failure 18ms… MVCC Cache 9 pull/5823/head #1023 Tests
passed: 10, muted: 9 andrey.mashenk… (2) 14 Jan 19 17:34
publicagent17_9096
Muted failure 12ms… MVCC Cache 9 refs/heads/master #1020
Tests passed: 10, muted: 9 No changes 14 Jan 19 14:10
publicagent07_9092
Muted failure 24ms… MVCC Cache 9 refs/heads/master #1019
Tests passed: 10, muted: 9 No changes 14 Jan 19 13:06
publicagent13_9096
Muted failure 17ms… MVCC Cache 9 refs/heads/master #1018
Tests passed: 10, muted: 9 Changes (2) 14 Jan 19 12:17
publicagent10_9092
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1017
Tests passed: 10, muted: 9 Changes (2) 14 Jan 19 11:16
publicagent14_9096
Muted failure 14ms… MVCC Cache 9 refs/heads/master #1016
Tests passed: 10, muted: 9 No changes 14 Jan 19 10:06
publicagent11_9092
Muted failure 15ms… MVCC Cache 9 refs/heads/master #1015
Tests passed: 10, muted: 9 No changes 14 Jan 19 09:17
publicagent10_9096
Muted failure 12ms… MVCC Cache 9 refs/heads/master #1014
Tests passed: 10, muted: 9 No changes 14 Jan 19 08:28
publicagent11_9092
Muted failure 25ms… MVCC Cache 9 refs/heads/master #1013
Tests passed: 10, muted: 9 No changes 14 Jan 19 07:36
publicagent17_9091
Muted failure 16ms… MVCC Cache 9 refs/heads/master #1012
Tests passed: 10, muted: 9 No changes 14 Jan 19 06:46
publicagent11_9096
Muted failure 26ms… MVCC Cache 9 refs/heads/master #1011
Tests passed: 10, muted: 9 No changes 14 Jan 19 05:56
publicagent09_9094
Muted failure 8ms … MVCC Cache 9 refs/heads/master #1010
Tests passed: 10, muted: 9 No changes 14 Jan 19 05:07
publicagent17_9092
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1009
Tests passed: 10, muted: 9 No changes 14 Jan 19 04:16
publicagent15_9094
Muted failure 18ms… MVCC Cache 9 refs/heads/master #1008
Tests passed: 10, muted: 9 No changes 14 Jan 19 03:26
publicagent16_9096
Muted failure 25ms… MVCC Cache 9 refs/heads/master #1007
Tests passed: 10, muted: 9 No changes 14 Jan 19 01:56
publicagent14_9094
Muted failure 10ms… MVCC Cache 9 refs/heads/master #1006
Tests passed: 10, muted: 9 No changes 14 Jan 19 01:06
publicagent16_9093
Muted failure 20ms… MVCC Cache 9 pull/5814/head #1005 Tests
passed: 9, ignored: 1, muted: 9 Oleg Ignatenko (79) 14 Jan 19 00:16
publicagent06_9092
Muted failure 13ms… MVCC Cache 9 refs/heads/master #1004
Tests passed: 10, muted: 9 No changes 13 Jan 19 23:47
publicagent16_9092
... etc{noformat}
I happened to find it out when re-running TC bot to get visa for IGNITE-10796
because I picked unmuted test from master. I re-run MVCC 9 suite several times
and every time it failed with execution timeout and it passed only after I
suppressed execution of reproducer back again.
Typical thread dump I observed from timed out test:
{noformat}
"sys-stripe-0-#557%distributed.IgniteTxCachePrimarySyncTest0%" #631 prio=5
os_prio=0 tid=0x7f7861d06000 nid=0x73583 waiting on condition
[0x7f7817af9000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.StripedExecutor$StripeConcurrentQueue.take(StripedExecutor.java:672)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:494)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748){noformat}
(i) Reopening the ticket because of above. In case if I am mistaken -
[~amashenkov], [~gvvinblade], if you can provide successful teamcity execution
results for this test case (or better yet, TC bot
[jira] [Reopened] (IGNITE-10518) MVCC: Update operation may hangs on backup on unstable topology.
[ https://issues.apache.org/jira/browse/IGNITE-10518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko reopened IGNITE-10518: - > MVCC: Update operation may hangs on backup on unstable topology. > - > > Key: IGNITE-10518 > URL: https://issues.apache.org/jira/browse/IGNITE-10518 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: Hanging, failover, mvcc_stabilization_stage_1 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > Update operation may hangs on backup awaiting next topology. > Symptoms: > # Exchange for topology version 6.1 has been finished. > # Exchange for topology version 6.2 awaits for partition release. > # DhtTxRemote waits for exchange. > Seems, tx maps on outdated topology version. > Reproducer IgniteTxCachePrimarySyncTest.testSingleKeyCommit() in Mvcc mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743385#comment-16743385
]
Ignite TC Bot commented on IGNITE-6564:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2805544buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect calculation size and keySize for cluster cache metrics
>
>
> Key: IGNITE-6564
> URL: https://issues.apache.org/jira/browse/IGNITE-6564
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Alexand Polyakov
>Priority: Minor
> Labels: iep-6
>
> They are currently not passed by ring and therefore only taken from current
> node, which returns incorrect (local) value.
> See CacheMetricsSnapshot class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10852) [Documentation] - Add details on to public API behaviour
[ https://issues.apache.org/jira/browse/IGNITE-10852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743357#comment-16743357 ] Prachi Garg commented on IGNITE-10852: -- Updated the docs. - [https://apacheignite.readme.io/v2.7/docs/exception-handling-28] > [Documentation] - Add details on to public API behaviour > > > Key: IGNITE-10852 > URL: https://issues.apache.org/jira/browse/IGNITE-10852 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.4, 2.5, 2.6, 2.7 >Reporter: Alexander Gerus >Assignee: Prachi Garg >Priority: Major > Fix For: 2.8 > > > Current public API documentation has some specification gaps. In case if > method was not successfully executed, it is not clear what should be done by > user code. > Good practice is to describe all API exceptions that can be processed by user > code and recommended actions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10879) Create suite of Cassandra Cache Store tests, add to TC
[ https://issues.apache.org/jira/browse/IGNITE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743231#comment-16743231 ] Ilya Kasnacheev commented on IGNITE-10879: -- [~irudyak] please review proposed test suite for Cassandra Store > Create suite of Cassandra Cache Store tests, add to TC > -- > > Key: IGNITE-10879 > URL: https://issues.apache.org/jira/browse/IGNITE-10879 > Project: Ignite > Issue Type: Sub-task > Components: cassandra >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > Currently, they're not running in TC at all -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10573) [ML] Consistent API for Ensemble training
[ https://issues.apache.org/jira/browse/IGNITE-10573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Malykh updated IGNITE-10573: -- Description: Unify API for ensemble training algorithms. Also unify "engines" for ensemble algorithms > [ML] Consistent API for Ensemble training > - > > Key: IGNITE-10573 > URL: https://issues.apache.org/jira/browse/IGNITE-10573 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > Time Spent: 9h 10m > Remaining Estimate: 0h > > Unify API for ensemble training algorithms. Also unify "engines" for ensemble > algorithms -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10573) [ML] Consistent API for Ensemble training
[ https://issues.apache.org/jira/browse/IGNITE-10573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-10573: Fix Version/s: 2.8 > [ML] Consistent API for Ensemble training > - > > Key: IGNITE-10573 > URL: https://issues.apache.org/jira/browse/IGNITE-10573 > Project: Ignite > Issue Type: Improvement > Components: ml >Reporter: Yury Babak >Assignee: Artem Malykh >Priority: Major > Fix For: 2.8 > > Time Spent: 9h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743205#comment-16743205 ] Pavel Voronkin commented on IGNITE-10877: - Benchmark Mode Cnt Score Error Units SmallHashSetsVsReadOnlyViewBenchmark.hashSetContainsRandom thrpt 20 26221395,193 ± 240929,392 ops/s SmallHashSetsVsReadOnlyViewBenchmark.hashSetIteratorRandom thrpt 20 12626598,194 ± 1742223,886 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewContainsRandom thrpt 20 23301229,681 ± 534549,170 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewIteratorRandom thrpt 20 21134614,093 ± 666488,488 ops/s we see 2x improvement in iterator and slight reduce in contains() in addition to reduced allocations. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr > > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10877) GridAffinityAssignment.initPrimaryBackupMaps memory pressure
[ https://issues.apache.org/jira/browse/IGNITE-10877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743205#comment-16743205 ] Pavel Voronkin edited comment on IGNITE-10877 at 1/15/19 4:41 PM: -- Benchmark Mode Cnt Score Error Units SmallHashSetsVsReadOnlyViewBenchmark.hashSetContainsRandom thrpt 20 25690717,349 ± 200741,979 ops/s SmallHashSetsVsReadOnlyViewBenchmark.hashSetIteratorRandom thrpt 20 12836581,770 ± 248020,906 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewContainsRandom thrpt 20 22278517,368 ± 339376,502 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewIteratorRandom thrpt 20 19959598,363 ± 709696,316 ops/s we see 2x improvement in iterator and slight reduce in contains() in addition to reduced allocations. was (Author: voropava): Benchmark Mode Cnt Score Error Units SmallHashSetsVsReadOnlyViewBenchmark.hashSetContainsRandom thrpt 20 26221395,193 ± 240929,392 ops/s SmallHashSetsVsReadOnlyViewBenchmark.hashSetIteratorRandom thrpt 20 12626598,194 ± 1742223,886 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewContainsRandom thrpt 20 23301229,681 ± 534549,170 ops/s SmallHashSetsVsReadOnlyViewBenchmark.readOnlyViewIteratorRandom thrpt 20 21134614,093 ± 666488,488 ops/s we see 2x improvement in iterator and slight reduce in contains() in addition to reduced allocations. > GridAffinityAssignment.initPrimaryBackupMaps memory pressure > > > Key: IGNITE-10877 > URL: https://issues.apache.org/jira/browse/IGNITE-10877 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Major > Attachments: grid.srv.node.1.0-29.12.2018-12.50.15.jfr > > > 1) While running tests with JFR we observe huge memory allocation pressure > produced by: > *Stack Trace TLABs Total TLAB Size(bytes) Pressure(%)* > java.util.HashMap.newNode(int, Object, Object, HashMap$Node) 481 298 044 784 > 100 > java.util.HashMap.putVal(int, Object, Object, boolean, boolean) 481 298 044 > 784 100 > java.util.HashMap.put(Object, Object) 481 298 044 784 100 > java.util.HashSet.add(Object) 480 297 221 040 99,724 > > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.initPrimaryBackupMaps() > 1 823 744 0,276 > org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.(AffinityTopologyVersion, > List, List) 1 823 744 0,276 > *Allocation stats* > Class Average Object Size(bytes) Total Object Size(bytes) TLABs Average TLAB > Size(bytes) Total TLAB Size(bytes) Pressure(%) > java.util.HashMap$Node 32 15 392 481 619 635,726 298 044 784 32,876 > java.lang.Object[] 1 470,115 461 616 314 655 019,236 205 676 040 22,687 > java.util.HashMap$Node[] 41 268,617 6 149 024 149 690 046,067 102 816 864 > 11,341 > java.lang.Integer 16 1 456 91 662 911,385 60 324 936 6,654 > java.util.ArrayList 24 1 608 67 703 389,97 47 127 128 5,198 > 2) Also another hot place found > Stack Trace TLABs Total TLAB Size(bytes) Pressure(%) > java.util.ArrayList.grow(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureExplicitCapacity(int) 7 5 766 448 9,554 > java.util.ArrayList.ensureCapacityInternal(int) 7 5 766 448 9,554 > java.util.ArrayList.add(Object) 7 5 766 448 9,554 > > org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.nodes(int, > AffinityTopologyVersion, GridDhtPartitionState, GridDhtPartitionState[]) 7 5 > 766 448 9,554 > The reason of that is defail > I think we need to improve memory efficiency by switching from from Sets to > BitSets > > JFR attached, see Allocations in 12:50:28 - 12:50:29 > > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10949) org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE
Alexand Polyakov created IGNITE-10949: - Summary: org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE Key: IGNITE-10949 URL: https://issues.apache.org/jira/browse/IGNITE-10949 Project: Ignite Issue Type: Bug Components: binary Affects Versions: 2.7 Reporter: Alexand Polyakov method entrySet return null then generates NullPointerException in method hashCode, toString and all classes that use an instance of this object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10948) Ignition.Stop() methods (named, all, etc.) fail to Stop cluster nodes
Glenn Wiebe created IGNITE-10948:
Summary: Ignition.Stop() methods (named, all, etc.) fail to Stop
cluster nodes
Key: IGNITE-10948
URL: https://issues.apache.org/jira/browse/IGNITE-10948
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.7
Environment: [08:32:01] __
[08:32:01] / _/ ___/ |/ / _/_ __/ __/
[08:32:01] _/ // (7 7 // / / / / _/
[08:32:01] /___/\___/_/|_/___/ /_/ /___/
[08:32:01]
[08:32:01] ver. 2.7.1#20181210-sha1:a39dbf0f
[08:32:01] 2018 Copyright(C) Apache Software Foundation
[08:32:01]
[08:32:01] Ignite documentation: http://ignite.apache.org
[08:32:01]
[08:32:01] Quiet mode.
[08:32:01] ^-- Logging to file
'C:\apps\gridgain-ultimate-8.7.1\work\log\ignite-55082e2d.0.log'
[08:32:01] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
[08:32:01] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
"-v" to ignite.\{sh|bat}
[08:32:01]
[08:32:01] OS: Windows 10 10.0 amd64
[08:32:01] VM information: Java(TM) SE Runtime Environment 1.8.0_162-b12 Oracle
Corporation Java HotSpot(TM) 64-Bit Server VM 25.162-b12
Reporter: Glenn Wiebe
Fix For: 3.0, 2.8
The Ignition singleton stop() or stopAll() methods do not respond by stopping
any or all of the cluster nodes.
Unlike the ignite.cluster().stop() methods, the Ignition.stop() methods ignore
the requested stop command, simply returning the following warning: "(wrn)
Ignoring stopping Ignite instance that was already stopped or never started:
MyServerName"
This fails whether the cluster was active() = true or false.
This fails whether the command was issued from a Server or Client node.
Maybe this method should be deprecated, but currently documented method does
not work.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10640) Create cluster-wide MetaStorage analogue
[
https://issues.apache.org/jira/browse/IGNITE-10640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743151#comment-16743151
]
Ignite TC Bot commented on IGNITE-10640:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2798185buildTypeId=IgniteTests24Java8_RunAll]
> Create cluster-wide MetaStorage analogue
>
>
> Key: IGNITE-10640
> URL: https://issues.apache.org/jira/browse/IGNITE-10640
> Project: Ignite
> Issue Type: New Feature
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: IEP-4, Phase-2
>
> Issues like IGNITE-8571 require the ability to store and update some
> properties consistently on the whole cluster. It is proposed to implement
> generic way of doing this. Main requirements are:
> * read / write / delete;
> * surviving node / cluster restart;
> * consistency;
> * ability to add listeners on changing properties.
> First implementation is going to be based on local MetaStorage to guarantee
> data persistence. Existing MetaStorage API is a subject to change as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10305:
Assignee: Alexander Lapin
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6826) Change default DiscoverySpi ipFinder type for examples
[ https://issues.apache.org/jira/browse/IGNITE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743141#comment-16743141 ] Ivan Bessonov commented on IGNITE-6826: --- [~SomeFire] changes look good, thank you! > Change default DiscoverySpi ipFinder type for examples > -- > > Key: IGNITE-6826 > URL: https://issues.apache.org/jira/browse/IGNITE-6826 > Project: Ignite > Issue Type: Improvement > Components: examples >Affects Versions: 2.3 >Reporter: Alexey Popov >Assignee: Ryabov Dmitrii >Priority: Major > Labels: newbie > Fix For: 2.8 > > > It is better to change multicast ipFinder to static (vm) ipFinder for java > examples, .NET examples and C++ examples. > http://apache-ignite-developers.2346864.n4.nabble.com/ipFinder-configuration-for-Samples-td23818.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[ https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743118#comment-16743118 ] Vladimir Ozerov commented on IGNITE-10754: -- [~jooger], confirming. > Query history statistics API > > > Key: IGNITE-10754 > URL: https://issues.apache.org/jira/browse/IGNITE-10754 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29, monitoring > Time Spent: 40m > Remaining Estimate: 0h > > As of now we have query statistics > (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. > 1) Duration execution it just time between start execution and return cursor > to client and doesn't include all life time of query. > 2) It doesn't know about multistatement queries. Such queries participate in > statistics as single query without splitting. > 3) API to access the statistics expose as depend on cache, however query > don't have such dependency. > > Need to create parallel similar realization as we already have. > Use new infrastructure of tracking running queries developed under > IGNITE-10621 and update statistics on unregister phase. > Expose API on upper level then it placed now. Right place will be written > later. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10946) --excludeCaches do not fit unified argument naming format
[
https://issues.apache.org/jira/browse/IGNITE-10946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov resolved IGNITE-10946.
-
Resolution: Duplicate
Will be fixed in IGNITE-10507
> --excludeCaches do not fit unified argument naming format
> -
>
> Key: IGNITE-10946
> URL: https://issues.apache.org/jira/browse/IGNITE-10946
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Priority: Major
> Fix For: 2.5
>
>
> IGNITE-10279 unifies options / arguments naming format.
> but in the mean time, new option _excludeCaches_ introduced to _--cache
> idle_verify_ do not fit that format:
> A piece of help:
> {noformat}
> --cache idle_verify [--dump] [--skip-zeros] [--excludeCaches
> cache1,...,cacheN|[--cache-filter
> ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]|cache1,...,cacheN]
>
> Verify counters and hash sums of primary and backup partitions for the
> specified caches on an idle cluster and print out the differences, if any.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-10946) --excludeCaches do not fit unified argument naming format
[
https://issues.apache.org/jira/browse/IGNITE-10946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov closed IGNITE-10946.
---
Assignee: Sergey Antonov
Ignite Flags: (was: Docs Required)
> --excludeCaches do not fit unified argument naming format
> -
>
> Key: IGNITE-10946
> URL: https://issues.apache.org/jira/browse/IGNITE-10946
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.5
>
>
> IGNITE-10279 unifies options / arguments naming format.
> but in the mean time, new option _excludeCaches_ introduced to _--cache
> idle_verify_ do not fit that format:
> A piece of help:
> {noformat}
> --cache idle_verify [--dump] [--skip-zeros] [--excludeCaches
> cache1,...,cacheN|[--cache-filter
> ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]|cache1,...,cacheN]
>
> Verify counters and hash sums of primary and backup partitions for the
> specified caches on an idle cluster and print out the differences, if any.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743102#comment-16743102
]
Igor Sapego commented on IGNITE-10940:
--
Added related documentation ticket.
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Priority: Major
> Labels: c++
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10947) CPP: Fix documentation on how to build Ignite C++ on Linux
Igor Sapego created IGNITE-10947:
Summary: CPP: Fix documentation on how to build Ignite C++ on Linux
Key: IGNITE-10947
URL: https://issues.apache.org/jira/browse/IGNITE-10947
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Igor Sapego
We now have build step (IGNITE-10940) that performs following steps during
release of the binary package of the Ignite:
{code}
# libtoolize
# aclocal
# autoheader
# automake --add-missing
# autoreconf
{code}
So we now should change documentation, that users only need to run following
commands to build Ignite C++ from binary distribution of Ignite.
{code}
# ./configure
# make
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743085#comment-16743085
]
Igor Sapego commented on IGNITE-10940:
--
[~ilyak],
I totally support this initiative.
[~vveider],
It will not work on our Windows agents, if that's was what you were asking, so
this step only should be performed on Unix-like agents.
If you mean generated ./configure script - than no, it is platform-independent.
Actually, its purpose is to create Makefile for any platform.
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Priority: Major
> Labels: c++
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10946) --excludeCaches do not fit unified argument naming format
Max Shonichev created IGNITE-10946:
--
Summary: --excludeCaches do not fit unified argument naming format
Key: IGNITE-10946
URL: https://issues.apache.org/jira/browse/IGNITE-10946
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Max Shonichev
Fix For: 2.5
IGNITE-10279 unifies options / arguments naming format.
but in the mean time, new option _excludeCaches_ introduced to _--cache
idle_verify_ do not fit that format:
A piece of help:
{noformat}
--cache idle_verify [--dump] [--skip-zeros] [--excludeCaches
cache1,...,cacheN|[--cache-filter
ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]|cache1,...,cacheN]
Verify counters and hash sums of primary and backup partitions for the
specified caches on an idle cluster and print out the differences, if any.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10507) Control.sh add ability to check crc sums of stored pages
[
https://issues.apache.org/jira/browse/IGNITE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743078#comment-16743078
]
Ignite TC Bot commented on IGNITE-10507:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2804511buildTypeId=IgniteTests24Java8_RunAll]
> Control.sh add ability to check crc sums of stored pages
>
>
> Key: IGNITE-10507
> URL: https://issues.apache.org/jira/browse/IGNITE-10507
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Critical
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should have ability to check stored data on disk. Also we should return
> all exceptions from all nodes, if they are occurred.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10945) Document Baseline auto-adjust feature
Ivan Bessonov created IGNITE-10945:
--
Summary: Document Baseline auto-adjust feature
Key: IGNITE-10945
URL: https://issues.apache.org/jira/browse/IGNITE-10945
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Ivan Bessonov
Assignee: Artem Budnikov
>From IGNITE-8571:
Now we have only one way to change BLAT - manually update it via console.sh or
API.
We need to add the possibility to change it automatically. Adjust to current
topology.
So, I propose 3 new parameters which would be responsible to tune this feature.
1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto
adjusting baseline.
2. autoAdjustTimeout - time which we would wait after the actual topology
change. But it would be reset if new discovery event happened. (node join/exit).
3. autoAdjustMaxTimeout - time which we would wait from the first dicovery
event in the chain. If we achieved it than we would change BLAT right away (no
matter were another node join/exit happened or not).
We need to change API next way:
1. org.apache.ignite.IgniteCluster
*Add*
isBaselineAutoAdjustEnabled()
setBaselineAutoAdjustEnabled(boolean enabled);
setBaselineAutoAdjustTimeout(long timeoutInMs);
setBaselineAutoAdjustMaxTimeout(long timeoutInMs);
2. org.apache.ignite.configuration.IgniteConfiguration
*Add*
IgniteConfiguration setBaselineAutoAdjustEnabled(boolean enabled);
IgniteConfiguration setBaselineAutoAdjustTimeout(long timeoutInMs);
IgniteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs);
Also, we need to ensure that all nodes would have the same parameters.
And we should be able to survive coordinator left during parameters changes.
-
For IGNITE-8575:
Proposed API format for control.sh:
{{--baseline autoadjust disable}}
{{--baseline autoadjust enable }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8571) Baseline auto-adjust feature
[ https://issues.apache.org/jira/browse/IGNITE-8571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-8571: -- Fix Version/s: 2.8 > Baseline auto-adjust feature > > > Key: IGNITE-8571 > URL: https://issues.apache.org/jira/browse/IGNITE-8571 > Project: Ignite > Issue Type: New Feature >Reporter: Eduard Shangareev >Priority: Major > Labels: IEP-4, Phase-2 > Fix For: 2.8 > > > Now we have only one way to change BLAT - manually update it via console.sh > or API. > We need to add the possibility to change it automatically. Adjust to current > topology. > So, I propose 3 new parameters which would be responsible to tune this > feature. > 1. Flag autoAdjustEnabled - true/false. Easy. Manual baseline control or auto > adjusting baseline. > 2. autoAdjustTimeout - time which we would wait after the actual topology > change. But it would be reset if new discovery event happened. (node > join/exit). > 3. autoAdjustMaxTimeout - time which we would wait from the first dicovery > event in the chain. If we achieved it than we would change BLAT right away > (no matter were another node join/exit happened or not). > We need to change API next way: > 1. org.apache.ignite.IgniteCluster > *Add* > isBaselineAutoAdjustEnabled() > setBaselineAutoAdjustEnabled(boolean enabled); > setBaselineAutoAdjustTimeout(long timeoutInMs); > setBaselineAutoAdjustMaxTimeout(long timeoutInMs); > 2. org.apache.ignite.configuration.IgniteConfiguration > *Add* > IgniteConfiguration setBaselineAutoAdjustEnabled(boolean enabled); > IgniteConfiguration setBaselineAutoAdjustTimeout(long timeoutInMs); > IgniteConfiguration setBaselineAutoAdjustMaxTimeout(long timeoutInMs); > Also, we need to ensure that all nodes would have the same parameters. > And we should be able to survive coordinator left during parameters changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743051#comment-16743051 ] Mikhail Cherkasov commented on IGNITE-10886: [~skozlov] could you please help me with testing of this change? I tested it manually, but might be you know/have some automated tests for sh scripts? > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov updated IGNITE-10944: Description: *Current sequence:* 1)Server starts (coordinator) 2)Client starts 3)Client sends to the coordinator its discovery data using *provideDiscoveryData* method 4)Coordinator start validation of the node using *validateNewNode* 5)The client joins the cluster; otherwise fails 6)Coordinator provides the discovery data to plugin provider in *receiveDiscoveryData.* After that this data could be passed to the plugin. But in case if we require to validate new node using the discovery data from *receiveDiscoveryData* method then we should add a possibility to get this data in *validateNewNode* method. was: *Current sequence:* 1)Server starts (coordinator) 2)Client starts 3)Client sends to the coordinator its discovery data using *provideDiscoveryData* method 4)Coordinator start validation of the node using *validateNewNode* 5)The client joins the cluster; otherwise fails 6)Coordinator provides the discovery data to plugin provider in *receiveDiscoveryData.* After that this data could be passed to the plugin. But in case if we require to validate new node using the discovery data from *receiveDiscoveryData* method. We should add a possibility to get this data in *validateNewNode* method. > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method then we should add a possibility to get this > data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov updated IGNITE-10944: Fix Version/s: 2.8 > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method. We should add a possibility to get this data > in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
Andrey Aleksandrov created IGNITE-10944: --- Summary: Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode Key: IGNITE-10944 URL: https://issues.apache.org/jira/browse/IGNITE-10944 Project: Ignite Issue Type: Improvement Reporter: Andrey Aleksandrov *Current sequence:* 1)Server starts (coordinator) 2)Client starts 3)Client sends to the coordinator its discovery data using *provideDiscoveryData* method 4)Coordinator start validation of the node using *validateNewNode* 5)The client joins the cluster; otherwise fails 6)Coordinator provides the discovery data to plugin provider in *receiveDiscoveryData.* After that this data could be passed to the plugin. But in case if we require to validate new node using the discovery data from *receiveDiscoveryData* method. We should add a possibility to get this data in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10944) Plugin discovery data from PluginProvider.provideDiscoveryData should be available in PluginProvider.validateNewNode
[ https://issues.apache.org/jira/browse/IGNITE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov updated IGNITE-10944: Affects Version/s: 2.7 > Plugin discovery data from PluginProvider.provideDiscoveryData should be > available in PluginProvider.validateNewNode > > > Key: IGNITE-10944 > URL: https://issues.apache.org/jira/browse/IGNITE-10944 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.8 > > > *Current sequence:* > > 1)Server starts (coordinator) > 2)Client starts > 3)Client sends to the coordinator its discovery data using > *provideDiscoveryData* method > 4)Coordinator start validation of the node using *validateNewNode* > 5)The client joins the cluster; otherwise fails > 6)Coordinator provides the discovery data to plugin provider in > *receiveDiscoveryData.* After that this data could be passed to the plugin. > But in case if we require to validate new node using the discovery data from > *receiveDiscoveryData* method. We should add a possibility to get this data > in *validateNewNode* method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10941) Ignite won't build with Java 11
[
https://issues.apache.org/jira/browse/IGNITE-10941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kalinin updated IGNITE-10941:
Description:
*sun.misc*, *sun.nio.ch*, *com.sun.jmx.mbeanserver* is no longer supported in
Java 11. This makes it impossible to build Apache Ignite for this version.
When I run the _Buil Progect_ from the IDEA IDE, I get the following error
messages (Warnings removed):
{code:java}
Information:java: Errors occurred while compiling module 'ignite-core'
Information:javac 11.0.1 was used to compile java sources
Information:15.01.19 14:07 - Compilation completed with 33 errors and 100
warnings in 33 s 148 ms
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java
Error:(258, 16) java: package sun.misc does not exist
Error:(8743, 29) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.IgniteUtils
Error:(8743, 49) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.IgniteUtils
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/util/GridUnsafe.java
Error:(32, 16) java: package sun.misc does not exist
Error:(60, 26) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1389, 20) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1391, 20) java: cannot find symbol
symbol: variable Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1396, 52) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1397, 42) java: cannot find symbol
symbol: class Unsafe
Error:(1398, 39) java: cannot find symbol
symbol: class Unsafe
Error:(1402, 37) java: cannot find symbol
symbol: class Unsafe
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryMarshaller.java
Error:(31, 16) java: package sun.misc does not exist
Error:(56, 29) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.binary.BinaryMarshaller
Error:(56, 49) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.binary.BinaryMarshaller
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/marshaller/optimized/OptimizedMarshaller.java
Error:(34, 16) java: package sun.misc does not exist
Error:(285, 29) java: cannot find symbol
symbol: class Unsafe
location: class
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller
Error:(285, 49) java: cannot find symbol
symbol: class Unsafe
location: class
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java
Error:(30, 16) java: package sun.misc does not exist
Error:(327, 38) java: package sun.misc does not exist
Error:(1693, 34) java: package sun.misc does not exist
Error:(1716, 12) java: cannot find symbol
symbol: class Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1718, 20) java: cannot find symbol
symbol: variable Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1723, 52) java: cannot find symbol
symbol: class Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1725, 32) java: cannot find symbol
symbol: class Unsafe
Error:(1726, 39) java: cannot find symbol
symbol: class Unsafe
Error:(1730, 37) java: cannot find symbol
symbol: class Unsafe
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/mem/file/MappedFile.java
Error:(29, 18) java: package sun.nio.ch does not exist
Error:(33, 62) java: cannot find symbol
symbol: class FileChannelImpl
location: class org.apache.ignite.internal.mem.file.MappedFile
Error:(36, 64) java: cannot find symbol
symbol: class FileChannelImpl
location: class org.apache.ignite.internal.mem.file.MappedFile
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/tck/TCKMBeanServerBuilder.java
Error:(20, 31) java: package com.sun.jmx.mbeanserver does not exist
Error:(37, 16) java: cannot find symbol
symbol: variable JmxMBeanServer
location: class org.apache.ignite.internal.tck.TCKMBeanServerBuilder
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/util/UnsafeDirectBufferCleaner.java
Error:(22, 16) java: package sun.misc does not exist
Error:(36, 26) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.UnsafeDirectBufferCleaner
---{code}
Trying to build with Maven produces the same result.
{code:java}
$ mvn compile -Plgpl
[jira] [Updated] (IGNITE-10943) "No next node in topology" infinite messages in log after cycle cluster nodes restart
[
https://issues.apache.org/jira/browse/IGNITE-10943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sherstobitov updated IGNITE-10943:
-
Attachment: grid.1.node.1.jstack.log
> "No next node in topology" infinite messages in log after cycle cluster nodes
> restart
> -
>
> Key: IGNITE-10943
> URL: https://issues.apache.org/jira/browse/IGNITE-10943
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Dmitry Sherstobitov
>Priority: Critical
> Attachments: grid.1.node.1.jstack.log
>
>
> Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
> After cluster restarted here is one node with 100% CPU load and following
> messages in log:
> {code:java}
> 2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
> Message has been added to queue: TcpDiscoveryNodeFailedMessage
> [failedNodeId=e006e575-bbc8-4004-8ce3-ddc165d1748c, order=12, warning=null,
> super=TcpDiscoveryAbstractMessage [sndNodeId=null,
> id=3cfe0715861-24a27aff-e471-4db1-ac46-cda072de17b9, verifierNodeId=null,
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]
> 2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
> Pending messages will be resent to local node
> 2019-01-15T15:16:41,333][INFO ][tcp-disco-srvr-#3][TcpDiscoverySpi] TCP
> discovery spawning a new thread for connection [rmtAddr=/172.25.1.40,
> rmtPort=59236]
> 2019-01-15T15:16:41,333][INFO ][tcp-disco-sock-reader-#21][TcpDiscoverySpi]
> Started serving remote node connection [rmtAddr=/172.25.1.40:59236,
> rmtPort=59236]
> 2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
> Message has been added to queue: TcpDiscoveryStatusCheckMessage
> [creatorNode=TcpDiscoveryNode [id=24a27aff-e471-4db1-ac46-cda072de17b9,
> addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 172.25.1.40],
> sockAddrs=[/172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500,
> lab40.gridgain.local/172.25.1.40:47500, /127.0.0.1:47500], discPort=47500,
> order=0, intOrder=15, lastExchangeTime=1547554584282, loc=true,
> ver=2.4.13#20190114-sha1:a7667ae6, isClient=false], failedNodeId=null,
> status=0, super=TcpDiscoveryAbstractMessage [sndNodeId=null,
> id=4cfe0715861-24a27aff-e471-4db1-ac46-cda072de17b9, verifierNodeId=null,
> topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]
> 2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
> Ignore message failed nodes, sender node is in fail list
> [nodeId=e006e575-bbc8-4004-8ce3-ddc165d1748c,
> failedNodes=[a251994d-8df6-4b2d-a28c-18ec55a3a48c,
> a5fa9095-2e4b-48e5-803d-551a5ebde558]]
> 2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,334][DEBUG][tcp-disco-sock-reader-#21][TcpDiscoverySpi]
> Initialized connection with remote node
> [nodeId=6df245fe-6288-4d93-ab20-2b9ac1b35771, client=false]
> 2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,336][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.
> 2019-01-15T15:16:41,336][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
> next node in topology.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10943) "No next node in topology" infinite messages in log after cycle cluster nodes restart
Dmitry Sherstobitov created IGNITE-10943:
Summary: "No next node in topology" infinite messages in log after
cycle cluster nodes restart
Key: IGNITE-10943
URL: https://issues.apache.org/jira/browse/IGNITE-10943
Project: Ignite
Issue Type: Bug
Affects Versions: 2.4
Reporter: Dmitry Sherstobitov
Attachments: grid.1.node.1.jstack.log
Same scenario as in https://issues.apache.org/jira/browse/IGNITE-10878
After cluster restarted here is one node with 100% CPU load and following
messages in log:
{code:java}
2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
Message has been added to queue: TcpDiscoveryNodeFailedMessage
[failedNodeId=e006e575-bbc8-4004-8ce3-ddc165d1748c, order=12, warning=null,
super=TcpDiscoveryAbstractMessage [sndNodeId=null,
id=3cfe0715861-24a27aff-e471-4db1-ac46-cda072de17b9, verifierNodeId=null,
topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]
2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
Pending messages will be resent to local node
2019-01-15T15:16:41,333][INFO ][tcp-disco-srvr-#3][TcpDiscoverySpi] TCP
discovery spawning a new thread for connection [rmtAddr=/172.25.1.40,
rmtPort=59236]
2019-01-15T15:16:41,333][INFO ][tcp-disco-sock-reader-#21][TcpDiscoverySpi]
Started serving remote node connection [rmtAddr=/172.25.1.40:59236,
rmtPort=59236]
2019-01-15T15:16:41,333][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
Message has been added to queue: TcpDiscoveryStatusCheckMessage
[creatorNode=TcpDiscoveryNode [id=24a27aff-e471-4db1-ac46-cda072de17b9,
addrs=[0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 172.25.1.40],
sockAddrs=[/172.17.0.1:47500, /0:0:0:0:0:0:0:1%lo:47500,
lab40.gridgain.local/172.25.1.40:47500, /127.0.0.1:47500], discPort=47500,
order=0, intOrder=15, lastExchangeTime=1547554584282, loc=true,
ver=2.4.13#20190114-sha1:a7667ae6, isClient=false], failedNodeId=null,
status=0, super=TcpDiscoveryAbstractMessage [sndNodeId=null,
id=4cfe0715861-24a27aff-e471-4db1-ac46-cda072de17b9, verifierNodeId=null,
topVer=0, pendingIdx=0, failedNodes=null, isClient=false]]
2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi]
Ignore message failed nodes, sender node is in fail list
[nodeId=e006e575-bbc8-4004-8ce3-ddc165d1748c,
failedNodes=[a251994d-8df6-4b2d-a28c-18ec55a3a48c,
a5fa9095-2e4b-48e5-803d-551a5ebde558]]
2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,334][DEBUG][tcp-disco-sock-reader-#21][TcpDiscoverySpi]
Initialized connection with remote node
[nodeId=6df245fe-6288-4d93-ab20-2b9ac1b35771, client=false]
2019-01-15T15:16:41,334][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,335][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,336][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.
2019-01-15T15:16:41,336][DEBUG][tcp-disco-msg-worker-#2][TcpDiscoverySpi] No
next node in topology.{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743035#comment-16743035
]
Ilya Kasnacheev commented on IGNITE-10940:
--
[~vveider] It is NOT platform dependant as far as my understanding goes. You
could run it on FreeBSD or Cygwin if you liked and the result will be the same.
Can you try and introduce such build phase? How is our release process shaped?
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Priority: Major
> Labels: c++
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10942) [TC Bot] Optimize backround JIRA tickets sync
Dmitriy Pavlov created IGNITE-10942: --- Summary: [TC Bot] Optimize backround JIRA tickets sync Key: IGNITE-10942 URL: https://issues.apache.org/jira/browse/IGNITE-10942 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov JIRA sync is now performed in not an efficient manner. All project data is reloaded every 15 minutes, and this may create additional pressure for 3rd party services. Introduce incremental updates (update is running only until the first non-modified element found) and full updates. Check ticket data modification before saving into Ignite DB (will safe WAL & page store pressure). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10688) Expose SQL views for IO statistics
[ https://issues.apache.org/jira/browse/IGNITE-10688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-10688: -- Assignee: Yury Gerzhedovich > Expose SQL views for IO statistics > -- > > Key: IGNITE-10688 > URL: https://issues.apache.org/jira/browse/IGNITE-10688 > Project: Ignite > Issue Type: Task > Components: persistence, sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-27 > Fix For: 2.8 > > > As of now no such way to get IO statistics through SQL. > Need to expose SQL views to be able view statistics for indexes and cache > group caches. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9470:
---
Description:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
In some tests we have to repeat tx operation in case of version conflict. Most
likely, we can rely to caused-exception with some meaningful type (e.g.
MvccVersionMismatchException) to repeat operation.
Pay attention that tx could be aborted at different stages, but we should fail
consistently. Some examples:
1. Before next operation in tx started.
2. While operation in tx is in progress.
3. When {{tx.commit()}} is called.
was:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
In some tests we have to repeat tx operation in case of version conflict. Most
likely, we can rely to caused-exception with some meaningful type (e.g.
MvccVersionMismatchException) to repeat operation.
Pay attention that tx could be aborted at different stages, but we should fail
consistently. Some examples:
1. Before next operation in tx started.
2. While operation in tx is in progress.
3. When `tx.commit()` is called.
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
> Pay attention that tx could be aborted at different stages, but we should
> fail consistently. Some examples:
> 1. Before next operation in tx started.
> 2. While operation in tx is in progress.
> 3. When {{tx.commit()}} is called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10754) Query history statistics API
[ https://issues.apache.org/jira/browse/IGNITE-10754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743027#comment-16743027 ] Yury Gerzhedovich commented on IGNITE-10754: [~vozerov], Vladimir, all mentioned things were fixed. Could you please confirm Configuration part to change .Net part accordingly - the reason we have failed tests for .Net. > Query history statistics API > > > Key: IGNITE-10754 > URL: https://issues.apache.org/jira/browse/IGNITE-10754 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: iep-29, monitoring > Time Spent: 40m > Remaining Estimate: 0h > > As of now we have query statistics > (*_org.apache.ignite.IgniteCache#queryMetrics_*) , but have few issues. > 1) Duration execution it just time between start execution and return cursor > to client and doesn't include all life time of query. > 2) It doesn't know about multistatement queries. Such queries participate in > statistics as single query without splitting. > 3) API to access the statistics expose as depend on cache, however query > don't have such dependency. > > Need to create parallel similar realization as we already have. > Use new infrastructure of tracking running queries developed under > IGNITE-10621 and update statistics on unregister phase. > Expose API on upper level then it placed now. Right place will be written > later. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743004#comment-16743004
]
Taras Ledkov edited comment on IGNITE-10824 at 1/15/19 12:33 PM:
-
[~pkouznet],
1. please pay attention to concurrent access to the {{GridH2RowDescriptor}} and
the columns {{HashMap}} at the H2 table.
Does acquire the shared lock on the table makes sense inside the
{{verifyDmlColumns}}?
2. COPY command doesn't work with native SQL. But the test
{{IgniteCacheSqlDmlErrorSelfTest#testCopyMixingPlaceholderAndFields}} check
only plan builder. So you can remove the code to fill CSV file
{{IgniteCacheSqlDmlErrorSelfTest#createTmpCsvFileWithContent}} and use any file
name.
was (Author: tledkov-gridgain):
[~pkouznet], please pay attention to concurrent access to the
{{GridH2RowDescriptor}} and the columns {{HashMap}} at the H2 table.
Does acquire the shared lock on the table makes sense inside the
{{verifyDmlColumns}}?
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9470) MVCC TX: Mvcc transactions should throw proper exception when rolled back.
[
https://issues.apache.org/jira/browse/IGNITE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9470:
---
Description:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
In some tests we have to repeat tx operation in case of version conflict. Most
likely, we can rely to caused-exception with some meaningful type (e.g.
MvccVersionMismatchException) to repeat operation.
Pay attention that tx could be aborted at different stages, but we should fail
consistently. Some examples:
1. Before next operation in tx started.
2. While operation in tx is in progress.
3. When `tx.commit()` is called.
was:
When MVCC transaction is rolled back due to a write conflict it throws
{{CacheException}} with "Mvcc version mismatch" message. This behavior violates
Ignite transactions API. Instead it should throw
{{TransactionRollbackException}} with a clear message like a "Transaction has
been aborted due to a write conflict (Please try again.)"
It is also need to propogate this changes to JDBC and ODBC components and fix
mvcc tests.
In some tests we have to repeat tx operation in case of version conflict. Most
likely, we can rely to caused-exception with some meaningful type (e.g.
MvccVersionMismatchException) to repeat operation.
> MVCC TX: Mvcc transactions should throw proper exception when rolled back.
> --
>
> Key: IGNITE-9470
> URL: https://issues.apache.org/jira/browse/IGNITE-9470
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, mvcc, odbc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: Muted_test, mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> When MVCC transaction is rolled back due to a write conflict it throws
> {{CacheException}} with "Mvcc version mismatch" message. This behavior
> violates Ignite transactions API. Instead it should throw
> {{TransactionRollbackException}} with a clear message like a "Transaction has
> been aborted due to a write conflict (Please try again.)"
> It is also need to propogate this changes to JDBC and ODBC components and fix
> mvcc tests.
>
> In some tests we have to repeat tx operation in case of version conflict.
> Most likely, we can rely to caused-exception with some meaningful type (e.g.
> MvccVersionMismatchException) to repeat operation.
> Pay attention that tx could be aborted at different stages, but we should
> fail consistently. Some examples:
> 1. Before next operation in tx started.
> 2. While operation in tx is in progress.
> 3. When `tx.commit()` is called.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10917) IgniteCacheQueryNodeRestartSelfTest2.testRestarts stable failure
[
https://issues.apache.org/jira/browse/IGNITE-10917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-10917:
Labels: MakeTeamcityGreenAgain Muted_test (was: MakeTeamcityGreenAgain)
> IgniteCacheQueryNodeRestartSelfTest2.testRestarts stable failure
>
>
> Key: IGNITE-10917
> URL: https://issues.apache.org/jira/browse/IGNITE-10917
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Ivan Pavlukhin
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> {{IgniteCacheQueryNodeRestartSelfTest2.testRestarts}} fails on master. It was
> broken by extending exception details when query fails by linked ticked.
> Messages were changed but test expects old ones. You can find test statistics
> on TC
> https://ci.ignite.apache.org/viewLog.html?buildId=2789190=buildResultsDiv=IgniteTests24Java8_Queries2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10784) SQL: Create a view with list of existing tables
[
https://issues.apache.org/jira/browse/IGNITE-10784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743015#comment-16743015
]
Pavel Kuznetsov commented on IGNITE-10784:
--
About p.1 : In short, I've removed locking.
Revisited the code.
- Added locking inside getTables() is not correct, because this method is used
by H2, which might have already locked the table.
- Locking while reading Table#columns was required (select to a View doesn't
lock all the tables). BUT, Iteration over columns is removed, and in the view
we read only final or effectively final fields.
> SQL: Create a view with list of existing tables
> ---
>
> Key: IGNITE-10784
> URL: https://issues.apache.org/jira/browse/IGNITE-10784
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> We need to create a system view of currently available SQL tables.
> Minimal required information:
> 1) Schema name
> 2) Table name
> 3) Owning cache name
> 4) Owning cache ID
> Other info to consider:
> 1) Affinity column name
> 2) Key/value aliases
> 3) Key/value type names
> 4) Analyse other vendors (e.g. MySQL, Postgresql) and see if any other useful
> information could be exposed (taking in count that a lot of engine properties
> are already exposed through {{CACHES}} view)
> Starting point: {{SqlSystemView}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5438) JDBC thin: support query timeout
[
https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743011#comment-16743011
]
Alexander Lapin commented on IGNITE-5438:
-
[~vozerov] All fixed, visa recaptured.
> JDBC thin: support query timeout
>
>
> Key: IGNITE-5438
> URL: https://issues.apache.org/jira/browse/IGNITE-5438
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Alexander Lapin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5438) JDBC thin: support query timeout
[
https://issues.apache.org/jira/browse/IGNITE-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743005#comment-16743005
]
Ignite TC Bot commented on IGNITE-5438:
---
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2796738buildTypeId=IgniteTests24Java8_RunAll]
> JDBC thin: support query timeout
>
>
> Key: IGNITE-5438
> URL: https://issues.apache.org/jira/browse/IGNITE-5438
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Alexander Lapin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{setQueryTimeout}} method of JDBC {{Statement}} must be supported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10824) SQL: mixing _key and key columns in the DML queries must be disallowed
[
https://issues.apache.org/jira/browse/IGNITE-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16743004#comment-16743004
]
Taras Ledkov commented on IGNITE-10824:
---
[~pkouznet], please pay attention to concurrent access to the
{{GridH2RowDescriptor}} and the columns {{HashMap}} at the H2 table.
Does acquire the shared lock on the table makes sense inside the
{{verifyDmlColumns}}?
> SQL: mixing _key and key columns in the DML queries must be disallowed
> --
>
> Key: IGNITE-10824
> URL: https://issues.apache.org/jira/browse/IGNITE-10824
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DML should contain either placeholder for _key (_val) or subset of key
> (value) columns but not both. Also we should keep in mind _key/_value aliases
> Given table with primary key column {{id}} and value column {{salary}}. Next
> queries should be validated to parsing error:
> {code:sql}
> INSERT INTO TEST_TABLE (_key, id, salary) VALUES (1, 2, 42);
> UPDATE TEST_TABLE SET _val = 1, salary = 2;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10941) Ignite won't build with Java 11
Andrey Kalinin created IGNITE-10941:
---
Summary: Ignite won't build with Java 11
Key: IGNITE-10941
URL: https://issues.apache.org/jira/browse/IGNITE-10941
Project: Ignite
Issue Type: Bug
Environment: ~$ /usr/lib/jvm/java-11-oracle/bin/java -version
java version "11.0.1" 2018-10-16 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.1+13-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.1+13-LTS, mixed mode)
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
Reporter: Andrey Kalinin
*sun.misc*, *sun.nio.ch*, *com.sun.jmx.mbeanserver* is no longer supported in
Java 11. This makes it impossible to build Apache Ignite for this version.
When I run the build from the IDE, I get the following error messages (Warnings
removed):
{code:java}
Information:java: Errors occurred while compiling module 'ignite-core'
Information:javac 11.0.1 was used to compile java sources
Information:15.01.19 14:07 - Compilation completed with 33 errors and 100
warnings in 33 s 148 ms
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java
Error:(258, 16) java: package sun.misc does not exist
Error:(8743, 29) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.IgniteUtils
Error:(8743, 49) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.IgniteUtils
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/util/GridUnsafe.java
Error:(32, 16) java: package sun.misc does not exist
Error:(60, 26) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1389, 20) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1391, 20) java: cannot find symbol
symbol: variable Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1396, 52) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.util.GridUnsafe
Error:(1397, 42) java: cannot find symbol
symbol: class Unsafe
Error:(1398, 39) java: cannot find symbol
symbol: class Unsafe
Error:(1402, 37) java: cannot find symbol
symbol: class Unsafe
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/binary/BinaryMarshaller.java
Error:(31, 16) java: package sun.misc does not exist
Error:(56, 29) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.binary.BinaryMarshaller
Error:(56, 49) java: cannot find symbol
symbol: class Unsafe
location: class org.apache.ignite.internal.binary.BinaryMarshaller
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/marshaller/optimized/OptimizedMarshaller.java
Error:(34, 16) java: package sun.misc does not exist
Error:(285, 29) java: cannot find symbol
symbol: class Unsafe
location: class
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller
Error:(285, 49) java: cannot find symbol
symbol: class Unsafe
location: class
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/jsr166/ConcurrentLinkedDeque8.java
Error:(30, 16) java: package sun.misc does not exist
Error:(327, 38) java: package sun.misc does not exist
Error:(1693, 34) java: package sun.misc does not exist
Error:(1716, 12) java: cannot find symbol
symbol: class Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1718, 20) java: cannot find symbol
symbol: variable Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1723, 52) java: cannot find symbol
symbol: class Unsafe
location: class org.jsr166.ConcurrentLinkedDeque8
Error:(1725, 32) java: cannot find symbol
symbol: class Unsafe
Error:(1726, 39) java: cannot find symbol
symbol: class Unsafe
Error:(1730, 37) java: cannot find symbol
symbol: class Unsafe
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/mem/file/MappedFile.java
Error:(29, 18) java: package sun.nio.ch does not exist
Error:(33, 62) java: cannot find symbol
symbol: class FileChannelImpl
location: class org.apache.ignite.internal.mem.file.MappedFile
Error:(36, 64) java: cannot find symbol
symbol: class FileChannelImpl
location: class org.apache.ignite.internal.mem.file.MappedFile
---
/home/kalinin/git/incubator-ignite/modules/core/src/main/java/org/apache/ignite/internal/tck/TCKMBeanServerBuilder.java
Error:(20, 31) java: package com.sun.jmx.mbeanserver does not exist
Error:(37, 16) java: cannot find symbol
symbol: variable JmxMBeanServer
location: class
[jira] [Updated] (IGNITE-10178) change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA ticket URL")
[
https://issues.apache.org/jira/browse/IGNITE-10178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10178:
Fix Version/s: 2.8
> change tests that fail("Ignite JIRA ticket URL") to @Ignore("Ignite JIRA
> ticket URL")
> -
>
> Key: IGNITE-10178
> URL: https://issues.apache.org/jira/browse/IGNITE-10178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Change tests that use {{fail("Ignite JIRA ticket URL")}} to {{@Ignore("Ignite
> JIRA ticket URL")}}. Do the same change for tests that fail by
> {{@IgniteIgnore("Ignite JIRA ticket URL")}}, like for example
> [S3CheckpointSpiStartStopSelfTest.testStartStop|https://github.com/apache/ignite/blob/master/modules/aws/src/test/java/org/apache/ignite/spi/checkpoint/s3/S3CheckpointSpiStartStopSelfTest.java].
> Also, use
> [Ignore|http://junit.sourceforge.net/javadoc/org/junit/Ignore.html] to
> annotate empty test classes in examples that were discovered and re-muted per
> IGNITE-10174.
> If needed, refer parent task for more details.
> Note this step would better be coordinated with Teamcity and TC bot
> maintainers because it may substantially impact them.
> -
> Note that tests that are expected to be ignored depending on runtime
> conditions should be rewritten to use {{Assume}} instead of {{fail}}. So that
> old code...
> {code}if (someRuntimeCondition())
> fail("Ignite JIRA ticket URL");{code}
> ...will change to
> {code}Assume.assumeFalse("Ignite JIRA ticket URL",
> someRuntimeCondition());{code}
> (this change can be "extracted" into separate JIRA task if it is more
> convenient). Readers interested to find more details about how {{Assume}}
> works can find more details and code snippet [in comments
> here|https://issues.apache.org/jira/browse/IGNITE-10178?focusedCommentId=16723863=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16723863].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10776) Migrate from JUnit 3 to 4 config variations test suites
[
https://issues.apache.org/jira/browse/IGNITE-10776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10776:
Fix Version/s: 2.8
> Migrate from JUnit 3 to 4 config variations test suites
> ---
>
> Key: IGNITE-10776
> URL: https://issues.apache.org/jira/browse/IGNITE-10776
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate config variations test suites from JUnit 3 to 4.
> If needed, refer parent task comments for more details.
> Note this might be somewhat tough nut to crack design wise since
> {{JUnit4TestAdapter}} plays a special role in config variations tests, see
> IGNITE-10739.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10796) Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
[
https://issues.apache.org/jira/browse/IGNITE-10796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ignatenko updated IGNITE-10796:
Fix Version/s: 2.8
> Migrate from JUnit 3 to 4 suites involving IgniteTestSuite
> --
>
> Key: IGNITE-10796
> URL: https://issues.apache.org/jira/browse/IGNITE-10796
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to migrate from JUnit 3 to 4 test suites suites involving
> {{IgniteTestSuite}} API that was introduced per IGNITE-3658.
> If needed, refer parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[ https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10777: Fix Version/s: 2.8 > Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test > suites > --- > > Key: IGNITE-10777 > URL: https://issues.apache.org/jira/browse/IGNITE-10777 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 2.8 >Reporter: Oleg Ignatenko >Assignee: Oleg Ignatenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API > involving test suites that may be missed in prior sub-tasks under the parent > task. > If needed, refer to parent task comments for more details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10777) Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test suites
[
https://issues.apache.org/jira/browse/IGNITE-10777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742987#comment-16742987
]
Ignite TC Bot commented on IGNITE-10777:
{panel:title=-- Run :: All (Nightly): No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All (Nightly)*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2790696buildTypeId=IgniteTests24Java8_RunAllNightly]
> Cleanup remainders of JUnit4TestAdapter and other JUnit 3 API involving test
> suites
> ---
>
> Key: IGNITE-10777
> URL: https://issues.apache.org/jira/browse/IGNITE-10777
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This task is to cleanup remainders of JUnit4TestAdapter and other JUnit 3 API
> involving test suites that may be missed in prior sub-tasks under the parent
> task.
> If needed, refer to parent task comments for more details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10938) After restart cluster with non-blt nodes - they left by handler
[ https://issues.apache.org/jira/browse/IGNITE-10938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742952#comment-16742952 ] Sergey Kosarev commented on IGNITE-10938: - duplicates https://issues.apache.org/jira/browse/IGNITE-9739 > After restart cluster with non-blt nodes - they left by handler > --- > > Key: IGNITE-10938 > URL: https://issues.apache.org/jira/browse/IGNITE-10938 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.8 >Reporter: ARomantsov >Priority: Critical > Fix For: 2.8 > > > I have cluster wherein topology contain blt and non-blt nodes, but after > restart - nodes left by handler > java.lang.IllegalStateException: Unable to find consistentId by UUID -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742942#comment-16742942
]
Peter Ivanov commented on IGNITE-10940:
---
No objections from my side. Seems valid proposition.
One question only -- will {{libtoolize && aclocal && autoheader && automake
--add-missing && autoreconf}} be platform dependant or not?
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Priority: Major
> Labels: c++
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
Ilya Kasnacheev created IGNITE-10940:
Summary: Supply pre-built ./configure with Apache Ignite releases
Key: IGNITE-10940
URL: https://issues.apache.org/jira/browse/IGNITE-10940
Project: Ignite
Issue Type: Improvement
Components: build
Reporter: Ilya Kasnacheev
Right now we have the following build steps for C++ in docs:
{code}
cd modules/platforms/cpp
libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
./configure
make
sudo make install
{code}
However, it is customary for C++ projects to ship release tarballs with first
step already done. ./configure should be pre-built and libtoolize, etc, are
already ran since you should not force user to install them, and the process of
their application is deterministic.
I suggest we add libtoolize && etc step to release builds so that user's first
step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10940) Supply pre-built ./configure with Apache Ignite releases
[
https://issues.apache.org/jira/browse/IGNITE-10940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742939#comment-16742939
]
Ilya Kasnacheev commented on IGNITE-10940:
--
[~isapego] [~vveider] WDYT?
> Supply pre-built ./configure with Apache Ignite releases
>
>
> Key: IGNITE-10940
> URL: https://issues.apache.org/jira/browse/IGNITE-10940
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Priority: Major
> Labels: c++
>
> Right now we have the following build steps for C++ in docs:
> {code}
> cd modules/platforms/cpp
> libtoolize && aclocal && autoheader && automake --add-missing && autoreconf
> ./configure
> make
> sudo make install
> {code}
> However, it is customary for C++ projects to ship release tarballs with first
> step already done. ./configure should be pre-built and libtoolize, etc, are
> already ran since you should not force user to install them, and the process
> of their application is deterministic.
> I suggest we add libtoolize && etc step to release builds so that user's
> first step will be ./configure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10890) Web console: UIRouter cleanup
[ https://issues.apache.org/jira/browse/IGNITE-10890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin updated IGNITE-10890: --- Labels: architecture ui wizard (was: ui wizard) Remaining Estimate: 6h Original Estimate: 6h > Web console: UIRouter cleanup > - > > Key: IGNITE-10890 > URL: https://issues.apache.org/jira/browse/IGNITE-10890 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Labels: architecture, ui, wizard > Original Estimate: 6h > Remaining Estimate: 6h > > 1. Do not depend on _@uirouter/angularjs/lib/legacy/stateEvents_, replace all > legacy $scope events with transition-based API. > 2. Remove _@uirouter/visualizer_, which is only used for development. > The goal is to decrease bundle size and drop legacy APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742917#comment-16742917 ] Mikhail Cherkasov edited comment on IGNITE-10886 at 1/15/19 9:58 AM: - [~ilyak] without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] was (Author: mcherkasov): without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-10885) Yardstick scripts refer to nonexistent OffHeap benchmarks
[
https://issues.apache.org/jira/browse/IGNITE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ostanin closed IGNITE-10885.
-
> Yardstick scripts refer to nonexistent OffHeap benchmarks
> -
>
> Key: IGNITE-10885
> URL: https://issues.apache.org/jira/browse/IGNITE-10885
> Project: Ignite
> Issue Type: Bug
> Components: yardstick
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Oleg Ostanin
>Priority: Minor
> Fix For: 2.8
>
>
> {code}
> IgnitePutTxOffHeapValuesBenchmark
> IgnitePutTxOffHeapBenchmark
> IgniteSqlQueryJoinOffHeapBenchmark
> IgnitePutOffHeapBenchmark
> IgnitePutOffHeapValuesBenchmark
> IgnitePutGetOffHeapValuesBenchmark
> IgniteSqlQueryOffHeapBenchmark
> {code}
> I expect we don't have those since 2.0, yet:
> {code}
> ~/w/incubator-ignite% grep -ri IgnitePutTxOffHeapValuesBenchmark *
> modules/yardstick/target/assembly/config/benchmark-remote.properties:-cfg
> ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w
> ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutTxOffHeapValuesBenchmark -sn
> IgniteNode -ds ${ver}tx-put-offheap-val-${b}-backup,\
> modules/yardstick/config/benchmark-remote.properties:-cfg
> ${SCRIPT_DIR}/../config/ignite-remote-config.xml -nn ${nodesNum} -b ${b} -w
> ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutTxOffHeapValuesBenchmark -sn
> IgniteNode -ds ${ver}tx-put-offheap-val-${b}-backup,\
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16742917#comment-16742917 ] Mikhail Cherkasov commented on IGNITE-10886: without fix: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev with fix: Mikhails-MBP:apache-ignite-2.7.0-bin mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Ignite Command Line Startup, ver. 2.7.0#20181130-sha1:256ae401 ... [19:17:31,306][INFO][main][IgniteKernal] IGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin [19:17:31,306][INFO][main][IgniteKernal] VM arguments: [-XX:+AggressiveOpts, -Xms1g, -Xmx1g, -XX:MaxMetaspaceSize=256m, -DIGNITE_QUIET=false, -DIGNITE_SUCCESS_FILE=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin/work/ignite_success_80a26259-9b3f-4f81-aee2-56a558bda5f7, -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.port=49184, -Dcom.sun.management.jmxremote.authenticate=false, -Dcom.sun.management.jmxremote.ssl=false, -DIGNITE_HOME=/Users/mcherkasov/Downloads/apache-ignite-2.7.0-bin, -DIGNITE_PROG_NAME=bin/ignite.sh, -Xmx3G, -Xms3G, -DIGNITE_CLUSTER_NAME=dev dev dev] > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10886) -J-PARAMS does not allow spaces in arguments
[ https://issues.apache.org/jira/browse/IGNITE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Cherkasov updated IGNITE-10886: --- Description: -J-PARAMS doesn't allow spaces, so you can not pass for example: -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. it will fail with the following message: mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G -J-DIGNITE_CLUSTER_NAME="dev dev dev" Error: Could not find or load main class dev was: JVM_OPTS and -J-PARAMS doesn't allow spaces, so you can pass for example: -DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > -J-PARAMS does not allow spaces in arguments > > > Key: IGNITE-10886 > URL: https://issues.apache.org/jira/browse/IGNITE-10886 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > -J-PARAMS doesn't allow spaces, so you can not pass for example: > -J-DIGNITE_CLUSTER_NAME="dev dev dev" and set name for you cluster in WC. > it will fail with the following message: > mcherkasov$ bash bin/ignite.sh -v -J-Xmx3G -J-Xms3G > -J-DIGNITE_CLUSTER_NAME="dev dev dev" > Error: Could not find or load main class dev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
