date:20171012

[jira] [Resolved] (IGNITE-6616) WebConsole cache config parse

2017-10-12 Thread Alexander Belyak (JIRA)


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

Alexander Belyak resolved IGNITE-6616.
--
Resolution: Won't Fix

> WebConsole cache config parse
> -
>
> Key: IGNITE-6616
> URL: https://issues.apache.org/jira/browse/IGNITE-6616
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Minor
> Fix For: 2.4
>
>
> 1) Go to /monitoring/dashboard
> 2) Press Start cache button
> 3) Add  (without quotes in value)
> 4) Press Start button
> Expected result: warning about xml format
> Actual result: "Are you sure you want to start cache with name: ?" 
> message



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6616) WebConsole cache config parse

2017-10-12 Thread Alexander Belyak (JIRA)

Alexander Belyak created IGNITE-6616:


 Summary: WebConsole cache config parse
 Key: IGNITE-6616
 URL: https://issues.apache.org/jira/browse/IGNITE-6616
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Minor
 Fix For: 2.4


1) Go to /monitoring/dashboard
2) Press Start cache button
3) Add  (without quotes in value)
4) Press Start button
Expected result: warning about xml format
Actual result: "Are you sure you want to start cache with name: ?" 
message



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-12 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-6560:
-

Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Test configuration of data regions. Try to generate project and run node.
See IGNITE-6030 for more info.

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6287) DDL Support for WebConsole

2017-10-12 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov closed IGNITE-6287.
--

> DDL Support for WebConsole
> --
>
> Key: IGNITE-6287
> URL: https://issues.apache.org/jira/browse/IGNITE-6287
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Denis Magda
>Assignee: Pavel Konstantinov
>Priority: Critical
>  Labels: usability
> Fix For: 2.3
>
> Attachments: screenshot-1.png
>
>
> DDL queries like CREATE TABLE don't work in Web Console.
> First, if Ignite cluster is started with zero caches deployed then "Execute" 
> button will be disabled and there is now way to execute CREATE TABLE in 
> general.
> Second, if to create a dummy cache on cluster startup and execute this
> {code}
> CREATE TABLE City (
>   id LONG PRIMARY KEY, name VARCHAR)
>   WITH "template=replicated";
> {code}
> Then the console will generate the exception 
> {code}
> Error: class org.apache.ignite.internal.processors.query.IgniteSQLException: 
> CREATE TABLE can only be executed on PUBLIC schema.
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6190) SQL query fails silently if Set is passed as a parameter

2017-10-12 Thread Roman Shtykh (JIRA)


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

Roman Shtykh updated IGNITE-6190:
-
Fix Version/s: 2.4

> SQL query fails silently if Set is passed as a parameter
> 
>
> Key: IGNITE-6190
> URL: https://issues.apache.org/jira/browse/IGNITE-6190
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Denis Magda
>Assignee: Roman Shtykh
>  Labels: usability
> Fix For: 2.4
>
> Attachments: TestIgniteQuery.zip
>
>
> Seems like the SqlQuery API does not like {{Set}} as the input parameter. 
> While this query doesn't work (the Set is used as an input):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId);
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> This one works well (the Set is converted to Array explicitly):
> {code}
> public Map getAccountsForLe(Set leId) {
> SqlQuery query =
> new SqlQuery(Account.class, "from Account join 
> table(id varchar = ?) i on Account.clientLegalEntityId = i.id")
> .setArgs(leId.toArray());
> Map results = new HashMap<>();
> _cache.query(query).getAll().stream().forEach(e -> 
> results.put(e.getKey(), e.getValue()));
> return results;
> }
> {code}
> The fact that it fails silently is an issue. IMHO there should be some 
> validation to alert the calling code that the type specified is not valid or 
> the set has to be transformed to the array on the fly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6534) Configure NotNull fields with annotations

2017-10-12 Thread Roman Shtykh (JIRA)


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

Roman Shtykh updated IGNITE-6534:
-
Fix Version/s: 2.4

> Configure NotNull fields with annotations
> -
>
> Key: IGNITE-6534
> URL: https://issues.apache.org/jira/browse/IGNITE-6534
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Roman Shtykh
> Fix For: 2.4
>
>
> IGNITE-6509 introduces a way to configure non-null QueryEntity fields.
> Implement {{@QuerySqlField.notNull}} property to allow same thing via 
> annotations.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-6371:
-

[~ptupitsyn], looks good, thanks.

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6592) Describe Ignite C++ pointer reading and writing semantics

2017-10-12 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-6592:
-

@Igor Sapego, simplified the docs a bit. Please confirm that the current 
version is technically correct and assign the ticket on Prachi for the final 
review:
https://apacheignite-cpp.readme.io/v2.2/docs/serialization-23#section-reading-and-writing-values

> Describe Ignite C++ pointer reading and writing semantics
> -
>
> Key: IGNITE-6592
> URL: https://issues.apache.org/jira/browse/IGNITE-6592
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Need to describe how user can read and write nullable values using pointer 
> semantic in Ignite C++:
> {code}
> // One can write null value like this:
> writer.WriteObject(nullptr);
> // And read it like this:
> std::unique_ptr nullableVal = reader.ReadObject();
> if (nullableVal) {
>   // Processing...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6594) Add missing flags to the list of the ODBC connection string attributes.

2017-10-12 Thread Denis Magda (JIRA)


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

Denis Magda reassigned IGNITE-6594:
---

Assignee: Prachi Garg  (was: Igor Sapego)

> Add missing flags to the list of the ODBC connection string attributes.
> ---
>
> Key: IGNITE-6594
> URL: https://issues.apache.org/jira/browse/IGNITE-6594
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Prachi Garg
> Fix For: 2.3
>
>
> Need to add {{collocated}}, {{replicated_only}}, {{lazy}} and 
> {{update_on_server}} flags to the list of the ODBC connection string 
> attributes here: 
> https://apacheignite-sql.readme.io/v2.1/docs/connection-string-and-dsn



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6594) Add missing flags to the list of the ODBC connection string attributes.

2017-10-12 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-6594:
-

[~isapego], this is what's needed. Thanks!

[~pgarg], please review the properties listed in the description above and 
close the ticket:
https://apacheignite-sql.readme.io/v2.1/docs/connection-string-and-dsn

> Add missing flags to the list of the ODBC connection string attributes.
> ---
>
> Key: IGNITE-6594
> URL: https://issues.apache.org/jira/browse/IGNITE-6594
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Need to add {{collocated}}, {{replicated_only}}, {{lazy}} and 
> {{update_on_server}} flags to the list of the ODBC connection string 
> attributes here: 
> https://apacheignite-sql.readme.io/v2.1/docs/connection-string-and-dsn



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

2017-10-12 Thread Nikolay Izhikov (JIRA)


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

Nikolay Izhikov commented on IGNITE-6005:
-

[~agura], Thank you for review.

> Thread can be interrupted after Thread.interrupted() call and the problem 
> will be the same

Internally {{get}} and {{remove}} operation uses {{java.util.Semaphore}}
So I think we have to keep trying to remove data structure if we get 
InterruptedException to fix a described issue.

Do you have another solution without {{while(wasInterrupted)...}} loop ?

Please, see my updated PR.

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
>

[jira] [Updated] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-6371:
---
Fix Version/s: (was: 2.3)
   2.4

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.4
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6371:


[~dmagda] replied on GitHub.

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-6371:
-

[~ptupitsyn], forgot to submit the notes. Did now.

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6615) .NET: Thin client: XML configuration

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6615:
--

 Summary: .NET: Thin client: XML configuration
 Key: IGNITE-6615
 URL: https://issues.apache.org/jira/browse/IGNITE-6615
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
 Fix For: 2.4


Provide a way to configure {{IgniteClientConfiguration}} in XML, similar to 
{{IgniteConfiguration}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

2017-10-12 Thread Andrey Gura (JIRA)


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

Andrey Gura edited comment on IGNITE-6005 at 10/12/17 3:06 PM:
---

[~NIzhikov] The change doesn't fix the problem. Thread can be interrupted after 
{{Thread.interrupted()}} call and the problem will be the same.


was (Author: agura):
[~NIzhikov] The change doesn't fix the problem. Thread can be interrupted after 
call {{Thread.interrupted()}} and the problem will be the same.

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at

[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

2017-10-12 Thread Andrey Gura (JIRA)


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

Andrey Gura commented on IGNITE-6005:
-

[~NIzhikov] The change doesn't fix the problem. Thread can be interrupted after 
call {{Thread.interrupted()}} and the problem will be the same.

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.3
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
>

[jira] [Assigned] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ

2017-10-12 Thread Alexey Popov (JIRA)


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

Alexey Popov reassigned IGNITE-4723:


Assignee: Alexey Popov

> .NET: Support REGEXP_LIKE in LINQ
> -
>
> Key: IGNITE-4723
> URL: https://issues.apache.org/jira/browse/IGNITE-4723
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>  Labels: .NET, LINQ, newbie
>
> {{REGEXP_REPLACE}} H2 function is supported in LINQ via {{Regex.Replace}}, 
> see {{MethodVisitor}}.
> Add mapping for {{REGEXP_LIKE}} via {{Regex.IsMatch}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

2017-10-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6234:


Github user mcherkasov closed the pull request at:

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


> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at 
>

[jira] [Assigned] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-12 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko reassigned IGNITE-6560:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-12 Thread Denis Mekhanikov (JIRA)


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

Denis Mekhanikov reassigned IGNITE-6572:


Assignee: Denis Mekhanikov

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6560) Web console: New api for memory and persistence configuration

2017-10-12 Thread Vasiliy Sisko (JIRA)


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

Vasiliy Sisko commented on IGNITE-6560:
---

Implemented data transfer objects.
Implemented 'Data storage configuration' section of cluster configuration.

> Web console: New api for memory and persistence configuration
> -
>
> Key: IGNITE-6560
> URL: https://issues.apache.org/jira/browse/IGNITE-6560
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Affects Versions: 2.2
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
> Fix For: 2.3
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6614) .NET: DotNetCore examples

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6614:
--

 Summary: .NET: DotNetCore examples
 Key: IGNITE-6614
 URL: https://issues.apache.org/jira/browse/IGNITE-6614
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


.NET Thin Client works under .NET Core. Create separate examples project for 
that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5343) .NET: Interoperate with JVM directly, get rid of C++ layer

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-5343:
---
Labels: .NET xplat  (was: .NET)

> .NET: Interoperate with JVM directly, get rid of C++ layer
> --
>
> Key: IGNITE-5343
> URL: https://issues.apache.org/jira/browse/IGNITE-5343
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
>
> We can work with JNI directly using P/Invoke, there is no real need for C++ 
> layer.
> Advantages of removing C++ layer:
> * *No MSVC++ 2010 dependency*
> * *No build tools required for development*
> * Simplify and speed up the build procedure
> * No embedded libraries
> * Easier crossplatform support (IGNITE-2662)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-2662) .NET Standard support

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-2662:
---
Labels: .net xplat  (was: .net)

> .NET Standard support
> -
>
> Key: IGNITE-2662
> URL: https://issues.apache.org/jira/browse/IGNITE-2662
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>  Labels: .net, xplat
>
> Ignite.NET should target .NET Standard so it is available on maximum number 
> of platforms, see
> https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
> https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again
> https://github.com/dotnet/core/blob/master/roadmap.md
> This will allow us to run on Windows, OSX, and Linux, and target .NET Core in 
> additional to good old regular .NET.
> Possible difficulties:
> * JNI interop. Core has dllImport and it works on linux, and our C++ client 
> works on linux, so it should be possible
> * Reflection. We use it a lot, and API has changed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6613) .NET: Thin client: Create dotnet core unit test project, run on Linux

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6613:
--

 Summary: .NET: Thin client: Create dotnet core unit test project, 
run on Linux
 Key: IGNITE-6613
 URL: https://issues.apache.org/jira/browse/IGNITE-6613
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


.NET Thin Client actually works on .NET Core and on Linux. Let's add unit tests 
for that and run them on Linux machines to avoid regression.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6612) Wrap ack methods in their own class

2017-10-12 Thread Ivan Fedotov (JIRA)

Ivan Fedotov created IGNITE-6612:


 Summary: Wrap ack methods in their own class
 Key: IGNITE-6612
 URL: https://issues.apache.org/jira/browse/IGNITE-6612
 Project: Ignite
  Issue Type: Improvement
Affects Versions: None
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov
Priority: Trivial
 Fix For: 2.3



Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, 
“ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, 
“ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, 
“ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, 
“ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. 

These methods should be placed in separate class “AckVariousInformation” and 
called from the class instance in IgniteKernal.





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6057) SQL: Full scan should be performed through data pages bypassing primary index

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6057:

Labels: performance  (was: iep-1 performance)

> SQL: Full scan should be performed through data pages bypassing primary index
> -
>
> Key: IGNITE-6057
> URL: https://issues.apache.org/jira/browse/IGNITE-6057
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
>
> Currently both SQL full scan and {{CREATE INDEX}} commands iterate through 
> primary index to get all existing values. Consider that we have 10 entries 
> per data page on average. In this case we will have to read the same data 
> page 10 times when reaching relevant keys in different parts of index tree. 
> This could be very inefficient on certain workloads.
> We should iterate over data pages directly instead. This way a page with 10 
> entries will be accessed only once. However, we should take cache groups in 
> count - if there are too many entries from other logical caches, this 
> approach could make situation even worse, unless we have a mechanism to skip 
> unnecessary entries (or the whole pages!) efficiently.
> Probably we should develop a cost-based model, which will take in count the 
> following statistics:
> 1) Average entry size. The longer the entry, the lesser the benefit. 
> Especially if overflow pages are used frequently. 
> 2) Cache groups. Ideally, we should estimate number of entries from all 
> logical caches. The more entries from other caches, the lesser the benefit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6057) SQL: Full scan should be performed through data pages bypassing primary index

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6057:

Labels: iep-1 performance  (was: performance)

> SQL: Full scan should be performed through data pages bypassing primary index
> -
>
> Key: IGNITE-6057
> URL: https://issues.apache.org/jira/browse/IGNITE-6057
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
>
> Currently both SQL full scan and {{CREATE INDEX}} commands iterate through 
> primary index to get all existing values. Consider that we have 10 entries 
> per data page on average. In this case we will have to read the same data 
> page 10 times when reaching relevant keys in different parts of index tree. 
> This could be very inefficient on certain workloads.
> We should iterate over data pages directly instead. This way a page with 10 
> entries will be accessed only once. However, we should take cache groups in 
> count - if there are too many entries from other logical caches, this 
> approach could make situation even worse, unless we have a mechanism to skip 
> unnecessary entries (or the whole pages!) efficiently.
> Probably we should develop a cost-based model, which will take in count the 
> following statistics:
> 1) Average entry size. The longer the entry, the lesser the benefit. 
> Especially if overflow pages are used frequently. 
> 2) Cache groups. Ideally, we should estimate number of entries from all 
> logical caches. The more entries from other caches, the lesser the benefit.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5949) DDL: Support ALTER TABLE DROP COLUMN

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-5949:

Description: 
Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.

Design considerations:
1) Drop should only be possible on binary types without schema (see 
IGNITE-5611). Probably we will need a new option for {{CREATE TABLE}} command
2) Drop should not block other operations for a long time. We should 
synchronously block the table, change meta, then release the lock and let 
operations continue.
3) Actual data remove should be performed asynchronously in the same way we 
create index. During this time we should not allow any other modifications to 
the table
4) Be careful with node stop - we do not want to wait for years for this 
command to complete.

  was:Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} 
command.


> DDL: Support ALTER TABLE DROP COLUMN
> 
>
> Key: IGNITE-5949
> URL: https://issues.apache.org/jira/browse/IGNITE-5949
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Alexander Paschenko
> Fix For: 2.4
>
>
> Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.
> Design considerations:
> 1) Drop should only be possible on binary types without schema (see 
> IGNITE-5611). Probably we will need a new option for {{CREATE TABLE}} command
> 2) Drop should not block other operations for a long time. We should 
> synchronously block the table, change meta, then release the lock and let 
> operations continue.
> 3) Actual data remove should be performed asynchronously in the same way we 
> create index. During this time we should not allow any other modifications to 
> the table
> 4) Be careful with node stop - we do not want to wait for years for this 
> command to complete.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5949) DDL: Support ALTER TABLE DROP COLUMN

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-5949:

Description: 
Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.

Design considerations:
1) Drop should only be possible on binary types without schema (see 
IGNITE-6611). Probably we will need a new option for {{CREATE TABLE}} command
2) Drop should not block other operations for a long time. We should 
synchronously block the table, change meta, then release the lock and let 
operations continue.
3) Actual data remove should be performed asynchronously in the same way we 
create index. During this time we should not allow any other modifications to 
the table
4) Be careful with node stop - we do not want to wait for years for this 
command to complete.

  was:
Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.

Design considerations:
1) Drop should only be possible on binary types without schema (see 
IGNITE-5611). Probably we will need a new option for {{CREATE TABLE}} command
2) Drop should not block other operations for a long time. We should 
synchronously block the table, change meta, then release the lock and let 
operations continue.
3) Actual data remove should be performed asynchronously in the same way we 
create index. During this time we should not allow any other modifications to 
the table
4) Be careful with node stop - we do not want to wait for years for this 
command to complete.


> DDL: Support ALTER TABLE DROP COLUMN
> 
>
> Key: IGNITE-5949
> URL: https://issues.apache.org/jira/browse/IGNITE-5949
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Alexander Paschenko
> Fix For: 2.4
>
>
> Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.
> Design considerations:
> 1) Drop should only be possible on binary types without schema (see 
> IGNITE-6611). Probably we will need a new option for {{CREATE TABLE}} command
> 2) Drop should not block other operations for a long time. We should 
> synchronously block the table, change meta, then release the lock and let 
> operations continue.
> 3) Actual data remove should be performed asynchronously in the same way we 
> create index. During this time we should not allow any other modifications to 
> the table
> 4) Be careful with node stop - we do not want to wait for years for this 
> command to complete.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6611) Optionally disable binary metadata for type

2017-10-12 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6611:
---

 Summary: Optionally disable binary metadata for type
 Key: IGNITE-6611
 URL: https://issues.apache.org/jira/browse/IGNITE-6611
 Project: Ignite
  Issue Type: Task
  Components: binary, sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
 Fix For: 2.4


We need to introduce special metadata mode for type - without metadata. This 
way we will have a kind of "flexible" type with no restrictions. This will be 
especially useful for SQL-related types where schema changes are possible (e.g. 
ADD COLUMN -> DROP COLUMN).

Public part should be exposed to:
1) {{BinaryTypeConfiguration}}
2) {{BinaryType}} - add a flag here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5949) DDL: Support ALTER TABLE DROP COLUMN

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-5949:

Fix Version/s: 2.4

> DDL: Support ALTER TABLE DROP COLUMN
> 
>
> Key: IGNITE-5949
> URL: https://issues.apache.org/jira/browse/IGNITE-5949
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Andrew Mashenkov
> Fix For: 2.4
>
>
> Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-5949) DDL: Support ALTER TABLE DROP COLUMN

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov reassigned IGNITE-5949:
---

Assignee: Alexander Paschenko

> DDL: Support ALTER TABLE DROP COLUMN
> 
>
> Key: IGNITE-5949
> URL: https://issues.apache.org/jira/browse/IGNITE-5949
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Alexander Paschenko
> Fix For: 2.4
>
>
> Ignite should support {{DROP COLUMN}} operation for {{ALTER TABLE}} command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6135) java.sql.Date is serialized using OptimizedMarshaller

2017-10-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6135:


GitHub user NSAmelchev opened a pull request:

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

IGNITE-6135

- add new type SQL_DATE(for java.sql.Date class) into the Binary Marshaller.

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

$ git pull https://github.com/NSAmelchev/ignite ignite-6135

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

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


commit 27d01e55406df1b1f498b8c09c278c29a47ba038
Author: NSAmelchev 
Date:   2017-10-11T12:53:09Z

add test

commit ed8ec5d0a1e59f87e8dd0f7fba07bbfb117dcb47
Author: NSAmelchev 
Date:   2017-10-12T12:02:38Z

Fix




> java.sql.Date is serialized using OptimizedMarshaller
> -
>
> Key: IGNITE-6135
> URL: https://issues.apache.org/jira/browse/IGNITE-6135
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.1
>Reporter: Valentin Kulichenko
>Assignee: Amelchev Nikita
>
> For some reason, if an object has a field of {{java.sql.Date}}, it's 
> serialized with {{OptimizedMarshaller}}. It should be a first class citizen, 
> similar to {{java.util.Date}}.
> In addition, it's possible to write a field using builder like this:
> {code}
> builder.setField(name, val, java.util.Date.class)
> {code}
> where {{val}} is instance of {{java.sql.Date}}. This leads to an exception 
> during deserialization, because {{java.util.Date}} would be expected.
> More context and code reproducing the issue can be found here: 
> http://apache-ignite-users.70518.x6.nabble.com/JDBC-store-Date-deserialization-problem-td16276.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6610) Unexpected error message 'Duplicate column name' in case if query has LIMIT

2017-10-12 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6610:
---

 Summary: Unexpected error message 'Duplicate column name' in case 
if query has LIMIT 
 Key: IGNITE-6610
 URL: https://issues.apache.org/jira/browse/IGNITE-6610
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
 Fix For: 2.4


Reported by [~pkonstantinov], Try to execute the following query:
{{SELECT * FROM ( select p.id, d.id from Person p inner join Department d on 
d.id = p.depid ) LIMIT 50}}
This is valud query, but error message appears:
{{Duplicate column name "ID"; SQL statement: SELECT * FROM ( select p.id, d.id 
from Person p inner join Department d on d.id = p.depid ) LIMIT 50 [42121-195]}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6320) SQL: ANTLR performance assessment

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6320:

Fix Version/s: 2.4

> SQL: ANTLR performance assessment
> -
>
> Key: IGNITE-6320
> URL: https://issues.apache.org/jira/browse/IGNITE-6320
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Fix For: 2.4
>
>
> Proposed process:
> 1) Download MySQL grammar [1]
> 2) Generate parser
> 3) Measure parsing performance for both simple and complex SQL queries with 
> JMH.
> 4) Analyze the numbers
> [1] https://github.com/antlr/grammars-v4/tree/master/mysql



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6261) ODBC support for Mac OSX

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6261:

Fix Version/s: (was: 2.4)

> ODBC support for Mac OSX
> 
>
> Key: IGNITE-6261
> URL: https://issues.apache.org/jira/browse/IGNITE-6261
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc, sql
>Affects Versions: 2.1
> Environment: Analytics
>Reporter: Pranas Baliuka
>Assignee: Igor Sapego
>  Labels: usability
>
> In order for Ignite to be useful in analytics environment (accessing data via 
> R / Most reporting engines), the ODBC access is required.
> Analyst do use Mac OSX (not only Linux/Windows).
> The current ODBC driver is not compilable on OSX due to 1-2 different kernel 
> API functions.
> Similar incompatibility issues are already resolved in similar projects using 
> conditional macros in C language. i.e. it may not be a big challenge to make 
> it work.
> Thanks for planning and considerations!
> PS:
> For my use case the issue is a Blocker, because rJAVA is dead (requires Java 
> 6 installation on Mac OSX) and even with rJAVA , the JDBC implementation is 
> not working for R (class cast exceptions).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4490) Optimize DML for fast INSERT and MERGE

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-4490:

Fix Version/s: (was: 2.4)

> Optimize DML for fast INSERT and MERGE
> --
>
> Key: IGNITE-4490
> URL: https://issues.apache.org/jira/browse/IGNITE-4490
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>  Labels: performance
>
> It's possible to avoid any SQL querying and map some INSERT and MERGE 
> statements to cache operations in a way similar to that of UPDATE and DELETE 
> - i.e. don't make queries when there are no expressions to evaluate in the 
> query and enhance update plans to perform direct cache operations when INSERT 
> and MERGE affect columns {{_key}} and {{_val}} only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4489) Maintain correct MERGE semantic in DML

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-4489:

Fix Version/s: (was: 2.4)

> Maintain correct MERGE semantic in DML
> --
>
> Key: IGNITE-4489
> URL: https://issues.apache.org/jira/browse/IGNITE-4489
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 1.8
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>
> Currently it's impossible to MERGE object in UPDATE style - i.e. when key is 
> present in cache, unaffected field values should be retained, and instead of 
> building new object we should base it on previous one for given key.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6528) Warning if no table for BinaryObject

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6528:

Fix Version/s: (was: 2.3)

> Warning if no table for BinaryObject
> 
>
> Key: IGNITE-6528
> URL: https://issues.apache.org/jira/browse/IGNITE-6528
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary, cache, sql
>Reporter: Mikhail Cherkasov
>
> I've seen several times that due wrong cache configuration people can't find 
> data in cache and blame Ignite that it's buggy and doesn't work.
> And it's very difficult to find an error in the code, especially if you don't 
> have reach experience with Ignite.
> The problem is that we don't have strong typing when defining QueryEntriy and 
> a user can use an arbitrary string id to
> define a type, but he should use the same string id to obtain binary object 
> builder, however, people sometimes confusing this.
> So the user can define QueryEntity with value type:  
> queryEntity.setValueType("MyCoolName") and 
> later put to cache the following binary object: 
> ignite.binary.toBinary(value), but this object won't be indexed, because
> ignite.binary.toBinary uses class name as string id while indexing expects to 
> find "MyCoolName" as id.
> The example is simple and the error is obvious when you see this two lines 
> close to each other, however, in real life, cache definition and data 
> ingestion are separated by tons of code.
> We can save a lot of man-hours for our users if Ignite will print a warning 
> If a cache has a configured QE and user puts BinaryObject with typeName which 
> doesn't correspond to any QE.
> The warning should be printed only once, something like:
> [WARN] No table is found for %typeName% binary object.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6572:
-

Agree with [~dmekhanikov]. We should allow multiple caches (not tables!) to 
share the same custom schema. All we need to achieve this is to add usage 
counter to a schema and implement correct synchronization (read-write lock, I 
guess) around cache create/destroy.

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6609) H2PkHashIndex.H2Cursor doesn't take in count expiration

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6609:

Fix Version/s: (was: 2.4)

> H2PkHashIndex.H2Cursor doesn't take in count expiration
> ---
>
> Key: IGNITE-6609
> URL: https://issues.apache.org/jira/browse/IGNITE-6609
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>
> Correct: {{H2Cursor#next}} - expire time is checked;
> Incorrect: {{H2PkHashIndex.H2Cursor#next}} - expired time is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6609) H2PkHashIndex.H2Cursor doesn't take in count expiration

2017-10-12 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6609:
---

 Summary: H2PkHashIndex.H2Cursor doesn't take in count expiration
 Key: IGNITE-6609
 URL: https://issues.apache.org/jira/browse/IGNITE-6609
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
 Fix For: 2.4


Correct: {{H2Cursor#next}} - expire time is checked;
Incorrect: {{H2PkHashIndex.H2Cursor#next}} - expired time is ignored.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6594) Add missing flags to the list of the ODBC connection string attributes.

2017-10-12 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-6594:
-

[~dmagda] added more detailed description. Is it OK now?

> Add missing flags to the list of the ODBC connection string attributes.
> ---
>
> Key: IGNITE-6594
> URL: https://issues.apache.org/jira/browse/IGNITE-6594
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.2
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.3
>
>
> Need to add {{collocated}}, {{replicated_only}}, {{lazy}} and 
> {{update_on_server}} flags to the list of the ODBC connection string 
> attributes here: 
> https://apacheignite-sql.readme.io/v2.1/docs/connection-string-and-dsn



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6507) Commit can be lost in network split scenario

2017-10-12 Thread Alexandr Kuramshin (JIRA)


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

Alexandr Kuramshin commented on IGNITE-6507:


I've found that after {{GridDhtTxPrepareFuture.onNodeLeft()}} makes all its 
miniFuts done, and {{GridNearTxLocal}} prepareFut.listener calls 
{{GridNearTxFinishFuture.finish(true, true)}} (with commit) then 
{{GridDhtTxFinishRequest}} will be send.

Upon sending {{GridDhtTxFinishRequest}} a {{ClusterTopologyCheckedException}} 
will be thrown and {{GridDhtTxFinishFuture.MiniFuture.onNodeLeft()}} makes 
{{GridNearTxLocal}} successfully committed.

[~ascherbakov],

do you suppose to be transaction rolled back when 
{{GridDhtTxPrepareFuture.onNodeLeft()}} occurs?

> Commit can be lost in network split scenario
> 
>
> Key: IGNITE-6507
> URL: https://issues.apache.org/jira/browse/IGNITE-6507
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Priority: Critical
>  Labels: important
> Fix For: 2.4
>
>
> Commit can be lost in network split scenario
> Reproducer:
> https://github.com/ascherbakoff/ignite/blob/ignite-6507/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/distributed/dht/IgniteCacheTopologySplitTxConsistencyTest.java
> If routing will be switched to second data center, new transactions will no 
> see commited state.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov edited comment on IGNITE-6605 at 10/12/17 11:34 AM:


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


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

> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.
> 4) In most cases we do not need real key/value! Only partition is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6605:
-

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

> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.
> 4) In most cases we do not need real key/value! Only partition is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6608) .NET: Thin client documentation

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6608:


Added introduction to 
https://apacheignite-net.readme.io/v2.3/docs/clients-and-servers, main content 
to https://apacheignite-net.readme.io/v2.3/docs/thin-client.

> .NET: Thin client documentation
> ---
>
> Key: IGNITE-6608
> URL: https://issues.apache.org/jira/browse/IGNITE-6608
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Document new Thin Client API on readme.io: 
> https://apacheignite-net.readme.io/docs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn edited comment on IGNITE-6371 at 10/12/17 10:02 AM:
---

[~dmagda] there are no notes in the pull request, make sure you have submitted 
them.
Better yet, post them here in JIRA.

Yes, I do consider preparing the documentation: IGNITE-6607, IGNITE-6608


was (Author: ptupitsyn):
[~dmagda] there are no notes in the pull request, make sure you have submitted 
them.
Better yet, post them here in JIRA.

Yes, I do consider preparing the documentation.

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6608) .NET: Thin client documentation

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6608:
--

 Summary: .NET: Thin client documentation
 Key: IGNITE-6608
 URL: https://issues.apache.org/jira/browse/IGNITE-6608
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Document new Thin Client API on readme.io: 
https://apacheignite-net.readme.io/docs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6607) Thin client: protocol documentation

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6607:
--

 Summary: Thin client: protocol documentation
 Key: IGNITE-6607
 URL: https://issues.apache.org/jira/browse/IGNITE-6607
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Document thin client protocol on Ignite wiki: 
https://cwiki.apache.org/confluence/display/IGNITE/Design+Documents

* Common message format (length, flags)
* Data types (endianness, strings, etc)
* Request/Response format for each message type
* How to connect



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5928) .NET: Get rid of BinaryStreamBase

2017-10-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-5928:


Github user asfgit closed the pull request at:

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


> .NET: Get rid of BinaryStreamBase
> -
>
> Key: IGNITE-5928
> URL: https://issues.apache.org/jira/browse/IGNITE-5928
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> {{BinaryStreamBase}} is an abstract class with a single inheritor 
> {{BinaryHeapStream}}.
> Get rid of it for the sake of simplicity (and probably performance).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6605:

Description: 
1) Merge two anonymous implementations as they does the same things.
2) Get rid of binary search in favor of hash-based lookup.
3) Do not create a filter for {{PARTITIONED}} cache with no backups when there 
are no explicit partitions.
4) In most cases we do not need real key/value! Only partition is needed.

  was:
1) Merge two anonymous implementations as they does the same things.
2) Get rid of binary search in favor of hash-based lookup.
3) Do not create a filter for {{PARTITIONED}} cache with no backups when there 
are no explicit partitions.


> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.
> 4) In most cases we do not need real key/value! Only partition is needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5928) .NET: Get rid of BinaryStreamBase

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-5928:


Looks good to me, merged to master: 
{{b8b7c50865d37449616cc6dadeeaba84526945f4}}.

> .NET: Get rid of BinaryStreamBase
> -
>
> Key: IGNITE-5928
> URL: https://issues.apache.org/jira/browse/IGNITE-5928
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> {{BinaryStreamBase}} is an abstract class with a single inheritor 
> {{BinaryHeapStream}}.
> Get rid of it for the sake of simplicity (and probably performance).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6606) Web console agent download

2017-10-12 Thread Alexander Belyak (JIRA)

Alexander Belyak created IGNITE-6606:


 Summary: Web console agent download
 Key: IGNITE-6606
 URL: https://issues.apache.org/jira/browse/IGNITE-6606
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Affects Versions: 2.1
Reporter: Alexander Belyak
Assignee: Alexey Kuznetsov
Priority: Minor
 Fix For: 2.4


To connect web console to ignite cluster I must use web-agent, but in first 
time its not oblivious where to get it.
1) Documentation ( https://apacheignite-tools.readme.io/docs/getting-started ) 
say "Ignite Web Agent zip ships with ignite-web-agent.{sh|bat} script" It's 
wrong.
2) In web console cluster configure screen I see big red buttons "Save project" 
and "Save and download projects", but to download web-agent I must found small 
link in bottom "Download agent" (near Feedback and Apache Ignite logo, it's 
wrong place) Moreover, agent configuration contain one parameter from cluster 
configuration (IGNITE_JETTY_PORT) so download link should be cluster wide, not 
web console wide.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6572) Allow multiple caches use one SQL schema

2017-10-12 Thread Denis Mekhanikov (JIRA)


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

Denis Mekhanikov commented on IGNITE-6572:
--

[~dmagda], yes, I'm talking about {{QueryEntity}}. I had a conversation with 
[~vozerov] about it. Currently we don't have any options how to make multiple 
caches have the same schema. Implementing it in SQL syntax requires major code 
changes and it doesn't have a predictable timeline. At the same time, fixing 
behavior for {{QueryEntity}}-API doesn't require much resources. Currently if 
you create a custom schema, you can only have a single table in it. It is not 
usable at all. I think, we should give users at least some way to use custom 
schema, even though it will be deprecated.

> Allow multiple caches use one SQL schema
> 
>
> Key: IGNITE-6572
> URL: https://issues.apache.org/jira/browse/IGNITE-6572
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Denis Mekhanikov
>  Labels: usability
> Fix For: 2.4
>
>
> When trying to create more than one cache with the same SQL schema name, the 
> following exception is thrown:
> {noformat}
> Exception in thread "main" class org.apache.ignite.IgniteException: Schema 
> already registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:957)
>   at org.apache.ignite.Ignition.start(Ignition.java:350)
>   at 
> org.apache.ignite.examples.repro.schema.SchemaExampleNode.main(SchemaExampleNode.java:7)
> Caused by: class org.apache.ignite.IgniteCheckedException: Schema already 
> registered: TEST_SCHEMA
>   at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.registerCache(IgniteH2Indexing.java:2110)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.registerCache0(GridQueryProcessor.java:1393)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart0(GridQueryProcessor.java:784)
>   at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStart(GridQueryProcessor.java:845)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1185)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1884)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCachesOnLocalJoin(GridCacheProcessor.java:1755)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:619)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1901)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It should be allowed to share schema between caches. Currently it works for 
> PUBLIC schema only.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-6605:


GitHub user devozerov opened a pull request:

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

IGNITE-6605



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

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

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

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


commit c4f0895aa71db35e684de210915a7ccd41ef514c
Author: devozerov 
Date:   2017-10-12T08:11:32Z

Removed unused method.

commit 046ecb254628ee6fe2471b11f2f5da665b802b78
Author: devozerov 
Date:   2017-10-12T09:10:47Z

WIP.

commit 35999f4fffc433294057b40a925227e3882a
Author: devozerov 
Date:   2017-10-12T09:19:21Z

Fixed compilation.

commit cf16a5181c02df8c16d310a8d94310e01d458d09
Author: devozerov 
Date:   2017-10-12T09:21:17Z

Fix.




> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6605:
---

 Summary: SQL: Merge and optimize backup query filter
 Key: IGNITE-6605
 URL: https://issues.apache.org/jira/browse/IGNITE-6605
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


1) Merge two anonymous implementations as they does the same things.
2) Get rid of binary search in favor of hash-based lookup.
3) Do not create a filter for {{PARTITIONED}} cache with no backups when there 
are no explicit partitions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6605:

Component/s: sql

> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6605) SQL: Merge and optimize backup query filter

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6605:

Labels: performance  (was: )

> SQL: Merge and optimize backup query filter
> ---
>
> Key: IGNITE-6605
> URL: https://issues.apache.org/jira/browse/IGNITE-6605
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> 1) Merge two anonymous implementations as they does the same things.
> 2) Get rid of binary search in favor of hash-based lookup.
> 3) Do not create a filter for {{PARTITIONED}} cache with no backups when 
> there are no explicit partitions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-6234) [Test failure] GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode

2017-10-12 Thread Krzysztof Chmielewski (JIRA)


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

Krzysztof Chmielewski edited comment on IGNITE-6234 at 10/12/17 9:14 AM:
-

Hi,
I'm facing this issue to, but in a slightly different scenario. 

However I wonder how *schemaIds* can be null since *BinaryMetadata* constructor 
sets this field to *Collections.emptySet();* in a "worst" case.

Unless the *BinaryMetadata* is also deserialized and its parameterized 
constructor is not called. 


was (Author: kristoffsc):
Hi,
I'm facing this issue to, but in a slightly different scenario. 

However I wonder how *schemaIds* can be null since *BinaryMetadata* constructor 
sets this field to *Collections.emptySet();* in a "worst" case.

Unless the *BinaryMetadata* is also deserialized and its constructor is not 
called. 

> [Test failure] 
> GridCacheClientModesTcpClientDiscoveryAbstractTest$CaseNearReplicatedTransactional.testGetFromClientNode
> ---
>
> Key: IGNITE-6234
> URL: https://issues.apache.org/jira/browse/IGNITE-6234
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>  Labels: MakeTeamcityGreenAgain
>
> Test reproducible locally although with a very low probability. 
> I wasn't able to reproduce it starting test in isolation but managed to do it 
> starting *GridCacheClientModesTcpClientDiscoveryAbstractTest* 50 times in a 
> row observing from 1 to 3 failures.
> Test run with failed test is available 
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=798538=buildResultsDiv=Ignite20Tests_IgniteCache].
> It seems that when client requests value of custom class from near cache it 
> may see BinaryMetadata for this class with no schema.
> Test fails with the following exception:
> {noformat}
> java.lang.NullPointerException: null
> at 
> org.apache.ignite.internal.binary.BinaryMetadata.hasSchema(BinaryMetadata.java:189)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:517)
> at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:185)
> at 
> org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1237)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:284)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:183)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.reader(BinaryObjectImpl.java:830)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:794)
> at 
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:161)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:41)
> at 
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1734)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1889)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.addResult(GridCacheContext.java:1828)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.loadEntries(GridNearGetFuture.java:752)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.access$000(GridNearGetFuture.java:68)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture$MiniFuture.onResult(GridNearGetFuture.java:1012)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearGetFuture.onResult(GridNearGetFuture.java:215)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearCacheAdapter.processGetResponse(GridNearCacheAdapter.java:294)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:92)
> at 
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTransactionalCache$1.apply(GridNearTransactionalCache.java:90)
> at 
>

[jira] [Created] (IGNITE-6604) Log exchange progress

2017-10-12 Thread Alexander Belyak (JIRA)

Alexander Belyak created IGNITE-6604:


 Summary: Log exchange progress
 Key: IGNITE-6604
 URL: https://issues.apache.org/jira/browse/IGNITE-6604
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Minor


Sometimes exchange process hangs (because some errors, OOMe, deadlocks, etc), 
sometimes it require significant time to finish (finish eviction, long Full GC, 
etc).
We need some logging, that will show progress, because often exchange is block 
whole cluster and support team wanna know what's happen and how many time it 
will continue. Main point - simplify throubleshooting, just as grep standard 
message/logging class, for example: "Exchange progress: evicting partition 
" or "Exchange progress: waiting for response from  nodes".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6603) .NET: EntityFramework Core Data Provider

2017-10-12 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6603:
--

 Summary: .NET: EntityFramework Core Data Provider
 Key: IGNITE-6603
 URL: https://issues.apache.org/jira/browse/IGNITE-6603
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Create a Data Provider for Entity Framework Core, so that Ignite can be used as 
a database transparently: 
https://docs.microsoft.com/en-us/ef/core/providers/writing-a-provider



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5928) .NET: Get rid of BinaryStreamBase

2017-10-12 Thread Alexey Popov (JIRA)


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

Alexey Popov commented on IGNITE-5928:
--

Scope of changes:
1. Changes done by Reshaper refactor
2. protected renamed to private manually
3. minor issues with auto-refactor were fixed
4. Test cases passed locally, TC is in progress
[~ptupitsyn] Please review & approve the fix


> .NET: Get rid of BinaryStreamBase
> -
>
> Key: IGNITE-5928
> URL: https://issues.apache.org/jira/browse/IGNITE-5928
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> {{BinaryStreamBase}} is an abstract class with a single inheritor 
> {{BinaryHeapStream}}.
> Get rid of it for the sake of simplicity (and probably performance).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5928) .NET: Get rid of BinaryStreamBase

2017-10-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on IGNITE-5928:


GitHub user apopovgg opened a pull request:

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

IGNITE-5928 .NET: Get rid of BinaryStreamBase

Please review

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

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

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

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


commit 92bdcb407a9fc1a06964b44329608ad629aecbf2
Author: apopov 
Date:   2017-10-12T08:40:30Z

IGNITE-5928 .NET: Get rid of BinaryStreamBase




> .NET: Get rid of BinaryStreamBase
> -
>
> Key: IGNITE-5928
> URL: https://issues.apache.org/jira/browse/IGNITE-5928
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Minor
>  Labels: .NET, newbie
> Fix For: 2.4
>
>
> {{BinaryStreamBase}} is an abstract class with a single inheritor 
> {{BinaryHeapStream}}.
> Get rid of it for the sake of simplicity (and probably performance).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6371) .NET: Thin client example

2017-10-12 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6371:


[~dmagda] there are no notes in the pull request, make sure you have submitted 
them.
Better yet, post them here in JIRA.

Yes, I do consider preparing the documentation.

> .NET: Thin client example
> -
>
> Key: IGNITE-6371
> URL: https://issues.apache.org/jira/browse/IGNITE-6371
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> Create an example for thin client (requires external node started with 
> {{ignite.bat}} or {{Apache.Ignite.exe}}).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6129) SQL: implement date/time types comparison without deserialization

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6129:

Labels: performance  (was: iep-1 performance)

> SQL: implement date/time types comparison without deserialization
> -
>
> Key: IGNITE-6129
> URL: https://issues.apache.org/jira/browse/IGNITE-6129
> Project: Ignite
>  Issue Type: Task
>  Components: general, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: performance
>
> We need to implement the same optimization as was done for strings 
> (IGNITE-5918), but for date-time data types. This could improve performance 
> of both {{SELECT}} and {{CREATE INDEX}} commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Description: 
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper}}, {{H2*IO}}). 
2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
instead of {{SearchRow}}
3) Refactored classes should be moved to core module.
4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
it is really needed.
5) Two operations {{putNative}} and {{getNative}} should be added to 
{{GridH2IndexBase}}. They should accept normal key-value objects instead of H2 
rows.
6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}}) 
should be moved to {{putNative}}/{{getNative}} methods.

Note that IO classes should be reworked carefully to maintain backward 
compatibility.


  was:
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper}}, {{H2*IO}}). 
2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
instead of {{SearchRow}}
3) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
it is really needed.
4) Two operations {{putNative}} and {{getNative}} should be added to 
{{GridH2IndexBase}}. They should accept normal key-value objects instead of H2 
rows.
5) Finally, index creation routine should be moved to 
{{putNative}}/{{getNative}} methods.

Note that IO classes should be reworked carefully to maintain backward 
compatibility.



> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
> instead of {{SearchRow}}
> 3) Refactored classes should be moved to core module.
> 4) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
> it is really needed.
> 5) Two operations {{putNative}} and {{getNative}} should be added to 
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of 
> H2 rows.
> 6) Finally, all index index update routines (cache put/get, {{CREATE INDEX}}) 
> should be moved to {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward 
> compatibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Description: 
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper}}, {{H2*IO}}). 
2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
instead of {{SearchRow}}
3) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
it is really needed.
4) Two operations {{putNative}} and {{getNative}} should be added to 
{{GridH2IndexBase}}. They should accept normal key-value objects instead of H2 
rows.
5) Finally, index creation routine should be moved to 
{{putNative}}/{{getNative}} methods.

Note that IO classes should be reworked carefully to maintain backward 
compatibility.


  was:
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper}}, {{H2*IO}}). 



> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 
> 2) We should remove all H2 stuff from there, and start using {{CacheDataRow}} 
> instead of {{SearchRow}}
> 3) Conversion to {{SearchRow}} should happen inside {{H2TreeIndex}} only when 
> it is really needed.
> 4) Two operations {{putNative}} and {{getNative}} should be added to 
> {{GridH2IndexBase}}. They should accept normal key-value objects instead of 
> H2 rows.
> 5) Finally, index creation routine should be moved to 
> {{putNative}}/{{getNative}} methods.
> Note that IO classes should be reworked carefully to maintain backward 
> compatibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Description: 
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper}}, {{H2*IO}}). 


  was:
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper, {{H2*IO}}). 



> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper}}, {{H2*IO}}). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Description: 
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:
1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
({{InlineIndexHelper, {{H2*IO}}). 


  was:
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:




> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:
> 1) Actual tree is {{H2Tree}}. It is accompanied by several helper classes 
> ({{InlineIndexHelper, {{H2*IO}}). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Description: 
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 row which will be passed to index. This 
operation might require unnecessary memory copying and deserializations. We 
should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.

Here is how this could be achieved:



  was:
Currently the only way to update standard user index is through H2 
infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
we have to construct a kind of H2 rowm which will be passed to index. This 
operation might require unnecesary memory copying and deserializations. 

We should try to find a way to bypass H2 stuff altogether and add data to 
underlying {{BPlusTree}} directly.


> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 row which will be passed to index. This 
> operation might require unnecessary memory copying and deserializations. We 
> should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.
> Here is how this could be achieved:



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6409) SQL: bypass H2 during index update

2017-10-12 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6409:

Fix Version/s: 2.4

> SQL: bypass H2 during index update
> --
>
> Key: IGNITE-6409
> URL: https://issues.apache.org/jira/browse/IGNITE-6409
> Project: Ignite
>  Issue Type: Task
>  Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently the only way to update standard user index is through H2 
> infrastructure. See {{GridH2IndexBase#put}} and it's usages. For every update 
> we have to construct a kind of H2 rowm which will be passed to index. This 
> operation might require unnecesary memory copying and deserializations. 
> We should try to find a way to bypass H2 stuff altogether and add data to 
> underlying {{BPlusTree}} directly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

74 matches

Mail list logo