[jira] [Assigned] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-4421:
--

Assignee: Igor Sapego  (was: Pavel Tupitsyn)

> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4421:


Looks good, see my minor comment in review.

> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4317) Redesign Queries Screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov updated IGNITE-4317:
---
Attachment: scan.png
chart settings.png

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
> Attachments: chart settings.png, scan.png
>
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (IGNITE-4317) Redesign Queries Screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov reopened IGNITE-4317:

  Assignee: Dmitriy Shabalin  (was: Andrey Novikov)

Reviewed. Fixed work with promise for angular 1.6

My notes:
* Different gap between cache, filter, page size controls in scan.
* Different base line for page size in scan 
* Missing tooltip for filter in scan
* Different gap for top and bottom for chart settings.
* Different base line for 'Show X min' in query chart settings.
* Fetch first page only should be replaced to input with label 'Limit:' and 
default value 

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-4317) Redesign Queries Screen

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-4317.

Resolution: Fixed

> Redesign Queries Screen
> ---
>
> Key: IGNITE-4317
> URL: https://issues.apache.org/jira/browse/IGNITE-4317
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
>
> Simplify queries screen to implement divide execute action to SCAN and QUERY 
> actions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4358) Better error reporting in case of unmarshallable classes.

[Rohit Mohta (JIRA)]

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

Rohit Mohta commented on IGNITE-4358:
-

[~ascherbakov] Changed the message per your comment. NPE check was present in 
my earlier patch too.
```
Objects.requireNonNull(r, "Trying to execute a null closure. Make sure the 
closure is not assignable from classes listed in MarshallerExclusions");
```


> Better error reporting in case of unmarshallable classes.
> -
>
> Key: IGNITE-4358
> URL: https://issues.apache.org/jira/browse/IGNITE-4358
> Project: Ignite
>  Issue Type: Improvement
>  Components: compute, messaging, newbie
>Affects Versions: 1.6
>Reporter: Alexei Scherbakov
>Assignee: Rohit Mohta
>Priority: Trivial
>  Labels: newbie
> Fix For: 2,0
>
> Attachments: IGNITE-4358-Exceptionlog-05Dec2016.txt, 
> IGNITE-4358-GridClosureProcessor-05Dec2016.patch, PureIgniteRunTest.java
>
>
> When trying to execute Thread's derived class implementing IgniteRunnable 
> using compute API, it silently serializes to null because Thread 
> serialization is prohibited in MarshallerExclusions and throws NPE on 
> executing node.
> We need to throw more informative exception for such case.
> Reproducer in the attachment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-3921) ODBC: Add documentation for the PDO interoperability.

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-3921.
---

Done.

> ODBC: Add documentation for the PDO interoperability.
> -
>
> Key: IGNITE-3921
> URL: https://issues.apache.org/jira/browse/IGNITE-3921
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, odbc
>Affects Versions: 1.7
>Reporter: Igor Sapego
>Assignee: Prachi Garg
>  Labels: documentation, odbc
> Fix For: 1.8
>
>
> We have checked our ODBC driver for the compatibility with the PDO. Now we 
> need to document it for our users.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4003) Slow or faulty client can stall the whole cluster.

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-4003:
-

Found issues with recovery descriptor reservation. Fixed. Waiting for TC.

> Slow or faulty client can stall the whole cluster.
> --
>
> Key: IGNITE-4003
> URL: https://issues.apache.org/jira/browse/IGNITE-4003
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Andrey Gura
>Priority: Critical
> Fix For: 2.0
>
>
> Steps to reproduce:
> 1) Start two server nodes and some data to cache.
> 2) Start a client from Docker subnet, which is not visible from the outside. 
> Client will join the cluster.
> 3) Try to put something to cache or start another node to force rabalance.
> Cluster is stuck at this moment. Root cause - servers are constantly trying 
> to establish outgoing connection to the client, but fail as Docker subnet is 
> not visible from the outside. It may stop virtually all cluster operations.
> Typical thread dump:
> {code}
> org.apache.ignite.IgniteCheckedException: Failed to send message (node may 
> have left the grid or TCP connection cannot be established due to firewall 
> issues) [node=TcpDiscoveryNode [id=a15d74c2-1ec2-4349-9640-aeacd70d8714, 
> addrs=[127.0.0.1, 172.17.0.6], sockAddrs=[/127.0.0.1:0, /127.0.0.1:0, 
> /172.17.0.6:0], discPort=0, order=7241, intOrder=3707, 
> lastExchangeTime=1474096941045, loc=false, ver=1.5.23#20160526-sha1:259146da, 
> isClient=true], topic=T4 [topic=TOPIC_CACHE, 
> id1=949732fd-1360-3a58-8d9e-0ff6ea6182cc, 
> id2=a15d74c2-1ec2-4349-9640-aeacd70d8714, id3=2], msg=GridContinuousMessage 
> [type=MSG_EVT_NOTIFICATION, routineId=7e13c48e-6933-48b2-9f15-8d92007930db, 
> data=null, futId=null], policy=2]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1129)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1347)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1227)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1198)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1180)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:841)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:800)
>  ~[ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:787)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:343)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:250)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3476)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:548)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:207)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.processForceKeyResponse(GridDhtPreloader.java:636)
>  [ignite-core-1.5.23.jar:1.5.23]
>   at 
> 

[jira] [Closed] (IGNITE-4345) incorrect/outdated info on site

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-4345.
---

> incorrect/outdated info on site
> ---
>
> Key: IGNITE-4345
> URL: https://issues.apache.org/jira/browse/IGNITE-4345
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sergey Korzhevsky
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 1.8
>
>
> Old/icorrect info on the site.
> 1) http://ignite.apache.org/download.cgi#docker
>a) "guide" link points to 1.5 version
>b) "docker repository" is a broken link, should be 
> https://hub.docker.com/u/apacheignite/
> i guess.
> 2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
> IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
> bob/master/ignite-cfg.xml) does not exists.
> I think, it may be pointed to the some file in the current github repo. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4345) incorrect/outdated info on site

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-4345:
-

Done.

> incorrect/outdated info on site
> ---
>
> Key: IGNITE-4345
> URL: https://issues.apache.org/jira/browse/IGNITE-4345
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Sergey Korzhevsky
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 1.8
>
>
> Old/icorrect info on the site.
> 1) http://ignite.apache.org/download.cgi#docker
>a) "guide" link points to 1.5 version
>b) "docker repository" is a broken link, should be 
> https://hub.docker.com/u/apacheignite/
> i guess.
> 2) https://apacheignite.readme.io/v1.7/docs/docker-deployment
> IGNITE_CONFIG "example url"'s file (https://raw.githubusercontent.com/
> bob/master/ignite-cfg.xml) does not exists.
> I think, it may be pointed to the some file in the current github repo. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3710:
-

Please take a look at my first comment that includes additional details. This 
overall issues is caused by Maven.

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-3710:
-

The error is exactly the same as I've described above. The issue of the 
compilation is triggered by the following
[13:38:24][Step 5/6] [ERROR] error: missing or invalid dependency detected 
while loading class file 'SparkContext.class'.

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1443) CPP: Implement cache continuous queries.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-1443:
-

Ok, I've finished an example but faced some merge-related issues. Sorting out.

> CPP: Implement cache continuous queries.
> 
>
> Key: IGNITE-1443
> URL: https://issues.apache.org/jira/browse/IGNITE-1443
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, important, roadmap
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4408) IndexingSpi support keepBinary options

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-4408:
-

As for original issue, I don't think we really need a configuration property or 
{{withKeepBinary}} flag here. Luckily, {{IndexingSpi}} does not have generics 
and accepts objects, and I think it makes perfect sense to pass what is 
actually stored. If it's a binary object - pass a binary object. In vast 
majority of use cases user will not need a deserialized value (actually, I 
would consider this as a misuse in case binary format is used), but even if 
they do, {{deserialize()}} method is always available.

Having said that, I think we just need to get rid of deserialization step which 
we have before calling the SPI methods.

> IndexingSpi support keepBinary options
> --
>
> Key: IGNITE-4408
> URL: https://issues.apache.org/jira/browse/IGNITE-4408
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>  Labels: easyfix, performance
> Fix For: 2.0
>
>
> For now key and values is being deserialized before passing to IndexingSpi. 
> This can cause performance issues in some cases and there is no way to change 
> this behavior.
> It look like we should allow to avoid deserialization and pass BinaryObjects 
> if keepBinary option is true as we do for CacheStore. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3966) Hadoop: automatically add ${HADOOP_HOME}/lib/native to java.library.path system property

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-3966:

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> Hadoop: automatically add ${HADOOP_HOME}/lib/native to java.library.path 
> system property
> 
>
> Key: IGNITE-3966
> URL: https://issues.apache.org/jira/browse/IGNITE-3966
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>  Labels: easyfix
> Fix For: 2.0
>
>
> Now in order to use native libs user is expected to add -J-Djava.library.path 
> explicitly upon node start.
> In most of the Hadoop distributions native libraries are found in 
> ${HADOOP_HOME}/lib/native/ , and, if such directory exists, we can add 
> -Djava.library.path  paramater automatically. 
> Note that if -Djava.library.path  is also given explicitly by the user, we 
> should  merge his explicit value with our implicitly added value.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (IGNITE-4018) DML: Add documentation to Apache Ignite Readme.io

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-4018.
---

> DML: Add documentation to Apache Ignite Readme.io
> -
>
> Key: IGNITE-4018
> URL: https://issues.apache.org/jira/browse/IGNITE-4018
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, SQL
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 1.8
>
>
> In Apache Ignite 1.8 the community is planning to release DML support.
> To adopt DML usage we need to add documentation about the feature.
> Let's create a new page for now named DML and place it under SQL Queries page 
> [1] in the menu. The content should be the following:
> - Basic overview.
> - Description of INSERT, UPDATE, MERGE commands with code snippet examples.
> - There should be paragraphs saying that it's supported by our JDBC and ODBC 
> drivers (refer to the relevant ODBC page's section IGNITE-4019).
> - As a part of this ticket add a section to existed JDBC Driver page [2] 
> describing that it works over the driver as well. Provide a code snippet 
> example. Refer to this section from the main DML page.
> The page should be hidden until 1.8 gets released. Once you've done assign 
> the ticket to [~pgarg] for polishing and review.
> [1] https://apacheignite.readme.io/docs/sql-queries
> [2] https://apacheignite.readme.io/docs/jdbc-driver



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4421:


GitHub user isapego opened a pull request:

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

IGNITE-4421: Added BinaryObject handling in ODBC.



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

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

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

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


commit 3df412e7f25aac8227b68cffe1577593a05d1431
Author: sboikov 
Date:   2016-12-07T09:25:32Z

ignite-2545 Optimization for GridCompoundFuture's futures iteration

commit f3db74f782c68c7f73ef3ef4390e010976493634
Author: Anton Vinogradov 
Date:   2016-12-07T10:15:37Z

IGNITE-4238: Added geospatial queries example (nolgpl examples hotfix)

commit 56efb10c40fd4481d6a9dc00928e7beee1f164c5
Author: Anton Vinogradov 
Date:   2016-12-07T11:25:53Z

IGNITE-4353 Parent Cassandra module deployed on maven repository (hotfix: 
deploy to custom maven repository)

commit 83710a9d1bb7379e5f3d891ed95c86096263740b
Author: Pavel Tupitsyn 
Date:   2016-12-12T14:52:22Z

IGNITE-4413 .NET: Fix DateTime argument handling in SqlQuery

This closes #1341

commit 5d8b6b8e9fab87b36b9a58db18b8bed2e0796d05
Author: Igor Sapego 
Date:   2016-12-13T13:59:14Z

IGNITE-4421: Added BinaryObject handling in ODBC.

commit 2d44a33055919d8da914b0b12c1a4d05b7ba9c58
Author: Igor Sapego 
Date:   2016-12-13T15:35:06Z

IGNITE-4421: Refactoring.

commit de7f1c498a23347edd85431460c0f69628e42fff
Author: Igor Sapego 
Date:   2016-12-13T16:53:56Z

IGNITE-4421: Added test.




> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4302) Use discovery custom messages instead of system cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4302:
-

Started working on this issue; it seems most of changes are localized in 
*CacheObjectBinaryProcessorImpl* class. Will send a design proposal to dev list 
when one is available.

> Use discovery custom messages instead of system cache
> -
>
> Key: IGNITE-4302
> URL: https://issues.apache.org/jira/browse/IGNITE-4302
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> h4. Notes
> See [IGNITE-4157|https://issues.apache.org/jira/browse/IGNITE-4157] for more 
> details about context.
> h4. Acceptance Criteria
> # Binary metadata cache is deleted.
> # Binary metadata exchange is performed using *DiscoveryCustomMessage* events.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4157) Use discovery custom messages instead of marshaller cache

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-4157:
-

Fixed issue with newly added test for *MappingRejected* messages, fixed issue 
with existing *OptimizedMarshallerNodeFailoverTest* shown up after latest merge 
from master branch.

> Use discovery custom messages instead of marshaller cache
> -
>
> Key: IGNITE-4157
> URL: https://issues.apache.org/jira/browse/IGNITE-4157
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
> Fix For: 2.0
>
>
> Currently we use system caches for keeping classname to class ID mapping and 
> for storing binary metadata
> This has several serious disadvantages:
> 1) We need to introduce at least two additional thread pools for each of 
> these caches
> 2) Since cache operations require stable topology, registering a class ID or 
> updating metadata inside a transaction or another cache operation is tricky 
> and deadlock-prone.
> 3) It may be beneficial in some cases to have nodes with no caches at all, 
> currently this is impossible because system caches are always present.
> 4) Reading binary metadata leads to huge local contention, caching metadata 
> values in a local map doubles memory consumption
> I suggest we use discovery custom events for these purposes. Each node will 
> have a corresponding local map (state) which will be updated inside custom 
> event handler. From the first point of view, this should remove all the 
> disadvantages above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Description: 
Replicated cache sometimes won't sync across nodes properly.
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.

  was:
Replicated cache sometimes won't sync across nodes properly.
Cache should be configured with CacheWriteSynchronizationMode.FULL_SYNC and 
CacheRebalanceMode.SYNC
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.


> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (IGNITE-3085) Hadoop module cannot load native libraries when running inside HDP 2.3.4

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky resolved IGNITE-3085.
-
Resolution: Cannot Reproduce

Cannot reproduce the issue on current master branch with HDP 2.4 sandbox.

> Hadoop module cannot load native libraries when running inside HDP 2.3.4
> 
>
> Key: IGNITE-3085
> URL: https://issues.apache.org/jira/browse/IGNITE-3085
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2,0
>
>
> 1) Run some load with Hadoop Accelerator in HDP 2.2 - all is fine.
> 2) Run the same load with HDP 2.3.4, exception is thorwn:
> {code}
> java.lang.NoClassDefFoundError: org/apache/hadoop/util/NativeCodeLoader
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.initializeNativeLibraries(HadoopClassLoader.java:145)
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.(HadoopClassLoader.java:127)
>   at 
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.start(HadoopJobTracker.java:160)
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopProcessor.start(HadoopProcessor.java:103)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1486)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:859)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1689)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1548)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1004)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:930)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:816)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:715)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:585)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:555)
>   at org.apache.ignite.Ignition.start(Ignition.java:347)
>   at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.util.NativeCodeLoader
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4423) ignite.binary().type(entity.getKeyType())==null before first cache.put()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4423:
-
Priority: Minor  (was: Major)

> ignite.binary().type(entity.getKeyType())==null before first cache.put()
> 
>
> Key: IGNITE-4423
> URL: https://issues.apache.org/jira/browse/IGNITE-4423
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Priority: Minor
> Attachments: BinTest.java
>
>
> See attacheed test for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Attachment: ReplicatedCacheFails.java

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
> Attachments: ReplicatedCacheFails.java
>
>
> Replicated cache sometimes won't sync across nodes properly.
> Cache should be configured with CacheWriteSynchronizationMode.FULL_SYNC and 
> CacheRebalanceMode.SYNC
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-4424:
-
Affects Version/s: 1.8

> REPLICATED cache isn't synced across nodes
> --
>
> Key: IGNITE-4424
> URL: https://issues.apache.org/jira/browse/IGNITE-4424
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.0
>
>
> Replicated cache sometimes won't sync across nodes properly.
> Cache should be configured with CacheWriteSynchronizationMode.FULL_SYNC and 
> CacheRebalanceMode.SYNC
> PFA a reproducer code.
> All nodes are started at the same time on different machines:
> * Ignition.start() // Blocks until node is up
> * Only one of the nodes performs next: getOrCreateCache() then putAll() 
> * All the other nodes block on this before proceeding. 
> * All of the nodes perform next:
> ** getOrCreateCache() // Again
> ** cache.localSize(CachePeekMode.ALL)
> All nodes should see filled cache, but sometimes some nodes see empty cache. 
> LocalSize call can be replaced by iterating over cache, but result will be 
> same.
> Logs says that more than one cluster is started unexpectedly, but there is no 
> errors at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4263) Hadoop: abstract out offheap/heap memory management.

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-4263:
--

Some tests are failed after {{master}} has been merged to the branch.
e.g. {{HadoopMapReduceTest.testWholeMapReduceExecution}}.

There are no memory violations but reduce works incorrect. 
The problem is not reproduced by the unit tests for shuffle collections.

> Hadoop: abstract out offheap/heap memory management.
> 
>
> Key: IGNITE-4263
> URL: https://issues.apache.org/jira/browse/IGNITE-4263
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>  Labels: performance
> Fix For: 2.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4424) REPLICATED cache isn't synced across nodes

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4424:


 Summary: REPLICATED cache isn't synced across nodes
 Key: IGNITE-4424
 URL: https://issues.apache.org/jira/browse/IGNITE-4424
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Andrew Mashenkov
Priority: Critical
 Fix For: 2.0


Replicated cache sometimes won't sync across nodes properly.
Cache should be configured with CacheWriteSynchronizationMode.FULL_SYNC and 
CacheRebalanceMode.SYNC
PFA a reproducer code.

All nodes are started at the same time on different machines:
* Ignition.start() // Blocks until node is up
* Only one of the nodes performs next: getOrCreateCache() then putAll() 
* All the other nodes block on this before proceeding. 
* All of the nodes perform next:
** getOrCreateCache() // Again
** cache.localSize(CachePeekMode.ALL)
All nodes should see filled cache, but sometimes some nodes see empty cache. 
LocalSize call can be replaced by iterating over cache, but result will be same.

Logs says that more than one cluster is started unexpectedly, but there is no 
errors at all.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4423) ignite.binary().type(entity.getKeyType())==null before first cache.put()

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-4423:


 Summary: ignite.binary().type(entity.getKeyType())==null before 
first cache.put()
 Key: IGNITE-4423
 URL: https://issues.apache.org/jira/browse/IGNITE-4423
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov
 Attachments: BinTest.java

See attacheed test for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4423) ignite.binary().type(entity.getKeyType())==null before first cache.put()

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-4423:
-
Attachment: BinTest.java

> ignite.binary().type(entity.getKeyType())==null before first cache.put()
> 
>
> Key: IGNITE-4423
> URL: https://issues.apache.org/jira/browse/IGNITE-4423
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
> Attachments: BinTest.java
>
>
> See attacheed test for details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3886 at 12/13/16 3:05 PM:
--

1) Done. That's actually a very good point, and now the script works on 
TeamCity without any tweaks, because we have M2_HOME there.

2) mavenOpts parameter added.

3) PowerShell is already used in pre-build steps for AnyCPU to build both x64 
and x86. Some things are really hard in regular batch scripts. And PowerShell 
is everywhere already, every supported up-to date Windows system has 4.0 
version installed. Visual Studio requires it, for example.

So yes, let's keep it as is for now. If there is demand, we can rewrite to 
batch script.

4) Done.


was (Author: ptupitsyn):
1) Done. That's actually a very good point, and now the script works on 
TeamCity without any tweaks, because we have M2_HOME there.

2)

3) PowerShell is already used in pre-build steps for AnyCPU to build both x64 
and x86. Some things are really hard in regular batch scripts. And PowerShell 
is everywhere already, every supported up-to date Windows system has 4.0 
version installed. Visual Studio requires it, for example.

So yes, let's keep it as is for now. If there is demand, we can rewrite to 
batch script.

4)

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-4421:
-

I found a root cause of the issue. In {{OdbcRequestHandler}} we now acquire 
keep-binary cache instance ({{withKeepBinary()}}), so any complex object 
returned as an instance of  {{BinaryObjectExImpl}}, which serialized as 
{{IGNITE_TYPE_BINARY}}. Currently, we don't handle objects of type 
{{IGNITE_TYPE_BINARY}} in ODBC driver.
I'm going to implement it.

> ODBC: SQLFetch fails if result set contains non-primitive column.
> -
>
> Key: IGNITE-4421
> URL: https://issues.apache.org/jira/browse/IGNITE-4421
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.8
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 2.0
>
>
> If any column of the result set is complex binary object (non primitive 
> type), then {{SQLFetch}} fails upon call with the following message:
> {noformat}
> Error 01S01: Can not retrieve row column.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-4422:
---
Description: 
* Move PlatformTarget to public package org.apache.ignite.platform

* Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.

  was:Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.


> Define platform plugin API in Java
> --
>
> Key: IGNITE-4422
> URL: https://issues.apache.org/jira/browse/IGNITE-4422
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> * Move PlatformTarget to public package org.apache.ignite.platform
> * Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
> {{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
> User should be able to add {{PlatformPluginConfiguration}} to 
> {{PlatformConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4422) Define platform plugin API in Java

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4422:
--

 Summary: Define platform plugin API in Java
 Key: IGNITE-4422
 URL: https://issues.apache.org/jira/browse/IGNITE-4422
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


Add {{PlatformPluginConfiguration}}, {{PlatformPluginContext}} and 
{{PlatformPluginPorvider}}, similar to regular plugins and to cache plugins. 
User should be able to add {{PlatformPluginConfiguration}} to 
{{PlatformConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-3886 at 12/13/16 2:00 PM:
--

1) Done. That's actually a very good point, and now the script works on 
TeamCity without any tweaks, because we have M2_HOME there.

2)

3) PowerShell is already used in pre-build steps for AnyCPU to build both x64 
and x86. Some things are really hard in regular batch scripts. And PowerShell 
is everywhere already, every supported up-to date Windows system has 4.0 
version installed. Visual Studio requires it, for example.

So yes, let's keep it as is for now. If there is demand, we can rewrite to 
batch script.

4)


was (Author: ptupitsyn):
1) Done. That's actually a very good point, and now the script works on 
TeamCity without any tweaks, because we have M2_HOME there.
2)
3) PowerShell is already used in pre-build steps for AnyCPU to build both x64 
and x86. Some things are really hard in regular batch scripts. And PowerShell 
is everywhere already, every supported up-to date Windows system has 4.0 
version installed. Visual Studio requires it, for example. I think it is very 
unlikely that a person who wants to build Ignite from sources does not have 
PowerShell installed.
4)

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3886) .NET: Build script

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-3886:


1) Done. That's actually a very good point, and now the script works on 
TeamCity without any tweaks, because we have M2_HOME there.
2)
3) PowerShell is already used in pre-build steps for AnyCPU to build both x64 
and x86. Some things are really hard in regular batch scripts. And PowerShell 
is everywhere already, every supported up-to date Windows system has 4.0 
version installed. Visual Studio requires it, for example. I think it is very 
unlikely that a person who wants to build Ignite from sources does not have 
PowerShell installed.
4)

> .NET: Build script
> --
>
> Key: IGNITE-3886
> URL: https://issues.apache.org/jira/browse/IGNITE-3886
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.0
>
>
> Create a build script with powershell or cake http://cakebuild.net/.
> Currently, we have our build completely automated on TeamCity. However, it 
> should be possible to build everything (jars, dlls, NuGet) locally with a 
> single command.
> As a result, we should have:
> * bin folder with all .NET-related files (DLL, XML, XSD, etc) and Libs folder 
> with jar files
> * nupkg folder with all NuGet packages
> Investigate how to integrate this with Maven: IGNITE-2292



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4421) ODBC: SQLFetch fails if result set contains non-primitive column.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-4421:
---

 Summary: ODBC: SQLFetch fails if result set contains non-primitive 
column.
 Key: IGNITE-4421
 URL: https://issues.apache.org/jira/browse/IGNITE-4421
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.8
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.0


If any column of the result set is complex binary object (non primitive type), 
then {{SQLFetch}} fails upon call with the following message:
{noformat}
Error 01S01: Can not retrieve row column.
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3618) Client can not load data after server restarts

[Dmitry Parkhonin (JIRA)]

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

Dmitry Parkhonin commented on IGNITE-3618:
--

The same exception can be observed when trying to call a remote service after 
the whole cluster restart.
I can reproduce the error on Apache Ignite 1.8 too.

2016-12-13 09:42:53,636 DEBUG - Task result received for 
a6896ff9-ab3f-4fde-8482-b9c876d54c82@c6a68b54-9630-4715-b8a6-c50d861bccb5 
[ru.depsy.pricinggrid.client.AbstractSession] [sys-#51%pricingGridServer%] {}
2016-12-13 09:42:53,636 ERROR - The calibration has failed 
[ru.depsy.server.zerocice.MyServiceI] [sys-#51%pricingGridServer%] {}
class org.apache.ignite.compute.ComputeUserUndeclaredException: Failed to 
execute job due to unexpected runtime exception 
[jobId=97c4a87f851-39d922a0-b23e-49be-b70a-f31d130a6ee6, ses=GridJobSessionImpl 
[ses=GridTaskSessionImpl 
[taskName=ru.depsy.pricinggrid.client.ignite.IgniteTask, dep=SharedDeployment 
[rmv=false, super=GridDeployment [ts=1481622173293, depMode=SHARED, 
clsLdr=GridDeploymentClassLoader 
[id=c390097f851-a52881e1-10b0-4332-a609-79deb560c69c, singleNode=false, 
nodeLdrMap={39d922a0-b23e-49be-b70a-f31d130a6ee6=46c4a87f851-39d922a0-b23e-49be-b70a-f31d130a6ee6},
 p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], 
clsLdrId=c390097f851-a52881e1-10b0-4332-a609-79deb560c69c, userVer=0, 
loc=false, sampleClsName=ru.depsy.pricinggrid.client.ignite.IgniteTask, 
pendingUndeploy=false, undeployed=false, usage=1]], 
taskClsName=ru.depsy.pricinggrid.client.ignite.IgniteTask, 
sesId=67c4a87f851-39d922a0-b23e-49be-b70a-f31d130a6ee6, 
startTime=1481622172731, endTime=9223372036854775807, 
taskNodeId=39d922a0-b23e-49be-b70a-f31d130a6ee6, 
clsLdr=GridDeploymentClassLoader 
[id=c390097f851-a52881e1-10b0-4332-a609-79deb560c69c, singleNode=false, 
nodeLdrMap={39d922a0-b23e-49be-b70a-f31d130a6ee6=46c4a87f851-39d922a0-b23e-49be-b70a-f31d130a6ee6},
 p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false, 
cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=true, 
subjId=39d922a0-b23e-49be-b70a-f31d130a6ee6, mapFut=IgniteFuture 
[orig=GridFutureAdapter [resFlag=0, res=null, startTime=1481622173293, 
endTime=0, ignoreInterrupts=false, state=INIT]]], 
jobId=97c4a87f851-39d922a0-b23e-49be-b70a-f31d130a6ee6]]
at 
org.apache.ignite.internal.processors.job.GridJobWorker.handleThrowable(GridJobWorker.java:607)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:427)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1089)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1766)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1238)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:866)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:829)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Cannot find 
metadata for object with compact footer: -771298812
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:1709)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:278)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:177)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1683)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:776)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1481)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1683)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:639)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:776)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1481)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1683)
at 

[jira] [Created] (IGNITE-4420) .NET: Improve documentation for query configuration combined with reflective serialization

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4420:
--

 Summary: .NET: Improve documentation for query configuration 
combined with reflective serialization
 Key: IGNITE-4420
 URL: https://issues.apache.org/jira/browse/IGNITE-4420
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.0


With automatic properties the situation is straightforward: mark property with 
[QuerySqlField].

With manual backing fields there may be some confusion, because reflective 
serializer operates on fields, and field names start with "_" in default naming 
convention. 

Make sure all situations are documented properly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-1650:
--

Link at dev-list discussion: 
http://apache-ignite-developers.2346864.n4.nabble.com/Which-thread-is-used-to-run-IgniteFuture-continuations-td3904.html

> Add ability to specify thread pool for IgniteFuture listen/chain methods.
> -
>
> Key: IGNITE-1650
> URL: https://issues.apache.org/jira/browse/IGNITE-1650
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Chandresh Pancholi
> Fix For: 2.0
>
>
> Closures passed to IgniteFuture listen() and chain() methods are executed 
> either in the same thread if future is completed, or in a completion thread 
> (usually this is a thread from one of Ignite pools).
> This enforces restrictions on what user can do in closures. He cannot use 
> call operations, he cannot call any Ignite operations. Otherwise deadlocks or 
> starvation could occur.
> To fix that we should allow user to pass optional thread pool where passed 
> closure should be executed. This already done in Java 8 CompletableFuture. We 
> should do almost the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky edited comment on IGNITE-3877 at 12/13/16 11:20 AM:


The problem is in mixing notions GroupBlockSize and BlockSize. 
As comment to class 
{code}org.apache.ignite.igfs.IgfsGroupDataBlocksKeyMapper{code} states, when 
{code}org.apache.hadoop.fs.FileSystem{code} lies upon IGFS, the Hadoop Fs block 
size equals to underlying IGFS *group* block size (which, in turn, is the block 
size multiplied by groupSize).
When we  have IGFS over Hadoop FileSystem, we also use the group block size as 
the block size of the created secondary Fs files (see 
{code}org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext#create{code}).
This way, when reading files we should follow the same logic: IGFS *group* 
block size ==  Hadoop block size, and IGFS block size is just the configuration 
value 
({code}org.apache.ignite.configuration.FileSystemConfiguration#getBlockSize{code})
 . 
This way we make the logic consistent, and fix the assertion issue described 
above.




was (Author: iveselovskiy):
The problem is in mixing notions GroupBlockSize and BlockSize. 
As comment to class 
{code}org.apache.ignite.igfs.IgfsGroupDataBlocksKeyMapper{code} states, when 
{code}org.apache.hadoop.fs.FileSystem{code} lies upon IGFS, the Hadoop Fs block 
size equals to underlying IGFS group block size (which, in turn, is the block 
size multiplied by groupSize).
When we  have IGFS over Hadoop FileSystem, we also use the group block size as 
the block size of the created secondary Fs files (see 
{code}org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext#create{code}).
This way, when reading files we should follow the same logic: IGFS *group* 
block size ==  Hadoop block size, and IGFS block size is just the configuration 
value 
({code}org.apache.ignite.configuration.FileSystemConfiguration#getBlockSize{code})
 . 
This way we make the logic consistent, and fix the assertion issue described 
above.



> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky commented on IGNITE-3877:
-

The problem is in mixing notions GroupBlockSize and BlockSize. 
As comment to class 
{code}org.apache.ignite.igfs.IgfsGroupDataBlocksKeyMapper{code} states, when 
{code}org.apache.hadoop.fs.FileSystem{code} lies upon IGFS, the Hadoop Fs block 
size equals to underlying IGFS group block size (which, in turn, is the block 
size multiplied by groupSize).
When we  have IGFS over Hadoop FileSystem, we also use the group block size as 
the block size of the created secondary Fs files (see 
{code}org.apache.ignite.internal.processors.igfs.IgfsSecondaryFileSystemCreateContext#create{code}).
This way, when reading files we should follow the same logic: IGFS *group* 
block size ==  Hadoop block size, and IGFS block size is just the configuration 
value 
({code}org.apache.ignite.configuration.FileSystemConfiguration#getBlockSize{code})
 . 
This way we make the logic consistent, and fix the assertion issue described 
above.



> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3710) Upgrade ignite-spark module to Spark 2.0

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-3710:
--

Denis, 

I've rechecked at another agent and see compilation error.
Seems dependency issue solved, please check.
http://ci.ignite.apache.org/viewLog.html?buildId=389376=IgniteTests_IgniteRdd=buildLog#_focus=428=428

> Upgrade ignite-spark module to Spark 2.0
> 
>
> Key: IGNITE-3710
> URL: https://issues.apache.org/jira/browse/IGNITE-3710
> Project: Ignite
>  Issue Type: Improvement
>  Components: Ignite RDD
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
> Attachments: Ignite_Tests_Ignite_RDD_495.log
>
>
> Currently {{ignite-spark}} depends on Spark 1.5.2 and fails with 2.0 with 
> this exception:
> {noformat}
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> org/apache/spark/Logging 
> at java.lang.ClassLoader.defineClass1(Native Method) 
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) 
> at 
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) 
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) 
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368) 
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362) 
> at java.security.AccessController.doPrivileged(Native Method) 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) 
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) 
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) 
> at 
> org.apache.ignite.spark.JavaIgniteContext.(JavaIgniteContext.scala:42) 
> at client.SparkIgniteClient.main(SparkIgniteClient.java:75) 
> 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 
> com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) 
> Caused by: java.lang.ClassNotFoundException: org.apache.spark.Logging 
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) 
> {noformat}
> Need to investigate if we can upgrade without breaking compatibility with old 
> versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (IGNITE-3176) Need to create gc log for each client separately [ yardstick-ignite ]

[Ilya Suntsov (JIRA)]

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

Ilya Suntsov edited comment on IGNITE-3176 at 12/13/16 11:01 AM:
-

[~Chandresh Pancholi]
I told about a little different use case:
1. Set in properties file number of servers and drivers (drivers are clients if 
we set --client parameter, please take a look at attachment) e.g:
{noformat}
# Comma-separated list of the hosts to run BenchmarkServers on. 2 nodes on 
local host are enabled by default.
SERVER_HOSTS=localhost,localhost,localhost

# Comma-separated list of the hosts to run BenchmarkDrivers on. 1 node on local 
host is enabled by default.
DRIVER_HOSTS=localhost,localhost
{noformat}

2. bin/benchmark-run-all.sh config/benchmark.properties only in one terminal.

In this case we receive 2 gc files.


was (Author: ustas):
I told about a little different use case:
1. Set in properties file number of servers and drivers (drivers are clients if 
we set --client parameter, please take a look at attachment) e.g:
{noformat}
# Comma-separated list of the hosts to run BenchmarkServers on. 2 nodes on 
local host are enabled by default.
SERVER_HOSTS=localhost,localhost,localhost

# Comma-separated list of the hosts to run BenchmarkDrivers on. 1 node on local 
host is enabled by default.
DRIVER_HOSTS=localhost,localhost
{noformat}

2. bin/benchmark-run-all.sh config/benchmark.properties only in one terminal.

In this case we receive 2 gc files.

> Need to create gc log for each client separately [ yardstick-ignite ]
> -
>
> Key: IGNITE-3176
> URL: https://issues.apache.org/jira/browse/IGNITE-3176
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, general
>Affects Versions: 1.6
>Reporter: Ilya Suntsov
>Assignee: Chandresh Pancholi
>Priority: Critical
> Fix For: 2.0
>
> Attachments: benchmark.properties
>
>
> In case when started more than one client/server on one host yardstick 
> re-write GC logs.
> GC options contain in *.properties files:
> {noformat}
> now0=`date +'%H%M%S'`
> # JVM options.
> JVM_OPTS=${JVM_OPTS}" -DIGNITE_QUIET=false"
> # Uncomment to enable concurrent garbage collection (GC) if you encounter 
> long GC pauses.
> JVM_OPTS=${JVM_OPTS}" \
> -Xloggc:./gc${now0}.log \
> -XX:+PrintGCDetails \
> -verbose:gc \
> -XX:+UseParNewGC \
> -XX:+UseConcMarkSweepGC \
> -XX:+UseTLAB \
> -XX:NewSize=128m \
> -XX:MaxNewSize=128m \
> -XX:MaxTenuringThreshold=0 \
> -XX:SurvivorRatio=1024 \
> -XX:+UseCMSInitiatingOccupancyOnly \
> -XX:CMSInitiatingOccupancyFraction=60 \
> {noformat}
> As you can see here will be created 1 log file and if you start another 
> driver/server with the same properties file will be re-write.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-4402) Prepare Cloud Images for 1.8 Release

[Nikolay Tikhonov (JIRA)]

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

Nikolay Tikhonov commented on IGNITE-4402:
--

[~dmagda]
Yes, it not needed. IGNITE_VERSION allows using any version of ignite.

> Prepare Cloud Images for 1.8 Release
> 
>
> Key: IGNITE-4402
> URL: https://issues.apache.org/jira/browse/IGNITE-4402
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
>Priority: Blocker
> Fix For: 1.8
>
>
> We have to prepare all the AI 1.8 cloud images for the environments listed 
> here:
> https://ignite.apache.org/download.cgi#docker
> Once this done, share the URLs with me and I'll update the site.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3961) IGFS: Support direct PROXY mode invocation in method: affinity

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3961:

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> IGFS: Support direct PROXY mode invocation in method: affinity
> --
>
> Key: IGNITE-3961
> URL: https://issues.apache.org/jira/browse/IGNITE-3961
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.0
>
>
> See 
> {{org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.getFileBlockLocations}}
>  for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-3961) IGFS: Support direct PROXY mode invocation in method: affinity

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3961:
---

Assignee: Vladimir Ozerov  (was: Taras Ledkov)

> IGFS: Support direct PROXY mode invocation in method: affinity
> --
>
> Key: IGNITE-3961
> URL: https://issues.apache.org/jira/browse/IGNITE-3961
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> See 
> {{org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem.getFileBlockLocations}}
>  for reference.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4106:
---

Assignee: Vladimir Ozerov  (was: Andrew Mashenkov)

> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Vladimir Ozerov
>  Labels: performance, sql
> Fix For: 2.0
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4106) SQL: parallelize sql queries over cache local partitions

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4106:

Assignee: Andrew Mashenkov  (was: Vladimir Ozerov)

> SQL: parallelize sql queries over cache local partitions
> 
>
> Key: IGNITE-4106
> URL: https://issues.apache.org/jira/browse/IGNITE-4106
> Project: Ignite
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 1.6, 1.7
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>  Labels: performance, sql
> Fix For: 2.0
>
> Attachments: 1node-4thread.jfr, 4node-1thread.jfr
>
>
> If we run SQL query on cache partitioned over several cluster nodes, it will 
> be split into several queries running in parallel. But really we will have 
> one thread per query on each node.
> So, for now, to improve SQL query performance we need to run more Ignite 
> instances or split caches manually.
> It seems to be better to split local SQL queries over cache partitions, so we 
> would be able to parallelize SQL query on every single node and utilize CPU 
> more efficiently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3877:

Assignee: Ivan Veselovsky  (was: Vladimir Ozerov)

> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-3877) Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as blockSize

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-3877:
---

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> Clarify if IgfsFile -> FileStatus conversion should treat groupBlockSize as 
> blockSize
> -
>
> Key: IGNITE-3877
> URL: https://issues.apache.org/jira/browse/IGNITE-3877
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
> Fix For: 2.0
>
>
> During Metrics tests repairing test 
> org.apache.ignite.igfs.Hadoop1DualAbstractTest#testMetricsBlock revealed the 
> following problem:
> org.apache.ignite.hadoop.fs.v1.IgniteHadoopFileSystem#convert(org.apache.ignite.igfs.IgfsFile)
>  method treats groupBlockSize as blockSize for Hadoop FileStatus. 
> groupBlockSize can be several times larger than blockSize, so blockSize in 
> status gets different to that in original IgfsFile .
> changing file.groupBlockSize() to file.blockSize()  fixes problem in metrics 
> tests, but creates problems in Hadoop tests that are bound to splits 
> calculation, since split calculation related to blockSizes.
> Need to 
> 1) clarify if the treatment of groupBlcokSize was intentional.
> 2) fix either metrics tests or Hadoop tests. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-3085) Hadoop module cannot load native libraries when running inside HDP 2.3.4

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3085:

Assignee: Ivan Veselovsky

> Hadoop module cannot load native libraries when running inside HDP 2.3.4
> 
>
> Key: IGNITE-3085
> URL: https://issues.apache.org/jira/browse/IGNITE-3085
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
>Priority: Critical
>  Labels: bigdata, important
> Fix For: 2,0
>
>
> 1) Run some load with Hadoop Accelerator in HDP 2.2 - all is fine.
> 2) Run the same load with HDP 2.3.4, exception is thorwn:
> {code}
> java.lang.NoClassDefFoundError: org/apache/hadoop/util/NativeCodeLoader
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.initializeNativeLibraries(HadoopClassLoader.java:145)
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopClassLoader.(HadoopClassLoader.java:127)
>   at 
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.start(HadoopJobTracker.java:160)
>   at 
> org.apache.ignite.internal.processors.hadoop.HadoopProcessor.start(HadoopProcessor.java:103)
>   at 
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1486)
>   at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:859)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1689)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1548)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1004)
>   at 
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:930)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:816)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:715)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:585)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:555)
>   at org.apache.ignite.Ignition.start(Ignition.java:347)
>   at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: java.lang.ClassNotFoundException: 
> org.apache.hadoop.util.NativeCodeLoader
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
>   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>   ... 16 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4097) Spilled map-reduce: map side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4097:

Assignee: Ivan Veselovsky  (was: Vladimir Ozerov)

> Spilled map-reduce: map side.
> -
>
> Key: IGNITE-4097
> URL: https://issues.apache.org/jira/browse/IGNITE-4097
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>
> Implement spilled output on Map side of map-reduce.
> In general, algorithm should follow the one used in Hadoop. The difference on 
> the Map side is that 
> 1) we use sorting collection (Hadoop sorts a range of map outputs explicitly);
> 2) we store the map output in files not using FileSystem , but rather local 
> files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (IGNITE-4097) Spilled map-reduce: map side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4097:

Fix Version/s: (was: 2.0)

> Spilled map-reduce: map side.
> -
>
> Key: IGNITE-4097
> URL: https://issues.apache.org/jira/browse/IGNITE-4097
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>
> Implement spilled output on Map side of map-reduce.
> In general, algorithm should follow the one used in Hadoop. The difference on 
> the Map side is that 
> 1) we use sorting collection (Hadoop sorts a range of map outputs explicitly);
> 2) we store the map output in files not using FileSystem , but rather local 
> files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (IGNITE-4097) Spilled map-reduce: map side.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-4097:
---

Assignee: Vladimir Ozerov  (was: Ivan Veselovsky)

> Spilled map-reduce: map side.
> -
>
> Key: IGNITE-4097
> URL: https://issues.apache.org/jira/browse/IGNITE-4097
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.6
>Reporter: Ivan Veselovsky
>Assignee: Vladimir Ozerov
>
> Implement spilled output on Map side of map-reduce.
> In general, algorithm should follow the one used in Hadoop. The difference on 
> the Map side is that 
> 1) we use sorting collection (Hadoop sorts a range of map outputs explicitly);
> 2) we store the map output in files not using FileSystem , but rather local 
> files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4419) .NET: Serilog integration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4419:
--

 Summary: .NET: Serilog integration
 Key: IGNITE-4419
 URL: https://issues.apache.org/jira/browse/IGNITE-4419
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.0


Serilog is another popular .NET logger: https://serilog.net/

Integrate with Ignite.NET, see NLog and log4net integrations: IGNITE-3279, 
IGNITE-3280



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4418) Web console: summary page is hangs if clusters list contain a huge cluster

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-4418:
--

 Summary: Web console: summary page is hangs if clusters list 
contain a huge cluster
 Key: IGNITE-4418
 URL: https://issues.apache.org/jira/browse/IGNITE-4418
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov


I have a cluster with 1284 caches (with 1284 models).
When I open summary page it hangs for a 10-15 seconds.
No splash screen with loading progress shows.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (IGNITE-3923) Web Console: Summary page - Download button should show progress of downloading

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-3923:


Tested. Closed. For my last comment I've created a new issue.

> Web Console: Summary page - Download button should show progress of 
> downloading
> ---
>
> Key: IGNITE-3923
> URL: https://issues.apache.org/jira/browse/IGNITE-3923
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.6
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
> Fix For: 2.0
>
>
> In case of download large project Summary page is not responsive.
> To fix this we should somehow animate "Download progress".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)