date:20171013

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

2017-10-13 Thread Denis Magda (JIRA)


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

Denis Magda commented on IGNITE-6608:
-

[~ptupitsyn], I would add the following:
* Examples on how to configure the thin client connection with App.config and 
Spring XML. Presently we have the source code approach only.
* Specify the scope of the supported APIs such as cache get/put operations and 
scan queries. 

> .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] [Updated] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6631:

Labels: performance  (was: )

> Optimize GridH2KeyValueRowOnheap.getValue() method
> --
>
> Key: IGNITE-6631
> URL: https://issues.apache.org/jira/browse/IGNITE-6631
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> There are some unnecessary operations around this method:
> 1) Redundant recursion
> 2) Too big value cache
> Etc.
> Need to optimize it.



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

[jira] [Commented] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method

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


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

ASF GitHub Bot commented on IGNITE-6631:


GitHub user devozerov opened a pull request:

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

IGNITE-6631



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

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

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

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


commit 1438eb74b5789d8dbf5d241be0facae0766bc561
Author: devozerov 
Date:   2017-10-13T19:53:42Z

Optos.

commit c0db1bc8a04d16789eb36903bb05d9920389d98b
Author: devozerov 
Date:   2017-10-13T20:12:34Z

Fixed.

commit be689c22c0409658ec84aba701c7b18d688c82f7
Author: devozerov 
Date:   2017-10-13T20:17:46Z

Minors.




> Optimize GridH2KeyValueRowOnheap.getValue() method
> --
>
> Key: IGNITE-6631
> URL: https://issues.apache.org/jira/browse/IGNITE-6631
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.4
>
>
> There are some unnecessary operations around this method:
> 1) Redundant recursion
> 2) Too big value cache
> Etc.
> Need to optimize it.



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

[jira] [Created] (IGNITE-6631) Optimize GridH2KeyValueRowOnheap.getValue() method

2017-10-13 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6631:
---

 Summary: Optimize GridH2KeyValueRowOnheap.getValue() method
 Key: IGNITE-6631
 URL: https://issues.apache.org/jira/browse/IGNITE-6631
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


There are some unnecessary operations around this method:
1) Redundant recursion
2) Too big value cache
Etc.

Need to optimize it.



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

[jira] [Commented] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.

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


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

ASF GitHub Bot commented on IGNITE-6630:


GitHub user xtern opened a pull request:

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

IGNITE-6630 Time units fix.



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

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

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

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


commit 73cdd7c96914b3a08551f918e2214a5fdb7a4390
Author: Pereslegin Pavel 
Date:   2017-10-13T19:01:40Z

IGNITE-6630 Time units fix.




> Incorrect time units of average transaction commit/rollback duration cache 
> metrics.
> ---
>
> Key: IGNITE-6630
> URL: https://issues.apache.org/jira/browse/IGNITE-6630
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: metrics, newbie
>
> AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics 
> calculated in milliseconds instead of microseconds as pointed in javadoc.
> Simple junit reproducer:
> {code:java}
> public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
> /** */
> private  CacheConfiguration cacheConfiguration(String name) {
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration<>(name);
> cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheConfiguration.setStatisticsEnabled(true);
> return cacheConfiguration;
> }
> /** */
> public void testTxCommitDuration() throws Exception {
> try ( Ignite node = startGrid(0)) {
> IgniteCache cache = 
> node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));
> try (Transaction tx = node.transactions().txStart()) {
> cache.put(1, 1);
> // Await 1 second.
> U.sleep(1_000);
> tx.commit();
> }
> // Documentation says that this metric is in microseconds.
> float commitTime = cache.metrics().getAverageTxCommitTime();
> // But this assertion will fail because it in milliseconds and 
> returns only ~1000.
> assert commitTime >= 1_000_000;
> }
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.

2017-10-13 Thread Pavel Pereslegin (JIRA)


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

Pavel Pereslegin updated IGNITE-6630:
-
Description: 
AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics 
calculated in milliseconds instead of microseconds as pointed in javadoc.

Simple junit reproducer:
{code:java}
public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
/** */
private  CacheConfiguration cacheConfiguration(String name) {
CacheConfiguration cacheConfiguration = new 
CacheConfiguration<>(name);
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
cacheConfiguration.setStatisticsEnabled(true);
return cacheConfiguration;
}

/** */
public void testTxCommitDuration() throws Exception {
try ( Ignite node = startGrid(0)) {
IgniteCache cache = 
node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));

try (Transaction tx = node.transactions().txStart()) {
cache.put(1, 1);

// Await 1 second.
U.sleep(1_000);

tx.commit();
}

// Documentation says that this metric is in microseconds.
float commitTime = cache.metrics().getAverageTxCommitTime();

// But this assertion will fail because it in milliseconds and 
returns only ~1000.
assert commitTime >= 1_000_000;
}
}
}
{code}


  was:
AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics 
calculated in milliseconds instead of microseconds as pointed in javadoc.

Simple junit repro:
{code:java}
public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
/** */
private  CacheConfiguration cacheConfiguration(String name) {
CacheConfiguration cacheConfiguration = new 
CacheConfiguration<>(name);
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
cacheConfiguration.setStatisticsEnabled(true);
return cacheConfiguration;
}

/** */
public void testTxCommitDuration() throws Exception {
try ( Ignite node = startGrid(0)) {
IgniteCache cache = 
node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));

try (Transaction tx = node.transactions().txStart()) {
cache.put(1, 1);

// Await 1 second.
U.sleep(1_000);

tx.commit();
}

// Documentation says that this metric is in microseconds.
float commitTime = cache.metrics().getAverageTxCommitTime();

// But this assertion will fail because it in milliseconds and 
returns only ~1000.
assert commitTime >= 1_000_000;
}
}
}
{code}



> Incorrect time units of average transaction commit/rollback duration cache 
> metrics.
> ---
>
> Key: IGNITE-6630
> URL: https://issues.apache.org/jira/browse/IGNITE-6630
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>  Labels: metrics, newbie
>
> AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics 
> calculated in milliseconds instead of microseconds as pointed in javadoc.
> Simple junit reproducer:
> {code:java}
> public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
> /** */
> private  CacheConfiguration cacheConfiguration(String name) {
> CacheConfiguration cacheConfiguration = new 
> CacheConfiguration<>(name);
> cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheConfiguration.setStatisticsEnabled(true);
> return cacheConfiguration;
> }
> /** */
> public void testTxCommitDuration() throws Exception {
> try ( Ignite node = startGrid(0)) {
> IgniteCache cache = 
> node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));
> try (Transaction tx = node.transactions().txStart()) {
> cache.put(1, 1);
> // Await 1 second.
> U.sleep(1_000);
> tx.commit();
> }
> // Documentation says that this metric is in microseconds.
> float commitTime = cache.metrics().getAverageTxCommitTime();
> // But this assertion will fail because it in milliseconds and 
> returns only ~1000.
> assert commitTime >= 1_000_000;
>

[jira] [Created] (IGNITE-6630) Incorrect time units of average transaction commit/rollback duration cache metrics.

2017-10-13 Thread Pavel Pereslegin (JIRA)

Pavel Pereslegin created IGNITE-6630:


 Summary: Incorrect time units of average transaction 
commit/rollback duration cache metrics.
 Key: IGNITE-6630
 URL: https://issues.apache.org/jira/browse/IGNITE-6630
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
Priority: Minor


AverageTxCommitTime and AverageTxRollbackTime metrics in CacheMetrics 
calculated in milliseconds instead of microseconds as pointed in javadoc.

Simple junit repro:
{code:java}
public class CacheMetricsTxAvgTimeTest extends GridCommonAbstractTest {
/** */
private  CacheConfiguration cacheConfiguration(String name) {
CacheConfiguration cacheConfiguration = new 
CacheConfiguration<>(name);
cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
cacheConfiguration.setStatisticsEnabled(true);
return cacheConfiguration;
}

/** */
public void testTxCommitDuration() throws Exception {
try ( Ignite node = startGrid(0)) {
IgniteCache cache = 
node.createCache(cacheConfiguration(DEFAULT_CACHE_NAME));

try (Transaction tx = node.transactions().txStart()) {
cache.put(1, 1);

// Await 1 second.
U.sleep(1_000);

tx.commit();
}

// Documentation says that this metric is in microseconds.
float commitTime = cache.metrics().getAverageTxCommitTime();

// But this assertion will fail because it in milliseconds and 
returns only ~1000.
assert commitTime >= 1_000_000;
}
}
}
{code}




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

[jira] [Created] (IGNITE-6629) Make service persistence and automatic redeployment configurable in ServiceConfiguration

2017-10-13 Thread Ivan Rakov (JIRA)

Ivan Rakov created IGNITE-6629:
--

 Summary: Make service persistence and automatic redeployment 
configurable in ServiceConfiguration
 Key: IGNITE-6629
 URL: https://issues.apache.org/jira/browse/IGNITE-6629
 Project: Ignite
  Issue Type: Improvement
  Components: managed services
Affects Versions: 2.3
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk
 Fix For: 2.4


Before 2.3, if persistence was enabled globally, services were recovered along 
with system cache. But in 2.3, persistence can be enabled for per data region 
(IGNITE-6030), and system data region is not persistent.
We should add feaure to configure service redeployment after restart. 
Service-related information should be stored in Metastore instead of system 
cache.

IgniteChangeGlobalStateServiceTest#testDeployService should be fixed under this 
ticket.



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

[jira] [Updated] (IGNITE-6629) Make service automatic redeployment configurable in ServiceConfiguration

2017-10-13 Thread Ivan Rakov (JIRA)


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

Ivan Rakov updated IGNITE-6629:
---
Summary: Make service automatic redeployment configurable in 
ServiceConfiguration  (was: Make service persistence and automatic redeployment 
configurable in ServiceConfiguration)

> Make service automatic redeployment configurable in ServiceConfiguration
> 
>
> Key: IGNITE-6629
> URL: https://issues.apache.org/jira/browse/IGNITE-6629
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Affects Versions: 2.3
>Reporter: Ivan Rakov
>Assignee: Alexey Goncharuk
> Fix For: 2.4
>
>
> Before 2.3, if persistence was enabled globally, services were recovered 
> along with system cache. But in 2.3, persistence can be enabled for per data 
> region (IGNITE-6030), and system data region is not persistent.
> We should add feaure to configure service redeployment after restart. 
> Service-related information should be stored in Metastore instead of system 
> cache.
> IgniteChangeGlobalStateServiceTest#testDeployService should be fixed under 
> this ticket.



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

[jira] [Updated] (IGNITE-6628) Make possible to rebuild all SQL indexes programmatically with enabled persistence.

2017-10-13 Thread Alexei Scherbakov (JIRA)


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

Alexei Scherbakov updated IGNITE-6628:
--
Description: 
We have unofficial way for rebuilding indexes, which is called on activation if 
index.bin is removed from PDS directory.

Code is located here [1]

I think it's ok to make it public for several cases: model is changed, index is 
damaged, etc...

Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap 
and leading to OOM.

[1] 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange
[2] 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash

  was:
We have unofficial way for rebuilding indexes, which is called on activation if 
index.bin is removed from PDS directory.

Code is located here [1]

I think it's ok to make it public for several cases: model is changed, index is 
damage, etc...

Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap 
and leading to OOM.

[1] 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange
[2] 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash


> Make possible to rebuild all SQL indexes programmatically with enabled 
> persistence.
> ---
>
> Key: IGNITE-6628
> URL: https://issues.apache.org/jira/browse/IGNITE-6628
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.4
>
>
> We have unofficial way for rebuilding indexes, which is called on activation 
> if index.bin is removed from PDS directory.
> Code is located here [1]
> I think it's ok to make it public for several cases: model is changed, index 
> is damaged, etc...
> Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap 
> and leading to OOM.
> [1] 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange
> [2] 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash



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

[jira] [Created] (IGNITE-6628) Make possible to rebuild all SQL indexes programmatically with enabled persistence.

2017-10-13 Thread Alexei Scherbakov (JIRA)

Alexei Scherbakov created IGNITE-6628:
-

 Summary: Make possible to rebuild all SQL indexes programmatically 
with enabled persistence.
 Key: IGNITE-6628
 URL: https://issues.apache.org/jira/browse/IGNITE-6628
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.4


We have unofficial way for rebuilding indexes, which is called on activation if 
index.bin is removed from PDS directory.

Code is located here [1]

I think it's ok to make it public for several cases: model is changed, index is 
damage, etc...

Also current impl has a bug: CacheEntry in [2] is not touched, polluting heap 
and leading to OOM.

[1] 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager#beforeExchange
[2] 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#rebuildIndexesFromHash



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

[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum

2017-10-13 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-6627:
-
Description: 
There is an deserialization issue with complex structure.

Please see the sample code below:
{noformat}
public enum SampleEnum : byte
{
One = 0,
Two = 1,
Three = 2
}
{noformat}
{noformat}
var cache = ignite.GetOrCreateCache>>("mySampleCache");
cache.Put("DictData", Dict);
var result = cache.Get("DictData");
{noformat}

var result = cache.Get("DictData"); fails with exception:
{"The constructor to deserialize an object of type 
'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' 
was not found."}

If we change 
Dictionary>
to 
Dictionary>
then everything works fine

  was:
There is an deserialization issue with complex structure.

Please see the sample code below:
{noformat}
public enum SampleEnum : byte
{
One = 0,
Two = 1,
Three = 2
}
{noformat}
{noformat}
var cache = ignite.GetOrCreateCache>>("mySampleCache");
cache.Put("DictData", Dict);
var result = cache.Get("DictData");
{noformat}

{{cache.Get("DictData"); }} fails with eception:
{"The constructor to deserialize an object of type 
'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' 
was not found."}

if we change 
Dictionary>
to 
Dictionary>
then everything is ok


> .NET: cache deserialization fail with complex value type & enum
> ---
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>  Labels: .NET
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Assigned] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-13 Thread Alexey Popov (JIRA)


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

Alexey Popov reassigned IGNITE-6627:


Assignee: Alexey Popov

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>  Labels: .NET
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum

2017-10-13 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-6627:
-
Labels: .NET  (was: )

> .NET: cache deserialization fail with complex value type & enum
> ---
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>  Labels: .NET
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Updated] (IGNITE-6627) .NET: cache deserialization fails with complex value type & enum

2017-10-13 Thread Alexey Popov (JIRA)


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

Alexey Popov updated IGNITE-6627:
-
Summary: .NET: cache deserialization fails with complex value type & enum  
(was: .NET: cache deserialization fail with complex value type & enum)

> .NET: cache deserialization fails with complex value type & enum
> 
>
> Key: IGNITE-6627
> URL: https://issues.apache.org/jira/browse/IGNITE-6627
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.2
>Reporter: Alexey Popov
>  Labels: .NET
>
> There is an deserialization issue with complex structure.
> Please see the sample code below:
> {noformat}
> public enum SampleEnum : byte
> {
> One = 0,
> Two = 1,
> Three = 2
> }
> {noformat}
> {noformat}
> var cache = ignite.GetOrCreateCache Dictionary>>("mySampleCache");
> cache.Put("DictData", Dict);
> var result = cache.Get("DictData");
> {noformat}
> var result = cache.Get("DictData"); fails with exception:
> {"The constructor to deserialize an object of type 
> 'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]'
>  was not found."}
> If we change 
> Dictionary>
> to 
> Dictionary>
> then everything works fine



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

[jira] [Created] (IGNITE-6627) .NET: cache deserialization fail with complex value type & enum

2017-10-13 Thread Alexey Popov (JIRA)

Alexey Popov created IGNITE-6627:


 Summary: .NET: cache deserialization fail with complex value type 
& enum
 Key: IGNITE-6627
 URL: https://issues.apache.org/jira/browse/IGNITE-6627
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.2
Reporter: Alexey Popov


There is an deserialization issue with complex structure.

Please see the sample code below:
{noformat}
public enum SampleEnum : byte
{
One = 0,
Two = 1,
Three = 2
}
{noformat}
{noformat}
var cache = ignite.GetOrCreateCache>>("mySampleCache");
cache.Put("DictData", Dict);
var result = cache.Get("DictData");
{noformat}

{{cache.Get("DictData"); }} fails with eception:
{"The constructor to deserialize an object of type 
'System.Collections.Generic.ObjectEqualityComparer`1[SampleProject.SampleEnum]' 
was not found."}

if we change 
Dictionary>
to 
Dictionary>
then everything is ok



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

[jira] [Commented] (IGNITE-5608) SQL scripts execution capability

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-5608:
-

[~oleg-ostanin], my comments:
1) Let's utilize the same approach as in {{ignite.bat|sh}} - perform validation 
and startup in a single Java class. This way we will avoid duplication.
2) We should exit the program in case of connection failure. This is not the 
case now - I remain in sqlline terminal. Please consult to sqlline scripts to 
understand how they (vendor) achieve this.

> SQL scripts execution capability
> 
>
> Key: IGNITE-5608
> URL: https://issues.apache.org/jira/browse/IGNITE-5608
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> There should be a way to feed an SQL script to Ignite and execute it right 
> away. A script can consist of DDL command that will define cluster and SQL 
> configuration as well as of DML commands that, for instance, preload data 
> into Ignite.



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

[jira] [Updated] (IGNITE-5224) .NET: PadLeft and PadRight support in LINQ

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

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

> .NET: PadLeft and PadRight support in LINQ
> --
>
> Key: IGNITE-5224
> URL: https://issues.apache.org/jira/browse/IGNITE-5224
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexey Popov
>Priority: Trivial
>  Labels: .NET, LINQ, newbie
> Fix For: 2.3
>
>
> Add {{String.PadLeft}} and {{String.PadRight}} functions to LINQ, map them to 
> SQL {{LPAD}} and {{RPAD}}. See {{MethodVisitor.cs}}.



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

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

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

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

> .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
> Fix For: 2.3
>
>
> {{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] [Updated] (IGNITE-6338) .NET: Thin client: LINQ

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-6338:
---
Labels: .NET linq  (was: .NET)

> .NET: Thin client: LINQ
> ---
>
> Key: IGNITE-6338
> URL: https://issues.apache.org/jira/browse/IGNITE-6338
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>  Labels: .NET, linq
>
> Make sure LINQ works via thin client. This requires implementing 
> {{ICacheInternal}}.



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

[jira] [Assigned] (IGNITE-6336) .NET: Thin client: Create cache

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn reassigned IGNITE-6336:
--

Assignee: Pavel Tupitsyn

> .NET: Thin client: Create cache
> ---
>
> Key: IGNITE-6336
> URL: https://issues.apache.org/jira/browse/IGNITE-6336
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
>
> Create caches from thin client (by name and from {{CacheConfiguration}}).
> Implement {{ICache.GetConfiguration}}.



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

[jira] [Resolved] (IGNITE-6621) .NET: Disable thin client for 2.3 release

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn resolved IGNITE-6621.

Resolution: Fixed

> .NET: Disable thin client for 2.3 release
> -
>
> Key: IGNITE-6621
> URL: https://issues.apache.org/jira/browse/IGNITE-6621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> 2.3 is coming out soon, and thin client feature is far from being 
> release-ready (small part of cache APIs is all we have), let's disable it in 
> {{ignite-2.3}} branch to avoid confusing users.



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

[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6621:


Merged to {{ignite-2.3}}: {{6df7ebc430cf5a099474361b61b2593a5884992b}}.

> .NET: Disable thin client for 2.3 release
> -
>
> Key: IGNITE-6621
> URL: https://issues.apache.org/jira/browse/IGNITE-6621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> 2.3 is coming out soon, and thin client feature is far from being 
> release-ready (small part of cache APIs is all we have), let's disable it in 
> {{ignite-2.3}} branch to avoid confusing users.



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

[jira] [Commented] (IGNITE-6581) clent deadlock in spiStart

2017-10-13 Thread Semen Boikov (JIRA)


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

Semen Boikov commented on IGNITE-6581:
--

[~kdudkov], I think this issue should be fixed in this way: when client detects 
that it is disconnected but client join was never finished (joinLatch is not 
released), then there is no need to call notifyDiscovery.

Thanks

> clent deadlock in spiStart
> --
>
> Key: IGNITE-6581
> URL: https://issues.apache.org/jira/browse/IGNITE-6581
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Konstantin Dudkov
>Assignee: Konstantin Dudkov
>
> {code:java}
> "tcp-client-disco-msg-worker-#4%soloots-tg-ManagementFabric%" #50 prio=5 
> os_prio=0 tid=0x7fafecd50800 nid=0x469e sleeping[0x7fafc3bfa000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at 
> org.apache.ignite.internal.util.GridSpinReadWriteLock.tryWriteLock(GridSpinReadWriteLock.java:349)
> at 
> org.apache.ignite.internal.GridKernalGatewayImpl.writeLock(GridKernalGatewayImpl.java:121)
> at 
> org.apache.ignite.internal.IgniteKernal.onDisconnected(IgniteKernal.java:3427)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:601)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2400)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.notifyDiscovery(ClientImpl.java:2379)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1707)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> "main" #1 prio=5 os_prio=0 tid=0x7fafec01 nid=0x4644 waiting on 
> condition [0x7faff325]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x00068a331ad0> (a 
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at 
> org.apache.ignite.spi.discovery.tcp.ClientImpl.spiStart(ClientImpl.java:265)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:1862)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:268)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:690)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1682)
> at 
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:940)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1814)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1605)
> - locked <0x0004107210e8> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:569)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:516)
> at org.apache.ignite.Ignition.start(Ignition.java:322)
> at 
> com.workday.fabric.ignite.IgniteFabric.lambda$start$1(IgniteFabric.java:143)
> at 
> com.workday.fabric.ignite.IgniteFabric$$Lambda$6/576020159.run(Unknown Source)
> at 
> com.workday.fabric.util.InvocationInterceptor.invokeRunnable(InvocationInterceptor.java:119)
> at com.workday.fabric.ignite.IgniteFabric.start(IgniteFabric.java:138)
> - locked <0x0004107212e0> (a 
> com.workday.fabric.ignite.IgniteWorkdayFabric)
> at 
> com.workday.fabric.FabricManager.ensureFabric(FabricManager.java:146)
> - locked <0x000410721368> (a 
> java.util.concurrent.ConcurrentHashMap)
> at 
> com.workday.fabric.WorkdayFabricManager.ensureFabric(WorkdayFabricManager.java:76)
> at 
> com.workday.fabric.verifier.FabricVerifier.verify(FabricVerifier.java:347)
> at 
> com.workday.fabric.verifier.FabricVerifier.main(FabricVerifier.java:276)
> {code}



--
This message was sent by Atlassian JIRA

[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release

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


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

ASF GitHub Bot commented on IGNITE-6621:


Github user ptupitsyn closed the pull request at:

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


> .NET: Disable thin client for 2.3 release
> -
>
> Key: IGNITE-6621
> URL: https://issues.apache.org/jira/browse/IGNITE-6621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> 2.3 is coming out soon, and thin client feature is far from being 
> release-ready (small part of cache APIs is all we have), let's disable it in 
> {{ignite-2.3}} branch to avoid confusing users.



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

[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions

2017-10-13 Thread Anton Vinogradov (JIRA)


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

Anton Vinogradov commented on IGNITE-4172:
--

[~asfedotov]
Looks good to me.

> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
>  Labels: usability
> Fix For: 2.4
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine. 
> Next query can fails with error, if one of row localDateTimeField value has 
> zero-time: 
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method. 
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.



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

[jira] [Updated] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6624:

Labels: performance  (was: )

> SQL: IndexingQueryCacheFilter should use immediate partition data if possible
> -
>
> Key: IGNITE-6624
> URL: https://issues.apache.org/jira/browse/IGNITE-6624
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement working with partitions rather than keys when 
> possible,



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

[jira] [Updated] (IGNITE-6626) SQL: Doesn't materialize rows when possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6626:

Description: 
We need to filter backup keys during query execution. Currently to achieve this 
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function

What it might look like:
1) Get row link
2) Get partition from link

This ticket is to implement row filtering on B+Tree level and avoid their 
materialization.

> SQL: Doesn't materialize rows when possible
> ---
>
> Key: IGNITE-6626
> URL: https://issues.apache.org/jira/browse/IGNITE-6626
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement row filtering on B+Tree level and avoid their 
> materialization.



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

[jira] [Commented] (IGNITE-6626) SQL: Doesn't materialize rows when possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6626:
-

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

> SQL: Doesn't materialize rows when possible
> ---
>
> Key: IGNITE-6626
> URL: https://issues.apache.org/jira/browse/IGNITE-6626
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement row filtering on B+Tree level and avoid their 
> materialization.



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

[jira] [Commented] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6624:
-

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

> SQL: IndexingQueryCacheFilter should use immediate partition data if possible
> -
>
> Key: IGNITE-6624
> URL: https://issues.apache.org/jira/browse/IGNITE-6624
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement working with partitions rather than keys when 
> possible,



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

[jira] [Created] (IGNITE-6626) SQL: Doesn't materialize rows when possible

2017-10-13 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6626:
---

 Summary: SQL: Doesn't materialize rows when possible
 Key: IGNITE-6626
 URL: https://issues.apache.org/jira/browse/IGNITE-6626
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4






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

[jira] [Commented] (IGNITE-6626) SQL: Doesn't materialize rows when possible

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


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

ASF GitHub Bot commented on IGNITE-6626:


GitHub user devozerov opened a pull request:

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

IGNITE-6626



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

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

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

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


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.

commit 5846dffcb585c8aa010fc278dcec36ba90521d17
Author: devozerov 
Date:   2017-10-12T11:02:38Z

WIP.

commit bbeebee9572e86340fdc4228c4a27eb65418e7c8
Author: devozerov 
Date:   2017-10-12T11:21:20Z

Fixed.

commit 9ab5729303ac5221cef25028bd2761802ead52a3
Author: devozerov 
Date:   2017-10-12T11:26:48Z

Fixed.

commit de8a6645287f09292be59744515958bc0fcdfeec
Author: devozerov 
Date:   2017-10-12T11:29:36Z

Finalization.

commit 37b9b68c40f3b8320f08c384a1657be2db4b8c29
Author: devozerov 
Date:   2017-10-12T11:33:10Z

Do not create row.

commit 60115cafe10b5bf9cad45b6e6e5337eb65cfb5ef
Author: devozerov 
Date:   2017-10-12T13:26:06Z

Merge branch 'master' into ignite-6605

commit 20a74cfd099cf54149f2abdd99ef9d3058236edd
Author: devozerov 
Date:   2017-10-12T13:30:43Z

Finalization.

commit 71b235cad60a994294762f866987ee3862e00a45
Author: devozerov 
Date:   2017-10-12T13:35:02Z

COMPATIBILITY: rename current class.

commit e55e4a6e22c558fc5f47027afa93db8f1c18c487
Author: devozerov 
Date:   2017-10-12T13:36:15Z

Returned old class.

commit da60e04a78c9261059b3810a7454bc882a563569
Author: devozerov 
Date:   2017-10-12T13:40:35Z

Revert "Returned old class."

This reverts commit e55e4a6e22c558fc5f47027afa93db8f1c18c487.

commit 6689035ea3b1808918a36a189720c53d130c380f
Author: devozerov 
Date:   2017-10-12T13:40:45Z

Revert "COMPATIBILITY: rename current class."

This reverts commit 71b235cad60a994294762f866987ee3862e00a45.

commit 50a7cc58b87c27db8bfe327851ce8e29a94de45a
Author: devozerov 
Date:   2017-10-13T08:05:23Z

Merge branch 'master' into ignite-6605

commit 3f787a8e34564964a8014f2fe3af59e4115c0341
Author: devozerov 
Date:   2017-10-13T09:27:08Z

WIP.

commit ac756bd4c798f509872be34c328f962ef968e6ed
Author: devozerov 
Date:   2017-10-13T11:21:09Z

Merge branch 'master' into ignite-6605-debug

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/spi/indexing/IndexingQueryCacheFilter.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2PkHashIndex.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java

commit feec224213e2d13331b6dcae0ed16f735fcb7c7e
Author: devozerov 
Date:   2017-10-13T12:15:03Z

Implemented.

commit 3fc237cfb5c44ca81ada69ad38643edf9bb31f95
Author: devozerov 
Date:   2017-10-13T12:17:36Z

Cosmetics.

commit fd1e90b08d5f9804c2e6160a63c3b09298d5e37c
Author: devozerov 
Date:   2017-10-13T12:18:21Z

Done.

commit 836523dc77b14c43e7a56e5956daf6c85004d34f
Author: devozerov 
Date:   2017-10-13T12:21:01Z

Merge branch 'ignite-6624' into ignite-6626

# Conflicts:
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java




> SQL: Doesn't materialize rows when possible
> ---
>
> Key: IGNITE-6626
> URL: https://issues.apache.org/jira/browse/IGNITE-6626
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter:

[jira] [Commented] (IGNITE-6621) .NET: Disable thin client for 2.3 release

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


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

ASF GitHub Bot commented on IGNITE-6621:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-6621 .NET: Disable thin client



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

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

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

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


commit 6859178606d3ad4381b1a337473c360956296a20
Author: Pavel Tupitsyn 
Date:   2017-10-13T12:15:03Z

IGNITE-6621 .NET: Disable thin client




> .NET: Disable thin client for 2.3 release
> -
>
> Key: IGNITE-6621
> URL: https://issues.apache.org/jira/browse/IGNITE-6621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> 2.3 is coming out soon, and thin client feature is far from being 
> release-ready (small part of cache APIs is all we have), let's disable it in 
> {{ignite-2.3}} branch to avoid confusing users.



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

[jira] [Updated] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov updated IGNITE-6624:

Description: 
We need to filter backup keys during query execution. Currently to achieve this 
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function

What it might look like:
1) Get row link
2) Get partition from link

This ticket is to implement working with partitions rather than keys when 
possible,

  was:
We need to filter backup keys during query execution. Currently to achieve this 
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function

What it might look like:
1) Get row link
2) Get partition from link

p.1 is very simple to implement. p.2 might be harded and probably should be 
implemented out of scope of this ticket.


> SQL: IndexingQueryCacheFilter should use immediate partition data if possible
> -
>
> Key: IGNITE-6624
> URL: https://issues.apache.org/jira/browse/IGNITE-6624
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is to implement working with partitions rather than keys when 
> possible,



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

[jira] [Commented] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible

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


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

ASF GitHub Bot commented on IGNITE-6624:


GitHub user devozerov opened a pull request:

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

IGNITE-6624



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

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

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

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


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.

commit 5846dffcb585c8aa010fc278dcec36ba90521d17
Author: devozerov 
Date:   2017-10-12T11:02:38Z

WIP.

commit bbeebee9572e86340fdc4228c4a27eb65418e7c8
Author: devozerov 
Date:   2017-10-12T11:21:20Z

Fixed.

commit 9ab5729303ac5221cef25028bd2761802ead52a3
Author: devozerov 
Date:   2017-10-12T11:26:48Z

Fixed.

commit de8a6645287f09292be59744515958bc0fcdfeec
Author: devozerov 
Date:   2017-10-12T11:29:36Z

Finalization.

commit 37b9b68c40f3b8320f08c384a1657be2db4b8c29
Author: devozerov 
Date:   2017-10-12T11:33:10Z

Do not create row.

commit 60115cafe10b5bf9cad45b6e6e5337eb65cfb5ef
Author: devozerov 
Date:   2017-10-12T13:26:06Z

Merge branch 'master' into ignite-6605

commit 20a74cfd099cf54149f2abdd99ef9d3058236edd
Author: devozerov 
Date:   2017-10-12T13:30:43Z

Finalization.

commit 71b235cad60a994294762f866987ee3862e00a45
Author: devozerov 
Date:   2017-10-12T13:35:02Z

COMPATIBILITY: rename current class.

commit e55e4a6e22c558fc5f47027afa93db8f1c18c487
Author: devozerov 
Date:   2017-10-12T13:36:15Z

Returned old class.

commit da60e04a78c9261059b3810a7454bc882a563569
Author: devozerov 
Date:   2017-10-12T13:40:35Z

Revert "Returned old class."

This reverts commit e55e4a6e22c558fc5f47027afa93db8f1c18c487.

commit 6689035ea3b1808918a36a189720c53d130c380f
Author: devozerov 
Date:   2017-10-12T13:40:45Z

Revert "COMPATIBILITY: rename current class."

This reverts commit 71b235cad60a994294762f866987ee3862e00a45.

commit 50a7cc58b87c27db8bfe327851ce8e29a94de45a
Author: devozerov 
Date:   2017-10-13T08:05:23Z

Merge branch 'master' into ignite-6605

commit 3f787a8e34564964a8014f2fe3af59e4115c0341
Author: devozerov 
Date:   2017-10-13T09:27:08Z

WIP.

commit ac756bd4c798f509872be34c328f962ef968e6ed
Author: devozerov 
Date:   2017-10-13T11:21:09Z

Merge branch 'master' into ignite-6605-debug

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/spi/indexing/IndexingQueryCacheFilter.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/H2Cursor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2PkHashIndex.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GridH2IndexBase.java

commit 3fc237cfb5c44ca81ada69ad38643edf9bb31f95
Author: devozerov 
Date:   2017-10-13T12:17:36Z

Cosmetics.




> SQL: IndexingQueryCacheFilter should use immediate partition data if possible
> -
>
> Key: IGNITE-6624
> URL: https://issues.apache.org/jira/browse/IGNITE-6624
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>  Labels: performance
> Fix For: 2.4
>
>
> We need to filter backup keys during query execution. Currently to achieve 
> this we do the following:
> 1) Get row link
> 2) Materialize the row (!!!)
> 3) Create H2 row (H2 wrapping)
> 4) Then get key from H2 row (unwrapping)
> 5) Calculate partition through affinity function
> What it might look like:
> 1) Get row link
> 2) Get partition from link
> This ticket is

[jira] [Created] (IGNITE-6625) JDBC thin: support SSL connection to Ignite node

2017-10-13 Thread Taras Ledkov (JIRA)

Taras Ledkov created IGNITE-6625:


 Summary: JDBC thin: support SSL connection to Ignite node
 Key: IGNITE-6625
 URL: https://issues.apache.org/jira/browse/IGNITE-6625
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Affects Versions: 2.2
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.3


SSL connection must be supported for JDBC thin driver.



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

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

2017-10-13 Thread Alexandr Fedotov (JIRA)


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

Alexandr Fedotov reassigned IGNITE-3164:


Assignee: (was: Alexandr Fedotov)

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



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

[jira] [Commented] (IGNITE-4172) SQL: Add support for Java 8 Time API classes in date\time functions

2017-10-13 Thread Alexandr Fedotov (JIRA)


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

Alexandr Fedotov commented on IGNITE-4172:
--

[~avinogradov], PR updated. Please verify.

> SQL: Add support for Java 8 Time API classes in date\time functions
> ---
>
> Key: IGNITE-4172
> URL: https://issues.apache.org/jira/browse/IGNITE-4172
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Andrew Mashenkov
>Assignee: Alexandr Fedotov
>  Labels: usability
> Fix For: 2.4
>
>
> We have is issue with querying LocalDateTime objects with our SQL engine. 
> Next query can fails with error, if one of row localDateTimeField value has 
> zero-time: 
> select DATEDIFF('DAY', localDateTimeField, CURRENT_DATE ()) from t;
> Startpoint is IgniteH2Indexing.wrap() method. 
> We need add support to these classes: LocalDate, LocalTime, LocalDateTime.



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

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

2017-10-13 Thread Andrey Gura (JIRA)


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

Andrey Gura commented on IGNITE-6005:
-

I think better way is using special code flow for operations with 
non-interruptible semantic.

> [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] [Commented] (IGNITE-4723) .NET: Support REGEXP_LIKE in LINQ

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


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

ASF GitHub Bot commented on IGNITE-4723:


Github user asfgit closed the pull request at:

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


> .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
> Fix For: 2.4
>
>
> {{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] [Created] (IGNITE-6624) SQL: IndexingQueryCacheFilter should use immediate partition data if possible

2017-10-13 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6624:
---

 Summary: SQL: IndexingQueryCacheFilter should use immediate 
partition data if possible
 Key: IGNITE-6624
 URL: https://issues.apache.org/jira/browse/IGNITE-6624
 Project: Ignite
  Issue Type: Task
  Components: cache, sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


We need to filter backup keys during query execution. Currently to achieve this 
we do the following:
1) Get row link
2) Materialize the row (!!!)
3) Create H2 row (H2 wrapping)
4) Then get key from H2 row (unwrapping)
5) Calculate partition through affinity function

What it might look like:
1) Get row link
2) Get partition from link

p.1 is very simple to implement. p.2 might be harded and probably should be 
implemented out of scope of this ticket.



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

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

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-4723:


Looks good to me, merged to master: 
{{5e1a22db1c1da0e5d866fd5a465dd3cdc7b3ffa0}}.

> .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
> Fix For: 2.4
>
>
> {{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-6605) SQL: Merge and optimize backup query filter

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


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

ASF GitHub Bot commented on IGNITE-6605:


Github user devozerov closed the pull request at:

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


> 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-5357) Replicated cache reads load balancing.

2017-10-13 Thread Mikhail Lipkovich (JIRA)


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

Mikhail Lipkovich commented on IGNITE-5357:
---

[~vozerov], [~ascherbakov] thanks both of you!
Sorry for late response - I was on a vacation. So probably the question about 
version is not relevant anymore and it can be changed to 2.4

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



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

[jira] [Updated] (IGNITE-4887) Support transaction continuation in another thread

2017-10-13 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov updated IGNITE-4887:
-
Description: 
Consider the following pseudo-code:
{code:xml}
IgniteTransactions transactions = ignite1.transactions();
Transaction tx = startTransaction(transactions);
cache.put("key1", 1);
tx.stop();
{code}
And in another thread:
{code:xml}
transactions.txStart(tx);
cache.put("key3", 3);
cache.remove("key2");
tx.commit();
{code}
The Api should be implemented , that let you continue transaction in another 
thread.
method suspend() should mark the transaction as unavailable for further commit.
method resume should resume the transaction. 

reason behind the proposal :
Consider the next scenario:
we begin transaction, doing some changes and start async future that will be 
able to introduce futher changes into transaction and commit it in the end.



  was:
Consider the following pseudo-code:
{code:xml}
IgniteTransactions transactions = ignite1.transactions();
Transaction tx = startTransaction(transactions);
cache.put("key1", 1);
tx.stop();
{code}
And in another thread:
{code:xml}
transactions.txStart(tx);
cache.put("key3", 3);
cache.remove("key2");
tx.commit();
{code}
The Api should be implemented , that let you continue transaction in another 
thread.
method stop() should mark the transaction as unavailable for further commit.
method txStart() should resume the transaction. 

reason behind the proposal :
Consider the next scenario:
we begin transaction, doing some changes and start async future that will be 
able to introduce futher changes into transaction and commit it in the end.




> Support transaction continuation in another thread
> --
>
> Key: IGNITE-4887
> URL: https://issues.apache.org/jira/browse/IGNITE-4887
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.9
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Attachments: HangTest.txt
>
>
> Consider the following pseudo-code:
> {code:xml}
> IgniteTransactions transactions = ignite1.transactions();
> Transaction tx = startTransaction(transactions);
> cache.put("key1", 1);
> tx.stop();
> {code}
> And in another thread:
> {code:xml}
> transactions.txStart(tx);
> cache.put("key3", 3);
> cache.remove("key2");
> tx.commit();
> {code}
> The Api should be implemented , that let you continue transaction in another 
> thread.
> method suspend() should mark the transaction as unavailable for further 
> commit.
> method resume should resume the transaction. 
> reason behind the proposal :
> Consider the next scenario:
> we begin transaction, doing some changes and start async future that will be 
> able to introduce futher changes into transaction and commit it in the end.



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

[jira] [Created] (IGNITE-6623) Web console: export query result set doesn't work on Edge

2017-10-13 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-6623:
--

 Summary: Web console: export query result set doesn't work on Edge
 Key: IGNITE-6623
 URL: https://issues.apache.org/jira/browse/IGNITE-6623
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov


Execute any query and try to Export\ExportAll in result table



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

[jira] [Commented] (IGNITE-6519) Race in SplitAwareTopologyValidator on activator and server node join

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


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

ASF GitHub Bot commented on IGNITE-6519:


GitHub user akuramshingg opened a pull request:

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

IGNITE-6519 Race in SplitAwareTopologyValidator on activator and server 
node join

TestRecordingCommunicationSpi fix
references IGNITE-6507 Commit can be lost in network split scenario

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

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

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

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


commit 25fefabd3a61df7de2bac48a49fe384107d02aa4
Author: Alexandr Kuramshin 
Date:   2017-10-13T10:27:12Z

IGNITE-6519 Race in SplitAwareTopologyValidator on activator and server 
node join
TestRecordingCommunicationSpi fix




> Race in SplitAwareTopologyValidator on activator and server node join
> -
>
> Key: IGNITE-6519
> URL: https://issues.apache.org/jira/browse/IGNITE-6519
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>
> The following sequence may occur:
> 1. {{SplitAwareTopologyValidator}} detects split, gets {{NOTVALID}} and 
> returns false from {{validate()}}
> 2. Activator node joins and {{SplitAwareTopologyValidator}} gets {{REPAIRED}}
> 3. Server node joins from other DC and it makes 
> {{SplitAwareTopologyValidator}} gets {{VALID}}
> 4. Then the server node left the cluster and {{SplitAwareTopologyValidator}} 
> should return false from {{validate()}} in cause of next split
> But current implementation makes {{SplitAwareTopologyValidator}} 
> auto-{{REPAIRED}}. Actually if the activator node will being forgotten to 
> leave the cluster it may automatically repair a split many times. But it 
> supposed to be manual operation.



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

[jira] [Commented] (IGNITE-6519) Race in SplitAwareTopologyValidator on activator and server node join

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


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

ASF GitHub Bot commented on IGNITE-6519:


Github user akuramshingg closed the pull request at:

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


> Race in SplitAwareTopologyValidator on activator and server node join
> -
>
> Key: IGNITE-6519
> URL: https://issues.apache.org/jira/browse/IGNITE-6519
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
>
> The following sequence may occur:
> 1. {{SplitAwareTopologyValidator}} detects split, gets {{NOTVALID}} and 
> returns false from {{validate()}}
> 2. Activator node joins and {{SplitAwareTopologyValidator}} gets {{REPAIRED}}
> 3. Server node joins from other DC and it makes 
> {{SplitAwareTopologyValidator}} gets {{VALID}}
> 4. Then the server node left the cluster and {{SplitAwareTopologyValidator}} 
> should return false from {{validate()}} in cause of next split
> But current implementation makes {{SplitAwareTopologyValidator}} 
> auto-{{REPAIRED}}. Actually if the activator node will being forgotten to 
> leave the cluster it may automatically repair a split many times. But it 
> supposed to be manual operation.



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

[jira] [Created] (IGNITE-6622) User defined function doesn't work if query executed via ignite.context().query().querySqlFieldsNoCache(qry, true);

2017-10-13 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-6622:
--

 Summary: User defined function doesn't work if query executed via 
ignite.context().query().querySqlFieldsNoCache(qry, true);
 Key: IGNITE-6622
 URL: https://issues.apache.org/jira/browse/IGNITE-6622
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Pavel Konstantinov


User defined function doesn't work if query executed via 
ignite.context().query().querySqlFieldsNoCache(qry, true);



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

[jira] [Comment Edited] (IGNITE-5608) SQL scripts execution capability

2017-10-13 Thread Oleg Ostanin (JIRA)


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

Oleg Ostanin edited comment on IGNITE-5608 at 10/13/17 9:53 AM:


I've added more examples in help and .bat file for sqlline launch:
https://ci.ignite.apache.org/viewLog.html?buildId=889637=artifacts=IgniteRelease_XxxFromMirrorIgniteRelease3PrepareVote#!1rrb2,1esn4zrslm4po


was (Author: oleg-ostanin):
I've added more examples in help and .bat file for sqlline launch:

> SQL scripts execution capability
> 
>
> Key: IGNITE-5608
> URL: https://issues.apache.org/jira/browse/IGNITE-5608
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> There should be a way to feed an SQL script to Ignite and execute it right 
> away. A script can consist of DDL command that will define cluster and SQL 
> configuration as well as of DML commands that, for instance, preload data 
> into Ignite.



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

[jira] [Commented] (IGNITE-5608) SQL scripts execution capability

2017-10-13 Thread Oleg Ostanin (JIRA)


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

Oleg Ostanin commented on IGNITE-5608:
--

I've added more examples in help and .bat file for sqlline launch:

> SQL scripts execution capability
> 
>
> Key: IGNITE-5608
> URL: https://issues.apache.org/jira/browse/IGNITE-5608
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>Assignee: Oleg Ostanin
> Fix For: 2.3
>
>
> There should be a way to feed an SQL script to Ignite and execute it right 
> away. A script can consist of DDL command that will define cluster and SQL 
> configuration as well as of DML commands that, for instance, preload data 
> into Ignite.



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

[jira] [Updated] (IGNITE-6621) .NET: Disable thin client for 2.3 release

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn updated IGNITE-6621:
---
Description: 2.3 is coming out soon, and thin client feature is far from 
being release-ready (small part of cache APIs is all we have), let's disable it 
in {{ignite-2.3}} branch to avoid confusing users.  (was: 2.3 is coming out 
soon, and thin client feature is far from being release-ready (small part of 
cache APIs is all we have), let's disable it in {{ignite-2.3}} branch.)

> .NET: Disable thin client for 2.3 release
> -
>
> Key: IGNITE-6621
> URL: https://issues.apache.org/jira/browse/IGNITE-6621
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, thin client
>Affects Versions: 2.3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.3
>
>
> 2.3 is coming out soon, and thin client feature is far from being 
> release-ready (small part of cache APIs is all we have), let's disable it in 
> {{ignite-2.3}} branch to avoid confusing users.



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

[jira] [Updated] (IGNITE-5714) Context switching for pessimistic transactions

2017-10-13 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov updated IGNITE-5714:
-
Description: 
Support transaction suspend()\resume() operations for pessimistic transactions. 
Resume can be called in another thread.

   _+But there is a problem+_: Imagine, we started pessimistic transaction in 
thread T1 and then perform put operation, which leads to sending 
GridDistributedLockRequest to another node. Lock request contains thread id of 
the transaction. Then we call suspend, resume in another thread and we also 
must send messages to other nodes to change thread id. 

It seems complicated task.It’s better to get rid of sending thread id to the 
nodes.
We can use transaction xid on other nodes instead of thread id. Xid is sent to 
nodes in GridDistributedLockRequest#nearXidVer

   _+Proposed solution+_ : On remote nodes instead of thread id of near 
transaction GridDistributedLockRequest#threadId use its xid 
GridDistributedLockRequest#nearXidVer.
Remove usages of near transaction's thread id on remote nodes.

  was:
Support transaction suspend()\resume() operations for pessimistic transactions. 
Resume can be called in another thread.

   _But there is a problem_: Imagine, we started pessimistic transaction in 
thread T1 and then perform put operation, which leads to sending 
GridDistributedLockRequest to another node. Lock request contains thread id of 
the transaction. Then we call suspend, resume in another thread and we also 
must send messages to other nodes to change thread id. 

It seems complicated task.It’s better to get rid of sending thread id to the 
nodes.
We can use transaction xid on other nodes instead of thread id. Xid is sent to 
nodes in GridDistributedLockRequest#nearXidVer

   _Proposed solution_ : On remote nodes instead of thread id of near 
transaction GridDistributedLockRequest#threadId use its xid 
GridDistributedLockRequest#nearXidVer.
Remove usages of near transaction's thread id on remote nodes.


> Context switching for pessimistic transactions
> --
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>
> Support transaction suspend()\resume() operations for pessimistic 
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in 
> thread T1 and then perform put operation, which leads to sending 
> GridDistributedLockRequest to another node. Lock request contains thread id 
> of the transaction. Then we call suspend, resume in another thread and we 
> also must send messages to other nodes to change thread id. 
> It seems complicated task.It’s better to get rid of sending thread id to the 
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent 
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near 
> transaction GridDistributedLockRequest#threadId use its xid 
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.



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

[jira] [Updated] (IGNITE-5714) Context switching for pessimistic transactions

2017-10-13 Thread Alexey Kuznetsov (JIRA)


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

Alexey Kuznetsov updated IGNITE-5714:
-
Description: 
Support transaction suspend()\resume() operations for pessimistic transactions. 
Resume can be called in another thread.

   _But there is a problem_: Imagine, we started pessimistic transaction in 
thread T1 and then perform put operation, which leads to sending 
GridDistributedLockRequest to another node. Lock request contains thread id of 
the transaction. Then we call suspend, resume in another thread and we also 
must send messages to other nodes to change thread id. 

It seems complicated task.It’s better to get rid of sending thread id to the 
nodes.
We can use transaction xid on other nodes instead of thread id. Xid is sent to 
nodes in GridDistributedLockRequest#nearXidVer

   _Proposed solution_ : On remote nodes instead of thread id of near 
transaction GridDistributedLockRequest#threadId use its xid 
GridDistributedLockRequest#nearXidVer.
Remove usages of near transaction's thread id on remote nodes.

  was:Implement context switching for pessimistic transactions


> Context switching for pessimistic transactions
> --
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
>  Issue Type: Sub-task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>
> Support transaction suspend()\resume() operations for pessimistic 
> transactions. Resume can be called in another thread.
>_But there is a problem_: Imagine, we started pessimistic transaction in 
> thread T1 and then perform put operation, which leads to sending 
> GridDistributedLockRequest to another node. Lock request contains thread id 
> of the transaction. Then we call suspend, resume in another thread and we 
> also must send messages to other nodes to change thread id. 
> It seems complicated task.It’s better to get rid of sending thread id to the 
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent 
> to nodes in GridDistributedLockRequest#nearXidVer
>_Proposed solution_ : On remote nodes instead of thread id of near 
> transaction GridDistributedLockRequest#threadId use its xid 
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.



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

[jira] [Created] (IGNITE-6621) .NET: Disable thin client for 2.3 release

2017-10-13 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6621:
--

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


2.3 is coming out soon, and thin client feature is far from being release-ready 
(small part of cache APIs is all we have), let's disable it in {{ignite-2.3}} 
branch.



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

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

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6605:
-

One more run: https://ci.ignite.apache.org/viewQueued.html?itemId=889654

> 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] [Created] (IGNITE-6620) Document JDBC/ODBC "skipReducerOnUpdate" flag

2017-10-13 Thread Vladimir Ozerov (JIRA)

Vladimir Ozerov created IGNITE-6620:
---

 Summary: Document JDBC/ODBC "skipReducerOnUpdate" flag
 Key: IGNITE-6620
 URL: https://issues.apache.org/jira/browse/IGNITE-6620
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3






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

[jira] [Commented] (IGNITE-6024) SQL: execute DML statements on the server when possible

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


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

ASF GitHub Bot commented on IGNITE-6024:


Github user asfgit closed the pull request at:

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


> SQL: execute DML statements on the server when possible
> ---
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.3
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network 
> communication  Instead, we should execute DML statements directly on server 
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g., 
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
> question - they must go through the client anyway. Probably 
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if 
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When 
> MVCC and TX SQL is ready, client will assign proper counters to server 
> requests.



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

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

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


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

ASF GitHub Bot commented on IGNITE-6371:


Github user asfgit closed the pull request at:

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


> .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-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6371:


Merged to master: {{5ec744cf7fb0db0658f91176bf98dfe5ccb05be2}}.

> .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-6608) .NET: Thin client documentation

2017-10-13 Thread Pavel Tupitsyn (JIRA)


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

Pavel Tupitsyn commented on IGNITE-6608:


Done, [~dmagda], please have a look.

> .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] [Created] (IGNITE-6619) .NET: Ignite Demo Application

2017-10-13 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6619:
--

 Summary: .NET: Ignite Demo Application
 Key: IGNITE-6619
 URL: https://issues.apache.org/jira/browse/IGNITE-6619
 Project: Ignite
  Issue Type: Task
  Components: examples, platforms
Reporter: Pavel Tupitsyn


We have a number of examples, but each of them demonstrates some particular 
feature in isolation.

Let's create a fully-functional line-of-business CRUD .NET application that 
uses Ignite.NET as a database, demonstrating transactions, queries (SQL and 
LINQ), atomics, whatever we can put in there.



--
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-13 Thread Igor Sapego (JIRA)


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

Igor Sapego commented on IGNITE-6592:
-

Done.

> 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: Prachi Garg
> 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-6592) Describe Ignite C++ pointer reading and writing semantics

2017-10-13 Thread Igor Sapego (JIRA)


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

Igor Sapego reassigned IGNITE-6592:
---

Assignee: Prachi Garg  (was: Igor Sapego)

> 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: Prachi Garg
> 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] [Updated] (IGNITE-6618) Web console: Do not show client nodes in node selection modal

2017-10-13 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov updated IGNITE-6618:
---
Summary: Web console: Do not show client nodes in node selection modal  
(was: Do not show client nodes in node selection modal)

> Web console: Do not show client nodes in node selection modal
> -
>
> Key: IGNITE-6618
> URL: https://issues.apache.org/jira/browse/IGNITE-6618
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Pavel Konstantinov
> Fix For: 2.3
>
>
> I tried to 'Execute on Selected Node' the following query
> {code}
> SELECT c.id, d.id, p.id, p.salary 
> FROM "c_partitioned".City c
> inner join "c_partitioned".Department d
> on c.id=d.CTYID 
> inner join "c_partitioned".Person p
> on d.id=p.depID and p.salary > 5000
> inner join "c_partitioned".PersonBonus pb
> on p.id=pb.perID and pb.COUNT  < 5000
> where exists (select * from "c_partitioned".Person where rank > 0)
> {code}
> and selected a client node in the list of nodes
> and got exception
> {code}
> General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, 
> d.id, p.id, p.salary 
>  FROM "c_partitioned".City c
>  inner join "c_partitioned".Department d
>  on c.id=d.CTYID 
>  inner join "c_partitioned".Person p
>  on d.id=p.depID and p.salary > 5000
>  inner join "c_partitioned".PersonBonus pb
>  on p.id=pb.perID and pb.COUNT < 5000
>  where exists (select * from "c_partitioned".Person where rank > 0) 
> [5-195]
> {code}



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

[jira] [Created] (IGNITE-6618) Do not show client nodes in node selection modal

2017-10-13 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-6618:
--

 Summary: Do not show client nodes in node selection modal
 Key: IGNITE-6618
 URL: https://issues.apache.org/jira/browse/IGNITE-6618
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Pavel Konstantinov
 Fix For: 2.3


I tried to 'Execute on Selected Node' the following query
{code}
SELECT c.id, d.id, p.id, p.salary 
FROM "c_partitioned".City c
inner join "c_partitioned".Department d
on c.id=d.CTYID 
inner join "c_partitioned".Person p
on d.id=p.depID and p.salary > 5000
inner join "c_partitioned".PersonBonus pb
on p.id=pb.perID and pb.COUNT  < 5000
where exists (select * from "c_partitioned".Person where rank > 0)
{code}

and selected a client node in the list of nodes
and got exception
{code}
General error: "java.lang.NullPointerException"; SQL statement: SELECT c.id, 
d.id, p.id, p.salary 
 FROM "c_partitioned".City c
 inner join "c_partitioned".Department d
 on c.id=d.CTYID 
 inner join "c_partitioned".Person p
 on d.id=p.depID and p.salary > 5000
 inner join "c_partitioned".PersonBonus pb
 on p.id=pb.perID and pb.COUNT < 5000
 where exists (select * from "c_partitioned".Person where rank > 0) [5-195]
{code}



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

[jira] [Assigned] (IGNITE-6482) Add support for groups count

2017-10-13 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov reassigned IGNITE-6482:
--

Assignee: (was: Pavel Konstantinov)

> Add support for groups count
> 
>
> Key: IGNITE-6482
> URL: https://issues.apache.org/jira/browse/IGNITE-6482
> Project: Ignite
>  Issue Type: Improvement
>  Components: yardstick
>Reporter: Pavel Konstantinov
>Priority: Minor
>
> Current implementation supports only one group for caches.
> We need improve it to support more then one group.
> Each group will have / caches inside.
> Applicable only if option -cc (caches count) is set.
> Default groups count = 1.



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

[jira] [Closed] (IGNITE-5908) Web console: may failed to open non-root if user is not authorized

2017-10-13 Thread Pavel Konstantinov (JIRA)


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

Pavel Konstantinov closed IGNITE-5908.
--

> Web console: may failed to open non-root if user is not authorized
> --
>
> Key: IGNITE-5908
> URL: https://issues.apache.org/jira/browse/IGNITE-5908
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>
> For example try to open http://localhost/configuration/basic
> Expected: should redirect to home page



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

[jira] [Created] (IGNITE-6617) Web console: there is no error message that cluster is not active on Queries screen

2017-10-13 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-6617:
--

 Summary: Web console: there is no error message that cluster is 
not active on Queries screen
 Key: IGNITE-6617
 URL: https://issues.apache.org/jira/browse/IGNITE-6617
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Pavel Konstantinov
 Fix For: 2.4


start cluster with persistent
start web agent connected to this cluster
open Queries on web console
try to execute any 'select' query
there is no error message that cluster is not active



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

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

2017-10-13 Thread Alexey Popov (JIRA)


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

Alexey Popov commented on IGNITE-4723:
--

Changes:
1. {{Regex.IsMatch()}} added
2. Basic {{RegexOptions}} are supported for {{Regex.Replace()}} and 
{{Regex.IsMatch()}}
3. Corresponding string tests added

[~ptupitsyn] Please review

> .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
> Fix For: 2.4
>
>
> {{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-4723) .NET: Support REGEXP_LIKE in LINQ

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


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

ASF GitHub Bot commented on IGNITE-4723:


GitHub user apopovgg opened a pull request:

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

IGNITE-4723 .NET: Support REGEXP_LIKE in LINQ



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

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

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

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


commit 5b77a02948885239418708edde91480e1b73fb0d
Author: apopov 
Date:   2017-10-13T08:03:10Z

IGNITE-4723 .NET: Support REGEXP_LIKE in LINQ




> .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-6024) SQL: execute DML statements on the server when possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6024:
-

Final test run: https://ci.ignite.apache.org/viewQueued.html?itemId=889324

> SQL: execute DML statements on the server when possible
> ---
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.3
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network 
> communication  Instead, we should execute DML statements directly on server 
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g., 
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
> question - they must go through the client anyway. Probably 
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if 
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When 
> MVCC and TX SQL is ready, client will assign proper counters to server 
> requests.



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

[jira] [Commented] (IGNITE-6024) SQL: execute DML statements on the server when possible

2017-10-13 Thread Vladimir Ozerov (JIRA)


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

Vladimir Ozerov commented on IGNITE-6024:
-

Renamed flag to {{skipReducerOnUpdate}}.

> SQL: execute DML statements on the server when possible
> ---
>
> Key: IGNITE-6024
> URL: https://issues.apache.org/jira/browse/IGNITE-6024
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: important, performance
> Fix For: 2.3
>
>
> Currently we execute DML statements as follows:
> 1) Get query result set to the client
> 2) Construct entry processors and send them to servers in batches
> This approach is inefficient as it causes a lot of unnecessary network 
> communication  Instead, we should execute DML statements directly on server 
> nodes when it is possible.
> Implementation considerations:
> 1) Determine set of queries which could be processed in this way. E.g., 
> {{LIMIT/OFFSET}}, {{GROUP BY}}, {{ORDER BY}}, {{DISTINCT}}, etc. are out of 
> question - they must go through the client anyway. Probably 
> {{skipMergeTable}} flag is a good starting point (good, not precise!)
> 2) Send request to every server and execute local DML right there
> 3) No failover support at the moment - throw "partial update" exception if 
> topology is unstable
> 4) Handle partition reservation carefully
> 5) Transactions: we still have single coordinator - this is a client. When 
> MVCC and TX SQL is ready, client will assign proper counters to server 
> requests.



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

73 matches

Mail list logo