[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik updated IGNITE-3933:
---
Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(\*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For *REPLICATED* caches SQL query like *select \* from 
> my_replicated_cache* returns as many duplicates for each record as many nodes 
> in an Ignite cluster. Same problem with *select count(\*) from 
> my_replicated_cache* - it returns actual number of records multiplied by the 
> number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik updated IGNITE-3933:
---
Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select \* from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For *REPLICATED* caches SQL query like *select \* from 
> my_replicated_cache* returns as many duplicates for each record as many nodes 
> in an Ignite cluster. Same problem with *select count(*) from 
> my_replicated_cache* - it returns actual number of records multiplied by the 
> number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns 

[jira] [Created] (IGNITE-3934) Web Consloe: Capacity planning

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-3934:


 Summary: Web Consloe: Capacity planning
 Key: IGNITE-3934
 URL: https://issues.apache.org/jira/browse/IGNITE-3934
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 1.7
Reporter: Alexey Kuznetsov
 Fix For: 1.8


We have a capacity planning page [1] in docs, but it's not very easy to follow 
this guide when data is loaded from a large database with 100s of tables. How 
about we add this calculation to the Web Console? I think we can do this during 
the model import - get the counts of each table and approximate the size of 
each table's row.

[1] http://apacheignite.gridgain.org/v1.7/docs/capacity-planning




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

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For *REPLICATED* caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying *PARTITIONED* cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying *REPLICATED* cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
*PARTITIONED* caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine *REPLICATED* and *PARTITIONED* 
caches in one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for *REPLICATED* cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
PARTITIONED caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For *REPLICATED* caches SQL query like *select * from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with *select count(*) from my_replicated_cache* - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like *select * from 
my_replicated_cache* return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the *select * from my_replicated_cache* query. At the same time it failed 
to execute simple queries like *select * from my_partitioned_cache* against 
PARTITIONED caches throwing this error:

*java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]*

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with *select count(*) from my_replicated_cache* - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with *select count(*) from my_replicated_cache* - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(**) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with *select count(*) from my_replicated_cache* - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> *Example 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(**) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with "select count(**) from my_replicated_cache" - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select ** from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like *select ** from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with "select count(*) from my_replicated_cache" - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1* - using simple JDBC connection URL 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.

Example 2 - specifying replicated or partitioned cache in JDBC connection URL 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with "select count(*) from my_replicated_cache" - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> *Example 2 - 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1 - using simple JDBC connection URL* 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like *select ** from my_replicated_cache* 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.


*Example 2 - specifying replicated or partitioned cache in JDBC connection URL* 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1 - using simple JDBC connection URL* 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like *select * from my_replicated_cache* 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with "select count(*) from my_replicated_cache" - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> *Example 

[jira] [Updated] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

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

Igor Rudyak updated IGNITE-3933:

Description: 
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

*Example 1* - using simple JDBC connection URL 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.

Example 2 - specifying replicated or partitioned cache in JDBC connection URL 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.

  was:
There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

Example 1 - using simple JDBC connection URL 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.

Example 2 - specifying replicated or partitioned cache in JDBC connection URL 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.


> JDBC issue with Replicated & Partitioned caches
> ---
>
> Key: IGNITE-3933
> URL: https://issues.apache.org/jira/browse/IGNITE-3933
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc-driver, odbc, SQL
>Affects Versions: 1.8
>Reporter: Igor Rudyak
>Priority: Critical
>
> There is an issue with JDBC when trying to play with different types of 
> caches using the same JDBC connection.
> *Example 1* - using simple JDBC connection URL 
> jdbc:ignite:cfg://file:///my-ignite-client-config.xm
> 1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
> returns as many duplicates for each record as many nodes in an Ignite 
> cluster. Same problem with "select count(*) from my_replicated_cache" - it 
> returns actual number of records multiplied by the number of Ignite nodes.
> 2) At the same time if traversing the cache using "for" loop and iterator, it 
> returns exactly what's needed without any duplicates.
> Example 2 - 

[jira] [Created] (IGNITE-3933) JDBC issue with Replicated & Partitioned caches

[Igor Rudyak (JIRA)]

Igor Rudyak created IGNITE-3933:
---

 Summary: JDBC issue with Replicated & Partitioned caches
 Key: IGNITE-3933
 URL: https://issues.apache.org/jira/browse/IGNITE-3933
 Project: Ignite
  Issue Type: Bug
  Components: jdbc-driver, odbc, SQL
Affects Versions: 1.8
Reporter: Igor Rudyak
Priority: Critical


There is an issue with JDBC when trying to play with different types of caches 
using the same JDBC connection.

Example 1 - using simple JDBC connection URL 
jdbc:ignite:cfg://file:///my-ignite-client-config.xm

1) For REPLICATED caches SQL query like "select * from my_replicated_cache" 
returns as many duplicates for each record as many nodes in an Ignite cluster. 
Same problem with "select count(*) from my_replicated_cache" - it returns 
actual number of records multiplied by the number of Ignite nodes.

2) At the same time if traversing the cache using "for" loop and iterator, it 
returns exactly what's needed without any duplicates.

Example 2 - specifying replicated or partitioned cache in JDBC connection URL 
jdbc:ignite:cfg://cache=my_cache@file:///my-ignite-client-config.xm
 
1) If specifying PARTITIONED cache in JDBC URL - queries like "select * from 
my_replicated_cache" return duplicates
 
2) If specifying REPLICATED cache in JDBC URL - it doesn't return duplicates 
for the "select * from my_replicated_cache" query. At the same time it failed 
to execute simple queries like "select * from my_partitioned_cache" against 
PARTITIONED caches throwing this error:

java.lang.RuntimeException: javax.cache.CacheException: Queries running on 
replicated cache should not contain JOINs with partitioned tables 
[rCache=product, pCache=order]

The fact that it's not possible to combine REPLICATED and PARTITIONED caches in 
one SQL query (using one JDBC connection) looks not very good. 

Also the idea of specifying cache name (for REPLICATED cache) in the JDBC URL 
for optimization purposes doesn't look good. It's better to utilize rather wide 
used "hits" approach, to provide optimization hints inside SQL query. Otherwise 
it's not possible to use JDBC with analytical and UI tools to run ad-hock SQL 
queries.



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

[jira] [Assigned] (IGNITE-2680) Terminating running SQL queries

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov reassigned IGNITE-2680:
-

Assignee: Alexei Scherbakov  (was: Sergi Vladykin)

> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alexei Scherbakov
>  Labels: important
>
> If to start a long running SQL query over a huge cache will millions of 
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed 
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related 
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;



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

[jira] [Commented] (IGNITE-1525) Return value for cache operation can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-1525:
--

putIfAbsent/remove will be fixed as separated issue IGNITE-3932
prototype fixing putIfAbsent/remove checked to honor changes provided by this 
fix.

> Return value for cache operation can be lost with onePhaseCommit
> 
>
> Key: IGNITE-1525
> URL: https://issues.apache.org/jira/browse/IGNITE-1525
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.8
>
>
> Looks like with {{onePhaseCommit}} return value for cache operation can be 
> lost if primary node fails, {{GridNearTxPrepareResponse}} with return value 
> is not received, but transaction executes 'check backup' step and finishes 
> without error.
> Reproduces in {{IgniteCachePutRetryTransactionalSelfTest.testInvoke}}, also 
> added one more test to check return value 
> {{IgniteCachePutRetryTransactionalSelfTest.testGetAndPut}}.
> Please unmute tests on TC when fixed.



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

[jira] [Commented] (IGNITE-3601) Read-only optimistic transaction shouldn't throw an exception if entry version was not changed.

[Semen Boikov (JIRA)]

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

Semen Boikov commented on IGNITE-3601:
--

In tx cache putIfAbsent does not properly handle case when old value is loaded 
from remote node, implemented fix, need verify TC.

> Read-only optimistic transaction shouldn't throw an exception if entry 
> version was not changed.
> ---
>
> Key: IGNITE-3601
> URL: https://issues.apache.org/jira/browse/IGNITE-3601
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Semen Boikov
> Fix For: 1.8
>
> Attachments: Test.java
>
>
> Concurrent read only transactions reading the same key throw unexpected 
> IgniteTxOptimisticCheckedException. 
> They shouldn't do what because entry version was not changed.
> See the reproducer in the attachment.



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

[jira] [Resolved] (IGNITE-3810) FileSwapSpaceSpi can hang when large value is written

[Semen Boikov (JIRA)]

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

Semen Boikov resolved IGNITE-3810.
--
Resolution: Fixed

Reviewed, looks good, merged.

> FileSwapSpaceSpi can hang when large value is written
> -
>
> Key: IGNITE-3810
> URL: https://issues.apache.org/jira/browse/IGNITE-3810
> Project: Ignite
>  Issue Type: Bug
>  Components: swap
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
> Fix For: 1.8
>
> Attachments: SwapSpaceTest.java
>
>
> Test reproducing the issue is attached.
> Weirdly, the value of size {{1024 * 1024 - 48}} is successfully written, but 
> when it is only one byte bigger, the swap space hangs.



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

[jira] [Updated] (IGNITE-3810) FileSwapSpaceSpi can hang when large value is written

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-3810:
-
Assignee: (was: Semen Boikov)

> FileSwapSpaceSpi can hang when large value is written
> -
>
> Key: IGNITE-3810
> URL: https://issues.apache.org/jira/browse/IGNITE-3810
> Project: Ignite
>  Issue Type: Bug
>  Components: swap
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
> Fix For: 1.8
>
> Attachments: SwapSpaceTest.java
>
>
> Test reproducing the issue is attached.
> Weirdly, the value of size {{1024 * 1024 - 48}} is successfully written, but 
> when it is only one byte bigger, the swap space hangs.



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

[jira] [Created] (IGNITE-3932) Return value for remove or putIfAbsent can be lost with onePhaseCommit

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-3932:


 Summary: Return value for remove or putIfAbsent can be lost with 
onePhaseCommit
 Key: IGNITE-3932
 URL: https://issues.apache.org/jira/browse/IGNITE-3932
 Project: Ignite
  Issue Type: Bug
Reporter: Anton Vinogradov
Assignee: Anton Vinogradov






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

[jira] [Created] (IGNITE-3931) IGFS: Support direct PROXY mode invocations. Fix tests & stabilization

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-3931:


 Summary: IGFS: Support direct PROXY mode invocations. Fix tests & 
stabilization
 Key: IGNITE-3931
 URL: https://issues.apache.org/jira/browse/IGNITE-3931
 Project: Ignite
  Issue Type: Sub-task
  Components: IGFS
Affects Versions: 1.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 1.8






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

[jira] [Commented] (IGNITE-3858) IGFS: Support direct PROXY mode invocation in methods: create / append

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3858:
--

Fixed

> IGFS: Support direct PROXY mode invocation in methods: create / append
> --
>
> Key: IGNITE-3858
> URL: https://issues.apache.org/jira/browse/IGNITE-3858
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
>




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

[jira] [Closed] (IGNITE-3861) ODBC: installer doesn't support path to driver with backspaces

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova closed IGNITE-3861.
--
Assignee: (was: Vasilisa  Sidorova)

Fix verified for Ignite 1.6.8 

> ODBC: installer doesn't support path to driver with backspaces
> --
>
> Key: IGNITE-3861
> URL: https://issues.apache.org/jira/browse/IGNITE-3861
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.6
> Environment: Win 8, odbc installer 1.6.7
>Reporter: Vasilisa  Sidorova
> Fix For: 1.8
>
>
> -
> STEPS FOR REPRODUCE
> -
> # Build odbc driver according to instruction from 
> $IGNITE_HOME/platforms/cpp/DEVNOTES.txt
> # Put driver into folder with path which contains backspaces
> # Install odbc driver according to instruction from  
> $IGNITE_HOME/platforms/cpp/odbc/README.txt 
> -
> ACTUAL RESULT
> -
> # Driver get error like this:
> {noformat}
> C:\ignite\platforms\cpp\odbc\install>install_x86.cmd "C:\Program 
> Files\IgniteODBC\ignite.odbc.dll"
> warning: The path you have specified seems to be a directory. Note that you 
> have to specify path to driver file itself instead.
> Installing driver: ""C:\Program Files\IgniteODBC\ignite.odbc.dll""
> The operation completed successfully.
> The operation completed successfully.
> ERROR: Invalid syntax.
> Type "REG ADD /?" for usage.
> The operation completed successfully.
> Driver can not be found: ""C:\Program Files\IgniteODBC\ignite.odbc.dll""
> Call format: install_x86 abs_path_to_driver
> Press any key to continue . . .
> {noformat}
> # Driver isn't installed
> -
> EXPECTED RESULT
> -
> Driver is installed without any exceptions or should give correct and clear  
> error string



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

[jira] [Closed] (IGNITE-3799) More descriptive exception for Cassandra column names duplicates

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-3799.


> More descriptive exception for Cassandra column names duplicates 
> -
>
> Key: IGNITE-3799
> URL: https://issues.apache.org/jira/browse/IGNITE-3799
> Project: Ignite
>  Issue Type: Bug
>Reporter: Igor Rudyak
>Assignee: Igor Rudyak
>
> If POJO persistence strategy is used and cache key is mapped to the same 
> column as one of the POJO fields, it's better to re-throw more descriptive 
> exception instead of 
> *com.datastax.driver.core.exceptions.InvalidQueryException: The column names 
> contains duplicates*



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

[jira] [Closed] (IGNITE-3114) "IllegalStateException: Row conflict should never happen" during load test

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova closed IGNITE-3114.
---

> "IllegalStateException: Row conflict should never happen" during load test
> --
>
> Key: IGNITE-3114
> URL: https://issues.apache.org/jira/browse/IGNITE-3114
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Priority: Critical
> Fix For: 1.8
>
> Attachments: benchmark-cache-load.properties, logs.zip
>
>
> Configuration:
> - 3 drivers at 1 host, 30 servers at 3 hosts;
> - all operations are enabled except SCAN_QUERY, SQL_QUERY and CONTINUOUS_QUERY
> - for other settings see attached benchmark-cache-load.properties file
> Steps to reproduce:
> 1) Run load test:
>  ./bin/benchmark-run-all.sh config/benchmark-cache-load.properties
> 2) Check all server log files. 
> Note: In my case I noticed that all these exceptions happened only at 20th 
> server (1st server node at the 3rd host), so see 
> 20160511-ignite-1.6.0-SNAPSHOT-37c03c22-pr670-c3-s40/logs/servers/10.20.0.223/logs-20160511-040658/logs_servers/040710_id20_10.20.0.223.log
>  in attached archive.
> Expected:
> No exceptions.
> Actual:
> "java.lang.IllegalStateException: Row conflict should never happen, unique 
> indexes are not supported" exceptions accur while running load test 
> benchmark. 
> java.lang.IllegalStateException: Row conflict should never happen, unique 
> indexes are not supported.
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:410)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:340)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:524)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:700)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:3849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3309)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1618)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:305)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:50)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:80)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>  



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

[jira] [Resolved] (IGNITE-3114) "IllegalStateException: Row conflict should never happen" during load test

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova resolved IGNITE-3114.
-
Resolution: Cannot Reproduce

> "IllegalStateException: Row conflict should never happen" during load test
> --
>
> Key: IGNITE-3114
> URL: https://issues.apache.org/jira/browse/IGNITE-3114
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Priority: Critical
> Fix For: 1.8
>
> Attachments: benchmark-cache-load.properties, logs.zip
>
>
> Configuration:
> - 3 drivers at 1 host, 30 servers at 3 hosts;
> - all operations are enabled except SCAN_QUERY, SQL_QUERY and CONTINUOUS_QUERY
> - for other settings see attached benchmark-cache-load.properties file
> Steps to reproduce:
> 1) Run load test:
>  ./bin/benchmark-run-all.sh config/benchmark-cache-load.properties
> 2) Check all server log files. 
> Note: In my case I noticed that all these exceptions happened only at 20th 
> server (1st server node at the 3rd host), so see 
> 20160511-ignite-1.6.0-SNAPSHOT-37c03c22-pr670-c3-s40/logs/servers/10.20.0.223/logs-20160511-040658/logs_servers/040710_id20_10.20.0.223.log
>  in attached archive.
> Expected:
> No exceptions.
> Actual:
> "java.lang.IllegalStateException: Row conflict should never happen, unique 
> indexes are not supported" exceptions accur while running load test 
> benchmark. 
> java.lang.IllegalStateException: Row conflict should never happen, unique 
> indexes are not supported.
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:410)
> at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:340)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:524)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:700)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:407)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateIndex(GridCacheMapEntry.java:3849)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:3309)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1618)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:305)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:50)
> at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:80)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:847)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:105)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:810)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
>  



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

[jira] [Commented] (IGNITE-3859) IGFS: Support direct PROXY mode invocation in method: open

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3859:
--

Fixed

> IGFS: Support direct PROXY mode invocation in method: open
> --
>
> Key: IGNITE-3859
> URL: https://issues.apache.org/jira/browse/IGNITE-3859
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 1.8
>
>




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

[jira] [Commented] (IGNITE-3929) Hadoop: Fix native libraries loading mechanism.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-3929:
-

Looks like we can employ the following mechanism:
1) Still use {{HadoopConfiguration.getNativeLibraryNames()}} method.
2) Add well-known Hadoop (and any other distribution) library names.
3) If name is absolute, then use {{System.load}}. If relative - 
{{System.loadLibrary}}.
4) Try loading libraries in static initializer of {{HadoopClassLoader}}. 
5) All user-defined libs are considered mandatory, while our libs may be either 
mandatory or optional. E.g. {{hadoop}} is optional library.
6) Link loaded libraries from parent classloader to current classloader.

> Hadoop: Fix native libraries loading mechanism.
> ---
>
> Key: IGNITE-3929
> URL: https://issues.apache.org/jira/browse/IGNITE-3929
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 1.8
>
>
> Currently we do the following to load native libraries:
> 1) Ask parent class loader (normally it is app class loader) to load 
> {{org.apache.hadoop.util.NativeCodeLoader}} class. It will force loading of 
> relevant Hadoop native libraries.
> 2) Then hack into parent class loader internals, find loaded library, and 
> wire it up to current classloader.
> This approach will not work any more because parent classloader normally will 
> not have Hadoop in classpath.
> We should provide alternative solution.



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

[jira] [Assigned] (IGNITE-3199) .NET: ASP.NET Session-State Store Provider

[Vasilisa Sidorova (JIRA)]

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

Vasilisa  Sidorova reassigned IGNITE-3199:
--

Assignee: Vasilisa  Sidorova

> .NET: ASP.NET Session-State Store Provider
> --
>
> Key: IGNITE-3199
> URL: https://issues.apache.org/jira/browse/IGNITE-3199
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 1.7
>Reporter: Pavel Tupitsyn
>Assignee: Vasilisa  Sidorova
>  Labels: .net
> Fix For: 1.8
>
>
> See https://msdn.microsoft.com/en-us/library/ms178587.aspx
> Code should be put to Apache.Ignite.AspNet assembly (see IGNITE-2379)



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

[jira] [Commented] (IGNITE-3858) IGFS: Support direct PROXY mode invocation in methods: create / append

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-3858:
--

Please take a look at the another implementation of the PROXY mode for the 
IgfsOutputStream. 

> IGFS: Support direct PROXY mode invocation in methods: create / append
> --
>
> Key: IGNITE-3858
> URL: https://issues.apache.org/jira/browse/IGNITE-3858
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>




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

[jira] [Commented] (IGNITE-3858) IGFS: Support direct PROXY mode invocation in methods: create / append

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3858:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-3858 IGFS: Support direct PROXY mode invocation in methods: cr…

…eate / append

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

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

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

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


commit 775a86c53766dd97f572f37ddb74b5cdd429c7f0
Author: tledkov-gridgain 
Date:   2016-09-19T12:52:19Z

IGNITE-3858 IGFS: Support direct PROXY mode invocation in methods: create / 
append




> IGFS: Support direct PROXY mode invocation in methods: create / append
> --
>
> Key: IGNITE-3858
> URL: https://issues.apache.org/jira/browse/IGNITE-3858
> Project: Ignite
>  Issue Type: Sub-task
>  Components: IGFS
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>




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

[jira] [Updated] (IGNITE-3929) Hadoop: Fix native libraries loading mechanism.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3929:

Description: 
Currently we do the following to load native libraries:
1) Ask parent class loader (normally it is app class loader) to load 
{{org.apache.hadoop.util.NativeCodeLoader}} class. It will force loading of 
relevant Hadoop native libraries.
2) Then hack into parent class loader internals, find loaded library, and wire 
it up to current classloader.

This approach will not work any more because parent classloader normally will 
not have Hadoop in classpath.

We should provide alternative solution.

  was:
Currently we do the following to load native libraries:
1) Ask parent class loader (normally it is app class loader) to load 
{{org.apache.hadoop.util.NativeCodeLoader}} class. It will force loading of 
relevant Hadoop native libraries.
2) Then hack into parent class loader internals, find loaded library, and wire 
it up to current classloader.

This approach will not work any more because parent classloader normally will 
not have Hadoop in classpath.

We should provide alternative solution. One idea is to hack into 
{{findLibrary}} method: when it is called we can create alternative library 
name and point it, e.g., to symlink of a target library.


> Hadoop: Fix native libraries loading mechanism.
> ---
>
> Key: IGNITE-3929
> URL: https://issues.apache.org/jira/browse/IGNITE-3929
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 1.8
>
>
> Currently we do the following to load native libraries:
> 1) Ask parent class loader (normally it is app class loader) to load 
> {{org.apache.hadoop.util.NativeCodeLoader}} class. It will force loading of 
> relevant Hadoop native libraries.
> 2) Then hack into parent class loader internals, find loaded library, and 
> wire it up to current classloader.
> This approach will not work any more because parent classloader normally will 
> not have Hadoop in classpath.
> We should provide alternative solution.



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

[jira] [Commented] (IGNITE-1915) .NET: Ignite as Entity Framework Second-Level Cache

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1915:


Merged with master, refactored cleanup and version increment to Java approach 
with cache extension.

Discovered an issue: if entity set version data is lost (due to node failure), 
incorrect results can be returned for queries.
We can't have cache with backups to avoid duplicating possibly huge query 
results.

Solution here is similar to IGFS approach: use two caches. One "meta" cache 
with entity set versions, and another "data" cache with actual query results.
To simplify configuration, the only user-provided parameter is "provider name". 
Cache names will be generated automatically form it. Optionally, user would be 
able to provide customized cache configs.

> .NET: Ignite as Entity Framework Second-Level Cache
> ---
>
> Key: IGNITE-1915
> URL: https://issues.apache.org/jira/browse/IGNITE-1915
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .net, roadmap
> Fix For: 1.8
>
>
> Entity Framework is #1 ORM for .NET
> We should provide easy solution to boost Entity Framework performance with 
> Ignite.
> EF5 and EF6 have different 2nd level cache mechanisms (EF5 has a built-in 
> one, EF6 requies more customization or a 3rd party lib like 
> https://efcache.codeplex.com/). For now, let's do EF6 only.
> This should be in a separate assembly and a separate NuGet package.



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

[jira] [Created] (IGNITE-3929) Hadoop: Fix native libraries loading mechanism.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3929:
---

 Summary: Hadoop: Fix native libraries loading mechanism.
 Key: IGNITE-3929
 URL: https://issues.apache.org/jira/browse/IGNITE-3929
 Project: Ignite
  Issue Type: Sub-task
  Components: hadoop
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
 Fix For: 1.8


Currently we do the following to load native libraries:
1) Ask parent class loader (normally it is app class loader) to load 
{{org.apache.hadoop.util.NativeCodeLoader}} class. It will force loading of 
relevant Hadoop native libraries.
2) Then hack into parent class loader internals, find loaded library, and wire 
it up to current classloader.

This approach will not work any more because parent classloader normally will 
not have Hadoop in classpath.

We should provide alternative solution. One idea is to hack into 
{{findLibrary}} method: when it is called we can create alternative library 
name and point it, e.g., to symlink of a target library.



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

[jira] [Updated] (IGNITE-3928) Hadoop: Print warning if Hadoop is found in classpath of parent classloader.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3928:

Summary: Hadoop: Print warning if Hadoop is found in classpath of parent 
classloader.  (was: Hadoop: print warning if Hadoop is found in classpath of 
parent classloader.)

> Hadoop: Print warning if Hadoop is found in classpath of parent classloader.
> 
>
> Key: IGNITE-3928
> URL: https://issues.apache.org/jira/browse/IGNITE-3928
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Ivan Veselovsky
> Fix For: 1.8
>
>
> Normally parent classloader should not have Hadoop in classpath. Otherwise we 
> may end up in JAR hell situation.
> We need to probe parent classloader for Hadoop and print a warning if Hadoop 
> is likely to be in the classpath. E.g. we can probe for {{FileSystem}} or 
> {{Configuration}} class.



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

[jira] [Updated] (IGNITE-3918) Hadoop: Move interfaces from "hadoop-impl" to "hadoop" module.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3918:

Summary: Hadoop: Move interfaces from "hadoop-impl" to "hadoop" module.  
(was: Hadoop: move interfaces from "hadoop-impl" to "hadoop" module.)

> Hadoop: Move interfaces from "hadoop-impl" to "hadoop" module.
> --
>
> Key: IGNITE-3918
> URL: https://issues.apache.org/jira/browse/IGNITE-3918
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>




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

[jira] [Commented] (IGNITE-3927) Web Console: Need to reload notebooks in sql after "become this user" was used.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-3927:


Tested. 

> Web Console: Need to reload notebooks in sql after "become this user" was 
> used. 
> 
>
> Key: IGNITE-3927
> URL: https://issues.apache.org/jira/browse/IGNITE-3927
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.8
>
>




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

[jira] [Closed] (IGNITE-3927) Web Console: Need to reload notebooks in sql after "become this user" was used.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-3927.
--
Assignee: (was: Pavel Konstantinov)

> Web Console: Need to reload notebooks in sql after "become this user" was 
> used. 
> 
>
> Key: IGNITE-3927
> URL: https://issues.apache.org/jira/browse/IGNITE-3927
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Novikov
>Priority: Minor
> Fix For: 1.8
>
>




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

[jira] [Created] (IGNITE-3928) Hadoop: print warning if Hadoop is found in classpath of parent classloader.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3928:
---

 Summary: Hadoop: print warning if Hadoop is found in classpath of 
parent classloader.
 Key: IGNITE-3928
 URL: https://issues.apache.org/jira/browse/IGNITE-3928
 Project: Ignite
  Issue Type: Sub-task
  Components: hadoop
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Ivan Veselovsky
 Fix For: 1.8


Normally parent classloader should not have Hadoop in classpath. Otherwise we 
may end up in JAR hell situation.

We need to probe parent classloader for Hadoop and print a warning if Hadoop is 
likely to be in the classpath. E.g. we can probe for {{FileSystem}} or 
{{Configuration}} class.



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

[jira] [Reopened] (IGNITE-3705) Warnings when build ignite and ignite-example cpp projects with Visual Studio 2015 (v140) toolset

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova reopened IGNITE-3705:
-

cl : Command line warning D9025: overriding '/sdl-' with '/GS-'  still exists

> Warnings when build ignite and ignite-example cpp projects with Visual Studio 
> 2015 (v140) toolset
> -
>
> Key: IGNITE-3705
> URL: https://issues.apache.org/jira/browse/IGNITE-3705
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.7
> Environment: Windows 2010, Visual Studio 2015
>Reporter: Ksenia Rybakova
>Assignee: Ksenia Rybakova
>Priority: Minor
>  Labels: cpp
> Fix For: 1.8
>
>
> The following warnings apper when build ignite and ignite-example cpp 
> projects with Visual Studio 2015 (v140) toolset:
> {noformat}
> platforms\cpp\common\include\ignite/ignite_error.h(90): warning C4275: non 
> dll-interface class 'std::exception' used as base for dll-interface class 
> 'ignite::IgniteError'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\include\vcruntime_exception.h(43): note: see declaration of 
> 'std::exception'
> platforms\cpp\common\include\ignite/ignite_error.h(89): note: see declaration 
> of 'ignite::IgniteError'
> cl : Command line warning D9025: overriding '/sdl-' with '/GS-'
> {noformat}
> Steps to reproduce:
> - Install VS 2015 and SDK 8.1
> - Open %IGNITE_HOME%\platforms\cpp\project\vs\ignite.sln and 
> %IGNITE_HOME%\platforms\cpp\examples\project\vs\ignite-examples.sln solutions 
> in VS
> - Set "Visual Studio 2015 (v140)" as Platform Toolset and "8.1" as Target 
> Platform Version  in projects properties
> - Build solutions
> Expected: 
> - no errors and warnings



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

[jira] [Updated] (IGNITE-3705) Warnings when build ignite and ignite-example cpp projects with Visual Studio 2015 (v140) toolset

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-3705:

Assignee: Igor Sapego  (was: Ksenia Rybakova)

> Warnings when build ignite and ignite-example cpp projects with Visual Studio 
> 2015 (v140) toolset
> -
>
> Key: IGNITE-3705
> URL: https://issues.apache.org/jira/browse/IGNITE-3705
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.7
> Environment: Windows 2010, Visual Studio 2015
>Reporter: Ksenia Rybakova
>Assignee: Igor Sapego
>Priority: Minor
>  Labels: cpp
> Fix For: 1.8
>
>
> The following warnings apper when build ignite and ignite-example cpp 
> projects with Visual Studio 2015 (v140) toolset:
> {noformat}
> platforms\cpp\common\include\ignite/ignite_error.h(90): warning C4275: non 
> dll-interface class 'std::exception' used as base for dll-interface class 
> 'ignite::IgniteError'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\include\vcruntime_exception.h(43): note: see declaration of 
> 'std::exception'
> platforms\cpp\common\include\ignite/ignite_error.h(89): note: see declaration 
> of 'ignite::IgniteError'
> cl : Command line warning D9025: overriding '/sdl-' with '/GS-'
> {noformat}
> Steps to reproduce:
> - Install VS 2015 and SDK 8.1
> - Open %IGNITE_HOME%\platforms\cpp\project\vs\ignite.sln and 
> %IGNITE_HOME%\platforms\cpp\examples\project\vs\ignite-examples.sln solutions 
> in VS
> - Set "Visual Studio 2015 (v140)" as Platform Toolset and "8.1" as Target 
> Platform Version  in projects properties
> - Build solutions
> Expected: 
> - no errors and warnings



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

[jira] [Commented] (IGNITE-3916) Hadoop: Create additional module.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3916:


Github user devozerov closed the pull request at:

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


> Hadoop: Create additional module.
> -
>
> Key: IGNITE-3916
> URL: https://issues.apache.org/jira/browse/IGNITE-3916
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> The plan is as follows:
> 1) {{ignite-hadoop}} will have helpers and interfaces, but *will not* have 
> direct Hadoop dependency. This module will be loaded in runtime by the core.
> 2) {{ignite-hadoop-impl}} will have Hadoop-dependent implementations and have 
> direct dependency on Hadoop libraries. It will be accessed only through 
> {{HadoopClassLoader}} interface and should not be located in normal classpath 
> of the {{core}} module.
> In this ticket we should only create additional module, move all current 
> Hadoop classes there, and ensure correct dependencies 
> {{core <- hadoop <- hadoop-impl}}.



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

[jira] [Closed] (IGNITE-3916) Hadoop: Create additional module.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov closed IGNITE-3916.
---

> Hadoop: Create additional module.
> -
>
> Key: IGNITE-3916
> URL: https://issues.apache.org/jira/browse/IGNITE-3916
> Project: Ignite
>  Issue Type: Sub-task
>  Components: hadoop
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 1.8
>
>
> The plan is as follows:
> 1) {{ignite-hadoop}} will have helpers and interfaces, but *will not* have 
> direct Hadoop dependency. This module will be loaded in runtime by the core.
> 2) {{ignite-hadoop-impl}} will have Hadoop-dependent implementations and have 
> direct dependency on Hadoop libraries. It will be accessed only through 
> {{HadoopClassLoader}} interface and should not be located in normal classpath 
> of the {{core}} module.
> In this ticket we should only create additional module, move all current 
> Hadoop classes there, and ensure correct dependencies 
> {{core <- hadoop <- hadoop-impl}}.



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

[jira] [Resolved] (IGNITE-3927) Web Console: Need to reload notebooks in sql after "become this user" was used.

[Andrey Novikov (JIRA)]

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

Andrey Novikov resolved IGNITE-3927.

Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Andrey Novikov)

Added reload of notebooks list on become/revert. Fixed agent token on become.

> Web Console: Need to reload notebooks in sql after "become this user" was 
> used. 
> 
>
> Key: IGNITE-3927
> URL: https://issues.apache.org/jira/browse/IGNITE-3927
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 1.8
>
>




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

[jira] [Created] (IGNITE-3927) Web Console: Need to reload notebooks in sql after "become this user" was used.

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-3927:
--

 Summary: Web Console: Need to reload notebooks in sql after 
"become this user" was used. 
 Key: IGNITE-3927
 URL: https://issues.apache.org/jira/browse/IGNITE-3927
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Andrey Novikov
Assignee: Andrey Novikov
Priority: Minor
 Fix For: 1.8






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

[jira] [Commented] (IGNITE-3925) Output process ID to the log during node start.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3925:


GitHub user AMashenkov opened a pull request:

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

IGNITE-3925: Output process ID to the log during node start.



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

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

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

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


commit ebf354c568d0802b7eed1cc6b9d251941dbce014
Author: nikolay_tikhonov 
Date:   2016-09-16T11:32:13Z

IGNITE-3907 Fixed "Incorrect initialization CQ when node filter configured 
for cache"

commit c0b2b4797be4f250f6f1304ff27d45c72154608a
Author: Valentin Kulichenko 
Date:   2016-09-16T21:59:35Z

IGNITE-3635 - Fixed StackOverflowError thrown from BinaryObject.toString()

commit c24cabafd69804b3ac8e2c08895c9b9b9597a7f3
Author: Valentin Kulichenko 
Date:   2016-09-16T21:59:51Z

Merge remote-tracking branch 'community/ignite-1.6.8' into ignite-1.6.8

commit 333cdb6f780e091f8f0e50af46a9ea7727003916
Author: Andrey V. Mashenkov 
Date:   2016-09-19T09:57:36Z

Jvm pid added to startup message




> Output process ID to the log during node start.
> ---
>
> Key: IGNITE-3925
> URL: https://issues.apache.org/jira/browse/IGNITE-3925
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.7
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
>Priority: Minor
> Fix For: 1.8
>
>
> It might be very useful to know process ID of Ignite node. However, we do not 
> output this info to the log. Let's add it.
> I would output it after {{VM total memory}} message.
> Since there is no reliable way to get PID in Java, we do our best to get it, 
> but never throw and error if it is impossible for some reason.
> Start point: {{IgniteKernal.start}} and various {{IgniteKernal.ack*}} 
> methods. 



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

[jira] [Created] (IGNITE-3926) Exception thrown from static job initializer hangs remote future.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3926:
---

 Summary: Exception thrown from static job initializer hangs remote 
future.
 Key: IGNITE-3926
 URL: https://issues.apache.org/jira/browse/IGNITE-3926
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Andrew Mashenkov
 Fix For: 1.8


Test case:
1) Create a job/closure class with static initializer. Throw some exception 
from it (good candidate is {{NoClassDefFoundError}} which simulates a 
dependency which is missing at runtime).
2) Start standalone Ignite node.
3) Try to running a job on this node from remote process.
4) Observe that a future in remote process hangs because the first node fails 
to process error correctly.

Proposed fix:
We need to improve our error handling for our {{GridJobExecuteRequest}}. 
Possibly adding additional try-catch ensuring that no exceptions/errors are 
ignored.



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

[jira] [Created] (IGNITE-3925) Output process ID to the log during node start.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-3925:
---

 Summary: Output process ID to the log during node start.
 Key: IGNITE-3925
 URL: https://issues.apache.org/jira/browse/IGNITE-3925
 Project: Ignite
  Issue Type: Task
  Components: general
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Andrew Mashenkov
Priority: Minor
 Fix For: 1.8


It might be very useful to know process ID of Ignite node. However, we do not 
output this info to the log. Let's add it.

I would output it after {{VM total memory}} message.

Since there is no reliable way to get PID in Java, we do our best to get it, 
but never throw and error if it is impossible for some reason.

Start point: {{IgniteKernal.start}} and various {{IgniteKernal.ack*}} methods. 



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

[jira] [Updated] (IGNITE-500) CacheLoadingConcurrentGridStartSelfTest fails

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-500:
---
Priority: Critical  (was: Major)

> CacheLoadingConcurrentGridStartSelfTest fails
> -
>
> Key: IGNITE-500
> URL: https://issues.apache.org/jira/browse/IGNITE-500
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>Assignee: Anton Vinogradov
>Priority: Critical
>  Labels: Muted_test, important, user-request
> Fix For: 1.8
>
> Attachments: ignite-500.log
>
>
> http://apacheignite.readme.io/v1.0/discuss/550865a8e35e9c3b0083af3e



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

[jira] [Updated] (IGNITE-3922) IGFS: test org.apache.ignite.internal.processors.igfs.IgfsTaskSelfTest hangs on WiFi network

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-3922:

Priority: Critical  (was: Major)

> IGFS: test org.apache.ignite.internal.processors.igfs.IgfsTaskSelfTest hangs 
> on WiFi network
> 
>
> Key: IGNITE-3922
> URL: https://issues.apache.org/jira/browse/IGNITE-3922
> Project: Ignite
>  Issue Type: Bug
>  Components: IGFS
>Affects Versions: 1.7
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Critical
> Fix For: 1.8
>
>
> The following 2 tests frequently hang:
> org.apache.ignite.internal.processors.igfs.IgfsTaskSelfTest#testTask
> org.apache.ignite.internal.processors.igfs.IgfsTaskSelfTest#testTaskAsync
> Also that happens on public TC.
> Thread dump does not show any specific reason of stuck, but it frequently 
> contains stack like this:
> Thread [name="test-runner-#298%igfs.IgfsTaskSelfTest%", id=364, 
> state=RUNNABLE, blockCnt=14, waitCnt=25]
> at java.net.Inet6AddressImpl.getHostByAddr(Native Method)
> at java.net.InetAddress$1.getHostByAddr(InetAddress.java:905)
> at java.net.InetAddress.getHostFromNameService(InetAddress.java:590)
> at java.net.InetAddress.getHostName(InetAddress.java:532)
> at java.net.InetAddress.getHostName(InetAddress.java:504)
> at 
> o.a.i.i.processors.igfs.IgfsBlockLocationImpl.convertFromNodes(IgfsBlockLocationImpl.java:304)
> at 
> o.a.i.i.processors.igfs.IgfsBlockLocationImpl.(IgfsBlockLocationImpl.java:101)
> at 
> o.a.i.i.processors.igfs.IgfsDataManager.splitBlocks(IgfsDataManager.java:895)
> at 
> o.a.i.i.processors.igfs.IgfsDataManager.affinity0(IgfsDataManager.java:862)
> at 
> o.a.i.i.processors.igfs.IgfsDataManager.affinity(IgfsDataManager.java:738)
> at o.a.i.i.processors.igfs.IgfsImpl$18.call(IgfsImpl.java:1216)
> at o.a.i.i.processors.igfs.IgfsImpl$18.call(IgfsImpl.java:1191)
> at o.a.i.i.processors.igfs.IgfsImpl.safeOp(IgfsImpl.java:1679)
> at o.a.i.i.processors.igfs.IgfsImpl.affinity(IgfsImpl.java:1191)
> at o.a.i.igfs.mapreduce.IgfsTask.map(IgfsTask.java:116)
> at o.a.i.igfs.mapreduce.IgfsTask.map(IgfsTask.java:85)
> at 
> o.a.i.i.processors.task.GridTaskWorker$2.call(GridTaskWorker.java:519)
> at 
> o.a.i.i.processors.task.GridTaskWorker$2.call(GridTaskWorker.java:517)
> at o.a.i.i.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6509)
> at 
> o.a.i.i.processors.task.GridTaskWorker.body(GridTaskWorker.java:516)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> o.a.i.i.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:678)
> at 
> o.a.i.i.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:403)
> at 
> o.a.i.i.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:385)
> at o.a.i.i.processors.igfs.IgfsImpl.executeAsync(IgfsImpl.java:1446)
> at o.a.i.i.processors.igfs.IgfsImpl.executeAsync(IgfsImpl.java:1427)
> at o.a.i.i.processors.igfs.IgfsImpl.execute(IgfsImpl.java:1375)
> at 
> o.a.i.i.processors.igfs.IgfsTaskSelfTest.testTask(IgfsTaskSelfTest.java:171)
> 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 
> o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
> at 
> o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
> at 
> o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
> at java.lang.Thread.run(Thread.java:745)
> measurements of method 
> org.apache.ignite.internal.processors.igfs.IgfsBlockLocationImpl#convertFromNodes
>  ,
> duration show the following:
> : 
> ...
> convertFromNodes Took: 39 ms
> convertFromNodes Took: 34 ms
> convertFromNodes Took: 40 ms
> convertFromNodes Took: 32 ms
> convertFromNodes Took: 39 ms
> convertFromNodes Took: 32 ms
> convertFromNodes Took: 32 ms
> convertFromNodes Took: 37 ms
> convertFromNodes Took: 31 ms
> convertFromNodes Took: 31 ms
> convertFromNodes Took: 5067 ms
> convertFromNodes Took: 33 ms
> convertFromNodes Took: 31 ms
> convertFromNodes Took: 137 ms
> convertFromNodes Took: 33 ms
> convertFromNodes Took: 30 ms
> convertFromNodes Took: 41 ms
> convertFromNodes Took: 35 ms
> convertFromNodes 

[jira] [Updated] (IGNITE-3924) .NET: Integrate with Foundatio

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3924:
---
Description: 
Foundatio (https://github.com/exceptionless/Foundatio) wraps multiple 
frameworks (such as Redis) to provide unified interface for building 
distributed applications.

Ignite.NET can provide implementations for modules such as Caching, Queues, 
Messaging, Jobs.

Overview: http://codeopinion.com/in-memory-caching-with-foundatio/

  was:
Foundatio (https://github.com/exceptionless/Foundatio) wraps multiple 
frameworks (such as Redis) to provide unified interface for building 
distributed applications.

Ignite.NET can provide implementations for modules such as Caching, Queues, 
Messaging, Jobs.


> .NET: Integrate with Foundatio
> --
>
> Key: IGNITE-3924
> URL: https://issues.apache.org/jira/browse/IGNITE-3924
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net
> Fix For: 1.8
>
>
> Foundatio (https://github.com/exceptionless/Foundatio) wraps multiple 
> frameworks (such as Redis) to provide unified interface for building 
> distributed applications.
> Ignite.NET can provide implementations for modules such as Caching, Queues, 
> Messaging, Jobs.
> Overview: http://codeopinion.com/in-memory-caching-with-foundatio/



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

[jira] [Created] (IGNITE-3924) .NET: Integrate with Foundatio

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-3924:
--

 Summary: .NET: Integrate with Foundatio
 Key: IGNITE-3924
 URL: https://issues.apache.org/jira/browse/IGNITE-3924
 Project: Ignite
  Issue Type: New Feature
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 1.8


Foundatio (https://github.com/exceptionless/Foundatio) wraps multiple 
frameworks (such as Redis) to provide unified interface for building 
distributed applications.

Ignite.NET can provide implementations for modules such as Caching, Queues, 
Messaging, Jobs.



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

[jira] [Updated] (IGNITE-3924) .NET: Integrate with Foundatio

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-3924:
---
Priority: Minor  (was: Major)

> .NET: Integrate with Foundatio
> --
>
> Key: IGNITE-3924
> URL: https://issues.apache.org/jira/browse/IGNITE-3924
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Priority: Minor
>  Labels: .net
> Fix For: 1.8
>
>
> Foundatio (https://github.com/exceptionless/Foundatio) wraps multiple 
> frameworks (such as Redis) to provide unified interface for building 
> distributed applications.
> Ignite.NET can provide implementations for modules such as Caching, Queues, 
> Messaging, Jobs.



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

[jira] [Updated] (IGNITE-3810) FileSwapSpaceSpi can hang when large value is written

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3810:

Assignee: Semen Boikov  (was: Dmitriy Govorukhin)

> FileSwapSpaceSpi can hang when large value is written
> -
>
> Key: IGNITE-3810
> URL: https://issues.apache.org/jira/browse/IGNITE-3810
> Project: Ignite
>  Issue Type: Bug
>  Components: swap
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Semen Boikov
> Fix For: 1.8
>
> Attachments: SwapSpaceTest.java
>
>
> Test reproducing the issue is attached.
> Weirdly, the value of size {{1024 * 1024 - 48}} is successfully written, but 
> when it is only one byte bigger, the swap space hangs.



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

[jira] [Reopened] (IGNITE-3894) Web console: On import of database Java class/field's names should be valid Java names

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reopened IGNITE-3894:
--

> Web console: On import of database Java class/field's names should be valid 
> Java names
> --
>
> Key: IGNITE-3894
> URL: https://issues.apache.org/jira/browse/IGNITE-3894
> Project: Ignite
>  Issue Type: Sub-task
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
> Fix For: 1.8
>
>
> We should process:
> # java keywords
> # H2 sql keywords
> # Not valid java identifiers (for example starting with number)



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

[jira] [Assigned] (IGNITE-2698) CacheKeyConfiguration is used only with BinaryMarshaller

[Andrey Martianov (JIRA)]

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

Andrey Martianov reassigned IGNITE-2698:


Assignee: Andrey Martianov  (was: Yakov Zhdanov)

> CacheKeyConfiguration is used only with BinaryMarshaller
> 
>
> Key: IGNITE-2698
> URL: https://issues.apache.org/jira/browse/IGNITE-2698
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Andrey Martianov
> Fix For: 1.8
>
>
> Now if CacheKeyConfiguration is specified it is used only with 
> BinaryMarshaller. Need to take it into account with others marshallers as 
> well or update documentation.



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

[jira] [Updated] (IGNITE-3868) ODBC: DSN support for Windows works incorrectly

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-3868:

Assignee: Igor Sapego  (was: Vasilisa  Sidorova)

> ODBC: DSN support for Windows works incorrectly
> ---
>
> Key: IGNITE-3868
> URL: https://issues.apache.org/jira/browse/IGNITE-3868
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Affects Versions: 1.7
> Environment: Win 8, Apache Ignite 1.6.7
>Reporter: Vasilisa  Sidorova
>Assignee: Igor Sapego
>  Labels: odbc
> Fix For: 1.8
>
>
> -
> DESCRIPTION
> -
> Some keys aren't registered in the registry during odbc driver installation 
> and during DSN user data source adding:
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup
> HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version}
> -
> STEPS FOR REPRODUCE
> -
> # Build and install odbc driver according to instruction from product binaries
> # Go to Control Panel\System and Security\Administrative Tools\ODBC Data 
> Source Administrator (or run "odbcad32" command)
> # Try to add Apache Ignite DSN source
> -
> ACTUAL RESULT
> -
> Error message appear. Source isn't adding. There isn't 
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache Ignite\Setup key in the 
> registry
> -
> EXPECTED RESULT
> -
> Source is installed without any exception
> -
> NEXT STEPS FOR REPRODUCE
> -
> # Add HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Apache 
> Ignite\Setup=[path_to_ignite_odbc_driver] into registry
> # Add Apache Ignite DSN source in the ODBC Data Source Administrator
> # Start some cache
> # Run Tableau
> # Try to connect to the cache using DSN
> -
> ACTUAL RESULT
> -
> Connection error message appears. There aren't 
> HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version} keys in the registry
> -
> EXPECTED RESULT
> -
> Connection is successful
> -
> ADDITIONAL INFO
> -
> Keys HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\Apache Ignite 
> DSN\{port,protocol_version} are registered in the registry after user run 
> "Configure" command (without any changes) for Apache Ignite DSN source



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

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

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-3923:


 Summary: Web Console: Summary page - Download button should show 
progress of downloading
 Key: IGNITE-3923
 URL: https://issues.apache.org/jira/browse/IGNITE-3923
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.6
Reporter: Alexey Kuznetsov
 Fix For: 1.8


In case of download large project Summary page is not responsive.
To fix this we should somehow animate "Download progress".



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

[jira] [Assigned] (IGNITE-3917) Web console: Demo project for web console demo not working out of the box.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-3917:


Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: Demo project for web console demo not working out of the box.
> --
>
> Key: IGNITE-3917
> URL: https://issues.apache.org/jira/browse/IGNITE-3917
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 1.8
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> # Generate default url: jdbc:h2:mem:example;DB_CLOSE_DELAY=-1
> # Not work with aliases.
> # Demo should print '>> Demo started' and '>> Demo finished' and H2 server 
> and Ignite should be stopped.



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