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

[Amir Akhmedov (JIRA)]

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

Amir Akhmedov commented on IGNITE-3999:
---

Hi [~vozerov], thank you for your time to review it and your comments are 
highly appreciated.

I agree with you on the approaches to support case sensitivity and as per me 
functional index is a better choice.

Do you think I need to close the ticket with "Won't fix" status?

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



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

[jira] [Comment Edited] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-8439 at 5/9/18 12:52 AM:
---

[~agura] Ok, I will merge it to the master branch then. At least, it fixes the 
problem. And whoever has time for refactoring it can do it.

Can you please create another issue for refactoring?


was (Author: roman_s):
[~agura] Ok, I will merge it to the master branch. At least, it fixes the 
problem. And whoever has time for refactoring it can do it.

Can you please create another issue for refactoring?

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Comment Edited] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh edited comment on IGNITE-8439 at 5/9/18 12:51 AM:
---

[~agura] Ok, I will merge it to the master branch. At least, it fixes the 
problem. And whoever has time for refactoring it can do it.

Can you please create another issue for refactoring?


was (Author: roman_s):
[~agura] Ok, I will merge it to the master branch. At least, it fixes the 
problem. And whoever has time for refactoring it can do it.

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-8439:
--

[~agura] Ok, I will merge it to the master branch. At least, it fixes the 
problem. And whoever has time for refactoring it can do it.

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-7608) Sort keys in putAll/removeAll methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7608:


Github user SomeFire closed the pull request at:

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


> Sort keys in putAll/removeAll methods
> -
>
> Key: IGNITE-7608
> URL: https://issues.apache.org/jira/browse/IGNITE-7608
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1, 2.2
> Environment: We need to sort keys in cache putAll/removeAll 
> operations to avoid deadlocks there.
>Reporter: Alexander Belyak
>Assignee: Ryabov Dmitrii
>Priority: Major
>




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

[jira] [Comment Edited] (IGNITE-6895) TX deadlock monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6895 at 5/8/18 9:48 PM:
--

Please see IGNITE-7608

PutAll/RemoveAll also suffers of deadlock


was (Author: avinogradov):
Please see IGNITE-7608

PutAll/RemovaAll also suffers of deadlock

> TX deadlock monitoring
> --
>
> Key: IGNITE-6895
> URL: https://issues.apache.org/jira/browse/IGNITE-6895
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-7
> Fix For: 2.6
>
>
> Deadlocks with Cache Transactions
> Description
> Deadlocks of this type are possible if user locks 2 or more keys within 2 or 
> more transactions in different orders (this does not apply to OPTIMISTIC 
> SERIALIZABLE transactions as they are capable to detect deadlock and choose 
> winning tx). Currently, Ignite can detect deadlocked transactions but this 
> procedure is started only for transactions that have timeout set explicitly 
> or default timeout in configuration set to value greater than 0.
> Detection and Solution
> Each NEAR node should periodically (need new config property?) scan the list 
> of local transactions and initiate the same procedure as we have now for 
> timed out transactions. If deadlock found it should be reported to logs. Log 
> record should contain: near nodes, transaction IDs, cache names, keys 
> (limited to several tens of) involved in deadlock. User should have ability 
> to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually 
> rollback selected transaction through web console or Visor.
> Report
> If deadlock found it should be reported to logs. Log record should contain: 
> near nodes, transaction IDs, cache names, keys (limited to several tens of) 
> involved in deadlock.
> Also there should be a screen in Web Console that will list all ongoing 
> transactions in the cluster including the following info:
> - Near node
> - Start time
> - DHT nodes
> - Pending Locks (by request)
> Web Console should provide ability to rollback any transaction via UI.



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

[jira] [Commented] (IGNITE-6895) TX deadlock monitoring

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6895:
--

Please see IGNITE-7608

PutAll/RemovaAll also suffers of deadlock

> TX deadlock monitoring
> --
>
> Key: IGNITE-6895
> URL: https://issues.apache.org/jira/browse/IGNITE-6895
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-7
> Fix For: 2.6
>
>
> Deadlocks with Cache Transactions
> Description
> Deadlocks of this type are possible if user locks 2 or more keys within 2 or 
> more transactions in different orders (this does not apply to OPTIMISTIC 
> SERIALIZABLE transactions as they are capable to detect deadlock and choose 
> winning tx). Currently, Ignite can detect deadlocked transactions but this 
> procedure is started only for transactions that have timeout set explicitly 
> or default timeout in configuration set to value greater than 0.
> Detection and Solution
> Each NEAR node should periodically (need new config property?) scan the list 
> of local transactions and initiate the same procedure as we have now for 
> timed out transactions. If deadlock found it should be reported to logs. Log 
> record should contain: near nodes, transaction IDs, cache names, keys 
> (limited to several tens of) involved in deadlock. User should have ability 
> to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually 
> rollback selected transaction through web console or Visor.
> Report
> If deadlock found it should be reported to logs. Log record should contain: 
> near nodes, transaction IDs, cache names, keys (limited to several tens of) 
> involved in deadlock.
> Also there should be a screen in Web Console that will list all ongoing 
> transactions in the cluster including the following info:
> - Near node
> - Start time
> - DHT nodes
> - Pending Locks (by request)
> Web Console should provide ability to rollback any transaction via UI.



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

[jira] [Commented] (IGNITE-7608) Sort keys in putAll/removeAll methods

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7608:
--

[~SomeFire]

Thanks for help with investigating the issue.

> Sort keys in putAll/removeAll methods
> -
>
> Key: IGNITE-7608
> URL: https://issues.apache.org/jira/browse/IGNITE-7608
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1, 2.2
> Environment: We need to sort keys in cache putAll/removeAll 
> operations to avoid deadlocks there.
>Reporter: Alexander Belyak
>Assignee: Ryabov Dmitrii
>Priority: Major
>




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

[jira] [Assigned] (IGNITE-8361) Use discovery messages for service deployment

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur reassigned IGNITE-8361:
--

Assignee: Vyacheslav Daradur

> Use discovery messages for service deployment
> -
>
> Key: IGNITE-8361
> URL: https://issues.apache.org/jira/browse/IGNITE-8361
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Reporter: Denis Mekhanikov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: iep-17
>
> Service deployment should be based on discovery messages distribution.
> The procedure is as follows:
>  # Deploying node sends a message with a service configuration.
>  # Coordinator calculates the assignments and sends them in another message.
>  # Nodes check, whether they are assigned to deploy any services, and do so, 
> if they are.
> Utility cache won't be needed after these changes are made. All its mentions 
> should be removed from the code.



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

[jira] [Assigned] (IGNITE-8397) Update documentation for kNN regression (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8397:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Update documentation for kNN regression (release 2.5)
> -
>
> Key: IGNITE-8397
> URL: https://issues.apache.org/jira/browse/IGNITE-8397
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Denis Magda
>Priority: Major
>
> In Apache Ignite 2.5 we have changed a kNN regression working on top of 
> partition based dataset and now we need to update documentation for this 
> feature.
>  
> Previous version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/knn-regression]
> update with
> New version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-regression-25]



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

[jira] [Assigned] (IGNITE-5922) Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than PublicThreadPoolSize

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-5922:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Improve FifoCollisionSpi doc - ParallelJobsNumber should be less than 
> PublicThreadPoolSize
> --
>
> Key: IGNITE-5922
> URL: https://issues.apache.org/jira/browse/IGNITE-5922
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Evgenii Zhuravlev
>Assignee: Denis Magda
>Priority: Minor
> Fix For: 2.6
>
>




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

[jira] [Assigned] (IGNITE-8398) Update documentation for KMeans clustering (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8398:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Update documentation for KMeans clustering (release 2.5)
> 
>
> Key: IGNITE-8398
> URL: https://issues.apache.org/jira/browse/IGNITE-8398
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Denis Magda
>Priority: Major
>
> In Apache Ignite 2.5 we have changed a kMeans clustering and remove 
> FuzzyCMeans working on top of partition based dataset and now we need to 
> update documentation for this feature.
>  
> Previous version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering]
> update with
> New version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering-25]
>  
> IMPORTANT: Remove page 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/fuzzy-c-means-clustering]
>  



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

[jira] [Assigned] (IGNITE-8399) Add documentation for SVM Binary and Multi-class classification (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8399:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Add documentation for SVM Binary and Multi-class classification (release 2.5)
> -
>
> Key: IGNITE-8399
> URL: https://issues.apache.org/jira/browse/IGNITE-8399
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Denis Magda
>Priority: Major
>
> In Apache Ignite 2.5 we have added a SVM Binary and Multi-class 
> classification working on top of partition based dataset and now we need to 
> update documentation for this feature.
> Add page [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-25]
> Add page 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-multi-class-classification-25]
>  
>  



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

[jira] [Assigned] (IGNITE-8396) Update documentation for kNN classification (release 2.5)

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-8396:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Update documentation for kNN classification (release 2.5)
> -
>
> Key: IGNITE-8396
> URL: https://issues.apache.org/jira/browse/IGNITE-8396
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation, ml
>Affects Versions: 2.5
>Reporter: Aleksey Zinoviev
>Assignee: Denis Magda
>Priority: Major
>
> In Apache Ignite 2.5 we have changed a kNN classification working on top of 
> partition based dataset and now we need to update documentation for this 
> feature.
>  
> Previous version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification]
> update with
> New version: 
> [https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25]
>  



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

[jira] [Commented] (IGNITE-8266) Remove afterTestsStopped method due to stopAllGrids by default

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8266:


[~NIzhikov] can we remove after tests in separate issue?

 

Ideally I would suggest migration to JUnit4 instead of too much efforts in old 
JUnit3 tests, so IMO we can review PR and merge as is.

> Remove afterTestsStopped method due to stopAllGrids by default
> --
>
> Key: IGNITE-8266
> URL: https://issues.apache.org/jira/browse/IGNITE-8266
> Project: Ignite
>  Issue Type: Sub-task
>Affects Versions: 2.5
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
>  Labels: test
> Fix For: 2.6
>
>
> Remove this types of method from test in whole ignite-core module.
> {code:java}
> @Override protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }{code}



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

[jira] [Created] (IGNITE-8459) Searching checkpoint history for WAL rebalance is broken

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8459:
---

 Summary: Searching checkpoint history for WAL rebalance is broken
 Key: IGNITE-8459
 URL: https://issues.apache.org/jira/browse/IGNITE-8459
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


Currently the mechanism to search available checkpoint records in WAL to have 
history for WAL rebalance is broken. It means that WAL (Historical) rebalance 
will never find history for rebalance and full rebalance will be always used.

This mechanism was broken in 
https://github.com/apache/ignite/commit/ec04cd174ed5476fba83e8682214390736321b37
 by unclear reasons.

If we swap the following two code blocks (database().beforeExchange() and 
exchCtx if block):

{noformat}
/* It is necessary to run database callback before all topology 
callbacks.
   In case of persistent store is enabled we first restore partitions 
presented on disk.
   We need to guarantee that there are no partition state changes 
logged to WAL before this callback
   to make sure that we correctly restored last actual states. */
cctx.database().beforeExchange(this);

if (!exchCtx.mergeExchanges()) {
for (CacheGroupContext grp : cctx.cache().cacheGroups()) {
if (grp.isLocal() || cacheGroupStopping(grp.groupId()))
continue;

// It is possible affinity is not initialized yet if node joins 
to cluster.
if (grp.affinity().lastVersion().topologyVersion() > 0)
grp.topology().beforeExchange(this, !centralizedAff && 
!forceAffReassignment, false);
}
}
{noformat}

the searching mechanism will start to work correctly. Currently it's unclear 
why it's happened.



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

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

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko updated IGNITE-8320:

Description: 
Cache rebalance may result in page memory corruption.

{noformat}
[2018-04-18T14:33:23,260][ERROR][sys-#54][GridCacheIoManager] Failed processing 
message [senderId=95f06c25-e6bb-48f7-a3e5-4c05fc1c49be, 
msg=GridDhtPartitionSupplyMessage [rebalanceId=37, 
topVer=AffinityTopologyVersion [topVer=53, minorTopVer=1], missed=null, 
clean=null, msgSize=525350, estimatedKeysCnt=1690216, size=2, parts=[1, 2], 
super=GridCacheGroupIdMessage [grpId=-1831596270]]]
 org.apache.ignite.IgniteException: Runtime failure on row: Row@33b6805c[ key: 
 [idHash=773709078, hash=-630455542, ...], val:  [idHash=1309051286, 
hash=-1321165334, ver: GridCacheVersion [topVer=135435024, order=1523963943331, 
nodeOrder=4] ]
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2102)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2049)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:247)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:454)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:653)
 ~[ignite-indexing-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1866)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1391)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1255)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1451)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3527)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2735)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.preloadEntry(GridDhtPartitionDemander.java:823)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionDemander.handleSupplyMessage(GridDhtPartitionDemander.java:704)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleSupplyMessage(GridDhtPreloader.java:347)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:365)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:355)
 ~[ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:99)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1603)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:126)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2751)
 [ignite-core-2.4.4.b1.jar:2.4.4.b1]
 at 

[jira] [Updated] (IGNITE-8458) AffinityAssigment absorbs a lot of java heap

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8458:
--
Description: 
For the more hundred caches and several thousand partitions the size can grow 
out of 10 Gb.
In my case in heap stored ~5К {{HistoryAffinityAssigment}}, that took nearly 
12Gb.

  was:
For the more hundred caches and several thousand partitions the size can grow 
out of 10 Gb.
In my case heap stored ~5К {{HistoryAffinityAssigment}}


> AffinityAssigment absorbs a lot of java heap
> 
>
> Key: IGNITE-8458
> URL: https://issues.apache.org/jira/browse/IGNITE-8458
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> For the more hundred caches and several thousand partitions the size can grow 
> out of 10 Gb.
> In my case in heap stored ~5К {{HistoryAffinityAssigment}}, that took nearly 
> 12Gb.



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

[jira] [Created] (IGNITE-8458) AffinityAssigment absorbs a lot of java heap

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8458:
-

 Summary: AffinityAssigment absorbs a lot of java heap
 Key: IGNITE-8458
 URL: https://issues.apache.org/jira/browse/IGNITE-8458
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


For the more hundred caches and several thousand partitions the size can grow 
out of 10 Gb.
In my case heap stored ~5К {{HistoryAffinityAssigment}}



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

[jira] [Created] (IGNITE-8457) Typo in MarshallerUtils.jdkMarshaller() method

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8457:


 Summary: Typo in MarshallerUtils.jdkMarshaller() method
 Key: IGNITE-8457
 URL: https://issues.apache.org/jira/browse/IGNITE-8457
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.6


{code}

public static JdkMarshaller jdkMarshaller(@Nullable String nodeName) {
 JdkMarshaller marsh = new JdkMarshaller();

 setNodeName(new JdkMarshaller(), nodeName); // <<< BUG !!! 

 return marsh;
}

{code}



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

[jira] [Commented] (IGNITE-8452) ML module compilation failure under JDK 9

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8452:


Github user asfgit closed the pull request at:

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


> ML module compilation failure under JDK 9
> -
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Commented] (IGNITE-8452) ML module compilation failure under JDK 9

[Yury Babak (JIRA)]

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

Yury Babak commented on IGNITE-8452:


JDK 9 can't resolve types in DatasetWrapperTest(62 and 74), so I directly set 
this type. Merged.

> ML module compilation failure under JDK 9
> -
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Commented] (IGNITE-8422) Zookeeper discovery split brain detection shouldn't consider client nodes

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8422:


[~Jokser], thanks!
I'm ok with these changes as long as TC run results will be acceptable.

> Zookeeper discovery split brain detection shouldn't consider client nodes
> -
>
> Key: IGNITE-8422
> URL: https://issues.apache.org/jira/browse/IGNITE-8422
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Zookeeper discovery checks each splitted cluster on full 
> connectivity taking into account client nodes. This is not correct, because 
> server and client nodes may use different networks to connect to each other. 
> It means that there can be client which sees both parts of splitted cluster 
> and breaks split brain recovery - full connected part of server nodes will be 
> never find.
> We should exclude client nodes from split brain analysis and improve split 
> brain tests to make them truly fair.



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

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

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8456:
--

 Summary: Print warning if IGNITE_HOME & WORK and 
persistentStoreDir is not set, but persistence enabled
 Key: IGNITE-8456
 URL: https://issues.apache.org/jira/browse/IGNITE-8456
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Reporter: Dmitriy Pavlov
 Fix For: 2.6


In method org.apache.ignite.internal.util.IgniteUtils#workDirectory

Ignite determine Work dir to be set, same value may be used in case persistence 
Store Folder is not set and IGNITE_HOME is not specified.

In case work dir is not specified, temp directory is used for Ignite Work. But 
for persistence enabled case this means user DB goes to temp folder and may be 
removed later.

User may be confused by this behaviour. See:

[https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage]

and related Dev.List discussion

[http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-HOME-for-persistence-td26470.html]

 



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

[jira] [Commented] (IGNITE-8422) Zookeeper discovery split brain detection shouldn't consider client nodes

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-8422:
-

Changes are ready to merge.
TC Run: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3951%2Fhead

> Zookeeper discovery split brain detection shouldn't consider client nodes
> -
>
> Key: IGNITE-8422
> URL: https://issues.apache.org/jira/browse/IGNITE-8422
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Zookeeper discovery checks each splitted cluster on full 
> connectivity taking into account client nodes. This is not correct, because 
> server and client nodes may use different networks to connect to each other. 
> It means that there can be client which sees both parts of splitted cluster 
> and breaks split brain recovery - full connected part of server nodes will be 
> never find.
> We should exclude client nodes from split brain analysis and improve split 
> brain tests to make them truly fair.



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

[jira] [Created] (IGNITE-8455) Cover main Ignite memory modes

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8455:
---

 Summary: Cover main Ignite memory modes
 Key: IGNITE-8455
 URL: https://issues.apache.org/jira/browse/IGNITE-8455
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.6


Ignite website doesn't mention various modes on how Ignite native persistence 
can be used:

- no disk, data is in memory-only (potentially over a 3rd-party database)
- disk is a copy of the memory (only for recovery purposes)
- disk is a data storage with memory used as a performant caching layer
- indexes in memory and data on disk for better technical cost of ownership.

I believe we should put it in a table and explain it on the memory-centric page.

More details: 
http://apache-ignite-developers.2346864.n4.nabble.com/missing-website-info-td30145.html




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

[jira] [Commented] (IGNITE-6252) Cassandra Cache Store Session does not retry if prepare statement failed

[Yashasvi Kotamraju (JIRA)]

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

Yashasvi Kotamraju commented on IGNITE-6252:


Ticket addressing the Issue in the above comment, regarding continuous 
cassandra refresh issue :

https://issues.apache.org/jira/browse/IGNITE-8354

 

> Cassandra Cache Store Session does not retry if prepare statement failed
> 
>
> Key: IGNITE-6252
> URL: https://issues.apache.org/jira/browse/IGNITE-6252
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.0, 2.1
>Reporter: Sunny Chan
>Assignee: Igor Rudyak
>Priority: Major
> Fix For: 2.6
>
>
> During our testing, we have found that certain warning about prepared 
> statement:
> 2017-08-31 11:27:19.479 
> org.apache.ignite.cache.store.cassandra.CassandraCacheStore 
> flusher-0-#265%% WARN CassandraCacheStore - Prepared statement cluster 
> error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute 
> unknown prepared query : 0xc7647611fd755386ef63478ee7de577b. You may have 
> used a PreparedStatement that was created with another Cluster instance.
> We notice that after this warning occurs some of the data didn't persist 
> properly in cassandra cache. After further examining the Ignite's 
> CassandraSessionImpl code in method 
> execute(BatchExecutionAssistance,Iterable), we found that at around [line 
> 283|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L283],
>  if the prepare statement fails in the asnyc call, it will not retry the 
> operation as the error is stored in [line 
> 269|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L269]
>  and cleared in [line 
> 277|https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L277]
>  but it was not checked again after going through the [ResultSetFuture 
> |https://github.com/apache/ignite/blob/86bd544a557663bce497134f7826be6b24d53330/modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/session/CassandraSessionImpl.java#L307].
> I believe in line 307 you should check for error != null such that any 
> failure will be retry.



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

[jira] [Commented] (IGNITE-8452) ML module compilation failure under JDK 9

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8452:


GitHub user ybabak opened a pull request:

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

IGNITE-8452: ML module compilation failure under Java 9

fixed

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

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

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

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


commit 10011cceda916df52afb073821337acf706c4e1f
Author: YuriBabak 
Date:   2018-05-08T16:16:33Z

IGNITE-8452: ML module compilation failure under Java 9

fixed




> ML module compilation failure under JDK 9
> -
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7912:


GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-7912



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

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

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

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


commit 578a49689cefbcf94ab999c2837a5324fdd069c5
Author: Ivan Daschinskiy 
Date:   2018-03-14T17:43:34Z

IGNITE-7912 Add Visor WAL command to safely truncate WAL archives and
print list of files that is safe to truncate. Perform these task clusterwide
and per nodes that are specified.

commit 7b591d61c114ee24ef520480591ee1371d4f24ef
Author: Ivan Daschinskiy 
Date:   2018-03-20T16:46:36Z

IGNITE-7912 Rewrote code for preventing abstraction leaks, and added 
additional tests for CommandHandler.

commit 5f19e13b180ac346ad3d6886f7b37ad595c706dc
Author: Ivan Daschinskiy 
Date:   2018-03-21T10:35:27Z

IGNITE-7912 Merged with master and rewrote wal logic in CommandHandler 
according to new changes

commit 90daba6df7db6be0e42e07b20fa78bd4ce1c129e
Author: Ivan Daschinskiy 
Date:   2018-03-21T10:36:29Z

IGNITE-7912 Merged with master and rewrote wal logic in CommandHandler 
according to new changes

commit 4093e89e1c1fb58123db2b1a863c82e9e07bdbca
Author: Ivan Daschinskiy 
Date:   2018-03-23T14:03:36Z

Merge branch 'master' into ignite-7912

commit 680fe97ecb23bd13b4daa14d5723c112db5bc7fc
Author: Ivan Daschinskiy 
Date:   2018-03-23T14:04:43Z

IGNITE-7912 Merging master and revert GridDhtPartitionExchangeId

commit f3b46c1af07a73913dca2b0f9173fb23280d13f8
Author: Ivan Daschinskiy 
Date:   2018-03-31T09:13:11Z

IGNITE-7912 merge with master

commit 5478ca0454e83127f8a923e9e3da1e0bafb0424f
Author: Ivan Daschinskiy 
Date:   2018-04-03T08:33:21Z

IGNITE-7912 Simplified tests and corrected formatting issues

commit 012b9b43df19abe7a3e6c4cc7371cc506f29a93a
Author: Ivan Daschinskiy 
Date:   2018-04-04T13:12:41Z

IGNITE-7912 Code review reaction

commit 2c35061b2cba570d75231ae2addb6b1c6ef84ae8
Author: Ivan Daschinskiy 
Date:   2018-04-05T11:05:44Z

IGNITE-7912 Add test that checks whether reserved WAL segment
is not affected

commit 93014eea3402d216880c1f574285a53eb66999ab
Author: Ivan Daschinskiy 
Date:   2018-04-05T15:18:10Z

IGNITE-7912 Reworking test, part 1.

commit 0b94a1cdfc119577fe150a3d9094c897f9031537
Author: Ivan Daschinskiy 
Date:   2018-04-05T16:34:28Z

IGNITE-7912 Reworking test, part 2.

commit 4e09ed087b73e1887f49aa3242f64e1672c507e7
Author: Ivan Daschinskiy 
Date:   2018-04-06T14:57:16Z

IGNITE-7912 Small refactoring.

commit 4637e9f022af5c7fd101daf8c039d9f01d876988
Author: Ivan Daschinskiy 
Date:   2018-04-09T09:42:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7912

commit be6dc1bcc256d7a94834f63873520103846d3797
Author: Ivan Daschinskiy 
Date:   2018-04-09T09:49:13Z

IGNITE-7912 Small refactoring.

commit f6e4206dc8dcef1792bf9e25c204f0ce9732c209
Author: Ivan Daschinskiy 
Date:   2018-04-12T10:44:12Z

Merge branch 'master' into ignite-7912

commit 12f89a6458228b7163a032177812d476473ee8d0
Author: Ivan Daschinskiy 
Date:   2018-04-12T11:22:52Z

IGNITE-7912 Introduce IGNITE_ENABLE_EXPERIMENTAL_COMMAND system property
to hide WAL command by default.

commit 10d1ff6f8fab3239706da15d2ea63e894cb24385
Author: Ivan Daschinskiy 
Date:   2018-05-02T11:41:37Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7912

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/Arguments.java
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/Command.java
#   
modules/core/src/main/java/org/apache/ignite/internal/commandline/CommandHandler.java
#   
modules/core/src/test/java/org/apache/ignite/internal/commandline/CommandHandlerParsingTest.java
#   
modules/core/src/test/java/org/apache/ignite/util/GridCommandHandlerTest.java

commit 895bb93ca5365d8d54c15853b0a2fb92d888f2a1
Author: Ivan Daschinskiy 
Date:   2018-05-02T14:15:22Z

IGNITE-7912 wip.

commit c01ceddc697202e3c774383ac473db428015f838
Author: Ivan Daschinskiy 
Date:   2018-05-07T09:30:19Z

Merge 

[jira] [Commented] (IGNITE-8443) Flaky failure of IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8443:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8443 Transaction hangs when some error occurs during processig of 
GridNearLockRequest



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

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

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

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


commit 5e97fd54d3f37e2a49866931b71caac4ed462307
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:36:32Z

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest




> Flaky failure of 
> IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode
> ---
>
> Key: IGNITE-8443
> URL: https://issues.apache.org/jira/browse/IGNITE-8443
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Test fails on TC sometimes (failure rate: 30%) with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for update.
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.multinode(IgniteCacheClientNodeChangingTopologyTest.java:1855)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode(IgniteCacheClientNodeChangingTopologyTest.java:1673)
> {noformat}
> Each time some seconds prior to failure there is error in log:
> {noformat}
> [ERROR][sys-stripe-10-#90529%distributed.IgniteCacheClientNodeChangingTopologyTest0%][GridDhtColocatedCache]
>   Failed to unmarshal at least one of the keys for lock request 
> message: GridNearLockRequest [topVer=AffinityTopologyVersion [topVer=10, 
> minorTopVer=0], miniId=1, dhtVers=[...], 
> subjId=5ad87047-5d80-4530-bb48-f7c26846, taskNameHash=0, createTtl=-1, 
> accessTtl=-1, flags=6, filter=null, super=GridDistributedLockRequest 
> [nodeId=5ad87047-5d80-4530-bb48-f7c26846, nearXidVer=GridCacheVersion 
> [topVer=136730132, order=1525250131532, nodeOrder=7], threadId=100107, 
> futId=3e2912f2361-94bff164-8062-4fb4-8d85-c2e89e579148, timeout=0, 
> isInTx=true, isInvalidate=false, isRead=false, isolation=REPEATABLE_READ, 
> retVals=[...], txSize=0, flags=0, keysCnt=94, 
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=136730132, 
> order=1525250131532, nodeOrder=7], committedVers=null, rolledbackVers=null, 
> cnt=0, super=GridCacheIdMessage [cacheId=1544803905
>  class 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
>  [part=54, msg=Adding entry to partition that is concurrently evicted 
> [grp=default, part=54, shouldBeMoving=, belongs=true, 
> topVer=AffinityTopologyVersion [topVer=10, minorTopVer=0], 
> curTopVer=AffinityTopologyVersion [topVer=10, minorTopVer=1]]]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:923)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:798)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:955)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryExx(GridDhtCacheAdapter.java:545)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:987)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest0(GridDhtTransactionalCacheAdapter.java:667)
> 

[jira] [Commented] (IGNITE-8443) Flaky failure of IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8443:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest (TC run)



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

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

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

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


commit 5e97fd54d3f37e2a49866931b71caac4ed462307
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:36:32Z

IGNITE-8443 Transaction hangs when some error occurs during processing of 
GridNearLockRequest

commit 4f4f2f588aa2b172d33d1efd1d9b77fcd3667bf7
Author: Aleksey Plekhanov 
Date:   2018-05-08T15:43:04Z

IGNITE-8443 TC run




> Flaky failure of 
> IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode
> ---
>
> Key: IGNITE-8443
> URL: https://issues.apache.org/jira/browse/IGNITE-8443
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Test fails on TC sometimes (failure rate: 30%) with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for update.
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.multinode(IgniteCacheClientNodeChangingTopologyTest.java:1855)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode(IgniteCacheClientNodeChangingTopologyTest.java:1673)
> {noformat}
> Each time some seconds prior to failure there is error in log:
> {noformat}
> [ERROR][sys-stripe-10-#90529%distributed.IgniteCacheClientNodeChangingTopologyTest0%][GridDhtColocatedCache]
>   Failed to unmarshal at least one of the keys for lock request 
> message: GridNearLockRequest [topVer=AffinityTopologyVersion [topVer=10, 
> minorTopVer=0], miniId=1, dhtVers=[...], 
> subjId=5ad87047-5d80-4530-bb48-f7c26846, taskNameHash=0, createTtl=-1, 
> accessTtl=-1, flags=6, filter=null, super=GridDistributedLockRequest 
> [nodeId=5ad87047-5d80-4530-bb48-f7c26846, nearXidVer=GridCacheVersion 
> [topVer=136730132, order=1525250131532, nodeOrder=7], threadId=100107, 
> futId=3e2912f2361-94bff164-8062-4fb4-8d85-c2e89e579148, timeout=0, 
> isInTx=true, isInvalidate=false, isRead=false, isolation=REPEATABLE_READ, 
> retVals=[...], txSize=0, flags=0, keysCnt=94, 
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=136730132, 
> order=1525250131532, nodeOrder=7], committedVers=null, rolledbackVers=null, 
> cnt=0, super=GridCacheIdMessage [cacheId=1544803905
>  class 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
>  [part=54, msg=Adding entry to partition that is concurrently evicted 
> [grp=default, part=54, shouldBeMoving=, belongs=true, 
> topVer=AffinityTopologyVersion [topVer=10, minorTopVer=0], 
> curTopVer=AffinityTopologyVersion [topVer=10, minorTopVer=1]]]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:923)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:798)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:955)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryExx(GridDhtCacheAdapter.java:545)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:987)
>   at 

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6879:


Github user asfgit closed the pull request at:

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


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



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6879:
---
Summary: Support Spring Data 2.0  (was: Support Spring 2.0)

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



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

[jira] [Updated] (IGNITE-8437) Control utility fails to connect to cluster if zookeeper discovery used

[Dmitriy Govorukhin (JIRA)]

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

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

> Control utility fails to connect to cluster if zookeeper discovery used
> ---
>
> Key: IGNITE-8437
> URL: https://issues.apache.org/jira/browse/IGNITE-8437
> Project: Ignite
>  Issue Type: Improvement
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Dmitry Sherstobitov
>Assignee: Alexei Scherbakov
>Priority: Blocker
> Fix For: 2.6
>
>
> Start cluster with zookeeper discovery and try to run control.sh --tx utility
>  
> {code:java}
> 2018-05-03 16:56:36.225 
> [ERROR][mgmt-#115268%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
>  Failed to process client request [ses=GridSelectorNioSessionImpl 
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=395 
> lim=395 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0, 
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker 
> [name=grid-nio-worker-tcp-rest-0, 
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false, 
> hashCode=1766410348, interrupted=false, 
> runner=grid-nio-worker-tcp-rest-0-#48%DPL_GRID%DplGridNodeName%]]], 
> writeBuf=null, readBuf=null, inRecovery=null, outRecovery=null, 
> super=GridNioSessionImpl [locAddr=/10.116.158.48:11211, 
> rmtAddr=/10.78.10.31:55847, createTime=1525355795984, 
> closeTime=1525355796217, bytesSent=521553, bytesRcvd=461, bytesSent0=521553, 
> bytesRcvd0=461, sndSchedTime=1525355796217, lastSndTime=1525355796075, 
> lastRcvTime=1525355796175, readsPaused=false, 
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser 
> [marsh=JdkMarshaller [clsFilter=o.a.i.i.IgniteKernal$5@3e3d1d0d], 
> routerClient=false], directMode=false]], accepted=true]], 
> msg=GridClientTaskRequest [taskName=o.a.i.i.v.tx.VisorTxTask, 
> arg=VisorTaskArgument [debug=false]]]
> org.apache.ignite.internal.util.nio.GridNioException: class 
> org.apache.ignite.IgniteCheckedException: Failed to serialize object: 
> GridClientResponse [clientId=587ea745-dd1e-4631-aa85-feb5d49acc36, reqId=2, 
> destId=null, status=0, errMsg=null, result=GridClientTaskResultBean 
> [res={ZookeeperClusterNode [id=c4cc818d-b29f-427b-86b5-9a625287feb6, 
> addrs=[10.116.159.100], order=30, loc=false, client=true]=VisorTxTaskResult 
> []}, error=null, finished=true, id=~a7245b33-a37a-4084-a954-460c31834442]]
> at 
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionWrite(GridNioCodecFilter.java:100)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionWrite(GridNioFilterAdapter.java:121)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionWrite(GridNioFilterChain.java:269)
> at 
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onSessionWrite(GridNioFilterChain.java:192)
> at 
> org.apache.ignite.internal.util.nio.GridNioSessionImpl.send(GridNioSessionImpl.java:110)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:261)
> at 
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestNioListener$1.apply(GridTcpRestNioListener.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:165)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2$1.apply(GridRestProcessor.java:162)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
> at 
> 

[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6055:
-

[~vozerov]

I think we should add an ability to setup length constraints for a String field 
through {{QueryEntity}} or {{QuerySqlField}}, also.
Should I do it in this issue? 
Or should I create a separate ticket?

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Updated] (IGNITE-8452) ML module compilation failure under JDK 9

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-8452:
-
Summary: ML module compilation failure under JDK 9  (was: ML module 
compilation failure under Java 9)

> ML module compilation failure under JDK 9
> -
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Updated] (IGNITE-8454) Hadoop module compilation failure under JDK9

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-8454:
-
  Priority: Blocker  (was: Major)
Issue Type: Bug  (was: Task)

> Hadoop module compilation failure under JDK9
> 
>
> Key: IGNITE-8454
> URL: https://issues.apache.org/jira/browse/IGNITE-8454
> Project: Ignite
>  Issue Type: Bug
>Reporter: Peter Ivanov
>Priority: Blocker
>
> Reproduced on Linux (Mac is OK)
> {code}
> [16:38:27][Step 4/5] [ERROR] Failed to execute goal on project ignite-hadoop: 
> Could not resolve dependencies for project 
> org.apache.ignite:ignite-hadoop:jar:2.5.0-SNAPSHOT: Could not find artifact 
> jdk.tools:jdk.tools:jar:1.6 at specified path 
> /usr/lib/jvm/java-9-oracle/../lib/tools.jar
> {code}
> Possibly relates to Scala 2.10-2.11: 
> https://lists.apache.org/thread.html/%3caf9b21681d3ee94aa935901747be4b813a3b4...@shsmsx101.ccr.corp.intel.com%3E



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

[jira] [Updated] (IGNITE-8452) ML module compilation failure under JDK 9

[Peter Ivanov (JIRA)]

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

Peter Ivanov updated IGNITE-8452:
-
Issue Type: Bug  (was: Improvement)

> ML module compilation failure under JDK 9
> -
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Resolved] (IGNITE-7608) Sort keys in putAll/removeAll methods

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii resolved IGNITE-7608.

Resolution: Won't Fix

> Sort keys in putAll/removeAll methods
> -
>
> Key: IGNITE-7608
> URL: https://issues.apache.org/jira/browse/IGNITE-7608
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1, 2.2
> Environment: We need to sort keys in cache putAll/removeAll 
> operations to avoid deadlocks there.
>Reporter: Alexander Belyak
>Assignee: Ryabov Dmitrii
>Priority: Major
>




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

[jira] [Commented] (IGNITE-7608) Sort keys in putAll/removeAll methods

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-7608:


So, if there is no objections, I'm closing this ticket and for solving 
deadlocks we have IGNITE-6895.

> Sort keys in putAll/removeAll methods
> -
>
> Key: IGNITE-7608
> URL: https://issues.apache.org/jira/browse/IGNITE-7608
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0, 2.1, 2.2
> Environment: We need to sort keys in cache putAll/removeAll 
> operations to avoid deadlocks there.
>Reporter: Alexander Belyak
>Assignee: Ryabov Dmitrii
>Priority: Major
>




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

[jira] [Created] (IGNITE-8454) Hadoop module compilation failure under JDK9

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8454:


 Summary: Hadoop module compilation failure under JDK9
 Key: IGNITE-8454
 URL: https://issues.apache.org/jira/browse/IGNITE-8454
 Project: Ignite
  Issue Type: Task
Reporter: Peter Ivanov


Reproduced on Linux (Mac is OK)
{code}
[16:38:27][Step 4/5] [ERROR] Failed to execute goal on project ignite-hadoop: 
Could not resolve dependencies for project 
org.apache.ignite:ignite-hadoop:jar:2.5.0-SNAPSHOT: Could not find artifact 
jdk.tools:jdk.tools:jar:1.6 at specified path 
/usr/lib/jvm/java-9-oracle/../lib/tools.jar
{code}
Possibly relates to Scala 2.10-2.11: 
https://lists.apache.org/thread.html/%3caf9b21681d3ee94aa935901747be4b813a3b4...@shsmsx101.ccr.corp.intel.com%3E



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

[jira] [Commented] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-8037:
--

The proposal fix is available.
We have to hold JDBC connection to H2 until node is stopped.
Otherwise the DB objects are reset.

> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Taras Ledkov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for disconnect/reconnect 
> event.
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.waitReconnectEvent(IgniteClientReconnectAbstractTest.java:120)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:297)
> at 
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:238)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.reconnectClientNode(DynamicColumnsAbstractConcurrentSelfTest.java:804)
> at 
> org.apache.ignite.internal.processors.cache.index.DynamicColumnsAbstractConcurrentSelfTest.checkClientReconnect(DynamicColumnsAbstractConcurrentSelfTest.java:781)
> at 
> 

[jira] [Commented] (IGNITE-8037) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart is flaky

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8037:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-8037  
DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
 is flaky



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

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

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

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


commit 741e07220470190177cc1daa6668900295e3e0bb
Author: tledkov-gridgain 
Date:   2018-05-08T14:41:38Z

IGNITE-8037: holds H2 JDBC connection until node is stopped

commit 6d34a41fbb51c6c49f9a9e532cac712322ad06a5
Author: tledkov-gridgain 
Date:   2018-05-08T14:58:02Z

Merge branch '_master' into ignite-8037




> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testClientReconnectWithNonDynamicCacheRestart
>  is flaky
> ---
>
> Key: IGNITE-8037
> URL: https://issues.apache.org/jira/browse/IGNITE-8037
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Taras Ledkov
>Priority: Major
>
> Test fails on TC as well as locally (although local runs reproduce failure 
> rarely: 1-3 failed tests for 100 runs).
> There are suspicious errors in logs:
> {noformat}
> [2018-03-23 
> 18:55:19,371][ERROR][exchange-worker-#630%index.DynamicColumnsConcurrentTransactionalPartitionedSelfTest4%][GridQueryProcessor]
>  Failed to clear indexing on cache unregister (will ignore): idx
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed 
> to set schema for DB connection for thread [schema=idx]
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:542)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:705)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2794)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1630)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:799)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:860)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1161)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1768)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.initCachesOnLocalJoin(GridDhtPartitionsExchangeFuture.java:784)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:666)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2344)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.h2.jdbc.JdbcSQLException: Schema "idx" not found; SQL 
> statement:
> SET SCHEMA "idx" [90079-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.engine.Database.getSchema(Database.java:1755)
> at org.h2.command.dml.Set.update(Set.java:408)
> at org.h2.command.CommandContainer.update(CommandContainer.java:101)
> at org.h2.command.Command.executeUpdate(Command.java:260)
> at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
> at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.connectionForThread(IgniteH2Indexing.java:534)
> ... 14 more{noformat}
> Test fails with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for 

[jira] [Commented] (IGNITE-8453) FileDecompressor may access HashMap without proper synchronization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8453:


GitHub user glukos opened a pull request:

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

IGNITE-8453 FileDecompressor may access HashMap without proper synchr…

…onizationcommit 7037022)

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

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

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

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


commit 2a735095f13de156533dd0488910906474dd9850
Author: Ivan Rakov 
Date:   2018-05-08T14:55:34Z

IGNITE-8453 FileDecompressor may access HashMap without proper 
synchronizationcommit 7037022)




> FileDecompressor may access HashMap without proper synchronization
> --
>
> Key: IGNITE-8453
> URL: https://issues.apache.org/jira/browse/IGNITE-8453
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.5
>
>
> Caused by IGNITE-8429.
> FileDecompressor performs a remove from regular HashMap (which is shared to 
> other threads) without synchronization.



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

[jira] [Created] (IGNITE-8453) FileDecompressor may access HashMap without proper synchronization

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-8453:
--

 Summary: FileDecompressor may access HashMap without proper 
synchronization
 Key: IGNITE-8453
 URL: https://issues.apache.org/jira/browse/IGNITE-8453
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Rakov
Assignee: Ivan Rakov
 Fix For: 2.5


Caused by IGNITE-8429.
FileDecompressor performs a remove from regular HashMap (which is shared to 
other threads) without synchronization.



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

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8439:
-

[~roman_s] I replied on dev-list about this fix. It will work but would be 
better to refactor class. So I didn't include it to 2.5 release.

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8430:


Github user asfgit closed the pull request at:

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


> implement getCurrentCoordinator method in IgniteMXBean
> --
>
> Key: IGNITE-8430
> URL: https://issues.apache.org/jira/browse/IGNITE-8430
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, user can obtain coordinator node id via JMX attribute Coordinator 
> of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean.
> However, to get this attribute, external utility JMX must first understand 
> which discovery SPI implementation is used at current grid, which is 
> inconvenient. Would be much better if that attribute was located in same 
> instance no matter which Disco SPI was configured.
> Please, add String CurrentCoordinator attribute to Ignite MX bean with 
> following meaning:
>   - for the cases, when node does not know current coordinator (e.g. 
> getCoordinator returns null), attribute should be empty string ''
>   - for the case, when node knows current coordinator, return following 
> coordinator properties formatted as string, separated by ',':
>-- Coordinator IP address
>-- Coordinator node ID
>-- Coordinator node order
>-- Coordinator Fully Qualified Domain Name



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

[jira] [Commented] (IGNITE-8435) Inconsistent data after StopNodeFailureHandler handles process termination

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-8435:
-

LGTM. Merged to master and ignite-2.5 branches. Thanks for contribution!

> Inconsistent data after StopNodeFailureHandler handles process termination
> --
>
> Key: IGNITE-8435
> URL: https://issues.apache.org/jira/browse/IGNITE-8435
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Steps to reproduce:
> 1. Cluster started with StopNodeFailureHandler in config.
> 2. Upload data to the caches and run accounts task (transfer the amount from 
> one account to another for some cache).
> 3. Terminate one thread (ttl-cleanup-worker for example for one node).
> 4. Wait until accounts task finished the work.
> 5. Check the sum for caches.
> Expected result:
> The sum is the same as before thread rermination.
> Actual result:
> The sum is not the same for some caches.
> Also, I see these exception in the logs for node with terminated thread:
> {code:java}
> [13:08:37,709][SEVERE][sys-stripe-1-#2][GridNearTxLocal] Commit failed.
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Commit produced a runtime exception (all transaction entries will be 
> invalidated): 
> GridDhtTxRemote[xid=8e4906dd261--0815-47fa--0004, 
> xidVersion=GridCacheVersion [topVer=135612410, order=1524132517096, nod
> eOrder=4], concurrency=OPTIMISTIC, isolation=REPEATABLE_READ, 
> state=COMMITTING, invalidate=false, rollbackOnly=false, 
> nodeId=6f5954fa-e283-4506-9344-7a8914774681, timeout=4990, duration=41]
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:742)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:815)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1316)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1228)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:97)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:213)
>  at 
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:211)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
>  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:1556)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
>  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:1091)
>  at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
>  at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: Runtime failure on 
> search row: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@1aa35c0b
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1668)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1263)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:1782)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:359)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3604)
>  at 
> 

[jira] [Commented] (IGNITE-8041) Add a GA Grid example that solves 'Knapsack Problem'

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8041:


Github user asfgit closed the pull request at:

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


> Add a GA Grid example that solves 'Knapsack Problem' 
> -
>
> Key: IGNITE-8041
> URL: https://issues.apache.org/jira/browse/IGNITE-8041
> Project: Ignite
>  Issue Type: New Feature
>  Components: ml
>Reporter: Turik Campbell
>Assignee: Yury Babak
>Priority: Minor
> Fix For: 2.6
>
>
> The _Knapsack Problem_ is well known combinatorial optimization problem where 
> the goal is to maximize the benefit of objects in a knapsack without 
> exceeding its capacity.
> Additional information:
> [https://en.wikipedia.org/wiki/Knapsack_problem]
>  



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

[jira] [Updated] (IGNITE-7912) control.sh script should show used WAL-segments

[Dmitriy Govorukhin (JIRA)]

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

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

> control.sh script should show used WAL-segments
> ---
>
> Key: IGNITE-7912
> URL: https://issues.apache.org/jira/browse/IGNITE-7912
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Filatov
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Fix For: 2.6
>
>
> We have to erase wal archive because wal archive can grow large and we must 
> have safe way to remove unused segments to free disk space.



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

[jira] [Commented] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8430:


I've checked code and it looks good to me, in the same time there is number of 
suspicious test fails, so I've retriggered these suites.

> implement getCurrentCoordinator method in IgniteMXBean
> --
>
> Key: IGNITE-8430
> URL: https://issues.apache.org/jira/browse/IGNITE-8430
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, user can obtain coordinator node id via JMX attribute Coordinator 
> of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean.
> However, to get this attribute, external utility JMX must first understand 
> which discovery SPI implementation is used at current grid, which is 
> inconvenient. Would be much better if that attribute was located in same 
> instance no matter which Disco SPI was configured.
> Please, add String CurrentCoordinator attribute to Ignite MX bean with 
> following meaning:
>   - for the cases, when node does not know current coordinator (e.g. 
> getCoordinator returns null), attribute should be empty string ''
>   - for the case, when node knows current coordinator, return following 
> coordinator properties formatted as string, separated by ',':
>-- Coordinator IP address
>-- Coordinator node ID
>-- Coordinator node order
>-- Coordinator Fully Qualified Domain Name



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

[jira] [Commented] (IGNITE-5136) GridLogThrottle memory leak

[Ivan Fedotov (JIRA)]

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

Ivan Fedotov commented on IGNITE-5136:
--

[~SomeFire], looks good to me.

> GridLogThrottle memory leak
> ---
>
> Key: IGNITE-5136
> URL: https://issues.apache.org/jira/browse/IGNITE-5136
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Stanilovsky Evgeny
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> class GridLogThrottle stores throttle info into map and noone clears it.



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

[jira] [Updated] (IGNITE-8446) Ability to check and completely fill transactions on creation

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-8446:
-
Fix Version/s: 2.6

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.6
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



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

[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8446:


GitHub user anton-vinogradov opened a pull request:

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

IGNITE-8446 Ability to check and completely fill transactions on crea…

…tion

Signed-off-by: Anton Vinogradov 

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

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

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

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


commit ff9be9907f2e75ac6c16ab53d425f886987966dd
Author: Anton Vinogradov 
Date:   2018-05-08T12:34:33Z

IGNITE-8446 Ability to check and completely fill transactions on creation

Signed-off-by: Anton Vinogradov 




> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



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

[jira] [Updated] (IGNITE-8446) Ability to check and completely fill transactions on creation

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-8446:
-
Description: 
Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
guarantee it filled. 
So, we have to add special event fired on {{tx}} creation. 
This event can be used to provide such guarantee.

Plan:
Event EVT_TX_STARTED should be created.
Tx.label should be recodred as a part of this event.
Test, checking it's possible to restrict tx creation without filling the meta 
should be added.

  was:
Event EVT_USR_TX_START should be created.
Tx.label should be recodred as a part of this event.
Test, checking it's possible to restrict tx creation without filling the meta 
should be added.


> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



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

[jira] [Commented] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4150:
-

Unfortunately there are two problems:
1) Some new failures in splitter due to changed model in H2
2) Changed dependency on vividsolution, which is a breaking change (artifact 
name and packages were changed).

We have to move the ticket to further release.

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Updated] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-4150:

Fix Version/s: (was: 2.5)
   2.6

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.6
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Commented] (IGNITE-7896) Files of evicted partitions are not removed from disk storage

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-7896:
--

Please, review my PR

> Files of evicted partitions are not removed from disk storage
> -
>
> Key: IGNITE-7896
> URL: https://issues.apache.org/jira/browse/IGNITE-7896
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java
>
>
> Look at test reproduction: 
> [^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java]



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

[jira] [Assigned] (IGNITE-8452) ML module compilation failure under Java 9

[Andrey Gura (JIRA)]

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

Andrey Gura reassigned IGNITE-8452:
---

Assignee: Yury Babak

> ML module compilation failure under Java 9
> --
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Assignee: Yury Babak
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Commented] (IGNITE-8422) Zookeeper discovery split brain detection shouldn't consider client nodes

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-8422:


[~Jokser], I've reviewed your changes. In general all looks good, but I have a 
few comments regarding yellow code and code style:
1. BitSetIterator#next doesn't throw NoSuchElementException
2. ClusterGraph - unused import, abbreviations are not used
3. DefaultCommunicationFailureResolver#clusterNodeIds - block around one-liner
4. FullyConnectedComponentSearcher - abbreviations 
5. FullyConnectedComponentSearcherTest - abbreviations, missing comments

> Zookeeper discovery split brain detection shouldn't consider client nodes
> -
>
> Key: IGNITE-8422
> URL: https://issues.apache.org/jira/browse/IGNITE-8422
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> Currently Zookeeper discovery checks each splitted cluster on full 
> connectivity taking into account client nodes. This is not correct, because 
> server and client nodes may use different networks to connect to each other. 
> It means that there can be client which sees both parts of splitted cluster 
> and breaks split brain recovery - full connected part of server nodes will be 
> never find.
> We should exclude client nodes from split brain analysis and improve split 
> brain tests to make them truly fair.



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

[jira] [Updated] (IGNITE-8452) ML module compilation failure under Java 9

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8452:

Priority: Blocker  (was: Critical)

> ML module compilation failure under Java 9
> --
>
> Key: IGNITE-8452
> URL: https://issues.apache.org/jira/browse/IGNITE-8452
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.4
>Reporter: Peter Ivanov
>Priority: Blocker
> Fix For: 2.5
>
>
> Running Apache Ignite build on master branch (commit: ) fails with following 
> error:
> {code}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
> (default-testCompile) on project ignite-ml: Compilation failure: Compilation 
> failure:
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> [ERROR] 
> /Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
>  incompatible types: java.lang.Object cannot be converted to java.lang.Integer
> {code}



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

[jira] [Created] (IGNITE-8452) ML module compilation failure under Java 9

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8452:


 Summary: ML module compilation failure under Java 9
 Key: IGNITE-8452
 URL: https://issues.apache.org/jira/browse/IGNITE-8452
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Peter Ivanov
 Fix For: 2.5


Running Apache Ignite build on master branch (commit: ) fails with following 
error:
{code}
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile 
(default-testCompile) on project ignite-ml: Compilation failure: Compilation 
failure:
[ERROR] 
/Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[62,45]
 incompatible types: java.lang.Object cannot be converted to java.lang.Integer
[ERROR] 
/Users/vveider/Development/VCS/Git/ignite/modules/ml/src/test/java/org/apache/ignite/ml/dataset/primitive/DatasetWrapperTest.java:[74,38]
 incompatible types: java.lang.Object cannot be converted to java.lang.Integer
{code}



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

[jira] [Assigned] (IGNITE-8449) Avoid empty acquiring/releasing checkpointReadLock for stale updates

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev reassigned IGNITE-8449:
--

Assignee: Sergey Kosarev

> Avoid empty acquiring/releasing checkpointReadLock for stale updates
> 
>
> Key: IGNITE-8449
> URL: https://issues.apache.org/jira/browse/IGNITE-8449
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Kosarev
>Assignee: Sergey Kosarev
>Priority: Major
>
> we have in
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#update(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionExchangeId,
>  
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap,
>  boolean)
> currently we have something like this
> {code:java}
>ctx.database().checkpointReadLock();
> try {
> ...
> if (isStaleUpdate(cur, parts)) {
> 
> return false;
> }
> .
> }
> finally {
> ctx.database().checkpointReadUnlock();
> }
>  {code}
> we'd better do not  accquire those lock for isStaleUpdate == true branch. It 
> can significantly decrease contention as this method can be hot (thousands 
> invocations per minute) see also IGNITE-8226
>  



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

[jira] [Commented] (IGNITE-5011) Add validation of input params of disco command

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5011:


[~kuaw26] could you please review this ticket? I'm not so strong in scala.

> Add validation of input params of disco command
> ---
>
> Key: IGNITE-5011
> URL: https://issues.apache.org/jira/browse/IGNITE-5011
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Wuwei Lin
>Priority: Trivial
>
> {code}
> visor> disco -t=0h
> java.lang.IllegalArgumentException: Time frame size is not positive in: 0h
> at org.apache.ignite.visor.visor$.timeFilter(visor.scala:2671)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand.disco(VisorDiscoveryCommand.scala:127)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.disco.VisorDiscoveryCommand$$anonfun$4.apply(VisorDiscoveryCommand.scala:282)
> at 
> org.apache.ignite.visor.commands.VisorConsole.mainLoop(VisorConsole.scala:217)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.delayedEndpoint$org$apache$ignite$visor$commands$VisorConsole$1(VisorConsole.scala:329)
> at 
> org.apache.ignite.visor.commands.VisorConsole$delayedInit$body.apply(VisorConsole.scala:318)
> at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
> at 
> scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.collection.immutable.List.foreach(List.scala:381)
> at 
> scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:35)
> at scala.App$class.main(App.scala:76)
> at 
> org.apache.ignite.visor.commands.VisorConsole$.main(VisorConsole.scala:318)
> at 
> org.apache.ignite.visor.commands.VisorConsole.main(VisorConsole.scala)
> (wrn) : Invalid command name: 'disco -t=0h'
> (wrn) : Type 'help' to print commands list.
> {code}



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

[jira] [Commented] (IGNITE-8450) [ML] Cleanup the ML package: remove unused vector/matrix classes

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8450:


GitHub user zaleslaw opened a pull request:

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

IGNITE-8450: Cleanup old algebra



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

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

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

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


commit 098d2832b3f4af23c72bc25f43e4ab8a95f2f416
Author: Zinoviev Alexey 
Date:   2018-04-11T18:40:27Z

IGNITE-7829: Added example

commit 78f9ea687bff77ec9f6bef87126569cb92cbe745
Author: Zinoviev Alexey 
Date:   2018-04-13T15:44:26Z

Merge branch 'master' of https://github.com/apache/ignite

commit 199e17d19ccbde9f15aba5375d834c3930b3a989
Author: Zinoviev Alexey 
Date:   2018-04-27T10:12:47Z

Merge branch 'master' of https://github.com/apache/ignite

commit aca9833df4d3cc4a641dd9109daaf628bc85acdf
Author: Zinoviev Alexey 
Date:   2018-05-08T05:29:49Z

Merge branch 'master' of https://github.com/apache/ignite

commit 861102f115fdd2458aa30ff098395100885bae33
Author: Zinoviev Alexey 
Date:   2018-05-08T10:56:46Z

Removed old algebra




> [ML] Cleanup the ML package: remove unused vector/matrix classes
> 
>
> Key: IGNITE-8450
> URL: https://issues.apache.org/jira/browse/IGNITE-8450
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Remove
>  * unused algebraic classes
>  * related tests
>  * related matrix algorithms
>  * realted utils staff
>  * related examples
>  * related yardstick tests
>  



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

[jira] [Commented] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8429:


[~agura], please review.

 

[~ivan.glukos], I'm impressed TC run is green for PDS

> Unexpected error during incorrect WAL segment decompression, causes node 
> termination.
> -
>
> Key: IGNITE-8429
> URL: https://issues.apache.org/jira/browse/IGNITE-8429
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> File decompressor failure due to incorrect (zero-length) archived segment. 
> 2018-04-30 00:00:02.811 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, 
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104)
> 2018-04-30 00:00:02.812 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  JVM will be halted immediately due to the failure: 
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> touch 0754.wal
> zip 0754.wal.zip 0754.wal
> ls -l
> -rw-rw-r-- 1 dmitriy dmitriy   0 май  1 16:40 0754.wal
> -rw-rw-r-- 1 dmitriy dmitriy 190 май  1 16:46 0754.wal.zip
> Archive:  /tmp/temp/0754.wal.zip
>  Length   MethodSize  CmprDateTime   CRC-32   Name
>   --  ---  -- -   
>0  Stored0   0% 2018-05-01 16:40   0754.wal
>   ---  ------
>00   0%1 file
> We should softly handle this situation: print message in log and continue the 
> decompression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

[jira] [Commented] (IGNITE-8429) Unexpected error during incorrect WAL segment decompression, causes node termination.

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin commented on IGNITE-8429:


[~dpavlov] , please review.

[TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=projectOverview_IgniteTests24Java8=pull%2F3955%2Fhead]

> Unexpected error during incorrect WAL segment decompression, causes node 
> termination.
> -
>
> Key: IGNITE-8429
> URL: https://issues.apache.org/jira/browse/IGNITE-8429
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Rakov
>Priority: Critical
>  Labels: WAL
> Fix For: 2.5
>
>
> File decompressor failure due to incorrect (zero-length) archived segment. 
> 2018-04-30 00:00:02.811 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  Critical system error detected. Will be handled accordingly to configured 
> handler [hnd=class o.a.i.failure.StopNodeOrHaltFailureHandler, 
> failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly
> at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileDecompressor.run(FileWriteAheadLogManager.java:2104)
> 2018-04-30 00:00:02.812 
> [ERROR][wal-file-decompressor%DPL_GRID%DplGridNodeName][org.apache.ignite.Ignite]
>  JVM will be halted immediately due to the failure: 
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, 
> err=java.lang.IllegalStateException: Thread 
> wal-file-decompressor%DPL_GRID%DplGridNodeName is terminated unexpectedly]]
> touch 0754.wal
> zip 0754.wal.zip 0754.wal
> ls -l
> -rw-rw-r-- 1 dmitriy dmitriy   0 май  1 16:40 0754.wal
> -rw-rw-r-- 1 dmitriy dmitriy 190 май  1 16:46 0754.wal.zip
> Archive:  /tmp/temp/0754.wal.zip
>  Length   MethodSize  CmprDateTime   CRC-32   Name
>   --  ---  -- -   
>0  Stored0   0% 2018-05-01 16:40   0754.wal
>   ---  ------
>00   0%1 file
> We should softly handle this situation: print message in log and continue the 
> decompression with next segment.
> We also should handle "skipped" segments and don't delete them in 
> deleteObsoleteRawSegments().



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

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

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-8039:
-

[~alexey.kosenchuk],

Ok, I'll add this type description to documentation.

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



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

[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6055:
-

[~vozerov]

> why do we need to truncate anything on select? 

I think we should truncate *existing* data *if* 
{{ENABLE_COLUMN_CONSTRAINTS==true}}.

Data can be inserted in cache with previous Ignite version or with 
{{ENABLE_COLUMN_CONSTRAINTS==false}}.

>  we should have consistent behavior in both SQL and cache API

Got it. 

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6055:
-

[~NIzhikov], in general looks good, but if we truncate data on insert/update 
then why do we need to truncate anything on select? Another important issue - 
we should have consistent behavior in both SQL and cache API. But if we reject 
too long data on puts (either through SQL or cache API), it should works fine 
in all cases.

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

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

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-5945:
---

Assignee: Alexander Menshikov

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



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

[jira] [Comment Edited] (IGNITE-7823) Separate cache for non collocated IgniteSet.

[Pavel Pereslegin (JIRA)]

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

Pavel Pereslegin edited comment on IGNITE-7823 at 5/8/18 10:03 AM:
---

Implementation details.
* DataStructuresProcessor#compatibleCache creates separate cache for each new 
non-collocated version of IgniteSet (method IgniteSet#close destroys this 
cache).
 * A new implementation of IgniteSet called IgniteCacheSetImpl was introduced 
(also a separate proxy IgniteCacheSetProxy was created), duplicate code 
(GridCacheSetImpl and GridCacheSetProxy) should be removed in next major 
release.
 * Header is not used by non-collocated version of IgniteSet. Header is needed 
to identify keys in the shared cache, but with separate cache the 
GridCacheSetImpl implementation serves as an adapter for Set operations on this 
cache and does not require header.
 * CacheDataStructuresManager#set creates new instance of non-collocated 
version on each invocation.


was (Author: xtern):
Implementation details (changes affect only non-collocated version of 
IgniteSet).
 * DataStructuresProcessor#compatibleCache creates separate cache for each new 
non-collocated version of IgniteSet (method IgniteSet#close destroys this 
cache).
 * Header is not used by GridCacheSetImpl. Header is needed to identify keys in 
the shared cache, but with separate cache the GridCacheSetImpl implementation 
serves as an adapter for Set operations on this cache and does not require 
header.
 * CacheDataStructuresManager#set creates new instance GridCacheSetImpl on each 
invocation.
 * Flag "sharedCacheMode" in GridCacheSetImpl shows which version of Set was 
created (true - shared cache, false - separate cache).

> Separate cache for non collocated IgniteSet.
> 
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
>  Issue Type: New Feature
>  Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Currently, single data structures cache is shared between several collection 
> instances (IgniteQueue, IgniteSet).
> To support iterator() and size() IgniteSet maintains plain on-heap Java sets 
> on every node (see CacheDataStructuresManager.setDataMap). These sets 
> duplicate backing-cache entries, both primary and backup. For big 
> non-collocated sets it's too expensive to maintain redundant onheap data 
> copies. The simplest way to avoid copies is to use separate cache for 
> non-collocated IgniteSet version; hence size of set is the same as size of 
> backing cache, and also set iterator is virtually the same as backing cache 
> iterator. 
> The difference between exising set implementation and set based on separate 
> cache should be properly documented afterwards.



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

[jira] [Updated] (IGNITE-8443) Flaky failure of IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-8443:

Fix Version/s: 2.6

> Flaky failure of 
> IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode
> ---
>
> Key: IGNITE-8443
> URL: https://issues.apache.org/jira/browse/IGNITE-8443
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Test fails on TC sometimes (failure rate: 30%) with the following error:
> {noformat}
> junit.framework.AssertionFailedError: Failed to wait for update.
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.multinode(IgniteCacheClientNodeChangingTopologyTest.java:1855)
> at 
> org.apache.ignite.internal.processors.cache.distributed.IgniteCacheClientNodeChangingTopologyTest.testPessimisticTxPutAllMultinode(IgniteCacheClientNodeChangingTopologyTest.java:1673)
> {noformat}
> Each time some seconds prior to failure there is error in log:
> {noformat}
> [ERROR][sys-stripe-10-#90529%distributed.IgniteCacheClientNodeChangingTopologyTest0%][GridDhtColocatedCache]
>   Failed to unmarshal at least one of the keys for lock request 
> message: GridNearLockRequest [topVer=AffinityTopologyVersion [topVer=10, 
> minorTopVer=0], miniId=1, dhtVers=[...], 
> subjId=5ad87047-5d80-4530-bb48-f7c26846, taskNameHash=0, createTtl=-1, 
> accessTtl=-1, flags=6, filter=null, super=GridDistributedLockRequest 
> [nodeId=5ad87047-5d80-4530-bb48-f7c26846, nearXidVer=GridCacheVersion 
> [topVer=136730132, order=1525250131532, nodeOrder=7], threadId=100107, 
> futId=3e2912f2361-94bff164-8062-4fb4-8d85-c2e89e579148, timeout=0, 
> isInTx=true, isInvalidate=false, isRead=false, isolation=REPEATABLE_READ, 
> retVals=[...], txSize=0, flags=0, keysCnt=94, 
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=136730132, 
> order=1525250131532, nodeOrder=7], committedVers=null, rolledbackVers=null, 
> cnt=0, super=GridCacheIdMessage [cacheId=1544803905
>  class 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException
>  [part=54, msg=Adding entry to partition that is concurrently evicted 
> [grp=default, part=54, shouldBeMoving=, belongs=true, 
> topVer=AffinityTopologyVersion [topVer=10, minorTopVer=0], 
> curTopVer=AffinityTopologyVersion [topVer=10, minorTopVer=1]]]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:923)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:798)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:955)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryExx(GridDhtCacheAdapter.java:545)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:987)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest0(GridDhtTransactionalCacheAdapter.java:667)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$800(GridDhtTransactionalCacheAdapter.java:94)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12$1.run(GridDhtTransactionalCacheAdapter.java:704)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:511)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



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

[jira] [Comment Edited] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6055 at 5/8/18 9:39 AM:
-

[~vozerov]

I propose following design for this issue and IGNITE-8331:

1. We should reject with exception {{UPDATE}}, {{INSERT}}, {{MERGE}} statements 
that violates fields constraint.
2. We should truncate existing data when returning {{SELECT}} results.

3. We should introduce system property to enable/disable behaviour described in 
1, 2. (to preserve compatibility with current behaviour). 
{{ENABLE_COLUMN_CONSTRAINTS}}. Default value until 3.0 is {{false}}.


was (Author: nizhikov):
[~vozerov]

I propose following design for this issue and IGNITE-8331:

1. We should reject with exceptoin {{UPDATE}} and {{INSERT}} statements that 
violates fields constraint.
2. We should truncate existing data when returning {{SELECT}} results.

3. We should introduce system property to enable/disable behaviour described in 
1, 2. (to preserve compatibility with current behaviour). 
{{ENABLE_COLUMN_CONSTRAINTS}}. Default value until 3.0 is {{false}}.

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Commented] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov commented on IGNITE-8430:
---

TC - 
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=projectOverview_IgniteTests24Java8=pull%2F3957%2Fhead]

UP - https://reviews.ignite.apache.org/ignite/review/IGNT-CR-598

> implement getCurrentCoordinator method in IgniteMXBean
> --
>
> Key: IGNITE-8430
> URL: https://issues.apache.org/jira/browse/IGNITE-8430
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, user can obtain coordinator node id via JMX attribute Coordinator 
> of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean.
> However, to get this attribute, external utility JMX must first understand 
> which discovery SPI implementation is used at current grid, which is 
> inconvenient. Would be much better if that attribute was located in same 
> instance no matter which Disco SPI was configured.
> Please, add String CurrentCoordinator attribute to Ignite MX bean with 
> following meaning:
>   - for the cases, when node does not know current coordinator (e.g. 
> getCoordinator returns null), attribute should be empty string ''
>   - for the case, when node knows current coordinator, return following 
> coordinator properties formatted as string, separated by ',':
>-- Coordinator IP address
>-- Coordinator node ID
>-- Coordinator node order
>-- Coordinator Fully Qualified Domain Name



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

[jira] [Commented] (IGNITE-8430) implement getCurrentCoordinator method in IgniteMXBean

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8430:


GitHub user akalash opened a pull request:

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

IGNITE-8430 implemented getCurrentCoordinatorFormatted method in Igni…

…teMXBean

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

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

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

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


commit 0aa57ba6e47baff658279e53d38f6364e2626fbf
Author: Anton Kalashnikov 
Date:   2018-05-08T09:26:57Z

IGNITE-8430 implemented getCurrentCoordinatorFormatted method in 
IgniteMXBean




> implement getCurrentCoordinator method in IgniteMXBean
> --
>
> Key: IGNITE-8430
> URL: https://issues.apache.org/jira/browse/IGNITE-8430
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.5
>Reporter: Max Shonichev
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.5
>
>
> Currently, user can obtain coordinator node id via JMX attribute Coordinator 
> of TcpDiscoverySpi OR ZookeeperDiscoverySpi MBean.
> However, to get this attribute, external utility JMX must first understand 
> which discovery SPI implementation is used at current grid, which is 
> inconvenient. Would be much better if that attribute was located in same 
> instance no matter which Disco SPI was configured.
> Please, add String CurrentCoordinator attribute to Ignite MX bean with 
> following meaning:
>   - for the cases, when node does not know current coordinator (e.g. 
> getCoordinator returns null), attribute should be empty string ''
>   - for the case, when node knows current coordinator, return following 
> coordinator properties formatted as string, separated by ',':
>-- Coordinator IP address
>-- Coordinator node ID
>-- Coordinator node order
>-- Coordinator Fully Qualified Domain Name



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

[jira] [Assigned] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications

[Alexey Kosenchuk (JIRA)]

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

Alexey Kosenchuk reassigned IGNITE-8411:


Assignee: Denis Magda

> Binary Client Protocol spec: other parts clarifications
> ---
>
> Key: IGNITE-8411
> URL: https://issues.apache.org/jira/browse/IGNITE-8411
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Assignee: Denis Magda
>Priority: Major
>
> issues against previous parts: IGNITE-8039 IGNITE-8212
> Cache Configuration
>  ---
>  
> [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations]
>  - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - 
> QueryEntity - Structure of QueryField:
>  absent "default value - type Object" - it is the last field of the 
> QueryField in reality.
>  - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration:
>  Absent CacheAtomicityMode - is the first field in reality.
>  Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and 
> MaxQueryIterators in reality.
>  "Invalidate" field - does not exist in reality.
>  - meaning and possible values of every configuration parameter must be 
> clarified. If clarified in other docs, this spec must have link(s) to that 
> docs.
>  - suggest to combine somehow Cache Configuration descriptions in 
> OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid 
> duplicated descriptions.
> SQL and Scan Queries
>  
>  [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations]
>  - "Flag. Pass 0 for default, or 1 to keep the value in binary form.":
>  "the value in binary form" flag should be left end clarified in the 
> operations to which it is applicable for.
>  - OP_QUERY_SQL:
>  most of the fields in the request must be clarified. If clarified in other 
> docs, this spec must have link(s) to that docs.
>  For example:
>  ** "Name of a type or SQL table": name of what type?
>  - OP_QUERY_SQL_FIELDS:
>  most of the fields in the request must be clarified. If clarified in other 
> docs, this spec must have link(s) to that docs.
>  For example:
>  ** is there any correlation between "Query cursor page size" and "Max rows"?
>  ** "Statement type": why there are only three types? what about INSERT, etc.?
>  - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. 
> But responses for all other query operations contain it. Is it intentional?
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality.
>  - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type 
> "long". Should be "int".
>  - OP_QUERY_SCAN:
>  format and rules of the Filter object must be clarified. If clarified in 
> other docs, this spec must have link(s) to that docs.
>  - OP_QUERY_SCAN:
>  in general, it's not clear how this operation should be supported on 
> platforms other than the mentioned in "Filter platform" field.
>  - OP_QUERY_SCAN: "Number of partitions to query"
>  Should be updated to "A partition number to query"
>  
> Binary Types
>  
>  
> [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations]
>  - somewhere should be explained when and why these operations need to be 
> supported by a client.
>  - Type id and Field id:
>  should be clarified that before an Id calculation Type and Field names must 
> be updated to low case.
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id:
>  in reality it is not a type id (hash code) but a type code (1, 2,... 10,... 
> 103,...).
>  - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name":
>  should be explained what is it. If explained in other docs, this spec must 
> have link(s) to that docs.
>  - OP_PUT_BINARY_TYPE - schema id:
>  mandatory algorithm of schema Id calculation must be described somewhere. If 
> described in other docs, this spec must have link(s) to that docs.
>  - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME:
>  should be explained when and why these operations need to be supported by a 
> client.
>  How this operation should be supported on platforms other than the mentioned 
> in "Platform id" field.
>  - OP_REGISTER_BINARY_TYPE_NAME:
>  Type name - is it "full" or "short" name here?
>  Type id - is it a hash from "full" or "short" name here?



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

[jira] [Comment Edited] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4150 at 5/8/18 9:01 AM:
-

TC run: https://ci.ignite.apache.org/viewLog.html?buildId=1274486


was (Author: vozerov):
https://ci.ignite.apache.org/viewLog.html?buildId=1274486;

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Comment Edited] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov edited comment on IGNITE-6055 at 5/8/18 9:01 AM:
-

[~vozerov]

I propose following design for this issue and IGNITE-8331:

1. We should reject with exceptoin {{UPDATE}} and {{INSERT}} statements that 
violates fields constraint.
2. We should truncate existing data when returning {{SELECT}} results.

3. We should introduce system property to enable/disable behaviour described in 
1, 2. (to preserve compatibility with current behaviour). 
{{ENABLE_COLUMN_CONSTRAINTS}}. Default value until 3.0 is {{false}}.


was (Author: nizhikov):
[~vozerov]

I propose following design for this issue and IGNITE-8331:

1. We should reject with exceptoin {{UPDATE}} and {{INSERT}} statements that 
violates fields constraint.
2. We should truncate existing data when returning {{SELECT} results.

3. We should introduce system property to enable/disable behaviour described in 
1, 2. (to preserve compatibility with current behaviour). 
{{ENABLE_COLUMN_CONSTRAINTS}}. Default value until 3.0 is {{false}}.

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Comment Edited] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4150 at 5/8/18 9:01 AM:
-

https://ci.ignite.apache.org/viewLog.html?buildId=1274486;


was (Author: vozerov):
Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=1274474

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Commented] (IGNITE-6055) SQL: Add String length constraint

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6055:
-

[~vozerov]

I propose following design for this issue and IGNITE-8331:

1. We should reject with exceptoin {{UPDATE}} and {{INSERT}} statements that 
violates fields constraint.
2. We should truncate existing data when returning {{SELECT} results.

3. We should introduce system property to enable/disable behaviour described in 
1, 2. (to preserve compatibility with current behaviour). 
{{ENABLE_COLUMN_CONSTRAINTS}}. Default value until 3.0 is {{false}}.

> SQL: Add String length constraint
> -
>
> Key: IGNITE-6055
> URL: https://issues.apache.org/jira/browse/IGNITE-6055
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: sql-engine
>
> We should support {{CHAR(X)}} and {{VARCHAR{X}} syntax. Currently, we ignore 
> it. First, it affects semantics. E.g., one can insert a string with greater 
> length into a cache/table without any problems. Second, it limits efficiency 
> of our default configuration. E.g., index inline cannot be applied to 
> {{String}} data type as we cannot guess it's length.



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

[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications

[Alexey Kosenchuk (JIRA)]

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

Alexey Kosenchuk updated IGNITE-8411:
-
Description: 
issues against previous parts: IGNITE-8039 IGNITE-8212

Cache Configuration
 ---
 
[https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations]
 - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - 
QueryEntity - Structure of QueryField:
 absent "default value - type Object" - it is the last field of the QueryField 
in reality.

 - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration:
 Absent CacheAtomicityMode - is the first field in reality.
 Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and 
MaxQueryIterators in reality.
 "Invalidate" field - does not exist in reality.

 - meaning and possible values of every configuration parameter must be 
clarified. If clarified in other docs, this spec must have link(s) to that docs.

 - suggest to combine somehow Cache Configuration descriptions in 
OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid 
duplicated descriptions.

SQL and Scan Queries
 
 [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations]
 - "Flag. Pass 0 for default, or 1 to keep the value in binary form.":
 "the value in binary form" flag should be left end clarified in the operations 
to which it is applicable for.

 - OP_QUERY_SQL:
 most of the fields in the request must be clarified. If clarified in other 
docs, this spec must have link(s) to that docs.
 For example:
 ** "Name of a type or SQL table": name of what type?

 - OP_QUERY_SQL_FIELDS:
 most of the fields in the request must be clarified. If clarified in other 
docs, this spec must have link(s) to that docs.
 For example:
 ** is there any correlation between "Query cursor page size" and "Max rows"?
 ** "Statement type": why there are only three types? what about INSERT, etc.?

 - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. But 
responses for all other query operations contain it. Is it intentional?

 - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality.

 - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type "long". 
Should be "int".

 - OP_QUERY_SCAN:
 format and rules of the Filter object must be clarified. If clarified in other 
docs, this spec must have link(s) to that docs.

 - OP_QUERY_SCAN:
 in general, it's not clear how this operation should be supported on platforms 
other than the mentioned in "Filter platform" field.

 - OP_QUERY_SCAN: "Number of partitions to query"
 Should be updated to "A partition number to query"
 
Binary Types
 
 
[https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations]
 - somewhere should be explained when and why these operations need to be 
supported by a client.

 - Type id and Field id:
 should be clarified that before an Id calculation Type and Field names must be 
updated to low case.

 - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id:
 in reality it is not a type id (hash code) but a type code (1, 2,... 10,... 
103,...).

 - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name":
 should be explained what is it. If explained in other docs, this spec must 
have link(s) to that docs.

 - OP_PUT_BINARY_TYPE - schema id:
 mandatory algorithm of schema Id calculation must be described somewhere. If 
described in other docs, this spec must have link(s) to that docs.

 - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME:
 should be explained when and why these operations need to be supported by a 
client.
 How this operation should be supported on platforms other than the mentioned 
in "Platform id" field.

 - OP_REGISTER_BINARY_TYPE_NAME:
 Type name - is it "full" or "short" name here?
 Type id - is it a hash from "full" or "short" name here?

  was:
Cache Configuration
 ---
 
[https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations]
 - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - 
QueryEntity - Structure of QueryField:
 absent "default value - type Object" - it is the last field of the QueryField 
in reality.

 - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration:
 Absent CacheAtomicityMode - is the first field in reality.
 Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and 
MaxQueryIterators in reality.
 "Invalidate" field - does not exist in reality.

 - meaning and possible values of every configuration parameter must be 
clarified. If clarified in other docs, this spec must have link(s) to that docs.

 - suggest to combine somehow Cache Configuration descriptions in 
OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid 
duplicated descriptions.

 

[jira] [Commented] (IGNITE-8439) IGNITE_JETTY_HOST doesn't work (never has probably)

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-8439:
--

[~agura] Andrey, is it correct you are in charge of 2.5.0 release? Do you mind 
if I cherry-pick this fix into the release branch?

> IGNITE_JETTY_HOST doesn't work (never has probably)
> ---
>
> Key: IGNITE-8439
> URL: https://issues.apache.org/jira/browse/IGNITE-8439
> Project: Ignite
>  Issue Type: Bug
>  Components: rest
>Affects Versions: 2.4
>Reporter: Paul Anderson
>Assignee: Roman Shtykh
>Priority: Major
>
> GridJettyRestProtocol.java
>  
>  public void start(GridRestProtocolHandler hnd)
> ...
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress())
> ...
> should be
>  if(System.getProperty(IGNITE_JETTY_HOST)==null) 
> System.setProperty(IGNITE_JETTY_HOST, locHost.getHostAddress());



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

[jira] [Commented] (IGNITE-8447) .NET: DataStreamer.perThreadBufferSize

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8447:
-

There is failed test in .Net after this merge.
I reruned Platform .NET (Core Linux) and it succeed.

https://ci.ignite.apache.org/viewLog.html?buildId=1274462=queuedBuildOverviewTab

> .NET: DataStreamer.perThreadBufferSize 
> ---
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Comment Edited] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-4150 at 5/8/18 8:39 AM:
-

Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=1274474


was (Author: vozerov):
Test run: 
https://ci.ignite.apache.org/viewLog.html?buildId=1274365=buildResultsDiv=IgniteTests24Java8_RunAllSql

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Updated] (IGNITE-8451) [ML] Refactor Labeled Dataset: remove unused methods and fields

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8451:
-
Description: 
Remove
 * loading from file
 * distributed version (we need local version only)

> [ML] Refactor Labeled Dataset: remove unused methods and fields
> ---
>
> Key: IGNITE-8451
> URL: https://issues.apache.org/jira/browse/IGNITE-8451
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Remove
>  * loading from file
>  * distributed version (we need local version only)



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

[jira] [Updated] (IGNITE-8451) [ML] Refactor Labeled Dataset: remove unused methods and fields

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8451:
-
Description: 
Remove
 * loading from file
 * distributed version (we need local version only)
 * parent class Dataset and meta-information

  was:
Remove
 * loading from file
 * distributed version (we need local version only)


> [ML] Refactor Labeled Dataset: remove unused methods and fields
> ---
>
> Key: IGNITE-8451
> URL: https://issues.apache.org/jira/browse/IGNITE-8451
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Remove
>  * loading from file
>  * distributed version (we need local version only)
>  * parent class Dataset and meta-information



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

[jira] [Created] (IGNITE-8451) [ML] Refactor Labeled Dataset: remove unused methods and fields

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8451:


 Summary: [ML] Refactor Labeled Dataset: remove unused methods and 
fields
 Key: IGNITE-8451
 URL: https://issues.apache.org/jira/browse/IGNITE-8451
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Updated] (IGNITE-8450) [ML] Cleanup the ML package: remove unused vector/matrix classes

[Aleksey Zinoviev (JIRA)]

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

Aleksey Zinoviev updated IGNITE-8450:
-
Description: 
Remove
 * unused algebraic classes
 * related tests
 * related matrix algorithms
 * realted utils staff
 * related examples
 * related yardstick tests

 

> [ML] Cleanup the ML package: remove unused vector/matrix classes
> 
>
> Key: IGNITE-8450
> URL: https://issues.apache.org/jira/browse/IGNITE-8450
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>
> Remove
>  * unused algebraic classes
>  * related tests
>  * related matrix algorithms
>  * realted utils staff
>  * related examples
>  * related yardstick tests
>  



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

[jira] [Created] (IGNITE-8450) [ML] Cleanup the ML package: remove unused vector/matrix classes

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8450:


 Summary: [ML] Cleanup the ML package: remove unused vector/matrix 
classes
 Key: IGNITE-8450
 URL: https://issues.apache.org/jira/browse/IGNITE-8450
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Commented] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-4150:
-

Test run: 
https://ci.ignite.apache.org/viewLog.html?buildId=1274365=buildResultsDiv=IgniteTests24Java8_RunAllSql

> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Commented] (IGNITE-4150) B-Tree index cannot be used efficiently with IN clause.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-4150:


GitHub user devozerov opened a pull request:

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

IGNITE-4150



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

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

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

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


commit 32f2540d20223539e5a587993fa3e81d0d02961d
Author: devozerov 
Date:   2018-05-08T07:16:28Z

IGNITE-4150: Updated H2 version.




> B-Tree index cannot be used efficiently with IN clause.
> ---
>
> Key: IGNITE-4150
> URL: https://issues.apache.org/jira/browse/IGNITE-4150
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: performance
> Fix For: 2.5
>
>
> Consider the following query:
> {code}
> SELECT * FROM table
> WHERE a = ? AND b IN (?, ?)
> {code}
> If there is an index {{(a, b)}}, it will not be used properly: only column 
> {{a}} will be used. This will leads to multiple unnecessary comparisons.
> Most obvious way to fix that - use temporary table and {{JOIN}}. However, 
> this approach doesn't work well when there are multiple {{IN}}'s. 
> Proper solution would be to hack deeper into H2.



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

[jira] [Commented] (IGNITE-8434) .NET: Service proxies do not work on .NET Core

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-8434:


Cherry-picked to ignite-2.5: 4f45f59edd4e9b9c6f6bfbc2ddb526552e40b741

> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Service proxies do not work on .NET Core because of conditional compilation 
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never 
> used.
> Except in tests, so they pass.



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

[jira] [Resolved] (IGNITE-8434) .NET: Service proxies do not work on .NET Core

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-8434.

Resolution: Fixed

> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Service proxies do not work on .NET Core because of conditional compilation 
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never 
> used.
> Except in tests, so they pass.



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

[jira] [Commented] (IGNITE-8447) .NET: DataStreamer.perThreadBufferSize

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8447:


Github user asfgit closed the pull request at:

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


> .NET: DataStreamer.perThreadBufferSize 
> ---
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-8447) .NET: DataStreamer.perThreadBufferSize

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-8447:
-

[~ptupitsyn] Thank you!

Merged to master.

> .NET: DataStreamer.perThreadBufferSize 
> ---
>
> Key: IGNITE-8447
> URL: https://issues.apache.org/jira/browse/IGNITE-8447
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: .NET, MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> Need to add support of DataStreamer#perThreadBuffer property.
> It was added in IGNITE-6699.
> Related failed test - DataStreamerTest.TestBufferSize
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7699185391938208048=%3Cdefault%3E=testDetails



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

[jira] [Commented] (IGNITE-8434) .NET: Service proxies do not work on .NET Core

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-8434:


Merged to master: {{c9106fb0ac3f109aa07434911e265b1845984780}}.

> .NET: Service proxies do not work on .NET Core
> --
>
> Key: IGNITE-8434
> URL: https://issues.apache.org/jira/browse/IGNITE-8434
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> Service proxies do not work on .NET Core because of conditional compilation 
> in {{ServiceProxyTypeGenerator}}.
> We only compile for a single target, so {{NETCOREAPP2_0}} branch is never 
> used.
> Except in tests, so they pass.



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

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-3999 at 5/8/18 7:11 AM:
-

[~vkulichenko], [~dpavlov], [~NIzhikov], [~aakhmedov], [~al.psc],
In general this is not correct approach and I would recommend to stop working 
on this ticket. Defining separate type to control case sensitivity is not 
industry-wide practice. Instead, problems like this are solved through the 
following techniques:
1) Functional indexes - we do not have them, but this would be very nice 
addition to the product
2) Specifying collations on per-database, per-session or per-statement levels

We do not consider H2 as reference implementation for us, and do not want to 
support all it's features. Instead, our ultimate goal is to drop H2 and 
implement new features using industrial experience of major vendors. 

In any case, my comments to the ticket:
1) Indentation changes should be reverted, looks like your IDE doing this 
automatically. Patch should contain only real code changes.

2) {{QueryEntity}} is saved to metadata store on disk. Please make sure that 
binary compatibility is preserved between previous version and master. It 
should be possible to start a persistent cache with {{QueryEntity}} on the 
previous version, put some data to it, and then restart with master - node 
should start successfully and data should be available.

3) Solution is incomplete. You applied case insensitivity only to SQL. But we 
have other access path - cache. And cache operates on case-sensitive 
{{java.lang.Strings}}. Consider the following SQL snippet:
{code}
CREATE my_table (code VARCHAR_INSENSITIVE PRIMARY KEY, ...)
INSERT INTO (code) VALUES ('Test');
{code}

This call will remove a row:
{code}
DELETE FROM my_table WHERE code='test';
{code}

But this will not work:
{code}
ignite.cache("myTable").remove(new Key("test")); // "test" != "Test"
{code}

We strive to maintain consistent behavior irrespective of access path, so this 
should be fixed. But please note that this might be a huge thing, because all 
collation features should be respected. Provided complexity and lack of serious 
demand from users, I doubt this feature worth implementation at all. 


was (Author: vozerov):
[~vkulichenko], [~dpavlov], [~NIzhikov], [~aakhmedov], [~al.psc],
In general this is not correct approach and I would recommend to stop working 
on this ticket. Defining separate type to control case sensitivity is not 
industry-wide practice. Instead, problems like this are solved through the 
following techniques:
1) Functional indexes - we do not have them, but this would be very nice 
addition to the product
2) Specifying collations on per-database, per-session or per-statement levels

We do not consider H2 as reference implementation for us, and do not want to 
support all it's features. Instead, our ultimate goal is to drop H2 and 
implement new features using industrial experience of major vendors. 

In any case, my comments to the ticket:
1) Indentation changes should be reverted, looks like your IDE doing this 
automatically. Patch should contain only real code changes.

2) {{QueryEntity}} is saved to disk to metadata store. Please make sure that 
binary compatibility is preserved between previous version and master. It 
should be possible to start a persistent cache with {{QueryEntity}} on the 
previous version, put some data to is, and then restart with master - node 
should start successfully and data should be available.

3) Solution is incomplete. You applied case insensitivity only to SQL. But we 
have other access path - cache. And cache operates on case-sensitive 
{{java.lang.Strings}}. Consider the following SQL snippet:
{code}
CREATE my_table (code VARCHAR_INSENSITIVE PRIMARY KEY, ...)
INSERT INTO (code) VALUES ('Test');
{code}

This call will remove a row:
{code}
DELETE FROM my_table WHERE code='test';
{code}

But this will not work:
{code}
ignite.cache("myTable").remove(new Key("test")); // "test" != "Test"
{code}

We strive to maintain consistent behavior irrespective of access path, so this 
should be fixed. But please note that this might be a huge thing, because all 
collation features should be respected. Provided complexity and lack of serious 
demand from users, I doubt this feature worth implementation at all. 

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is 

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-3999 at 5/8/18 7:09 AM:
-

[~vkulichenko], [~dpavlov], [~NIzhikov], [~aakhmedov], [~al.psc],
In general this is not correct approach and I would recommend to stop working 
on this ticket. Defining separate type to control case sensitivity is not 
industry-wide practice. Instead, problems like this are solved through the 
following techniques:
1) Functional indexes - we do not have them, but this would be very nice 
addition to the product
2) Specifying collations on per-database, per-session or per-statement levels

We do not consider H2 as reference implementation for us, and do not want to 
support all it's features. Instead, our ultimate goal is to drop H2 and 
implement new features using industrial experience of major vendors. 

In any case, my comments to the ticket:
1) Indentation changes should be reverted, looks like your IDE doing this 
automatically. Patch should contain only real code changes.

2) {{QueryEntity}} is saved to disk to metadata store. Please make sure that 
binary compatibility is preserved between previous version and master. It 
should be possible to start a persistent cache with {{QueryEntity}} on the 
previous version, put some data to is, and then restart with master - node 
should start successfully and data should be available.

3) Solution is incomplete. You applied case insensitivity only to SQL. But we 
have other access path - cache. And cache operates on case-sensitive 
{{java.lang.Strings}}. Consider the following SQL snippet:
{code}
CREATE my_table (code VARCHAR_INSENSITIVE PRIMARY KEY, ...)
INSERT INTO (code) VALUES ('Test');
{code}

This call will remove a row:
{code}
DELETE FROM my_table WHERE code='test';
{code}

But this will not work:
{code}
ignite.cache("myTable").remove(new Key("test")); // "test" != "Test"
{code}

We strive to maintain consistent behavior irrespective of access path, so this 
should be fixed. But please note that this might be a huge thing, because all 
collation features should be respected. Provided complexity and lack of serious 
demand from users, I doubt this feature worth implementation at all. 


was (Author: vozerov):
[~vkulichenko], [~dpavlov], [~NIzhikov], [~aakhmedov], [~al.psc],
In general this is not correct approach and I would recommend to stop working 
on this ticket. Defining separate type to control sensitivity is not 
industry-wide practice. Instead, problems like this are solved through the 
following techniques:
1) Functional indexes - we do not have them, but this would be very nice 
addition to the product
2) Specifying collations on per-database, per-session or per-statement levels

We do not consider H2 as reference implementation for us, and do not want to 
support all it's features. Instead, our ultimate goal is to drop H2 and 
implement new features using industrial experience of major vendors. 

In any case, my comments to the ticket:
1) Indentation changes should be reverted, looks like your IDE doing this 
automatically. Patch should contain only real code changes.

2) {{QueryEntity}} is saved to disk to metadata store. Please make sure that 
binary compatibility is preserved between previous version and master. It 
should be possible to start a persistent cache with {{QueryEntity}} on the 
previous version, put some data to is, and then restart with master - node 
should start successfully and data should be available.

3) Solution is incomplete. You applied case insensitivity only to SQL. But we 
have other access path - cache. And cache operates on case-sensitive 
{{java.lang.Strings}}. Consider the following SQL snippet:
{code}
CREATE my_table (code VARCHAR_INSENSITIVE PRIMARY KEY, ...)
INSERT INTO (code) VALUES ('Test');
{code}

This call will remove a row:
{code}
DELETE FROM my_table WHERE code='test';
{code}

But this will not work:
{code}
ignite.cache("myTable").remove(new Key("test")); // "test" != "Test"
{code}

We strive to maintain consistent behavior irrespective of access path, so this 
should be fixed. But please note that this might be a huge thing, because all 
collation features should be respected. Provided complexity and lack of serious 
demand from users, I doubt this feature worth implementation at all. 

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.6
>
>
> Currently case insensitive search is 

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

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3999:
-

[~vkulichenko], [~dpavlov], [~NIzhikov], [~aakhmedov], [~al.psc],
In general this is not correct approach and I would recommend to stop working 
on this ticket. Defining separate type to control sensitivity is not 
industry-wide practice. Instead, problems like this are solved through the 
following techniques:
1) Functional indexes - we do not have them, but this would be very nice 
addition to the product
2) Specifying collations on per-database, per-session or per-statement levels

We do not consider H2 as reference implementation for us, and do not want to 
support all it's features. Instead, our ultimate goal is to drop H2 and 
implement new features using industrial experience of major vendors. 

In any case, my comments to the ticket:
1) Indentation changes should be reverted, looks like your IDE doing this 
automatically. Patch should contain only real code changes.

2) {{QueryEntity}} is saved to disk to metadata store. Please make sure that 
binary compatibility is preserved between previous version and master. It 
should be possible to start a persistent cache with {{QueryEntity}} on the 
previous version, put some data to is, and then restart with master - node 
should start successfully and data should be available.

3) Solution is incomplete. You applied case insensitivity only to SQL. But we 
have other access path - cache. And cache operates on case-sensitive 
{{java.lang.Strings}}. Consider the following SQL snippet:
{code}
CREATE my_table (code VARCHAR_INSENSITIVE PRIMARY KEY, ...)
INSERT INTO (code) VALUES ('Test');
{code}

This call will remove a row:
{code}
DELETE FROM my_table WHERE code='test';
{code}

But this will not work:
{code}
ignite.cache("myTable").remove(new Key("test")); // "test" != "Test"
{code}

We strive to maintain consistent behavior irrespective of access path, so this 
should be fixed. But please note that this might be a huge thing, because all 
collation features should be respected. Provided complexity and lack of serious 
demand from users, I doubt this feature worth implementation at all. 

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



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