[jira] [Updated] (IGNITE-3820) Web console: 'undo' apper in wrong section

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-3820:
-
Component/s: wizards

> Web console: 'undo' apper in wrong section
> --
>
> Key: IGNITE-3820
> URL: https://issues.apache.org/jira/browse/IGNITE-3820
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Dmitriy Shabalin
>Priority: Minor
>
> Create a new cache - Save.
> Open Memory section and open Mode drop down list but do not select any item.
> Observing - 'undo' appear in the General section.



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

[jira] [Updated] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4229:
-
Summary: Loading configuration from XML into Web Console for further 
editing  (was: Loading configuration from XML into Console for further editing)

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Kuznetsov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Updated] (IGNITE-4229) Loading configuration from XML into Web Console for further editing

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4229:
-
Component/s: wizards

> Loading configuration from XML into Web Console for further editing
> ---
>
> Key: IGNITE-4229
> URL: https://issues.apache.org/jira/browse/IGNITE-4229
> Project: Ignite
>  Issue Type: Wish
>  Components: wizards
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Kuznetsov
>Priority: Minor
>  Labels: console
>
> It would be great to have ability of loading an external XML into Console as 
> the initial configuration and then get editing.
> At this point it's only allowed to create a configuration from scratch and 
> then export to the XML.



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

[jira] [Updated] (IGNITE-5369) Add possibility to generate alias for primary key in WebConsole

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-5369:
-
Component/s: wizards

> Add possibility to generate alias for primary key in WebConsole
> ---
>
> Key: IGNITE-5369
> URL: https://issues.apache.org/jira/browse/IGNITE-5369
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.0
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Kuznetsov
>
> Add field with alias name for primary key, that wiil be used in 
> QueryEntity.setKeyFieldName



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

[jira] [Commented] (IGNITE-5643) REST API, call cache command without cacheName param - got java.lang.NullPointerException

[Roman Shtykh (JIRA)]

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

Roman Shtykh commented on IGNITE-5643:
--

I think it's fixed by IGNITE-5121

> REST API, call cache command without cacheName param - got 
> java.lang.NullPointerException
> -
>
> Key: IGNITE-5643
> URL: https://issues.apache.org/jira/browse/IGNITE-5643
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: any
>Reporter: Aleksandr
>Priority: Minor
>
> Steps to reproduce:
> 1) start Ignite with REST API enabled
> 2) run:
> curl http://localhost:8080/ignite?cmd=cache
> 3) got on server:
> [18:50:42,296][SEVERE][qtp1985938863-60][GridJettyRestProtocol] Failed to 
> process HTTP request [action=/ignite, req=(GET /ignite?cmd=cache)@359127791 
> org.eclipse.jetty.server.Request@1567daef]
> class org.apache.ignite.IgniteCheckedException: null
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:172)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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:748)
> Caused by: java.lang.NullPointerException
> at 
> java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cache(GridCacheProcessor.java:3439)
> at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler.localCache(GridCacheCommandHandler.java:752)
> at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler.executeCommand(GridCacheCommandHandler.java:716)
> at 
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler.handleAsync(GridCacheCommandHandler.java:582)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:266)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:89)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:155)
> 4) HTTP response body:
> {
>   "successStatus": 1,
>   "error": null,
>   "response": null,
>   "sessionToken": null
> }
> 5) Documentation tells cacheName is optional:
> https://apacheignite.readme.io/docs/rest-api#section-cache-metrics



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

[jira] [Updated] (IGNITE-5476) Web Console: backend API updates for basic configuration

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-5476:
-
Component/s: wizards

> Web Console: backend API updates for basic configuration
> 
>
> Key: IGNITE-5476
> URL: https://issues.apache.org/jira/browse/IGNITE-5476
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>
> New basic layout page will benefit greatly from several change at the backend 
> level:
> 1. Remove caches to clusters two-side relation.
> 2. Add a new API method that will create/update cluster and it's caches. It 
> will accept a {cluster: {...}, caches: [...]} object as parameter and will 
> throw if any of internal create/update operation fails. This will save a lot 
> of involved code that does roughly the same on the frontend.



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

[jira] [Resolved] (IGNITE-1278) Improve schema-import - generate cache configuration for each table

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-1278.
--
Resolution: Won't Fix

Schema import discontinued since ignite-2.0.

> Improve schema-import - generate cache configuration for each table
> ---
>
> Key: IGNITE-1278
> URL: https://issues.apache.org/jira/browse/IGNITE-1278
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Currently schema-import generates only cache type metadata.
> But will be useful optionally to generate separated cache configuration for 
> each table. In this case user will have completely cache configuration with 
> type metadata.



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

[jira] [Closed] (IGNITE-1278) Improve schema-import - generate cache configuration for each table

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-1278.


> Improve schema-import - generate cache configuration for each table
> ---
>
> Key: IGNITE-1278
> URL: https://issues.apache.org/jira/browse/IGNITE-1278
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Currently schema-import generates only cache type metadata.
> But will be useful optionally to generate separated cache configuration for 
> each table. In this case user will have completely cache configuration with 
> type metadata.



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

[jira] [Updated] (IGNITE-1278) Improve schema-import - generate cache configuration for each table

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-1278:
-
Component/s: wizards

> Improve schema-import - generate cache configuration for each table
> ---
>
> Key: IGNITE-1278
> URL: https://issues.apache.org/jira/browse/IGNITE-1278
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
>
> Currently schema-import generates only cache type metadata.
> But will be useful optionally to generate separated cache configuration for 
> each table. In this case user will have completely cache configuration with 
> type metadata.



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

[jira] [Updated] (IGNITE-1201) Create tests for Web Console Agent

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-1201:
-
Component/s: wizards

> Create tests for Web Console Agent
> --
>
> Key: IGNITE-1201
> URL: https://issues.apache.org/jira/browse/IGNITE-1201
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Sergey Evdokimov
>Assignee: Andrey Novikov
> Attachments: ignite-843_4abc9f1_ignite-1201.patch
>
>
> Need tests for Web Control Center Agent. 
> Tests should simulate Web Control Center requests.



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

[jira] [Closed] (IGNITE-2638) "Connection to Ignite Web Agent is not established" form not in focus

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2638.


Fixed in ignite-2.0

> "Connection to Ignite Web Agent is not established" form not in focus
> -
>
> Key: IGNITE-2638
> URL: https://issues.apache.org/jira/browse/IGNITE-2638
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
> Environment: OS X 10.10.5
> Safari 9.0.2 (10601.3.9)
>Reporter: Ilya Suntsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: after.png, before.png
>
>
> Steps for reproduce:
> 1. Stop  ignite-web-agent 
> 2. Go to https://console.gridgain.com/sql/demo
> 3. Click on 'Show security token'
> Result:
> Text in form became blurry. Please look in attachment.



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

[jira] [Updated] (IGNITE-2638) "Connection to Ignite Web Agent is not established" form not in focus

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2638:
-
Fix Version/s: 2.0

> "Connection to Ignite Web Agent is not established" form not in focus
> -
>
> Key: IGNITE-2638
> URL: https://issues.apache.org/jira/browse/IGNITE-2638
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
> Environment: OS X 10.10.5
> Safari 9.0.2 (10601.3.9)
>Reporter: Ilya Suntsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: after.png, before.png
>
>
> Steps for reproduce:
> 1. Stop  ignite-web-agent 
> 2. Go to https://console.gridgain.com/sql/demo
> 3. Click on 'Show security token'
> Result:
> Text in form became blurry. Please look in attachment.



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

[jira] [Resolved] (IGNITE-2638) "Connection to Ignite Web Agent is not established" form not in focus

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2638.
--
Resolution: Fixed

> "Connection to Ignite Web Agent is not established" form not in focus
> -
>
> Key: IGNITE-2638
> URL: https://issues.apache.org/jira/browse/IGNITE-2638
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Affects Versions: 1.6
> Environment: OS X 10.10.5
> Safari 9.0.2 (10601.3.9)
>Reporter: Ilya Suntsov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.0
>
> Attachments: after.png, before.png
>
>
> Steps for reproduce:
> 1. Stop  ignite-web-agent 
> 2. Go to https://console.gridgain.com/sql/demo
> 3. Click on 'Show security token'
> Result:
> Text in form became blurry. Please look in attachment.



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

[jira] [Comment Edited] (IGNITE-1099) Need to cleanup git

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-1099 at 7/4/17 2:06 AM:
--

Vasiliy, did you pushed to master report about branches in Git for closed 
issues?
If, yes, then resolve this issue as fixed and close it.


was (Author: kuaw26):
Vasiliy, did you pushed to master report about branches in Git for closed 
issues?

> Need to cleanup git
> ---
>
> Key: IGNITE-1099
> URL: https://issues.apache.org/jira/browse/IGNITE-1099
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Vasiliy Sisko
>
> * Need to resurrect tool (formerly named JiraBranchesToHtml) that shows up 
> branches for closed tickets in JIRA
> * Need to go through the branches and determine what branches are useless:
> ** ignite-sprint-*
> ** branches with no activity for recent months



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

[jira] [Assigned] (IGNITE-1099) Need to cleanup git

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-1099:


Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

Vasiliy, did you pushed to master report about branches in Git for closed 
issues?

> Need to cleanup git
> ---
>
> Key: IGNITE-1099
> URL: https://issues.apache.org/jira/browse/IGNITE-1099
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Vasiliy Sisko
>
> * Need to resurrect tool (formerly named JiraBranchesToHtml) that shows up 
> branches for closed tickets in JIRA
> * Need to go through the branches and determine what branches are useless:
> ** ignite-sprint-*
> ** branches with no activity for recent months



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

[jira] [Closed] (IGNITE-468) Schema Import utility assigns incorrect java types

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-468.
---

> Schema Import utility assigns incorrect java types
> --
>
> Key: IGNITE-468
> URL: https://issues.apache.org/jira/browse/IGNITE-468
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: sprint-2
> Environment: MySQL DB server
>Reporter: Sergey Kozlov
>Assignee: Alexey Kuznetsov
>
> MySQL Db servers allows follow number data types:
> 1. Unsigned numbers:
> {noformat}
> mysql> create table t1 (a1 tinyint unsigned, a2 tinyint signed, b1 smallint 
> unsigned, b2 smallint signed, c1 mediumint unsigned, c2 mediumint signed,
> d1 int unsigned, d2 int signed, e1 bigint unsigned, e2 bigint signed);
> Query OK, 0 rows affected (0.41 sec)
> {noformat}
> But the utility assigns for unsigned types same type as for signed one, e.g. 
> SmallInt unsigned (0..255) to Java.lang.Byte (-128 ... +127)
> 2.Allow to set for bit columns (limited to 64):
> {noformat}
> mysql> create table t3 (a bit(64));
> Query OK, 0 rows affected (0.49 sec)
> mysql> insert into t3 values(b'0101010');
> Query OK, 1 row affected (0.09 sec)
> mysql> select bin(a) from t3;
> ++
> | bin(a) |
> ++
> | 101010 |
> ++
> 1 row in set (0.02 sec)
> {noformat}



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

[jira] [Resolved] (IGNITE-468) Schema Import utility assigns incorrect java types

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-468.
-
Resolution: Won't Fix

Schema import utility was discontinued since ignite-2.0.
Use Web Console instead.

> Schema Import utility assigns incorrect java types
> --
>
> Key: IGNITE-468
> URL: https://issues.apache.org/jira/browse/IGNITE-468
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: sprint-2
> Environment: MySQL DB server
>Reporter: Sergey Kozlov
>Assignee: Alexey Kuznetsov
>
> MySQL Db servers allows follow number data types:
> 1. Unsigned numbers:
> {noformat}
> mysql> create table t1 (a1 tinyint unsigned, a2 tinyint signed, b1 smallint 
> unsigned, b2 smallint signed, c1 mediumint unsigned, c2 mediumint signed,
> d1 int unsigned, d2 int signed, e1 bigint unsigned, e2 bigint signed);
> Query OK, 0 rows affected (0.41 sec)
> {noformat}
> But the utility assigns for unsigned types same type as for signed one, e.g. 
> SmallInt unsigned (0..255) to Java.lang.Byte (-128 ... +127)
> 2.Allow to set for bit columns (limited to 64):
> {noformat}
> mysql> create table t3 (a bit(64));
> Query OK, 0 rows affected (0.49 sec)
> mysql> insert into t3 values(b'0101010');
> Query OK, 1 row affected (0.09 sec)
> mysql> select bin(a) from t3;
> ++
> | bin(a) |
> ++
> | 101010 |
> ++
> 1 row in set (0.02 sec)
> {noformat}



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

[jira] [Resolved] (IGNITE-2912) Implement support focus out to composite field

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2912.
--
Resolution: Won't Fix

UI will be redesigned. Focus out partially implemented.

> Implement support focus out to composite field
> --
>
> Key: IGNITE-2912
> URL: https://issues.apache.org/jira/browse/IGNITE-2912
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Closed] (IGNITE-2912) Implement support focus out to composite field

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2912.


> Implement support focus out to composite field
> --
>
> Key: IGNITE-2912
> URL: https://issues.apache.org/jira/browse/IGNITE-2912
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Assigned] (IGNITE-2912) Implement support focus out to composite field

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-2912:


Assignee: Alexey Kuznetsov  (was: Dmitriy Shabalin)

> Implement support focus out to composite field
> --
>
> Key: IGNITE-2912
> URL: https://issues.apache.org/jira/browse/IGNITE-2912
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
>




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

[jira] [Updated] (IGNITE-2712) Adjust width for cluster combobox on caches screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2712:
-
Component/s: wizards

> Adjust width for cluster combobox on caches screen
> --
>
> Key: IGNITE-2712
> URL: https://issues.apache.org/jira/browse/IGNITE-2712
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
>
> Create 11 clusters.
> Open Caches screen.
> Drop down clusters combobox.
> Currently in Firefox I see 'Select All ...'  but should 'Selected All (11)'



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

[jira] [Updated] (IGNITE-2114) implemented ability to download configuration as independent logic

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2114:
-
Component/s: wizards

> implemented ability to download configuration as independent logic
> --
>
> Key: IGNITE-2114
> URL: https://issues.apache.org/jira/browse/IGNITE-2114
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-2912) Implement support focus out to composite field

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2912:
-
Component/s: wizards

> Implement support focus out to composite field
> --
>
> Key: IGNITE-2912
> URL: https://issues.apache.org/jira/browse/IGNITE-2912
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
>




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

[jira] [Closed] (IGNITE-2712) Adjust width for cluster combobox on caches screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2712.


> Adjust width for cluster combobox on caches screen
> --
>
> Key: IGNITE-2712
> URL: https://issues.apache.org/jira/browse/IGNITE-2712
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
>
> Create 11 clusters.
> Open Caches screen.
> Drop down clusters combobox.
> Currently in Firefox I see 'Select All ...'  but should 'Selected All (11)'



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

[jira] [Resolved] (IGNITE-2712) Adjust width for cluster combobox on caches screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2712.
--
Resolution: Won't Fix

All dropdowns was redisigned (see IGNITE-5611).

> Adjust width for cluster combobox on caches screen
> --
>
> Key: IGNITE-2712
> URL: https://issues.apache.org/jira/browse/IGNITE-2712
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
>
> Create 11 clusters.
> Open Caches screen.
> Drop down clusters combobox.
> Currently in Firefox I see 'Select All ...'  but should 'Selected All (11)'



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

[jira] [Assigned] (IGNITE-2712) Adjust width for cluster combobox on caches screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-2712:


Assignee: Alexey Kuznetsov

> Adjust width for cluster combobox on caches screen
> --
>
> Key: IGNITE-2712
> URL: https://issues.apache.org/jira/browse/IGNITE-2712
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
>
> Create 11 clusters.
> Open Caches screen.
> Drop down clusters combobox.
> Currently in Firefox I see 'Select All ...'  but should 'Selected All (11)'



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

[jira] [Closed] (IGNITE-2114) implemented ability to download configuration as independent logic

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2114.


> implemented ability to download configuration as independent logic
> --
>
> Key: IGNITE-2114
> URL: https://issues.apache.org/jira/browse/IGNITE-2114
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>




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

[jira] [Resolved] (IGNITE-2114) implemented ability to download configuration as independent logic

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2114.
--
Resolution: Fixed

refactoring download to web workers implemented.

> implemented ability to download configuration as independent logic
> --
>
> Key: IGNITE-2114
> URL: https://issues.apache.org/jira/browse/IGNITE-2114
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>




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

[jira] [Updated] (IGNITE-2114) implemented ability to download configuration as independent logic

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2114:
-
Fix Version/s: 1.9

> implemented ability to download configuration as independent logic
> --
>
> Key: IGNITE-2114
> URL: https://issues.apache.org/jira/browse/IGNITE-2114
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 1.9
>
>




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

[jira] [Resolved] (IGNITE-2055) Implement ability to select version

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov resolved IGNITE-2055.
--
Resolution: Fixed

> Implement ability to select version 
> 
>
> Key: IGNITE-2055
> URL: https://issues.apache.org/jira/browse/IGNITE-2055
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 7vQf7r8.png
>
>




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

[jira] [Closed] (IGNITE-2055) Implement ability to select version

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-2055.


> Implement ability to select version 
> 
>
> Key: IGNITE-2055
> URL: https://issues.apache.org/jira/browse/IGNITE-2055
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 7vQf7r8.png
>
>




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

[jira] [Updated] (IGNITE-2055) Implement ability to select version

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-2055:
-
Fix Version/s: 2.1

> Implement ability to select version 
> 
>
> Key: IGNITE-2055
> URL: https://issues.apache.org/jira/browse/IGNITE-2055
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 7vQf7r8.png
>
>




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

[jira] [Assigned] (IGNITE-2055) Implement ability to select version

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-2055:


Assignee: Alexey Kuznetsov

> Implement ability to select version 
> 
>
> Key: IGNITE-2055
> URL: https://issues.apache.org/jira/browse/IGNITE-2055
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Shabalin
>Assignee: Alexey Kuznetsov
> Fix For: 2.1
>
> Attachments: 7vQf7r8.png
>
>




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

[jira] [Created] (IGNITE-5678) Need to document and test supported and unsupported SQL features

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-5678:
-

 Summary: Need to document and test supported and unsupported SQL 
features
 Key: IGNITE-5678
 URL: https://issues.apache.org/jira/browse/IGNITE-5678
 Project: Ignite
  Issue Type: Task
  Components: documentation, sql
Reporter: Dmitriy Setrakyan
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 2.1


We should provide supported and unsupported feature documentation, similar to 
PostgreSQL: https://www.postgresql.org/docs/devel/static/features.html

We can do the following:
* Have a very detailed documented list of all the supported/unsupported 
features in Ignite SQL engine.
* Once the list is created, ensure that we have sufficient test coverage for 
all the supported features.



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

[jira] [Commented] (IGNITE-5159) Create DDL Example

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5159:
-

[~dmagda]
{{Will you improve it?}}
Yes, sorry. This applies only to {{Organizations}} cache started in non dynamic 
manner, will fix.

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Commented] (IGNITE-5159) Create DDL Example

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5159:
-

[~al.psc]

Makes sense to me. Please document the {{execute}} method then stating that 
Persons table has nothing to do with the Organization cache.

What's about this point?

{{please use a unique name for the primary keys and use them instead of _key. 
Do the same for _val if any.}}

Will you improve it?

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Comment Edited] (IGNITE-5159) Create DDL Example

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-5159 at 7/3/17 11:59 PM:
--

[~dmagda]
* We don't create a table *"in"* any cache just as long as {{CREATE TABLE}} 
actually creates a cache of its own, no exceptions. Organizations' cache is 
used just for the sake of API entry point, nothing else.
* In 2.1, there are following changes: addition of {{PUBLIC}} schema and 
possibility of making queries without referring to cache first. Still, we 
currently don't have public API for "cacheless" queries, therefore, we are 
bound to use some pre-existing cache for API entry point.

Bottom line:
* {{Organizations}} cache (and therefor {{Organizations}} schema) has only 
{{Organizations}} table, nothing else.
* All dynamic tables live in {{PUBLIC}} schema and can't live anywhere else.
* Currently public API entry point for the queries can be only associated with 
a cache, no way around, but this does not imply where resulting table will 
reside.

We are working on "cacheless" queries execution and public API for it, but for 
the moment these things are WIP.


was (Author: al.psc):
[~dmagda]
* We don't create a table *"in"* any cache just as long as {{CREATE TABLE}} 
actually creates a cache of its own, no exceptions. Organizations' cache is 
used just for the sake of API entry point, nothing else.
* In 2.1, there are following changes: addition of {{PUBLIC}} schema and 
possibility of making queries without referring to cache first. Still, we 
currently don't have public API for "cacheless" queries, therefore, we are 
bound to use some pre-existing cache for API entry point.

Bottom line:
* {{Organizations}} cache has only {{Organizations}} table, nothing else.
* All dynamic tables live in {{PUBLIC}} schema and can't live anywhere else.
* Currently public API entry point for the queries can be only associated with 
a cache, no way around, but this does not imply where resulting table will 
reside.

We are working on "cacheless" queries execution and public API for it, but for 
the moment these things are WIP.

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Comment Edited] (IGNITE-5159) Create DDL Example

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko edited comment on IGNITE-5159 at 7/3/17 11:59 PM:
--

[~dmagda]
* We don't create a table *"in"* any cache just as long as {{CREATE TABLE}} 
actually creates a cache of its own, no exceptions. Organizations' cache is 
used just for the sake of API entry point, nothing else.
* In 2.1, there are following changes: addition of {{PUBLIC}} schema and 
possibility of making queries without referring to cache first. Still, we 
currently don't have public API for "cacheless" queries, therefore, we are 
bound to use some pre-existing cache for API entry point.

Bottom line:
* {{Organizations}} cache (and therefore {{Organizations}} schema) has only 
{{Organizations}} table, nothing else.
* All dynamic tables live in {{PUBLIC}} schema and can't live anywhere else.
* Currently public API entry point for the queries can be only associated with 
a cache, no way around, but this does not imply where resulting table will 
reside.

We are working on "cacheless" queries execution and public API for it, but for 
the moment these things are WIP.


was (Author: al.psc):
[~dmagda]
* We don't create a table *"in"* any cache just as long as {{CREATE TABLE}} 
actually creates a cache of its own, no exceptions. Organizations' cache is 
used just for the sake of API entry point, nothing else.
* In 2.1, there are following changes: addition of {{PUBLIC}} schema and 
possibility of making queries without referring to cache first. Still, we 
currently don't have public API for "cacheless" queries, therefore, we are 
bound to use some pre-existing cache for API entry point.

Bottom line:
* {{Organizations}} cache (and therefor {{Organizations}} schema) has only 
{{Organizations}} table, nothing else.
* All dynamic tables live in {{PUBLIC}} schema and can't live anywhere else.
* Currently public API entry point for the queries can be only associated with 
a cache, no way around, but this does not imply where resulting table will 
reside.

We are working on "cacheless" queries execution and public API for it, but for 
the moment these things are WIP.

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Commented] (IGNITE-5159) Create DDL Example

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko commented on IGNITE-5159:
-

[~dmagda]
* We don't create a table *"in"* any cache just as long as {{CREATE TABLE}} 
actually creates a cache of its own, no exceptions. Organizations' cache is 
used just for the sake of API entry point, nothing else.
* In 2.1, there are following changes: addition of {{PUBLIC}} schema and 
possibility of making queries without referring to cache first. Still, we 
currently don't have public API for "cacheless" queries, therefore, we are 
bound to use some pre-existing cache for API entry point.

Bottom line:
* {{Organizations}} cache has only {{Organizations}} table, nothing else.
* All dynamic tables live in {{PUBLIC}} schema and can't live anywhere else.
* Currently public API entry point for the queries can be only associated with 
a cache, no way around, but this does not imply where resulting table will 
reside.

We are working on "cacheless" queries execution and public API for it, but for 
the moment these things are WIP.

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Commented] (IGNITE-5159) Create DDL Example

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5159:
-

[~al.psc], please consider the following:
* {{Person}} table needs to be created in person's cache and not in the 
organization cache. As far as I remember, in the future there will be only one 
table (sql schema) to cache mapping.
* please use a unique name for the primary keys and use them instead of 
{{_key}}. Do the same for {{_val}} if any.

> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[jira] [Created] (IGNITE-5677) Document affinity-related SQL optimizations

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5677:
---

 Summary: Document affinity-related SQL optimizations
 Key: IGNITE-5677
 URL: https://issues.apache.org/jira/browse/IGNITE-5677
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.1


Refer to the ticket below for details on what has been done:
https://issues.apache.org/jira/browse/IGNITE-4509



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

[jira] [Comment Edited] (IGNITE-5532) .NET: Clean up and refactor CacheLinqTest

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5532 at 7/3/17 6:27 PM:


[~GuruStron], not sure about {{.Functions}} part: the difference between 
{{CacheLinqTest.Functions.Misc}} and {{CacheLinqTest.Misc}} is too subtle. I 
would just drop the {{.Functions}} part from all names, it should be clear 
enough.


was (Author: ptupitsyn):
[~GuruStron], not sure about {{.Functions}} partthe difference between 
{{CacheLinqTest.Functions.Misc}} and {{CacheLinqTest.Misc}} is too subtle. I 
would just drop the {{.Functions}} part from all names, it should be clear 
enough.

> .NET: Clean up and refactor CacheLinqTest
> -
>
> Key: IGNITE-5532
> URL: https://issues.apache.org/jira/browse/IGNITE-5532
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ, Tests
> Fix For: 2.2
>
>
> Clean up unit tests for cache {{LINQ}} queries(currently all are placed in 
> one big {{CacheLinqTest}} class with two child classes 
> {{CacheLinqTestSimpleName}} and {{CacheLinqTestSqlEscapeAll}}) - break up 
> into partial classes, move to separate folder.



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

[jira] [Commented] (IGNITE-5532) .NET: Clean up and refactor CacheLinqTest

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5532:


[~GuruStron], not sure about {{.Functions}} partthe difference between 
{{CacheLinqTest.Functions.Misc}} and {{CacheLinqTest.Misc}} is too subtle. I 
would just drop the {{.Functions}} part from all names, it should be clear 
enough.

> .NET: Clean up and refactor CacheLinqTest
> -
>
> Key: IGNITE-5532
> URL: https://issues.apache.org/jira/browse/IGNITE-5532
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ, Tests
> Fix For: 2.2
>
>
> Clean up unit tests for cache {{LINQ}} queries(currently all are placed in 
> one big {{CacheLinqTest}} class with two child classes 
> {{CacheLinqTestSimpleName}} and {{CacheLinqTestSqlEscapeAll}}) - break up 
> into partial classes, move to separate folder.



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

[jira] [Commented] (IGNITE-5532) .NET: Clean up and refactor CacheLinqTest

[Sergey Stronchinskiy (JIRA)]

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

Sergey Stronchinskiy commented on IGNITE-5532:
--

[~ptupitsyn]

Can you please review this? 

> .NET: Clean up and refactor CacheLinqTest
> -
>
> Key: IGNITE-5532
> URL: https://issues.apache.org/jira/browse/IGNITE-5532
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ, Tests
> Fix For: 2.2
>
>
> Clean up unit tests for cache {{LINQ}} queries(currently all are placed in 
> one big {{CacheLinqTest}} class with two child classes 
> {{CacheLinqTestSimpleName}} and {{CacheLinqTestSqlEscapeAll}}) - break up 
> into partial classes, move to separate folder.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5153:


GitHub user isapego opened a pull request:

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

IGNITE-5153 CPP: Introduced "varint" encoding in C++



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

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

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

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


commit 1e1e8432dc936df7c62557575a57c4a159b4bca6
Author: Vyacheslav Daradur 
Date:   2017-05-31T08:41:56Z

ignite-5097: writing arrays length in varint encoding was implemented

commit d162d3e3d9036cddb275b4a3d86b8f5de9795185
Author: daradurvs 
Date:   2017-06-01T18:35:13Z

ignite-5097: doUnsafeWriteUnsignedVarint method was added

commit bfe381b3a7498eb5bebeb25026a43d36656c6041
Author: daradurvs 
Date:   2017-06-04T21:25:48Z

ignite-5097: dotNET - writing arrays length in varint encoding was 
implemented

commit 516fcf41e4e973abf41cdd19acd2c9ea1bfb9445
Author: daradurvs 
Date:   2017-06-04T21:26:00Z

ignite-5097: dotNET - hardcoded hashcode values in the tests were changed 
according to new conditions

commit 51fd311c5775fb7c5801c9588cafbcd842be2a4f
Author: Igor Sapego 
Date:   2017-05-31T14:58:03Z

IGNITE-5153: Initial commit

commit a6dbd043de5d2aa08195ff67cad768fa3337e05e
Author: Igor Sapego 
Date:   2017-05-31T15:32:43Z

IGNITE-5153: Fix for Decimals

commit 302d68d4b8313a9f0e593d711ac22d3ab1534cf8
Author: Igor Sapego 
Date:   2017-07-03T17:53:58Z

IGNITE-5153: Fix for the test configuration




> CPP: BinaryMarshaller should write ints in "varint" encoding where it makes 
> sense
> -
>
> Key: IGNITE-5153
> URL: https://issues.apache.org/jira/browse/IGNITE-5153
> Project: Ignite
>  Issue Type: Sub-task
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Vyacheslav Daradur
>Assignee: Igor Sapego
> Fix For: 2.1
>
>
> Need to implement IGNITE-5097



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

[jira] [Commented] (IGNITE-5576) CPP: Implement Compute::Run() for Ignite C++

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5576:


[~isapego] looks good to me in general, see comment in Upsource.

> CPP: Implement Compute::Run() for Ignite C++
> 
>
> Key: IGNITE-5576
> URL: https://issues.apache.org/jira/browse/IGNITE-5576
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.1
>
>
> Need to implement method {{Compute::Run}} and {{Compute::RunAsync}} for 
> Ignite C++



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

[jira] [Comment Edited] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov edited comment on IGNITE-4908 at 7/3/17 5:18 PM:
--

[~sharpler],
Yes, Ignite.reentrantLock()  is ignite datastructure that stored in system 
cache and uses a pessimistic repeatable read transaction for updates.
IgniteCache.lock() looks like avoids a heavy transaction, but I'm not sure it 
is just a local lock. I would think it is distributed lock. 

How many nodes grid do you try?
What guarantees do you mean? Fairness? Unfair locks seems to have same 
performance as it also uses transactions. 

For now, user doesn't have a distributed lock with relaxed guaranties that 
would work as IgniteCache.lock(), but do not affect cache operations.
So, I've create this ticket to investigate a reason of slowdown and check if 
there is a way to speed up datastructure locks. 

Is there any reason why we can't have an additional implementation for 
datastructure lock based on IgniteCache.lock() with same speed an guarantee?





was (Author: amashenkov):
[~sharpler],
Yes, Ignite.reentrantLock()  is ignite datastructure that stored in system 
cache and uses a pessimistic repeatable read transaction for updates.
IgniteCache.lock() looks like avoids a heavy transaction, but I'm not sure it 
is just a local lock. I would think it is distributed lock. 

How many nodes grid do you try?
What guarantees do you mean? Fairness? Unfair locks seems to have same 
performance as it also uses transactions. 

For now, user doesn't have a distributed lock with relaxed guaranties that 
would work as IgniteCache.lock(), but do not affect cache operations.
So, I create the ticket investigate a reason of slowdown and check if there is 
a way to speed up datastructure locks. 

Is there any reason why we can't have an additional implementation for 
datastructure lock based on IgniteCache.lock() with same speed an guarantee?




> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-4908) Ignite.reentrantLock looks much slower than IgniteCache.lock.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-4908:
--

[~sharpler],
Yes, Ignite.reentrantLock()  is ignite datastructure that stored in system 
cache and uses a pessimistic repeatable read transaction for updates.
IgniteCache.lock() looks like avoids a heavy transaction, but I'm not sure it 
is just a local lock. I would think it is distributed lock. 

How many nodes grid do you try?
What guarantees do you mean? Fairness? Unfair locks seems to have same 
performance as it also uses transactions. 

For now, user doesn't have a distributed lock with relaxed guaranties that 
would work as IgniteCache.lock(), but do not affect cache operations.
So, I create the ticket investigate a reason of slowdown and check if there is 
a way to speed up datastructure locks. 

Is there any reason why we can't have an additional implementation for 
datastructure lock based on IgniteCache.lock() with same speed an guarantee?




> Ignite.reentrantLock looks much slower than IgniteCache.lock.
> -
>
> Key: IGNITE-4908
> URL: https://issues.apache.org/jira/browse/IGNITE-4908
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: 1.8
>Reporter: Andrew Mashenkov
>Assignee: Alexander Menshikov
> Fix For: 2.1
>
>
> We should make a benchmark and investigate this issue.



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

[jira] [Commented] (IGNITE-5576) CPP: Implement Compute::Run() for Ignite C++

[Igor Sapego (JIRA)]

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

Igor Sapego commented on IGNITE-5576:
-

[~ptupitsyn], Can you take a look?

> CPP: Implement Compute::Run() for Ignite C++
> 
>
> Key: IGNITE-5576
> URL: https://issues.apache.org/jira/browse/IGNITE-5576
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.0
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>  Labels: cpp
> Fix For: 2.1
>
>
> Need to implement method {{Compute::Run}} and {{Compute::RunAsync}} for 
> Ignite C++



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

[jira] [Commented] (IGNITE-5159) Create DDL Example

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5159:


GitHub user alexpaschenko opened a pull request:

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

IGNITE-5159 DDL example.



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

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

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

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


commit 75769a64059bef43b8d7ed103563896f96eabe84
Author: Alexander Paschenko 
Date:   2017-07-03T17:08:05Z

IGNITE-5159 DDL example.




> Create DDL Example
> --
>
> Key: IGNITE-5159
> URL: https://issues.apache.org/jira/browse/IGNITE-5159
> Project: Ignite
>  Issue Type: Task
>  Components: examples, sql
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>Priority: Blocker
>  Labels: important
> Fix For: 2.1
>
>
> We need to create a DDL example(s) that will demonstrate the following:
> - caches creation and removal using CREATE and DROP table commands.
> - indexes creation and removal using CREATE and DROP index commands.
> If CREATE SCHEME is supported by 2.1 then its usage should be demonstrated as 
> well.
> The example(s) has to be placed into new "sqlgrid" directory of the examples. 
> `CacheQueryExample` and `CacheQueryDmlExample` have to be moved there as 
> well. 



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

[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=16072717#comment-16072717
 ] 

Vyacheslav Daradur commented on IGNITE-5097:


[~isapego],
I've rebased the branch.

> 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.2
>
>
> 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.4.14#64029)

[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=16072701#comment-16072701
 ] 

Igor Sapego commented on IGNITE-5097:
-

[~daradurvs],
Also, please merge changes from master, cause it's hard to implement C++ on top 
of your ticket, cause its code base is outdated.

> 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.2
>
>
> 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.4.14#64029)

[jira] [Commented] (IGNITE-5532) .NET: Clean up and refactor CacheLinqTest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5532:


GitHub user gurustron opened a pull request:

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

IGNITE-5532 .NET: Clean up and refactor CacheLinqTest



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

$ git pull https://github.com/gurustron/ignite feature/IGNITE-5532

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

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


commit 89ca713cfc1c130958a038a0a3869bd65ecca991
Author: gurustron 
Date:   2017-07-02T18:10:47Z

break up CacheLinqTests class into partial




> .NET: Clean up and refactor CacheLinqTest
> -
>
> Key: IGNITE-5532
> URL: https://issues.apache.org/jira/browse/IGNITE-5532
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Sergey Stronchinskiy
>Assignee: Sergey Stronchinskiy
>Priority: Minor
>  Labels: .NET, LINQ, Tests
> Fix For: 2.2
>
>
> Clean up unit tests for cache {{LINQ}} queries(currently all are placed in 
> one big {{CacheLinqTest}} class with two child classes 
> {{CacheLinqTestSimpleName}} and {{CacheLinqTestSqlEscapeAll}}) - break up 
> into partial classes, move to separate folder.



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

[jira] [Commented] (IGNITE-5671) Collect cache SQL query stats

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-5671:
-

[~yzhdanov], there is already a ticket for this created:
https://issues.apache.org/jira/browse/IGNITE-4757

Could you add your requirements there and close this one as a duplicate?

> Collect cache SQL query stats
> -
>
> Key: IGNITE-5671
> URL: https://issues.apache.org/jira/browse/IGNITE-5671
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>
> # requests processed
> # plans on demand
> # timings
> # result set sizes



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

[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=16072682#comment-16072682
 ] 

Vyacheslav Daradur commented on IGNITE-5097:


[~avinogradov],
Makes sense. Thank you for the note.
I've created a sub-task: IGNITE-5676
I'll implement it soon.  

> 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.2
>
>
> 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.4.14#64029)

[jira] [Created] (IGNITE-5676) Provide compatibility property to allow to keep data in old format

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-5676:
--

 Summary: Provide compatibility property to allow to keep data in 
old format
 Key: IGNITE-5676
 URL: https://issues.apache.org/jira/browse/IGNITE-5676
 Project: Ignite
  Issue Type: Sub-task
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
 Fix For: 2.2






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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-5097:
--

[~daradurvs], 
seems you changing storage format, so it will be nice if you'll provide 
compatibility property to allow to keep data in old format. 

> 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.2
>
>
> 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.4.14#64029)

[jira] [Created] (IGNITE-5675) Add ability to detect and report anomalities

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5675:
-

 Summary: Add ability to detect and report anomalities
 Key: IGNITE-5675
 URL: https://issues.apache.org/jira/browse/IGNITE-5675
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# growing (or decreasing) response times
# changes to result sets of queries
# changes to serialized sizes of the objects
# anything else?
# 
Probably, we will need to add automatic reaction on these changes



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

[jira] [Created] (IGNITE-5674) Implement self-check MBean

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5674:
-

 Summary: Implement self-check MBean
 Key: IGNITE-5674
 URL: https://issues.apache.org/jira/browse/IGNITE-5674
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


MBean should provide access to settings management and gathered stats.



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

[jira] [Created] (IGNITE-5673) Collect cache operations stats

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5673:
-

 Summary: Collect cache operations stats
 Key: IGNITE-5673
 URL: https://issues.apache.org/jira/browse/IGNITE-5673
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# update requests processed
# lock, prepare, commit reqeuests processed and their timings



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

[jira] [Created] (IGNITE-5672) Report contended cache keys if any

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5672:
-

 Summary: Report contended cache keys if any
 Key: IGNITE-5672
 URL: https://issues.apache.org/jira/browse/IGNITE-5672
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5671) Collect cache SQL query stats

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5671:
-

 Summary: Collect cache SQL query stats
 Key: IGNITE-5671
 URL: https://issues.apache.org/jira/browse/IGNITE-5671
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# requests processed
# plans on demand
# timings
# result set sizes



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

[jira] [Updated] (IGNITE-5670) Collect high level API calls stats

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5670:
--
Description: 
# tasks sent
# jobs sent
# cache updates sent
# queries sent
# result set size
# timings

  was:
# tasks sent
# jobs sent
# cahce updates sent
# queries sent
# result set size
# timings


> Collect high level API calls stats
> --
>
> Key: IGNITE-5670
> URL: https://issues.apache.org/jira/browse/IGNITE-5670
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>
> # tasks sent
> # jobs sent
> # cache updates sent
> # queries sent
> # result set size
> # timings



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

[jira] [Created] (IGNITE-5670) Collect high level API calls stats

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5670:
-

 Summary: Collect high level API calls stats
 Key: IGNITE-5670
 URL: https://issues.apache.org/jira/browse/IGNITE-5670
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# tasks sent
# jobs sent
# cahce updates sent
# queries sent
# result set size
# timings



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

[jira] [Updated] (IGNITE-5666) Gather time statistics for user objects (de)serialization

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5666:
--
Description: Gather types, sizes and time taken.

> Gather time statistics for user objects (de)serialization
> -
>
> Key: IGNITE-5666
> URL: https://issues.apache.org/jira/browse/IGNITE-5666
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Yakov Zhdanov
>
> Gather types, sizes and time taken.



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

[jira] [Created] (IGNITE-5669) Gather stats for communication queues sizes per node

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5669:
-

 Summary: Gather stats for communication queues sizes per node
 Key: IGNITE-5669
 URL: https://issues.apache.org/jira/browse/IGNITE-5669
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5668) Gather stats for communication messages

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5668:
-

 Summary: Gather stats for communication messages
 Key: IGNITE-5668
 URL: https://issues.apache.org/jira/browse/IGNITE-5668
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


Stats should be collected for "to" and "from" messages.

# message type
# message size
# direct (de)serialization times
# processing times




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

[jira] [Created] (IGNITE-5667) Add ability to enable/disable certain self-check measurements in runtime

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5667:
-

 Summary: Add ability to enable/disable certain self-check 
measurements in runtime
 Key: IGNITE-5667
 URL: https://issues.apache.org/jira/browse/IGNITE-5667
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


Some of the measurements may be resource consuming. It would be good to have an 
opportunity to enable and disable them.

List of features is yet to come.



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

[jira] [Created] (IGNITE-5666) Gather time statistics for user objects (de)serialization

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5666:
-

 Summary: Gather time statistics for user objects (de)serialization
 Key: IGNITE-5666
 URL: https://issues.apache.org/jira/browse/IGNITE-5666
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5665) Implement histogram-like functionality to gather time stats on different operations

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5665:
-

 Summary: Implement histogram-like functionality to gather time 
stats on different operations
 Key: IGNITE-5665
 URL: https://issues.apache.org/jira/browse/IGNITE-5665
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


Idea and examples - https://github.com/HdrHistogram/HdrHistogram





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

[jira] [Updated] (IGNITE-5664) Implement self-check facilities for Ignite

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov updated IGNITE-5664:
--
Description: Self-check should spot and report possible problems in the 
topology - uneven load and data distribution, growing response times, etc. 
Please see sub-tickets for further details.

> Implement self-check facilities for Ignite
> --
>
> Key: IGNITE-5664
> URL: https://issues.apache.org/jira/browse/IGNITE-5664
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>
> Self-check should spot and report possible problems in the topology - uneven 
> load and data distribution, growing response times, etc. Please see 
> sub-tickets for further details.



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

[jira] [Created] (IGNITE-5664) Implement self-check facilities for Ignite

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5664:
-

 Summary: Implement self-check facilities for Ignite
 Key: IGNITE-5664
 URL: https://issues.apache.org/jira/browse/IGNITE-5664
 Project: Ignite
  Issue Type: Task
Reporter: Yakov Zhdanov






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

[jira] [Commented] (IGNITE-5473) Create ignite troubleshooting logger

[Yakov Zhdanov (JIRA)]

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

Yakov Zhdanov commented on IGNITE-5473:
---

[~agoncharuk], it seems this should always be enabled and reported and the task 
is to make it less intrusive.

> Create ignite troubleshooting logger
> 
>
> Key: IGNITE-5473
> URL: https://issues.apache.org/jira/browse/IGNITE-5473
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 2.0
>Reporter: Alexey Goncharuk
>Priority: Critical
>  Labels: important, observability
> Fix For: 2.2
>
>
> Currently, we have two extremes of logging - either INFO wich logs almost 
> nothing, or DEBUG, which will pollute logs with too verbose messages.
> We should create a 'troubleshooting' logger, which should be easily enabled 
> (via a system property, for example) and log all stability-critical node and 
> cluster events:
>  * Connection events (both communication and discovery), handshake status
>  * ALL ignored messages and skipped actions (even those we assume are safe to 
> ignore)
>  * Partition exchange stages and timings
>  * Verbose discovery state changes (this should make it easy to understand 
> the reason for 'Node has not been connected to the topology')
>  * Transaction failover stages and actions
>  * All unlogged exceptions
>  * Responses that took more than N milliseconds when in normal they should 
> return right away
>  * Long discovery SPI messages processing times
>  * Managed service deployment stages
>  * Marshaller mappings registration and notification
>  * Binary metadata registration and notification
>  * Continuous query registration / notification
> (add more)
> The amount of logging should be chosen accurately so that it would be safe to 
> enable this logger in production clusters.



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

[jira] [Commented] (IGNITE-5628) .NET: incorrect jvm.dll lookup paths for JRE

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5628:


Fixed in master: {{5093660d758ad4149d5cd135f3cad3dfee0ae6e4}}

> .NET: incorrect jvm.dll lookup paths for JRE
> 
>
> Key: IGNITE-5628
> URL: https://issues.apache.org/jira/browse/IGNITE-5628
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET
> Fix For: 2.1
>
>
> {{jvm.dll}} is located in different subfolders in JRE and JDK. Current code 
> only accounts for JDK. So if we set {{JAVA_HOME}} to a custom xcopy-deployed 
> JRE folder, jvm.dll can not be found.
> With normal Windows installations it works because we use registry for that.



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

[jira] [Updated] (IGNITE-5661) .NET: serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

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

> .NET: serialization failed when entity has property with IList and equals to 
> null
> -
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>  Labels: .NET
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Updated] (IGNITE-5661) .NET: serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5661:
---
Summary: .NET: serialization failed when entity has property with IList and 
equals to null  (was: .NET serialization failed when entity has property with 
IList and equals to null)

> .NET: serialization failed when entity has property with IList and equals to 
> null
> -
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>  Labels: .NET
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Updated] (IGNITE-5661) .NET: serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5661:
---
Component/s: platforms

> .NET: serialization failed when entity has property with IList and equals to 
> null
> -
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>  Labels: .NET
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Commented] (IGNITE-5661) ignite.NET serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5661:


Hi Chris, 

1) Before filing any bugs in JIRA, please discuss them on user and/or dev lists 
(d...@ignite.apache.org. u...@ignite.apache.org).
2) Please provide a clear reproducer or a unit test (as simple as possible). 
{{DbContext}}, {{CustMainInfo}} classes are not relevant to Ignite or the bug 
itself, I think.

> ignite.NET serialization failed when entity has property with IList and 
> equals to null
> --
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>  Labels: .NET
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Updated] (IGNITE-5661) .NET serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-5661:
---
Summary: .NET serialization failed when entity has property with IList and 
equals to null  (was: ignite.NET serialization failed when entity has property 
with IList and equals to null)

> .NET serialization failed when entity has property with IList and equals to 
> null
> 
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>  Labels: .NET
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Created] (IGNITE-5663) ODBC: Few consecutive inserts lead to exception

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5663:
-

 Summary: ODBC: Few consecutive inserts lead to exception
 Key: IGNITE-5663
 URL: https://issues.apache.org/jira/browse/IGNITE-5663
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.8
Reporter: Evgenii Zhuravlev
Assignee: Igor Sapego


Exception: ('HY010', '[HY010] Query is not prepared. (0) (SQLExecDirectW)')

Reproducer in python:


{code:java}
import pyodbc
cnxn = pyodbc.connect(DRIVER='{Apache Ignite}', 
ADDRESS='localhost:10800',CACHE="Person", autocommit=True)
cursor = cnxn.cursor()
select_string= "INSERT INTO Person(_key, id, firstName, lastName, salary) 
VALUES (?, ? , 'abcd', 'dhsagd', 1000)"
id_list = (1,1)
id_list2 = (2,2)
cursor.execute(select_string, id_list) 
cursor.execute(select_string, id_list2) 
{code}

Also, the same behavior with executemany.




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

[jira] [Deleted] (IGNITE-5660) ignite.NET serialization failed when entity has property with IList and equals to null

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn deleted IGNITE-5660:
---


> ignite.NET serialization failed when entity has property with IList and 
> equals to null
> --
>
> Key: IGNITE-5660
> URL: https://issues.apache.org/jira/browse/IGNITE-5660
> Project: Ignite
>  Issue Type: Bug
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:c#}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Updated] (IGNITE-5087) Enum comparison fails after marshal-unmarshal with BinaryMarshaller.

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov updated IGNITE-5087:
-
Component/s: binary

> Enum comparison fails after marshal-unmarshal with BinaryMarshaller.
> 
>
> Key: IGNITE-5087
> URL: https://issues.apache.org/jira/browse/IGNITE-5087
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: Amelchev Nikita
> Fix For: 2.1
>
> Attachments: EnumBinaryMarshallerBug.java
>
>
> PFA repro.
> It fails on 1.9 and on 2.0-snapshot as well.



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

[jira] [Updated] (IGNITE-5662) Primary index name should contain type ID or name

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-5662:
-
Attachment: IgnitePersistentStoreQueryTest.java

> Primary index name should contain type ID or name
> -
>
> Key: IGNITE-5662
> URL: https://issues.apache.org/jira/browse/IGNITE-5662
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
> Fix For: 2.1
>
> Attachments: IgnitePersistentStoreQueryTest.java
>
>
> Currently, the primary index name contains neither type ID nor type name. 
> Since metadata storage allocates tree root based on the index name, two 
> different indexes will be using the same index tree.
> Attached test reproduces this issue.
> A correct fix would be to include type ID or type name (depends on the 
> current SQL internals) to the index name.



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

[jira] [Created] (IGNITE-5662) Primary index name should contain type ID or name

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5662:


 Summary: Primary index name should contain type ID or name
 Key: IGNITE-5662
 URL: https://issues.apache.org/jira/browse/IGNITE-5662
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.1


Currently, the primary index name contains neither type ID nor type name. Since 
metadata storage allocates tree root based on the index name, two different 
indexes will be using the same index tree.

Attached test reproduces this issue.

A correct fix would be to include type ID or type name (depends on the current 
SQL internals) to the index name.



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

[jira] [Updated] (IGNITE-5661) ignite.NET serialization failed when entity has property with IList and equals to null

[Chris Wang (JIRA)]

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

Chris Wang updated IGNITE-5661:
---
Description: 
when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:java}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}

  was:
when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:c#}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}


> ignite.NET serialization failed when entity has property with IList and 
> equals to null
> --
>
> Key: IGNITE-5661
> URL: https://issues.apache.org/jira/browse/IGNITE-5661
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.0
> Environment: windows server 2012 x64
>Reporter: Chris Wang
>
> when using datastreamer or cache.put, insert entities into a cache, if there 
> are some properties with IList type and value is null, serialization might 
> failed, and no cache exists in H2 database even queryentities has been 
> configured. but cache.count() return the count that inserted.
> like codes below generates an empty cache in ignite h2 db:
> {code:java}
> using (var dc = GetDbContext(branchId)) //dc is DbContext
> {
> var infoList = 
> dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
> && cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property 
> IList Subsidaries and value is null.
> foreach (var item in infoList)
> {
> ds.AddData(item.PK, item);
> count++;
> if (count % 1000 == 0)
> 
> Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
> }
> ds.Flush();
> }
> 
> {code}



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

[jira] [Created] (IGNITE-5661) ignite.NET serialization failed when entity has property with IList and equals to null

[Chris Wang (JIRA)]

Chris Wang created IGNITE-5661:
--

 Summary: ignite.NET serialization failed when entity has property 
with IList and equals to null
 Key: IGNITE-5661
 URL: https://issues.apache.org/jira/browse/IGNITE-5661
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: windows server 2012 x64
Reporter: Chris Wang


when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:c#}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}



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

[jira] [Created] (IGNITE-5660) ignite.NET serialization failed when entity has property with IList and equals to null

[Chris Wang (JIRA)]

Chris Wang created IGNITE-5660:
--

 Summary: ignite.NET serialization failed when entity has property 
with IList and equals to null
 Key: IGNITE-5660
 URL: https://issues.apache.org/jira/browse/IGNITE-5660
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: windows server 2012 x64
Reporter: Chris Wang


when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:c#}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}



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

[jira] [Commented] (IGNITE-5659) BinaryMarshaller loads class with local classloader even if it excluded in Configuration

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-5659:
-

Test case to reproduce bug:

https://github.com/nizhikov/ignite/blob/bf5585d8095307a714bb14915192d017be9ae81d/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/GridCacheEmptyScanQueryTest.java#L144

> BinaryMarshaller loads class with local classloader even if it excluded in 
> Configuration
> 
>
> Key: IGNITE-5659
> URL: https://issues.apache.org/jira/browse/IGNITE-5659
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.0
>Reporter: Nikolay Izhikov
>Priority: Critical
>
> Run Ignite with configuration:
> Two nodes: server and client
> # BinaryMarshaller
> # PeerClassLoadingEnabled = true
> # PeerClassLoadingLocalClassPathExclude = org.apache.ignite.test.*
> Do following actions:
> # put some Employee data to the server node
> # run ScanQuery from client node
> Error on step 2:
> {noformat}
> Caused by: java.lang.ClassCastException: 
> org.apache.ignite.test.ignite2190.Employee cannot be cast to 
> org.apache.ignite.test.ignite2190.Employee
>   at 
> org.apache.ignite.test.ignite2190.EmployeePredicate.apply(EmployeePredicate.java:8)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:3000)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.onHasNext(GridCacheQueryManager.java:2923)
>   at 
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
>   at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1188)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:231)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1020)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:541)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:359)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:296)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:286)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
>   ... 3 more
> {noformat}



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

[jira] [Assigned] (IGNITE-5437) SQL: Incorrect partition is derived from query when argument type differs from column type

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5437:
---

Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> SQL: Incorrect partition is derived from query when argument type differs 
> from column type
> --
>
> Key: IGNITE-5437
> URL: https://issues.apache.org/jira/browse/IGNITE-5437
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
> Fix For: 2.1
>
> Attachments: BugReproducer5437.java
>
>
> Ignite SQL attempts to derive partition from the query in certain cases and 
> sends the map queries only to nodes which have those calculated partitions.
> Such queries are limited to contain equality conditions over key or affinity 
> key columns at the left and constant or parameter at the right.
> When the type of argument does not match the column type, the calculation 
> leads to wrong result.
> For example, the following query produces incomplete results when _key column 
> is INTEGER and the argument is CHAR. 
> select * from test where _key = ?
> However, this is valid and resultive query for H2, which does implicit 
> conversion in such cases.



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

[jira] [Assigned] (IGNITE-5204) The Unicode character in the value of a field which are included in an un-unique index will cause "stack overhead" exception

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5204:
---

Assignee: Sergey Kalashnikov  (was: Vladimir Ozerov)

> The Unicode character in the value of a field which are included in an 
> un-unique index will cause "stack overhead" exception
> 
>
> Key: IGNITE-5204
> URL: https://issues.apache.org/jira/browse/IGNITE-5204
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, sql
>Affects Versions: 2.0
> Environment: windows server 2012, JDK 1.8, X64
>Reporter: Chris Wang
>Assignee: Sergey Kalashnikov
>Priority: Critical
> Fix For: 2.1
>
> Attachments: IgniteSqlIssue5204Test.java
>
>
> When put  "草DX009090" as the value of BillId, which is a field of entity 
> Bill. If I define a index includes the BillId, and execute the query like 
> "select * from Bill where BillId=’草DX009090‘ in the H2 debug console, there 
> throws an exception by the H2 with a code 5000. 
> another scenario is, I have two entities, "Bill" and "Detail", both have 
> field "BillId". If either of them have value like "草DX009090" and execute the 
> query like "select bill.* from bill left join detail on 
> bill.billid=detail.billid", the whole ignite cache node will halt ( suppose 
> there should be an stack overhead exception, dead loop).
> ==
> I think the issue should relate to hash computing on the unicode character.



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

[jira] [Assigned] (IGNITE-5533) CREATE INDEX failed if table has been re-created

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5533:
---

Assignee: Alexander Paschenko  (was: Sergi Vladykin)

> CREATE INDEX failed if table has been re-created
> 
>
> Key: IGNITE-5533
> URL: https://issues.apache.org/jira/browse/IGNITE-5533
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kozlov
>Assignee: Alexander Paschenko
>Priority: Critical
> Fix For: 2.1
>
>
> The brief scenario:
> create table t1 - ok
> insert t1 - ok
> create index t1 - ok
> drop table t1 - ok
> create table t1 - ok
> insert t1 - ok
> create index t1 - fail
> {noformat}
> [21:13:46,190][SEVERE][sql-connector-#239%null%][JdbcRequestHandler] Failed 
> to execute SQL query [reqId=25, req=JdbcQueryExecuteRequest [schemaName=nu
> ll, pageSize=1024, maxRows=0, sqlQry=create index on "PUBLIC".t1 (b desc), 
> args=[]]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Schema 
> change operation failed: Failed to execute SQL statement on internal H2 d
> atabase: CREATE INDEX "t1_b_desc_idx" ON "PUBLIC"."T1" ("B" DESC, "_KEY" ASC)
> at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.convert(DdlStatementsProcessor.java:277)
> at 
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:221)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1331)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1856)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:1852)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1860)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:188)
> at 
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:122)
> 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:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {code:title=repoducer.java|borderStyle=solid}
> Connection conn = 
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1");
> Statement stmt = conn.createStatement();
> for (int i=0; i < 2; i++) {
> String t = Integer.toString(1);
> print(t);
> stmt.execute("drop table if exists \"PUBLIC\".t" + t);
> stmt.execute("create table \"PUBLIC\".t" + t + " (a int 
> primary key, b varchar(30))");
> for (int j=1; j < 10; j++) {
> String s = Integer.toString(j);
> stmt.execute("insert into \"PUBLIC\".t" + t + " (a,b) 
> values (" + s + ", '" + s + "')");
> }
> stmt.execute("create index on \"PUBLIC\".t" + t + " (b 
> desc)");
> stmt.execute("drop table \"PUBLIC\".t" + t);
> }
> {code}



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

[jira] [Updated] (IGNITE-5658) Optimizations for data streamer

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-5658:
--
Fix Version/s: 2.1

> Optimizations for data streamer
> ---
>
> Key: IGNITE-5658
> URL: https://issues.apache.org/jira/browse/IGNITE-5658
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yakov Zhdanov
>  Labels: performance
> Fix For: 2.1
>
>
> Data streamer can be improved with this:
> -batch on per-partition basis and send batches to striped pool
> -New default - perNodeParallelOps should be twice CPU count of a remote node 
> (if not set by user, if set then parallelOps for every node is the value 
> provided by user)
> -wait stable topology error should be output as warn



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

[jira] [Assigned] (IGNITE-5187) Dynamic index create/drop tests are flaky

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5187:
---

Assignee: Alexander Paschenko  (was: Taras Ledkov)

> Dynamic index create/drop tests are flaky
> -
>
> Key: IGNITE-5187
> URL: https://issues.apache.org/jira/browse/IGNITE-5187
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> Currently we rely on {{Thread.sleep}}. Probably we need something more 
> reliable.



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

[jira] [Assigned] (IGNITE-5187) Dynamic index create/drop tests are flaky

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5187:
---

Assignee: Taras Ledkov  (was: Vladimir Ozerov)

> Dynamic index create/drop tests are flaky
> -
>
> Key: IGNITE-5187
> URL: https://issues.apache.org/jira/browse/IGNITE-5187
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.1
>
>
> Currently we rely on {{Thread.sleep}}. Probably we need something more 
> reliable.



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

[jira] [Assigned] (IGNITE-5449) Add complex DDL+DML test.

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5449:
---

Assignee: Alexander Paschenko

> Add complex DDL+DML test.
> -
>
> Key: IGNITE-5449
> URL: https://issues.apache.org/jira/browse/IGNITE-5449
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> We need a test that will test data flow behavior in chain of DML+DDL 
> operations as a whole.



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

[jira] [Assigned] (IGNITE-5279) DDL: Improve test coverage for objects with different cases (upper/lower)

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-5279:
---

Assignee: Alexander Paschenko

> DDL: Improve test coverage for objects with different cases (upper/lower)
> -
>
> Key: IGNITE-5279
> URL: https://issues.apache.org/jira/browse/IGNITE-5279
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
> Fix For: 2.1
>
>
> 1) Case 1: create case insensitive table, say {{CREATE TABLE MyTable}}. Then 
> make sure that it is accessible (i.e. DML and DTOP TABLE) through both 
> {{MyTable}}, {{MYTABLE}} and {{"MYTABLE"}}
> 2) Case 2: create case-sensitive table, say {{CREATE TABLE "MyTable"}}. Make 
> sure that it is accessible through only {{"MyTable"}}
> 3) Case 3-4: same as case 1-2, but for indexes and without DML, respectively.



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

[jira] [Updated] (IGNITE-5482) Implement basic caching of query results

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5482:

Fix Version/s: (was: 2.1)
   2.2

> Implement basic caching of query results
> 
>
> Key: IGNITE-5482
> URL: https://issues.apache.org/jira/browse/IGNITE-5482
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.0
>Reporter: Alexander Paschenko
>Assignee: Alexander Paschenko
>  Labels: important
> Fix For: 2.2
>
>
> Sergi suggested that we reuse results of the same queries running 
> simultaneously - i.e. if a query is being executed with the same arguments 
> and flags again and again, there's no need to do actual querying of data, 
> instead we can really run query once while other simultaneous runs will wait 
> for those results.
> This strategy will be implemented on MAP stage of distributed query.



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

[jira] [Created] (IGNITE-5659) BinaryMarshaller loads class with local classloader even if it excluded in Configuration

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-5659:
---

 Summary: BinaryMarshaller loads class with local classloader even 
if it excluded in Configuration
 Key: IGNITE-5659
 URL: https://issues.apache.org/jira/browse/IGNITE-5659
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Nikolay Izhikov
Priority: Critical


Run Ignite with configuration:

Two nodes: server and client

# BinaryMarshaller
# PeerClassLoadingEnabled = true
# PeerClassLoadingLocalClassPathExclude = org.apache.ignite.test.*

Do following actions:

# put some Employee data to the server node
# run ScanQuery from client node

Error on step 2:

{noformat}
Caused by: java.lang.ClassCastException: 
org.apache.ignite.test.ignite2190.Employee cannot be cast to 
org.apache.ignite.test.ignite2190.Employee
at 
org.apache.ignite.test.ignite2190.EmployeePredicate.apply(EmployeePredicate.java:8)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:3000)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.onHasNext(GridCacheQueryManager.java:2923)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1188)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:231)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1020)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:541)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:359)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:296)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:286)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
... 3 more
{noformat}



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

[jira] [Resolved] (IGNITE-1365) Unable to deserialize object because class ID key is not in the cache

[Semen Boikov (JIRA)]

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

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

This issue is not possible anymore since marshaller cache was removed in 2.0.

> Unable to deserialize object because class ID key is not in the cache
> -
>
> Key: IGNITE-1365
> URL: https://issues.apache.org/jira/browse/IGNITE-1365
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
> Fix For: 2.0
>
>
> There is a test that fails because of object deserialization issue:
> http://204.14.53.153/viewLog.html?buildId=65291=buildResultsDiv=Ignite_IgniteBasic#testNameId7413691472559096192
> According to the log, the reason of the failure is the following:
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.cluster.ClusterTopologyServerNotFoundException: 
> Failed to map keys for cache (all partition nodes left the grid).
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.map(GridPartitionedGetFuture.java:308)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.init(GridPartitionedGetFuture.java:199)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAllAsync0(GridDhtAtomicCache.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1300(GridDhtAtomicCache.java:124)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$10.apply(GridDhtAtomicCache.java:336)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$10.apply(GridDhtAtomicCache.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:648)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAllAsync(GridDhtAtomicCache.java:334)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1345)
> at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:148)
> at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
> at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:256)
> {noformat}
> However, if to take a look at the test code we will see that this situation 
> is impossible: all the nodes should be alive during the test's execution.
> It means that the issue is somewhere in {{GridCacheAdapter.getTopologySafe}} 
> implementation.



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

[jira] [Updated] (IGNITE-1365) Unable to deserialize object because class ID key is not in the cache

[Semen Boikov (JIRA)]

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

Semen Boikov updated IGNITE-1365:
-
Fix Version/s: 2.0

> Unable to deserialize object because class ID key is not in the cache
> -
>
> Key: IGNITE-1365
> URL: https://issues.apache.org/jira/browse/IGNITE-1365
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
> Fix For: 2.0
>
>
> There is a test that fails because of object deserialization issue:
> http://204.14.53.153/viewLog.html?buildId=65291=buildResultsDiv=Ignite_IgniteBasic#testNameId7413691472559096192
> According to the log, the reason of the failure is the following:
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.cluster.ClusterTopologyServerNotFoundException: 
> Failed to map keys for cache (all partition nodes left the grid).
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.map(GridPartitionedGetFuture.java:308)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture.init(GridPartitionedGetFuture.java:199)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAllAsync0(GridDhtAtomicCache.java:1048)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1300(GridDhtAtomicCache.java:124)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$10.apply(GridDhtAtomicCache.java:336)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$10.apply(GridDhtAtomicCache.java:334)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:648)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAllAsync(GridDhtAtomicCache.java:334)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1345)
> at 
> org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:148)
> at 
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
> at 
> org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:256)
> {noformat}
> However, if to take a look at the test code we will see that this situation 
> is impossible: all the nodes should be alive during the test's execution.
> It means that the issue is somewhere in {{GridCacheAdapter.getTopologySafe}} 
> implementation.



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