[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472900#comment-16472900
 ] 

Ryabov Dmitrii commented on IGNITE-8456:


[~ivan.glukos], I made changes you suggested. Can you look again?

[~dpavlov], [PDS 
tests|https://ci.ignite.apache.org/viewLog.html?buildId=1285092=buildResultsDiv=IgniteTests24Java8_RunAllPds]
 are finished.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL

[Amir Akhmedov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472897#comment-16472897
 ] 

Amir Akhmedov commented on IGNITE-3999:
---

[~dpavlov], [~vozerov], [~vkulichenko]

I would be more than happy to contribute a function indexes but I will need 
some guidance on it.

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is possible only with the help of 
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add 
> a respective property to {{@QuerySqlField}} annotation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL

[Valentin Kulichenko (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472819#comment-16472819
 ] 

Valentin Kulichenko commented on IGNITE-3999:
-

[~dpavlov], [~vozerov], [~aakhmedov]

Guys, I'm not going to judge whether the solution proposed here is the best one 
or not - Vladimir knows better. However, I do know that this functionality is 
highly demanded - there were multiple requests from our users. Having said 
that, I'm OK with closing this ticket as long as we have an alternative. 
Personally, I really like the idea of supporting function indexes. They would 
cover case-insensitive search, as well as many other use cases.

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is possible only with the help of 
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add 
> a respective property to {{@QuerySqlField}} annotation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov closed IGNITE-7940.
--

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471628#comment-16471628
 ] 

Pavel Konstantinov commented on IGNITE-7940:


Tested on 2.5

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8467) minSize filter for transactions utility control.sh doesn't work

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8467:
---
Fix Version/s: 2.6

> minSize filter for transactions utility control.sh doesn't work
> ---
>
> Key: IGNITE-8467
> URL: https://issues.apache.org/jira/browse/IGNITE-8467
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Minor
> Fix For: 2.6
>
>
> I have following output when define control.sh utility with minSize filter
> Looks like it doesn't work.
> {code:java}
> Control utility --tx minDuration 15 minSize 10 order SIZE
> Control utility 
> 2018 Copyright(C) Apache Software Foundation
> User: 
> 
> Matching transactions:
> [16:52:30][:688] TcpDiscoveryNode [id=02f47e9a-efca-4d8c-a49f-3de4ca82d3ee, 
> 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:0, /0:0:0:0:0:0:0:1%lo:0, 
> lab40.gridgain.local/172.25.1.40:0, /127.0.0.1:0], discPort=0, order=5, 
> intOrder=5, lastExchangeTime=1525960350163, loc=false, 
> ver=2.5.1#20180427-sha1:48601cbd, isClient=true]
>  Tx: [xid=0f1d25a4361--0831-2c15--0005, label=tx_5, 
> state=ACTIVE, duration=16, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
>  Tx: [xid=05ad25a4361--0831-2c15--0005, label=tx_6, 
> state=ACTIVE, duration=15, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
>  Tx: [xid=7b2b25a4361--0831-2c15--0005, label=tx_1, 
> state=ACTIVE, duration=20, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
>  Tx: [xid=73ab25a4361--0831-2c15--0005, label=tx_2, 
> state=ACTIVE, duration=19, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
>  Tx: [xid=47ca25a4361--0831-2c15--0005, label=tx_0, 
> state=ACTIVE, duration=22, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[63e05a51]]
>  Tx: [xid=b0ac25a4361--0831-2c15--0005, label=tx_4, 
> state=ACTIVE, duration=17, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[473df74e]]
>  Tx: [xid=3a1c25a4361--0831-2c15--0005, label=tx_3, 
> state=ACTIVE, duration=18, isolation=REPEATABLE_READ, 
> concurrency=PESSIMISTIC, timeout=0, size=1, dhtNodes=[0cd15184]]{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs

[Pavel Konstantinov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Konstantinov closed IGNITE-7119.
--

> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs

[Pavel Konstantinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471539#comment-16471539
 ] 

Pavel Konstantinov commented on IGNITE-7119:


Tested on 2.5

> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8370) Web console: split page-signin into three separate pages

[Ilya Borisov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471684#comment-16471684
 ] 

Ilya Borisov commented on IGNITE-8370:
--

[~vabramova] current implementation (same as on confoguration pages) can't 
ensure that the focus will be placed on the first invalid element, but it does 
this most of the time.

> Web console: split page-signin into three separate pages
> 
>
> Key: IGNITE-8370
> URL: https://issues.apache.org/jira/browse/IGNITE-8370
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, the page-signin component solves three separate cases: user 
> registration, sign in and password restore. Since none of those features has 
> to be on the same page, let's split those to separate pages.
> What to do:
> 1. Split signup, signin and forgot password features to separate components 
> and pages.
> 2. While at it, add an optional "Phone" input to signup page in order to 
> match inputs available on user profile page.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2

[Alexander Menshikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470817#comment-16470817
 ] 

Alexander Menshikov edited comment on IGNITE-5945 at 5/11/18 9:28 AM:
--

I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
 So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

*UPD:*

460 passes locally


was (Author: sharpler):
I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
 So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

UPD:

460 passes locally

> Flaky failure in IgniteCache 5: 
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2

[Alexander Menshikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470817#comment-16470817
 ] 

Alexander Menshikov edited comment on IGNITE-5945 at 5/11/18 9:28 AM:
--

I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
 So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

UPD:

460 passes locally


was (Author: sharpler):
I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

> Flaky failure in IgniteCache 5: 
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8470) NPE when starting LOCAL cache on a client with no data regions

[Stanislav Lukyanov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Lukyanov updated IGNITE-8470:
---
Description: 
If a LOCAL cache is started on a client and the client has no data regions 
configured then an NPE is thrown with no error message:

{code}
class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7284)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:829)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:798)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapIndexScanTest.beforeTestsStarted(IgniteCacheOffheapIndexScanTest.java:78)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:599)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:485)
at junit.framework.TestCase.runBare(TestCase.java:139)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:207)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1983)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1881)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1773)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}

If assertions are enabled (-ea), an AssertionError is thrown instead:
{code}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:185)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1983)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1881)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1773)
at 

[jira] [Assigned] (IGNITE-8464) WALIterator broken (race on the switch to the next segment during iteration and concurrent archiving same segment)

[Anton Kalashnikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anton Kalashnikov reassigned IGNITE-8464:
-

Assignee: Anton Kalashnikov

> WALIterator broken (race on the switch to the next segment during iteration 
> and concurrent archiving same segment)
> --
>
> Key: IGNITE-8464
> URL: https://issues.apache.org/jira/browse/IGNITE-8464
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.6
>
>
> FileArchiver
> {code}
> final SegmentArchiveResult res = archiveSegment(toArchive);
> synchronized (this) {
>  while (locked.containsKey(toArchive) && !stopped)
>  wait();
> }
> // Firstly, format working file
> if (!stopped)
>  formatFile(res.getOrigWorkFile());
> synchronized (this) {
>  // Then increase counter to allow rollover on clean working file
>  changeLastArchivedIndexAndNotifyWaiters(toArchive);
>  notifyAll();
> }
> {code}
> Some thread may try read segments when archive formating file in work dir 
> (formatFile not synchronized), last archived index is still not updated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7585) GridDhtLockFuture related memory leak

[Alexei Scherbakov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Scherbakov resolved IGNITE-7585.
---
Resolution: Fixed

Fixed as part of IGNITE-6827

> GridDhtLockFuture related memory leak
> -
>
> Key: IGNITE-7585
> URL: https://issues.apache.org/jira/browse/IGNITE-7585
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.6
>
> Attachments: memleak.jpg
>
>
> GridDhtLockFuture related LockTimeoutObject is not removed on commit, 
> resulting in tx reference until timeout handler is triggered.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471825#comment-16471825
 ] 

Ivan Fedotov edited comment on IGNITE-8085 at 5/11/18 12:22 PM:


[~dpavlov], also I found the similar ticket IGNITE-5883: build logs weren't 
kept, but I looked at recent history of this tests and found that causes of 
fails are also relates with "Remote node could not start. " exception. I 
suppose that IGNITE-5883 could be closed after this would be merged. What do 
you think?


was (Author: ivanan.fed):
[~dpavlov], also I found the similar ticket IGNITE-5883: build logs weren't 
kept, but I looked at recent history of this tests and found that causes of 
fails are also relates with "Remote node could not start. " exception. I 
suppose that IGNITE-5883 could be closed after this would be merged. What do 
you think

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471825#comment-16471825
 ] 

Ivan Fedotov edited comment on IGNITE-8085 at 5/11/18 12:22 PM:


[~dpavlov], also I found similar ticket IGNITE-5883: build logs weren't kept, 
but I looked at recent history of this tests and found that causes of fails are 
also relates with "Remote node could not start. " exception. I suppose that 
IGNITE-5883 could be closed after this would be merged. What do you think


was (Author: ivanan.fed):
[~dpavlov], also I found similar ticket [1]: build logs weren't kept, but I 
looked at recent history of this tests and found that causes of fails are also 
relates with "Remote node could not start. " exception. I suppose that 
IGNITE-5883 could be closed after this would be merged. What do you think?

[1]https://issues.apache.org/jira/browse/IGNITE-5883

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471825#comment-16471825
 ] 

Ivan Fedotov edited comment on IGNITE-8085 at 5/11/18 12:22 PM:


[~dpavlov], also I found the similar ticket IGNITE-5883: build logs weren't 
kept, but I looked at recent history of this tests and found that causes of 
fails are also relates with "Remote node could not start. " exception. I 
suppose that IGNITE-5883 could be closed after this would be merged. What do 
you think


was (Author: ivanan.fed):
[~dpavlov], also I found similar ticket IGNITE-5883: build logs weren't kept, 
but I looked at recent history of this tests and found that causes of fails are 
also relates with "Remote node could not start. " exception. I suppose that 
IGNITE-5883 could be closed after this would be merged. What do you think

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471752#comment-16471752
 ] 

Ivan Fedotov commented on IGNITE-8085:
--

[~dpavlov], I researched this issue and it seems similar problem. I ran this 
test locally 600 times and it's done. I think, I can assign this ticket on me.

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-172) [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and IgniteTcpCommunicationRecoveryAckClosureSelfTest

[Amelchev Nikita (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471761#comment-16471761
 ] 

Amelchev Nikita edited comment on IGNITE-172 at 5/11/18 11:28 AM:
--

*1. GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow*

It test is OK. [Test 
history.|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7087354412440633390=testDetails]]
 It has 1 fail where most of spi tests were broken.

*2. GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes*

It test is good too. [Test 
history.|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1831896094370683279=testDetails]]

*3. IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow*
It test is not ok and I prepare PR that fixed it.

The test was failed because of ack closure don't apply by idle timeout (Timeout 
in the test is 5s, but idle timeout is 60s). I have decreased idle timeout to 
2s.

Test sends 251 messages and by ackThreshold(5) it doesn't apply too. I 
increased the count of messages as it done in 
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow() for guarantee 
queue overflow. But I set it to 1279, that count of all sent messages will in 
proportion to ackThreshold for test completion by ackThreshold. If test throws 
an exception on sending a message it will be checked applying closure by idle 
timeout.

I run it [1000 times on 
TC|https://ci.ignite.apache.org/viewLog.html?buildId=1283301=IgniteTests24Java8_Spi=testsInfo]
 and it OK.


was (Author: nsamelchev):
The test was failed because of ack closure don't apply by idle timeout (Timeout 
in the test is 5s, but idle timeout is 60s). I have decreased idle timeout to 
2s.

Test sends 251 messages and by ackThreshold(5) it doesn't apply too. I 
increased the count of messages as it done in 
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow() for guarantee 
queue overflow. But I set it to 1279, that count of all sent messages will in 
proportion to ackThreshold for test completion by ackThreshold. If test throws 
an exception on sending a message it will be checked applying closure by idle 
timeout.

I run it [1000 times on 
TC|https://ci.ignite.apache.org/viewLog.html?buildId=1283301=IgniteTests24Java8_Spi=testsInfo]
 and it OK.

> [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and 
> IgniteTcpCommunicationRecoveryAckClosureSelfTest
> -
>
> Key: IGNITE-172
> URL: https://issues.apache.org/jira/browse/IGNITE-172
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Irina Vasilinets
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow and 
> GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes 
>  fail sometimes.
> IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 1 from 10



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471774#comment-16471774
 ] 

Ivan Fedotov edited comment on IGNITE-8085 at 5/11/18 11:41 AM:


Also I want to clarify what was done in this ticket.

Start remote node via ssh has next logic: in StartNodeCallableImpl script [1] 
to start node and session for this [2] are formed. If info about successful 
start node was found in logs, ClusterStartNodeResultImpl.isSuccess() returns 
true, otherwise IgniteException "Remote node could not start. " will be thrown 
[3].

I suppose that tests failed due to there is not enough time to check logs and 
although remote node was started, exception is thrown and tests fail. I 
increase time and iterations for check and tests became green, locally (600 
times) and on TC(100 times). I think this fact confirmed my assumption. 

 

[1][https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L207]

[2][https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L136]

[3][https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285]


was (Author: ivanan.fed):
Also I want to clarify what was done in this ticket.

Start remote node via ssh has next logic: in StartNodeCallableImpl script [1] 
to start node and session for this [2] are formed. If info about successful 
start node was found in logs, ClusterStartNodeResultImpl.isSuccess() returns 
true, otherwise IgniteException "Remote node could not start. " will be thrown 
[3]. 

I suppose that tests failed due to there is not enough time to check logs and 
although remote node was started, exception is thrown and tests fail. I 
increase time and iterations for check and tests became green, locally (600 
times) and on TC(100 times). I think this fact confirmed my assumption. 

 

[1][https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L207]

[2]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L136

[3]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471774#comment-16471774
 ] 

Ivan Fedotov commented on IGNITE-8085:
--

Also I want to clarify what was done in this ticket.

Start remote node via ssh has next logic: in StartNodeCallableImpl script [1] 
to start node and session for this [2] are formed. If info about successful 
start node was found in logs, ClusterStartNodeResultImpl.isSuccess() returns 
true, otherwise IgniteException "Remote node could not start. " will be thrown 
[3]. 

I suppose that tests failed due to there is not enough time to check logs and 
although remote node was started, exception is thrown and tests fail. I 
increase time and iterations for check and tests became green, locally (600 
times) and on TC(100 times). I think this fact confirmed my assumption. 

 

[1][https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L207]

[2]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L136

[3]https://github.com/apache/ignite/blob/master/modules/ssh/src/main/java/org/apache/ignite/internal/util/nodestart/StartNodeCallableImpl.java#L285

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8238) Operation can fails with unexpected RuntimeException when node is stopping.

[Alexander Menshikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Menshikov reassigned IGNITE-8238:
---

Assignee: Alexander Menshikov

> Operation can fails with unexpected RuntimeException when node is stopping.
> ---
>
> Key: IGNITE-8238
> URL: https://issues.apache.org/jira/browse/IGNITE-8238
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
>Priority: Minor
> Fix For: 2.6
>
>
> Operation can fails with RuntimeException when node is stoped in other 
> thread. 
> It is not clear from javadoc that operation can throws RuntimeException.
>  We should add it to javadoc or e.g. throws IllegalStateException which 
> already present in java cache api javadoc.
> Failure in thread: Thread [id=3484, name=updater-2]
> java.lang.RuntimeException: Failed to perform cache update: node is stopping.
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1350)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.purgeExpired(GridCacheOffheapManager.java:1685)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.expire(GridCacheOffheapManager.java:796)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.unwindEvicts(GridCacheUtils.java:834)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leaveNoLock(GridCacheGateway.java:240)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheGateway.leave(GridCacheGateway.java:225)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onLeave(GatewayProtectedCacheProxy.java:1708)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.putAll(GatewayProtectedCacheProxy.java:945)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsContinuousRestartTest$1.call(IgnitePdsContinuousRestartTest.java:261)
>  at org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8470) NPE when starting LOCAL cache on a client with no data regions

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8470:
--

 Summary: NPE when starting LOCAL cache on a client with no data 
regions
 Key: IGNITE-8470
 URL: https://issues.apache.org/jira/browse/IGNITE-8470
 Project: Ignite
  Issue Type: Bug
Reporter: Stanislav Lukyanov


If a LOCAL cache is started on a client and the client has no data regions 
configured then an NPE is thrown with no error message:

{code}
class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7284)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:632)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:829)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1043)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:798)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapIndexScanTest.beforeTestsStarted(IgniteCacheOffheapIndexScanTest.java:78)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:599)
at 
org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:485)
at junit.framework.TestCase.runBare(TestCase.java:139)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at 
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:207)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1983)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1881)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1773)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}

If assertions are enabled (-ea), an AssertionError is thrown instead:
{code}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:185)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1983)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1881)
at 

[jira] [Commented] (IGNITE-8085) Flaky failures in Ignite Client Nodes test suite: Remote node could not start.

[Ivan Fedotov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471825#comment-16471825
 ] 

Ivan Fedotov commented on IGNITE-8085:
--

[~dpavlov], also I found similar ticket [1]: build logs weren't kept, but I 
looked at recent history of this tests and found that causes of fails are also 
relates with "Remote node could not start. " exception. I suppose that 
IGNITE-5883 could be closed after this would be merged. What do you think?

[1]https://issues.apache.org/jira/browse/IGNITE-5883

> Flaky failures in Ignite Client Nodes test suite:  Remote node could not 
> start. 
> 
>
> Key: IGNITE-8085
> URL: https://issues.apache.org/jira/browse/IGNITE-8085
> Project: Ignite
>  Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
>   Ignite Start Nodes 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls (master 
> fail rate 12,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodes (master fail rate 
> 10,1%) 
>   IgniteStartStopRestartTestSuite: 
> IgniteProjectionStartStopRestartSelfTest.testStopNodesByIds (master fail rate 
> 10,1%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6814497542781613621=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1179745277331816127=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-842929918974855010=%3Cdefault%3E=testDetails
> Test itself is quite old. Last commits were from [~tledkov-gridgain] at 2017.
>  {noformat}
> class org.apache.ignite.IgniteException: Remote node could not start. See log 
> for details: 
> /data/teamcity/work/bd85361428dcdb1/work/log/ignite-startNodes/03-29-2018--02-47-24-2003434e.log
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:388)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest$7.apply(IgniteProjectionStartStopRestartSelfTest.java:383)
> at 
> org.apache.ignite.internal.util.lang.GridFunc.forEach(GridFunc.java:1897)
> at 
> org.apache.ignite.internal.IgniteProjectionStartStopRestartSelfTest.testStartFiveNodesInTwoCalls(IgniteProjectionStartStopRestartSelfTest.java:383)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2002)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1917)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-172) [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and IgniteTcpCommunicationRecoveryAckClosureSelfTest

[Amelchev Nikita (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471761#comment-16471761
 ] 

Amelchev Nikita commented on IGNITE-172:


The test was failed because of ack closure don't apply by idle timeout (Timeout 
in the test is 5s, but idle timeout is 60s). I have decreased idle timeout to 
2s.

Test sends 251 messages and by ackThreshold(5) it doesn't apply too. I 
increased the count of messages as it done in 
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow() for guarantee 
queue overflow. But I set it to 1279, that count of all sent messages will in 
proportion to ackThreshold for test completion by ackThreshold. If test throws 
an exception on sending a message it will be checked applying closure by idle 
timeout.

I run it [1000 times on 
TC|https://ci.ignite.apache.org/viewLog.html?buildId=1283301=IgniteTests24Java8_Spi=testsInfo]
 and it OK.

> [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and 
> IgniteTcpCommunicationRecoveryAckClosureSelfTest
> -
>
> Key: IGNITE-172
> URL: https://issues.apache.org/jira/browse/IGNITE-172
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Irina Vasilinets
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow and 
> GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes 
>  fail sometimes.
> IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 1 from 10



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-172) [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and IgniteTcpCommunicationRecoveryAckClosureSelfTest

[Amelchev Nikita (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471761#comment-16471761
 ] 

Amelchev Nikita edited comment on IGNITE-172 at 5/11/18 11:29 AM:
--

*1. GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow*

It test is OK. [Test 
history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7087354412440633390=testDetails]
 It has 1 fail where most of spi tests were broken.

*2. GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes*

It test is good too. [Test 
history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1831896094370683279=testDetails]

*3. IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow*
It test is not ok and I prepare PR that fixed it.

The test was failed because of ack closure don't apply by idle timeout (Timeout 
in the test is 5s, but idle timeout is 60s). I have decreased idle timeout to 
2s.

Test sends 251 messages and by ackThreshold(5) it doesn't apply too. I 
increased the count of messages as it done in 
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow() for guarantee 
queue overflow. But I set it to 1279, that count of all sent messages will in 
proportion to ackThreshold for test completion by ackThreshold. If test throws 
an exception on sending a message it will be checked applying closure by idle 
timeout.

I run it [1000 times on 
TC|https://ci.ignite.apache.org/viewLog.html?buildId=1283301=IgniteTests24Java8_Spi=testsInfo]
 and it OK.


was (Author: nsamelchev):
*1. GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow*

It test is OK. [Test 
history.|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7087354412440633390=testDetails]]
 It has 1 fail where most of spi tests were broken.

*2. GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes*

It test is good too. [Test 
history.|[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1831896094370683279=testDetails]]

*3. IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow*
It test is not ok and I prepare PR that fixed it.

The test was failed because of ack closure don't apply by idle timeout (Timeout 
in the test is 5s, but idle timeout is 60s). I have decreased idle timeout to 
2s.

Test sends 251 messages and by ackThreshold(5) it doesn't apply too. I 
increased the count of messages as it done in 
GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow() for guarantee 
queue overflow. But I set it to 1279, that count of all sent messages will in 
proportion to ackThreshold for test completion by ackThreshold. If test throws 
an exception on sending a message it will be checked applying closure by idle 
timeout.

I run it [1000 times on 
TC|https://ci.ignite.apache.org/viewLog.html?buildId=1283301=IgniteTests24Java8_Spi=testsInfo]
 and it OK.

> [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and 
> IgniteTcpCommunicationRecoveryAckClosureSelfTest
> -
>
> Key: IGNITE-172
> URL: https://issues.apache.org/jira/browse/IGNITE-172
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Irina Vasilinets
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow and 
> GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes 
>  fail sometimes.
> IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 1 from 10



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8375) NPE due to race on cache stop and timeout handler execution.

[Alexander Menshikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465916#comment-16465916
 ] 

Alexander Menshikov edited comment on IGNITE-8375 at 5/11/18 11:46 AM:
---

As I see in this method the *cacheCfg* is ** used twice:
{code:java}
if (!skipStore && (read || cctx.loadPreviousValue()) && cctx.readThrough() && 
(needReturnVal || read)) {
{code}
 # cctx.loadPreviousValue() calls *cacheCfg*.isLoadPreviousValue()
 # cctx.readThrough() calls *cacheCfg*.isReadThrough() && !skipStore()


was (Author: sharpler):
[~ascherbakov] As I see in this method the *cacheCfg* is ** used twice:
{code:java}
if (!skipStore && (read || cctx.loadPreviousValue()) && cctx.readThrough() && 
(needReturnVal || read)) {
{code}
 # cctx.loadPreviousValue() calls *cacheCfg*.isLoadPreviousValue()
 # cctx.readThrough() calls *cacheCfg*.isReadThrough() && !skipStore();

Will it be a valid solution the add *cctx.config() != null && ...* into 
condition?

> NPE due to race on cache stop and timeout handler execution.
> 
>
> Key: IGNITE-8375
> URL: https://issues.apache.org/jira/browse/IGNITE-8375
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Priority: Major
> Fix For: 2.6
>
>
> {noformat}
> 2018-04-22 22:03:08.547 [INFO 
> ][Thread-25420][o.a.i.i.p.cache.GridCacheProcessor] Stopped cache 
> [cacheName=com.sbt.cdm.api.model.published.dictionary.PublishedSystem, 
> group=CACHEGROUP_DICTIONARY]
> 2018-04-22 22:03:08.548 
> [ERROR][grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%][o.a.i.i.p.t.GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.loadPreviousValue(GridCacheContext.java:1450)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:1030)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:731)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:82)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1133)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> NPE caused by execution of method [1] during timeout handler execution [2]:
> cacheCfg.isLoadPreviousValue() throws NPE because cacheCfg can be nulled by 
> [3] on stop.
> [1] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture#loadMissingFromStore
> [2] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.LockTimeoutObject#onTimeout
> [3] org.apache.ignite.internal.processors.cache.GridCacheContext#cleanup



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8375) NPE due to race on cache stop and timeout handler execution.

[Alexander Menshikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465916#comment-16465916
 ] 

Alexander Menshikov edited comment on IGNITE-8375 at 5/11/18 11:47 AM:
---

As I see in this method the *cacheCfg* is used twice:
{code:java}
if (!skipStore && (read || cctx.loadPreviousValue()) && cctx.readThrough() && 
(needReturnVal || read)) {
{code}
 # cctx.loadPreviousValue() calls *cacheCfg*.isLoadPreviousValue()
 # cctx.readThrough() calls *cacheCfg*.isReadThrough() && !skipStore()


was (Author: sharpler):
As I see in this method the *cacheCfg* is ** used twice:
{code:java}
if (!skipStore && (read || cctx.loadPreviousValue()) && cctx.readThrough() && 
(needReturnVal || read)) {
{code}
 # cctx.loadPreviousValue() calls *cacheCfg*.isLoadPreviousValue()
 # cctx.readThrough() calls *cacheCfg*.isReadThrough() && !skipStore()

> NPE due to race on cache stop and timeout handler execution.
> 
>
> Key: IGNITE-8375
> URL: https://issues.apache.org/jira/browse/IGNITE-8375
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexei Scherbakov
>Priority: Major
> Fix For: 2.6
>
>
> {noformat}
> 2018-04-22 22:03:08.547 [INFO 
> ][Thread-25420][o.a.i.i.p.cache.GridCacheProcessor] Stopped cache 
> [cacheName=com.sbt.cdm.api.model.published.dictionary.PublishedSystem, 
> group=CACHEGROUP_DICTIONARY]
> 2018-04-22 22:03:08.548 
> [ERROR][grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%][o.a.i.i.p.t.GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.loadPreviousValue(GridCacheContext.java:1450)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:1030)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:731)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.access$900(GridDhtLockFuture.java:82)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture$LockTimeoutObject.onTimeout(GridDhtLockFuture.java:1133)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> NPE caused by execution of method [1] during timeout handler execution [2]:
> cacheCfg.isLoadPreviousValue() throws NPE because cacheCfg can be nulled by 
> [3] on stop.
> [1] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture#loadMissingFromStore
> [2] 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.LockTimeoutObject#onTimeout
> [3] org.apache.ignite.internal.processors.cache.GridCacheContext#cleanup



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2

[Alexander Menshikov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Menshikov updated IGNITE-5945:

Comment: was deleted

(was: The test works fine when I added blocking of *GridDhtAtomicNearResponse* 
message from the other server (400+ passes).
But it's unclear why that work. I mean cache is FULL_SYNC so have to wait for 
responses from all nodes. I keep investigating the problem and will write about 
any result.)

> Flaky failure in IgniteCache 5: 
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8370) Web console: split page-signin into three separate pages

[Ilya Borisov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471686#comment-16471686
 ] 

Ilya Borisov commented on IGNITE-8370:
--

[~pkonstantinov] after testing the task please assign it back to me, I think I 
broke E2E again...

> Web console: split page-signin into three separate pages
> 
>
> Key: IGNITE-8370
> URL: https://issues.apache.org/jira/browse/IGNITE-8370
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.6
>
>
> Currently, the page-signin component solves three separate cases: user 
> registration, sign in and password restore. Since none of those features has 
> to be on the same page, let's split those to separate pages.
> What to do:
> 1. Split signup, signin and forgot password features to separate components 
> and pages.
> 2. While at it, add an optional "Phone" input to signup page in order to 
> match inputs available on user profile page.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8468) Adding and searching UUIDs in index tree produces a lot of garbage

[Igor Seliverstov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471703#comment-16471703
 ] 

Igor Seliverstov commented on IGNITE-8468:
--

[~amashenkov], looks OK to me.

> Adding and searching UUIDs in index tree produces a lot of garbage
> --
>
> Key: IGNITE-8468
> URL: https://issues.apache.org/jira/browse/IGNITE-8468
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Seems, optimization for UUIDs was missed in IGNITE-5918.
> PFA patch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-5945) Flaky failure in IgniteCache 5: IgniteCacheAtomicProtocolTest.testPutReaderUpdate2

[Alexander Menshikov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470817#comment-16470817
 ] 

Alexander Menshikov edited comment on IGNITE-5945 at 5/11/18 11:22 AM:
---

I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

*UPD:*

460 passes locally

600 passes on TC (see link)


was (Author: sharpler):
I found out the reason for the problem. As I see, rebalancing can change 
primary node with near cache when new client nodes appear. I'm not sure this is 
a valid behaver, but this is what really happens (I have checked it).
 So adding a call for *awaitPartitionMapExchange* can fix the problem. I will 
double check this solution (locally and on TC), prepare PR and update status of 
the issue when done.

*UPD:*

460 passes locally

> Flaky failure in IgniteCache 5: 
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate2
> --
>
> Key: IGNITE-5945
> URL: https://issues.apache.org/jira/browse/IGNITE-5945
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest#testPutReaderUpdate2
> {noformat}
> junit.framework.AssertionFailedError
>   at junit.framework.Assert.fail(Assert.java:55)
>   at junit.framework.Assert.assertTrue(Assert.java:22)
>   at junit.framework.Assert.assertFalse(Assert.java:39)
>   at junit.framework.Assert.assertFalse(Assert.java:47)
>   at junit.framework.TestCase.assertFalse(TestCase.java:219)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.readerUpdateDhtFails(IgniteCacheAtomicProtocolTest.java:865)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.IgniteCacheAtomicProtocolTest.testPutReaderUpdate2(IgniteCacheAtomicProtocolTest.java:765)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Fail is reproducable locally 2 times per 20 runs
> On TeamCity test success rate is 88,2%



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-172) [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and IgniteTcpCommunicationRecoveryAckClosureSelfTest

[Vitaliy Biryukov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471768#comment-16471768
 ] 

Vitaliy Biryukov commented on IGNITE-172:
-

[~NSAmelchev] , LGTM.

> [Test] [Rare] GridTcpCommunicationSpiRecoveryAckSelfTest and 
> IgniteTcpCommunicationRecoveryAckClosureSelfTest
> -
>
> Key: IGNITE-172
> URL: https://issues.apache.org/jira/browse/IGNITE-172
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.5.0.final
>Reporter: Irina Vasilinets
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> GridTcpCommunicationSpiRecoveryAckSelfTest.testQueueOverflow and 
> GridTcpCommunicationSpiTcpNoDelayOffSelfTest.testSendToManyNodes 
>  fail sometimes.
> IgniteTcpCommunicationRecoveryAckClosureSelfTest.testQueueOverflow - 1 from 10



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8384:
-
Description: 
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.

UPD: If we have an affinity field in key class, then affinity column will be 
added to secondary index as well. 
So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}

  was:
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.


> SQL: Secondary indexes should sort entries by links rather than keys
> 
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The 
> key itself is not stored in the index in general case. It means that we need 
> to perform a lookup to data page to find correct insertion point for index 
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
> link}}. This is all we need.
> UPD: If we have an affinity field in key class, then affinity column will be 
> added to secondary index as well. 
> So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8474) WalStateNodeLeaveExchangeTask prevents merge exchanges on leaving many nodes

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8474:
---

 Summary: WalStateNodeLeaveExchangeTask prevents merge exchanges on 
leaving many nodes
 Key: IGNITE-8474
 URL: https://issues.apache.org/jira/browse/IGNITE-8474
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Sergey Chugunov
Assignee: Sergey Chugunov
 Fix For: 2.6


Exchange merge mechanism provides huge optimization when a lot of nodes join or 
leave cluster simultaneously.

In IGNITE-7003 WalStateNodeLeaveExchangeTask custom exchange task was added 
which is generated for each NODE_LEFT/NODE_FAILED event.
Because of property skipForExchangeMerge set to false on this task it prohibits 
exchange merge optimization.

The property needs to be reconsidered and changed if it is not crucial for this 
functionality.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Ilya Kasnacheev (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472074#comment-16472074
 ] 

Ilya Kasnacheev commented on IGNITE-7963:
-

Instead javadoc "Note: Future may never complete unless close() or flush() is 
called explicitly."

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5874) Store TTL expire times in B+ tree on per-partition basis

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472153#comment-16472153
 ] 

Ivan Rakov commented on IGNITE-5874:


Thanks for your contribution!
Merged to master.

> Store TTL expire times in B+ tree on per-partition basis
> 
>
> Key: IGNITE-5874
> URL: https://issues.apache.org/jira/browse/IGNITE-5874
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Ivan Rakov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
> Attachments: IgnitePdsWithTtlTest.java
>
>
> TTL expire times for entries are stored in PendingEntriesTree, which is 
> singleton for cache. When expiration occurs, all system threads iterate 
> through the tree in order to remove expired entries. Iterating through single 
> tree causes contention and perfomance loss. 
> Related performance issue: https://issues.apache.org/jira/browse/IGNITE-5793
> We should keep instance of PendingEntriesTree for each partition, like we do 
> for CacheDataTree.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Aleksey Plekhanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472037#comment-16472037
 ] 

Aleksey Plekhanov commented on IGNITE-6846:
---

[~Alexey Kuznetsov], I've looked at your patch, changes looks good to me.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.6
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8473) Add option to enable/disable WAL for several caches with single command

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8473:
--

 Summary: Add option to enable/disable WAL for several caches with 
single command
 Key: IGNITE-8473
 URL: https://issues.apache.org/jira/browse/IGNITE-8473
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Rakov
 Fix For: 2.6


API method for disabling WAL in IgniteCluster accepts only one cache name. 
Every call triggers exchange and checkpoints cluster-wide - it takes plenty of 
time to disable/enable WAL for multiple caches.
We should add option to disable/enable WAL for several caches with single 
command. 

New proposed API methods:
IgniteCluster.disableWal(Collection cacheNames)
IgniteCluster.enableWal(Collection cacheNames)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Alexey Kuznetsov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472110#comment-16472110
 ] 

Alexey Kuznetsov commented on IGNITE-5960:
--

[~agoncharuk] 
 > Note that it would be cleaner to acquire the listeners map after the 
 > partition update counter is incremented, however, the listeners map is used 
 > in the needVal flag evaluation.

Yeah, I tried to acquire the listeners map *after* the partition update counter 
is incremented:
To do so, we firstly need to move _needVal_ and _readFromStore_ flags 
evaluation after update counter is incremented.
But _readFromStore_ flag must be evaluated strongly *before* partition counter 
is incremented, see _GridCacheMapEntry.AtomicCacheUpdateClosure#call_ where we 
load data from store.

So, we cannot acquire the listeners map *after* the partition update counter is 
incremented.

> Currently it is possible that {{evtOldVal}} will be {{null}} if we read 
>{{null}} from {{updateListeners}} in the first place.

In my fix, query entry must be filtered out  if we read {{null}} from 
{{updateListeners}} in the first place(this fixes the essential bug).

To filter out entry, _newVal_ and _oldVal_ must be passed as nulls to 
_cctx.continuousQueries().onEntryUpdated_ ,
see _CacheContinuousQueryManager#onEntryUpdated_ , 
_CacheContinuousQueryManager#skipUpdateEvent_ .

Let's consider again the scenario:

1) T1 updates E1 (updateCounter gets incremented to 1);
 2) T2 updates E2 (updateCounter gets incremented to 2);
 3) T2 finishes update and exits GridCacheMapEntry::innerUpdate method; In this 
point we have CacheContinuousQueryEventBuffer#currentPartitionCounter equals 2
 4) user adds continuous query listener;
 5) T1 proceeds, picks up listener (not null thanks to the fix) and notifies 
listener; Batch#startCntr equals 2 (currentPartitionCounter() returns 2) so 
 entry E1 would be filtered out of Batch (E1 update counter would be smaller 
than Batch#startCntr)
 PS E1 also can be sent to remote node(if we have remote listener installed) 
and processed in CacheContinuousQueryPartitionRecovery#collectEntries,
 but it would be filtered out there.
 6) T3 updates E3 (updateCounter gets incremented to 3) and notifies listener;

After 6) user's listener would be notified only once by key 3.

After listener is set by user, entry E1 must be filtered out.

 

Are you agree with such changes ?

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.6
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> 

[jira] [Commented] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472057#comment-16472057
 ] 

ASF GitHub Bot commented on IGNITE-7999:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3789


> Enhance performance of the thin JDBC streaming mode 
> 
>
> Key: IGNITE-7999
> URL: https://issues.apache.org/jira/browse/IGNITE-7999
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
> Attachments: Results.html, flamegraph-30.svg
>
>
> Try to enhance thin JDBC performance for streaming mode.
> Waiting for server response takes a lot of time on streaming INSERT.
> Try to skip server response in special mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5977) [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence

[Aleksey Plekhanov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472104#comment-16472104
 ] 

Aleksey Plekhanov commented on IGNITE-5977:
---

I made changes for {{IgniteAtomicSequence}}, {{IgniteCountDownLatch}}, 
{{IgniteSemaphore}} and {{IgniteLock}}. This data structures are vulnerable to 
a race condition. {{IgniteAtomicLong}} was fixed before by ticket IGNITE-7845. 
{{IgniteSet}} and {{IgniteQueue}} makes requests to distributed cache when we 
try to get these data structures, so it's not necessary to fix tests for these 
structures.

> [Test Failed]  IgniteClientDiscoveryDataStructuresTest.testSequence
> ---
>
> Key: IGNITE-5977
> URL: https://issues.apache.org/jira/browse/IGNITE-5977
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Fails locally.
> Example of failing 
> http://ci.ignite.apache.org/viewLog.html?buildId=760759=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId2829619862655631000



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8464) WALIterator broken (race on the switch to the next segment during iteration and concurrent archiving same segment)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472129#comment-16472129
 ] 

ASF GitHub Bot commented on IGNITE-8464:


GitHub user akalash opened a pull request:

https://github.com/apache/ignite/pull/3982

IGNITE-8464 removed file format after archive



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8464

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3982.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3982


commit 502e52d687e3b796b351cbb8e916d331a64675c6
Author: Anton Kalashnikov 
Date:   2018-05-11T15:40:13Z

IGNITE-8464 removed file format after archive




> WALIterator broken (race on the switch to the next segment during iteration 
> and concurrent archiving same segment)
> --
>
> Key: IGNITE-8464
> URL: https://issues.apache.org/jira/browse/IGNITE-8464
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.6
>
>
> FileArchiver
> {code}
> final SegmentArchiveResult res = archiveSegment(toArchive);
> synchronized (this) {
>  while (locked.containsKey(toArchive) && !stopped)
>  wait();
> }
> // Firstly, format working file
> if (!stopped)
>  formatFile(res.getOrigWorkFile());
> synchronized (this) {
>  // Then increase counter to allow rollover on clean working file
>  changeLastArchivedIndexAndNotifyWaiters(toArchive);
>  notifyAll();
> }
> {code}
> Some thread may try read segments when archive formating file in work dir 
> (formatFile not synchronized), last archived index is still not updated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura reassigned IGNITE-8471:
---

Assignee: Andrey Gura

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8471:

Fix Version/s: (was: 2.6)
   2.5

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura resolved IGNITE-8472.
-
   Resolution: Duplicate
Fix Version/s: (was: 2.6)

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8472
> URL: https://issues.apache.org/jira/browse/IGNITE-8472
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Critical
>
> There are two vulnerabilities in the latest 2.3.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: Upgrade Commons BeanUtils to the latest 
> version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution to this issue is:* To upgrade to the latest available Version 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys

[Andrew Mashenkov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8384:
-
Description: 
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.

UPD: If we have an affinity keys, then affinity column will be added to 
secondary index as well. 
 So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}

  was:
Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The key 
itself is not stored in the index in general case. It means that we need to 
perform a lookup to data page to find correct insertion point for index entry.

This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
link}}. This is all we need.

UPD: If we have an affinity field in key class, then affinity column will be 
added to secondary index as well. 
So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}


> SQL: Secondary indexes should sort entries by links rather than keys
> 
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: iep-19, performance
> Fix For: 2.6
>
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The 
> key itself is not stored in the index in general case. It means that we need 
> to perform a lookup to data page to find correct insertion point for index 
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols, 
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to 
> secondary index as well. 
>  So, we'll have secondary index as  {{(idx_cols, KEY, AFF_COL)}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Harendra Rai (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harendra Rai updated IGNITE-8471:
-
Issue Type: Bug  (was: Improvement)

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Major
> Fix For: 2.5
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8298) Broken UI of the latest table cell

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8298:

Fix Version/s: (was: 2.5)
   2.6

> Broken UI of the latest table cell
> --
>
> Key: IGNITE-8298
> URL: https://issues.apache.org/jira/browse/IGNITE-8298
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>Priority: Major
> Fix For: 2.6
>
>
> Check the latest cell in a table. It's UI looks broken.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8060:

Fix Version/s: (was: 2.5)
   2.6

> Sqline creating tables on client nodes works incorrect in case of node's 
> shutdown
> -
>
> Key: IGNITE-8060
> URL: https://issues.apache.org/jira/browse/IGNITE-8060
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.6
>
> Attachments: ignite-76cc6387.log, ignite-a1c90af9.log
>
>
> For reproducing (master branch)
> You should start one local server and one local client nodes and follow the 
> instructions:
> 1)Connect to client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 2)Create new table on client node:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> 3)Check that table exists from server node:
> !tables
> On this step table should be shown in the response.
> 4)Drop the client node
> 5)Create new client node
> 6)Connect to new client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 7)Check that table exists from server node:
> !tables
> *On this step there is no "city" table in the list.*
> 8)Try to drop the table:
>  DROP TABLE City;
>  java.sql.SQLException: Table doesn't exist: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  at sqlline.Commands.execute(Commands.java:823)
>  at sqlline.Commands.sql(Commands.java:733)
>  at sqlline.SqlLine.dispatch(SqlLine.java:795)
>  at sqlline.SqlLine.begin(SqlLine.java:668)
>  at sqlline.SqlLine.start(SqlLine.java:373)
>  at sqlline.SqlLine.main(SqlLine.java:265)
> 9)Try to create new table:
>  CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> java.sql.SQLException: Table already exists: CITY
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130)
>  at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299)
>  at sqlline.Commands.execute(Commands.java:823)
>  at sqlline.Commands.sql(Commands.java:733)
>  at sqlline.SqlLine.dispatch(SqlLine.java:795)
>  at sqlline.SqlLine.begin(SqlLine.java:668)
>  at sqlline.SqlLine.start(SqlLine.java:373)
>  at sqlline.SqlLine.main(SqlLine.java:265)
> Update:
> Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done.
>  !tables doen\t work even after SELECT
>  SELECT works OK.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8220) Discovery worker termination in PDS test

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8220:

Fix Version/s: (was: 2.5)
   2.6

> Discovery worker termination in PDS test
> 
>
> Key: IGNITE-8220
> URL: https://issues.apache.org/jira/browse/IGNITE-8220
> Project: Ignite
>  Issue Type: Test
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
>
> 3 suites failed 
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePds1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo1_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ActivateDeactivateCluster_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
> Example of tests failed:
> - IgniteClusterActivateDeactivateTestWithPersistence.testActivateFailover3
> - IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateFailover3  
> {noformat}
> [2018-04-11 
> 02:43:09,769][ERROR][tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%][IgniteTestResources]
>  Critical failure. Will be handled accordingly to configured handler 
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext 
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Thread 
> tcp-disco-srvr-#2298%cache.IgniteClusterActivateDeactivateTestWithPersistence0%
>  is terminated unexpectedly.]] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5977) [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471998#comment-16471998
 ] 

ASF GitHub Bot commented on IGNITE-5977:


GitHub user alex-plekhanov opened a pull request:

https://github.com/apache/ignite/pull/3981

IGNITE-5977 Flaky failure of IgniteClientDataStructuresTest (looped TC run)



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/alex-plekhanov/ignite ignite-5977-debug

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3981.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3981


commit 085458aad03955f9766b1df8a3cc3524f5071dbe
Author: Aleksey Plekhanov 
Date:   2018-05-11T14:07:27Z

IGNITE-5977 Flaky failure of IgniteClientDataStructuresTest

commit 69acbf1250e0d94e29943aedb36d194e6f79fbaf
Author: Aleksey Plekhanov 
Date:   2018-05-11T14:11:12Z

IGNITE-5977 Flaky failure of IgniteClientDataStructuresTest (looped TC run)




> [Test Failed]  IgniteClientDiscoveryDataStructuresTest.testSequence
> ---
>
> Key: IGNITE-5977
> URL: https://issues.apache.org/jira/browse/IGNITE-5977
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Fails locally.
> Example of failing 
> http://ci.ignite.apache.org/viewLog.html?buildId=760759=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId2829619862655631000



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Harendra Rai (JIRA)]

Harendra Rai created IGNITE-8471:


 Summary: Apache ignite for .NET has security vulnerabilities
 Key: IGNITE-8471
 URL: https://issues.apache.org/jira/browse/IGNITE-8471
 Project: Ignite
  Issue Type: Improvement
  Components: security
Affects Versions: 2.4
Reporter: Harendra Rai
 Fix For: 2.5


There are two security vulnerabilities in the latest 2.4.0 version.
 # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 :  
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]

*Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
the latest version >= commons-beanutils-1.9.2
 # commons-codec-1.6.jar: Here is the vulnerability detail 
https://issues.apache.org/jira/browse/CODEC-96

*Resolution* *to this issue is:* To upgrade to the latest available Version 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities

[Harendra Rai (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Harendra Rai updated IGNITE-8472:
-
Description: 
There are two vulnerabilities in the latest 2.3.0 version.
 # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 :  
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]

*Resolution to this issue is*: Upgrade Commons BeanUtils to the latest version 
>= commons-beanutils-1.9.2
 # commons-codec-1.6.jar: Here is the vulnerability detail 
https://issues.apache.org/jira/browse/CODEC-96

*Resolution to this issue is:* To upgrade to the latest available Version 1.11

  was:
There are two vulnerabilities in the latest 2.3.0 version.
 # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 :  
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]

*Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
the latest version >= commons-beanutils-1.9.2
 # commons-codec-1.6.jar: Here is the vulnerability detail 
https://issues.apache.org/jira/browse/CODEC-96

*Resolution to this issue is:* To upgrade to the latest available Version 1.11


> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8472
> URL: https://issues.apache.org/jira/browse/IGNITE-8472
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Critical
> Fix For: 2.5
>
>
> There are two vulnerabilities in the latest 2.3.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: Upgrade Commons BeanUtils to the latest 
> version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution to this issue is:* To upgrade to the latest available Version 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8471:

Fix Version/s: (was: 2.5)
   2.6

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Major
> Fix For: 2.6
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8472:

Fix Version/s: (was: 2.5)
   2.6

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8472
> URL: https://issues.apache.org/jira/browse/IGNITE-8472
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Critical
> Fix For: 2.6
>
>
> There are two vulnerabilities in the latest 2.3.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: Upgrade Commons BeanUtils to the latest 
> version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution to this issue is:* To upgrade to the latest available Version 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-6010) ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes

[Amelchev Nikita (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Amelchev Nikita reassigned IGNITE-6010:
---

Assignee: Amelchev Nikita

> ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes
> ---
>
> Key: IGNITE-6010
> URL: https://issues.apache.org/jira/browse/IGNITE-6010
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at 
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper(ZookeeperIpFinderTest.java:365)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Ryabov Dmitrii (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471935#comment-16471935
 ] 

Ryabov Dmitrii commented on IGNITE-8456:


[~dpavlov], I've done with logging. Here is ["Basic" 
build|https://ci.ignite.apache.org/viewLog.html?buildId=1283846;]. Prepared 
solution doesn't affect the existing Ignite functionality and other tests. 
Could you please review the changes?

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8472) Apache ignite for .NET has security vulnerabilities

[Harendra Rai (JIRA)]

Harendra Rai created IGNITE-8472:


 Summary: Apache ignite for .NET has security vulnerabilities
 Key: IGNITE-8472
 URL: https://issues.apache.org/jira/browse/IGNITE-8472
 Project: Ignite
  Issue Type: Bug
  Components: security
Affects Versions: 2.4
Reporter: Harendra Rai
 Fix For: 2.5


There are two vulnerabilities in the latest 2.3.0 version.
 # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 :  
[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]

*Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
the latest version >= commons-beanutils-1.9.2
 # commons-codec-1.6.jar: Here is the vulnerability detail 
https://issues.apache.org/jira/browse/CODEC-96

*Resolution to this issue is:* To upgrade to the latest available Version 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[Vladimir Ozerov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471919#comment-16471919
 ] 

Vladimir Ozerov commented on IGNITE-8471:
-

[~hkrai77], hi. Note that these vulnerabilities do not relate to Apache 
Ignite.NET, but to the whole product. 

> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Priority: Major
> Fix For: 2.5
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8055) Sqline command !tables works incorrect for client node

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8055:

Fix Version/s: (was: 2.5)
   2.6

> Sqline command !tables works incorrect for client node
> --
>
> Key: IGNITE-8055
> URL: https://issues.apache.org/jira/browse/IGNITE-8055
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Andrey Aleksandrov
>Priority: Minor
> Fix For: 2.6
>
>
> For reproducing:
> You should start one local server and one local client nodes and follow the 
> instructions:
> 1)Connect to server node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800
> 2)Create new table on server node:
> CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH 
> "template=replicated";
> 3)Check that table exists from server node:
> !tables
> On this step table should be shown in the response.
> 4)Connect to client node:
> sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801
> 5)Check that table exists from server node:
> !tables
> *On this step there is no "city" table in the list.*
> Next commands work from client node as well:
> SELECT * FROM City
> DROP TABLE City
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8219) B+Tree operation may result in an infinite loop in some case

[Andrey Gura (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8219:

Fix Version/s: (was: 2.5)
   2.6

>  B+Tree operation may result in an infinite loop in some case
> -
>
> Key: IGNITE-8219
> URL: https://issues.apache.org/jira/browse/IGNITE-8219
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Alexey Stelmak
>Assignee: Alexey Stelmak
>Priority: Major
> Fix For: 2.6
>
>
> B+Tree operation may result in an infinite loop in case. Test 
> DynamicIndexServerCoordinatorBasicSelfTest#testCreateIndexWithInlineSizePartitionedAtomic
>  region size = 512Mb, KEY_BEFORE=1, KEY_AFTER=2



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7818) Incorrect assertion in PDS page eviction method

[Ivan Fedotov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Fedotov reassigned IGNITE-7818:


Assignee: Ivan Fedotov

> Incorrect assertion in PDS page eviction method
> ---
>
> Key: IGNITE-7818
> URL: https://issues.apache.org/jira/browse/IGNITE-7818
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Fedotov
>Priority: Major
>
> There is an assertion in the method 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.Segment#removePageForReplacement:
>  
> {code:java}
> assert relRmvAddr != INVALID_REL_PTR;{code}
> Which seems potentially dangerous. In some rare cases, when count of 
> interations more then 40% of allocated pages and all processed pages are 
> aquired, the {{relRmvAddr}} variable will be uninitialized and 
> {{AssertionException}} will be thrown. But it's a correct case and page to 
> evict can be found later in the method {{tryToFindSequentially.}}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-5977) [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471997#comment-16471997
 ] 

ASF GitHub Bot commented on IGNITE-5977:


GitHub user alex-plekhanov opened a pull request:

https://github.com/apache/ignite/pull/3980

IGNITE-5977 Flaky failure of IgniteClientDataStructuresTest



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/alex-plekhanov/ignite ignite-5977

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3980.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3980


commit 085458aad03955f9766b1df8a3cc3524f5071dbe
Author: Aleksey Plekhanov 
Date:   2018-05-11T14:07:27Z

IGNITE-5977 Flaky failure of IgniteClientDataStructuresTest




> [Test Failed]  IgniteClientDiscoveryDataStructuresTest.testSequence
> ---
>
> Key: IGNITE-5977
> URL: https://issues.apache.org/jira/browse/IGNITE-5977
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Fails locally.
> Example of failing 
> http://ci.ignite.apache.org/viewLog.html?buildId=760759=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId2829619862655631000



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6879) Support Spring Data 2.0

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472396#comment-16472396
 ] 

Dmitriy Pavlov commented on IGNITE-6879:


Hi [~homich], 

 

it seems some test were anyway broken, Examples test can't pass on TC

[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9052304574499269123=%3Cdefault%3E=testDetails]

 

Could you please take a look and fix?

> Support Spring Data 2.0
> ---
>
> Key: IGNITE-6879
> URL: https://issues.apache.org/jira/browse/IGNITE-6879
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Assignee: Roman Meerson
>Priority: Major
> Fix For: 2.6
>
>
> Ignite-spring and ignite-spring-data now use Spring 1.1 and cannot be rebuilt 
> with Spring 2.0. Trying to change the Spring dependency version to 
> 2.0.0.release results in compile errors like below and requires regression in 
> general. 
> This improvement was created to either migrate from Spring 1.1 to 2.0 or 
> create another set of modules ignite-spring-xxx-2 to have backward 
> compatibility with Spring 1.1.
> [ERROR] 
> /Users/kukushal/Dev/incubator-ignite/modules/spring-data/src/main/java/org/apache/ignite/springdata/repository/IgniteRepository.java:[57,10]
>  name clash: deleteAll(java.lang.Iterable) in 
> org.apache.ignite.springdata.repository.IgniteRepository and 
> deleteAll(java.lang.Iterable) in 
> org.springframework.data.repository.CrudRepository have the same erasure, yet 
> neither overrides the other



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8161) Suspend-resume TX test is flaky on TC (~5% fail rate)

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472398#comment-16472398
 ] 

Dmitriy Pavlov commented on IGNITE-8161:


Are there any news on this?

 

> Suspend-resume TX test is flaky on TC (~5% fail rate)
> -
>
> Key: IGNITE-8161
> URL: https://issues.apache.org/jira/browse/IGNITE-8161
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1176294=buildResultsDiv=IgniteTests24Java8_Cache6#testNameId-7194341254453895210
> Causal chani java.lang.RuntimeException: javax.cache.CacheException: class 
> org.apache.ignite.transactions.TransactionTimeoutException: Cache transaction 
> timed out: GridNearTxLocal 
> First exception in log
> {noformat}
> validParts=null, state=MARKED_ROLLBACK, timedOut=true, 
> topVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], duration=172ms, 
> onePhaseCommit=false], size=0]]]
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest$CI2Exc.apply(IgniteOptimisticTxSuspendResumeTest.java:759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.executeTestForAllCaches(IgniteOptimisticTxSuspendResumeTest.java:728)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteOptimisticTxSuspendResumeTest.testTxTimeoutOnResumed(IgniteOptimisticTxSuspendResumeTest.java:431)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2018)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:136)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1933)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Test history
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7194341254453895210=testDetails



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda reassigned IGNITE-8039:
---

Assignee: Prachi Garg  (was: Igor Sapego)

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472412#comment-16472412
 ] 

Dmitriy Pavlov commented on IGNITE-3999:


Hi [~vkulichenko],

I would like to hear final ok from you, because you're reporter of this issue.

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is possible only with the help of 
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add 
> a respective property to {{@QuerySqlField}} annotation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6531) Need to add a 'required' field to the SpringResource annotation.

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472440#comment-16472440
 ] 

Denis Magda commented on IGNITE-6531:
-

[~dpavlov], I'm not sure what we're trying to improve here. [~skylark-nam] 
please explain your use case in more details.

> Need to add a 'required' field to the SpringResource annotation.
> 
>
> Key: IGNITE-6531
> URL: https://issues.apache.org/jira/browse/IGNITE-6531
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: joungdal.nam
>Assignee: joungdal.nam
>Priority: Minor
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In my test environment, only the client is used(setForceServerMode(true)). 
> Operating environments use clients and servers.
> Sometimes Injection is not required in the test environment.
> NoSuchBeanDefinitionException is not generated by specifying a value of false.
> public @interface SpringResource {
>   
>   /**
>* Declares whether the annotated dependency is required.
>* Defaults to {@code true}.
>*/
>   boolean required() default true;
> ..
> if (!StringUtils.isEmpty(beanName)) {
>   try {
>   bean = springCtx.getBean(beanName);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }
> else {
>   try {
>   bean = springCtx.getBean(beanCls);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8320) Page corruption during the rebalancing cache.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472351#comment-16472351
 ] 

ASF GitHub Bot commented on IGNITE-8320:


GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/3985

IGNITE-8320 Corrupted indexes fix



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8320-reproduce

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3985.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3985


commit ffb362929decc431b325bccc8c612a049f85063f
Author: Pavel Kovalenko 
Date:   2018-05-11T15:32:32Z

IGNITE-8320 Reproducer.

commit 37765277286a18198255bcbc2286073706ef6048
Author: Pavel Kovalenko 
Date:   2018-05-11T15:33:42Z

IGNITE-8320 Reproducer.

commit d1d265ae98ab79d6d80a667e4a844ea86f724e32
Author: Pavel Kovalenko 
Date:   2018-05-11T15:34:47Z

IGNITE-8320 Docs fix.

commit 234b1f8fcf24d849227e5e73e26fb81e0768cf21
Author: Pavel Kovalenko 
Date:   2018-05-11T15:36:01Z

IGNITE-8320 Docs fix.

commit 951d67e93677358470416a5faabe238b6e2bb21a
Author: Pavel Kovalenko 
Date:   2018-05-11T16:46:15Z

IGNITE-8320 Fix WIP.

commit a1acab629dfce81e904bdc6fac92458b60a7ac48
Author: Pavel Kovalenko 
Date:   2018-05-11T17:51:00Z

IGNITE-8320 Fix WIP.




> Page corruption during the rebalancing cache.
> -
>
> Key: IGNITE-8320
> URL: https://issues.apache.org/jira/browse/IGNITE-8320
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Cache rebalance may result in page memory corruption.
> {noformat}
> [2018-04-18T14:33:23,260][ERROR][sys-#54][GridCacheIoManager] Failed 
> processing message [senderId=95f06c25-e6bb-48f7-a3e5-4c05fc1c49be, 
> msg=GridDhtPartitionSupplyMessage [rebalanceId=37, 
> topVer=AffinityTopologyVersion [topVer=53, minorTopVer=1], missed=null, 
> clean=null, msgSize=525350, estimatedKeysCnt=1690216, size=2, parts=[1, 2], 
> super=GridCacheGroupIdMessage [grpId=-1831596270]]]
>  org.apache.ignite.IgniteException: Runtime failure on row: Row@33b6805c[ 
> key:  [idHash=773709078, hash=-630455542, ...], val:  
> [idHash=1309051286, hash=-1321165334, ver: GridCacheVersion 
> [topVer=135435024, order=1523963943331, nodeOrder=4] ]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:454)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:653)
>  ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1391)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1255)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1451)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
>  ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
>  at 
> 

[jira] [Commented] (IGNITE-584) Need to make sure that scan query returns consistent results on topology changes

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472410#comment-16472410
 ] 

Dmitriy Pavlov commented on IGNITE-584:
---

Hi [~zstan], is ticket still actual?

> Need to make sure that scan query returns consistent results on topology 
> changes
> 
>
> Key: IGNITE-584
> URL: https://issues.apache.org/jira/browse/IGNITE-584
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Affects Versions: 1.9, 2.0, 2.1
>Reporter: Artem Shutak
>Assignee: Semen Boikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.6
>
> Attachments: tc1.png
>
>
> Consistent results on topology changes was implemented for sql queries, but 
> looks like it still does not work for scan queries.
> This affects 'cache set' tests since set uses scan query for set iteration 
> (to be unmuted on TC): 
> GridCacheSetAbstractSelfTest testNodeJoinsAndLeaves and 
> testNodeJoinsAndLeavesCollocated; 
> Also see todos here GridCacheSetFailoverAbstractSelfTest



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8469) Non-heap memroy leak for calling cluster activation multi times

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472416#comment-16472416
 ] 

ASF GitHub Bot commented on IGNITE-8469:


GitHub user Mmuzaf opened a pull request:

https://github.com/apache/ignite/pull/3986

IGNITE-8469: release memory in case initialization multi times



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Mmuzaf/ignite ignite-8469

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3986.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3986


commit 38c0b2e3d26f3190f6d981ffa5f9a5862610f795
Author: Maxim Muzafarov 
Date:   2018-05-11T18:23:28Z

IGNITE-8469: release memory in case initialization multi times




> Non-heap memroy leak for calling cluster activation multi times
> ---
>
> Key: IGNITE-8469
> URL: https://issues.apache.org/jira/browse/IGNITE-8469
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.6
>
>
> Calling multiple time cluster (with enabled persistence and started client 
> nodes) activation {{ig3CB.cluster().active(true);}} leads to non-heap memory 
> leak.
> Line 
> {{org/apache/ignite/internal/pagemem/impl/PageMemoryNoStoreImpl.java:234}} 
> looks suspicious because of in case method 
> {{org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl#start}} 
> callled multi times (e.g. activate(true) called multi times) we lost info 
> about allocated regions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472425#comment-16472425
 ] 

Denis Magda commented on IGNITE-8039:
-

[~pgarg], please review new hidden pages prepared by Igor for the protocol.

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7893) Release Java Thin client documentation

[Prachi Garg (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472479#comment-16472479
 ] 

Prachi Garg commented on IGNITE-7893:
-

Reviewed. made some minor edits.

> Release Java Thin client documentation
> --
>
> Key: IGNITE-7893
> URL: https://issues.apache.org/jira/browse/IGNITE-7893
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.5
>
>
> Java thin client is already available for usage and documented:
> https://apacheignite.readme.io/v2.3/docs/java-thin-client
> It will be officially released in 2.5. For now, the users have to build it 
> from sources.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-7893) Release Java Thin client documentation

[Prachi Garg (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prachi Garg reassigned IGNITE-7893:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Release Java Thin client documentation
> --
>
> Key: IGNITE-7893
> URL: https://issues.apache.org/jira/browse/IGNITE-7893
> Project: Ignite
>  Issue Type: New Feature
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> Java thin client is already available for usage and documented:
> https://apacheignite.readme.io/v2.3/docs/java-thin-client
> It will be officially released in 2.5. For now, the users have to build it 
> from sources.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472190#comment-16472190
 ] 

ASF GitHub Bot commented on IGNITE-7999:


GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/3983

IGNITE-7999: for 2.4



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7999-2.4-next

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3983.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3983


commit 915dd2966084d78f7b4f3d482e6bd25f860c1e23
Author: Alexey Goncharuk 
Date:   2018-01-31T08:22:26Z

IGNITE-7569 Fixed index rebuild future - Fixes #3454.

commit 8ea8609259039852ab0c26f26ac528c1ffae7c94
Author: Alexey Goncharuk 
Date:   2018-01-31T08:24:57Z

IGNITE-7577 Fixing public API active flag on baseline changes - Fixes #3455.

commit c8ce1f66e98b3174d771a3b801a2538499dc2c3d
Author: Ivan Rakov 
Date:   2018-01-31T09:51:09Z

IGNITE-7475 Improved VerifyBackupPartitionsTask to calculate partition 
hashes in parallel - Fixes #3407.

Signed-off-by: Alexey Goncharuk 

commit 258ff4299da20122d7c387cb8579264035c93c18
Author: Alexey Goncharuk 
Date:   2018-01-31T13:52:24Z

IGNITE-7573 Fixed full API tests to be compliant with baseline topology

commit 254ed3a9c32d092702a0461509bf867cbd7cdee6
Author: Alexey Kuznetsov 
Date:   2018-02-01T08:22:53Z

ignite-2.4.0 Update version.

(cherry picked from commit 2e43749)

commit c1a9c0a404d77fba08170bedf14844f87abe3028
Author: Alexey Goncharuk 
Date:   2018-02-01T10:17:28Z

IGNITE-7569 Fixing index rebuild future

commit e43799ce70cdbe03d9e206381d1d5138b820b075
Author: Alexey Goncharuk 
Date:   2018-02-01T13:39:17Z

IGNITE-7520 Provide util-methods to get baseline from context - Fixes #3431.

commit 8f5fc7cfb0624cf2048efad38dfff32f782116e8
Author: Sergey Chugunov 
Date:   2018-02-02T08:24:29Z

IGNITE-7580 Fix compatibilityMode flag consistency

This closes #3466

(cherry picked from commit 8f2045e)

commit d3ddd50cb2b889173176b6c47c9ff61410e1d909
Author: Ilya Lantukh 
Date:   2018-02-07T10:33:28Z

IGNITE-7514 Affinity assignment should be recalculated when primary node is 
not OWNER

(cherry picked from commit faf50f1)

commit d3745e9d0a3ff5a64fba494889b7e2605f3af6bb
Author: Alexey Goncharuk 
Date:   2018-02-07T18:10:32Z

IGNITE-7639 Fixed NPE

commit f7c16855ba802d9d47048521aec7e14285e4a281
Author: Pavel Kovalenko 
Date:   2018-02-09T13:55:15Z

IGNITE-7540 Prevent page memory metadata corruption during checkpoint and 
group destroying. - Fixes #3490.

Signed-off-by: Alexey Goncharuk 

commit c92f167fc491078f02b9f94fe89edafc2902ebc2
Author: ilantukh 
Date:   2018-02-14T12:40:13Z

Updated version in properties.

commit 1ecf348dd429cf7861b414e0e5a7776b72dba281
Author: Sergey Chugunov 
Date:   2018-02-16T13:21:12Z

IGNITE-7699 BinaryMetadata exchange should not be triggered if metadata was 
not updated - Fixes #3523.

Signed-off-by: Alexey Goncharuk 

(cherry-picked from commit bcd3881)

commit 2458bd08a5b501b3eeb5caf0ae6dcaa2bcccd915
Author: EdShangGG 
Date:   2018-02-16T13:29:49Z

IGNITE-7676 Add affinity version to snapshot plugin stub - Fixes #3510.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit b6d21fb)

commit bfdcda7a2a6b5cf64f15ed169d2beb886f131fac
Author: EdShangGG 
Date:   2018-02-12T16:36:30Z

IGNITE-7626 Unify code in test which cleans up persistence directories - 
Fixes #3477.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit a0997b9)

commit 2e92e0094b270aa8489e66d94bfcf15eadabfb4f
Author: EdShangGG 
Date:   2018-02-12T18:44:10Z

IGNITE-7626 Unify code in test which clean up persistence directories - 
Fixes #3512.

Signed-off-by: Alexey Goncharuk 
(cherry picked from commit 6f6f8dd)

commit 3f86c127c78065999663a4fc4eaedb5e5d4bee1c
Author: EdShangGG 
Date:   2018-02-12T18:26:31Z

compilation fix

commit 0b9322c566f9b464291854142ac02495bd1817e4
Author: gg-shq 
Date:   2018-02-07T11:28:04Z

IGNITE-6917: Implemented SQL COPY command.

commit c5e386ca96750213bddcd98d0af0c589fee476ca

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472226#comment-16472226
 ] 

Dmitriy Pavlov commented on IGNITE-8456:


[~ivan.glukos] could you please take a look?

 

[~SomeFire] meanwhile could you please trigger Run All PDS instead of Basic. It 
has very limited coverage for Persistent Data Store functionality, so Run ALL 
PDS would be more relevant.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8475) Create new IgniteCache decorator with fair async methonds

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8475:
---
Description: 
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
 f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async operations.

IgniteCache.withFairAsync()

[dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]

  was:
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async operations.

IgniteCache.withFairAsync()


> Create new IgniteCache decorator with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
>  f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
> with fair async operations.
> IgniteCache.withFairAsync()
> [dev-list|http://apache-ignite-developers.2346864.n4.nabble.com/async-operation-is-not-fair-async-td30364.html]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6430) CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails periodically.

[Dmitriy Pavlov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-6430:
---
Fix Version/s: 2.6

> CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails 
> periodically.
> 
>
> Key: IGNITE-6430
> URL: https://issues.apache.org/jira/browse/IGNITE-6430
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {{CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime}} test 
> fails periodically.
> {noformat}
> [2017-09-18 15:18:20,073][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Expected less 5000, Actual:-100969
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime(CacheGroupsMetricsRebalanceTest.java:261)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> After fix test should be unmuted on TC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6430) CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails periodically.

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472243#comment-16472243
 ] 

Dmitriy Pavlov commented on IGNITE-6430:


[~DmitriyGovorukhin], could you please take a look? I think you are more 
experienced than me in context of this test.

> CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime test fails 
> periodically.
> 
>
> Key: IGNITE-6430
> URL: https://issues.apache.org/jira/browse/IGNITE-6430
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {{CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime}} test 
> fails periodically.
> {noformat}
> [2017-09-18 15:18:20,073][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Expected less 5000, Actual:-100969
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupsMetricsRebalanceTest.testRebalanceEstimateFinishTime(CacheGroupsMetricsRebalanceTest.java:261)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> After fix test should be unmuted on TC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8475) Create new IgniteCache decorator with fair async methonds

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8475:
--

 Summary: Create new IgniteCache decorator with fair async methonds
 Key: IGNITE-8475
 URL: https://issues.apache.org/jira/browse/IGNITE-8475
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.4
Reporter: Dmitriy Govorukhin
 Fix For: None


GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
operation completed. 

This means all async operation in one thread will be executed one by one but
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async 

operations.

 IgniteCache.withFairAsync()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Denis Magda (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472253#comment-16472253
 ] 

Denis Magda commented on IGNITE-8039:
-

[~isapego] you changes and proposed format look good to me. Are you done with 
this ticket and we can hand it over to Prachi for a final review?

[~alexey.kosenchuk] in fact, Igor is updating cloned and hidden pages of 2.4 
pages that are public. He is just following this part of our documentation 
process - _If you want to add a new document pertaining to the next release, 
create it within a document for the current version and keep the page hidden. _ 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-Readme.ioDocsforaNextRelease

So, the public and previously released 2.4 pages are left untackled. 

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8475) Create new IgniteCache decorator with fair async methonds

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8475:
---
Description: 
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation 
completed. 

This means all async operation in one thread will be executed one by one but 
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async operations.

IgniteCache.withFairAsync()

  was:
GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
operation completed. 

This means all async operation in one thread will be executed one by one but
not in parallel. Async operation is not async. 

Example for atomic cache 

f1=cache.getAsync(key1); 
f2=cache.getAsync(key2); 

f1 always will be complete before f2. 

Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
with fair async 

operations.

 IgniteCache.withFairAsync()


> Create new IgniteCache decorator with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
> f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
> with fair async operations.
> IgniteCache.withFairAsync()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8475) Create new IgniteCache decorator with fair async methonds

[Dmitriy Govorukhin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-8475:
---
Fix Version/s: (was: None)

> Create new IgniteCache decorator with fair async methonds
> -
>
> Key: IGNITE-8475
> URL: https://issues.apache.org/jira/browse/IGNITE-8475
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Dmitriy Govorukhin
>Priority: Major
>
> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async 
> operation completed. 
> This means all async operation in one thread will be executed one by one but 
> not in parallel. Async operation is not async. 
> Example for atomic cache 
> f1=cache.getAsync(key1); 
> f2=cache.getAsync(key2); 
> f1 always will be complete before f2. 
> Need to create a new decorator for IgniteCache, and return IgniteCache proxy 
> with fair async operations.
> IgniteCache.withFairAsync()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8133) Baseline topology documentation improvement

[Denis Magda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/IGNITE-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Magda updated IGNITE-8133:

Attachment: blt_guide.md

> Baseline topology documentation improvement
> ---
>
> Key: IGNITE-8133
> URL: https://issues.apache.org/jira/browse/IGNITE-8133
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
> Attachments: blt_guide.md
>
>
> Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
> Ignite cluster behavior when persistence is enabled (first of all, activation 
> and rebalancing timings).
> It seems that the current documentation may be confusing.
> For example, the sentence
> {quote}Note that the baseline topology is not set when the cluster is started 
> for the first time; that's the only time when a manual intervention is 
> needed.{quote}
> may lead one to think that baseline topology is not used by default and needs 
> to be enabled only if one wants to use it.
> Also, the documentation describes the tools and commands that are used to 
> manage the baseline topology and activation, but doesn't give guidelines on 
> which nodes should be in the topology, when should it be changed, etc.
> The documentation should be enhanced to
> - give clear understanding that baseline topology always needs to be 
> considered as a part of the cluster architecture when persistence is enabled;
> - provide overview of the behavioral changes compared to AI 2.3 (use a 
> note/warning block for that to separate it from the main text?);
> - provide basic guidelines and suggestions of how one can start a new cluster 
> and manage it (when to activate/deactivate, when to change baseline topology, 
> what happens and what needs to be done when a node fails or joins, how to use 
> consistentId)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6531) Need to add a 'required' field to the SpringResource annotation.

[Dmitriy Pavlov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472268#comment-16472268
 ] 

Dmitriy Pavlov commented on IGNITE-6531:


Hi [~skylark-nam] I did not understood which problem this fix will solve.

We can ignore absent bean defenition, by why? Is required=false is error-prone 
approach?

 

СС [~dmagda] please correct me if I'm wrong and it is popular ask coming from 
users.

> Need to add a 'required' field to the SpringResource annotation.
> 
>
> Key: IGNITE-6531
> URL: https://issues.apache.org/jira/browse/IGNITE-6531
> Project: Ignite
>  Issue Type: Improvement
>  Components: spring
>Affects Versions: 2.3
>Reporter: joungdal.nam
>Assignee: joungdal.nam
>Priority: Minor
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In my test environment, only the client is used(setForceServerMode(true)). 
> Operating environments use clients and servers.
> Sometimes Injection is not required in the test environment.
> NoSuchBeanDefinitionException is not generated by specifying a value of false.
> public @interface SpringResource {
>   
>   /**
>* Declares whether the annotated dependency is required.
>* Defaults to {@code true}.
>*/
>   boolean required() default true;
> ..
> if (!StringUtils.isEmpty(beanName)) {
>   try {
>   bean = springCtx.getBean(beanName);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }
> else {
>   try {
>   bean = springCtx.getBean(beanCls);
>   } catch(NoSuchBeanDefinitionException ne) {
>   if(annotation.required()) {
>   throw ne;
>   }
>   }
> }



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Igor Sapego (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472270#comment-16472270
 ] 

Igor Sapego commented on IGNITE-8039:
-

[~dmagda], yeah, I'm done if there are no comments from reviewers, so go ahead.

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8456) Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but persistence enabled

[Ivan Rakov (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472320#comment-16472320
 ] 

Ivan Rakov commented on IGNITE-8456:


[~SomeFire], I've looked through your changes.
I think, current message is not informative enough. My suggestions:
1. Use actual value of java.io.tmpdir property in warning message instead of 
its name.
2. Except for setting IGNITE_HOME, it's possible to change location of 
persistence folders with data storage configuration (see 
DataStorageConfiguration#walPath, DataStorageConfiguration#walArchivePath, 
DataStorageConfiguration#storagePath properties). This option should be 
mentioned in warning message as well.

> Print warning if IGNITE_HOME & WORK and persistentStoreDir is not set, but 
> persistence enabled
> --
>
> Key: IGNITE-8456
> URL: https://issues.apache.org/jira/browse/IGNITE-8456
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Ryabov Dmitrii
>Priority: Critical
>  Labels: easyfix, newbie
> Fix For: 2.6
>
>
> In method org.apache.ignite.internal.util.IgniteUtils#workDirectory
> Ignite determine Work dir to be set, same value may be used in case 
> persistence Store Folder is not set and IGNITE_HOME is not specified.
> In case work dir is not specified, temp directory is used for Ignite Work. 
> But for persistence enabled case this means user DB goes to temp folder and 
> may be removed later.
> User may be confused by this behaviour. See:
> [https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]
> and related Dev.List discussion
> [http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8471) Apache ignite for .NET has security vulnerabilities

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IGNITE-8471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472339#comment-16472339
 ] 

ASF GitHub Bot commented on IGNITE-8471:


GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/3984

IGNITE-8471 Dependencies upgraded



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-8471

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3984.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3984


commit 50c69ace2834a2ed6cbb4d828ee75a0dc157e208
Author: Andrey Gura 
Date:   2018-05-11T17:41:30Z

IGNITE-8471 Dependencies upgraded




> Apache ignite for .NET has security vulnerabilities
> ---
>
> Key: IGNITE-8471
> URL: https://issues.apache.org/jira/browse/IGNITE-8471
> Project: Ignite
>  Issue Type: Bug
>  Components: security
>Affects Versions: 2.4
>Reporter: Harendra Rai
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.5
>
>
> There are two security vulnerabilities in the latest 2.4.0 version.
>  # commons-beanutils-1.8.3.jar.  Here is the vulnerability id CVE-2014-0114 : 
>  [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114]
> *Resolution to this issue is*: All Commons BeanUtils users should upgrade to 
> the latest version >= commons-beanutils-1.9.2
>  # commons-codec-1.6.jar: Here is the vulnerability detail 
> https://issues.apache.org/jira/browse/CODEC-96
> *Resolution* *to this issue is:* To upgrade to the latest available Version 
> 1.11



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)