[jira] [Created] (IGNITE-7851) .NET: linq query throws "Hexadecimal string with odd number of characters" exception

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7851:


 Summary: .NET: linq query throws "Hexadecimal string with odd 
number of characters" exception
 Key: IGNITE-7851
 URL: https://issues.apache.org/jira/browse/IGNITE-7851
 Project: Ignite
  Issue Type: Bug
  Components: platforms, sql
Affects Versions: 2.3
Reporter: Alexey Popov
 Attachments: FirstOrDefaultKeyIssue.zip

Simple linq query with .Key throws an exception

{code}
var models = cache.AsCacheQueryable();
var entry = models.FirstOrDefault(m => m.Key == @"TST-1/1");
{code}


Apache.Ignite.Core.Common.IgniteException: Hexadecimal string with odd number 
of characters: "TST-1/1" [90003-195] ---> 
Apache.Ignite.Core.Common.JavaException: class 
org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number of 
characters: "TST-1/1" [90003-195]
at 
org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:519)
at 
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1240)
at 
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:877)
at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
Caused by: javax.cache.CacheException: class 
org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number of 
characters: "TST-1/1" [90003-195]
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1917)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:368)
at 
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1234)
... 2 more
Caused by: class org.apache.ignite.IgniteCheckedException: Hexadecimal string 
with odd number of characters: "TST-1/1" [90003-195]
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2468)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
... 5 more
Caused by: org.h2.message.DbException: Hexadecimal string with odd number of 
characters: "TST-1/1" [90003-195]
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
at org.h2.value.Value.convertTo(Value.java:957)
at 
org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:262)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.bindPartitionInfoParameter(IgniteH2Indexing.java:2520)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.calculateQueryPartitions(IgniteH2Indexing.java:2480)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeTwoStepsQuery(IgniteH2Indexing.java:1556)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1500)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
at 
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
... 6 more
Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number of 
characters: "TST-1/1" [90003-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
... 19 more

   --- End of inner exception stack trace ---
   at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* target, 
Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte* errMsgChars, 
Int32 errMsgCharsLen, SByte* stackTraceChars, Int32 stackTraceCharsLen, Void* 
errData, Int32 errDataLen)
   at 
Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.TargetInStreamOutObject(Void*
 ctx, Void* target, Int32 opType, Int64 memPtr)
   at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type, 
Action`1 writeAction)
   at Apache.Ignite.Core.Impl.Cache.CacheImpl`2.QueryFields[T](SqlFieldsQuery 
qry, Func`3 readerFunc)
   at 
Apache.Ignite.Linq.Impl.CacheFieldsQueryExecutor.ExecuteSingle[T](QueryModel 
queryModel, Boolean returnDefaultWhenEmpty)
   at 

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

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5357:


Hi, [~ascherbakov], I've updated [the 
PR|https://github.com/apache/ignite/pull/3578/files] to avoid memory's 
overhead. Please have a look, if you have time.

Now it covers {{get}} and {{getAll}} operations. I moved logic to 
{{GridCacheUtils}} since classes have no suitable common superclasses in the 
hierarchy.

New 
[ci.tests|https://ci.ignite.apache.org/viewLog.html?buildId=1115559=buildResultsDiv=IgniteTests24Java8_RunAll]
 look good.

About such optimization for {{READ_COMMITED}} mode, I'd like to implement it in 
a separate ticket, since it may need significant changes.

> 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: Lukjanenko Dmitry
>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] [Assigned] (IGNITE-7803) REST: Add support to get values inserted via API or SQL

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7803:


Assignee: Vladimir Ozerov  (was: Alexey Kuznetsov)

[~vozerov] Could you review my changes in ignite-7803 branch?

> 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: Vladimir Ozerov
>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-7033) Web console: Increase width of columns on admin page

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7033:


Looks acceptable.

> 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: Pavel Konstantinov
>Priority: Major
>
> *"Last activity" and "email" columns are too narrow*



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

[jira] [Updated] (IGNITE-7817) Spark 'close' API call hangs when executed within ignite service grid component

[Akshay Mhetre (JIRA)]

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

Akshay Mhetre updated IGNITE-7817:
--
Affects Version/s: 2.4
  Description: 
I am running a sprak job within ignite service grid. After job is done I am 
 calling close() on spark session. This is working for stable version of 
 ignite i.e. 2.3.0. However, its not working with 2.4.0-SNAPSHOT / 
2.5.0-SNAPSHOT version. 
 Please check detailed logs on this link : 

[http://apache-ignite-users.70518.x6.nabble.com/Spark-close-API-call-hangs-within-ignite-service-grid-td20252.html|http://example.com/]
 

  was:
I am running a sprak job within ignite service grid. After job is done I am 
calling close() on spark session. This is working for stable version of 
ignite i.e. 2.3.0. However, its not working with 2.5.0-SNAPSHOT version. 
Please check detailed logs on this link : 

[http://apache-ignite-users.70518.x6.nabble.com/Spark-close-API-call-hangs-within-ignite-service-grid-td20252.html|http://example.com]
 


> Spark 'close' API call hangs when executed within ignite service grid 
> component
> ---
>
> Key: IGNITE-7817
> URL: https://issues.apache.org/jira/browse/IGNITE-7817
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4, 2.5
>Reporter: Akshay Mhetre
>Priority: Major
>
> I am running a sprak job within ignite service grid. After job is done I am 
>  calling close() on spark session. This is working for stable version of 
>  ignite i.e. 2.3.0. However, its not working with 2.4.0-SNAPSHOT / 
> 2.5.0-SNAPSHOT version. 
>  Please check detailed logs on this link : 
> [http://apache-ignite-users.70518.x6.nabble.com/Spark-close-API-call-hangs-within-ignite-service-grid-td20252.html|http://example.com/]
>  



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

[jira] [Assigned] (IGNITE-6400) Document ClientConnectorConfiguration

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-6400:
---

Assignee: Denis Magda  (was: Prachi Garg)

[~dmagda], Please review the parameters table in - 

https://apacheignite-sql.readme.io/v2.3/docs/jdbc-driver-24#section-cluster-configuration

https://apacheignite-sql.readme.io/v2.3/docs/odbc-driver-24#section-cluster-configuration

> Document ClientConnectorConfiguration
> -
>
> Key: IGNITE-6400
> URL: https://issues.apache.org/jira/browse/IGNITE-6400
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, thin client
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Resolved] (IGNITE-7061) Rework Features menu and page

[Denis Magda (JIRA)]

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

Denis Magda resolved IGNITE-7061.
-
Resolution: Fixed

All the changes were merged to the master and deployed on the site.

> Rework Features menu and page
> -
>
> Key: IGNITE-7061
> URL: https://issues.apache.org/jira/browse/IGNITE-7061
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> The features menu and the page [1] is overloaded and confusing. As a 
> technical guy, I feel lost trying to grasp what’s important and what’s 
> secondary. That deters me from digging into the project. 
> Rework the menu and page in accordance with this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html
> All the changes are incorporated in this SVN branch:
> https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061
> [1] https://ignite.apache.org/features.html



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

[jira] [Closed] (IGNITE-7061) Rework Features menu and page

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-7061.
---

> Rework Features menu and page
> -
>
> Key: IGNITE-7061
> URL: https://issues.apache.org/jira/browse/IGNITE-7061
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> The features menu and the page [1] is overloaded and confusing. As a 
> technical guy, I feel lost trying to grasp what’s important and what’s 
> secondary. That deters me from digging into the project. 
> Rework the menu and page in accordance with this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html
> All the changes are incorporated in this SVN branch:
> https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061
> [1] https://ignite.apache.org/features.html



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

[jira] [Comment Edited] (IGNITE-7668) Cover menu and main page references with GA labels

[Prachi Garg (JIRA)]

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

Prachi Garg edited comment on IGNITE-7668 at 2/28/18 11:44 PM:
---

Added GA event labels to features, benefits, usecases for header menu as well 
as homepage clicks.


was (Author: pgarg):
Added GA event label to features, benefits, usecases for header menu as well as 
homepage clicks.

> Cover menu and main page references with GA labels
> --
>
> Key: IGNITE-7668
> URL: https://issues.apache.org/jira/browse/IGNITE-7668
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> It's useful to see insights on how frequent people click on specific 
> references shown on the main page or menus.
> Let's add labels to all the benefits and features so that GA can track these 
> events for us.



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

[jira] [Closed] (IGNITE-7668) Cover menu and main page references with GA labels

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-7668.
---

> Cover menu and main page references with GA labels
> --
>
> Key: IGNITE-7668
> URL: https://issues.apache.org/jira/browse/IGNITE-7668
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> It's useful to see insights on how frequent people click on specific 
> references shown on the main page or menus.
> Let's add labels to all the benefits and features so that GA can track these 
> events for us.



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

[jira] [Commented] (IGNITE-7668) Cover menu and main page references with GA labels

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-7668:
-

Added GA event label to features, benefits, usecases for header menu as well as 
homepage clicks.

> Cover menu and main page references with GA labels
> --
>
> Key: IGNITE-7668
> URL: https://issues.apache.org/jira/browse/IGNITE-7668
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> It's useful to see insights on how frequent people click on specific 
> references shown on the main page or menus.
> Let's add labels to all the benefits and features so that GA can track these 
> events for us.



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

[jira] [Resolved] (IGNITE-7668) Cover menu and main page references with GA labels

[Prachi Garg (JIRA)]

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

Prachi Garg resolved IGNITE-7668.
-
Resolution: Fixed

> Cover menu and main page references with GA labels
> --
>
> Key: IGNITE-7668
> URL: https://issues.apache.org/jira/browse/IGNITE-7668
> Project: Ignite
>  Issue Type: Sub-task
>  Components: site
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> It's useful to see insights on how frequent people click on specific 
> references shown on the main page or menus.
> Let's add labels to all the benefits and features so that GA can track these 
> events for us.



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

[jira] [Updated] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7466:

Affects Version/s: 2.4

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Updated] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7466:

Fix Version/s: (was: 2.4)
   2.5

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7816:

Component/s: examples

> 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-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7655:
-

[~abchaudhri] , as discussed, please add Java code snippets similar to the ones 
we have for scala.

> 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: Denis Magda
>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] [Assigned] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7655:
---

Assignee: Akmal Chaudhri  (was: Denis Magda)

> 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-7816) DataFrame examples: wrong folder, hidden on TeamCity

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7816:
-

[~dmagda], [~dpavlov]

>  can't we just import ignite-spark instead of listing all the jars this module

Short answer - no we can't because of flatten plugin from parent pom.

I raised discussion of this issue on dev-lis.
Please, see my mail:

http://apache-ignite-developers.2346864.n4.nabble.com/Maven-Issues-with-flatten-plugin-td27537.html

> 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
>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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7816:


Hi [~dmagda], [~NIzhikov], I've noticed before we need always list all 
dependencies. It seems transitive dependencies are disabled somehow in our 
poms. May be [~vveider] know where and how it can bypassed. Unfortunately, I am 
not maven guru, I prefer gradle :)

I can expects user will need to download tons of jars from maven central to see 
Ignite's examples. [~NIzhikov], is it enabled by default (e.g. under maven by 
profile)?

Dependency hell is always possible, but as far as I can see, spark version here 
is taken from variable, from parent poms. So if some conflict occur, then we 
will need to fix it anyway.

I suggest to create distrubution of Ignite from sorces and test examples 
manually for the first time before merge.

> 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
>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] [Assigned] (IGNITE-7825) ODBC: Update specification documentation

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7825:
---

Assignee: Prachi Garg  (was: Igor Sapego)

> ODBC: Update specification documentation
> 
>
> Key: IGNITE-7825
> URL: https://issues.apache.org/jira/browse/IGNITE-7825
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Prachi Garg
>Priority: Major
>  Labels: documentation, odbc
> Fix For: 2.4
>
>
> Need to update the following doc 
> [https://apacheignite-sql.readme.io/v2.3/docs/specification] according to the 
> newly implemented features in 2.4.



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

[jira] [Commented] (IGNITE-7825) ODBC: Update specification documentation

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7825:
-

Got you. [~pgarg] , could you briefly check the whole doc?

> ODBC: Update specification documentation
> 
>
> Key: IGNITE-7825
> URL: https://issues.apache.org/jira/browse/IGNITE-7825
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: documentation, odbc
> Fix For: 2.4
>
>
> Need to update the following doc 
> [https://apacheignite-sql.readme.io/v2.3/docs/specification] according to the 
> newly implemented features in 2.4.



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

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

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7816:
-

[~NIzhikov] , can't we just import {{ignite-spark}} instead of listing all the 
jars this module and your examples depend on one? Also how to deal with the 
situation when different scala or Spark versions are used, wouldn't it cause 
any problems with the examples? [~dpavlov] , please step in.

> 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
>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-7665) .NET: Target .NET Standard 2.0

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7665:


Related: 
https://blogs.msdn.microsoft.com/dotnet/2017/11/16/announcing-the-windows-compatibility-pack-for-net-core/

> .NET: Target .NET Standard 2.0
> --
>
> Key: IGNITE-7665
> URL: https://issues.apache.org/jira/browse/IGNITE-7665
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, xplat
> Fix For: 2.5
>
>
> As explained in IGNITE-2662 and 
> https://apacheignite-net.readme.io/v2.4/docs/cross-platform-support, our 
> projects/assemblies still target .NET 4.0.
> This simplifies build/release procedures, but has issues:
> * Ignite.NET *can't be used from .NET Standard 2.0 libraries* (big one)
> * Warning is displayed
> * Incompatible API usages may sneak in despite tests
> We should target {{netstandard2.0}} as well as .NET 4. Release package should 
> contain two set of assemblies.



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

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

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-7816 at 2/28/18 6:19 PM:
--

[~dmagda] 

I've closed my PR by mistake.
So I created a new one - https://github.com/apache/ignite/pull/3590

Note, I've done different changes, just to enable test of Spark examples on TC.

Please, take a look.


was (Author: nizhikov):
[~dmagda] 

I've closed my PR by mistake.
So I created a new one - https://github.com/apache/ignite/pull/3590
I fixed pom.xml and test suites to make Spark examples runnable on TC.
Please, take a look.

> 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
>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

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7816:
-

[~dmagda] 

I've closed my PR by mistake.
So I created a new one - https://github.com/apache/ignite/pull/3590
I fixed pom.xml and test suites to make Spark examples runnable on TC.
Please, take a look.

> 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
>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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7816:


GitHub user nizhikov opened a pull request:

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

IGNITE-7816: Update profile to execute spark examples on TC



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

$ git pull https://github.com/nizhikov/ignite IGNITE-7816

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

https://github.com/apache/ignite/pull/3590.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 #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
>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] [Created] (IGNITE-7850) Download page must link to KEYS and contain verification details

[Sebb (JIRA)]

Sebb created IGNITE-7850:


 Summary: Download page must link to KEYS and contain verification 
details
 Key: IGNITE-7850
 URL: https://issues.apache.org/jira/browse/IGNITE-7850
 Project: Ignite
  Issue Type: Bug
Reporter: Sebb


The download page has links to the ASC and SHA files.

However there is no link to the KEYS file needed to actually use the ASC (pgp) 
file, nor are there any instructions on how to verify downloads.

See https://tomcat.apache.org/download-90.cgi#Release_Integrity for an example 
of how to do it.



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

[jira] [Updated] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

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

Kevin Jin updated IGNITE-7849:
--
Description: 
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{code:title=IgniteContinuousQueryExample.java|borderStyle=solid}
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.cache.query.ContinuousQuery;
import org.apache.ignite.cache.query.QueryCursor;
import org.apache.ignite.cache.query.ScanQuery;
import javax.cache.Cache;
import javax.cache.event.CacheEntryEvent;

public class IgniteContinuousQueryExample {
private static final String CLUSTER = "TESTGRID";
private static final String TABLE = "TESTTABLE";

private static boolean isInteresting(Integer key, String value) {
return key > 10;
}

private static boolean isInteresting(CacheEntryEvent event) {
return isInteresting(event.getKey(), event.getValue());
}

private static void handleEntry(Cache.Entry event) {
System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());
}

private static void handleExistingEntries(Iterable> events) {
events.forEach(IgniteContinuousQueryExample::handleEntry);
}

public static void main(String[] args) throws InterruptedException {
try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {
for (int i = 0; i < 20; i++)
cache.put(i, Integer.toString(i));

ContinuousQuery query = new ContinuousQuery<>();
query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);
query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));


query.setLocalListener(IgniteContinuousQueryExample::handleExistingEntries);
try (QueryCursor> resultSet = 
cache.query(query)) {
handleExistingEntries(resultSet);

// Local listener callbacks will no longer be received once 
resultSet is closed so
//  these updates have to be inside the try-with-resources 
block and we have to wait
//  to close resultSet after the final update.
for (int i = 20; i < 30; i++)
cache.put(i, Integer.toString(i));

Thread.sleep(6);
}
}
}
}
{code}

However, this becomes more inconvenient when we want to use SqlQuery in the 
initial query to take advantage of indexing. This is the best that I can do:

{noformat}
query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));
{noformat}

This is obviously not ideal because we have to specify the predicate in two 
different ways. A quick Google revealed that there are products out there that 
more seamlessly support this use case of continuous querying. I understand that 
Ignite isn't built on top of SQL, unlike the commercial RDBMSes I found, so 
maybe this is an out-of-scope feature.

  was:
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{code:title=IgniteContinuousQueryExample.java|borderStyle=solid}
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.cache.query.ContinuousQuery;
import org.apache.ignite.cache.query.QueryCursor;
import org.apache.ignite.cache.query.ScanQuery;
import javax.cache.Cache;
import javax.cache.event.CacheEntryEvent;

public class IgniteContinuousQueryExample {
private static final String CLUSTER = "TESTGRID";
private static final String TABLE = "TESTTABLE";

private static boolean isInteresting(Integer key, String value) {
return key > 10;
}

private static boolean isInteresting(CacheEntryEvent event) {
return isInteresting(event.getKey(), event.getValue());
}

private static void handleEntry(Cache.Entry event) {
System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());
}

private static void handleExistingEntries(Iterable> events) {
events.forEach(IgniteContinuousQueryExample::handleEntry);
}

public static void main(String[] args) throws InterruptedException {
try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {
for (int i = 0; i < 20; i++)
cache.put(i, Integer.toString(i));

[jira] [Updated] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

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

Kevin Jin updated IGNITE-7849:
--
Description: 
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{code:title=IgniteContinuousQueryExample.java|borderStyle=solid}
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.Ignition;
import org.apache.ignite.cache.query.ContinuousQuery;
import org.apache.ignite.cache.query.QueryCursor;
import org.apache.ignite.cache.query.ScanQuery;
import javax.cache.Cache;
import javax.cache.event.CacheEntryEvent;

public class IgniteContinuousQueryExample {
private static final String CLUSTER = "TESTGRID";
private static final String TABLE = "TESTTABLE";

private static boolean isInteresting(Integer key, String value) {
return key > 10;
}

private static boolean isInteresting(CacheEntryEvent event) {
return isInteresting(event.getKey(), event.getValue());
}

private static void handleEntry(Cache.Entry event) {
System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());
}

private static void handleExistingEntries(Iterable> events) {
events.forEach(IgniteContinuousQueryExample::handleEntry);
}

public static void main(String[] args) throws InterruptedException {
try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {
for (int i = 0; i < 20; i++)
cache.put(i, Integer.toString(i));

ContinuousQuery query = new ContinuousQuery<>();
query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);
query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));


query.setLocalListener(IgniteContinuousQueryExample::handleExistingEntries);
try (QueryCursor> resultSet = 
cache.query(query)) {
handleExistingEntries(resultSet);

// Local listener callbacks will no longer be received once 
resultSet is closed so
//  these updates have to be inside the try-with-resources 
block and we have to wait
//  to close resultSet after the final update.
for (int i = 20; i < 30; i++)
cache.put(i, Integer.toString(i));

Thread.sleep(6);
}
}
}
}
{code}

However, this becomes more inconvenient when we want to use SqlQuery in the 
initial query to take advantage of indexing. This is the best that I can do:

query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
 query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));

This is obviously not ideal because we have to specify the predicate in two 
different ways. A quick Google revealed that there are products out there that 
more seamlessly support this use case of continuous querying. I understand that 
Ignite isn't built on top of SQL, unlike the commercial RDBMSes I found, so 
maybe this is an out-of-scope feature.

  was:
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
 {{import org.apache.ignite.IgniteCache;}}
 {{import org.apache.ignite.Ignition;}}
 {{import org.apache.ignite.cache.query.ContinuousQuery;}}
 {{import org.apache.ignite.cache.query.QueryCursor;}}
 {{import org.apache.ignite.cache.query.ScanQuery;}}
 {{import javax.cache.Cache;}}
 {{import javax.cache.event.CacheEntryEvent;}}
 {{public class IgniteContinuousQueryExample {}}
   \{{private static final String CLUSTER = "TESTGRID";}}
   \{{private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
 \{{ return key > 10;}}
 {

{   }}}
 {{  private static boolean isInteresting(CacheEntryEvent event) {}}
 \{{ return isInteresting(event.getKey(), event.getValue());}}
 \{{   }

}}
 {{  private static void handleEntry(Cache.Entry event) {}}
 \{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
 {

{   }}}
 
 {{  }}{{private static void handleResultSet(Iterable> events) {}}
 \{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
 \{{   }

}}
 {{  public static void main(String[] args) throws InterruptedException {}}
 \{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
 \{{   for (int i = 0; i < 20; i++)}}
 \{{ cache.put(i, Integer.toString());}}

{{  

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

[Maxim Muzafarov (JIRA)]

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

Maxim Muzafarov commented on IGNITE-7789:
-

Generally this test fails because of method:
{quote}doTestIgniteOperationOnDisconnect(Ignite client, final List>> ops)
{quote}
executes operations in this List<> not in that order in which they are put in. 
So, for the first case:

1) Assertion error in test-case: 
 Here we try to invoke operation here [return dfltCache.invoke(1, new 
CacheEntryProcessor()|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectApiExceptionTest.java#L341]
 and expect that key 10_000 already exists in cache (added in previous 
opertation in List), but in some cases it not because of execution order.

2) IgniteCheckedException from CacheProcessor on dynamic cache start
 Same situation. For method [public void dataStructureOperationsTest() throws 
Exception 
|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/IgniteClientReconnectApiExceptionTest.java#L97]
 we have execution plan:
{quote}OK - test case
 [2018-02-27 15:51:05,065][INFO ][async-callable-runner-1][root] Queue creation
 [2018-02-27 15:51:05,065][INFO ][async-callable-runner-1][root] Set creation
 [2018-02-27 15:51:05,065][INFO ][async-callable-runner-1][root] Atomic creation

FAIL - test case
 [2018-02-27 15:52:23,304][INFO ][async-callable-runner-1][root] Atomic creation
 [2018-02-27 15:52:23,304][INFO ][async-callable-runner-1][root] Queue creation
 [2018-02-27 15:52:23,303][INFO ][async-callable-runner-1][root] Set creation
{quote}
 and also number of default backups for [AtomicConfiguration 
|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/AtomicConfiguration.java#L32]
 and [CollectionConfiguration 
|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CollectionConfiguration.java#L47]
 are different:
{quote}CollectionConfiguration we have default backup = 0;
AtomicConfiguration we have DFLT_BACKUPS = 1;
{quote}
 

I suggest to rewrite hole test in the correct way, but I think this is for 
another task.

> 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 
> 

[jira] [Updated] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

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

Kevin Jin updated IGNITE-7849:
--
Description: 
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
 {{import org.apache.ignite.IgniteCache;}}
 {{import org.apache.ignite.Ignition;}}
 {{import org.apache.ignite.cache.query.ContinuousQuery;}}
 {{import org.apache.ignite.cache.query.QueryCursor;}}
 {{import org.apache.ignite.cache.query.ScanQuery;}}
 {{import javax.cache.Cache;}}
 {{import javax.cache.event.CacheEntryEvent;}}
 {{public class IgniteContinuousQueryExample {}}
   \{{private static final String CLUSTER = "TESTGRID";}}
   \{{private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
 \{{ return key > 10;}}
 {

{   }}}
 {{  private static boolean isInteresting(CacheEntryEvent event) {}}
 \{{ return isInteresting(event.getKey(), event.getValue());}}
 \{{   }

}}
 {{  private static void handleEntry(Cache.Entry event) {}}
 \{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
 {

{   }}}
 
 {{  }}{{private static void handleResultSet(Iterable> events) {}}
 \{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
 \{{   }

}}
 {{  public static void main(String[] args) throws InterruptedException {}}
 \{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
 \{{   for (int i = 0; i < 20; i++)}}
 \{{ cache.put(i, Integer.toString());}}

{{  }}{{ContinuousQuery query = new ContinuousQuery<>();}}
 \{{   query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);}}
 \{{   query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));}}

{{  
}}{{query.setLocalListener(IgniteContinuousQueryExample::handleResultSet);}}
 \{{   try (QueryCursor> resultSet = 
cache.query(query)) {}}
 \{{     handleResultSet(resultSet);}}

{{for (int i = 20; i < 30; i++)}}
 \{{   cache.put(i, Integer.toString());}}{{Thread.sleep(6);}}
 {

{   }

}}
 {

{ }

}}
 {

{   }

}}
 {{}}}

However, this becomes more inconvenient when we want to use SqlQuery in the 
initial query to take advantage of indexing. This is the best that I can do:

query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
 query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));

This is obviously not ideal because we have to specify the predicate in two 
different ways. A quick Google revealed that there are products out there that 
more seamlessly support this use case of continuous querying. I understand that 
Ignite isn't built on top of SQL, unlike the commercial RDBMSes I found, so 
maybe this is an out-of-scope feature.

  was:
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
 {{import org.apache.ignite.IgniteCache;}}
 {{import org.apache.ignite.Ignition;}}
 {{import org.apache.ignite.cache.query.ContinuousQuery;}}
 {{import org.apache.ignite.cache.query.QueryCursor;}}
 {{import org.apache.ignite.cache.query.ScanQuery;}}
 {{import javax.cache.Cache;}}
 {{import javax.cache.event.CacheEntryEvent;}}
 {{public class IgniteContinuousQueryExample {}}
 \{{   private static final String CLUSTER = "TESTGRID";}}
 \{{   private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
 \{{ return key > 10;}}
 \{{   }}}
 {{  private static boolean isInteresting(CacheEntryEvent event) {}}
 \{{ return isInteresting(event.getKey(), event.getValue());}}
 \{{   }}}
 {{  private static void handleEntry(Cache.Entry event) {}}
 \{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
 \{{   }}}

{{  }}{{private static void handleResultSet(Iterable> events) {}}
 \{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
 \{{   }}}
 {{  public static void main(String[] args) throws InterruptedException {}}
 \{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
 \{{   for (int i = 0; i < 20; i++)}}
 \{{ cache.put(i, Integer.toString());}}

{{  }}{{ContinuousQuery query = new ContinuousQuery<>();}}
 \{{   query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);}}
 \{{   query.setInitialQuery(new 

[jira] [Updated] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

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

Kevin Jin updated IGNITE-7849:
--
Description: 
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
 {{import org.apache.ignite.IgniteCache;}}
 {{import org.apache.ignite.Ignition;}}
 {{import org.apache.ignite.cache.query.ContinuousQuery;}}
 {{import org.apache.ignite.cache.query.QueryCursor;}}
 {{import org.apache.ignite.cache.query.ScanQuery;}}
 {{import javax.cache.Cache;}}
 {{import javax.cache.event.CacheEntryEvent;}}
 {{public class IgniteContinuousQueryExample {}}
 \{{   private static final String CLUSTER = "TESTGRID";}}
 \{{   private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
 \{{ return key > 10;}}
 \{{   }}}
 {{  private static boolean isInteresting(CacheEntryEvent event) {}}
 \{{ return isInteresting(event.getKey(), event.getValue());}}
 \{{   }}}
 {{  private static void handleEntry(Cache.Entry event) {}}
 \{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
 \{{   }}}

{{  }}{{private static void handleResultSet(Iterable> events) {}}
 \{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
 \{{   }}}
 {{  public static void main(String[] args) throws InterruptedException {}}
 \{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
 \{{   for (int i = 0; i < 20; i++)}}
 \{{ cache.put(i, Integer.toString());}}

{{  }}{{ContinuousQuery query = new ContinuousQuery<>();}}
 \{{   query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);}}
 \{{   query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));}}

{{  
}}{{query.setLocalListener(IgniteContinuousQueryExample::handleResultSet);}}
 \{{   try (QueryCursor> resultSet = 
cache.query(query)) {}}
 \{{     handleResultSet(resultSet);}}

{{for (int i = 20; i < 30; i++)}}
 \{{   cache.put(i, Integer.toString());}}{{Thread.sleep(6);}}
 \{{   }}}
 \{{ }}}
 \{{   }}}
 {{}}}

However, this becomes more inconvenient when we want to use SqlQuery in the 
initial query to take advantage of indexing. This is the best that I can do:

query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
 query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));

This is obviously not ideal because we have to specify the predicate in two 
different ways. A quick Google revealed that there are products out there that 
more seamlessly support this use case of continuous querying. I understand that 
Ignite isn't built on top of SQL, unlike the commercial RDBMSes I found, so 
maybe this is an out-of-scope feature.

  was:
Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
{{import org.apache.ignite.IgniteCache;}}
{{import org.apache.ignite.Ignition;}}
{{import org.apache.ignite.cache.query.ContinuousQuery;}}
{{import org.apache.ignite.cache.query.QueryCursor;}}
{{import org.apache.ignite.cache.query.ScanQuery;}}
{{import javax.cache.Cache;}}
{{import javax.cache.event.CacheEntryEvent;}}
{{public class IgniteContinuousQueryExample {}}
{{   private static final String CLUSTER = "TESTGRID";}}
{{   private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
{{ return key > 10;}}
{{   }}}
{{  private static boolean isInteresting(CacheEntryEvent event) {}}
{{ return isInteresting(event.getKey(), event.getValue());}}
{{   }}}
{{  private static void handleEntry(Cache.Entry event) {}}
{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
{{   }}}

{{  }}{{private static void handleResultSet(Iterable> events) {}}
{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
{{   }}}
{{  public static void main(String[] args) throws InterruptedException {}}
{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
{{   for (int i = 0; i < 20; i++)}}
{{ cache.put(i, Integer.toString(i));}}

{{  }}{{ContinuousQuery query = new ContinuousQuery<>();}}
{{   query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);}}
{{   query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));}}

{{  

[jira] [Created] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

Kevin Jin created IGNITE-7849:
-

 Summary: Generating a CacheEntryEventFilter from a SqlQuery
 Key: IGNITE-7849
 URL: https://issues.apache.org/jira/browse/IGNITE-7849
 Project: Ignite
  Issue Type: Wish
  Components: cache, sql
Affects Versions: 2.3
Reporter: Kevin Jin
 Fix For: None


Currently when we want to use the same predicate for the continuous query and 
initial query, it's easy enough to write something like this, assuming we are 
fine with the performance of ScanQuery:

{{import org.apache.ignite.Ignite;}}
{{import org.apache.ignite.IgniteCache;}}
{{import org.apache.ignite.Ignition;}}
{{import org.apache.ignite.cache.query.ContinuousQuery;}}
{{import org.apache.ignite.cache.query.QueryCursor;}}
{{import org.apache.ignite.cache.query.ScanQuery;}}
{{import javax.cache.Cache;}}
{{import javax.cache.event.CacheEntryEvent;}}
{{public class IgniteContinuousQueryExample {}}
{{   private static final String CLUSTER = "TESTGRID";}}
{{   private static final String TABLE = "TESTTABLE";}}

{{  }}{{private static boolean isInteresting(Integer key, String value) {}}
{{ return key > 10;}}
{{   }}}
{{  private static boolean isInteresting(CacheEntryEvent event) {}}
{{ return isInteresting(event.getKey(), event.getValue());}}
{{   }}}
{{  private static void handleEntry(Cache.Entry event) {}}
{{ System.out.println("Received value for " + event.getKey() + ": " + 
event.getValue());}}
{{   }}}

{{  }}{{private static void handleResultSet(Iterable> events) {}}
{{ events.forEach(IgniteContinuousQueryExample::handleEntry);}}
{{   }}}
{{  public static void main(String[] args) throws InterruptedException {}}
{{ try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache cache = client.cache(TABLE)) {}}
{{   for (int i = 0; i < 20; i++)}}
{{ cache.put(i, Integer.toString(i));}}

{{  }}{{ContinuousQuery query = new ContinuousQuery<>();}}
{{   query.setRemoteFilterFactory(() -> 
IgniteContinuousQueryExample::isInteresting);}}
{{   query.setInitialQuery(new 
ScanQuery<>(IgniteContinuousQueryExample::isInteresting));}}

{{  
}}{{query.setLocalListener(IgniteContinuousQueryExample::handleResultSet);}}
{{   try (QueryCursor> resultSet = 
cache.query(query)) {}}
{{     handleResultSet(resultSet);}}

{{for (int i = 20; i < 30; i++)}}
{{   cache.put(i, Integer.toString(i));}}{{Thread.sleep(6);}}
{{   }}}
{{ }}}
{{   }}}
{{}}}

However, this becomes more inconvenient when we want to use SqlQuery in the 
initial query to take advantage of indexing. This is the best that I can do:

query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
 query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));

This is obviously not ideal because we have to specify the predicate in two 
different ways. A quick Google revealed that there are products out there that 
more seamlessly support this use case of continuous querying. I understand that 
Ignite isn't built on top of SQL, unlike the commercial RDBMSes I found, so 
maybe this is an out-of-scope feature.



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

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

[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 DDL functionality (SELECT) is broken  (was: when Date type in 
value object is originally set as java.util.Date, then  after CREATE INDEX SQL 
queries (see attach), 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 DDL 
> functionality (SELECT) is broken



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

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

[Andrew Medvedev (JIRA)]

Andrew Medvedev created IGNITE-7848:
---

 Summary: 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
 Attachments: DateCannotBeCastTest.java

when Date type in value object is originally set as java.util.Date, then  after 
CREATE INDEX SQL queries (see attach), basic DDL functionality (SELECT) is 
broken



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

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

[Akmal Chaudhri (JIRA)]

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

Akmal Chaudhri reassigned IGNITE-7655:
--

Assignee: Denis Magda  (was: Akmal Chaudhri)

> 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: Denis Magda
>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-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

[Akmal Chaudhri (JIRA)]

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

Akmal Chaudhri commented on IGNITE-7655:


I have gone through the document and improved the readability and formatting.

> 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] [Resolved] (IGNITE-7383) Failed to restore memory after cluster restart and activating from outdated node

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh resolved IGNITE-7383.
--
Resolution: Won't Fix
  Assignee: Alexandr Kuramshin  (was: Ilya Lantukh)

> Failed to restore memory after cluster restart and activating from outdated 
> node
> 
>
> Key: IGNITE-7383
> URL: https://issues.apache.org/jira/browse/IGNITE-7383
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>Priority: Major
>
> Do the following steps for reproducing the problem:
> 1) start nodes 0-1-2
> 2) stop node 2
> 3) create a new cache and put some data into it
> 4) stop remaining nodes 0-1
> 5) start nodes 0-1-2
> 6) activate the cluster from the node 2
> Then 2 different results could be taken depending on which node is 
> coordinator:
> a) node 2 is a coordinator:
> {noformat}
> Failed to activate node components 
> [nodeId=42d762c7-b1e0-4283-939b-aeeb3c70, client=false, 
> topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1]]
> class org.apache.ignite.IgniteCheckedException: Failed to find cache group 
> descriptor [grpId=3119]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.getPageMemoryForCacheGroup(GridCacheDatabaseSharedManager.java:1602)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> and activation will be failed.
> b) node 2 is NOT a coordinator:
> we will get an error from the previous version, but the activation process 
> will not be failed and then we will take "Failed to wait PME" after a number 
> of assertions
> {noformat}
> Failed to process message [senderId=a940742f-bf17-41b4-bfc2-728bee72, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsSingleMessage]
> java.lang.AssertionError: -2100569601
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.clientTopology(GridCachePartitionExchangeManager.java:733)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.updatePartitionSingleMap(GridDhtPartitionsExchangeFuture.java:2877)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:1935)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:116)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1810)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1798)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1798)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1484)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:131)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:327)
>   at 
> 

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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7843:
---
Description: The command DROP column leads to subsequent SQL errors if 
there is some indexed field next to removed field.  (was: The command DROP 
table leads to subsequent SQL errors if there is some indexed field next to 
removed field.)

> 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
>
> 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] [Commented] (IGNITE-7831) Throw Exceptions instead of AssertionErrors when reading from corrupted persistence

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7831:
-

[~ilantukh], could you please give more details about the issue? What cases do 
you mean exactly? Are there any proposed solutions? Etc.

> 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
>
> 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.



--
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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-7843:


[~vozerov], Could you please review the fix?

> 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
>
> The command DROP table 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] [Commented] (IGNITE-7789) Ignite Client Nodes: failed test IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7789:


GitHub user Mmuzaf opened a pull request:

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

IGNITE-7789: fix IgniteClientReconnectApiExceptionTest, success rate 47.9%

Add backups value for CollectionConfiguration

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

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

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

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


commit 5fc300913d3f56a44faf1996c71285261cf1759a
Author: Maxim Muzafarov 
Date:   2018-02-28T14:22:09Z

IGNITE-7789: set backups value for CollectionConfiguration

commit c047db72c929c9834a12584618149f87e1b0370a
Author: Maxim Muzafarov 
Date:   2018-02-28T14:28:07Z

IGNITE-7789: use DFLT_BACKUPS constant for CollectionConfiguration




> 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 
> 

[jira] [Updated] (IGNITE-7847) Increase of total owning partition count after rebalance

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7847:
-
Fix Version/s: 2.5

> Increase of total owning partition count after rebalance
> 
>
> Key: IGNITE-7847
> URL: https://issues.apache.org/jira/browse/IGNITE-7847
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.5
>
>
> 1) Start 3 nodes with persistence enabled
> 2) Activate grid
> 3) Create cache with 1 backup and remember owning partition count on node1
> 4) Stop node2, set BLT and note that local owning partitions on node1 
> increased (to total number of partitions on cache)
> 5) Start node, set BLT and waitRebalance and
> Expected: owning partitions count on node1 became as on step 3
> Actual: owning partitions count on node1 still equals to step 4 value



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

[jira] [Assigned] (IGNITE-7847) Increase of total owning partition count after rebalance

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7847:


Assignee: Alexey Goncharuk

> Increase of total owning partition count after rebalance
> 
>
> Key: IGNITE-7847
> URL: https://issues.apache.org/jira/browse/IGNITE-7847
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Alexander Belyak
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.5
>
>
> 1) Start 3 nodes with persistence enabled
> 2) Activate grid
> 3) Create cache with 1 backup and remember owning partition count on node1
> 4) Stop node2, set BLT and note that local owning partitions on node1 
> increased (to total number of partitions on cache)
> 5) Start node, set BLT and waitRebalance and
> Expected: owning partitions count on node1 became as on step 3
> Actual: owning partitions count on node1 still equals to step 4 value



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

[jira] [Created] (IGNITE-7847) Increase of total owning partition count after rebalance

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7847:


 Summary: Increase of total owning partition count after rebalance
 Key: IGNITE-7847
 URL: https://issues.apache.org/jira/browse/IGNITE-7847
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


1) Start 3 nodes with persistence enabled

2) Activate grid

3) Create cache with 1 backup and remember owning partition count on node1

4) Stop node2, set BLT and note that local owning partitions on node1 increased 
(to total number of partitions on cache)

5) Start node, set BLT and waitRebalance and

Expected: owning partitions count on node1 became as on step 3

Actual: owning partitions count on node1 still equals to step 4 value



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

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

[Maxim Muzafarov (JIRA)]

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

Maxim Muzafarov reassigned IGNITE-7789:
---

Assignee: Maxim Muzafarov

> 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: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@511c0beb
> at 
> 

[jira] [Issue Comment Deleted] (IGNITE-7846) SQL: support COPY command by native SQL

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-7846:
-
Comment: was deleted

(was: [~vozerov], [~al.psc], please review the patch.)

> SQL: support COPY command by native SQL
> ---
>
> Key: IGNITE-7846
> URL: https://issues.apache.org/jira/browse/IGNITE-7846
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> The COPY command is supported only for JDBC client (IGNITE-6917).
> It must be supported by native SQL API.



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

[jira] [Commented] (IGNITE-7029) Add an ability to provide multiple connection addresses for thin JDBC driver

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7029:
--

[~vozerov], [~al.psc], please review the patch.

> Add an ability to provide multiple connection addresses for thin JDBC driver
> 
>
> Key: IGNITE-7029
> URL: https://issues.apache.org/jira/browse/IGNITE-7029
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Major
>
> Currently we allow only to provide one address when connecting via thin JDBC 
> driver. This has to issues:
> * If node driver is connected to goes down, the driver stops working.
> * Driver has to always go though the same node - this is a bottleneck.
> As a simple solution we can allow to provide multiple addresses, like MySQL 
> does for example: 
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html



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

[jira] [Commented] (IGNITE-7846) SQL: support COPY command by native SQL

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7846:
--

[~vozerov], [~al.psc], please review the patch.

> SQL: support COPY command by native SQL
> ---
>
> Key: IGNITE-7846
> URL: https://issues.apache.org/jira/browse/IGNITE-7846
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> The COPY command is supported only for JDBC client (IGNITE-6917).
> It must be supported by native SQL API.



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

[jira] [Commented] (IGNITE-7282) .NET: Thin client: Failover

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7282:


Merged with recent master. [~vozerov] please review.

> .NET: Thin client: Failover
> ---
>
> Key: IGNITE-7282
> URL: https://issues.apache.org/jira/browse/IGNITE-7282
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Currently user has to manually connect to some specific Ignite server.
> Implement some kind of automatic failover where Thin Client knows about 
> multiple nodes.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5553:


GitHub user xtern opened a pull request:

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

IGNITE-5553 Restore IgniteSet local data when PDS enabled.



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

$ git pull https://github.com/xtern/ignite IGNITE-5553

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

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


commit 8e01cf250d4f4cd06d2b3c44612b439410745219
Author: pereslegin-pa 
Date:   2018-02-28T09:27:57Z

IGNITE-5553 PDS restore local set data.




> 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-7843) SQL: ALTER TABLE DROP column may break certain SQL queries

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7843:


GitHub user skalashnikov opened a pull request:

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

IGNITE-7843: refresh index column ids on DROP COLUMN.



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

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

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

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


commit f96e51fe11c9ca141f1482dbfa7c2256ab32d5e9
Author: skalashnikov 
Date:   2018-02-28T13:40:20Z

IGNITE-7843: refresh index column ids on DROP COLUMN.




> 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
>
> The command DROP table 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] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7774:


[~vveider], thank you!

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]:
>  No default constructor found; nested 

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Peter Ivanov (JIRA)]

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

Peter Ivanov commented on IGNITE-7774:
--

[~guseinov], [~dpavlov] -- I'll look through the problem and review PR by the 
end of the week.

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> 

[jira] [Updated] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-7774:
-
Fix Version/s: (was: 2.3)
   2.5

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]:
>  No default constructor found; nested exception is 
> 

[jira] [Updated] (IGNITE-7846) SQL: support COPY command by native SQL

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-7846:
-
Summary: SQL: support COPY command by native SQL  (was: SQL: support COPY 
command by native SQL api)

> SQL: support COPY command by native SQL
> ---
>
> Key: IGNITE-7846
> URL: https://issues.apache.org/jira/browse/IGNITE-7846
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> The COPY command is supported only for JDBC client (IGNITE-6917).
> It must be supported by native SQL API.



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

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7774:


[~vveider], could you take a look to PR 
https://github.com/apache/ignite/pull/3567 ? It changes poms and may affect 
release.

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.3
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> 

[jira] [Created] (IGNITE-7846) SQL: support COPY command by native SQL api

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-7846:


 Summary: SQL: support COPY command by native SQL api
 Key: IGNITE-7846
 URL: https://issues.apache.org/jira/browse/IGNITE-7846
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.3
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.5


The COPY command is supported only for JDBC client (IGNITE-6917).
It must be supported by native SQL API.



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

[jira] [Commented] (IGNITE-7572) Local cache fails to start on client node

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7572:


[~dkarachentsev], please use run all for PR. Ignite is quite complex product, 
changes in any its core part may cause unexpected test failures.

> Local cache fails to start on client node
> -
>
> Key: IGNITE-7572
> URL: https://issues.apache.org/jira/browse/IGNITE-7572
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
>
> Client node doesn't have default configuration for data region and fails to 
> start local cache with the following exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7272)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.onKernalStart(GridCachePartitionExchangeManager.java:625)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:819)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1041)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> ... 1 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.CacheGroupContext.(CacheGroupContext.java:203)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:1971)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1869)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1759)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:744)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:626)
> 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:748)
> {noformat}
> Reproducer:
>  
> {code:java}
> import java.util.Arrays;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.jetbrains.annotations.NotNull;
> public class LocalCache {
> private static int id;
> public static void main(String[] args) throws InterruptedException {
> Ignition.setClientMode(false);
> Ignite server = Ignition.start(getConfiguration());
> System.out.println("Server is up");
> Ignition.setClientMode(true);
> Ignite client = Ignition.start(getConfiguration());
> System.out.println("Client is up");
> }
> @NotNull private static IgniteConfiguration getConfiguration() {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration("TEST");
> cacheConfiguration.setCacheMode(CacheMode.LOCAL);
> cfg.setCacheConfiguration(cacheConfiguration);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7718:


[~pvinokurov], are there any news on this issue?

> 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] [Comment Edited] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk edited comment on IGNITE-6083 at 2/28/18 1:12 PM:
---

[~Alexey Kuznetsov] Please note that 
IgnitePutAllLargeBatchSelfTest (Ignite Cache suite) and 
AtomicLongTest.TestMultithreaded (two .net suites) are consistently failing in 
your PR. Please take a look.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteCache_IgniteTests24Java8=pull%2F3546%2Fhead=buildTypeStatusDiv


was (Author: agoncharuk):
[~Alexey Kuznetsov] Please note that 
IgnitePutAllLargeBatchSelfTest (Ignite Cache 4 suite) and 
AtomicLongTest.TestMultithreaded (two .net suites) are consistently failing in 
your PR. Please take a look.

> Null value have appear in the entry processor, but the entry is existing
> 
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute 
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}} 
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at 
> second.



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

[jira] [Commented] (IGNITE-6083) Null value have appear in the entry processor, but the entry is existing

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6083:
--

[~Alexey Kuznetsov] Please note that 
IgnitePutAllLargeBatchSelfTest (Ignite Cache 4 suite) and 
AtomicLongTest.TestMultithreaded (two .net suites) are consistently failing in 
your PR. Please take a look.

> Null value have appear in the entry processor, but the entry is existing
> 
>
> Key: IGNITE-6083
> URL: https://issues.apache.org/jira/browse/IGNITE-6083
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Attachments: EntryProcessorInOptimisticTxTest.java
>
>
> In one thread load some data in a cache, after that I have execute 
> OPTIMISTIC, SERIALIZABLE transaction with two {{IgniteCache.invoke()}} 
> methods.
> The value had been corrected at first {{EntryProcessor}}, but it is NULL at 
> second.



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

[jira] [Commented] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-7832:
--

[~dpavlov],

I've go deeper in investigation and change ticket content.

It is general issue, seem an architectural lack.

> Ignite.resetLostPartitions() resets state under race.
> -
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> Assume, we have event listener that detects partition loss events and apply 
> some actions to recover lost data.
> After recovery process finished an Ignite.resetLostPartitions() method should 
> be called to mark all lost cache partitions as healthy.
> It is possible Ignite.resetLostPartitions() will be called during exchange, 
> but right before a new partition loss event will be fired.
> E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in 
> detectLostPartitions() method, while user thread will wait for the lock 
> inside Ignite.resetLostPartitions().
> So, after a new partition loss will be detected, is will be not possible to 
> abort user action and state of just lost partition will be reset.
> For that case, we should either abort resetLostPartitions() or reset 
> partitions state regarding topology version provided by user some how.



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

[jira] [Updated] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-7832:
-
Description: 
Assume, we have event listener that detects partition loss events and apply 
some actions to recover lost data.
After recovery process finished an Ignite.resetLostPartitions() method should 
be called to mark all lost cache partitions as healthy.

It is possible Ignite.resetLostPartitions() will be called during exchange, but 
right before a new partition loss event will be fired.

E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in 
detectLostPartitions() method, while user thread will wait for the lock inside 
Ignite.resetLostPartitions().
So, after a new partition loss will be detected, is will be not possible to 
abort user action and state of just lost partition will be reset.


For that case, we should either abort resetLostPartitions() or reset partitions 
state regarding topology version provided by user some how.

  was:
Steps to reproduce:
 # Start 3 nodes with Partitioned cache with no backups.
 Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
 PartitionLossPolicy should be smth other then IGNORED (which is default).
 # Put some data and make sure rebalance is finished.
 # Kill first node.
 I observe partition lost events on 2-nd node only, however, some of lost 
partitions should be owned by 3-rd node regarding a new topology. 
 Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
 # Kill 2-nd node.
 No partition lost events will be fired on 3-rd node. However data is obviously 
lost.
 Cache.lostPartitions() returns empty resultset.

Looks like partition lost events mechanics is broken and should be fixed.


> Ignite.resetLostPartitions() resets state under race.
> -
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> Assume, we have event listener that detects partition loss events and apply 
> some actions to recover lost data.
> After recovery process finished an Ignite.resetLostPartitions() method should 
> be called to mark all lost cache partitions as healthy.
> It is possible Ignite.resetLostPartitions() will be called during exchange, 
> but right before a new partition loss event will be fired.
> E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in 
> detectLostPartitions() method, while user thread will wait for the lock 
> inside Ignite.resetLostPartitions().
> So, after a new partition loss will be detected, is will be not possible to 
> abort user action and state of just lost partition will be reset.
> For that case, we should either abort resetLostPartitions() or reset 
> partitions state regarding topology version provided by user some how.



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

[jira] [Reopened] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov reopened IGNITE-7832:
--

> Ignite.resetLostPartitions() resets state under race.
> -
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> Assume, we have event listener that detects partition loss events and apply 
> some actions to recover lost data.
> After recovery process finished an Ignite.resetLostPartitions() method should 
> be called to mark all lost cache partitions as healthy.
> It is possible Ignite.resetLostPartitions() will be called during exchange, 
> but right before a new partition loss event will be fired.
> E.g. exchange thread own GridDhtPartitionTopologyImpl write lock in 
> detectLostPartitions() method, while user thread will wait for the lock 
> inside Ignite.resetLostPartitions().
> So, after a new partition loss will be detected, is will be not possible to 
> abort user action and state of just lost partition will be reset.
> For that case, we should either abort resetLostPartitions() or reset 
> partitions state regarding topology version provided by user some how.



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

[jira] [Updated] (IGNITE-7832) Ignite.resetLostPartitions() resets state under race.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-7832:
-
Summary: Ignite.resetLostPartitions() resets state under race.  (was: 
Partition lost events looks broken.)

> Ignite.resetLostPartitions() resets state under race.
> -
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only, however, some of lost 
> partitions should be owned by 3-rd node regarding a new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



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

[jira] [Commented] (IGNITE-7029) Add an ability to provide multiple connection addresses for thin JDBC driver

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7029:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7029  Add an ability to provide multiple connection addresses for 
thin JDBC driver



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

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

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

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


commit bc1efe5f514f576bcd16f009ef2e3b3ffc661487
Author: tledkov-gridgain 
Date:   2018-02-27T12:48:24Z

IGNITE-7029: add multiple connect addresses

commit 9d17bef8873c935a431d800c7f1beb778d768a09
Author: tledkov-gridgain 
Date:   2018-02-27T16:22:04Z

Merge branch '_master' into ignite-7029

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/ConnectionPropertiesImpl.java
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/JdbcThinConnection.java

commit a38ea80419c75473a39c7a9737400c9b36586e0a
Author: tledkov-gridgain 
Date:   2018-02-28T12:26:43Z

IGNITE-7029: close statements and result sets on disconnect

commit 6e8a548da0585eafaf68904c33b2dff0498f71d9
Author: tledkov-gridgain 
Date:   2018-02-28T12:26:55Z

Merge branch '_master' into ignite-7029




> Add an ability to provide multiple connection addresses for thin JDBC driver
> 
>
> Key: IGNITE-7029
> URL: https://issues.apache.org/jira/browse/IGNITE-7029
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Major
>
> Currently we allow only to provide one address when connecting via thin JDBC 
> driver. This has to issues:
> * If node driver is connected to goes down, the driver stops working.
> * Driver has to always go though the same node - this is a bottleneck.
> As a simple solution we can allow to provide multiple addresses, like MySQL 
> does for example: 
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html



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

[jira] [Created] (IGNITE-7845) Data race on atomicLong close

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-7845:
-

 Summary: Data race on atomicLong close
 Key: IGNITE-7845
 URL: https://issues.apache.org/jira/browse/IGNITE-7845
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Kalashnikov


Found by IgniteClientDataStructuresTest.testAtomicLong.

*Given:*

IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
true)

*When:*

IgniteAtomicLong was closed e.g. atomicLong.close()

*Then:*

If you try to get this value again sometimes you will get null IgniteAtomicLong 
value and sometimes you will get not null IgniteAtomicLong value e.g. 
ignite.atomicLong("long1", 1L, false) sometimes null, sometimes not null

But if we will get not null value IgniteAtomicLong and we will call method 
"get" on it, we will have one of two exception IllegalStateException("Sequence 
was removed from cache: " + name) if it already marked as deleted, and 
IgniteException("Failed to find atomic long: " + name) if it sill no marked as 
deleted but already deleted from cache.

*Expected:*

IgniteAtomicLong value always should be null(or not?)

*Why it's happend:*

When we close IgniteAtomicLong we removing value from cache in transaction but 
removing from internal storage(dsMap) happen asynchroniously in 
DataStructuresEntryListener for all nodes include local node. And when we try 
get value after close we still sometimes able to get IgniteAtomicLong from 
internal local storage.


*Solution(In my opinion):*

I guess in common case we don't  need call Ignite#atomicLong  every time when 
we need value, but we should use IgniteAtomicLong object received after first 
call. And if it is true, we can remove receiving IgniteAtomicLong from local 
storage(dsMap) - this changes will fix problem



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

[jira] [Assigned] (IGNITE-3164) Add an option to send resulting value instead of entry processor in transactional cache

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-3164:
---

Assignee: Dmitry Karachentsev

> Add an option to send resulting value instead of entry processor in 
> transactional cache
> ---
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Dmitry Karachentsev
>Priority: Major
>
> In some cases user can't guarantee that EP behaves consistently on all nodes. 
> In transactional cache this can lead to inconsistent cache, because we invoke 
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will 
> override current default behavior.
> We also need to update documentation, especially provide the explanation of 
> EP behavior in atomic and transactional caches.



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

[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible

[Dmitry Karachentsev (JIRA)]

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

Dmitry Karachentsev reassigned IGNITE-3471:
---

Assignee: Dmitry Karachentsev

> Do not send previous value to client node for invoke() when possible
> 
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Assignee: Dmitry Karachentsev
>Priority: Major
> Fix For: 2.5
>
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to 
> near node and apply EntryProcessor locally to get a return value. This can 
> induce a significant overhead when cache value is much larger than entry 
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> cache.get(key); // This should actually get the current cache value from 
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}



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

[jira] [Commented] (IGNITE-7844) Transaction incorrect state after client reconnected

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7844:


GitHub user voipp opened a pull request:

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

IGNITE-7844 Transaction incorrect state after client reconnected



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

$ git pull https://github.com/voipp/ignite IGNITE-7844

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

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


commit 38539c92ebf6ced27ffdd529b3fd9f8670babff1
Author: voipp 
Date:   2018-02-28T12:06:01Z

IGNITE-7844 Transaction incorrect state after client reconnected




> Transaction incorrect state after client reconnected
> 
>
> Key: IGNITE-7844
> URL: https://issues.apache.org/jira/browse/IGNITE-7844
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Transaction is started on client node.
>  Client reconnects, transaction rollbacks, but its state is left ACTIVE, 
> which is incorrect.



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

[jira] [Updated] (IGNITE-7844) Transaction incorrect state after client reconnected

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7844:
-
Description: 
Transaction is started on client node.
 Client reconnects, transaction rollbacks, but its state is left ACTIVE, which 
is incorrect.

  was:
Transaction is started on client node.
Client reconnects, transaction rollbacks, but its state is left ACTIVE, which 
incorrect.


> Transaction incorrect state after client reconnected
> 
>
> Key: IGNITE-7844
> URL: https://issues.apache.org/jira/browse/IGNITE-7844
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> Transaction is started on client node.
>  Client reconnects, transaction rollbacks, but its state is left ACTIVE, 
> which is incorrect.



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

[jira] [Created] (IGNITE-7844) Transaction incorrect state after client reconnected

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7844:


 Summary: Transaction incorrect state after client reconnected
 Key: IGNITE-7844
 URL: https://issues.apache.org/jira/browse/IGNITE-7844
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


Transaction is started on client node.
Client reconnects, transaction rollbacks, but its state is left ACTIVE, which 
incorrect.



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

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

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-7843:
--

 Summary: 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


The command DROP table 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] [Updated] (IGNITE-7842) testPutReaderUpdatePrimaryFails1 fails on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7842:
-
Labels: MakeTeamcityGreenAgain  (was: )

> testPutReaderUpdatePrimaryFails1 fails on TC
> 
>
> Key: IGNITE-7842
> URL: https://issues.apache.org/jira/browse/IGNITE-7842
> Project: Ignite
>  Issue Type: Test
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test fails because the transaction being tested may be non-one-phase 
> commit (a partition may be not evicted yet by the time the test starts),
> The suggested fix is to use a stronger version of 
> awaitPartitionMapExchange(boolean, boolean, List).



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

[jira] [Created] (IGNITE-7842) testPutReaderUpdatePrimaryFails1 fails on TC

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7842:


 Summary: testPutReaderUpdatePrimaryFails1 fails on TC
 Key: IGNITE-7842
 URL: https://issues.apache.org/jira/browse/IGNITE-7842
 Project: Ignite
  Issue Type: Test
  Components: cache
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.5


The test fails because the transaction being tested may be non-one-phase commit 
(a partition may be not evicted yet by the time the test starts),

The suggested fix is to use a stronger version of 
awaitPartitionMapExchange(boolean, boolean, List).



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

[jira] [Updated] (IGNITE-7841) "Failed to send one phase commit ack to backup node" at some examples with 2 nodes

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7841:

Description: 
- Open Ignite examples.

 - Start 1 server ignite node.

 - Start one of the following examples: 

org.apache.ignite.examples.java8.computegrid.ComputeAsyncExample
org.apache.ignite.examples.java8.computegrid.ComputeRunnableExample
org.apache.ignite.examples.java8.datagrid.CacheEntryProcessorExample 
org.apache.ignite.examples.java8.messaging.MessagingPingPongExample
org.apache.ignite.scalar.examples.ScalarTaskExample
org.apache.ignite.examples.java8.computegrid.ComputeBroadcastExample
org.apache.ignite.examples.java8.datagrid.CacheAffinityExample
org.apache.ignite.examples.java8.datastructures.IgniteExecutorServiceExample
org.apache.ignite.examples.java8.computegrid.ComputeCallableExample
org.apache.ignite.examples.java8.datagrid.CacheApiExample
org.apache.ignite.examples.java8.cluster.ClusterGroupExample
org.apache.ignite.examples.java8.computegrid.ComputeClosureExample
org.apache.ignite.examples.java8.messaging.MessagingExample 
org.apache.ignite.examples.messaging.MessagingExample

For instance 
org.apache.ignite.examples.java8.computegrid.ComputeCallableExample:

Example competed successfully
{noformat}
[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]

>>> Compute callable example started.

>>> Printing 'using' on this node from ignite job.

>>> Printing 'Count' on this node from ignite job.

>>> Total number of characters in the phrase is '28'.
>>> Check all nodes for output (this node is also part of the cluster).
[13:45:50] Ignite node stopped OK [uptime=00:00:00:483]

{noformat}
But server node failed to send one phase commit ack:
{noformat}
[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]


>>> Printing 'characters' on this node from ignite job.
>>> Printing 'callable' on this node from ignite job.
[13:45:49] Topology snapshot [ver=3, servers=1, clients=0, CPUs=4, heap=3.5GB]
[13:45:50,502][ERROR][sys-#51%null%][IgniteTxManager] Failed to send one phase 
commit ack to backup node [backup=f951ad58-414d-4091-b784-634a2675c830]
class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: 
Failed to send message because node left grid 
[nodeId=f951ad58-414d-4091-b784-634a2675c830, 
msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion 
[topVer=131294740, time=1519814749915, order=1519814744287, nodeOrder=1], 
GridCacheVersion [topVer=131294740, time=1519814749915, order=1519814744286, 
nodeOrder=1]], super=GridCacheMessage [msgId=-1, depInfo=null, err=null, 
skipPrepare=false, cacheId=0, cacheId=0]]]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1065)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$2.finish(IgniteTxManager.java:283)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.finish0(GridDeferredAckMessageSender.java:214)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.access$000(GridDeferredAckMessageSender.java:111)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer$1.run(GridDeferredAckMessageSender.java:159)
 at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6640)
 at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:788)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 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)

{noformat}

  was:
- Open Ignite examples.

- Start 1 server ignite node, use Java8.

- Start one of the Java8 examples ().

For instance, ComputeCallableExample.

Example competed successfully

{noformat}

[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]

>>> Compute callable example started.

>>> Printing 'using' on this node from ignite job.

>>> Printing 'Count' on this node from ignite job.

>>> Total number of characters in the phrase is '28'.
>>> Check all nodes for output (this node is also part of the cluster).
[13:45:50] Ignite node stopped OK [uptime=00:00:00:483]

{noformat}

But server node failed to send one phase commit ack:

{noformat}

[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]


>>> Printing 'characters' on this node from ignite job.
>>> Printing 'callable' on this node from ignite job.
[13:45:49] Topology snapshot [ver=3, servers=1, clients=0, CPUs=4, heap=3.5GB]
[13:45:50,502][ERROR][sys-#51%null%][IgniteTxManager] Failed to send one phase 
commit ack to backup node 

[jira] [Created] (IGNITE-7841) "Failed to send one phase commit ack to backup node" at some Java8 examples with 2 nodes

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-7841:
---

 Summary: "Failed to send one phase commit ack to backup node" at 
some Java8 examples with 2 nodes
 Key: IGNITE-7841
 URL: https://issues.apache.org/jira/browse/IGNITE-7841
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Ksenia Rybakova


- Open Ignite examples.

- Start 1 server ignite node, use Java8.

- Start one of the Java8 examples ().

For instance, ComputeCallableExample.

Example competed successfully

{noformat}

[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]

>>> Compute callable example started.

>>> Printing 'using' on this node from ignite job.

>>> Printing 'Count' on this node from ignite job.

>>> Total number of characters in the phrase is '28'.
>>> Check all nodes for output (this node is also part of the cluster).
[13:45:50] Ignite node stopped OK [uptime=00:00:00:483]

{noformat}

But server node failed to send one phase commit ack:

{noformat}

[13:45:49] Topology snapshot [ver=2, servers=2, clients=0, CPUs=4, heap=7.1GB]


>>> Printing 'characters' on this node from ignite job.
>>> Printing 'callable' on this node from ignite job.
[13:45:49] Topology snapshot [ver=3, servers=1, clients=0, CPUs=4, heap=3.5GB]
[13:45:50,502][ERROR][sys-#51%null%][IgniteTxManager] Failed to send one phase 
commit ack to backup node [backup=f951ad58-414d-4091-b784-634a2675c830]
class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: 
Failed to send message because node left grid 
[nodeId=f951ad58-414d-4091-b784-634a2675c830, 
msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion 
[topVer=131294740, time=1519814749915, order=1519814744287, nodeOrder=1], 
GridCacheVersion [topVer=131294740, time=1519814749915, order=1519814744286, 
nodeOrder=1]], super=GridCacheMessage [msgId=-1, depInfo=null, err=null, 
skipPrepare=false, cacheId=0, cacheId=0]]]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1065)
 at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$2.finish(IgniteTxManager.java:283)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.finish0(GridDeferredAckMessageSender.java:214)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer.access$000(GridDeferredAckMessageSender.java:111)
 at 
org.apache.ignite.internal.processors.cache.GridDeferredAckMessageSender$DeferredAckMessageBuffer$1.run(GridDeferredAckMessageSender.java:159)
 at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6640)
 at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:788)
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 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)

{noformat}



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

[jira] [Assigned] (IGNITE-7708) Ignite Compute has flaky failures

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk reassigned IGNITE-7708:


Assignee: Alexey Goncharuk

> Ignite Compute has flaky failures 
> --
>
> Key: IGNITE-7708
> URL: https://issues.apache.org/jira/browse/IGNITE-7708
> Project: Ignite
>  Issue Type: Bug
>  Components: compute
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1093187=IgniteTests24Java8_IgniteComputeGrid
>  
> https://ci.ignite.apache.org/viewLog.html?buildId=1092214=IgniteTests24Java8_IgniteComputeGrid
> IgniteBinaryObjectsComputeGridTestSuite
> IgniteComputeBasicConfigVariationsFullApiTestSuite
> it is required to fix flaky failure or remove tests from  suite because of 
> default notifications were enabled recently.
> Flaky failures generates a lot of unecessary spam.
> {noformat}
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollection
>  (fail rate 9%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollection
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApply
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTask
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyForCollectionWithReducerAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testAffinityCall
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallableAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastCallable
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallCollectionWithReducer
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testExecuteTaskClassAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testBroadcastClosure
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testApplyAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testCallAsync
>  (fail rate 8%) 
>  
> org.apache.ignite.testsuites.IgniteComputeBasicConfigVariationsFullApiTestSuite:
>  
> org.apache.ignite.internal.processors.compute.IgniteComputeConfigVariationsFullApiTest.testDeployExecuteByName
>  (fail rate 8%) 
>  
> 

[jira] [Updated] (IGNITE-7716) Red selftest in ML examples

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7716:
---
Fix Version/s: 2.5

> Red selftest in ML examples
> ---
>
> Key: IGNITE-7716
> URL: https://issues.apache.org/jira/browse/IGNITE-7716
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Yury Babak
>Assignee: Peter Ivanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=1447870893775475761



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

[jira] [Commented] (IGNITE-7763) Ignite CPP tests win32 failure

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7763:


Thanks [~isapego] and [~tledkov-gridgain], I've unmuted these 355 tests

> Ignite CPP tests win32 failure
> --
>
> Key: IGNITE-7763
> URL: https://issues.apache.org/jira/browse/IGNITE-7763
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformCppWin32
>  
> aborted
> std::exception: Failed to load JVM library.



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

[jira] [Updated] (IGNITE-7763) Ignite CPP tests win32 failure

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7763:
---
Fix Version/s: 2.5

> Ignite CPP tests win32 failure
> --
>
> Key: IGNITE-7763
> URL: https://issues.apache.org/jira/browse/IGNITE-7763
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformCppWin32
>  
> aborted
> std::exception: Failed to load JVM library.



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

[jira] [Commented] (IGNITE-7690) Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite Basic 2

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7690:


[~ivan.glukos], seems this issue is already done. I've resolved issue.

> Move shared memory suite (IpcSharedMemoryCrashDetectionSelfTest) to Ignite 
> Basic 2
> --
>
> Key: IGNITE-7690
> URL: https://issues.apache.org/jira/browse/IGNITE-7690
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Rakov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test is flaky but included into basic (stable) suite
>Ignite Basic [ tests 1 ] i 
>  org.apache.ignite.testsuites.IgniteBasicTestSuite: 
> org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryCrashDetectionSelfTest.testIgfsServerClientInteractionsUponClientKilling
>  (fail rate 2%) 
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2464527718752484555=%3Cdefault%3E=testDetails
> It is better to move this test to basic 2 suite - place for flaky and long 
> running tests.
> It is also desired to introduce IgniteBasic2 suite in code with correct 
> comments on purpose



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

[jira] [Commented] (IGNITE-7763) Ignite CPP tests win32 failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7763:


Github user asfgit closed the pull request at:

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


> Ignite CPP tests win32 failure
> --
>
> Key: IGNITE-7763
> URL: https://issues.apache.org/jira/browse/IGNITE-7763
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformCppWin32
>  
> aborted
> std::exception: Failed to load JVM library.



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

[jira] [Resolved] (IGNITE-7832) Partition lost events looks broken.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov resolved IGNITE-7832.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: 2.5)

> Partition lost events looks broken.
> ---
>
> Key: IGNITE-7832
> URL: https://issues.apache.org/jira/browse/IGNITE-7832
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Andrew Mashenkov
>Priority: Major
>
> Steps to reproduce:
>  # Start 3 nodes with Partitioned cache with no backups.
>  Register event handlers for EVT_CACHE_REBALANCE_PART_DATA_LOST event. 
>  PartitionLossPolicy should be smth other then IGNORED (which is default).
>  # Put some data and make sure rebalance is finished.
>  # Kill first node.
>  I observe partition lost events on 2-nd node only, however, some of lost 
> partitions should be owned by 3-rd node regarding a new topology. 
>  Cache.lostPartitions() returns non-empty resultset on 2-nd node only.
>  # Kill 2-nd node.
>  No partition lost events will be fired on 3-rd node. However data is 
> obviously lost.
>  Cache.lostPartitions() returns empty resultset.
> Looks like partition lost events mechanics is broken and should be fixed.



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

[jira] [Commented] (IGNITE-7825) ODBC: Update specification documentation

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-7825:
-

[~dmagda], basically, some {{NO}} and {{PARTIALLY}} words were changed to 
\{{YES}}, etc. Should I really give you exact links for them? There is going to 
be as much work for me as for you to find them all.

> ODBC: Update specification documentation
> 
>
> Key: IGNITE-7825
> URL: https://issues.apache.org/jira/browse/IGNITE-7825
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
>  Labels: documentation, odbc
> Fix For: 2.4
>
>
> Need to update the following doc 
> [https://apacheignite-sql.readme.io/v2.3/docs/specification] according to the 
> newly implemented features in 2.4.



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6868:


Github user alex-plekhanov closed the pull request at:

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


> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Commented] (IGNITE-7840) Web console: improve success notification for "import from database" config action

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-7840:
--

The task can only be done only as a part of IGNITE-5466 or after IGNITE-5466 
has been completed

> Web console: improve success notification for "import from database" config 
> action
> --
>
> Key: IGNITE-7840
> URL: https://issues.apache.org/jira/browse/IGNITE-7840
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-02-28-16-38-19-320.png
>
>
> Import from DB does not have it's own success notification, the actual 
> message is by "cache saved" effect. Let's implement a notification specific 
> to DB import. The message might say something like {{Imported from DB: 5 
> models and 3 caches}} or {{Imported from DB into "Cluster1": 1 model}} 
> depending on operation context.
> !image-2018-02-28-16-38-19-320.png!



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

[jira] [Issue Comment Deleted] (IGNITE-5357) Replicated cache reads load balancing.

[Lukjanenko Dmitry (JIRA)]

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

Lukjanenko Dmitry updated IGNITE-5357:
--
Comment: was deleted

(was: There wasn't any agreement with me.)

> 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: Lukjanenko Dmitry
>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] [Assigned] (IGNITE-7838) Fix redirection on logo click

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7838:
-

Assignee: Andrey Novikov  (was: Alexander Kalinin)

[~anovikov] Fixed redirection. Please review.

> Fix redirection on logo click
> -
>
> Key: IGNITE-7838
> URL: https://issues.apache.org/jira/browse/IGNITE-7838
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Andrey Novikov
>Priority: Major
>
> Redirection to last state was broken after login\landing pages split 
> (IGNITE-7650 )
>  
> Steps:
> 1) Login the app
> 2) Go to configuration page
> 3) Go to profile page
> 4) Click logo
> Actual: Redirection didn't occur
> Expected: User is redirectd to default state (confiuration)



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

[jira] [Commented] (IGNITE-6868) Implement new JMX metrics for TcpCommunicationSpi monitoring

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6868:


Github user alex-plekhanov closed the pull request at:

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


> Implement new JMX metrics for TcpCommunicationSpi monitoring
> 
>
> Key: IGNITE-6868
> URL: https://issues.apache.org/jira/browse/IGNITE-6868
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-6, jmx
> Fix For: 2.4
>
>
> These additional metrics should be implemented in TcpCommunicationSpi MBean:
> * Received messages count grouped by message type
> * Received messages count grouped by sender node
> * Sent messages count grouped by message type
> * Sent messages count grouped by receiver node



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

[jira] [Issue Comment Deleted] (IGNITE-5357) Replicated cache reads load balancing.

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5357:
---
Comment: was deleted

(was: I assigned the ticket to myself in agreement with Dmitry L.)

> 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: Lukjanenko Dmitry
>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] [Updated] (IGNITE-7840) Web console: improve success notification for "import from database" config action

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7840:
-
Attachment: image-2018-02-28-16-38-19-320.png

> Web console: improve success notification for "import from database" config 
> action
> --
>
> Key: IGNITE-7840
> URL: https://issues.apache.org/jira/browse/IGNITE-7840
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-02-28-16-38-19-320.png
>
>
> Import from DB does not have it's own success notification, the actual 
> message is by "cache saved" effect. Let's implement a notification specific 
> to DB import. The message might say something like {{Imported from DB: 5 
> models and 3 caches}} or {{Imported from DB into "Cluster1": 1 model}} 
> depending on operation context.



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

[jira] [Updated] (IGNITE-7840) Web console: improve success notification for "import from database" config action

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7840:
-
Description: 
Import from DB does not have it's own success notification, the actual message 
is by "cache saved" effect. Let's implement a notification specific to DB 
import. The message might say something like {{Imported from DB: 5 models and 3 
caches}} or {{Imported from DB into "Cluster1": 1 model}} depending on 
operation context.

!image-2018-02-28-16-38-19-320.png!

  was:Import from DB does not have it's own success notification, the actual 
message is by "cache saved" effect. Let's implement a notification specific to 
DB import. The message might say something like {{Imported from DB: 5 models 
and 3 caches}} or {{Imported from DB into "Cluster1": 1 model}} depending on 
operation context.


> Web console: improve success notification for "import from database" config 
> action
> --
>
> Key: IGNITE-7840
> URL: https://issues.apache.org/jira/browse/IGNITE-7840
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-02-28-16-38-19-320.png
>
>
> Import from DB does not have it's own success notification, the actual 
> message is by "cache saved" effect. Let's implement a notification specific 
> to DB import. The message might say something like {{Imported from DB: 5 
> models and 3 caches}} or {{Imported from DB into "Cluster1": 1 model}} 
> depending on operation context.
> !image-2018-02-28-16-38-19-320.png!



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

[jira] [Created] (IGNITE-7840) Web console: improve success notification for "import from database" config action

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7840:


 Summary: Web console: improve success notification for "import 
from database" config action
 Key: IGNITE-7840
 URL: https://issues.apache.org/jira/browse/IGNITE-7840
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov


Import from DB does not have it's own success notification, the actual message 
is by "cache saved" effect. Let's implement a notification specific to DB 
import. The message might say something like {{Imported from DB: 5 models and 3 
caches}} or {{Imported from DB into "Cluster1": 1 model}} depending on 
operation context.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-7421:
-

[~kukushal], I did preliminary review. Please address the following issues:
1) I do not think it makes sense to have separate module. Instead, it is better 
to store client inside {{ignite-core}} because it would simplify project 
configuration from user side (one jar instead of two). We already did this for 
thin JDBC driver. 
2) Once code is moved to the core, please make sure to remove all duplicated 
classes (QueryEntity, QueryIndex, etc)
3) Please pay attention to our common project structure - public classes and 
interfaces are stored inside {{org.apache.ignite}} subpackages. Internal 
classes are stored inside {{org.apache.ignite.*internal*}} packages. The same 
should be done for thin client - {{org.apache.ignite.client}} for public stuff, 
{{org.apache.ignite.internal.processors.odbc.thin}} for internal stuff ("odbc" 
in package name is an artifact, we will rename it to "client" later).
4) Please make sure that you follow our code convention rules. E.g., we 
disallow wildcards in package declarations. Every class should be defined 
explicitly. 

> 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, oldVal, newVal)
>          putAll
>          clear
>          remove(key)
>          remove(key, val)
>          removeAll()
>          removeAll(keys: Set)
>          getConfiguration(clazz): Configuration
>          close()
>      size(modes: CachePeekMode...)
>      query(qry: Query): QueryCursor
>      query(qry: SqlFieldsQuery): FieldsQueryCursor
>      withKeepBinary(): IgniteCache
>  Ignite
>      cache(name: String)
>      cacheNames(): Collection
>      binary(): IgniteBinary
>      createCache(name): Cache
>      getOrCreateCache(name): Cache
>      destroyCache(name)
>  Ignition
>      startClient(:ClientConfiguration): Ignite
>  ClientConfiguration(port, host, binaryConfiguration, sslConfiguration,
>  etc...)



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

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

[Lukjanenko Dmitry (JIRA)]

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

Lukjanenko Dmitry commented on IGNITE-5357:
---

There wasn't any agreement with me.

> 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] [Updated] (IGNITE-7838) Fix redirection on logo click

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin updated IGNITE-7838:
--
Description: 
Redirection to last state was broken after login\landing pages split 
(IGNITE-7650 )

 

Steps:

1) Login the app

2) Go to configuration page

3) Go to profile page

4) Click logo

Actual: Redirection didn't occur

Expected: User is redirectd to default state (confiuration)

  was:
Redirection to last state was broken after login\landing pages split 
(IGNITE-7650 )

 

Steps:

1) Login the app

2) Go to profile page

3) Go to configuration page

4) Click logo




Actual: Redirection didn't occur

Expected: User is redirectd to last state.


> Fix redirection on logo click
> -
>
> Key: IGNITE-7838
> URL: https://issues.apache.org/jira/browse/IGNITE-7838
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Major
>
> Redirection to last state was broken after login\landing pages split 
> (IGNITE-7650 )
>  
> Steps:
> 1) Login the app
> 2) Go to configuration page
> 3) Go to profile page
> 4) Click logo
> Actual: Redirection didn't occur
> Expected: User is redirectd to default state (confiuration)



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

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

[Lukjanenko Dmitry (JIRA)]

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

Lukjanenko Dmitry reassigned IGNITE-5357:
-

Assignee: Lukjanenko Dmitry  (was: Vyacheslav Daradur)

> 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: Lukjanenko Dmitry
>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-7839) Web console: validation messages on config pages sometimes blink at the same time

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-7839:
--

Can be only reproduced on new-design screens of IGNITE-5466.

> Web console: validation messages on config pages sometimes blink at the same 
> time
> -
>
> Key: IGNITE-7839
> URL: https://issues.apache.org/jira/browse/IGNITE-7839
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> *What happens:*
> Multiple validation error messages in nested {{list-editable}} forms 
> sometimes blink simultaneously on form submit. The forms in question are 
> available only on domain model configuration screen.
> *How to reproduce:*
> No solid scenarios yet, play around in domain model config form to hopefully 
> reproduce the issue.
>  
> *What to do:*
>  Investigate and fix the issue. It probably has to do with 
> {{$showValidationError}} $scope event triggered by {{triggerValidation}} 
> method of {{FormUtils}} service.



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