[jira] [Assigned] (IGNITE-5239) Web Console: Add an option to show full stack trace on Queries screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-5239:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web Console: Add an option to show full stack trace on Queries screen
> -
>
> Key: IGNITE-5239
> URL: https://issues.apache.org/jira/browse/IGNITE-5239
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
>
> In some situations we need full stack trace to show real error like: 
> {code}
> Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on 
> table "city" violates foreign key constraint "country_capital_fkey" on table 
> "country"
>   Detail: Key (id)=(3503) is still referenced from table "country".
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5239) Web Console: Add an option to show full stack trace on Queries screen

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-5239:
---

{code}
e = {CacheException@4878} "javax.cache.CacheException: class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
execute DML statement [stmt=delete from "WithdataCache".Withdata where _KEY = 
1, params=null]"
 detailMessage = "class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
execute DML statement [stmt=delete from "WithdataCache".Withdata where _KEY = 
1, params=null]"
 cause = {IgniteSQLException@4898} "class 
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
execute DML statement [stmt=delete from "WithdataCache".Withdata where _KEY = 
1, params=null]"
  sqlState = null
  statusCode = 0
  detailMessage = "Failed to execute DML statement [stmt=delete from 
"WithdataCache".Withdata where _KEY = 1, params=null]"
  cause = {CachePartialUpdateCheckedException@4902} "class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]"
   failedKeys = {ArrayList@4904}  size = 1
   topVer = {AffinityTopologyVersion@4905} "AffinityTopologyVersion [topVer=1, 
minorTopVer=0]"
   detailMessage = "Failed to update keys (retry update if possible)."
   cause = {CachePartialUpdateCheckedException@4902} "class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]"
   stackTrace = {StackTraceElement[0]@4899} 
   suppressedExceptions = {ArrayList@4907}  size = 1
0 = {IgniteCheckedException@4911} "class 
org.apache.ignite.IgniteCheckedException: Failed to update keys."
 detailMessage = "Failed to update keys."
 cause = {IgniteCheckedException@4911} "class 
org.apache.ignite.IgniteCheckedException: Failed to update keys."
 stackTrace = {StackTraceElement[0]@4899} 
 suppressedExceptions = {ArrayList@4914}  size = 1
  0 = {IgniteCheckedException@4918} "class 
org.apache.ignite.IgniteCheckedException: Runtime failure on search row: 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@4944f938"
   detailMessage = "Runtime failure on search row: 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@4944f938"
   cause = {IgniteCheckedException@4921} "class 
org.apache.ignite.IgniteCheckedException: Failed to remove value from database 
[table=public.withdata, key=1]"
detailMessage = "Failed to remove value from database 
[table=public.withdata, key=1]"
cause = {CacheWriterException@4925} 
"javax.cache.integration.CacheWriterException: Failed to remove value from 
database [table=public.withdata, key=1]"
 detailMessage = "Failed to remove value from database 
[table=public.withdata, key=1]"
 cause = {PSQLException@4927} "org.postgresql.util.PSQLException: 
ERROR: update or delete on table "withdata" violates foreign key constraint 
"withfk_fk_fkey" on table "withfk"\n  Detail: Key (key)=(1) is still referenced 
from table "withfk"."
  _serverError = {ServerErrorMessage@4930} "ERROR: update or delete on 
table "withdata" violates foreign key constraint "withfk_fk_fkey" on table 
"withfk"\n  Detail: Key (key)=(1) is still referenced from table "withfk"."
  SQLState = "23503"
  vendorCode = 0
  next = null
  detailMessage = "ERROR: update or delete on table "withdata" violates 
foreign key constraint "withfk_fk_fkey" on table "withfk"\n  Detail: Key 
(key)=(1) is still referenced from table "withfk"."
  cause = null
  stackTrace = {StackTraceElement[0]@4899} 
  suppressedExceptions = 
{Collections$UnmodifiableRandomAccessList@4758}  size = 0
 stackTrace = {StackTraceElement[0]@4899} 
 suppressedExceptions = {Collections$UnmodifiableRandomAccessList@4758} 
 size = 0
stackTrace = {StackTraceElement[0]@4899} 
suppressedExceptions = {Collections$UnmodifiableRandomAccessList@4758}  
size = 0
   stackTrace = {StackTraceElement[0]@4899} 
   suppressedExceptions = {Collections$UnmodifiableRandomAccessList@4758}  
size = 0
  stackTrace = {StackTraceElement[0]@4899} 
  suppressedExceptions = {Collections$UnmodifiableRandomAccessList@4758}  size 
= 0
 stackTrace = {StackTraceElement[0]@4899} 
 suppressedExceptions = {Collections$UnmodifiableRandomAccessList@4758}  size = 0
{code}

> Web Console: Add an option to show full stack trace on Queries screen
> -
>
> Key: IGNITE-5239
> URL: https://issues.apache.org/jira/browse/IGNITE-5239
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects 

[jira] [Issue Comment Deleted] (IGNITE-4793) Spark shared RDD example fails

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4793:

Comment: was deleted

(was: No longer reproduced. Most likely cleaning of local .m2 directory helped 
out.)

> Spark shared RDD example fails
> --
>
> Key: IGNITE-4793
> URL: https://issues.apache.org/jira/browse/IGNITE-4793
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9
>Reporter: Denis Magda
>Priority: Critical
>
> Download the latest Apache Ignite 1.9.0 binary and try to start either 
> {{SharedRDDExample}} or {{ScalarSharedRDDExample}}. I'm getting the exception 
> below all the time:
> {code}
> /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/bin/java 
> -Didea.launcher.port=7532 "-Didea.launcher.bin.path=/Applications/IntelliJ 
> IDEA CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath 
> 

[jira] [Updated] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik updated IGNITE-5413:
---
Attachment: 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch

Even more explicit version of the patch.

> Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
> -
>
> Key: IGNITE-5413
> URL: https://issues.apache.org/jira/browse/IGNITE-5413
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: 
> 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch, 
> 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch
>
>
> Apache Ignite is periodically accessing to 
> https://ignite.run/update_status_ignite-plain-text.php
> It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
> of course it has been happening for a long time.
> Corresponding code is 
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82
> Posting JVM env variable (or any other user's specific information) without 
> an explicit user's consent is a bad idea and should be disabled by default. 
> See  
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
> for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5414) Web Console: Model import should use unique indexes if no PK found

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-5414:


 Summary: Web Console: Model import should use unique indexes if no 
PK found
 Key: IGNITE-5414
 URL: https://issues.apache.org/jira/browse/IGNITE-5414
 Project: Ignite
  Issue Type: Task
  Components: wizards
Affects Versions: 1.7
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.1


When import model from RDBMS some tables without primary key could have unique 
index that could be used for key fields generation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik updated IGNITE-5413:
---
Attachment: 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch

Here's the patch to turn this functionality off completely until the time we 
know what and how to deal with this.


> Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
> -
>
> Key: IGNITE-5413
> URL: https://issues.apache.org/jira/browse/IGNITE-5413
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: 
> 0001-IGNITE-5413.-Ignite-shouldn-t-expose-nor-send-clear-.patch
>
>
> Apache Ignite is periodically accessing to 
> https://ignite.run/update_status_ignite-plain-text.php
> It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
> of course it has been happening for a long time.
> Corresponding code is 
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82
> Posting JVM env variable (or any other user's specific information) without 
> an explicit user's consent is a bad idea and should be disabled by default. 
> See  
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
> for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

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

Konstantin Boudnik reassigned IGNITE-5413:
--

Assignee: Konstantin Boudnik

> Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint
> -
>
> Key: IGNITE-5413
> URL: https://issues.apache.org/jira/browse/IGNITE-5413
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.1.4
>Reporter: Konstantin Boudnik
>Assignee: Konstantin Boudnik
>Priority: Blocker
> Fix For: 2.1
>
>
> Apache Ignite is periodically accessing to 
> https://ignite.run/update_status_ignite-plain-text.php
> It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
> of course it has been happening for a long time.
> Corresponding code is 
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82
> Posting JVM env variable (or any other user's specific information) without 
> an explicit user's consent is a bad idea and should be disabled by default. 
> See  
> https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
> for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5239) Web Console: Add an option to show full stack trace on Queries screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-5239:


Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

Please test with various databases.

> Web Console: Add an option to show full stack trace on Queries screen
> -
>
> Key: IGNITE-5239
> URL: https://issues.apache.org/jira/browse/IGNITE-5239
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
> Fix For: 2.1
>
>
> In some situations we need full stack trace to show real error like: 
> {code}
> Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on 
> table "city" violates foreign key constraint "country_capital_fkey" on table 
> "country"
>   Detail: Key (id)=(3503) is still referenced from table "country".
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5413) Ignite shouldn't expose nor send (clear-text) env variables to a 3rd endpoint

[Konstantin Boudnik (JIRA)]

Konstantin Boudnik created IGNITE-5413:
--

 Summary: Ignite shouldn't expose nor send (clear-text) env 
variables to a 3rd endpoint
 Key: IGNITE-5413
 URL: https://issues.apache.org/jira/browse/IGNITE-5413
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.1.4
Reporter: Konstantin Boudnik
Priority: Blocker
 Fix For: 2.1


Apache Ignite is periodically accessing to 
https://ignite.run/update_status_ignite-plain-text.php

It is enabled by default at least in org.apache.ignite:ignite-core:1.9.0, but 
of course it has been happening for a long time.

Corresponding code is 
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/ClusterProcessor.java#L81-L82

Posting JVM env variable (or any other user's specific information) without an 
explicit user's consent is a bad idea and should be disabled by default. 
See  
https://github.com/apache/ignite/blob/1d0b0765134a81e6626a9ef1c70939085f954847/modules/core/src/main/java/org/apache/ignite/internal/processors/cluster/GridUpdateNotifier.java#L313
for more details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5397) JDBC thin driver: clear server cursor automatically when last result piece is transmitted

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5397:
-

[~skalashnikov], as I understand with proposed approach we will have an issue 
with result set metadata. I propose the following approach:
1) For pure DML statements there is not metadata and no result set, so we can 
apply this optimization in a clean and consistent fashion.
2) As far as SQL requests, let's add special flag to connection properties, 
which will manage this behavior. When set to "false" (default), server side 
cursor will not be closed, hence we favor correctness over performance. WHen 
set to "true" it will close server-side cursor, and any call to result set 
metadata will produce {{SQLException}} in cursor is already closed. Let's name 
this flag {{autoCloseServerCursors}}.

> JDBC thin driver: clear server cursor automatically when last result piece is 
> transmitted
> -
>
> Key: IGNITE-5397
> URL: https://issues.apache.org/jira/browse/IGNITE-5397
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: performance
> Fix For: 2.1
>
>
> When last part of result set is sent from the server, we should do the 
> following:
> 1) Clear server-side cursor
> 2) Set special marker on the client side that "cursor" close request is not 
> needed. This way we will save two network hops for typical DML request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5376) JDBC thin: Expose SqlFieldsQuery hints as parameters

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5376:
---

Assignee: Vladimir Ozerov  (was: Taras Ledkov)

> JDBC thin: Expose SqlFieldsQuery hints as parameters
> 
>
> Key: IGNITE-5376
> URL: https://issues.apache.org/jira/browse/IGNITE-5376
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We should expose:
> 1) {{enforceJoinOrder}}
> 2) {{distributedJoins}}
> 3) {{replicatedOnly}}
> 4) {{collocated}}
> As per the rest:
> - {{partitions}} should be avoided for now, as they are very request-specific
> - {{local}} flag cannot be supported for now, as "cacheless" query execution 
> cannot be executed through "local" workflow for now (we cannot determine 
> query parallelism)
> - {{timeout}} - will be handled in another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-5376) JDBC thin: Expose SqlFieldsQuery hints as parameters

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-5376.
-
Resolution: Fixed

> JDBC thin: Expose SqlFieldsQuery hints as parameters
> 
>
> Key: IGNITE-5376
> URL: https://issues.apache.org/jira/browse/IGNITE-5376
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We should expose:
> 1) {{enforceJoinOrder}}
> 2) {{distributedJoins}}
> 3) {{replicatedOnly}}
> 4) {{collocated}}
> As per the rest:
> - {{partitions}} should be avoided for now, as they are very request-specific
> - {{local}} flag cannot be supported for now, as "cacheless" query execution 
> cannot be executed through "local" workflow for now (we cannot determine 
> query parallelism)
> - {{timeout}} - will be handled in another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5376) JDBC thin: Expose SqlFieldsQuery hints as parameters

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5376:

Description: 
We should expose:
1) {{enforceJoinOrder}}
2) {{distributedJoins}}
3) {{replicatedOnly}}
4) {{collocated}}

As per the rest:
- {{partitions}} should be avoided for now, as they are very request-specific
- {{local}} flag cannot be supported for now, as "cacheless" query execution 
cannot be executed through "local" workflow for now (we cannot determine query 
parallelism)
- {{timeout}} - will be handled in another ticket.

  was:
We should expose:
1) {{enforceJoinOrder}}
2) {{distributedJoins}}
3) {{replicatedOnly}}
4) {{collocated}}
5) {{pageSize}}

As per the rest:
- {{partitions}} should be avoided for now, as they are very request-specific
- {{local}} flag cannot be supported for now, as "cacheless" query execution 
cannot be executed through "local" workflow for now (we cannot determine query 
parallelism)
- {{timeout}} - will be handled in another ticket.


> JDBC thin: Expose SqlFieldsQuery hints as parameters
> 
>
> Key: IGNITE-5376
> URL: https://issues.apache.org/jira/browse/IGNITE-5376
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> We should expose:
> 1) {{enforceJoinOrder}}
> 2) {{distributedJoins}}
> 3) {{replicatedOnly}}
> 4) {{collocated}}
> As per the rest:
> - {{partitions}} should be avoided for now, as they are very request-specific
> - {{local}} flag cannot be supported for now, as "cacheless" query execution 
> cannot be executed through "local" workflow for now (we cannot determine 
> query parallelism)
> - {{timeout}} - will be handled in another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5409) JDBC thin: support schema in query string

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5409:

Fix Version/s: (was: 2.1)
   2.2

> JDBC thin: support schema in query string
> -
>
> Key: IGNITE-5409
> URL: https://issues.apache.org/jira/browse/IGNITE-5409
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
> Fix For: 2.2
>
>
> We need to support the following syntax: 
> {{jdbc:ignite:thin://host:port/schema}}. 
> In this case schema should be set to provided name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5408) JDBC driver should not require Class.forName() call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5408:


Github user devozerov closed the pull request at:

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


> JDBC driver should not require Class.forName() call
> ---
>
> Key: IGNITE-5408
> URL: https://issues.apache.org/jira/browse/IGNITE-5408
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
> Instead, it works as follows:
> 1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
> 2) Driver has static initializer which registers itself within 
> {{DriverManager}}.
> We should do that for both think and new thin drivers, and remove all 
> {{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5412) JDBC thin: review ResultSetMetadata implementation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5412:
---

 Summary: JDBC thin: review ResultSetMetadata implementation
 Key: IGNITE-5412
 URL: https://issues.apache.org/jira/browse/IGNITE-5412
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


1) Is it correct?
2) Why do we have muted tests for it?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5408) JDBC driver should not require Class.forName() call

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5408:
---

Assignee: Vladimir Ozerov  (was: Alexander Paschenko)

> JDBC driver should not require Class.forName() call
> ---
>
> Key: IGNITE-5408
> URL: https://issues.apache.org/jira/browse/IGNITE-5408
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
> Instead, it works as follows:
> 1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
> 2) Driver has static initializer which registers itself within 
> {{DriverManager}}.
> We should do that for both think and new thin drivers, and remove all 
> {{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5408) JDBC driver should not require Class.forName() call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5408:


GitHub user devozerov opened a pull request:

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

IGNITE-5408



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

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

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

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


commit ecacd40e3b66270e821d3ba22a08d38c03db9333
Author: devozerov 
Date:   2017-06-05T18:56:42Z

Done for new driver.

commit 394e94992b0f913250c9723b86c9a98c13ae4aab
Author: devozerov 
Date:   2017-06-05T18:59:12Z

Done for old driver.




> JDBC driver should not require Class.forName() call
> ---
>
> Key: IGNITE-5408
> URL: https://issues.apache.org/jira/browse/IGNITE-5408
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
> Instead, it works as follows:
> 1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
> 2) Driver has static initializer which registers itself within 
> {{DriverManager}}.
> We should do that for both think and new thin drivers, and remove all 
> {{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-3562) Dependency to outdated Lucene 3.5.0

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-3562:
--

I've port .Net test to java.
So, it was easy to find a usage of wrong lucene field type as doc uid.


> Dependency to outdated Lucene 3.5.0
> ---
>
> Key: IGNITE-3562
> URL: https://issues.apache.org/jira/browse/IGNITE-3562
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.6
>Reporter: Alexander Veit
>Assignee: Andrew Mashenkov
>  Labels: important
> Fix For: 2.1
>
>
> Ignite 1.6.0 comes with Lucene 3.5.0 core as dependency, which dates back to 
> the year 2011.
> This makes it difficult to integrate with newer software.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5377) ODBC: Expose SqlFieldsQuery hints as parameters

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5377:

Labels: important  (was: )

> ODBC: Expose SqlFieldsQuery hints as parameters
> ---
>
> Key: IGNITE-5377
> URL: https://issues.apache.org/jira/browse/IGNITE-5377
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: important
> Fix For: 2.1
>
>
> Same as for JDBC (IGNITE-5376):
> We should expose:
> 1) {{enforceJoinOrder}}
> 2) {{distributedJoins}}
> 3) {{replicatedOnly}}
> 4) {{collocated}}
> 5) {{pageSize}}
> As per the rest:
> - {{partitions}} should be avoided for now, as they are very request-specific
> - {{local}} flag cannot be supported for now, as "cacheless" query execution 
> cannot be executed through "local" workflow for now (we cannot determine 
> query parallelism)
> - {{timeout}} - will be handled in another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5233:

Fix Version/s: (was: 2.1)
   2.2

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5401) Investigate hangs in JDBC driver testIndexState()

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5401:

Fix Version/s: (was: 2.1)
   2.2

> Investigate hangs in JDBC driver testIndexState()
> -
>
> Key: IGNITE-5401
> URL: https://issues.apache.org/jira/browse/IGNITE-5401
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> Two JDBC tests hang from time to time. Root cause is the same as tests are 
> similar.
> 1) 
> org.apache.ignite.jdbc.thin.JdbcThinDynamicIndexAbstractSelfTest#testIndexState
> 2) 
> org.apache.ignite.internal.jdbc2.JdbcDynamicIndexAbstractSelfTest#testIndexState
> Failures are noly happen in ATOMIC PARTITIONED cache (with and without 
> "near").
> Stack trace:
> {noformat}
> [17:37:00] :   [Step 4/5] Thread 
> [name="test-runner-#22990%thin.JdbcThinDynamicIndexAtomicPartitionedSelfTest%",
>  id=29018, state=WAITING, blockCnt=0, waitCnt=4]
> [17:37:00] :   [Step 4/5] at sun.misc.Unsafe.park(Native Method)
> [17:37:00] :   [Step 4/5] at 
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:315)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:176)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:262)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:780)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:757)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryContext.descriptorForClass(BinaryContext.java:628)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:164)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:248)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:371)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:849)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:799)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1769)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapSingleUpdate(GridNearAtomicSingleUpdateFuture.java:546)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:451)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:440)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1161)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:650)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2329)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.distributed.near.GridNearAtomicCache.put(GridNearAtomicCache.java:444)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2306)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.i.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1494)
> [17:37:00] :   [Step 4/5] at 
> o.a.i.jdbc.thin.JdbcThinDynamicIndexAbstractSelfTest.testIndexState(JdbcThinDynamicIndexAbstractSelfTest.java:273)
> [17:37:00] :   [Step 4/5] at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [17:37:00] :   [Step 4/5] at 
> 

[jira] [Commented] (IGNITE-5400) .NET: IgniteConfiguration.SqlConnectorConfiguration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5400:


Done, waiting for TC: 
http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests_Ignite20Tests=pull%2F2085%2Fhead

> .NET: IgniteConfiguration.SqlConnectorConfiguration
> ---
>
> Key: IGNITE-5400
> URL: https://issues.apache.org/jira/browse/IGNITE-5400
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> We should move new SQL server configuration to .NET once IGNITE-5275 is ready.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5400) .NET: IgniteConfiguration.SqlConnectorConfiguration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5400:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-5400 .NET: IgniteConfiguration.SqlConnectorConfiguration



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

$ git pull https://github.com/ptupitsyn/ignite ignite-5400

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

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


commit c7324b71d25864651ebe5d2336b43db4f5ad8313
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:04:02Z

IGNITE-5400 .NET: IgniteConfiguration.SqlConnectorConfiguration

commit 1dd8b62e623a3effdf80249c44e5407cf476d9bd
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:14:45Z

wip

commit 4b16665d3f23ee1da2338c9967da23f3f1edbea5
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:18:13Z

Config file done

commit 62c248318bfac660c20a0d284935ea54e67a3d9d
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:18:57Z

wip

commit 49134eb74bd872145511f3c3cd8b5f998c30f59e
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:34:49Z

wip thread pool sizes

commit 29a54876f7fe51e20e665ad085609f2bf56f4642
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:37:42Z

wip

commit 261f269d827899e8367054bdb0113bf9cb3033f8
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:40:59Z

wip

commit 9aaeca474e84a01d719ea5252522ba2a1ea58db5
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:44:36Z

wip

commit 405d0a6350791e7f5d8d686c82f6fdb73523709c
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:45:59Z

wip tests

commit 63399bae4ba22f8adc38ef69c7f8889fb62742d2
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:47:43Z

wip

commit 27ab9ddc3dec9ff6b6c1bda3ca30136e5b806e72
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:49:01Z

wip

commit 417fbb64b37ee237de726cfe1067f284aa866362
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:50:40Z

wip tests

commit 7da92ca16e6a5230681e1b24b1192f5d068db0ad
Author: Pavel Tupitsyn 
Date:   2017-06-05T15:51:56Z

wip tests

commit e5566b71e39d8fd034bb34d73e46d7f934d9b00f
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:23:28Z

wip

commit 55cd2d253b3a47b2d5447529d3f8b0632cc2a603
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:24:31Z

java read-write done

commit 0a86fec0804c777a584f584457c756688f0c8400
Author: Pavel Tupitsyn 
Date:   2017-06-05T16:31:36Z

wip

commit 784e03299c413312aab5af5152025abb4656a83f
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:16:34Z

wip

commit 44c12b2be058be502daa17b945146593dbf7513d
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:19:22Z

wip tests

commit 7f57c359c03acc364bfc4c7e4a33ceca41bf384d
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:24:57Z

wip

commit 81d8d43624016b78222b87d44dc9fa8a47d53f15
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:31:37Z

wip

commit d3b9f3879468dfcd03622a05a15067227c87f579
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:42:22Z

Fix default value serialization

commit 5343c943f3f4e5c6a72852f762326d91bb6e8440
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:45:05Z

wip

commit 89187cde6b3314f4f1d33fcbcbe0b3e855ac3da4
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:56:49Z

wip schema

commit 2e97df5f306c9fdab5a0798cdba6796c5873dba4
Author: Pavel Tupitsyn 
Date:   2017-06-05T17:59:48Z

wip schema

commit 63253f46a5a87bb5269fb6fdf0a4955b9f7eb424
Author: Pavel Tupitsyn 
Date:   2017-06-05T18:03:42Z

xsd done

commit a12e8970cbfdb52f2464893cd72d42c7f27d74ab
Author: Pavel Tupitsyn 
Date:   2017-06-05T18:08:08Z

All done




> .NET: IgniteConfiguration.SqlConnectorConfiguration
> ---
>
> Key: IGNITE-5400
> URL: https://issues.apache.org/jira/browse/IGNITE-5400
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> We should move new SQL server configuration to .NET once IGNITE-5275 is ready.



--
This message was 

[jira] [Commented] (IGNITE-5355) Create task with release tools

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5355:


Github user achetaev closed the pull request at:

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


> Create task with release tools
> --
>
> Key: IGNITE-5355
> URL: https://issues.apache.org/jira/browse/IGNITE-5355
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Aleksey Chetaev
>Assignee: Aleksey Chetaev
>
> 1. Create task for auto-generate HTML formatted releases notes



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5410) Invocation of HadoopDataOutStream#write(byte[], int, int) with zero len сauses an AssertionError.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-5410:

Description: 
Writing an array of zero length causes the following AssertionError:

{code}
java.lang.AssertionError: 0
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
...
{code}

Suggested fix is to change the assertion to 
{code} assert size >= 0 : size; {code}

  was:
Writing an array of zero length causes the following AssertionError:

{code}
java.lang.AssertionError: 0
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
...
{code}

Suggested fix is to change the assertion to 
{code} assert size > 0 : size; {code}


> Invocation of HadoopDataOutStream#write(byte[], int, int) with zero len 
> сauses an AssertionError.
> -
>
> Key: IGNITE-5410
> URL: https://issues.apache.org/jira/browse/IGNITE-5410
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 2.1
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Minor
>
> Writing an array of zero length causes the following AssertionError:
> {code}
> java.lang.AssertionError: 0
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
>   at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
> ...
> {code}
> Suggested fix is to change the assertion to 
> {code} assert size >= 0 : size; {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5196) Concurrent modification in .GridDiscoveryManager.nodeCaches

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5196:


GitHub user gvvinblade opened a pull request:

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

IGNITE-5196



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

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

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

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


commit 93ef1c9761df653a8a1019380c8b20ce20827d42
Author: Igor Seliverstov 
Date:   2017-06-05T13:43:07Z

IGNITE-5196




> Concurrent modification in .GridDiscoveryManager.nodeCaches
> ---
>
> Key: IGNITE-5196
> URL: https://issues.apache.org/jira/browse/IGNITE-5196
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> {noformat}
> ./grid149.tar.gz:org.apache.ignite.IgniteCheckedException: null
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7281) 
> ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:171)
>  [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> ./grid149.tar.gz:   at java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_121]
> ./grid149.tar.gz:Caused by: java.util.ConcurrentModificationException: null
> ./grid149.tar.gz:   at 
> java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.HashMap$EntryIterator.next(HashMap.java:1471) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.HashMap$EntryIterator.next(HashMap.java:1469) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.nodeCaches(GridDiscoveryManager.java:1733)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.createNodeBean(GridTopologyCommandHandler.java:219)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHO
> T]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.handleAsync(GridTopologyCommandHandler.java:109)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:265)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:88)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:154)
>  [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5408) JDBC driver should not require Class.forName() call

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-5408:
---

Assignee: Alexander Paschenko

> JDBC driver should not require Class.forName() call
> ---
>
> Key: IGNITE-5408
> URL: https://issues.apache.org/jira/browse/IGNITE-5408
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
> Instead, it works as follows:
> 1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
> 2) Driver has static initializer which registers itself within 
> {{DriverManager}}.
> We should do that for both think and new thin drivers, and remove all 
> {{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5411) Persist affinity key on disk

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5411:

Summary: Persist affinity key on disk  (was: Persist affinity key on disc)

> Persist affinity key on disk
> 
>
> Key: IGNITE-5411
> URL: https://issues.apache.org/jira/browse/IGNITE-5411
> Project: Ignite
>  Issue Type: Task
>  Components: binary
>Reporter: Vladimir Ozerov
> Fix For: 2.1
>
>
> Currently binary metadata is not persisted on a disk anyhow. It means that 
> after full cluster restart we will loose all runtime metadata (except of 
> those configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.
> In future releases we will store metadata in separate storage. For now I 
> propose only to store typeId -> affinityKey mapping on disc to improve value 
> of {{CREATE TABLE}} feature where affinity key is essential for data 
> co-location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5411) Persist affinity key on disk

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5411:

Description: 
Currently binary metadata is not persisted on a disk anyhow. It means that 
after full cluster restart we will loose all runtime metadata (except of those 
configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.

In future releases we will store metadata in separate storage. For now I 
propose only to store typeId -> affinityKey mapping on disk to improve value of 
{{CREATE TABLE}} feature where affinity key is essential for data co-location.

  was:
Currently binary metadata is not persisted on a disk anyhow. It means that 
after full cluster restart we will loose all runtime metadata (except of those 
configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.

In future releases we will store metadata in separate storage. For now I 
propose only to store typeId -> affinityKey mapping on disc to improve value of 
{{CREATE TABLE}} feature where affinity key is essential for data co-location.


> Persist affinity key on disk
> 
>
> Key: IGNITE-5411
> URL: https://issues.apache.org/jira/browse/IGNITE-5411
> Project: Ignite
>  Issue Type: Task
>  Components: binary
>Reporter: Vladimir Ozerov
> Fix For: 2.1
>
>
> Currently binary metadata is not persisted on a disk anyhow. It means that 
> after full cluster restart we will loose all runtime metadata (except of 
> those configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.
> In future releases we will store metadata in separate storage. For now I 
> propose only to store typeId -> affinityKey mapping on disk to improve value 
> of {{CREATE TABLE}} feature where affinity key is essential for data 
> co-location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5411) Persist affinity key on disc

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5411:
---

 Summary: Persist affinity key on disc
 Key: IGNITE-5411
 URL: https://issues.apache.org/jira/browse/IGNITE-5411
 Project: Ignite
  Issue Type: Task
  Components: binary
Reporter: Vladimir Ozerov
 Fix For: 2.1


Currently binary metadata is not persisted on a disk anyhow. It means that 
after full cluster restart we will loose all runtime metadata (except of those 
configured explicitly in {{IgniteConfiguration.binaryConfiguration}}.

In future releases we will store metadata in separate storage. For now I 
propose only to store typeId -> affinityKey mapping on disc to improve value of 
{{CREATE TABLE}} feature where affinity key is essential for data co-location.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5410) Invocation of HadoopDataOutStream#write(byte[], int, int) with zero len сauses an AssertionError.

[Ivan Veselovsky (JIRA)]

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

Ivan Veselovsky updated IGNITE-5410:

Summary: Invocation of HadoopDataOutStream#write(byte[], int, int) with 
zero len сauses an AssertionError.  (was: Invocation of 
HadoopOutputStream.write() with an empty array сauses an AssertionError.)

> Invocation of HadoopDataOutStream#write(byte[], int, int) with zero len 
> сauses an AssertionError.
> -
>
> Key: IGNITE-5410
> URL: https://issues.apache.org/jira/browse/IGNITE-5410
> Project: Ignite
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 2.1
>Reporter: Ivan Veselovsky
>Assignee: Ivan Veselovsky
>Priority: Minor
>
> Writing an array of zero length causes the following AssertionError:
> {code}
> java.lang.AssertionError: 0
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
>   at 
> org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
>   at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
> ...
> {code}
> Suggested fix is to change the assertion to 
> {code} assert size > 0 : size; {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5410) Invocation of HadoopOutputStream.write() with an empty array сauses an AssertionError.

[Ivan Veselovsky (JIRA)]

Ivan Veselovsky created IGNITE-5410:
---

 Summary: Invocation of HadoopOutputStream.write() with an empty 
array сauses an AssertionError.
 Key: IGNITE-5410
 URL: https://issues.apache.org/jira/browse/IGNITE-5410
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 2.1
Reporter: Ivan Veselovsky
Assignee: Ivan Veselovsky
Priority: Minor


Writing an array of zero length causes the following AssertionError:

{code}
java.lang.AssertionError: 0
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopOffheapBuffer.move(HadoopOffheapBuffer.java:95)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.move(HadoopDataOutStream.java:55)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.collections.HadoopMultimapBase$AdderBase$1.move(HadoopMultimapBase.java:206)
at 
org.apache.ignite.internal.processors.hadoop.shuffle.streams.HadoopDataOutStream.write(HadoopDataOutStream.java:70)
at org.apache.hadoop.io.BytesWritable.write(BytesWritable.java:187)
...
{code}

Suggested fix is to change the assertion to 
{code} assert size > 0 : size; {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5380) Validate cache QueryEntities in discovery thread

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5380:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-5380



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

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

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

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


commit 79917bfbc67eefa68d799746158c0d5ab5fcc19f
Author: Alexander Paschenko 
Date:   2017-06-01T15:33:35Z

IGNITE-5380 Query entity conflicts validation - first steps

commit 11736f3623fee692b97246b05854233ea06431c2
Author: Alexander Paschenko 
Date:   2017-06-02T10:02:32Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0bcf86240db99c697f2ae73ae1a472f867862547
Author: Alexander Paschenko 
Date:   2017-06-02T13:02:42Z

Merge remote-tracking branch 'apache/master' into ignite-5380

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

commit 621879d687480428bc375dd7c150712cf400b786
Author: Alexander Paschenko 
Date:   2017-06-02T13:29:41Z

IGNITE-5380 Additional schema wide index name uniqueness check.

commit ac06866faebb5d1f1f8d74ad0e99026e9a5f2264
Author: Alexander Paschenko 
Date:   2017-06-02T13:35:49Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit bce568648a6bc2f97bff0e7b36ced8fa08c26aee
Author: Alexander Paschenko 
Date:   2017-06-05T11:45:13Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0ebf6c7cf3e453e15cc8b84ac0dda48e1bf4037e
Author: Alexander Paschenko 
Date:   2017-06-05T15:35:10Z

IGNITE-5380 Tests.

commit 43a50f94dfc2aaf08b209d8d080ead885b5c02a9
Author: Alexander Paschenko 
Date:   2017-06-05T15:35:44Z

Merge remote-tracking branch 'apache/master' into ignite-5380

commit 0c83f340a1351c56d6bedb477cf1e61b05184909
Author: devozerov 
Date:   2017-06-05T15:45:59Z

Review.

commit a8c2ecdd8c340d7b17d193800fbd88c7342828e4
Author: devozerov 
Date:   2017-06-05T15:52:49Z

Review (unwrap issue).

commit 910b6595ce0b6ff8e8a7639e1a8195989d8f22ab
Author: Alexander Paschenko 
Date:   2017-06-05T16:00:39Z

IGNITE-5380 Minor.

commit 8dd7930726deb7f1bcb900e5276ec36b08ea631e
Author: Alexander Paschenko 
Date:   2017-06-05T16:08:55Z

IGNITE-5380 Minor.

commit e0fbf03b552905f1c251baea38fd2934999e7f69
Author: Alexander Paschenko 
Date:   2017-06-05T16:09:26Z

Merge remote-tracking branch 'apache/master' into ignite-5380




> Validate cache QueryEntities in discovery thread
> 
>
> Key: IGNITE-5380
> URL: https://issues.apache.org/jira/browse/IGNITE-5380
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Consider the following case:
> 1) Execute SQL: TABLE Person ...}}
> 2) Then again: TABLE Person ...}}
> Second call will lead to exception in exchange thread and will hang the whole 
> cluster. 
> We need to add validation of {{CacheConfiguration.queryEntities}} wrt to 
> other caches. This check should be performed in discovery thread. Note that 
> we cannot rely on {{GridQueryProcessor}} or {{IgniteH2Indexing}} state, as 
> some cache start requests may already be enqueued to exchange worker. 
> Instead, we should perform cross-cache validation base only on two things:
> 1) {{DynamicCacheDescriptor.cacheCfg}}
> 2) {{DynamicCacheDescriptor.schema}}
> That is, we should resolve cache schema name from configuration, tables and 
> indexes from schema, and then cross-validate them with other caches.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5409) JDBC thin: support schema in query string

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5409:
---

 Summary: JDBC thin: support schema in query string
 Key: IGNITE-5409
 URL: https://issues.apache.org/jira/browse/IGNITE-5409
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


We need to support the following syntax: 
{{jdbc:ignite:thin://host:port/schema}}. 

In this case schema should be set to provided name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5233:
---

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5233:
---

Assignee: Vladimir Ozerov  (was: Taras Ledkov)

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5379) JDBC thin: get rid of cache name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5379:


Github user devozerov closed the pull request at:

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


> JDBC thin: get rid of cache name
> 
>
> Key: IGNITE-5379
> URL: https://issues.apache.org/jira/browse/IGNITE-5379
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> JDBC driver should not depend on cache name anyhow. We should remove it form 
> configuration, and use {{GridQueryProcessor.querySqlFieldsNoCache}} method to 
> start query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5126) Support batches for thin client based JDBC driver

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5126:

Fix Version/s: (was: 2.1)
   2.2

> Support batches for thin client based JDBC driver
> -
>
> Key: IGNITE-5126
> URL: https://issues.apache.org/jira/browse/IGNITE-5126
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 1.9
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> Support batches operations for the thin client based JDBC driver:
> https://apacheignite.readme.io/docs/jdbc-driver#hostname-based-jdbc-connection



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5376) JDBC thin: Expose SqlFieldsQuery hints as parameters

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5376:
---

Assignee: Taras Ledkov

> JDBC thin: Expose SqlFieldsQuery hints as parameters
> 
>
> Key: IGNITE-5376
> URL: https://issues.apache.org/jira/browse/IGNITE-5376
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> We should expose:
> 1) {{enforceJoinOrder}}
> 2) {{distributedJoins}}
> 3) {{replicatedOnly}}
> 4) {{collocated}}
> 5) {{pageSize}}
> As per the rest:
> - {{partitions}} should be avoided for now, as they are very request-specific
> - {{local}} flag cannot be supported for now, as "cacheless" query execution 
> cannot be executed through "local" workflow for now (we cannot determine 
> query parallelism)
> - {{timeout}} - will be handled in another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5379) JDBC thin: get rid of cache name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5379:


GitHub user devozerov opened a pull request:

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

IGNITE-5379



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

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

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

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


commit ae8a40e56b4c95babd705e51f0412e9278281ceb
Author: devozerov 
Date:   2017-06-05T15:13:23Z

Done.




> JDBC thin: get rid of cache name
> 
>
> Key: IGNITE-5379
> URL: https://issues.apache.org/jira/browse/IGNITE-5379
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> JDBC driver should not depend on cache name anyhow. We should remove it form 
> configuration, and use {{GridQueryProcessor.querySqlFieldsNoCache}} method to 
> start query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5400) .NET: IgniteConfiguration.SqlConnectorConfiguration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5400:
---
Summary: .NET: IgniteConfiguration.SqlConnectorConfiguration  (was: Migrate 
new SQL configuration to .NET)

> .NET: IgniteConfiguration.SqlConnectorConfiguration
> ---
>
> Key: IGNITE-5400
> URL: https://issues.apache.org/jira/browse/IGNITE-5400
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> We should move new SQL server configuration to .NET once IGNITE-5275 is ready.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5400) Migrate new SQL configuration to .NET

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-5400:
--

Assignee: Pavel Tupitsyn

> Migrate new SQL configuration to .NET
> -
>
> Key: IGNITE-5400
> URL: https://issues.apache.org/jira/browse/IGNITE-5400
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> We should move new SQL server configuration to .NET once IGNITE-5275 is ready.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-5308) .NET: Add "schema" property to SqlFieldsQuery

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-5308.

Resolution: Fixed

> .NET: Add "schema" property to SqlFieldsQuery
> -
>
> Key: IGNITE-5308
> URL: https://issues.apache.org/jira/browse/IGNITE-5308
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> Implement new properties from IGNITE-5307.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5308) .NET: Add "schema" property to SqlFieldsQuery

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5308:


Merged to master: {{3642d6c0de956cf8556eb9b31bea4e5b6cf738d1}}

> .NET: Add "schema" property to SqlFieldsQuery
> -
>
> Key: IGNITE-5308
> URL: https://issues.apache.org/jira/browse/IGNITE-5308
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> Implement new properties from IGNITE-5307.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5379) JDBC thin: get rid of cache name

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5379:
---

Assignee: Vladimir Ozerov

> JDBC thin: get rid of cache name
> 
>
> Key: IGNITE-5379
> URL: https://issues.apache.org/jira/browse/IGNITE-5379
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> JDBC driver should not depend on cache name anyhow. We should remove it form 
> configuration, and use {{GridQueryProcessor.querySqlFieldsNoCache}} method to 
> start query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-5275) Create SQL listener configuration based on OdbcConfiguration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov resolved IGNITE-5275.
-
Resolution: Fixed

> Create SQL listener configuration based on OdbcConfiguration
> 
>
> Key: IGNITE-5275
> URL: https://issues.apache.org/jira/browse/IGNITE-5275
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We need to introduce new configuration API which will be applicable for both 
> ODBC and JDBC drivers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (IGNITE-5275) Create SQL listener configuration based on OdbcConfiguration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reopened IGNITE-5275:
-

> Create SQL listener configuration based on OdbcConfiguration
> 
>
> Key: IGNITE-5275
> URL: https://issues.apache.org/jira/browse/IGNITE-5275
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We need to introduce new configuration API which will be applicable for both 
> ODBC and JDBC drivers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5275) Create SQL listener configuration based on OdbcConfiguration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5275:


Github user devozerov closed the pull request at:

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


> Create SQL listener configuration based on OdbcConfiguration
> 
>
> Key: IGNITE-5275
> URL: https://issues.apache.org/jira/browse/IGNITE-5275
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We need to introduce new configuration API which will be applicable for both 
> ODBC and JDBC drivers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5397) JDBC thin driver: clear server cursor automatically when last result piece is transmitted

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-5397:
--

Assignee: Sergey Kalashnikov  (was: Taras Ledkov)

> JDBC thin driver: clear server cursor automatically when last result piece is 
> transmitted
> -
>
> Key: IGNITE-5397
> URL: https://issues.apache.org/jira/browse/IGNITE-5397
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>  Labels: performance
> Fix For: 2.1
>
>
> When last part of result set is sent from the server, we should do the 
> following:
> 1) Clear server-side cursor
> 2) Set special marker on the client side that "cursor" close request is not 
> needed. This way we will save two network hops for typical DML request.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5308) .NET: Add "schema" property to SqlFieldsQuery

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5308:


LINQ {{QueryOptions}} does not need this property, since LINQ always generates 
queries with schema specified.

> .NET: Add "schema" property to SqlFieldsQuery
> -
>
> Key: IGNITE-5308
> URL: https://issues.apache.org/jira/browse/IGNITE-5308
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
> Fix For: 2.1
>
>
> Implement new properties from IGNITE-5307.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5309) CPP: Add "schema" property to SqlFieldsQuery

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5309:


Github user isapego closed the pull request at:

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


> CPP: Add "schema" property to SqlFieldsQuery
> 
>
> Key: IGNITE-5309
> URL: https://issues.apache.org/jira/browse/IGNITE-5309
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.1
>
>
> Propagate new properties from IGNITE-5307.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5263) ODBC: use schema notion instead of cache name

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5263:


Github user isapego closed the pull request at:

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


> ODBC: use schema notion instead of cache name
> -
>
> Key: IGNITE-5263
> URL: https://issues.apache.org/jira/browse/IGNITE-5263
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, odbc
> Fix For: 2.1
>
>
> We should no longer operate on "cacheName". Instead, we should work with 
> schemas.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5309) CPP: Add "schema" property to SqlFieldsQuery

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5309:


[~isapego] good to merge.

> CPP: Add "schema" property to SqlFieldsQuery
> 
>
> Key: IGNITE-5309
> URL: https://issues.apache.org/jira/browse/IGNITE-5309
> Project: Ignite
>  Issue Type: Task
>  Components: platforms, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.1
>
>
> Propagate new properties from IGNITE-5307.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5239) Web Console: Add an option to show full stack trace on Queries screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-5239:


Assignee: Alexey Kuznetsov

> Web Console: Add an option to show full stack trace on Queries screen
> -
>
> Key: IGNITE-5239
> URL: https://issues.apache.org/jira/browse/IGNITE-5239
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
>
> In some situations we need full stack trace to show real error like: 
> {code}
> Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on 
> table "city" violates foreign key constraint "country_capital_fkey" on table 
> "country"
>   Detail: Key (id)=(3503) is still referenced from table "country".
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5263) ODBC: use schema notion instead of cache name

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5263:


[~isapego] looks good to me.

> ODBC: use schema notion instead of cache name
> -
>
> Key: IGNITE-5263
> URL: https://issues.apache.org/jira/browse/IGNITE-5263
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, odbc
> Fix For: 2.1
>
>
> We should no longer operate on "cacheName". Instead, we should work with 
> schemas.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5263) ODBC: use schema notion instead of cache name

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5263:
-

[~ptupitsyn], please review

> ODBC: use schema notion instead of cache name
> -
>
> Key: IGNITE-5263
> URL: https://issues.apache.org/jira/browse/IGNITE-5263
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, odbc
> Fix For: 2.1
>
>
> We should no longer operate on "cacheName". Instead, we should work with 
> schemas.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-814) Implement Algorithmic Skeletons (a.k.a. Parallelism Patterns) and other Parallelism and Concurrency Abstractions

[Alexei Kaigorodov (JIRA)]

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

Alexei Kaigorodov reassigned IGNITE-814:


Assignee: Alexei Kaigorodov

> Implement Algorithmic Skeletons (a.k.a. Parallelism Patterns) and other 
> Parallelism and Concurrency Abstractions
> 
>
> Key: IGNITE-814
> URL: https://issues.apache.org/jira/browse/IGNITE-814
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Suminda Dharmasena
>Assignee: Alexei Kaigorodov
>
> See: http://en.wikipedia.org/wiki/Algorithmic_skeleton



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5263) ODBC: use schema notion instead of cache name

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5263:
-

[~isapego], I added one more fix. Please check if the problem has gone.

> ODBC: use schema notion instead of cache name
> -
>
> Key: IGNITE-5263
> URL: https://issues.apache.org/jira/browse/IGNITE-5263
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, odbc
> Fix For: 2.1
>
>
> We should no longer operate on "cacheName". Instead, we should work with 
> schemas.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-5233:
--

Waits for [tests 
results|http://195.239.208.174/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2079%2Fhead]

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5263) ODBC: use schema notion instead of cache name

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5263:
-

[~vozerov], previous issue is fixed, but now I get NPE in several tests (much 
less number of tests):
{noformat}
Failed to fetch SQL query result [reqId=5, req=OdbcQueryFetchRequest 
[queryId=1, pageSize=1024]]
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.isPreloadingActive(GridReduceQueryExecutor.java:353)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:577)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1160)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:95)
at 
org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.fetchQuery(OdbcRequestHandler.java:251)
at 
org.apache.ignite.internal.processors.odbc.odbc.OdbcRequestHandler.handle(OdbcRequestHandler.java:120)
at 
org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:152)
at 
org.apache.ignite.internal.processors.odbc.SqlListenerNioListener.onMessage(SqlListenerNioListener.java:44)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
Following tests are failing:
- TestCurrentDate
- TestCurdate
- TestCurrentTime
- TestCurtime
- TestCurrentTimestamp
- TestOperatorLessInt
- TestOperatorLessDouble
- TestEscConvertFunctionDouble
- TestEscConvertFunctionFloat

> ODBC: use schema notion instead of cache name
> -
>
> Key: IGNITE-5263
> URL: https://issues.apache.org/jira/browse/IGNITE-5263
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>  Labels: cpp, odbc
> Fix For: 2.1
>
>
> We should no longer operate on "cacheName". Instead, we should work with 
> schemas.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5408) JDBC driver should not require Class.forName() call

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5408:
---

 Summary: JDBC driver should not require Class.forName() call
 Key: IGNITE-5408
 URL: https://issues.apache.org/jira/browse/IGNITE-5408
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
 Fix For: 2.1


Modern JDBC drivers do not require explicit init through {{Class.forName}}. 
Instead, it works as follows:
1) {{java.sql.Driver}} file is created under {{META-INF/services}} directory.
2) Driver has static initializer which registers itself within 
{{DriverManager}}.

We should do that for both think and new thin drivers, and remove all 
{{Class.forName}} calls from tests afterwards.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5275) Create SQL listener configuration based on OdbcConfiguration

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5275:


GitHub user devozerov opened a pull request:

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

IGNITE-5275



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

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

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

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


commit 87d86a15ef26b74ae08c5f5a042c493ba963dda4
Author: devozerov 
Date:   2017-06-04T07:19:58Z

WIP.

commit 31205503d8f4eef72955aae19aa28ae448fc84c1
Author: devozerov 
Date:   2017-06-04T07:40:49Z

Created configuration bean.

commit 0bc5708b16ffb53848abc2ad4a40e6fde6782134
Author: devozerov 
Date:   2017-06-05T08:15:33Z

Merge branch 'master' into ignite-5275

commit c950aba8063c34c2046d699feb49673be9d605e6
Author: devozerov 
Date:   2017-06-05T10:18:02Z

Added connector configuration.

commit 954aaae5f1eb62ba7550c3fad1cf9bc0c7cfb511
Author: devozerov 
Date:   2017-06-05T10:36:57Z

Implemented ODBC -> SQL config conversion.

commit 3fd27fb2fbd844487c98a91791aad5b3835b2226
Author: devozerov 
Date:   2017-06-05T10:54:10Z

Added validation.

commit 4af1d1dee67a52934492ec023d219d56b784c126
Author: devozerov 
Date:   2017-06-05T10:54:50Z

Minors.

commit e89c0405b695a2b3c710dabfd536b4e4efe276cd
Author: devozerov 
Date:   2017-06-05T11:06:11Z

WIP.

commit d7e1c315e9ad63b68fc07046c7e4c1ec16a90fd8
Author: devozerov 
Date:   2017-06-05T11:07:35Z

Last class left: SqlListenerProcessorValidationSelfTest.

commit 6768a9ac8edc642f89b8939d411265c7e830abd3
Author: devozerov 
Date:   2017-06-05T11:20:43Z

WIP on tests.

commit b4dede2e18dc8b4dc5f82639158f649f548c2490
Author: devozerov 
Date:   2017-06-05T11:47:40Z

WIP on tests.

commit e598b20b47c5c3eafa2c3f39cacaf077aaae76aa
Author: devozerov 
Date:   2017-06-05T11:47:57Z

WIP.

commit 254a5a1cef52b3a228013c5d9ae0b1ce67c02ede
Author: devozerov 
Date:   2017-06-05T12:04:04Z

Tests.

commit bdf4bdadf147167fe4c6a4bd4584294a00b0a5c4
Author: devozerov 
Date:   2017-06-05T12:04:14Z

WIP.




> Create SQL listener configuration based on OdbcConfiguration
> 
>
> Key: IGNITE-5275
> URL: https://issues.apache.org/jira/browse/IGNITE-5275
> Project: Ignite
>  Issue Type: Task
>  Components: odbc, sql
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
> Fix For: 2.1
>
>
> We need to introduce new configuration API which will be applicable for both 
> ODBC and JDBC drivers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5233:


GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-5233: JDBC thin Driver: implement metadata support 



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

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

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

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


commit b5c48680feb029c614557b457dc4e6451ca20f2d
Author: tledkov-gridgain 
Date:   2017-06-02T15:32:04Z

IGNITE-5233: save the progress

commit 06edb3ea591382aae22b73e0012edb166c022b55
Author: tledkov-gridgain 
Date:   2017-06-02T15:51:27Z

IGNITE-5233: save the progress

commit a50df0b490cf4972079fb90e0d0c593cf03e670c
Author: tledkov-gridgain 
Date:   2017-06-05T11:55:19Z

IGNITE-5233: index & params meta

commit 8df35cb890b2c2e88d3dd172c68579bb59bd
Author: tledkov-gridgain 
Date:   2017-06-05T12:06:36Z

Merge branch 'master' into ignite-5233

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




> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5233) JDBC thin Driver: implement metadata support

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-5233:
-
Summary: JDBC thin Driver: implement metadata support   (was: JDBC Driver: 
implement metadata support )

> JDBC thin Driver: implement metadata support 
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5406) VisorExecutorConfiguration and VisorGridConfiguration should use IgniteConfiguration.sqlConnectorConfiguration insread of IgniteConfiguration.odbcConfiguration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5406:

Summary: VisorExecutorConfiguration and VisorGridConfiguration should use 
IgniteConfiguration.sqlConnectorConfiguration insread of 
IgniteConfiguration.odbcConfiguration  (was: VisorExecutorConfiguration and 
VisroGridConfiguration should use IgniteConfiguration.sqlConnectorConfiguration 
insread of IgniteConfiguration.odbcConfiguration)

> VisorExecutorConfiguration and VisorGridConfiguration should use 
> IgniteConfiguration.sqlConnectorConfiguration insread of 
> IgniteConfiguration.odbcConfiguration
> ---
>
> Key: IGNITE-5406
> URL: https://issues.apache.org/jira/browse/IGNITE-5406
> Project: Ignite
>  Issue Type: Bug
>  Components: sql, visor
>Reporter: Vladimir Ozerov
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5402) Errors related to multi-version support

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-5402:
-

 Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)
Fix Version/s: 2.1
Affects Version/s: 2.0

> Errors related to multi-version support
> ---
>
> Key: IGNITE-5402
> URL: https://issues.apache.org/jira/browse/IGNITE-5402
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
>
> 1) eviction policy for server and client is the same, but should be different
> 2) Marshaller on Summary is not changed when version is changed
> on Cluster set version 1.x and set OptimizedMarshaller
> go to Summary and look at preview - it shows Optimized
> change version to 2.0 - look at preview - marshaller is still Optimized



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5402) Errors related to multi-version support

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-5402:
---

Fixed code generation for client near cache.
For marshaller created separated issue IGNITE-5407

> Errors related to multi-version support
> ---
>
> Key: IGNITE-5402
> URL: https://issues.apache.org/jira/browse/IGNITE-5402
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>
> 1) eviction policy for server and client is the same, but should be different
> 2) Marshaller on Summary is not changed when version is changed
> on Cluster set version 1.x and set OptimizedMarshaller
> go to Summary and look at preview - it shows Optimized
> change version to 2.0 - look at preview - marshaller is still Optimized



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5407) Web console: Wrong generation of marshaller on version switch

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-5407:
-

 Summary: Web console: Wrong generation of marshaller on version 
switch
 Key: IGNITE-5407
 URL: https://issues.apache.org/jira/browse/IGNITE-5407
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.0
Reporter: Vasiliy Sisko
 Fix For: 2.1


2) Marshaller on Summary is not changed when version is changed

on Cluster set version 1.x and set OptimizedMarshaller
go to Summary and look at preview - it shows Optimized
change version to 2.0 - look at preview - marshaller is still Optimized



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5196) Concurrent modification in .GridDiscoveryManager.nodeCaches

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-5196:


Assignee: Igor Seliverstov  (was: Semen Boikov)

> Concurrent modification in .GridDiscoveryManager.nodeCaches
> ---
>
> Key: IGNITE-5196
> URL: https://issues.apache.org/jira/browse/IGNITE-5196
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Igor Seliverstov
> Fix For: 2.1
>
>
> {noformat}
> ./grid149.tar.gz:org.apache.ignite.IgniteCheckedException: null
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7281) 
> ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:171)
>  [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> ./grid149.tar.gz:   at java.lang.Thread.run(Thread.java:745) 
> [na:1.8.0_121]
> ./grid149.tar.gz:Caused by: java.util.ConcurrentModificationException: null
> ./grid149.tar.gz:   at 
> java.util.HashMap$HashIterator.nextNode(HashMap.java:1437) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.HashMap$EntryIterator.next(HashMap.java:1471) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> java.util.HashMap$EntryIterator.next(HashMap.java:1469) ~[na:1.8.0_121]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.nodeCaches(GridDiscoveryManager.java:1733)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.createNodeBean(GridTopologyCommandHandler.java:219)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHO
> T]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.handlers.top.GridTopologyCommandHandler.handleAsync(GridTopologyCommandHandler.java:109)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:265)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:88)
>  ~[ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:154)
>  [ignite-core-1.10.3.ea6.jar:2.0.0-SNAPSHOT]
> ./grid149.tar.gz:   ... 4 common frames omitted
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5406) VisorExecutorConfiguration and VisroGridConfiguration should use IgniteConfiguration.sqlConnectorConfiguration insread of IgniteConfiguration.odbcConfiguration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-5406:
-

{{VisorOdbcConfiguration}} should also be replaced with new 
{{VisorSqlConnectorConfiguration}}.

> VisorExecutorConfiguration and VisroGridConfiguration should use 
> IgniteConfiguration.sqlConnectorConfiguration insread of 
> IgniteConfiguration.odbcConfiguration
> ---
>
> Key: IGNITE-5406
> URL: https://issues.apache.org/jira/browse/IGNITE-5406
> Project: Ignite
>  Issue Type: Bug
>  Components: sql, visor
>Reporter: Vladimir Ozerov
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5406) VisorExecutorConfiguration and VisroGridConfiguration should use IgniteConfiguration.sqlConnectorConfiguration insread of IgniteConfiguration.odbcConfiguration

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-5406:
---

 Summary: VisorExecutorConfiguration and VisroGridConfiguration 
should use IgniteConfiguration.sqlConnectorConfiguration insread of 
IgniteConfiguration.odbcConfiguration
 Key: IGNITE-5406
 URL: https://issues.apache.org/jira/browse/IGNITE-5406
 Project: Ignite
  Issue Type: Bug
  Components: sql, visor
Reporter: Vladimir Ozerov
Assignee: Alexey Kuznetsov
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5097:
-

[~daradurvs], yeah, I'm going to do it in the nearest time.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

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

Richa Bali updated IGNITE-5405:
---
Description: 
EvictableEntry has null value for corresponding key.

*SCENARIO:*
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is *removed* from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
*Details of sample project:*
* DemoEntry class containing mId and mTimeUTC as member variables. mId is the 
unique identifier used as key for cache and mTimeUTC is the member variable 
used in DemoComparator.
* DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
* IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
*DemoProject:*
* 10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. 
* Size is set to 5.
* 2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

*Observations:*
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
* "Null value logs.txt": logs when null value scenario occurred.
* "No null value logs.txt": logs when null value scenario didn't occur.


  was:
EvictableEntry has null value for corresponding key.
SCENARIO:
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is removed from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
Details of sample project:
DemoEntry class containing mId and mTimeUTC. mId is the unique identifier used 
as key for cache and mTimeUTC is the member variable used in DemoComparator.
DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
DemoProject:
10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

Observations:
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
"Null value logs.txt": logs when null value scenario occurred.
"No null value logs.txt": logs when null value scenario didn't occur.

Sample project is also attached. 


> Null values in comparator for EvictableEntry
> 
>
> Key: IGNITE-5405
> URL: https://issues.apache.org/jira/browse/IGNITE-5405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Richa Bali
> Attachments: Ignite_Project.7z, No null value logs.txt, Null value 
> logs.txt
>
>
> EvictableEntry has null value for corresponding key.
> *SCENARIO:*
> We cache an object with key as a unique identifier (member variable of the 
> object) and value as the object itself.
> EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.
> Entry is *removed* from cache for some keys but those entries are 
> subsequently passed to comparator with key but null object.
> Sample project is attached.
> *Details of sample project:*
> * DemoEntry class containing mId and mTimeUTC as member variables. mId is the 
> unique identifier used as key for cache and mTimeUTC is the member variable 
> used in DemoComparator.
> * DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
> * IgniteEvictionListener is the listener to check if the entries are evicted.
> Sample run:
> *DemoProject:*
> * 10 entries are added to cache for which the eviction policy used is 
> SortedEvictionPolicy on the basis of DemoComparator. 
> * 

[jira] [Updated] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

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

Richa Bali updated IGNITE-5405:
---
Attachment: (was: Ignite_Project.7z)

> Null values in comparator for EvictableEntry
> 
>
> Key: IGNITE-5405
> URL: https://issues.apache.org/jira/browse/IGNITE-5405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Richa Bali
> Attachments: Ignite_Project.7z, No null value logs.txt, Null value 
> logs.txt
>
>
> EvictableEntry has null value for corresponding key.
> SCENARIO:
> We cache an object with key as a unique identifier (member variable of the 
> object) and value as the object itself.
> EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.
> Entry is removed from cache for some keys but those entries are subsequently 
> passed to comparator with key but null object.
> Sample project is attached.
> Details of sample project:
> DemoEntry class containing mId and mTimeUTC. mId is the unique identifier 
> used as key for cache and mTimeUTC is the member variable used in 
> DemoComparator.
> DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
> IgniteEvictionListener is the listener to check if the entries are evicted.
> Sample run:
> DemoProject:
> 10 entries are added to cache for which the eviction policy used is 
> SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
> 2 of the entries are removed and data in cache is printed.
> Note: Removed keys are not used to fetch the data from cache.
> Observations:
> Sometimes, null value for the key (not null key) is passed to comparator. 
> Since the data used in sample project is limited to 10 entries only, it is 
> not reproducible in all the runs. It occurs sometimes (may be because of 
> asynchronous behavior).
> But if we try to retrieve even the removed value by commenting lines 62-64 of 
> DemoProject, it is usually reproducible.
> Attached are the sample logs where we retrieved only those values that were 
> not removed.
> "Null value logs.txt": logs when null value scenario occurred.
> "No null value logs.txt": logs when null value scenario didn't occur.
> Sample project is also attached. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

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

Richa Bali updated IGNITE-5405:
---
Attachment: No null value logs.txt
Null value logs.txt
Ignite_Project.7z

> Null values in comparator for EvictableEntry
> 
>
> Key: IGNITE-5405
> URL: https://issues.apache.org/jira/browse/IGNITE-5405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Richa Bali
> Attachments: Ignite_Project.7z, Ignite_Project.7z, No null value 
> logs.txt, Null value logs.txt
>
>
> EvictableEntry has null value for corresponding key.
> SCENARIO:
> We cache an object with key as a unique identifier (member variable of the 
> object) and value as the object itself.
> EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.
> Entry is removed from cache for some keys but those entries are subsequently 
> passed to comparator with key but null object.
> Sample project is attached.
> Details of sample project:
> DemoEntry class containing mId and mTimeUTC. mId is the unique identifier 
> used as key for cache and mTimeUTC is the member variable used in 
> DemoComparator.
> DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
> IgniteEvictionListener is the listener to check if the entries are evicted.
> Sample run:
> DemoProject:
> 10 entries are added to cache for which the eviction policy used is 
> SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
> 2 of the entries are removed and data in cache is printed.
> Note: Removed keys are not used to fetch the data from cache.
> Observations:
> Sometimes, null value for the key (not null key) is passed to comparator. 
> Since the data used in sample project is limited to 10 entries only, it is 
> not reproducible in all the runs. It occurs sometimes (may be because of 
> asynchronous behavior).
> But if we try to retrieve even the removed value by commenting lines 62-64 of 
> DemoProject, it is usually reproducible.
> Attached are the sample logs where we retrieved only those values that were 
> not removed.
> "Null value logs.txt": logs when null value scenario occurred.
> "No null value logs.txt": logs when null value scenario didn't occur.
> Sample project is also attached. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

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

Richa Bali updated IGNITE-5405:
---
Attachment: Ignite_Project.7z

> Null values in comparator for EvictableEntry
> 
>
> Key: IGNITE-5405
> URL: https://issues.apache.org/jira/browse/IGNITE-5405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Richa Bali
> Attachments: Ignite_Project.7z, Ignite_Project.7z, No null value 
> logs.txt, Null value logs.txt
>
>
> EvictableEntry has null value for corresponding key.
> SCENARIO:
> We cache an object with key as a unique identifier (member variable of the 
> object) and value as the object itself.
> EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.
> Entry is removed from cache for some keys but those entries are subsequently 
> passed to comparator with key but null object.
> Sample project is attached.
> Details of sample project:
> DemoEntry class containing mId and mTimeUTC. mId is the unique identifier 
> used as key for cache and mTimeUTC is the member variable used in 
> DemoComparator.
> DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
> IgniteEvictionListener is the listener to check if the entries are evicted.
> Sample run:
> DemoProject:
> 10 entries are added to cache for which the eviction policy used is 
> SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
> 2 of the entries are removed and data in cache is printed.
> Note: Removed keys are not used to fetch the data from cache.
> Observations:
> Sometimes, null value for the key (not null key) is passed to comparator. 
> Since the data used in sample project is limited to 10 entries only, it is 
> not reproducible in all the runs. It occurs sometimes (may be because of 
> asynchronous behavior).
> But if we try to retrieve even the removed value by commenting lines 62-64 of 
> DemoProject, it is usually reproducible.
> Attached are the sample logs where we retrieved only those values that were 
> not removed.
> "Null value logs.txt": logs when null value scenario occurred.
> "No null value logs.txt": logs when null value scenario didn't occur.
> Sample project is also attached. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

Richa Bali created IGNITE-5405:
--

 Summary: Null values in comparator for EvictableEntry
 Key: IGNITE-5405
 URL: https://issues.apache.org/jira/browse/IGNITE-5405
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Richa Bali


EvictableEntry has null value for corresponding key.
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is removed from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
Details of sample project:
DemoEntry class containing mId and mTimeUTC. mId is the unique identifier used 
as key for cache and mTimeUTC is the member variable used in DemoComparator.
DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
DemoProject:
10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

Observations:
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
"Null value logs.txt": logs when null value scenario occurred.
"No null value logs.txt": logs when null value scenario didn't occur.

Sample project is also attached. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5405) Null values in comparator for EvictableEntry

[Richa Bali (JIRA)]

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

Richa Bali updated IGNITE-5405:
---
Description: 
EvictableEntry has null value for corresponding key.
SCENARIO:
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is removed from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
Details of sample project:
DemoEntry class containing mId and mTimeUTC. mId is the unique identifier used 
as key for cache and mTimeUTC is the member variable used in DemoComparator.
DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
DemoProject:
10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

Observations:
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
"Null value logs.txt": logs when null value scenario occurred.
"No null value logs.txt": logs when null value scenario didn't occur.

Sample project is also attached. 

  was:
EvictableEntry has null value for corresponding key.
We cache an object with key as a unique identifier (member variable of the 
object) and value as the object itself.
EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.

Entry is removed from cache for some keys but those entries are subsequently 
passed to comparator with key but null object.

Sample project is attached.
Details of sample project:
DemoEntry class containing mId and mTimeUTC. mId is the unique identifier used 
as key for cache and mTimeUTC is the member variable used in DemoComparator.
DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
IgniteEvictionListener is the listener to check if the entries are evicted.

Sample run:
DemoProject:
10 entries are added to cache for which the eviction policy used is 
SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
2 of the entries are removed and data in cache is printed.

Note: Removed keys are not used to fetch the data from cache.

Observations:
Sometimes, null value for the key (not null key) is passed to comparator. Since 
the data used in sample project is limited to 10 entries only, it is not 
reproducible in all the runs. It occurs sometimes (may be because of 
asynchronous behavior).
But if we try to retrieve even the removed value by commenting lines 62-64 of 
DemoProject, it is usually reproducible.

Attached are the sample logs where we retrieved only those values that were not 
removed.
"Null value logs.txt": logs when null value scenario occurred.
"No null value logs.txt": logs when null value scenario didn't occur.

Sample project is also attached. 


> Null values in comparator for EvictableEntry
> 
>
> Key: IGNITE-5405
> URL: https://issues.apache.org/jira/browse/IGNITE-5405
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Richa Bali
>
> EvictableEntry has null value for corresponding key.
> SCENARIO:
> We cache an object with key as a unique identifier (member variable of the 
> object) and value as the object itself.
> EvictionPolicy used is the SortedEvictionPolicy with our custom comparator.
> Entry is removed from cache for some keys but those entries are subsequently 
> passed to comparator with key but null object.
> Sample project is attached.
> Details of sample project:
> DemoEntry class containing mId and mTimeUTC. mId is the unique identifier 
> used as key for cache and mTimeUTC is the member variable used in 
> DemoComparator.
> DemoComparator is used for SortedEvictionPolicy on the basis of mTimeUTC.
> IgniteEvictionListener is the listener to check if the entries are evicted.
> Sample run:
> DemoProject:
> 10 entries are added to cache for which the eviction policy used is 
> SortedEvictionPolicy on the basis of DemoComparator. Size is set to 5.
> 2 of the entries are removed and data in cache is printed.
> Note: Removed keys are not used to fetch the data from cache.
> Observations:

[jira] [Commented] (IGNITE-4636) .NET: Support local collection joins in LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-4636:


I've filed the ticket: IGNITE-5404

If there is no easy way to convert user arrays to {{object[]}} for such 
queries, we should do the following:
1) Leave the implementation as is (local join in compiled query does not work)
2) Add a separate test for this, mark with {{[Ignore("IGNITE-5404")]}}

> .NET: Support local collection joins in LINQ
> 
>
> Key: IGNITE-4636
> URL: https://issues.apache.org/jira/browse/IGNITE-4636
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 1.8
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>  Labels: .NET, LINQ
> Fix For: 2.1
>
>
> LINQ {{IN}} clause is implemented in IGNITE-4425 and maps from 
> {{ICollection.Contains}}.
> However, {{IN}} has some limitations in Ignite, and better alternative is 
> temporary table join:
> https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations
> Example SQL:
> {code}
> new SqlFieldsQuery("select p.name from Person p join table(id bigint = ?) i 
> on p.OrgId = i.id", new object[] { new object[] {1,3}})
> {code}
> Add support in LINQ like this:
> {code}persons.AsCacheQueryable().Join(new[] {1, 3}, p => p.Value.OrgId, x => 
> x, (p, x) => p);{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5404) SQL temp table join does not work with typed arrays

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5404:
--

 Summary: SQL temp table join does not work with typed arrays
 Key: IGNITE-5404
 URL: https://issues.apache.org/jira/browse/IGNITE-5404
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
 Fix For: 2.1


Reproducer:

{code}
Ignite ignite = Ignition.start();

QueryEntity qe = new QueryEntity("java.lang.Integer", 
"java.lang.String");
Collection qes = new ArrayList();
qes.add(qe);
CacheConfiguration ccfg = new 
CacheConfiguration("foo").setQueryEntities(qes);
IgniteCache cache = ignite.createCache(ccfg);

cache.put(1, "1");
cache.put(2, "2");

// Works
// Object[] queryArgs = {new Object[]{1}};

// Does not work
Object[] queryArgs = {new int[]{1}};

SqlFieldsQuery query = new SqlFieldsQuery(
"select _val from string join table (id bigint = ?) i on _key = 
id")
.setArgs(queryArgs);

List all = cache.query(query).getAll();

for (List l : all) {
System.out.println(l.get(0));
}
{code}

Exception:
{code}
SEVERE: Failed to execute local query.
class org.apache.ignite.IgniteCheckedException: Failed to execute SQL query.
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1226)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1278)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1253)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:610)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:478)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:206)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:149)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:147)
at 
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2426)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1308)
at 
org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:729)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$8.iterator(IgniteH2Indexing.java:1493)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.iterator(QueryCursorImpl.java:94)
at 
org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:113)
at TestLocalJoin.main(TestLocalJoin.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: org.h2.jdbc.JdbcSQLException: Data conversion error converting 
"'[I@6bea52d4' (ID BIGINT)"; SQL statement:
SELECT
__Z0._VAL __C0_0
FROM TABLE(ID BIGINT=?1) I__Z1 
 INNER JOIN "foo".STRING __Z0 
 ON TRUE
WHERE __Z0._KEY = I__Z1.ID [22018-195]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.table.Column.convert(Column.java:172)
at org.h2.expression.TableFunction.getTable(TableFunction.java:118)
at org.h2.expression.TableFunction.getValue(TableFunction.java:41)
at org.h2.table.FunctionTable.getValueResultSet(FunctionTable.java:218)
at org.h2.table.FunctionTable.getResult(FunctionTable.java:189)
at org.h2.index.FunctionIndex.find(FunctionIndex.java:50)
at org.h2.index.BaseIndex.find(BaseIndex.java:128)
at org.h2.index.IndexCursor.find(IndexCursor.java:169)
at org.h2.table.TableFilter.next(TableFilter.java:468)
at 
org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
at 

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5097:


[~isapego], as far as I know, you've already worked on the task from the 
beginning.   
Could you port the changes to the CPP platform?

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5403) Test flakily fails

[Stanilovsky Evgeny (JIRA)]

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

Stanilovsky Evgeny updated IGNITE-5403:
---
Attachment: GridDiscoveryManagerAliveCacheSelfTest2.java

> Test flakily fails
> --
>
> Key: IGNITE-5403
> URL: https://issues.apache.org/jira/browse/IGNITE-5403
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Stanilovsky Evgeny
>Priority: Critical
> Attachments: GridDiscoveryManagerAliveCacheSelfTest2.java
>
>
> simple flaky nodes test fails.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5403) Test flakily fails

[Stanilovsky Evgeny (JIRA)]

Stanilovsky Evgeny created IGNITE-5403:
--

 Summary: Test flakily fails
 Key: IGNITE-5403
 URL: https://issues.apache.org/jira/browse/IGNITE-5403
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.9
Reporter: Stanilovsky Evgeny
Priority: Critical


simple flaky nodes test fails.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (IGNITE-5388) Web Console: Support to configuration for Ignite 2.x and Ignite 1.x

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-5388.
--

> Web Console: Support to configuration for Ignite 2.x and Ignite 1.x
> ---
>
> Key: IGNITE-5388
> URL: https://issues.apache.org/jira/browse/IGNITE-5388
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5388) Web Console: Support to configuration for Ignite 2.x and Ignite 1.x

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5388:


Tested.

> Web Console: Support to configuration for Ignite 2.x and Ignite 1.x
> ---
>
> Key: IGNITE-5388
> URL: https://issues.apache.org/jira/browse/IGNITE-5388
> Project: Ignite
>  Issue Type: Bug
>  Components: UI, wizards
>Affects Versions: 2.0
>Reporter: Andrey Novikov
>Assignee: Pavel Konstantinov
> Fix For: 2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5402) Errors related to multi-version support

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-5402:
--

 Summary: Errors related to multi-version support
 Key: IGNITE-5402
 URL: https://issues.apache.org/jira/browse/IGNITE-5402
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov


1) eviction policy for server and client is the same, but should be different
2) Marshaller on Summary is not changed when version is changed

on Cluster set version 1.x and set OptimizedMarshaller
go to Summary and look at preview - it shows Optimized
change version to 2.0 - look at preview - marshaller is still Optimized





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5097:


Got it. Sounds good to me then.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-5097 at 6/5/17 9:31 AM:


[~ptupitsyn],
bq. Not sure though about int<->uint casts. 
It is equivalent of {{<<<}} unsigned left bit-shift operator in Java
This is necessary in the case of negative numbers, otherwise it may provide 
infinite loop. Covered by added unit test.
bq. 1) Does this work for negative values?
Yes it works for negative values, but we shouldn't use it for, because negative 
values always take 5 bytes.
bq. 2) Since we use this thing purely for positive values, should we use uint 
in method signature?
Not sure. I'd prefer not to use {{uint}} for compliance with the Java 
implementation.


was (Author: daradurvs):
[~ptupitsyn],
bq. Not sure though about int<->uint casts. 
It is equivalent of {{>>>}} unsigned right bit-shift operator in Java
This is necessary in the case of negative numbers, otherwise it may provide 
infinite loop. Covered by added unit test.
bq. 1) Does this work for negative values?
Yes it works for negative values, but we shouldn't use it for, because negative 
values always take 5 bytes.
bq. 2) Since we use this thing purely for positive values, should we use uint 
in method signature?
Not sure. I'd prefer not to use {{uint}} for compliance with the Java 
implementation.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-5097 at 6/5/17 9:29 AM:


[~ptupitsyn],
bq. Not sure though about int<->uint casts. 
It is equivalent of {{>>>}} unsigned right bit-shift operator in Java
This is necessary in the case of negative numbers, otherwise it may provide 
infinite loop. Covered by added unit test.
bq. 1) Does this work for negative values?
Yes it works for negative values, but we shouldn't use it for, because negative 
values always take 5 bytes.
bq. 2) Since we use this thing purely for positive values, should we use uint 
in method signature?
Not sure. I'd prefer not to use {{uint}} for compliance with the Java 
implementation.


was (Author: daradurvs):
bq. Not sure though about int<->uint casts. 
It is equivalent of {{>>>}} unsigned right bit-shift operator in Java
This is necessary in the case of negative numbers, otherwise it may provide 
infinite loop. Covered by added unit test.
bq. 1) Does this work for negative values?
Yes it works for negative values, but we shouldn't use it for, because negative 
values always take 5 bytes.
bq. 2) Since we use this thing purely for positive values, should we use uint 
in method signature?
Not sure. I'd prefer not to use {{uint}} for compliance with the Java 
implementation.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5097:


bq. Not sure though about int<->uint casts. 
It is equivalent of {{>>>}} unsigned right bit-shift operator in Java
This is necessary in the case of negative numbers, otherwise it may provide 
infinite loop. Covered by added unit test.
bq. 1) Does this work for negative values?
Yes it works for negative values, but we shouldn't use it for, because negative 
values always take 5 bytes.
bq. 2) Since we use this thing purely for positive values, should we use uint 
in method signature?
Not sure. I'd prefer not to use {{uint}} for compliance with the Java 
implementation.

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (IGNITE-5303) WebConsole configuration wizard doesn't properly handle multiple RDBMS

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-5303:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> WebConsole configuration wizard doesn't properly handle multiple RDBMS
> --
>
> Key: IGNITE-5303
> URL: https://issues.apache.org/jira/browse/IGNITE-5303
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Alexey Kuznetsov
>Priority: Critical
>
> Imagine a use case when cache_A needs to persist data in database_A while 
> cache_B has to be connected with database_B as a part of a single application.
> WebConsole allows importing a schema from both databases but:
> * in a final Spring XML configuration there will be only one data source bean 
> defined.
> * both cache_A and cache_B will use the data source of a database that was 
> used last for the schema importing.
> This is what we need to do:
> * Spring XML and Java configurations must include data source beans for every 
> database that was used for the schema importing.
> * security.properties file must contain a connection URL and credentials for 
> every database.
> * we need to support databases of different and similar vendors. For 
> instance, both database_A and database_B can be MySQL ones or database_B can 
> be based on PostgreSQL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5303) WebConsole configuration wizard doesn't properly handle multiple RDBMS

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-5303:
---

Implemented adding of database name to name of data source.

> WebConsole configuration wizard doesn't properly handle multiple RDBMS
> --
>
> Key: IGNITE-5303
> URL: https://issues.apache.org/jira/browse/IGNITE-5303
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Magda
>Assignee: Vasiliy Sisko
>Priority: Critical
>
> Imagine a use case when cache_A needs to persist data in database_A while 
> cache_B has to be connected with database_B as a part of a single application.
> WebConsole allows importing a schema from both databases but:
> * in a final Spring XML configuration there will be only one data source bean 
> defined.
> * both cache_A and cache_B will use the data source of a database that was 
> used last for the schema importing.
> This is what we need to do:
> * Spring XML and Java configurations must include data source beans for every 
> database that was used for the schema importing.
> * security.properties file must contain a connection URL and credentials for 
> every database.
> * we need to support databases of different and similar vendors. For 
> instance, both database_A and database_B can be MySQL ones or database_B can 
> be based on PostgreSQL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (IGNITE-5097) BinaryMarshaller should write ints in "varint" encoding where it makes sense

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5097:


[~daradurvs], .NET changes look good to me in general, thank you.
Not sure though about {{int}}<->{{uint}} casts. 
1) Does this work for negative values?
2) Since we use this thing purely for positive values, should we use {{uint}} 
in method signature?

> BinaryMarshaller should write ints in "varint" encoding where it makes sense
> 
>
> Key: IGNITE-5097
> URL: https://issues.apache.org/jira/browse/IGNITE-5097
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 2.0
>Reporter: Vladimir Ozerov
>Assignee: Vyacheslav Daradur
>  Labels: important, performance
> Fix For: 2.1
>
>
> There are a lot of places in the code where we write integers for some 
> special purposes. Quite often their value will be vary small, so that 
> applying "varint" format could save a lot of space at the cost of very low 
> additional CPU overhead. 
> Specifically:
> 1) Array/collection/map lengths
> 2) BigDecimal's (usually will save ~6 bytes)
> 3) Strings
> 4) Enum ordinals



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-5323) Move record serializer version from file name to file header

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-5323.
--
Resolution: Fixed

Merged to ignite-5267 branch

> Move record serializer version from file name to file header
> 
>
> Key: IGNITE-5323
> URL: https://issues.apache.org/jira/browse/IGNITE-5323
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>  Labels: important
> Fix For: 2.1
>
>
> Keeping records serializer version in the WAL segment file name makes it hard 
> to implement forward serializer version update because we need to rename 
> files on recovery.
> Instead, we should write serializer version in the file header and use it 
> when reading records.
> We should also add some boilerplate code in order to make it easier to add 
> new serializer versions in the future.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5344) JDBC thin driver: support Statement.closeOnCompletion

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5344:

Summary: JDBC thin driver: support Statement.closeOnCompletion  (was: JDBC 
Driver: support Statement.closeOnCompletion)

> JDBC thin driver: support Statement.closeOnCompletion
> -
>
> Key: IGNITE-5344
> URL: https://issues.apache.org/jira/browse/IGNITE-5344
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5234) JDBC thin driver: support connection and query timeout

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5234:

Summary: JDBC thin driver: support connection and query timeout  (was: JDBC 
Driver: support connection and query timeout)

> JDBC thin driver: support connection and query timeout
> --
>
> Key: IGNITE-5234
> URL: https://issues.apache.org/jira/browse/IGNITE-5234
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5344) JDBC Driver: support Statement.closeOnCompletion

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5344:

Fix Version/s: (was: 2.1)
   2.2

> JDBC Driver: support Statement.closeOnCompletion
> 
>
> Key: IGNITE-5344
> URL: https://issues.apache.org/jira/browse/IGNITE-5344
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (IGNITE-5234) JDBC Driver: support connection and query timeout

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5234:

Fix Version/s: (was: 2.1)
   2.2

> JDBC Driver: support connection and query timeout
> -
>
> Key: IGNITE-5234
> URL: https://issues.apache.org/jira/browse/IGNITE-5234
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (IGNITE-5322) Improve WAL record/iterator structure

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-5322.
--
Resolution: Fixed

> Improve WAL record/iterator structure
> -
>
> Key: IGNITE-5322
> URL: https://issues.apache.org/jira/browse/IGNITE-5322
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>  Labels: important
> Fix For: 2.1
>
>
> Currently, we rely on the WAL files layout and zero-ing to make a decision 
> when to stop the iteration.
> Instead, we should write a WAL Pointer to each record with it's position in 
> the file. This will allow us to verify that we are reading a consistent 
> records sequence and should also remove a requirement for zero-clean WAL 
> segment.
> When iterating over the WAL, we should calculate expected next WAL pointer 
> and check that read pointer is equal to the read. If we found a difference, 
> this means that we encountered a stale segment and can stop the iteration.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)