date:20180301


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

Alexey Kuznetsov reassigned IGNITE-7033:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Web console: Increase width of columns on admin page
> 
>
> Key: IGNITE-7033
> URL: https://issues.apache.org/jira/browse/IGNITE-7033
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> *"Last activity" and "email" columns are too narrow*



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

[jira] [Assigned] (IGNITE-7803) REST: Add support to get values inserted via API or SQL


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

Alexey Kuznetsov reassigned IGNITE-7803:


Assignee: Pavel Konstantinov  (was: Vladimir Ozerov)

[~pkonstantinov] please test in branch ignite-7803

To test:

1) Put in cache various data: int, long, String, Date, ..., POJO and after that 
get them via REST.

2) Create table with PK from ONE column and insert data and get via REST.

> REST: Add support to get values inserted via API or SQL
> ---
>
> Key: IGNITE-7803
> URL: https://issues.apache.org/jira/browse/IGNITE-7803
> Project: Ignite
>  Issue Type: Task
>  Components: rest
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Scenario 1:
>  # cache.put(1, new Person(1, Alex, 300))
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}
> Scenario 2:
>  # create table person(id integer primary key, name varchar(100), salary 
> integer);
>  # insert into person(id, name, salary) values (1, Alex, 300)
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}



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

[jira] [Commented] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

2018-03-01 Thread Valentin Kulichenko (JIRA)


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

Valentin Kulichenko commented on IGNITE-7655:
-

[~abchaudhri], do you have {{ignite-spark}} module on the classpath? This code 
compiles for me in Java:
{code:java}
String sss = IgniteDataFrameSettings.OPTION_CONFIG_FILE();{code}
Can you show the example that you tried to create and describe what is not 
working?

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Akmal Chaudhri
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



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

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()


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

Dmitriy Pavlov commented on IGNITE-7791:


[~Mmuzaf] sure, thank you

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   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.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

2018-03-01 Thread Maxim Muzafarov (JIRA)


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

Maxim Muzafarov commented on IGNITE-7791:
-

[~dpavlov] looks different. I'll try to look at and make some research tomorrow.

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   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.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>   at 
>

[jira] [Assigned] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

2018-03-01 Thread Maxim Muzafarov (JIRA)


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

Maxim Muzafarov reassigned IGNITE-7791:
---

Assignee: Maxim Muzafarov

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   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.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--

[jira] [Assigned] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

2018-03-01 Thread Denis Magda (JIRA)


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

Denis Magda reassigned IGNITE-7536:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Commented] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

2018-03-01 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-7536:
-

Put together Automatic Activation section on the page below that describes the 
concept behind the baseline topology and explains how to set it from the API 
and command line tools level:

[https://apacheignite.readme.io/v2.3/docs/cluster-activation-24]

[~pgarg], could you please finalize the doc doing the following:
 * Document `Setting Topology From Ignite Web Console` section.
 * Revisit `Setting Topology From Command Line`. Probably you have a better 
idea on how to better cover the topology management from the command line tool.
 * There are some TODOs left. Please find out how to address them. Probably you 
should ask a question on @dev for some of the points.

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Commented] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

2018-03-01 Thread Akmal Chaudhri (JIRA)


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

Akmal Chaudhri commented on IGNITE-7655:


[~NIzhikov], I have been trying to build some Java code examples, equivalent to 
your Scala code. However, I notice that:

*org.apache.ignite.spark.IgniteDataFrameSettings*

is only implemented in Scala. Is that correct please?

Thank you.

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Akmal Chaudhri
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



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

[jira] [Commented] (IGNITE-6557) Test IgniteTxRemoveTimeoutObjectsTest has flaky fails

2018-03-01 Thread Vitaliy Biryukov (JIRA)


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

Vitaliy Biryukov commented on IGNITE-6557:
--

Hi, [~agoncharuk],

Done. I also ran test 10 times on TC.

[link to 
TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2548535635395432064=testDetails_IgniteTests24Java8=pull%2F2803%2Fhead]

> Test IgniteTxRemoveTimeoutObjectsTest has flaky fails
> -
>
> Key: IGNITE-6557
> URL: https://issues.apache.org/jira/browse/IGNITE-6557
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Build log:
> {noformat}
> [org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects]
>  junit.framework.AssertionFailedError: Grids contain LockTimeoutObjects.
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.assertDoesNotContainLockTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:92)
> {noformat}



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

[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed

2018-03-01 Thread Vyacheslav Daradur (JIRA)


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

Vyacheslav Daradur commented on IGNITE-7756:


Hi [~dpavlov], {{UUID}}'s serialization format wasn't changed in this task.
{{UUID}} handled as system type since Ignite 2.0 (IGNITE-4611)
Looks like Nikolay added missed part.

Am I miss something and indexes are handled in a special way?

> Streamer fails if IgniteUuid is indexed
> ---
>
> Key: IGNITE-7756
> URL: https://issues.apache.org/jira/browse/IGNITE-7756
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
> IndexedType.
> Spark tests in IGNITE-7227 are failed because of this issue.
> Reproducer:
> {code:java}
> public void testStreamer() throws Exception {
> Ignite client = grid("client");
> CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");
> ccfg.setIndexedTypes(IgniteUuid.class, String.class);
> client.createCache(ccfg);
> try(IgniteDataStreamer cache =
> client.dataStreamer("UUID_CACHE")) {
> for(Integer i=0; i<2; i++)
> cache.addData(IgniteUuid.randomUuid(), i.toString());
> }
> }
> {code}
> Exception stack trace:
> {noformat}
> [23:43:35] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to 
> execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, 
> lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class 
> org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=57961924-82ec-4d56-81eb-1a4109a0]
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to set initial 
> value for cache entry
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
> actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
>   at

[jira] [Updated] (IGNITE-7033) Web console: Increase width of columns on admin page


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

Alexey Kuznetsov updated IGNITE-7033:
-
Component/s: wizards

> Web console: Increase width of columns on admin page
> 
>
> Key: IGNITE-7033
> URL: https://issues.apache.org/jira/browse/IGNITE-7033
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> *"Last activity" and "email" columns are too narrow*



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

[jira] [Updated] (IGNITE-7033) Web console: Increase width of columns on admin page


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

Alexey Kuznetsov updated IGNITE-7033:
-
Fix Version/s: 2.5

> Web console: Increase width of columns on admin page
> 
>
> Key: IGNITE-7033
> URL: https://issues.apache.org/jira/browse/IGNITE-7033
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> *"Last activity" and "email" columns are too narrow*



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

[jira] [Assigned] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation


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

Alexey Kuznetsov reassigned IGNITE-7462:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



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

[jira] [Updated] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation


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

Alexey Kuznetsov updated IGNITE-7462:
-
Component/s: wizards

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error


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

Dmitriy Pavlov commented on IGNITE-5553:


TC looks good, thank you. 

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-7756) Streamer fails if IgniteUuid is indexed


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

Dmitriy Pavlov commented on IGNITE-7756:


Hi [~NIzhikov], IMO we should carefuly test compatibilty here (PDS compatibilty 
suite)
and plugins functioning.

So let me run some additional tests. I will come back with results later

> Streamer fails if IgniteUuid is indexed
> ---
>
> Key: IGNITE-7756
> URL: https://issues.apache.org/jira/browse/IGNITE-7756
> Project: Ignite
>  Issue Type: Bug
>  Components: streaming
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> IgniteDataStreamer are failed to put data to the cache if IgniteUuid is 
> IndexedType.
> Spark tests in IGNITE-7227 are failed because of this issue.
> Reproducer:
> {code:java}
> public void testStreamer() throws Exception {
> Ignite client = grid("client");
> CacheConfiguration ccfg = new CacheConfiguration("UUID_CACHE");
> ccfg.setIndexedTypes(IgniteUuid.class, String.class);
> client.createCache(ccfg);
> try(IgniteDataStreamer cache =
> client.dataStreamer("UUID_CACHE")) {
> for(Integer i=0; i<2; i++)
> cache.addData(IgniteUuid.randomUuid(), i.toString());
> }
> }
> {code}
> Exception stack trace:
> {noformat}
> [23:43:35] (err) Failed to execute compound future reducer: 
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false, 
> cancelled=false, err=null, futs=[true, true]][23:43:35] (err) Failed to 
> execute compound future reducer: GridCompoundFuture [rdc=null, initFlag=1, 
> lsnrCalls=0, done=false, cancelled=false, err=null, futs=[true, true]]class 
> org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
> [node=57961924-82ec-4d56-81eb-1a4109a0]
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1900)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:344)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteException: Failed to set initial 
> value for cache entry
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:2135)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:397)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:302)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:59)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:89)
>   ... 6 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update 
> index, incorrect key class [expCls=org.apache.ignite.lang.IgniteUuid, 
> actualCls=org.apache.ignite.internal.binary.BinaryObjectImpl]
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1954)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1877)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:403)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1207)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
>   at 
>

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

2018-03-01 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin commented on IGNITE-5553:
--

[~dpavlov], I updated TC test results link.

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()


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

Dmitriy Pavlov commented on IGNITE-7791:


Hi [~Mmuzaf], is this test-fail similar to test you have recently fixed in 
[IGNITE-7789]?

> Ignite Client Nodes: failed test 
> IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
> ---
>
> Key: IGNITE-7791
> URL: https://issues.apache.org/jira/browse/IGNITE-7791
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky, success rate: 32.4%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]
> Reproducible locally.
> Test fails on waiting for disco cache content:
> {noformat}
> junit.framework.AssertionFailedError
>   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.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
>   at 
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
>   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:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This fail may be caused by another exception earlier in the log:
> {noformat}
> [2018-02-22 
> 14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
>  Failed to reinitialize local partitions (preloading will be stopped): 
> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
> minorTopVer=1], discoEvt=DiscoveryCustomEvent 
> [customMsg=CacheAffinityChangeMessage 
> [id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
> partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
> [topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
> evt=DISCOVERY_CUSTOM_EVT]
> java.lang.AssertionError: 236160867
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
>   at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at

[jira] [Commented] (IGNITE-7809) Ignite PDS 2 & PDS 2 Direct IO: stable failures of IgniteWalFlushDefaultSelfTest


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

Ilya Lantukh commented on IGNITE-7809:
--

I've fixed the cause of test failures, but they started to randomly fail with 
other kinds of problems. Will continue investigation.

> Ignite PDS 2 & PDS 2 Direct IO: stable failures of 
> IgniteWalFlushDefaultSelfTest
> 
>
> Key: IGNITE-7809
> URL: https://issues.apache.org/jira/browse/IGNITE-7809
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Probably after last WAL default changes 'IGNITE-7594 Fixed performance drop 
> after WAL optimization for FSYNC' 2 tests in 2 build configs began to fail
>Ignite PDS 2 (Direct IO) [ tests 2 ]  
>  IgnitePdsNativeIoTestSuite2: 
> IgniteWalFlushDefaultSelfTest.testFailAfterStart (fail rate 13,0%) 
>  IgnitePdsNativeIoTestSuite2: 
> IgniteWalFlushDefaultSelfTest.testFailWhileStart (fail rate 13,0%) 
>Ignite PDS 2 [ tests 2 ]  
>  IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailAfterStart 
> (fail rate 8,4%) 
>  IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailWhileStart 
> (fail rate 8,4%) 



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error


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

Dmitriy Pavlov commented on IGNITE-5553:


Hi [~xtern], could you provide link to TC run all?

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Commented] (IGNITE-6557) Test IgniteTxRemoveTimeoutObjectsTest has flaky fails

2018-03-01 Thread Alexey Goncharuk (JIRA)


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

Alexey Goncharuk commented on IGNITE-6557:
--

Hi [~VitaliyB],

Can you please replace sleep() with GridTestUtils.waitForCondition(, getTestTimeout()) and then assert that wait returned true? The 
sleep() is quite unreliable and sensitive to timeout processor changes.

> Test IgniteTxRemoveTimeoutObjectsTest has flaky fails
> -
>
> Key: IGNITE-6557
> URL: https://issues.apache.org/jira/browse/IGNITE-6557
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Build log:
> {noformat}
> [org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects]
>  junit.framework.AssertionFailedError: Grids contain LockTimeoutObjects.
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.assertDoesNotContainLockTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteTxRemoveTimeoutObjectsTest.testTxRemoveTimeoutObjects(IgniteTxRemoveTimeoutObjectsTest.java:92)
> {noformat}



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

[jira] [Updated] (IGNITE-7623) Thin client Java API - async API

2018-03-01 Thread Alexey Kukushkin (JIRA)


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

Alexey Kukushkin updated IGNITE-7623:
-
Description: Implement Async version of all the Java thin client APIs.   
(was: Implement Async version of all the client APIs. This is a big task - 
consider splitting it into multiple tasks. )

> Thin client Java API - async API
> 
>
> Key: IGNITE-7623
> URL: https://issues.apache.org/jira/browse/IGNITE-7623
> Project: Ignite
>  Issue Type: Task
>  Components: clients
>Reporter: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>   Original Estimate: 0.4h
>  Remaining Estimate: 0.4h
>
> Implement Async version of all the Java thin client APIs. 



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

[jira] [Updated] (IGNITE-7623) Thin client Java API - async API

2018-03-01 Thread Alexey Kukushkin (JIRA)


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

Alexey Kukushkin updated IGNITE-7623:
-
Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-7421)

> Thin client Java API - async API
> 
>
> Key: IGNITE-7623
> URL: https://issues.apache.org/jira/browse/IGNITE-7623
> Project: Ignite
>  Issue Type: Task
>  Components: clients
>Reporter: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>   Original Estimate: 0.4h
>  Remaining Estimate: 0.4h
>
> Implement Async version of all the client APIs. This is a big task - consider 
> splitting it into multiple tasks. 



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

[jira] [Commented] (IGNITE-7789) Ignite Client Nodes: failed test IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()


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

ASF GitHub Bot commented on IGNITE-7789:


Github user asfgit closed the pull request at:

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


> Ignite Client Nodes: failed test 
> IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()
> --
>
> Key: IGNITE-7789
> URL: https://issues.apache.org/jira/browse/IGNITE-7789
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky, success rate: 47.9%, test history is 
> [here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3790177050933093125=testDetails].
> May fail in two different ways.
> *1 Assertion error in test code*
> Rarely reproducible locally.
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [1]
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3073)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:130)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:285)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:280)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
> at java.lang.Thread.run(Thread.java:745)
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
> update keys on primary node.
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKeys(UpdateErrors.java:124)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:342)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1785)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3055)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
> ... 12 more
> Suppressed: java.lang.AssertionError: Assertion error on search row: 
>

[jira] [Updated] (IGNITE-7517) Get rid of org.jsr166.ConcurrentLinkedDeque8

2018-03-01 Thread Andrey Gura (JIRA)


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

Andrey Gura updated IGNITE-7517:

Description: Replace usages of {{ConcurrentLinkedDeque8}} by 
{{ConcurrentLinkedDeque}} Java 8 implementation.

> Get rid of org.jsr166.ConcurrentLinkedDeque8
> 
>
> Key: IGNITE-7517
> URL: https://issues.apache.org/jira/browse/IGNITE-7517
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Replace usages of {{ConcurrentLinkedDeque8}} by {{ConcurrentLinkedDeque}} 
> Java 8 implementation.



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

[jira] [Updated] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-03-01 Thread Andrey Gura (JIRA)


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

Andrey Gura updated IGNITE-7831:

Fix Version/s: 2.5

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



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

[jira] [Created] (IGNITE-7860) JDBC thin driver: set default socket buffer sizes to greater value

Vladimir Ozerov created IGNITE-7860:
---

 Summary: JDBC thin driver: set default socket buffer sizes to 
greater value
 Key: IGNITE-7860
 URL: https://issues.apache.org/jira/browse/IGNITE-7860
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Affects Versions: 2.3, 2.4
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 2.5


Currently they are set to zero, meaning that OS will use it's default. But 
tyically these defaults are too pessimistic. Let's set them to 64Kb.



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

[jira] [Comment Edited] (IGNITE-7421) Thin client Java API - data grid API


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

Vladimir Ozerov edited comment on IGNITE-7421 at 3/1/18 1:57 PM:
-

[~kukushal], my comments:
1) {{Factory}} - let's use {{javax.cache.configuration.Factory}} instead of our 
own interface to avoid duplication; we already do this in many places of our 
configuration
2) {{IgniteClientConfiguration}}:
- by convention we put all top-level configuration classes to 
{{org.apache.ignite.configuration}}
- we set {{tcpNoDelay}} to {{true}} by default in all other places, let's do 
the same here
- let's set {{sslProto}} to {{TLS}} by default explicitly instead of doing this 
somewhere deep inside internal classes
- {{credentialsProvider}} factory looks like an overkill for me; plain username 
and password strings would be enough, the easier - the better (that is, even 
{{Credentials}} class could be removed)
- during JDBC/ODBC development we revealed that setting socket buffer sizes to 
OS defaults are typically bad idea because these buffers are too small. Let's 
set them to 32Kb by default (we do the same for {{TcpCommunicationSpi}})
- there should be only default constructor; the rest things are set through 
settter, this is our product-wide conventions
- addresses should be stored as {{String[]}}, not {{List}}, 
relevant setter should accept vararg ({{setAddresses(String...)}}) - this is 
proven to be more convenient for users; all further address resolution should 
happen outside of configuration class
- configuration should be {{Serializable}} for the sake of user convenience
- I think it is better to expose {{sslProtocol}} as enum rather than as string; 
without this user will not know the list of possible values without reading 
documentation
- instead of having different setters for host and port, there should be only 
one setter {{setAddresses}}. This is how we defined endpoints in other parts of 
the system. There should be no defaults - at least one address should always be 
provided explicitly

3) {{Credentials}} - not sure we need it at all
4) {{SystemEvent}}  - we are going to design common error code glossary soon. 
Let's avoid doing this for separate components without seeing the whole 
picture. String error message would be enough for now
5) {{ProtocolVersion}} is purely internal thing and should not be exposed to 
public API
6) {{SslMode}} - let's rename members to {{REQUIRE*D*}} and {{DISABLE*D*}}
7) I do not think we need {{IgniteClientError}}, {{IgniteProtocolError}}, 
{{IgniteProtocolVersionMismatch}} and {{IgniteServerError}} for now, 
{{IgniteClientException}} should be enough. Moreover, they are not "errors" in 
general sense, but "exceptions". Instead, all these cases should be expressed 
through a sensible error messages.
8) We need to have common prefixes for all public classes, {{Client}} in this 
case; e.g.: {{ClientException}}, {{ClientConfiguration}}, etc.
9) {{IgniteUnavailableException}} - please confirm that exceptions from all 
provided addresses are tracked properly here with help of "supressed excpetion" 
Java feature
10) {{CacheClientConfiguration}}:
- there should be only default constructor
- class should be {{Serializable}}
- please take all defaults directly from {{CacheConfiguration}}; this way, once 
default is changed in CacheConfiguration, it will be applied to 
CacheClientConfiguration automcatically, what would help us to maintain API 
consistency
- {{setKeyConfiguration}}, {{setQueryEntities}} - let's use varargs here

11) {{IgniteClient.start}} - {{Ignition}} class is a better place for this 
method - you can create both a node and a client from a single place. This is 
now it is implemented in .NET (and in Hazelcast)
12) {{IgniteClient.nonQuery}} - let's remove this for now. We will design new 
SQL API in future and would definitely looks different and located in different 
place
13) {{CacheClient.cacheId}} - this should not be exposed to user API, cache ID 
is internal thing


was (Author: vozerov):
[~kukushal], my comments:
1) {{Factory}} - let's use {{javax.cache.configuration.Factory}} instead of our 
own interface to avoid duplication; we already do this in many places of our 
configuration
2) {{IgniteClientConfiguration}}:
- by convention we put all top-level configuration classes to 
{{org.apache.ignite.configuration}}
- we set {{tcpNoDelay}} to {{true}} by default in all other places, let's do 
the same here
- let's set {{sslProto}} to {{TLS}} by default explicitly instead of doing this 
somewhere deep inside internal classes
- {{credentialsProvider}} factory looks like an overkill for me; plain username 
and password strings would be enough, the easier - the better (that is, even 
{{Credentials}} class could be removed)
- during JDBC/ODBC development we revealed that setting socket buffer sizes to 
OS defaults are typically bad idea

[jira] [Updated] (IGNITE-7859) SQL streaming support via native API

2018-03-01 Thread Alexander Paschenko (JIRA)


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

Alexander Paschenko updated IGNITE-7859:

Component/s: sql

> SQL streaming support via native API
> 
>
> Key: IGNITE-7859
> URL: https://issues.apache.org/jira/browse/IGNITE-7859
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> In addition to streaming via thin JDBC driver, ability to run same {{SET 
> STREAMING}} command should be added to cache API.



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

[jira] [Updated] (IGNITE-7859) SQL streaming support via native API

2018-03-01 Thread Alexander Paschenko (JIRA)


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

Alexander Paschenko updated IGNITE-7859:

Fix Version/s: 2.5

> SQL streaming support via native API
> 
>
> Key: IGNITE-7859
> URL: https://issues.apache.org/jira/browse/IGNITE-7859
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
>
> In addition to streaming via thin JDBC driver, ability to run same {{SET 
> STREAMING}} command should be added to cache API.



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

[jira] [Created] (IGNITE-7859) SQL streaming support via native API

2018-03-01 Thread Alexander Paschenko (JIRA)

Alexander Paschenko created IGNITE-7859:
---

 Summary: SQL streaming support via native API
 Key: IGNITE-7859
 URL: https://issues.apache.org/jira/browse/IGNITE-7859
 Project: Ignite
  Issue Type: Task
Reporter: Alexander Paschenko


In addition to streaming via thin JDBC driver, ability to run same {{SET 
STREAMING}} command should be added to cache API.



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

[jira] [Commented] (IGNITE-7421) Thin client Java API - data grid API


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

Vladimir Ozerov commented on IGNITE-7421:
-

[~kukushal], my comments:
1) {{Factory}} - let's use {{javax.cache.configuration.Factory}} instead of our 
own interface to avoid duplication; we already do this in many places of our 
configuration
2) {{IgniteClientConfiguration}}:
- by convention we put all top-level configuration classes to 
{{org.apache.ignite.configuration}}
- we set {{tcpNoDelay}} to {{true}} by default in all other places, let's do 
the same here
- let's set {{sslProto}} to {{TLS}} by default explicitly instead of doing this 
somewhere deep inside internal classes
- {{credentialsProvider}} factory looks like an overkill for me; plain username 
and password strings would be enough, the easier - the better (that is, even 
{{Credentials}} class could be removed)
- during JDBC/ODBC development we revealed that setting socket buffer sizes to 
OS defaults are typically bad idea because these buffers are too small. Let's 
set them to 32Kb by default (we do the same for {{TcpCommunicationSpi}})
- there should be only default constructor; the rest things are set through 
settter, this is our product-wide conventions
- addresses should be stored as {{String[]}}, not {{List}}, 
relevant setter should accept vararg ({{setAddresses(String...)}}) - this is 
proven to be more convenient for users; all further address resolution should 
happen outside of configuration class
- configuration should be {{Serializable}} for the sake of user convenience
- I think it is better to expose {{sslProtocol}} as enum rather than as string; 
without this user will not know the list of possible values without reading 
documentation
- instead of having different setters for host and port, there should be only 
one setter {{setAddresses}}. This is how we defined endpoints in other parts of 
the system. There should be no defaults - at least one address should always be 
provided explicitly
3) {{Credentials}} - not sure we need it at all
4) {{SystemEvent}}  - we are going to design common error code glossary soon. 
Let's avoid doing this for separate components without seeing the whole 
picture. String error message would be enough for now
5) {{ProtocolVersion}} is purely internal thing and should not be exposed to 
public API
6) {{SslMode}} - let's rename members to {{REQUIRE*D*}} and {{DISABLE*D*}}
7) I do not think we need {{IgniteClientError}}, {{IgniteProtocolError}}, 
{{IgniteProtocolVersionMismatch}} and {{IgniteServerError}} for now, 
{{IgniteClientException}} should be enough. Moreover, they are not "errors" in 
general sense, but "exceptions". Instead, all these cases should be expressed 
through a sensible error messages.
8) We need to have common prefixes for all public classes, {{Client}} in this 
case; e.g.: {{ClientExcpetion}}, {{ClientConfiguratoin}}, etc.
9) {{IgniteUnavailableException}} - please confirm that exceptions from all 
provided addresses are tracked properly here with help of "supressed excpetion" 
Java feature
10) {{CacheClientConfiguration}}:
- there should be only default constructor
- class should be {{Serializable}}
- please take all defaults directly from {{CacheConfiguration}}; this way, once 
default is changed in CacheConfiguration, it will be applied to 
CacheClientConfiguration automcatically, what would help us to maintain API 
consistency
- {{setKeyConfiguration}}, {{setQueryEntities}} - let's use varargs here
11) {{IgniteClient.start}} - {{Ignition}} class is a better place for this 
method - you can create both a node and a client from a single place. This is 
now it is implemented in .NET (and in Hazelcast)
12) {{IgniteClient.nonQuery}} - let's remove this for now. We will design new 
SQL API in future and would definitely looks different and located in different 
place
13) {{CacheClient.cacheId}} - this should not be exposed to user API, cache ID 
is internal thing

> Thin client Java API - data grid API
> 
>
> Key: IGNITE-7421
> URL: https://issues.apache.org/jira/browse/IGNITE-7421
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kukushkin
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: data, java, thin
>
> Implement below Java bindings for the thin client protocol. The client 
> configuration must support failover and encryption.
> Cache
>      JCache (limited)
>          getName(): String
>          put(key, val)
>          get(key): V
>          getAll(keys: Set): Map
>          containsKey(key): boolean
>          getAndPut(key, val): V
>          getAndReplace(key, val): V
>          getAndRemove(key): V
>          putIfAbsent
>          replace(key, val)
>          replace(key,

[jira] [Comment Edited] (IGNITE-7421) Thin client Java API - data grid API


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

Vladimir Ozerov edited comment on IGNITE-7421 at 3/1/18 1:53 PM:
-

[~kukushal], my comments:
1) {{Factory}} - let's use {{javax.cache.configuration.Factory}} instead of our 
own interface to avoid duplication; we already do this in many places of our 
configuration
2) {{IgniteClientConfiguration}}:
- by convention we put all top-level configuration classes to 
{{org.apache.ignite.configuration}}
- we set {{tcpNoDelay}} to {{true}} by default in all other places, let's do 
the same here
- let's set {{sslProto}} to {{TLS}} by default explicitly instead of doing this 
somewhere deep inside internal classes
- {{credentialsProvider}} factory looks like an overkill for me; plain username 
and password strings would be enough, the easier - the better (that is, even 
{{Credentials}} class could be removed)
- during JDBC/ODBC development we revealed that setting socket buffer sizes to 
OS defaults are typically bad idea because these buffers are too small. Let's 
set them to 32Kb by default (we do the same for {{TcpCommunicationSpi}})
- there should be only default constructor; the rest things are set through 
settter, this is our product-wide conventions
- addresses should be stored as {{String[]}}, not {{List}}, 
relevant setter should accept vararg ({{setAddresses(String...)}}) - this is 
proven to be more convenient for users; all further address resolution should 
happen outside of configuration class
- configuration should be {{Serializable}} for the sake of user convenience
- I think it is better to expose {{sslProtocol}} as enum rather than as string; 
without this user will not know the list of possible values without reading 
documentation
- instead of having different setters for host and port, there should be only 
one setter {{setAddresses}}. This is how we defined endpoints in other parts of 
the system. There should be no defaults - at least one address should always be 
provided explicitly

3) {{Credentials}} - not sure we need it at all
4) {{SystemEvent}}  - we are going to design common error code glossary soon. 
Let's avoid doing this for separate components without seeing the whole 
picture. String error message would be enough for now
5) {{ProtocolVersion}} is purely internal thing and should not be exposed to 
public API
6) {{SslMode}} - let's rename members to {{REQUIRE*D*}} and {{DISABLE*D*}}
7) I do not think we need {{IgniteClientError}}, {{IgniteProtocolError}}, 
{{IgniteProtocolVersionMismatch}} and {{IgniteServerError}} for now, 
{{IgniteClientException}} should be enough. Moreover, they are not "errors" in 
general sense, but "exceptions". Instead, all these cases should be expressed 
through a sensible error messages.
8) We need to have common prefixes for all public classes, {{Client}} in this 
case; e.g.: {{ClientExcpetion}}, {{ClientConfiguratoin}}, etc.
9) {{IgniteUnavailableException}} - please confirm that exceptions from all 
provided addresses are tracked properly here with help of "supressed excpetion" 
Java feature
10) {{CacheClientConfiguration}}:
- there should be only default constructor
- class should be {{Serializable}}
- please take all defaults directly from {{CacheConfiguration}}; this way, once 
default is changed in CacheConfiguration, it will be applied to 
CacheClientConfiguration automcatically, what would help us to maintain API 
consistency
- {{setKeyConfiguration}}, {{setQueryEntities}} - let's use varargs here

11) {{IgniteClient.start}} - {{Ignition}} class is a better place for this 
method - you can create both a node and a client from a single place. This is 
now it is implemented in .NET (and in Hazelcast)
12) {{IgniteClient.nonQuery}} - let's remove this for now. We will design new 
SQL API in future and would definitely looks different and located in different 
place
13) {{CacheClient.cacheId}} - this should not be exposed to user API, cache ID 
is internal thing


was (Author: vozerov):
[~kukushal], my comments:
1) {{Factory}} - let's use {{javax.cache.configuration.Factory}} instead of our 
own interface to avoid duplication; we already do this in many places of our 
configuration
2) {{IgniteClientConfiguration}}:
- by convention we put all top-level configuration classes to 
{{org.apache.ignite.configuration}}
- we set {{tcpNoDelay}} to {{true}} by default in all other places, let's do 
the same here
- let's set {{sslProto}} to {{TLS}} by default explicitly instead of doing this 
somewhere deep inside internal classes
- {{credentialsProvider}} factory looks like an overkill for me; plain username 
and password strings would be enough, the easier - the better (that is, even 
{{Credentials}} class could be removed)
- during JDBC/ODBC development we revealed that setting socket buffer sizes to 
OS defaults are typically bad idea

[jira] [Commented] (IGNITE-7253) JDBC thin driver: introduce streaming mode


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

ASF GitHub Bot commented on IGNITE-7253:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-7253



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

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

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

https://github.com/apache/ignite/pull/3591.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 #3591


commit 4477a14a7820a673e1d00040fbef25511e149d79
Author: Alexander Paschenko 
Date:   2018-02-28T09:16:48Z

IGNITE-7253 Initial streaming state

commit 3502928dafc2aa3a49e58ef703b6fc2d2f02458b
Author: Alexander Paschenko 
Date:   2018-02-28T12:36:39Z

IGNITE-7253 SET keyword

commit 6407a53d75d052e7d00d361e20372688acc20ed8
Author: Alexander Paschenko 
Date:   2018-02-28T15:57:20Z

IGNITE-7253 SET STREAMING params

commit 4945069f44d81038880f0444e85ae19b5d50b764
Author: Alexander Paschenko 
Date:   2018-03-01T09:13:46Z

IGNITE-7253 Removed streaming parameters from connection string

commit b7d9c7d0cc36f5019bbf200c0ef2ac5094fae01a
Author: Alexander Paschenko 
Date:   2018-03-01T13:49:49Z

IGNITE-7253 finishing.

commit 5ed144b471baec048d8f2423122c2ad73c96a43c
Author: Alexander Paschenko 
Date:   2018-03-01T13:51:05Z

IGNITE-7253 fixed comment.




> JDBC thin driver: introduce streaming mode
> --
>
> Key: IGNITE-7253
> URL: https://issues.apache.org/jira/browse/IGNITE-7253
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IGNITE_7253.patch
>
>
> Should be done after IGNITE-6022. We should allow optional streaming mode for 
> JDBC driver. In this mode only INSERTs without SELECT should be possible. All 
> other DML operations should throw an exception. 
> Design considerations:
> 1) Add command {{SET STREAMING=1|ON|0|OFF}} which will enable or disable 
> streaming for connection.
> 2) Add command {{STREAMER FLUSH}} which will force data flush.
> 3) Only INSERT without SELECT works, all other DML statements should throw an 
> exception
> 4) It should be possible to stream into several tables simultaneously (i.e. 
> several streamers could be opened)
> 5) Any DDL statement should force flush of all currently opened streamers.



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

[jira] [Commented] (IGNITE-5580) Improve node failure cause information

2018-03-01 Thread Alexey Goncharuk (JIRA)


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

Alexey Goncharuk commented on IGNITE-5580:
--

[~SomeFire], I think this kind of logging is good enough until the 
troubleshooting logger is implemented.

[~agura] Can you please review the changes and check if it makes sense to 
include them into one of the stability IEPs?

> Improve node failure cause information
> --
>
> Key: IGNITE-5580
> URL: https://issues.apache.org/jira/browse/IGNITE-5580
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>Priority: Major
>  Labels: observability
> Fix For: 2.5
>
>
> When a node fails, we do not print out any information about the root cause 
> of this failure. This makes it extremely hard to investigate the failure 
> causes - I need to find a previous node for the failed node and check the 
> logs on the previous node.
> I suggest that we add extensive information about the reason of the node 
> failure and the sequence of events that led to this, e.g.:
> [time] [NODE] Sending a message to next node - failed _because_ - write 
> timeout, read timeout, ...?
> [time] [NODE] Connection check - failed - why? Connection refused, handshake 
> timed out, ...?
> ...
> [time] [NODE] Decided to drop the node because of the sequence above
> Maybe we do not need to print out this information always, but we do need 
> this when troubleshooting logger is enabled.
> Also, DiscoverySpi should collect a set of latest important events and dump 
> these events in case of local node segmentation. This will allow users to 
> match the events in the cluster and events on local node and get to the 
> bottom of the failure.



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

[jira] [Assigned] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

2018-03-01 Thread Denis Mekhanikov (JIRA)


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

Denis Mekhanikov reassigned IGNITE-7794:


Assignee: Denis Mekhanikov

> Marshaller mappings are not saved to disk on joining nodes
> --
>
> Key: IGNITE-7794
> URL: https://issues.apache.org/jira/browse/IGNITE-7794
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.5
>
> Attachments: GridMarshallerMappingConsistencyTest.java
>
>
> Find attached test class.
> When a node connects to a cluster, that already has some marshaller mappings, 
> they are not saved to disk on the joining node. It may result in "Unknown 
> pair" error, if a cluster has persistence enabled, and a nodes without needed 
> mappings start and try to read persisted data.



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

[jira] [Comment Edited] (IGNITE-7704) Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations

2018-03-01 Thread Alexey Popov (JIRA)

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

Alexey Popov edited comment on IGNITE-7704 at 3/1/18 1:34 PM:
--

Sample description:

GLOBAL:

IgniteConfiguration.setNetworkTimeout:
It is a global timeout for high-level operations where a network is involved.
For instance, IgniteMessaging delivery uses this timeout or DiscoverySpi
handshake.

IgniteConfiguration.setFailureDetectionTimeout:
It is a global timeout for detecting failures at IgniteSpi implementations
(including DiscoverySpi and CommunicationSpi).
The failure detection algorithm actually limits a range of simple network
operations related to a single logical operation (for instance, a reliable
delivery of some DiscoverySpi message within a cluster).
Failure detection timeout is a cumulative timeout for a socket connection,
sending and receiving data bytes and all possible socket retries (if some
failure happens).
This timeout is intended to simplify the failure detection condition from a
user perspective.

IgniteConfiguration.setClientFailureDetectionTimeout: - it is a special case
for DiscoverySpi client-node Ignite.

TCP DISCOVERY SPI:

If you need more control over failure detection algorithm for TcpDiscoverySpi
you can explicitly use the following low-level options (that will disable
failureDetectoinTimeout logic):

1. TcpDiscoverySpi.setConnectTimeout - socket connection timeout
2. TcpDiscoverySpi.setReconnectCount - number of reconnect attempts used when
establishing connection with the remote node and sending messages to it
3. TcpDiscoverySpi.setSocketTimeout - socket write timeout. The write operation
will be repeated getReconnectCount() times if it exceeds this timeout
4. TcpDiscoverySpi.setAckTimeout - message acknowledgment timeout. If a message
acknowledgment is not received within this timeout, sending is considered as
failed and SPI will try to repeat send operation. It is automatically doubled
for simultaneous retries up to getMaxAckTimeout value.
5. TcpDiscoverySpi.setMaxAckTimeout - maximum connection timeout, if the
getAckTimeout reaches getMaxAckTimeout then SPI give up sending retries

Another important TcpDiscoverySpi timeouts:

TcpDiscoverySpi.setJoinTimeout - It is a timeout for join process when a
new/restarted node joins a cluster. The node tries to connect to all available
IP addresses provided by ipFinder within this timeout.
If the timeout is exceeded, the node will give up and throw an exception from
Ignition.start().

TcpDiscoverySpi.setNetworkTimeout - timeout for high-level operations like
handshake. It looks like it should be deprecated and the
IgniteConfiguration.getNetworkTimeout should be used here.

TCP COMMUNICATION SPI:

If you need more control over failure detection algorithm for
TcpCommunicationSpi you can explicitly use the following low-level options
(that will disable failureDetectoinTimeout logic):

1. TcpCommunicationSpi.setConnectTimeout - socket connection timeout, will be
automatically doubled for simultaneous retries (up to getReconnectCount)
related to a single logical operation
2. TcpCommunicationSpi.setMaxConnectTimeout - maximum connection timeout, the
higher limit of getReconnectCount-times doubled getConnectTimeout
3. TcpCommunicationSpi.setReconnectCount - number of reconnect attempts used
when establishing connection with the remote node and sending messages to it

Another important TcpCommunicationSpi timeouts:

TcpDiscoverySpi.setSocketWriteTimeout - timeout to send a message.
TcpDiscoverySpi.setIdleConnectionTimeout - maximum idle connection timeout upon
which a connection will be closed.

was (Author: alexey.tank2):
Sample description:

GLOBAL:

IgniteConfiguration.setClientFailureDetectionTimeout: - it is a special case
for DiscoverySpi client-node Ignite.

TCP DISCOVERY SPI:

If you need more control over failure detection algorithm for TcpDiscoverySpi
you can explicitly use the following low-level options (that will disable

[jira] [Created] (IGNITE-7858) "Cannot find cache" error for existing cache on unstable topology

2018-03-01 Thread Alexey Kukushkin (JIRA)

Alexey Kukushkin created IGNITE-7858:


 Summary: "Cannot find cache" error for existing cache on unstable 
topology 
 Key: IGNITE-7858
 URL: https://issues.apache.org/jira/browse/IGNITE-7858
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Java thin client high availability test fails with "Cannot find cache" error 
for existing cache.

Reproducer:

git fetch professional
git checkout ignite-7421
Open org.apache.ignite.thinclient.system.ReliabilityTest and search for "TODO: 
fix CACHE_DOES_NOT_EXIST server error". Then remove the try/catch block leaving 
only assertion call.
Run test testFailover



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

[jira] [Assigned] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

2018-03-01 Thread Aleksey Plekhanov (JIRA)


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

Aleksey Plekhanov reassigned IGNITE-7831:
-

Assignee: Aleksey Plekhanov

> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



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

[jira] [Updated] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

2018-03-01 Thread Pavel Kovalenko (JIRA)


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

Pavel Kovalenko updated IGNITE-7467:

Attachment: partitions_update_counters_and_sizes_affected_tests

> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Attachments: partitions_update_counters_and_sizes_affected_tests
>
>
> In Ignite we heavily rely on an invariant that under no load owning 
> partitions will have equal sizes and, more importantly, equal partition 
> counters. This invariant becomes even more important when persistence is 
> enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.



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

[jira] [Updated] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence


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

Ilya Lantukh updated IGNITE-7831:
-
Description: 
There are a few places in our code where we explicitly throw AssertionErrors 
due to inability to correctly read data from persistence and many more places 
where we make assertions based on read values.

Assertions are used to indicate problems in internal logic, while persistence 
might also get corrupted by various external reasons. It also makes uniform 
handling of such issues considerably harder, because exception handling logic 
in Ignite ignores Errors. If we want to improve stability and minimize 
consequenses of pesistence corruption, we should replace all those 
AssertionErrors and asserts with Exceptions, so that current exception handling 
mechanisms could be reduce. In a number of situations it means that instead of 
causing cluster-wide hang-up problematic node will be automatically killed.

  was:Assertions are used to indicate problems in internal logic, while 
persistence might also get corrupted by various external reasons. It also makes 
uniform handling of such issues considerably harder, because most places of 
code in Ignite ignore Errors.


> Throw Exceptions instead of AssertionErrors when reading from corrupted 
> persistence
> ---
>
> Key: IGNITE-7831
> URL: https://issues.apache.org/jira/browse/IGNITE-7831
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Priority: Major
>  Labels: iep-14
>
> There are a few places in our code where we explicitly throw AssertionErrors 
> due to inability to correctly read data from persistence and many more places 
> where we make assertions based on read values.
> Assertions are used to indicate problems in internal logic, while persistence 
> might also get corrupted by various external reasons. It also makes uniform 
> handling of such issues considerably harder, because exception handling logic 
> in Ignite ignores Errors. If we want to improve stability and minimize 
> consequenses of pesistence corruption, we should replace all those 
> AssertionErrors and asserts with Exceptions, so that current exception 
> handling mechanisms could be reduce. In a number of situations it means that 
> instead of causing cluster-wide hang-up problematic node will be 
> automatically killed.



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

[jira] [Commented] (IGNITE-7565) Remove IgniteSet from heap

2018-03-01 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin commented on IGNITE-7565:
--

Hello, [~sbberkov].

This issue was raised on devlist and 
[discussion|http://apache-ignite-developers.2346864.n4.nabble.com/IgniteSet-implementation-changes-required-td23783.html]
 ended up with the following.
Current implementation is good enough for small sets. As for the large sets we 
need to implement Set adapter on IgniteCache 
([IGNITE-7823|https://issues.apache.org/jira/browse/IGNITE-7823]).

> Remove IgniteSet from heap
> --
>
> Key: IGNITE-7565
> URL: https://issues.apache.org/jira/browse/IGNITE-7565
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.2
>Reporter: Alexander Belyak
>Assignee: Pavel Pereslegin
>Priority: Major
>
> IgniteSet store all data in durable memory and in java heap. It's not good 
> for big clusters and big sets, so we need to remove values from heap.



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

[jira] [Assigned] (IGNITE-7823) Enrich IgniteCache with asSet method

2018-03-01 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin reassigned IGNITE-7823:


Assignee: Pavel Pereslegin

> Enrich IgniteCache with asSet method
> 
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.5
>
>
> Existing {{IgniteSet}} datastructure is good enough for small sets. For big 
> sets it's too expensive to maintain redundant onheap data copies. Thus we'd 
> better to add new {{IgniteCache::asSet}} method returning set adapter to 
> existing cache. The difference between these two kinds of sets should be 
> properly documented afterwards. 



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

[jira] [Assigned] (IGNITE-5357) Replicated cache reads load balancing.

2018-03-01 Thread Vyacheslav Daradur (JIRA)


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

Vyacheslav Daradur reassigned IGNITE-5357:
--

Assignee: Vyacheslav Daradur  (was: Lukjanenko Dmitry)

> Replicated cache reads load balancing.
> --
>
> Key: IGNITE-5357
> URL: https://issues.apache.org/jira/browse/IGNITE-5357
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Currently all read requests from client node to replicated cache will go 
> through primary node for key.
> Need to select random affinity node in topology and send request here (only 
> if readFromBackups=true)
> If where are server nodes collocated on same host with client, must select 
> target node from them.



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC


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

ASF GitHub Bot commented on IGNITE-7717:


Github user asfgit closed the pull request at:

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


> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



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

[jira] [Created] (IGNITE-7857) Extend IgniteWalFlushMultiNodeFailoverAbstractSelfTest to cover MMAP mode

Ilya Lantukh created IGNITE-7857:


 Summary: Extend IgniteWalFlushMultiNodeFailoverAbstractSelfTest to 
cover MMAP mode
 Key: IGNITE-7857
 URL: https://issues.apache.org/jira/browse/IGNITE-7857
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh






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

[jira] [Comment Edited] (IGNITE-7848) On Date type mismatch DDL functionality is broken

2018-03-01 Thread Sergey Kalashnikov (JIRA)


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

Sergey Kalashnikov edited comment on IGNITE-7848 at 3/1/18 12:32 PM:
-

[~andmed], I have looked into this issue and unfortunately this is kind of 
expected behaviour now. Current implementation of DDL ADD and DROP column has a 
limitation that it only update meta and does not modify the data itslef. So the 
CREATE INDEX and SELECT in your test fail because they see old field data which 
are of wrong type. With current implementation you need to clean the old fields 
manually first (NULL them with update f.ex).


was (Author: skalashnikov):
[~andmed], I have looked into this issue and unfortunately this is kind of 
expected behaviour now. Current implementation of DDL ADD and DROP column has a 
limitation does not modify the data. So the CREATE INDEX and SELECT in your 
test fail because they see old field data which are of wrong type. With current 
implementation you need to clean the old fields manually first (NULL them with 
update f.ex).

> On Date type mismatch DDL functionality is broken
> -
>
> Key: IGNITE-7848
> URL: https://issues.apache.org/jira/browse/IGNITE-7848
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: DateCannotBeCastTest.java
>
>
> when Date type in value object is originally set as java.util.Date, then 
> after ADD COLUMN IF NOT EXISTS and CREATE INDEX on this field, basic SQL 
> functionality (SELECT) is broken



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

[jira] [Commented] (IGNITE-7848) On Date type mismatch DDL functionality is broken

2018-03-01 Thread Sergey Kalashnikov (JIRA)


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

Sergey Kalashnikov commented on IGNITE-7848:


[~andmed], I have looked into this issue and unfortunately this is kind of 
expected behaviour now. Current implementation of DDL ADD and DROP column has a 
limitation does not modify the data. So the CREATE INDEX and SELECT in your 
test fail because they see old field data which are of wrong type. With current 
implementation you need to clean the old fields manually first (NULL them with 
update f.ex).

> On Date type mismatch DDL functionality is broken
> -
>
> Key: IGNITE-7848
> URL: https://issues.apache.org/jira/browse/IGNITE-7848
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: DateCannotBeCastTest.java
>
>
> when Date type in value object is originally set as java.util.Date, then 
> after ADD COLUMN IF NOT EXISTS and CREATE INDEX on this field, basic SQL 
> functionality (SELECT) is broken



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

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

2018-03-01 Thread Pavel Vinokurov (JIRA)


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

Pavel Vinokurov commented on IGNITE-7718:
-

[~dpavlov], 

I merged master into my branch. 

Tests look stable now.

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=projectOverview_IgniteTests24Java8=pull%2F3534%2Fmerge

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



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

[jira] [Created] (IGNITE-7856) ODBC: Support COPY command

Vladimir Ozerov created IGNITE-7856:
---

 Summary: ODBC: Support COPY command
 Key: IGNITE-7856
 URL: https://issues.apache.org/jira/browse/IGNITE-7856
 Project: Ignite
  Issue Type: Task
  Components: odbc
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.5


Need to do that in the same way as it is implemented in JDBC driver.



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

[jira] [Created] (IGNITE-7855) ODBC: Supoprt streaming mode

Vladimir Ozerov created IGNITE-7855:
---

 Summary: ODBC: Supoprt streaming mode
 Key: IGNITE-7855
 URL: https://issues.apache.org/jira/browse/IGNITE-7855
 Project: Ignite
  Issue Type: Task
  Components: odbc
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.5


We need to support streaming mode in the same way it is done for JDBC.



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

[jira] [Created] (IGNITE-7854) Java thin client: add username/password authentication support

Vladimir Ozerov created IGNITE-7854:
---

 Summary: Java thin client: add username/password authentication 
support
 Key: IGNITE-7854
 URL: https://issues.apache.org/jira/browse/IGNITE-7854
 Project: Ignite
  Issue Type: Task
  Components: thin client
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
 Fix For: 2.5






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

[jira] [Created] (IGNITE-7853) .NET thin client: supoprt username/password authentication

Vladimir Ozerov created IGNITE-7853:
---

 Summary: .NET thin client: supoprt username/password authentication
 Key: IGNITE-7853
 URL: https://issues.apache.org/jira/browse/IGNITE-7853
 Project: Ignite
  Issue Type: Task
  Components: thin client
Reporter: Vladimir Ozerov
 Fix For: 2.5






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

[jira] [Created] (IGNITE-7852) ODBC: Support username/password authentication

Vladimir Ozerov created IGNITE-7852:
---

 Summary: ODBC: Support username/password authentication
 Key: IGNITE-7852
 URL: https://issues.apache.org/jira/browse/IGNITE-7852
 Project: Ignite
  Issue Type: Task
  Components: odbc
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.5






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

[jira] [Commented] (IGNITE-7843) SQL: ALTER TABLE DROP column may break certain SQL queries


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

ASF GitHub Bot commented on IGNITE-7843:


Github user asfgit closed the pull request at:

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


> SQL: ALTER TABLE DROP column may break certain SQL queries
> --
>
> Key: IGNITE-7843
> URL: https://issues.apache.org/jira/browse/IGNITE-7843
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Blocker
> Fix For: 2.4
>
>
> The command DROP column leads to subsequent SQL errors if there is some 
> indexed field next to removed field.



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

[jira] [Comment Edited] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not

2018-03-01 Thread Michael Griggs (JIRA)


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

Michael Griggs edited comment on IGNITE-1903 at 3/1/18 12:08 PM:
-

 I have built a simple reproducer for this

 [https://gitlab.com/michael.griggs/cachestorerepro]


was (Author: endian675):
 I have built a simple reproducer for this

 

https://gitlab.com/michael.griggs/cachestorerepro

> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: community, usability
> Fix For: 2.5
>
>
> See User discussion thread:  
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary:  When a grid client joins the grid (clientMode=true) it 
> receives a message from the server node(s) on the grid that contains the 
> serialized CacheStore implementation object.  If the client does not have 
> this class on its CLASSPATH (and there is no reason it should, as it is a 
> client) then the de-serialization of this message will fail, causing this 
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1 
> class org.apache.ignite.IgniteCheckedException: Failed to find class with 
> given class loader for unmarshalling (make sure same versions of all classes 
> are available on all nodes or enable peer-class-loading): 
> sun.misc.Launcher$AppClassLoader@14dad5dc 
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>  
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> Caused by: java.lang.ClassNotFoundException: 
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore 
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of 
> a TRANSACTIONAL cache can begin the transaction on the underlying store.  
> The only current solution to this is to add the grid node's CacheStore 
> implementation class definition to the CLASSPATH of the client.  This creates 
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or 
> server), all existing cache configurations (which include cache stores) are 
> sent to this node. It then deserializes it during startup which can cause 
> exceptions on clients or servers where cache is not supposed to be deployed 
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format 
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and 
> cache store only if it returns true. In case of error, STOP join process (now 
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until 
> user's code tries to actually use the cache (calls Ignite.cache. If cache is 
> ATOMIC, never deserialize the cache store.



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

[jira] [Commented] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not

2018-03-01 Thread Michael Griggs (JIRA)


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

Michael Griggs commented on IGNITE-1903:


 I have built a simple reproducer for this

 

https://gitlab.com/michael.griggs/cachestorerepro

> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: community, usability
> Fix For: 2.5
>
>
> See User discussion thread:  
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary:  When a grid client joins the grid (clientMode=true) it 
> receives a message from the server node(s) on the grid that contains the 
> serialized CacheStore implementation object.  If the client does not have 
> this class on its CLASSPATH (and there is no reason it should, as it is a 
> client) then the de-serialization of this message will fail, causing this 
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1 
> class org.apache.ignite.IgniteCheckedException: Failed to find class with 
> given class loader for unmarshalling (make sure same versions of all classes 
> are available on all nodes or enable peer-class-loading): 
> sun.misc.Launcher$AppClassLoader@14dad5dc 
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>  
> at 
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>  
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
> Caused by: java.lang.ClassNotFoundException: 
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore 
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of 
> a TRANSACTIONAL cache can begin the transaction on the underlying store.  
> The only current solution to this is to add the grid node's CacheStore 
> implementation class definition to the CLASSPATH of the client.  This creates 
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or 
> server), all existing cache configurations (which include cache stores) are 
> sent to this node. It then deserializes it during startup which can cause 
> exceptions on clients or servers where cache is not supposed to be deployed 
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format 
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and 
> cache store only if it returns true. In case of error, STOP join process (now 
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until 
> user's code tries to actually use the cache (calls Ignite.cache. If cache is 
> ATOMIC, never deserialize the cache store.



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

[jira] [Updated] (IGNITE-7843) SQL: ALTER TABLE DROP column may break certain SQL queries


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

Vladimir Ozerov updated IGNITE-7843:

Fix Version/s: 2.4

> SQL: ALTER TABLE DROP column may break certain SQL queries
> --
>
> Key: IGNITE-7843
> URL: https://issues.apache.org/jira/browse/IGNITE-7843
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.4
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Blocker
> Fix For: 2.4
>
>
> The command DROP column leads to subsequent SQL errors if there is some 
> indexed field next to removed field.



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

[jira] [Assigned] (IGNITE-7467) Verify partition update counters and sizes on partition map exchange

2018-03-01 Thread Pavel Kovalenko (JIRA)


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

Pavel Kovalenko reassigned IGNITE-7467:
---

Assignee: Alexey Goncharuk  (was: Pavel Kovalenko)

Ready to review.
PR: https://github.com/apache/ignite/pull/3579
TC Run: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3579%2Fhead

Changes show problem with update counters inconsistency in a couple of tests. 
List of the affected tests will be published later.

> Verify partition update counters and sizes on partition map exchange
> 
>
> Key: IGNITE-7467
> URL: https://issues.apache.org/jira/browse/IGNITE-7467
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>
> In Ignite we heavily rely on an invariant that under no load owning 
> partitions will have equal sizes and, more importantly, equal partition 
> counters. This invariant becomes even more important when persistence is 
> enabled.
> However, due to a possible bug in the code, this invariant can be violated 
> which in a long run may lead to an undetected data loss. We need to take best 
> effort to detect such a situation as soon as possible.
> Currently, we already send partition update counters during partition map 
> exchange. We can also send partition sizes and verify that corresponding 
> partitions in OWNING state have equal partition update counters and sizes.
> If a divergence detected, we can:
> 1) Always print out an error message to the log
> 2) Move the corresponding caches to the read-only state to prevent further 
> corruption or operating on invalid data
> Also, we can introduce a ./control.sh command which will trigger an empty 
> exchange to verify the partition states.



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC


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

Ilya Lantukh commented on IGNITE-7717:
--

Looks good.

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



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

[jira] [Commented] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

2018-03-01 Thread Alexey Goncharuk (JIRA)


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

Alexey Goncharuk commented on IGNITE-7788:
--

It is physically impossible to change the cache group for an existing cache.

We should add a check to validate the configuration and not start if such a 
condition is detected.

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Goncharuk
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Assigned] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation


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

Pavel Konstantinov reassigned IGNITE-7462:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



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

[jira] [Comment Edited] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation


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

Pavel Konstantinov edited comment on IGNITE-7462 at 3/1/18 11:09 AM:
-

Tested:
# Zookeeper Discovery SPI - generation of Base path field - OK
# S3 discovery SPI - missed fields - OK
# S3 checkpoint SPI - missed fields - OK
## client configuration - missed fields - verified
## fixed generation of retry policies - verified
# Cluster communication - removed Discovery startup delay for 2.3.0 version - OK
# Cluster data storage - missed Checkpoint write order. - OK 


was (Author: pkonstantinov):
Tested:
# Zookeeper Discovery SPI - generation of Base path field - OK
# S3 discovery SPI - missed fields - OK
# S3 checkpoint SPI - missed fields - OK
## client configuration - missed fields - verified
## fixed generation of retry policies
# Cluster communication - removed Discovery startup delay for 2.3.0 version - OK
# Cluster data storage - missed Checkpoint write order. - OK 

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



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

[jira] [Commented] (IGNITE-7462) Web console: remove invoking of depricated methods from code generation


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

Pavel Konstantinov commented on IGNITE-7462:


Tested:
# Zookeeper Discovery SPI - generation of Base path field - OK
# S3 discovery SPI - missed fields - OK
# S3 checkpoint SPI - missed fields - OK
## client configuration - missed fields - verified
## fixed generation of retry policies
# Cluster communication - removed Discovery startup delay for 2.3.0 version - OK
# Cluster data storage - missed Checkpoint write order. - OK 

> Web console: remove invoking of depricated methods from code generation
> ---
>
> Key: IGNITE-7462
> URL: https://issues.apache.org/jira/browse/IGNITE-7462
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>
> e.g. Warning:(2867, 13) java: setLongQueryWarningTimeout(long) in 
> org.apache.ignite.configuration.CacheConfiguration has been deprecated



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

[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-03-01 Thread Nikolay Izhikov (JIRA)


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

Nikolay Izhikov commented on IGNITE-7816:
-

[~vveider]

>  Where to look at dependencies?

1. {{spark}} - 
https://github.com/apache/ignite/blob/master/modules/spark/pom.xml#L144
2. {{spark_2.10}} - 
https://github.com/apache/ignite/blob/master/modules/spark-2.10/pom.xml#L150
3. spark examples - 
https://github.com/apache/ignite/pull/3590/files#diff-08740066c64337d38cccd84991ac0912R155

The long list of dependencies with `test` scope is introduced because of 
flatten plugin.
We don't need it without flatten plugin.

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, examples
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



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

[jira] [Commented] (IGNITE-7459) Web console: do not show result title until query end


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

Pavel Konstantinov commented on IGNITE-7459:


Please reproduce step-by-step from the description. It's still reproducible.

> Web console: do not show result title until query end
> -
>
> Key: IGNITE-7459
> URL: https://issues.apache.org/jira/browse/IGNITE-7459
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Currently we print result title (below result table) for scan before it was 
> actually ended.
> It looks confusing if scan with filter is executing
> Look at the screenshot - I set filter = '12957' and click Scan and it alredy 
> printed below result table but table shows content from previous scan
>  !screenshot-1.png! 



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

[jira] [Assigned] (IGNITE-7459) Web console: do not show result title until query end


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

Pavel Konstantinov reassigned IGNITE-7459:
--

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

> Web console: do not show result title until query end
> -
>
> Key: IGNITE-7459
> URL: https://issues.apache.org/jira/browse/IGNITE-7459
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexander Kalinin
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Currently we print result title (below result table) for scan before it was 
> actually ended.
> It looks confusing if scan with filter is executing
> Look at the screenshot - I set filter = '12957' and click Scan and it alredy 
> printed below result table but table shows content from previous scan
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-7848) On Date type mismatch DDL functionality is broken

2018-03-01 Thread Andrew Medvedev (JIRA)


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

Andrew Medvedev updated IGNITE-7848:

Description: when Date type in value object is originally set as 
java.util.Date, then after ADD COLUMN IF NOT EXISTS and CREATE INDEX on this 
field, basic SQL functionality (SELECT) is broken  (was: when Date type in 
value object is originally set as java.util.Date, then after ADD COLUMN IF NOT 
EXISTS and CREATE INDEX on this field, basic DDL functionality (SELECT) is 
broken)

> On Date type mismatch DDL functionality is broken
> -
>
> Key: IGNITE-7848
> URL: https://issues.apache.org/jira/browse/IGNITE-7848
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrew Medvedev
>Priority: Major
> Attachments: DateCannotBeCastTest.java
>
>
> when Date type in value object is originally set as java.util.Date, then 
> after ADD COLUMN IF NOT EXISTS and CREATE INDEX on this field, basic SQL 
> functionality (SELECT) is broken



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

[jira] [Assigned] (IGNITE-7712) Add an ability to globally enable 'lazy' flag for SQL queries


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

Pavel Konstantinov reassigned IGNITE-7712:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Add an ability to globally enable 'lazy' flag for SQL queries
> -
>
> Key: IGNITE-7712
> URL: https://issues.apache.org/jira/browse/IGNITE-7712
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We have the {{lazy}} flag that can be set when a particular query is 
> executed, it's disabled by default.
> In some cases it can be useful to enable this flag globally, especially it 
> makes sense for the tools like Visor and Web Console.
> Let's do the following:
>  * Set it to {{true}} by default in Web Console.
>  * Add a system property that will allow to do the same on node level.



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

[jira] [Commented] (IGNITE-7712) Add an ability to globally enable 'lazy' flag for SQL queries


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

Pavel Konstantinov commented on IGNITE-7712:


Lazy flag now ON by default

> Add an ability to globally enable 'lazy' flag for SQL queries
> -
>
> Key: IGNITE-7712
> URL: https://issues.apache.org/jira/browse/IGNITE-7712
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We have the {{lazy}} flag that can be set when a particular query is 
> executed, it's disabled by default.
> In some cases it can be useful to enable this flag globally, especially it 
> makes sense for the tools like Visor and Web Console.
> Let's do the following:
>  * Set it to {{true}} by default in Web Console.
>  * Add a system property that will allow to do the same on node level.



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

[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity


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

Dmitriy Pavlov commented on IGNITE-7816:


[~vveider] it is about examples, flatten plugin forces us to specify all 
transitive dependencies. You can look to proposed change in examples pom: 
https://github.com/apache/ignite/pull/3590

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, examples
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



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

[jira] [Commented] (IGNITE-7816) DataFrame examples: wrong folder, hidden on TeamCity

2018-03-01 Thread Peter Ivanov (JIRA)


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

Peter Ivanov commented on IGNITE-7816:
--

What module we are talking about? Where to look at dependencies?

> DataFrame examples: wrong folder, hidden on TeamCity
> 
>
> Key: IGNITE-7816
> URL: https://issues.apache.org/jira/browse/IGNITE-7816
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation, examples
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Trivial
> Fix For: 2.4
>
>
> 1. Spark DataFrame examples are in 
> {{examples/src/main/spark/org/apache/ignite/examples/spark}} folder. Should 
> be moved to 
> {{examples/src/main/scala/org/apache/ignite/scalar/examples/spark}}.
> 2. Spark DataFrame examples not tested on Team City under Ignite Examples. 
> https://issues.apache.org/jira/browse/IGNITE-7655?focusedCommentId=16377875=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16377875



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

[jira] [Commented] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join